Sign in to follow this  

Shadows not being projected correctly

This topic is 3595 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

So, here's what I'm doing: Set projection matrix to light's gluPerspective Set modelview matrix to light's gluLookAt Render the scene geometry into a depth-only FBO Set projection matrix to players's gluPerspective Set modelview matrix to players's gluLookAt Make texture matrix using: (bias matrix) * (light's projection) * (light's modelview) * (camera's modelview inverse) Render scene properly using the following shadow coordinates specified in the vert shader:
shadowCoord = gl_TextureMatrix[3] * gl_ModelViewMatrix * gl_Vertex + vec4(0.0,0.0,-0.004,0.0);
the offset is there to prevent z-fighting. This is what happens: However, if I place the gluLookAt for both the light and scene camera into the projection matrix, shadows are rendered correctly (but lighting breaks): Am I missing out on a step? The drawing of the geometry includes calling glLightfv with GL_POSITION, but taking it out didn't help. I'm not sure what other details might be requried, but here's the main bits. Thanks.

Share this post


Link to post
Share on other sites
Strangely, if I remove the inverse modelview from the matrix and the modelview multiplication from the shader, it works as expected - when the vertices aren't affected by the modelview matrix, such as with the floor, the shadow is rendered properly, but it obviously falls down when rendering on geometry affected by the modelview matrix.

Share this post


Link to post
Share on other sites
(bias matrix) * (light's projection) * (light's modelview) * (camera's modelview inverse)

No, that should be
(bias matrix) * (light's projection) * (light's modelview) * (object matrix)

and use polygon offsetting to avoid z-fighting.

And for rendering the scene
shadowCoord = gl_TextureMatrix[1] * ObjectMatrix * gl_Vertex;

The texture matrix should have
(bias matrix) * (light's projection) * (light's modelview)

Share this post


Link to post
Share on other sites
Wouldn't I have to compute an object matrix separately for each object then? The texture matrix contains the camera's modelview inverse so it would cancel out the gluLookAt from the modelview matrix inside the vert shader, leaving just the object transformation.
The complete transformation I'm doing is:
(bias matrix) * (light's projection) * (light's modelview) * (camera's modelview inverse) * (camera's and object's modelview).
The last two (should) cancel out the camera transformation. At least that's how I've understood the implementation.

Obviously something's gone wrong somewhere, though.

Share this post


Link to post
Share on other sites
1. Yes, you would compute the object matrix separatly.

2. The modelview should contain light_lookAt * objectMatrix for your
gl_Position = ftransform();

3. When you project from the light's pespective, the light is the camera.
No need for "camera's modelview inverse"

Share this post


Link to post
Share on other sites
1. That shouldn't be required for shadow mapping. (I guess that is one way to do it - but I'd like to avoid it if possible)
2. The vertex position should contain the light's view transformation when rendering the scene from the player's perspective?
3. What I mean by "camera's modelview inverse" is the inverse of the gluLookAt used when rendering the scene properly from the player's perspective, the only purpose of that matrix is to cancel out the camera transformation and leave just the object transformation (when multiplied by the modelview matrix in the vertex shader).

Share this post


Link to post
Share on other sites
For 1 and 3, I guess it depends on what you are doing. I'm answering based on what I'm doing.

Quote:

2. The vertex position should contain the light's view transformation when rendering the scene from the player's perspective?


When rendering from the player's perspective, the light is no longer the "camera".
The answer is simply : no

Share this post


Link to post
Share on other sites

This topic is 3595 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