Advertisement Jump to content
Sign in to follow this  
myers

Shadow map flickering when lights move

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

One of the problems of shadow maps which receives little attention (as far as I can see) is that their limited resolution is particularly troublesome when a light is in motion, and that perspective-warping approaches to maximising resolution actually exacerbate this.

It's not worth worrying about when lights move quickly, but slow, subtle movements cause very noticeable flickering at shadow edges even when the texel-pixel ratio is fairly high. The cause of this is obvious, but I'm having trouble finding any suggestions for remedying it. I expected that it would be a problem, but didn't notice how bad it looked until I implemented a dynamic time-of-day system. Because the sun moves across the sky at a rate of a fraction of a degree per frame, the shadow edges swim constantly.

I've tried two ways of mitigating this. One is to move the sun in greater, less frequent increments. This looks slightly better, arguably, as there is no incessant swimming, but this is replaced by dramatic "jumps" when the light does move which are even more noticeable.

The other approach I tried was having two shadow maps, with the light at slightly different positions for each, and blending between them. As expected, this pretty much eliminates the whole visual problem, but at the cost of a doubling of memory usage, rendering passes, and lookups. Accumulating both passes onto a single buffer would obviously reduce these overheads, but I don't see how that's possible.

This must be a fairly common problem, as it will arise in any situation involving a slow-moving light - any system that moves a shadow-casting sun in real time (or even 10x, 20x, 30x real time) will be faced with it. Is there a less expensive way of addressing it than my solution?

Share this post


Link to post
Share on other sites
Advertisement
Which shadow mapping technique are you using?

For large outdoor scenes, PSSM (Parallel-Split Shadow Map) is recommended. Assassin's Creed II combines it with VSM (Variance Shadow maps) to hide even further the subtle (but annoying) flickering of day-night cycles.

IIRC, Burnout Paradise uses VSM too to hide day-night cycle flickering.

So... which technique are you using?
Cheers
Dark Sylinc

Share this post


Link to post
Share on other sites
Another technique that is better than the Variance Shadow Map (VSM), is Exponential Shadow Map (ESM). ESM's are about 10% faster, use half the storage of VSM's and light bleeding for the most part is eliminated.

Read up on which ever though. VSM's have lots of examples, to learn from. There are no examples to learn ESM's from, but VSM's and ESM's are so similiar, a change from one to the other literally, takes about 10 lines of code to change.

Too many acronyms . . .

Share this post


Link to post
Share on other sites
With games becoming more and more dynamic, there is pretty much nothing that you can do except increase resolution and filtering.

Before when everything was static you could use Stable Cascaded Shadow Maps: pixel centers are aligned in every frame and shadow map segments ware not rotated. Problem with this is low shadow map utilization, but it is was worth it because there was no flickering.

But now, when we have a lot of vegetation that even slightly moves this becomes useless. Example games are Crysis and Sniper Ghost warrior (they use Stable CSM even though they have dynamic vegetation - which is not very smart because "Stable" doesn't work in this case). In new Crysis, usage of Stable CSM is justified because there isn't much vegetation - it happens in the city where most of the geometry is static (step back if you ask me).

I recommend using new shadow mapping approaches such as CAMERA SPACE SHADOW MAPS that completely utilizes shadow map so you can have achieve better results with less work (only one pass and only one SM). There will still be flickering, but you can use much smaller shadow map and less filtering to achieve better results.

Share this post


Link to post
Share on other sites
Quote:
Original post by Matias Goldberg
Which shadow mapping technique are you using?

For large outdoor scenes, PSSM (Parallel-Split Shadow Map) is recommended. Assassin's Creed II combines it with VSM (Variance Shadow maps) to hide even further the subtle (but annoying) flickering of day-night cycles.

IIRC, Burnout Paradise uses VSM too to hide day-night cycle flickering.

So... which technique are you using?
Cheers
Dark Sylinc


CSM. At least, I think so - I'm a little unclear on the difference between CSM and PSSM. Basically, I split the light frustum in three and use a map per split.

I did initially also use VSM, but dropped it because it resulted in pretty bad light leaks and was actually slower than vanilla SM, even with PCF. I'll have a look at ESM, as smasherprog suggests. But I'm not sure how it would help with this problem: even if you use a large blur kernel, wouldn't that just "spread out" the flickering, rather than making it less noticeable?

Share this post


Link to post
Share on other sites
Quote:
Original post by myers
CSM. At least, I think so - I'm a little unclear on the difference between CSM and PSSM. Basically, I split the light frustum in three and use a map per split.

I assume you say CSM as in cascaded shadow maps (and not Convultion shadow maps)
PSSM is a type of CSM.
One key aspect is that PSSM bases the position of the each shadow camera scientifically (with a simple lerp that weights a linear with an exponential formula), where's other CSM implementations determine the cascades/split points empirically or with other formulas.

Quote:
Original post by myers
But I'm not sure how it would help with this problem: even if you use a large blur kernel, wouldn't that just "spread out" the flickering, rather than making it less noticeable?

Yes, it might, but you sure alleviate the problem (and sometimes a lot).
Imagine just two pixels, one black (shadowed) another white (lit). When you move the camera or the light, the two pixels shift their colours due to sampling problems (the white pixel becomes the black one and vice versa)
If you use filtering, both pixels will be grey. Furthermore if both are equally gray, even if they constantly switch places due to sampling imprecisions, they would still have the same colour aka. no flicker at all.

That was a simplified example, but on the big picture, errors and flickering get blended with correct pixels producing smoother results.
Of course very large kernels will introduce other problems, such as pixels that should be fully lit becoming slightly shadowed.

Cheers
Dark Sylinc

Share this post


Link to post
Share on other sites
Quote:
Original post by Matias Goldberg
Quote:
Original post by myers
But I'm not sure how it would help with this problem: even if you use a large blur kernel, wouldn't that just "spread out" the flickering, rather than making it less noticeable?

Yes, it might, but you sure alleviate the problem (and sometimes a lot).
Imagine just two pixels, one black (shadowed) another white (lit). When you move the camera or the light, the two pixels shift their colours due to sampling problems (the white pixel becomes the black one and vice versa)
If you use filtering, both pixels will be grey. Furthermore if both are equally gray, even if they constantly switch places due to sampling imprecisions, they would still have the same colour aka. no flicker at all.

That was a simplified example, but on the big picture, errors and flickering get blended with correct pixels producing smoother results.
Of course very large kernels will introduce other problems, such as pixels that should be fully lit becoming slightly shadowed.


Or (more glaringly, I think) pixels that should be shadowed becoming lit. I hope to get a chance to implement ESM this week and report back, but bad experiences have made me generally wary of covering up artifacts simply by increasing blur size.

If this is the standard approach, though, I'll certainly give it a try. Someone mentioned Crysis - I believe they use VSM, so I'll have to check that out and see how shadows cast by moving vegetation look.

Quote:
Original post by 2square
See the section "Moving the Light in Texel-Sized Increments" in Common Techniques to Improve Shadow Depth Maps

Hope this helps.


That discusses a slightly different issue, though, which is achieving stability with CSM when the camera moves, not the light.

Share this post


Link to post
Share on other sites
Reviving an old thread. I was hoping there would be some good answer in the end, but it doesn't look like it :-).

I just encountered this problem with my current project when I started having the day/night cycle change automatically. I'm going with roughly 24 minutes of real time per game time, and the shadows "swimming" as the sun moves is very noticeable.

I tried implementing the blending the O.P. mentioned. e.g. I update the light direction every 5 seconds and gradually fade the new shadows in. Obviously this comes at a pretty big performance cost, but I mitigate it somewhat by have a "band" that moves across the screen that is a fraction of the screen width. Only the region in there is undergoing blending, so I save a good amount of texture fetch bandwidth (I still have to render two shadow maps every frame though). The effect is a little strange though, and I'm not sure I'm satisfied with it.

Another option would be blending things in pixel by pixel or block by block using two passes and the stencil buffer. I'm not sure if that would look good though.

I looked at Fable 2 which has day/night cycles to see how it was done there. They have very soft penumbras, which I think helps a lot. Their shadows are also not very dark (lots of ambient light). And it looks like only some objects cast shadows. Notably people and vegetation, both of which are constantly moving - so that's another thing that helps. I walked around a bit but didn't see very many static objects casting shadows outside. Looking closely at some large tree trunks, you do see the shadows shimmer constantly as they move with respect to the sun. But it's fairly well hidden by the lack of sharp shadow definition.

Anyone have any other ideas? (please note, this is about artifacts when the light source moves, not the camera - a few posters seemed to be confused about that).

Share this post


Link to post
Share on other sites
As an FYI, I wrote up a summary of the things I tried and the results here:

http://mtnphil.wordpress.com/2011/10/31/shadow-maps-for-moving-light-sources/

The original poster mentioned reducing texture memory usage by rendering both "previous" and "current" shadow maps into the same texture. This is pretty straightforward if you adjust the color write channels when rendering (I describe what I did in the blog post above).

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!