Hello,
I'm implementing a deferred shading renderer based on OpenGL. I got everything setup and lighting seems to work but I can't figure out why the light is appearing on the faces that should be completely dark.
For non-normal-mapped objects everything works fine. So I guess there is something wrong with my tangent-space normalmaps.
Here's the code for generating g-buffer-normal-map (in view-space):
[source lang="cpp"]Vertex Shader:
normal = normalize(gl_NormalMatrix * gl_Normal);
vec3 t = normalize(gl_NormalMatrix * gl_MultiTexCoord1.xyz);
vec3 b = cross(normal,t);
TBN = mat3(t,b,normal);
Fragment Shader:
vec3 n = (texture2D(normalMap,gl_TexCoord[0].st).rgb-0.5)*2;
n = normalize(TBN * n);
gl_FragData[2] = vec4((n+1)*0.5,1); [/source]
Even if I only display dot(normal,lightdir) I get light artifacts on the faces the light shouldn't reach ...
Here are images of the "final" lightmap render and the normalmap from the g-buffer.
Thanks for your help
Deferred shading - problems with normal map
Even if I only display dot(normal,lightdir) I get light artifacts on the faces the light shouldn't reach ...
At the first glance I would say, that your normals are correct. I guess that you have a missconception. When you have a surface facing away from your lightsource, the angle between surface normal and light is greater than 90 degree which lead to cutting off the light. But applying a normal map to this surface, the normals rendered to the gbuffer start to bend and this could lead to bending to less then 90 degree which lead to lighting of back faced surfaces.
Either try to avoid such drastically normal maps to lessen the artifacts, use a shadow map or save the surface normal too. The latter is quite easy, but will cost additional bandwidth, but in this case you would leave out the lighting calculation if the surface normal is pointing away.
Author
Thanks for your answer!
I had the same explanation for the problem but if this is really what is causing the problem I wonder why normal maps can store normals that go in the face they are displayed on. I see that for calculations with the TBN-matrix you need a vector with values from -1 to 1 but why do I store those vectors in the final normalmap?
I guess i have to play with the tangent-space normalmaps then.
Thanks again for your answer.
I had the same explanation for the problem but if this is really what is causing the problem I wonder why normal maps can store normals that go in the face they are displayed on. I see that for calculations with the TBN-matrix you need a vector with values from -1 to 1 but why do I store those vectors in the final normalmap?
I guess i have to play with the tangent-space normalmaps then.
Thanks again for your answer.
I wonder why normal maps can store normals that go in the face they are displayed on
They don't need to. A simple, though extreme, example:
1. Polygon normal points up, directional light source from the left => polygon is perpendicular to light source => no lighting at all
2. Same as 1, but you have a normal map with normals pointing to the left => polygon is still perpendicular, but some normals pointing directly to the light source => texel get directly lighted by light source
As you can see, you don't need any normals pointing into the surface. This is the extreme case, more sane normals will have the same problem, even if they don't get lit with a high intensity.
TBN-matrix you need a vector with values from -1 to 1 but why do I store those vectors in the final normalmap?
Most often you only need this for the x,y component, which is absolutly legal and necessary. The z component (pointing away from the surface) is in 99.9% of the time positive, this is the reason all the normals maps got this bluish tint(z-component=b channel > 0.5). But as stated above, the problem is not that a normal is pointing into the surface.
I guess i have to play with the tangent-space normalmaps then.
This is not a problem you can solve by playing around with the tangent-space normal maps, you can only lessen the effect by reducing the angle between surface normal and tangent normal. If you want to get rid of the effect, use either surface normals for normal map culling or shadow mapping or accept it
Author
Sorry for not posting some weeks now. I've lots of work at university at the moment ;)
I kind of fixed it for now. But using way to extreme Normalmaps will bring back the bug.
Thanks for your help!
I kind of fixed it for now. But using way to extreme Normalmaps will bring back the bug.
Thanks for your help!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
