Shadow volume problems

I’m having troubles implementing the zPass algorithm for shadow volume rendering (I haven’t tried the zPass method yet).
The problem comes where two shadow volumes of different occluders overlap. It looks something like this:

             °L

       ------
      /      \
     /     -------
    /     /***\   \
   /     /*****\   \

0000011111110000000111100000000

Where L is the light source.
\ and / show the shadow volume.

  • is the overlapping shadow volume and
    the 1s and 0s represent the value in the stencil buffer.

As you see the overlapping area of the two shadow volumes in the middle become unshadowed because of the zero value in the stencil shadow.
The shadows look completely ok if there are no overlapping shadow casters and the camera is not inside the shadow volume, of course.
I’ve searched the web for this and had a look at various samples but I just can’t find where the problem is. My triangle edges also seem to be correct. Maybe there is some special winding or something else I’ve missed.

I hope someone of you guys will bring me on the right track again

So thanks for your help. I’ll post some code here if this will be neccessary

Originally posted by Jens Scheddin:
[b]I’m having troubles implementing the zPass algorithm for shadow volume rendering (I haven’t tried the zPass method yet).
The problem comes where two shadow volumes of different occluders overlap. It looks something like this:

[quote]

             °L

       ------
      /      \
     /     -------
    /     /***\   \
   /     /*****\   \

0000011111110000000111100000000

Where L is the light source.
\ and / show the shadow volume.

  • is the overlapping shadow volume and
    the 1s and 0s represent the value in the stencil buffer.

As you see the overlapping area of the two shadow volumes in the middle become unshadowed because of the zero value in the stencil shadow.
The shadows look completely ok if there are no overlapping shadow casters and the camera is not inside the shadow volume, of course.
I’ve searched the web for this and had a look at various samples but I just can’t find where the problem is. My triangle edges also seem to be correct. Maybe there is some special winding or something else I’ve missed.

I hope someone of you guys will bring me on the right track again

So thanks for your help. I’ll post some code here if this will be neccessary[/b][/QUOTE]

Use increment (for frontfaces) and decrement (for backfaces) instead of inverting one stencil bit.
Then you get 2 at that area…

That’s exactly what I’m doing:

vxglCullFace(GL_BACK);
vxglStencilOp(GL_KEEP, GL_KEEP, GL_INCR_WRAP_EXT);
vxglVertexPointer(4, GL_FLOAT, 0, light->m_shadowVolumes.m_volumeVertices);
vxglDrawElements(
GL_QUADS,
light->m_shadowVolumes.m_numVolumeElements,
GL_UNSIGNED_INT,
light->m_shadowVolumes.m_volumeElements);

vxglCullFace(GL_FRONT);
vxglStencilOp(GL_KEEP, GL_KEEP, GL_DECR_WRAP_EXT);
vxglVertexPointer(4, GL_FLOAT, 0, light->m_shadowVolumes.m_volumeVertices);
vxglDrawElements(
GL_QUADS,
light->m_shadowVolumes.m_numVolumeElements,
GL_UNSIGNED_INT,
light->m_shadowVolumes.m_volumeElements);
vxglCullFace(GL_BACK);

There must be some stupid stupid error somewhere else…

check out your stencil write mask,
it might be 1, but you want 0xff(…)ff
(~0)
cb
“Live and learn (or die trying!)”

check out your stencil write mask,
it might be 1, but you want 0xff(…)ff
(~0)
cb
“Live and learn (or die trying!)”

During stencil buffer writes stencilFunc looks like this:
vxglStencilFunc(GL_ALWAYS, 0, ~0);
For the lighting path it’s:
vxglStencilFunc(GL_EQUAL, 0, ~0); and
vxglStencilOp(GL_KEEP, GL_KEEP, GL_KEEP);

I think I have set up OpenGL for stencil shadows correctly.

Is there any special winding for the vertices of my triangle edges? May this cause the problem I experience?

I also noted that when using GL_INCR and GL_DECR instead of GL_INCR_WRAP_EXT and GL_DECR_WRAP_EXT I don’t see any shadows at all. But this may be because of the rendering order of the triangles of my scene.

Yes, the winding order is very important so that your front-facing shadow volume faces are always wound counterclockwise. See the discussion in my article on Gamasutra:

Mechanics of Robust Stencil Shadows

In particular, see the sections on silhouette determination and shadow volume construction.

– Eric Lengyel

[This message has been edited by Eric Lengyel (edited 09-29-2003).]

Yes, the winding order is very important so that your front-facing shadow volume faces are always wound counterclockwise. See the discussion in my article on Gamasutra:
Mechanics of Robust Stencil Shadows

In particular, see the sections on silhouette determination and shadow volume construction.

– Eric Lengyel

Thanks for that tip. My shadow volume face normals now point out of the shadow volume. But this doesn’t solve the problem. It’s still the same result. If I render the shadow volumes to the color buffer everything looks as it should. So there must be something wrong with my gl states, I think. Any clue?

See Table 1 in the article. You need to make sure that your extruded shadow volume faces are consistently wound.

They do have a consistent winding. When I render only the front or the back faces into the color buffer then everything looks ok: Backward facing faces of the shadow volume are only visible when culling is set to GL_FRONT and vice versa.

Another thing I forgot to mention is that my geometry is not closed. Means that my test scene has two quads which cast shadows to each other and a wall. But this should not be a problem since I only extrude the four outer edges of each quad.

[This message has been edited by Jens Scheddin (edited 09-30-2003).]

A few days more of testing made me almost go nuts on this problem.
I can now definitely say that my shadow volume is absolutely correct. The winding, rendering order, extrusion, …
I also realized that when inverting the stencil buffer when drawing fron and back facing quads of the shadow volume leads to EXACTLY the same result as with INCR_WRAP on frontfaces and DECR_WRAP on backfaces. GL_INCR and GL_DECR on the other side removes the shadows in and behind the overlapping shadow volume (the one marked with * in the ASCII art on the top of this topic).
Has somebody experienced something like this before and/or can explain how this could be happening?

It’s difficult to help on a problem like this without more details. There are lots of little things that can get messed up when rendering SSVs.