shadow map question


is this normal aliasing with shadow maps ? I’m using SGIX_depth_texure, SGIX_shadow, pbuffer/render_texure/NV_render_depth_texture and not quite sure if this half shadowed stripes are normal.

Quite common. to minimize the effect, use a higher offset when rendering the shadowmap, and try to keep ambientlight as near zero as possible…

Yes it’s common, you could also try a higher resolution depth map, that will help with fewer side effects than the alternatives.

The issue is the lack of reconstruction filters in the depth map (which would break in other ways).

This looks like your front surfaces are aliasing with your shadow map.

You can get around this problem for most closed geometry (except very thin geometry) by rendering only back-facing triangles into the depth map, rather than front-facing triangles.

Let regular normal dot product decide local shading, and use the depth map for global shading.

There’s also a technique called “perspective shadow maps” which uses perspective texture projection to get more precision close to the camera, and less precision far away. Basically, it fits the frustum of the projected shadow map onto the unit cube of the viewing frustum in post-projection space. The paper makes for good reading!

Jwatte, if you understood that paper, maybe can you explain how point lights inside the frustum are handled? Do they benefit from post-perspective shadow mapping too ?


Nice suggestion jwatte (on the back faces). My only concern would be back face aliasing with the shadow map if there were any rear face contribution through ambient or interpolation. I’d heard of another algorithm which bisects the closest second closest depth values but it requires a dual zbuffer, your post is an interesting and much more practical variation on this.


The thing that annoys me with the backface trick are the artifacts that appear where two objects meet. Like a foot on the floor. Because it’s the backfaces’ depth that is in the map, often the shadow doesn’t quite meet the foot, which creates an illusion of objects floating in the air.

I get around this by first rendering backface depth and blending frontface depth on this. It eliminates precision problems vey well since the depths in the shadow map are somewhere ‘inside’ the objects. The cost is an additional pass when making the shadow maps, plus this might not be possible with depth textures (as opposed to storing depth in color).


the backface trick makes shadowing errors always on the shadowed site of the meshes. dunno about your floor problem… i don’t get it…if the foot is on the floor, how should you see the shadow?..

if you want, you can fill 2 depthbuffers, one frontfaces, one backfaces, and then take the average of both…

but that is twice the work (except when you render z manually as multiple outputs to a say float2 buffer…)

I get the foot problem. It’s aliasing, just reversed – you may get some pixel on the floor that’s right next to the foot, and the foot is between it and the light, yet that pixel is not in shadow. The fix for this is to use polygon offset the other way compared to regular front-face shadow buffers. Of course, that makes the problem with very thin geometry worse.

Regarding point lights inside the frustum, there just isn’t a good way to deal with point lights in the shadow map algorithm, except possibly if you can get cube map depth textures going.

It’s worth noting that, even though Doom III uses shadow volumes, it seems to rely on projected textures for lighting. If you do the same, it should be simple to use shadow buffers whose texture just mirror the projected light texture.

Last, you may note that shadow volume approaches also have aliasing problems, although their error is in the same space as regular geometry.

Having a better look on valoh’s picture, it seems the problem is more about your local lighting model than the shadows. These errors shouldn’t be visible if you would correctly put zero light on faces not facing the light. I can see you’re aiming for a certain visual result, but you might have to organize it a bit differently to make the shadows work well.

The negative offset with backfaces has it’s problems, but I guess you’re aware of them. It’s not just thin objects, in a sphere, for example, part of the frontfaces near the silhouette as seen from the light will get shadowed too.

For the omnidirectional case there is always the dual paraboloid thing, there’s currently a link on the front page if you haven’t seen that paper yet. Don’t know how well that can be actually used, it requires quite high (or adaptive) tesselation, so it’s not a thing you just plug into your engine. I wish they didn’t all suck, shadow algorithms you know…


Here’s a good link to a paper on rendering back faces into the shadow map called second depth shadow mapping that I posted in another thread recently.

thanks for the numerous answers.

higher resolution depth map didn’t solve the problem. for the image i used a 2048x2048 depth texture

only back faces for depth_texture: not better, using polygon offset i have the same aliasing problems and without incorrect self shadowing.

darker scene/lesser ambient: as soon as you use multiple lights, you’ll get the same problems. so, no solution for real life.

currently i’m converting my program to Cg to do some per pixel lighting. Next i’ll take a look at the perspective shadow maps and second depth mapping…

What kind of incorrect self-shadowing do you see with the second-depth approach? It should work fine unless your mesh has holes in it or something.

– Tom

Originally posted by Tom Nuydens:
[b]What kind of incorrect self-shadowing do you see with the second-depth approach? It should work fine unless your mesh has holes in it or something.

– Tom[/b]

the incorrect self-shadowing (less and smaller shadows) i got with positiv polygon offset. Yeah, i know, everything still a little hacked
negativ or zero polygon offset i had aliasing (again to high ambient), and that came from ambient lighting.

also with a second thought, i guess my point for the less ambient/darker scene is not correct. The only real problem is the ambient factor. multiple lights with low ambient shouldn’t be a problem.

so, before further guesses and incomplete tests i’ll get that per pixel Cg stuff done and finish the shadow mapping

Second-depth is a different technique, I believe. It requires two separate Z buffers to work, and writes the “second smallest” value into the second depth buffer. There is currently no hardware support for that.

Back-facing is still a first-depth algorithm (with hardware support) but gets rid of “surface acne” problems without imposing polygon offset.

I, too, wish they (the shadow algorithms) didn’t all suck :slight_smile:

I think you accumulate lighting wrong. How exactly you do it? It should be something like:

  1. Render all ambient first
  2. Add each light with it’s respective shadow map. No ambient here

If you want to add some kind of backlight to your lights, that’s fine, but don’t use shadow maps for those. You can draw all backlights/fill lights in the first pass without any shadows.


Actually, rendering back faces into the shadow map is suggested in the second depth paper as a fast way of implementing second depth shadow mapping in hardware. You can also do it with two depth buffers if you want to of course. If you think about it, as long as your objects are closed, rendering back faces is the same thing as rendering the second closest surface. They also do some extra sampling to avoid aliasing to avoid artifacts with thin objects IIRC, I’m unsure if you could do that in hardware. Probably with ARB_fragment_program you could, I don’t remeber the details.