Jump to content

  • Log In with Google      Sign In   
  • Create Account


Standard approach to shadow mapping multiple light sources?

  • You cannot reply to this topic
6 replies to this topic

#1 Husbjörn   Members   -  Reputation: 185

Like
0Likes
Like

Posted 14 June 2014 - 10:04 AM

So I've been contemplating this lately, is there any standard approach to how to (efficiently) handle dynamic shadow mapping of multiple light sources?

As I've understood it the common advice is to just render separate depth maps for each visible light in the scene and then let the scene shader(s) iterate over all of those. However this just sounds like it would get extremely wasteful with relatively few lights.

Assume for example that I have a moderately complex scene lit by three point lights; this translates into having to render the scene 18 times just to generate the depth maps and then those maps have to be stored in memory as well (assuming 2048x2048x16 maps that alone will use 144Mb VRAM, I suppose that isn't overly much, but it still adds up with further lights).

Another big issue is that this approach would quickly eat up texture slots for the actual scene shader (I suppose you could put multiple shadow maps into a texture atlas but that has its problems as well).

I'd just imagine there should be a way to somehow combine shadow calculations, or is it really all about the art of cheating (ie. only make the x most significant lights in the current frame actually cast shadows)?

 

If anybody would like to share some information, thoughts or links to papers or similar on this subject it would be greatly appreciated smile.png


Edited by Husbjörn, 14 June 2014 - 10:06 AM.


Sponsor:

#2 mhagain   Crossbones+   -  Reputation: 7431

Like
0Likes
Like

Posted 14 June 2014 - 12:46 PM

Use a cube map and a geometry shader and you don't need to render the scene 6 times per light; it goes back down to once per light.

 

Also consider using smaller shadow textures for lower intensity lights.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#3 MJP   Moderators   -  Reputation: 10226

Like
4Likes
Like

Posted 14 June 2014 - 12:49 PM

Point lights are tricky, for the reasons you mentioned: using 6 depth maps per point light will consume a lot of memory and performance, so it doesn't scale up very well. For this reason most games don't support very many point light shadows simultaneously, or even at all. And if they do, they most likely stick to a resolution lower than 2K in order to save on memory and performance. The game that I work on uses a texture array of 16 shadow maps for point and spotlight shadows, so we would only support 2 point lights max (although in practice we avoid that case since we get a larger visual impact by reserving the shadow maps for additional spot light shadows). In light of all of this, it probably makes sense to give some deep thought as to whether the design of your game really needs multiple point light shadows. If it does, then here are some things you can consider:

 

  1. Definitely "cheat" if you can with regards to carefully choosing which lights cast shadows. We do this all over the place. Artists choose which lights cast shadows, and also author distances at which shadows fade out. We also apply frustum culling (which you should of course do as well) to only render shadows that are within the camera's frustum, as well as apply pre-baked visibility culling. Our visibility system basically goes through our levels at certain points, and determines which meshes would be visibility to the camera and aren't blocked by other meshes. Then we also do the same for static lights, and also determine which meshes actually need to cast shadows for that light (skipping meshes that are completely occluded by the shadow of other meshes). 
  2. Depending on your game, you may be able to cache shadow maps so that you don't need to regenerate them every frame. The easy case would be a static light that's only casting shadows from static geo: you can generate that shadow map once, and keep using it until the light isn't visible or something dynamic moves through it.This doesn't help on memory, but definitely helps on performance. Even if there is a dynamic object moving through the light, you may be able to still only update that shadow map every N frames as long as the light is fairly far from the camera. You can also look into more complex variants of this basic idea, such as the one presented in this paper: http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=clustered_with_shadows
  3. You can try looking into Dual Paraboloid Shadow Mapping as an alternative to cube maps for point light shadows. Dual paraboloid mapping lets you use only 2 maps instead of 6 since each map effectively covers a hemisphere. However the projection it uses is non-linear, so linear rasterization causes errors to occur. These errors may not be noticable if your geometry highly tessellated, so it depends on your game.
  4. If you really want to get crazy, you can look into ray-tracing in the pixel shader or better yet cone-tracing through a voxel grid. These approaches remove the need for a shadow map entirely which can help for scaling up to arbitrary numbers of lights, but of course come with their own complications.

Edited by MJP, 15 June 2014 - 12:55 PM.


#4 MJP   Moderators   -  Reputation: 10226

Like
0Likes
Like

Posted 14 June 2014 - 12:50 PM

Use a cube map and a geometry shader and you don't need to render the scene 6 times per light; it goes back down to once per light.

 

 

This is true, but it comes with a significant GPU cost.



#5 Husbjörn   Members   -  Reputation: 185

Like
0Likes
Like

Posted 15 June 2014 - 09:23 AM


Use a cube map

Admittedly I'm not all too familiar with cube maps but won't they essentially render as 6 separate maps anyway?

 

 

@MJP: Thanks for the insight.

My planned game probably won't "require" that many lights, I'm basically just planning ahead and trying to come up with the most flexible solution to start with so as to not have to rewrite too large portions should it turn out I need an extra light or four somewhere along the way. Frustum culling the lights makes sense and I've heard of faking point light shadows by actually generating shadows for an imaginary spot light pointing at the most lit area of said point light (such as straight down on the ground).

As for pre-generating static lighting on static meshes, won't that by definition fail and you'll have to regenerate the whole thing the minute any dynamic objects enter the shadowed zone however? I suppose it would still work for distant / unreachable areas though (although I'm planning a mostly outdoors game that would require dynamic directional sun / moon lighting anyway so I guess this isn't too applicable at my particular situation unfortunately. Good to know for later endeavours though.).

Also thanks for the links, will read through them during the upcoming rainy vacation days! That dual paraboloid shadow mapping seems like it could be quite useable at a first glance smile.png

 

Edit: forgot to mention it but I was under the impression that you could at most have up to 16 textures bound to the graphics pipeline for any single draw call. It would however seem I was dead wrong as MSDN suggests the number to be 128 for shader model 4 (however no such number is given for SM5). That at least gives some more headroom to work with, even though it will of course be limited by other factors instead in the end then.


Edited by Husbjörn, 15 June 2014 - 09:27 AM.


#6 Jason Z   Crossbones+   -  Reputation: 4690

Like
0Likes
Like

Posted 16 June 2014 - 07:42 PM


Use a cube map and a geometry shader and you don't need to render the scene 6 times per light; it goes back down to once per light.

That reduces the number of draw calls, but still requires rasterizing of the scene 6 times (once for each 2D surface) so the primary cost is still present.



#7 Dawoodoz   Members   -  Reputation: 290

Like
0Likes
Like

Posted 19 June 2014 - 06:54 AM

I use subsivision of a square atlas for multiple depth maps to use the same texture slot. By removing all allocations in the atlas each render of the world, there will be no more than 3 unused squares per size after allocating a new square and a fixed size array can be used to store them.

 

https://code.google.com/p/david-piuvas-graphics-engine/source/browse/trunk/Engine/QuadAllocator.cpp


My open source DirectX 10/11 graphics engine. https://sites.google.com/site/dawoodoz

"My design pattern is the simplest to understand. Everyone else is just too stupid to understand it."






PARTNERS