Sign in to follow this  

GLSL gl_NormalMatrix transform breaks lighting?

This topic is 3662 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to set up lighting, and the fixed functionality does not look right. The lighting changes suddenly and incorrectly, often times with half a cube being brightly lit and the other half getting nothing but ambient lighting. However if I use a shader and DO NOT transform my normals by gl_NormalMatrix things look correct. I assume I'm transforming something I shouldn't be or not transforming something I should be, but I'm not sure where. I am also using a skinned animation system. My process is something like this:
Setup:
   Specify lighting parameters and enable lights/lighting
   Turn on the shader if I'm using one

Update Loop:
   Pose the skeleton
   Transform each vertex via binding and new world matrices
   Transform each normal via binding and new world matrices
   
Draw Loop:
   Push camera stuff into model view matrix
   Re-send light position (glLightfv(GL_POSITION...) so it stays with geometry as camera moves) 
   Draw each triangle in the transformed model
For testing purposes I've scaled the skin down to a single cube that doesn't animate and has a single bone. I've tried not transforming the normals via the skinning algorithm, but it doesn't make any difference. I've also tried not resending the light position but it is still no good! If I make my fragment shader use the normals for the frag color the cube looks like it has proper normals when I don't trasnform by gl_NormalMatrix. When I do transform by gl_NormalMatrix the normals change constantly as the eye position changes. The normals being fixed regardless of eye position seems correct to me, but I get kind of confused by all the different "spaces". I almost want to just write all my shaders to not use the gl_NormalMatrix transform, but I'm sure that if the fixed functionality doesn't work then writing shaders that look right without the transform would be a hack at best.

Share this post


Link to post
Share on other sites
So you are sending the light position into gl with glLightfv() with a 0.0 or 1.0 at the end? You realize that the light position is stored in eye coordinates? It is transformed by the modelview matrix...

Share this post


Link to post
Share on other sites
Quote:
Original post by MARS_999
So you are sending the light position into gl with glLightfv() with a 0.0 or 1.0 at the end? You realize that the light position is stored in eye coordinates? It is transformed by the modelview matrix...


With a 1 at the end.

Like let's say my light is at 1,3,3,1

Every frame I draw I start by computing the new modelview matrix for the camera.

Then I call gllightfv to send the position with 1,3,3,1 (I never change that value)

Then I draw my geometry.

Am I supposed to be doing some kind of transform on the light first?

Share this post


Link to post
Share on other sites
The light position is transformed by the modelview matrix when glLight is called (just as if it were a point), and it is stored in eye coordinates.

Post your rendering code so we can have a look.

Share this post


Link to post
Share on other sites
Aha!

I was trying to explain my code as I posted it for you, but in doing so I found my own problem.

I was multiplying the projection matrix into the modelview matrix when I updated the camera! I fixed it to put the projection in the projection matrix and the model view in the modelview matrix.

So now it works! Kind of! I was explicitly repositioning the light after the camera update and that made things still look "off", but I guess if the light is always automatically multiplied by the ModelView matrix then I don't have to do that unless I move my geometry in some way OTHER than via the modelview matrix, and I want the light to stick to it.

Thanks Mars!

(edited: I said perspective matrix when I meant projection matrix)

Share this post


Link to post
Share on other sites

This topic is 3662 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this