is this the best way to do it? seems to me like alot of space is wasted...
[Edited by - Dragon_Strike on June 1, 2007 2:04:59 PM]
splitting frustum for shadowmaps
Author
im doin some experimenting on splitting the lightfrustum to fit the view frustum.. similar to cascaded shadowmaps and PSSM.. but im unsure how these techniques calculate the view frustun... so ive tried doin it myself...
basicly since im using ortho projection for my light im using boxes to define the light frustum... the box is set by -near,far,size = furstumsize/2
i split the viewfrustum using 3 splitplanes... and then put a box inbetween two splitplanes and set the size to fit the viewfrustum in all cases...
something like this..
is this the best way to do it? seems to me like alot of space is wasted...
[Edited by - Dragon_Strike on June 1, 2007 2:04:59 PM]
is this the best way to do it? seems to me like alot of space is wasted...
[Edited by - Dragon_Strike on June 1, 2007 2:04:59 PM]
Damn good picture.. I'm working out the same thing on my project. Your picture seems logical in 2 dimensions, but I think if you looked at it from the camera view with the light shining down and acrost the view frustum.. you would notice regions of the frustum get excluded from light calculations.
Maybe I'm wrong but that is what I am finding.
Please keep in touch with me if you find out any solutions, I will do the same.
Or you can check up on my blog hopefully I'll have CSM's figured out by the end of next week.
-Matt
Maybe I'm wrong but that is what I am finding.
Please keep in touch with me if you find out any solutions, I will do the same.
Or you can check up on my blog hopefully I'll have CSM's figured out by the end of next week.
-Matt
Author
it works fine in 3d since its centered at the midpoint... but i dont think the box thing is right since it will skip objects that might cause shadows before the view.. so i think i should move the near clip furrther away from the midpoint
Alright, spent some time playing applying your picture to my code. There definately is some extremly wasted depth map space. Right now I'm calculating a cube shaped orthogonal depth map with the worst case radius (as illustrated in your picture). I'm also linearly dividing the view frustum depths which I'm sure is not optimal.
I'm pretty sure, from remembering what I've read and actualy playing with it, that instead of only considering the worst case, all 8 corners defining the depth map's view frustum region should be translated into the lights space so that all 6 planes of the depth projection can be set as tightly as possible.
Here are some pictures of what I've done, thanks for the inspiration and hopefully we can knock this thing out.
I'm pretty sure, from remembering what I've read and actualy playing with it, that instead of only considering the worst case, all 8 corners defining the depth map's view frustum region should be translated into the lights space so that all 6 planes of the depth projection can be set as tightly as possible.
Here are some pictures of what I've done, thanks for the inspiration and hopefully we can knock this thing out.
Author
the problem here is that u always have to render in the direction the light is facing... is there any way u could do shadowmapping W/O rendering in the direction of the light and only use the light projectionmatrix for setting the depth...
EDIT:: i dont think that something is better then its worst case... i dont see any point in switching between good<->bad depending on the viewdir..
btw.. what shadowmap depth are u using? or would recommend?
im just wondering but would it be possible as a speed up to only update one shadowmap each frame? that would mean if u have 4 shadowmaps itd take 4 frames to update the entire shadowinformation... and itd be "4 times faster" without any noticeable visual costs... or?
[Edited by - Dragon_Strike on June 2, 2007 6:22:37 AM]
EDIT:: i dont think that something is better then its worst case... i dont see any point in switching between good<->bad depending on the viewdir..
btw.. what shadowmap depth are u using? or would recommend?
im just wondering but would it be possible as a speed up to only update one shadowmap each frame? that would mean if u have 4 shadowmaps itd take 4 frames to update the entire shadowinformation... and itd be "4 times faster" without any noticeable visual costs... or?
[Edited by - Dragon_Strike on June 2, 2007 6:22:37 AM]
The way that I do it is to project bounding volumes of the various splits into 2D light space and "zoom" the standard shadow projection matrix in on the relevant 2D rectangle. This seems to work pretty well in practice, although I'm sure that one could do better if they thought about it for a while.
No - you have to render from the light's point of view to get proper occlusion.
You can certainly do this, but all of the implementations that I've seen that use such an optimization look terrible; i.e. it's very obvious. In particular split edge problems become even more obvious due to increased temporal incoherence. Such a technique will also play very poorly with multi-gpu setups like SLI or Crossfire since it will force at least one shadow map to be transferred between the GPUs every frame.
Quote:Original post by Dragon_Strike
the problem here is that u always have to render in the direction the light is facing... is there any way u could do shadowmapping W/O rendering in the direction of the light and only use the light projectionmatrix for setting the depth...
No - you have to render from the light's point of view to get proper occlusion.
Quote:Original post by Dragon_Strike
im just wondering but would it be possible as a speed up to only update one shadowmap each frame? that would mean if u have 4 shadowmaps itd take 4 frames to update the entire shadowinformation... and itd be "4 times faster" without any noticeable visual costs... or?
You can certainly do this, but all of the implementations that I've seen that use such an optimization look terrible; i.e. it's very obvious. In particular split edge problems become even more obvious due to increased temporal incoherence. Such a technique will also play very poorly with multi-gpu setups like SLI or Crossfire since it will force at least one shadow map to be transferred between the GPUs every frame.
what you want is a light view frustum that only encloses the split. It should be a rectangle that is "fixed" to the camera direction. So when you look from above in 2D space on it, you see rectangles overlapping slightly, enclosing the splits. This way you loose only the corners of the rectangles that are towards the viewer.
I haven't found the "right" way to construct a light view frustum, but I am convinced now that there is always some shadow map resolution loss involved, independently how hard you try.
If the light view frustum is closer than the viewer's frustum slice you enclose two things actually have happened:
- you lost resolution
- you draw more than you should
The later can be solved by involving culling planes that are parallel to the viewer's view frustum. This way you can cull out objects that would lie in the wasted corners of the light view frustum.
- Wolf
I haven't found the "right" way to construct a light view frustum, but I am convinced now that there is always some shadow map resolution loss involved, independently how hard you try.
If the light view frustum is closer than the viewer's frustum slice you enclose two things actually have happened:
- you lost resolution
- you draw more than you should
The later can be solved by involving culling planes that are parallel to the viewer's view frustum. This way you can cull out objects that would lie in the wasted corners of the light view frustum.
- Wolf
It should be noted that if you combine a splitting scheme with a warping scheme (like TSM, LiPSM, etc) you can probably get more uniform usage of the shadow map(s). That said I've found the latter to be a bit overkill in most of my tests, but it will of course depend on your scene.
Great picture, Dragon_Strike.
I'm in the process of implementing the exact same thing (I'm sure we're all doing this type of shadowing these days). I agree that finding the optimal light frustum for a given split is not well addressed by much of the literature. Seems you've found a method that will work in all cases, but is unsatisfyingly suboptimal. I'm in the same boat.
It occurs to me that by rotating the light's orthogonal frustum about the Z axis you could find an orientation which would allow it to be shrunk some, but I have no idea how to determine that optimal rotation.
And of course, as noted in the PSSM paper, it may be worth looking into fitting the light frustum to the bounding volume of the shadow casters in the split, rather than the split frustum itself.
I'm in the process of implementing the exact same thing (I'm sure we're all doing this type of shadowing these days). I agree that finding the optimal light frustum for a given split is not well addressed by much of the literature. Seems you've found a method that will work in all cases, but is unsatisfyingly suboptimal. I'm in the same boat.
It occurs to me that by rotating the light's orthogonal frustum about the Z axis you could find an orientation which would allow it to be shrunk some, but I have no idea how to determine that optimal rotation.
And of course, as noted in the PSSM paper, it may be worth looking into fitting the light frustum to the bounding volume of the shadow casters in the split, rather than the split frustum itself.
Dragon_strike, you would not be switching between the worst and non worse scenerio, it would be the same algorithm the whole time which in the worse case could produce the above projections, but in the best case would provide much tighter bounds.
Also right now I'm setting my ortho near and far planes to -radius, radius, essentially creating a cube around the shadowed region. massive waste of depth since my shadow maps start WAYYY in the sky.. I think I'm going to add a "shadow safe height" that the depth map frustums will never exceed as it's not necessary.
Also right now I'm setting my ortho near and far planes to -radius, radius, essentially creating a cube around the shadowed region. massive waste of depth since my shadow maps start WAYYY in the sky.. I think I'm going to add a "shadow safe height" that the depth map frustums will never exceed as it's not necessary.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement