generating shadow maps

Started by
5 comments, last by Basiror 19 years, 7 months ago
I've been doing some work with shadow mapping and I was curious about a couple of things. Since regenerating the shadowmaps takes a little time (more for point lights), but these do not have to be recalculated every frame, what it usually the suggested method for updating them? I figure a couple of possibilities.. 1) Seperate thread.. nice first thought, but I'm thinking this will be more trouble than its worth. 2) Tell the shadow maps to update portions of themselves each frame. So for point lights, I could generate one face each frame and every 6 frames (something along those lines) upload the new shadow map. However, for single 2D textures, I would want to update the whole thing if I'm gonna worry with it in the first place. Any thoughts on the matter?
Advertisement
The seperate thread idea is almost certainly worth forgetting about; unless you plan to lock the texture and render into it by hand (!) you'd need to make it a render target and everything, and that prevents you from rendering in your primary thread... if any multithreading were to happen you'd want something like [all graphics] + [everything else], but even then it's a pretty substantial undertaking.

It's certainly worth exploiting temporal coherence. I guess one of the first things you could do is a simple check of the volume of space that the light effects - if there are no dynamic objects being rendered into the shadow map then you certainly don't need to update it. As such, flagging partially-dynamic objects as inactive becomes important - things like doors or lifts, which are static most of the time.

As far as amortizing the stuff over multiple frames goes... that's certainly something you want to consider, but it's more useful under particular conditions, such as a fixed frame rate - you can see how much time you have left this frame, and possibly do a second face of the map.

I'm wondering about other things that could help... maybe multiple render targets somehow? Optimizing your shadow map renderer? Using fewer pointlights?

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Ok, glad I wasn't missing something with the seperate thread business.

I agree with the thoughts of using the time remaining metric because my primary concern was the framerate jumping around too much. However, I like not fixing the framerate but that would probably be the best way to do it, since then I can budget X percent of a given frame to regenerate shadow maps.

This process I figure would more so be targeted at my terrain renderer. Assuming no other dynamic movement except the sun which moves slowly (this is really the primary reason I started this thread), I was thinking that given n shadow maps for the terrain I could update blocks of them each frame instead of all of them. In doing so, I would basically have checkpoints in that when the sun moves a certain amount upload the new shadow maps. Problem with that is the shadows will pop too much I'm assuming.

Ah well, best way will probably just be to experiement and see what happens.
Hmm...

Say you generate shadow maps for 5-degree pitch intervals. At most you have 36 maps; what's more likely is that you'll generate them on the fly, so let's say you hold the map for the position the sun most recently passed, plus the one it's coming up to, and you're building the map for the one after - e.g. having the sun at 47 degrees moving upwards would mean maps for 45, 50, and 55 in memory at once.

Now, I'm wondering if it'd be possible to simply blend between the maps, weighting them to reflect which point the sun is closer to.

That ought to give you all the time you need to generate the map required for the next 'slice' of the arc.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

Seems like it would be possible to set the alpha value at 0 for the map at 50 degrees and 1 for the map at 47 degrees and then intepolate such that when the sun reaches 50 the alpha values for the map at 50 degrees is 1 and the map at 45 degrees is 0. Then ditch the map at 45 degress.

Good stuff, I think these are some great ideas!
You've got it pretty much right, but I think you may be overcautious on the impact of simply updating your shadow maps when they need updating.

We have many shadow casters in our terrain dbs, both static and moving. A shadow map update can be be triggered by 1) caster moving and/or 2) light moving. Moving casters updates are triggered pretty much every frame (since they are moving). Static caster updates are triggered when the light moves. We set a max number of casters updated per frame, and simply stop updating casters when we hit that number. We'll continue updating as many as possible each frame until we hit them all. We give preference (of course) to casters which are currently visible.

Result? Even with about 200 casters, updating 8 per frame, we get to them all within a few hundred milliseconds at 60 fps. Almost no performance impact, at least from the updating :)

Our casters are generally very minimal meshes, so they render quickly. I guess the secret to good performance in our case is highly optimized mechanics of casting and projecting. Anyway, shadow maps is good stuff.

joe
image space
or you use stencil shadows for models and shadowmaps for static geometry

would be cool if we could read back transformed vertices after the vertex shader
http://www.8ung.at/basiror/theironcross.html

This topic is closed to new replies.

Advertisement