Shadowmaps: Point lights / perspective. Which techniques?
Author
Hi,
I'm using variance shadowMaps for spotlights for a while now. Works fine, but it's time to extend the code with some new techniques:
- Long range shadowMaps -> 'Perspective Correct'(for the sun)
- ShadowMaps for pointlights
I've heard about cascaded shadowMaps, splitted shadowMaps, and so on. What would be a nice realtime solution for long range (spot)lights? The quality doesn't have to be superb, but it still needs to have the soft edges/blur like VSM. For example, what kind of technique does Crysis use to generate shadows from the sun?
As for the pointlights, as far as I can think you could use a cubeMap, or dual paraboloid shadowmaps. The first one would require to render the depth six times (when the map should be updated)... Dual paraboloid only 2 if I understand it well, BUT, the world needs to have a high tesselation, right? Again, what's a popular technique used for point lights?
Greetings,
Rick
Quote:Original post by spek
I've heard about cascaded shadowMaps, splitted shadowMaps, and so on. What would be a nice realtime solution for long range (spot)lights? The quality doesn't have to be superb, but it still needs to have the soft edges/blur like VSM.
Definitely cascaded/parallel-split shadow maps are a high-quality solution that is easy to code up. They can be used in conjunction with variance shadow maps, PCF or any other shadow filtering technique so you can still achieve correct filtering and soft edges. Check out the source code to the Ch8 demo in GPU Gems 3 for an implementation of Parallel-Split Variance Shadow Maps.
Quote:Original post by spek
As for the pointlights, as far as I can think you could use a cubeMap, or dual paraboloid shadowmaps. The first one would require to render the depth six times (when the map should be updated)... Dual paraboloid only 2 if I understand it well, BUT, the world needs to have a high tesselation, right?
That's entirely correct. If your scene is tesselated enough (or you have tesselation hardware), DP maps are pretty reasonable and have been used to good effect in the past. Also blurring them gives a more "correct" filter than blurring cube map faces. However if you don't want to worry about tesselation and such, cube maps do work pretty well too, although they are more expensive to render as you note. Cube maps are a bit tougher to apply PCF to, but VSMs work naturally with hardware trilinear/aniso filtering so no additional effort is needed.
You can combine VSM with cascading/parallel-split shadow maps.
Beaten to it by Andy, who of course could answer a question regarding shadows (especially vsm) better than I.
As far as the perspective of a camera for the sun, the sun's rays are almost parallel, so an orthographic projection is usually used to represent shadows from the sun.
Beaten to it by Andy, who of course could answer a question regarding shadows (especially vsm) better than I.
As far as the perspective of a camera for the sun, the sun's rays are almost parallel, so an orthographic projection is usually used to represent shadows from the sun.
This is probably obvious but worth mentioning...if you work with cube maps you'll want to cull as agressively as possible. This especially applies to the cube map faces: determine the 3D volume that represents the area visible to each cube map face (it will be frustum-shaped), and if it's outside the main view frustum than don't render to it. After that of course you can use regular frustum-culling techniques to determine which objects need to be rendered to that face.
That's actually a very good point for practical cube shadow map implementations: if the light is offscreen you can always align your cube map faces so that you need at most 5 (one will be parallel and pointed away from the nearest frustum face). There are other cases in which your "cube map" reduces to only a few or even only a single face (if that face frustum covers the whole view frustum). Definitely detect and align your shadow cube map as aggressively as possible to take advantage of these common scenarios.
If you do decide to use dual-paraboloid shadow maps, then I'll suggest that you look at 'Practical Implementation of Dual Paraboloid Shadow Maps', which covers a few tricks and details to help with the tesselation requirements, especially on receivers. By using one very simple technique, the need for tesselation of receivers is completely removed.
http://portal.acm.org/citation.cfm?id=1183331
If you don't have access to the ACM DL, send me a PM, and I can e-mail you a copy of the paper. There was also a paper at I3D this year about computing polygons that can correctly bound the paraboloid projection of a triangle during rasterization, so that you can (it seems) also remove the need to tesselate casters. I haven't read the paper in depth yet, nor have we implemented the technique, but we're still using DPSM for all of our point-light shadowing.
Edit: URL for I3D paper...
http://portal.acm.org/citation.cfm?id=1342250.1342267&coll=GUIDE&dl=&type=series&idx=SERIES749∂=series&WantType=Proceedings&title=I3D
http://portal.acm.org/citation.cfm?id=1183331
If you don't have access to the ACM DL, send me a PM, and I can e-mail you a copy of the paper. There was also a paper at I3D this year about computing polygons that can correctly bound the paraboloid projection of a triangle during rasterization, so that you can (it seems) also remove the need to tesselate casters. I haven't read the paper in depth yet, nor have we implemented the technique, but we're still using DPSM for all of our point-light shadowing.
Edit: URL for I3D paper...
http://portal.acm.org/citation.cfm?id=1342250.1342267&coll=GUIDE&dl=&type=series&idx=SERIES749∂=series&WantType=Proceedings&title=I3D
Quote:Original post by osmanb
By using one very simple technique, the need for tesselation of receivers is completely removed.
I'm not convinced that technique is compatible with variance shadow maps, which require both casters and receivers to be represented in the shadow map, hence exposing the same linear rasterization problems that dual paraboloid maps are generally prone to.
Quote:Original post by osmanb
There was also a paper at I3D this year about computing polygons that can correctly bound the paraboloid projection of a triangle during rasterization, so that you can (it seems) also remove the need to tesselate casters.
Yeah the I3D paper was an interesting way to effectively do the non-linear rasterization manually. This is certain an option, although there will of course be some overhead for rasterizing the extra fragments that linearly bound the poly-"curves" in DP space.
From a practical point of view there is no real advantage in Dual-Paraboloid shadow maps ... well ok the fact that they might consume less memory but even this is not necessarily true. What you gain by reducing the number of rendering pathes is what you loose while doing alpha testing or texkills in the pixel shader. I admit I never really measured the performance compared to cube shadow maps but the later are just a more powerful concept.
The obvious advantage of cube shadow maps is the lower error level. The other thing to consider is that you not always need to update all six directions. In many cases five directions will be enough and you might get away with four or less if you tweak the projection a bit.
If you look at it from this perspective, cube shadow maps are quite flexible.
If you add Andy's VSM approach or any other probability based approach you can reach a really good quality level with quite small maps (e.g. 256x256). To get any comparable quality you need bigger maps for dual-paraboloid shadow maps.
... so the only thing that really speaks in favour of DPSM is the lower memory consumption. This is a tough argument in the console world and as long as you can not store less than the six faces of a cube shadow map maybe even a deal breaker :-)
The obvious advantage of cube shadow maps is the lower error level. The other thing to consider is that you not always need to update all six directions. In many cases five directions will be enough and you might get away with four or less if you tweak the projection a bit.
If you look at it from this perspective, cube shadow maps are quite flexible.
If you add Andy's VSM approach or any other probability based approach you can reach a really good quality level with quite small maps (e.g. 256x256). To get any comparable quality you need bigger maps for dual-paraboloid shadow maps.
... so the only thing that really speaks in favour of DPSM is the lower memory consumption. This is a tough argument in the console world and as long as you can not store less than the six faces of a cube shadow map maybe even a deal breaker :-)
I tend to agree with wolf in that the non-linear rasterization required by DP maps is a bit of a deal-breaker in most cases. Cube maps just work a lot more naturally with the hardware that we currently have. In a theoretical sense doing box-shaped filters on a DP map is "more correct" than a cube map (i.e. better approx to the solid angle), but for shadows you'll rarely ever notice the problem.
Thus I'd pursue cube shadow maps first and only really look at DP maps if you end up doing something like instant radiosity - in which the memory consumption will really kill you - or if you run into a particular problem with the cube maps.
Thus I'd pursue cube shadow maps first and only really look at DP maps if you end up doing something like instant radiosity - in which the memory consumption will really kill you - or if you run into a particular problem with the cube maps.
I agree that DPSM is certainly more complex (and tricky) than using cubemaps. I do think they're an overall performance win, though, depending on your scene construction and other factors. Our original use case was a top-down style dungeon crawler. The game used lots of point lights, and we wanted full scene shadowing. It shipped on both PS3 and 360, with 4 shadowing point lights supported.
The amount of rendering setup and actual draw time for all of the necessary cubemaps seems like it would have been prohibitive (in addition to the memory cost).
Since then we've got VSM working with our DPSM implementation, and it looks great. We still aren't using the clever rasterisation techniques, as our camera and lighting generally lets us get away with geometry that's only as tesselated as it would be for a current-gen game anyway.
Of course, if I was targeting DX10, I'd almost certainly be using cubemaps, given the ability to render all six faces in one pass, and even on DX9 (for PC), the simpler logic and consistent density of shadow texels would be a good argument for that route.
The amount of rendering setup and actual draw time for all of the necessary cubemaps seems like it would have been prohibitive (in addition to the memory cost).
Since then we've got VSM working with our DPSM implementation, and it looks great. We still aren't using the clever rasterisation techniques, as our camera and lighting generally lets us get away with geometry that's only as tesselated as it would be for a current-gen game anyway.
Of course, if I was targeting DX10, I'd almost certainly be using cubemaps, given the ability to render all six faces in one pass, and even on DX9 (for PC), the simpler logic and consistent density of shadow texels would be a good argument for that route.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
