[Patch] Bug in Steep Parallax Mapping of Lighting shader

Development
1

There’s a bug in Steep Parallax Mapping of the Lighting shader. At low angles, the mapping looks deformed (see video).



http://www.youtube.com/watch?v=gFaNNZAIxKI



The problem is, that steepParallaxOffset() needs vViewDir unnormalized. After applying the patch below, it looks like this:

http://www.youtube.com/watch?v=_13cQcVwlbE


I found this bug while trying to implement "Dynamic Parallax Occlusion Mapping with Approximate Soft Shadows". It's not yet done, but here's a first preview:

http://www.youtube.com/watch?v=y-I3LtwUhxI


Btw, is there an easy way to get the compiled assembler output of a jme shader (without adjusting the shader to RenderMonkey or the like)?

Warning: The backslash before "No newline at end of file" has been swallowed by WordPress. Press "quote" to see it. No idea if these lines are needed anyway.

[patch]
Index: Lighting.vert
--- Lighting.vert Base (BASE)
+++ Lighting.vert Locally Modified (Based On LOCAL)
@@ -158,7 +158,7 @@
mat3 tbnMat = mat3(wvTangent, wvBinormal * -inTangent.w,wvNormal);

//vPosition = wvPosition * tbnMat;
- vViewDir = viewDir * tbnMat;
No newline at end of file
+ vViewDir = -wvPosition * tbnMat;
No newline at end of file
lightComputeDir(wvPosition, lightColor, wvLightPos, vLightDir);
vLightDir.xyz = (vLightDir.xyz * tbnMat).xyz;
#elif !defined(VERTEX_LIGHTING)
[/patch]

[patch]
Index: Lighting.frag
--- Lighting.frag Base (BASE)
+++ Lighting.frag Locally Modified (Based On LOCAL)
@@ -249,8 +249,9 @@
#else
vec4 lightDir = vLightDir;
lightDir.xyz = normalize(lightDir.xyz);
+ vec3 viewDir = normalize(vViewDir);

- vec2 light = computeLighting(normal, vViewDir.xyz, lightDir.xyz) * spotFallOff;
+ vec2 light = computeLighting(normal, viewDir, lightDir.xyz) * spotFallOff;
#ifdef COLORRAMP
diffuseColor.rgb *= texture2D(m_ColorRamp, vec2(light.x, 0.0)).rgb;
specularColor.rgb *= texture2D(m_ColorRamp, vec2(light.y, 0.0)).rgb;
[/patch]
10 Likes
2

Top, this was annoying me/us for a long time now ^^ Thanks

3

It looks great! We could never quite fix that bug …

By the way, can we change the vViewDir variable to something that better suits its contents? It actually contains the world view position, so perhaps it should be named as such (wvPosition?)

4

Brilliant!

Thanks for this fix i’ll commit it.



Your soft shadows version looks nice, keep it up :wink:


@Momoko_Fan said:
By the way, can we change the vViewDir variable to something that better suits its contents? It actually contains the world view position, so perhaps it should be named as such (wvPosition?)

I always wondered why it was called like that, i never changed it because i tough you had a valid reason :p
I'll change it too

EDIT : now you can use parallax mapping on a quad without distortion....can't believe it was the issue!!! Thanks Survivor
5
@Momoko_Fan said:
By the way, can we change the vViewDir variable to something that better suits its contents? It actually contains the world view position, so perhaps it should be named as such (wvPosition?)

In case of normal mapping, it contains the (unnormalized) view vector in tangent space. If you use the same variable for view space and tangent space lighting, then no prefix would be best. I'm still looking for a good naming convention in my shader. Some people use hungarian notation. I prefix varyings with "v_" and then the space i.e. "v_wsNormal" or "v_tsView". But I wonder if "v_v3ViewTS" or "v_v3_ViewTS" would be better. I can really lo(o)se myself in these details an get nothing done. :(
1 Like
6
@survivor said:
In case of normal mapping, it contains the (unnormalized) view vector in tangent space. If you use the same variable for view space and tangent space lighting, then no prefix would be best. I'm still looking for a good naming convention in my shader. Some people use hungarian notation. I prefix varyings with "v_" and then the space i.e. "v_wsNormal" or "v_tsView". But I wonder if "v_v3ViewTS" or "v_v3_ViewTS" would be better. I can really lo(o)se myself in these details an get nothing done. :(

The v stands for varying. View direction is in tangent space if normal mapping is used, otherwise its in view space. For that reason you can't really give it a prefix like "ts" or "ws"
7

@survivor , can you give your testscene? I’m very interested…

And how did you make the occlusion map?

8

It’s all in my RealSlimShader project (which is everything else but slim now). “MatDefs/LightingSP_POM.*” would be the file you are interested in. It’s basically a translation of Natalya Tatarchuk’s HLSL implementation. But it’s slow. And by slow I mean fcking slow. I’m trying to figure out why ("_1"). I guess it has something to do with dynamic branching and dependent texture lookups, but I’m new to this.



I just restored the project to a state that actually works so you can run it.

1 Like
9

Hey! thanks! I’ll try it.

10

Hey! @survivor , I’m very excited by the ProjectiveTextureMapping! I suppose it can be used for bullets holes and some projections…

You are welcome to the ShaderBlow project. http://code.google.com/p/jme-glsl-shaders/

If you finish the stuff in ProjectiveTextureMapping it would be cool to add it to the library. I can add you as a committer there.