Hi!
I'm programming cascaded shadow maps for outdoor lighting. I'm following this opengl example:
http://developer.dow...shadow_maps.pdf
You can find the code here:
http://developer.dow...gl/samples.html

Code is pretty self [color=#000000][font=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif]

[background=rgb(250, 250, 250)]explanatory but I have a question. [/background][/font]

[font=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif][color=#000000]In order to get the near and far plane for every frustum, code says that we have to [/font]make sure that all relevant shadow casters are included into one unique shadow map. I mean when computing the farPlane and the near plane that define the current shadow map's frustum, if half an object is at one side of the far plane and the other part is at the other side, we have to recompute the farPlane to make sure that the object is completely inside one unique frustum.
Is that really necessary if we want to implement cascaded shadow maps? because to me that's a a pain in the neck. what if I skip that part of the algorithm?
Thanks

No, that would be impossible. As the player moves you would never be able to guarantee that your near frustum in their diagram will never cut an object up. I didn't find the part you referred to in that paper about uniqueness, but you will have to draw the object 2 times for the case of bleeding from the near to the far. Imagine if you had a giant forest, theres no way to adjust your frustum so that every tree is completely in the near OR completely in the far.

I mentioned this in one of the other cascaded shadow mapping threads, but do give adaptive shadow maps through rectilinear texture warping a gander. It only uses one map/'cascade' so lots of the cascaded shadow mapping edge cases aren't necessary. You can definitely get superior quality and possibly speed on top of it

2 issues I have with that video. I would like to see a non checkered ground scene and also not a flat ground because flat ground makes basically 0 shadows at distance no matter what method you use because 1 pixel steps at far distances (relative to a viewer who is 6 feet tall) could cover hundreds of feet from their viewpoint. So you need hills and other objects at far distances. The other issue, you have to render it every single frame. When I do cascades that cover very far distances with tons of trees and other things, I don't want to render it all every frame. So I have several cascades that are far away and only get updated when the player travels say 100 feet, then I take 1 snapshot again, and wait till they move another 100 feet from there. I supposed the local map closest to the player could use a method like you have posted to warp the shadow map, but you have not provided enough in that demo to say you only need 1 shadow map. So you need thousands more trees and better ground to fully prove it that is going to look good or not, and how you can keep framerates down with realistically big scenes.

That's actually the point of the algorithm. It's actually enlarging or shrinking regions on the shadow map based on how important they are to the final scene-- in the case you mention, the RTW warp maps would 'steal' some resolution from the surrounding/unimportant areas (say, stuff cast on scene backfaces or not in the view frustum outright) and use that for areas that are actually visible. With some tweaking, you could probably get uniform sampling density across the image!

Re: amortization-- True, this is an advantage of cascaded shadow maps. On the other hand, you don't need to do extra processing to determine which shadow map slice your objects will occupy or doing edge case handling when it straddles boundaries. Profile for your use case?

EDIT: There are some trees towards the end of the vid-- I think they hold up pretty well