How to project shadow mapping for direction light in dynamic scene
Author
Hi all.
I want to add shadow mapping technique to my engine.. but i found some problem.
I dont know where to generate position and size of bounding of shadow projection when my light is directional light and my camera go around to scene.
For spot light or point light shadow mapping, shadow are projected to texture at light position, but for direction light, it doesn't have position.
If i set center of projection to be camera position, there are some parts of scene that doesnt be seen (ie. behind camera ) are project to texture..
How to know minimize shadowmap bounding that include and fit to frustum volume ?
Thx for help.
ps. Sorry for my bad english if it hard to read.
Essentially, for this situation you have to dynamically compute a temporary "working" position for your light.
One way to do it would be to transform the eight corners of the camera frustum into the light's "view" space. By doing this you can compute the FarZ (far clip plane distance) which would be the difference between the max.z and min.z corners of the camera frustum points in light view space.
You could then position the light by backing up from the centroid of the camera frustum in the opposite direction of the light by the amount of max.z. Your near clip plane would be 0.0, your far clip plane would max.z - min.z, your look at point would be the camera's frustum centroid, and your up vector would be anything orthogonal to your light's direction. You would build an othographic projection and your max/min values would simply by max.x & max.y and min.x & min.y.
Hopefully that makes some sense. :)
One way to do it would be to transform the eight corners of the camera frustum into the light's "view" space. By doing this you can compute the FarZ (far clip plane distance) which would be the difference between the max.z and min.z corners of the camera frustum points in light view space.
You could then position the light by backing up from the centroid of the camera frustum in the opposite direction of the light by the amount of max.z. Your near clip plane would be 0.0, your far clip plane would max.z - min.z, your look at point would be the camera's frustum centroid, and your up vector would be anything orthogonal to your light's direction. You would build an othographic projection and your max/min values would simply by max.x & max.y and min.x & min.y.
Hopefully that makes some sense. :)
Would you need to dynamically create this shadowmap for orthogonal directional light in a static scene as well? I ask because I am about to implement directional lights into my shadow mapping algo, and this method seems tied close to the camera?
Quote:Original post by qjones20
Would you need to dynamically create this shadowmap for orthogonal directional light in a static scene as well? I ask because I am about to implement directional lights into my shadow mapping algo, and this method seems tied close to the camera?
Depends. If your light and all objects will be static too, then no, there is no reason to render it more than once.
However, if the light direction will change then the entire shadow map will have to be re-rendered every frame. If objects will change, then something will have to be done dynamically. That's up to you to decide how to handle though.
Quote:
Depends. If your light and all objects will be static too, then no, there is no reason to render it more than once.
OK, so this is no different than normal shadow mapping. But it sounds like if you do re-render every frame, even for static objects, you may be able to gain some additional quality in your shadow maps because the lights near/far clip distance would be as close to the viewed scene as possible, which from what I understand implementing directional light shadow maps is very tough to get good quality, due to depth buffer imprecision. Especially with non-attenuated light sources like the sun.
Quote:Original post by qjones20Quote:
Depends. If your light and all objects will be static too, then no, there is no reason to render it more than once.
...you may be able to gain some additional quality in your shadow maps because the lights near/far clip distance would be as close to the viewed scene as possible, which from what I understand implementing directional light shadow maps is very tough to get good quality, due to depth buffer imprecision. Especially with non-attenuated light sources like the sun.
I'm not so sure about that. Remember that it's an orthographic projection which I "believe" results in a linear post-projected z-range. The number of hardware bits dedicated to the fractional part of a floating point number remains the same no matter what, so I don't believe you would gain anything really from adjusting near/far clip plane distances on a per-frame basis for a directional light.
What really matters when it comes to shadow mapping with a directional light is the area with which you're trying to stretch your shadow map over. The larger that physical world space area is compared to your shadow map size, the worse the noticeable aliasing will get.
Thanks for posting up the logic for updating the lights position. I had this doubt for a long time in how to determine the lights position. It makes sense that you have to adjust the position of the light based on the view frustum 
The tricks with directional lights are making the shadows stable when rotating or translating the camera.
The translation is a matter of padding the shadowmap 1 or 2 texels and computing how far off a shadowmap-texel-center the view origin is, and adjusting by that amount.
Rotations are harder, you need to compute the convex chunk of the view frustum going into the shadowmap cascade and treat it as a sphere so it becomes rotationaly invariant with repsect to resolution. This has side effects, as changing the field of view will cause the shadowmap to dance. Which can be worked around by not allowing, or rounding upt he field of view into buckets and inflating the verts making up the view frustum by the worst-case field of view of the bucket it is in. They shadows will still pop when transitioning buckets but that can be hidden by not allowing
The translation is a matter of padding the shadowmap 1 or 2 texels and computing how far off a shadowmap-texel-center the view origin is, and adjusting by that amount.
Rotations are harder, you need to compute the convex chunk of the view frustum going into the shadowmap cascade and treat it as a sphere so it becomes rotationaly invariant with repsect to resolution. This has side effects, as changing the field of view will cause the shadowmap to dance. Which can be worked around by not allowing, or rounding upt he field of view into buckets and inflating the verts making up the view frustum by the worst-case field of view of the bucket it is in. They shadows will still pop when transitioning buckets but that can be hidden by not allowing
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
