• Advertisement
Sign in to follow this  

Parallel Split Shadowmapping

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

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

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Doesn't that make the algorithm quite sensitive to geometric complexity?
Yes. With four shadow maps you render eight times. It is better to render only five times :-). You achieve this by using a texture atlas and then using the texture atlas to render only once.
<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>.

Quote:
Also, Is Cascaded shadowmapping the same as Parallel Split Mapping?

I would think so.

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
so the technique wouldn't be view-dependant
You mean view in-dependant right? You can only do this if you know that the area you want to cover has a known size. For example in a Baseball game or any sports game you know the size of the field.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
it depends on the scene ... if you want shadows at nights on a number of point lights, cached shadow maps make sense. So you mount them to those light sources and cache the shadows in a huge texture atlas ... probably with 16 or 32 small maps (256x256). A good technique here is variance shadow maps. They have a good ratio between performance and errors in that case.

Share this post


Link to post
Share on other sites
Quote:
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).
Oh I work for R* ...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Ok, I decided to ignore the view-dependancy for a while and try to implement a standard case of Parallel Split Shadowmapping.
They talk about clearing the Z-buffer to 0 before they render the backface geometry into the shadowmap, to make use of Z-culling. Is this equivalent to a glClear(GL_DEPTH_BUFFER_BIT); before rendering into the offscreen depth buffer?

Jeroen

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement