Hi, everyone, I've just taken a look at the parallel split shadowmapping demo and I must say that I'm quite impressed with the results they're getting. But they're suggesting to do multiple passes and reuse one shadow map. Doesn't that make the algorithm quite sensitive to geometric complexity? Also, because you make the projection dependant on the camera's frustum, you're forced to render the shadow geometry every frame. Isn't there a better way so that I don't lose the ability to cache my shadow maps, like standard shadowmapping? Also, Is Cascaded shadowmapping the same as Parallel Split Mapping? Just one proposition, wouldn't it be better to split the LIGHT's frustum, instead of the camera frustum. That way you don't have to render your shadow geometry if the light doesn't move. Jeroen

Hello,

first of all, thanks for the reply.

Quote:

Quote:Just one proposition, wouldn't it be better to split the LIGHT's frustum, instead of the camera frustum. That way you don't have to render your shadow geometry if the light doesn't move.

You slice the view frustum in slices and dedicate a shadow map to each of those slices. As soon as the camera moves you have to update the shadow maps.

I know that with parallel split maps you have to update your shadowmaps each time the camera moves, but wouldn't it be better to split the light's frustum or something, so the technique wouldn't be view-dependant (like standard shadowmapping).
Do you know of such a technique allready?

Jeroen

I'm quoting here something about cascaded shadowmapping:

"render the scene to each shadow map (so for N=3, you'll render the scene 3 times. Keep in mind that unlike perspective/light space shadow maps or similar techniques, you are not forced to re-render the shadow maps every frame, you can "cache" the shadow maps for a couple of frames)"

This text about cascaded shadowmapping explicitly states that it is possible to somehow cache the shadowmaps. I just don't have a clue how to do it.
Besides, some sites/papers on the net state it as the primary advantage of CSM's over PSM's.

Jeroen

Quote:Original post by wolf
<shameless plug> there will be an article in ShaderX5 that describes cascaded shadow maps and a practical implementation ... means it is running in games that will come out in 2007 </shameless plug>.

This wouldn't happen to be Crysis, would it? I noticed in some of the videos that it's using cascaded shadow maps (it exhibits some of the symptoms that a not-quite-super-tweaked implementation that one would expect).

Quote:

Quote:Just one proposition, wouldn't it be better to split the LIGHT's frustum, instead of the camera frustum. That way you don't have to render your shadow geometry if the light doesn't move.

You slice the view frustum in slices and dedicate a shadow map to each of those slices. As soon as the camera moves you have to update the shadow maps.

Fwiw, chances are you'd have to update significant portions of the shadow maps anyways, since A) it's likely you'll have some animation (be it simple movement or skinned anim) and B) as the camera moves, the light frustum's field of interest would have to move correspondingly. Regarding B, since most games have a camera that's moving somewhat frequently anyways you might as well just make the shadow map pattern view dependent, and have it clamped rather tightly to the view frustum to save yourself some memory/wasted fill. Hell, if you're feeling really ballsy and/or feel a bit cramped on video memory and what a higher res map, it's not totally out of the question to have just one or two dedicated shadow maps that you refresh a few times *coughidnextcough* each frame.

Quote:This text about cascaded shadowmapping explicitly states that it is possible to somehow cache the shadowmaps. I just don't have a clue how to do it.

Well, if you're able to store the shadow maps in video memory (e.g. for the 3 passes, store 2 shadow maps, and just refresh the second one, for the two closest regions, twice inside a frame, and the first one refresh every 2 or 3 frames) it's a cheap hack that would give decent results (although, I've never seen it in action). The onyl flaw is that further away objects/shadows aren't updated as smoothly/quickly. However, once you spill over the GPU memory limit your performance is probably going to run off of a cliff and straight into a pre-dug grave.

Also, if the consumer is using SLi or Crossfire you'll run into some performance snags due to the inter-frame-usage, depending on the quality of the implementation in the drivers. Of course, that IS only, what, 0.1% of the gaming population? They can keep on sucking their own e-peens, amirite?

If you have a scene of 500.000 polygons, you don't want to render this 2-3 times more per frame for shadowmapping. Especially for directional lights it is good to update your shadow map only once per 5-8 frames or not at all if you don't have lots of animation.

I got this from a post on gamedev:
"Carmack talked about a different scheme during quakecon, where shadowmaps have the same origin, but each one covers a bigger and bigger piece of the scene, while CSMs spread along the viewing direction (or its projection along the world's plane, if we talk about terrains, or relatively flat scenes).
Advantages, is to not have the perspective transform in the SM, with the obvious benefits of removing some aspects of the view dependance. This means, that the SM will cover the scene less dependantly on the view, and some artifacts will be less visible (like dancing shadow edges), AND computing the SM will not be nessecarily per frame (wich is a huge advandage). And the word 'uniform' mean a better handling of bias and z-related artifacts."

How would I go about to implement this?

Jeroen

In Ysaneya's Journal entry, there are some details about doing CSMs centered on the camera (and then snapped to texel boundries) that can be view independent:
http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&reply_id=2760249

I think this might have also been the approach taken on the Happycake project too - there are probably some details from the dev diary worth looking at there:
http://number-none.com/happycake/index.html

Ah, shadows.

[edit]
Ah, that text you quoted earlier was from Ysaneya's journal it seems. My apologies.

T