Sign in to follow this  
spek

Shadowmaps: Point lights / perspective. Which techniques?

Recommended Posts

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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
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&part=series&WantType=Proceedings&title=I3D

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by wolf
From a practical point of view there is no real advantage in Dual-Paraboloid shadow maps


I'm of two minds about this. In my own experience I found cubemaps to be more intuitive and robust.

However there are some questions I can't really answer...what is better for hardware: 2 tex2dProj calls to sample the DPSMs or a single but more complex texCUBE call for the cubemap...

THe main problem with cubemaps I think is clearing and switching to six surfaces...certainly less efficient than 2 surfaces...especially when we are using floating point surfaces. Poeple are talking about cases when that can be reduced to fewer faces, but this is hardly a reliable reduction...when the light is viewed from any distance at all all 6 sides will need to be updated, and I would argue this is more common than not.

John Carmack of ID seems to recommend against cubemaps for another reason: you cant use different sizes for faces independently at the same time. But i have a hard time believing 6 tex2DProj calls can be efficient so i'm not sure I understand him..maybe he believes that using the smaller size for certain faces is a big win that trumps all the texture samples.. I dont know.

The interesting thing about shadow mapping is how wide open the method is.. there is no "right solution" yet as far as i can see.

Share this post


Link to post
Share on other sites
Quote:
It shipped on both PS3 and 360, with 4 shadowing point lights supported.
Very impressive.

Here is another thought: what you can do as well is trying to get away with 2D shadows :-) ... just tweak your lights to be "spotlights".

Share this post


Link to post
Share on other sites
Quote:
Original post by osmanb
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.

Yeah it's true that rendering to 6 faces at once is a theoretical win for cube maps on DX10, although in some initial benchmarking that I did rendering the faces separately with some course CPU frustum culling was still faster than the GS-cloning approach. Instancing is another interesting approach that's a bit more hardware-friendly than GS-cloning, and GS-binning is theoretically efficient for this sort of discrete frustum rendering. That said, GS implementations leave a lot to be desired on current hardware (especially G80), particularly when amplification/deamplification is used. Since rendering shadow maps is pretty simple and batch-friendly, throwing all of the geometry at the GPU might end up being the most reasonable in the long run, depending on the CPU setup cost of course.

Certainly there are a few variables to play around with... I'd still say try cube maps first and if they are too slow (particularly on the CPU side), etc. try DP maps.

Share this post


Link to post
Share on other sites
Everybody; thanks!

It seems was at the right place with cascaded/split shadowMaps (but what's the difference between those two). Anyone some nice papers or demo's (I don't have the GPU Gems book(s), should have asked Santaclaus for it :) ) ?


Point lights seem to be a bigger challenge. I'm not very keen on fragmentating the whole scene into small polygons (and still have 'depth errors'). I was hoping though that there was another solution besides cubemaps. But ok, I think I'll go for that one.


The reason I was questioning cubeMaps is the performance of course. Nowadays more and more games are using shadowMaps (Crysis, Bioshock as well I believe). Maybe I'm totally wrong (since Osmanb is specifically talking about 4 point lights on quite powerfull hardware), but I thought point lights are pretty much used in these games. Although I might be wrong. Maybe only a small amount of lights is actually casting shadows...

About rendering a cubemap in 1 pass, is that possible in OpenGL as well? I guess this has something to do with geometry shaders. I never used them so far, only took a brief look at them. I didn't quite understand the difference between Vertex shaders and geometry shaders, or better said, when/where to use them.


Thanks again for your critical views on the techniques!
Rick

Share this post


Link to post
Share on other sites
Although many games have some kind of shadows, if you look at the majority of games (even the big names that get credit for their graphics), they generally have VERY simple shadows. Dozens of games from the last two years that have been repeated praised for their amazing graphics feature one of the following:

- Static lighting with pre-baked lightmaps.
- At most one shadowing dynamic light-source, usually a directional light
- Projected texture shadows! (Lost Odyssey, I'm looking at you! That game doesn't even correctly cull shadows from polygons that aren't facing the light. I was able to do that on PSP.)

In total, despite all the cool techniques that have been developed, and the significant horsepower out there, most people just punt on shadows. Of course, the real message might be that it's not worth spending much programmer (or CPU/GPU) time implementing advanced shadows, when no one seems to notice or care.

Share this post


Link to post
Share on other sites
I see. To be honest, I never really noticed the lack of correct lights/shadows either, unless I really checked every pixel :)

Ow, I see cascaded and splitted shadowmaps is the same thing. I'll try the nVidia OpenGL SDK demo this week. That technique seems to be "a lot" slower as well than a default shadowMap. But yet again, there won't be that much "big range" lights either. The sun is a good example of course, although it will probably be used more for large light beacons in a warehouse (or something like it) in my case.

It comes down to strategically configuring the lighting for each scene, and what the hardware allows of course. 2 point lights, 2 long range lights, a bunch of normal spotlights and fake lights. Something like that...

Allright then. Time to try this at home. Ow, and could someone explain how to render a cubemap in 1 pass? Like I said, it's probably something with geometry shaders. But I haven't start with them yet. I even doubt if Cg 1.5 (which I'm using now) is already supporting them...

Greetings,
Rick

Share this post


Link to post
Share on other sites
Quote:
Original post by spekOw, and could someone explain how to render a cubemap in 1 pass? Like I said, it's probably something with geometry shaders.

Check out the Direct3D 10 sample for single-pass cube map rendering. The technique is the same in OpenGL and indeed does use geometry shaders. In particular you need to be able to decide per-primitive which render target to write to.

Share this post


Link to post
Share on other sites
Quote:
Although many games have some kind of shadows, if you look at the majority of games (even the big names that get credit for their graphics), they generally have VERY simple shadows. Dozens of games from the last two years that have been repeated praised for their amazing graphics feature one of the following:

- Static lighting with pre-baked lightmaps.
- At most one shadowing dynamic light-source, usually a directional light
- Projected texture shadows! (Lost Odyssey, I'm looking at you! That game doesn't even correctly cull shadows from polygons that aren't facing the light. I was able to do that on PSP.)

gears of war is a perfect example, many ppl praised it for the graphics, personally i thought it was a step backwards/sideways from older games WRT shadowing/shading.
Q/ why did ppl think looked good?
A/ im betting cause of the exaggerated normalmaps with specular + DOF/motion

Quote:
In total, despite all the cool techniques that have been developed, and the significant horsepower out there, most people just punt on shadows. Of course, the real message might be that it's not worth spending much programmer (or CPU/GPU) time implementing advanced shadows, when no one seems to notice or care.
so true thats why ive sort of given up on going for the perfect result with lighting + just stick something approx in 99% of the ppl cant tell the difference. 10x halfassed pointlights (with shadows) is better than 1 nice pointlight with shadows, things have gotta be inyourface for the populace to notice

Share this post


Link to post
Share on other sites
Quote:
Original post by osmanb
In total, despite all the cool techniques that have been developed, and the significant horsepower out there, most people just punt on shadows. Of course, the real message might be that it's not worth spending much programmer (or CPU/GPU) time implementing advanced shadows, when no one seems to notice or care.


It does seem to happen quite a bit. Even in a game like Crysis I've come across scenes (especially with point lights) where the shadows show some nasty artifacts. I've also never really been a fan of the way they randomly jitter the shadow map samples.

However on the other hand, Uncharted for the PS3 has probably the most impressive shadow map implementation I've ever seen in a game. They must be "faking" a good portion of it, but the end result sure is nice!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this