Not logged in, Join Here! or Log In Below:  
News Articles Search    

 Home / 3D Theory & Graphics / Shadow Volumes - flickering Account Manager
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

April 27, 2005, 06:32 AM

Based on NVIDIAs paper i've implemented shadow volumes. When i compare it with
shadow mapping (same scene, same geometry), bot shadows cover excatly the same
area. I haven't any problem when the camera is inside the shadow volume, too.

But whenever there are larger triangles which are in an exact line to the light,
this triangle does flicker (camera position dependant).

Have tried different DepthFunc settings. With a large PolygonOffset the effect
disappears (but i'm not aware of any example that uses PolygonOffset).

Is there anyone with similar problems or am I a poor programmer?


April 27, 2005, 07:40 AM

Some code would help please! :p


April 27, 2005, 05:17 PM

Have in mind that if a triangle is aligned to the light, the normal dot lightdir will oscilate sign beeing 0 and will confuse de shadow volume, visibility determination, siluete ... use an epsilong for discriminate the dot product to get plus or more than epsilon visible, less than epsilong not.
Other solution could be polygon offset, to displace the z value when you proyect the shadow volume.


April 28, 2005, 02:14 AM

Have tried such a large epsilon that the whole volume get messed up, but the flickering parts don't disappear. As I've written, with e.g. glPolygonOffset(0, 128) the artifacts disappear.

e.g. NVIDIAs infinity shadow volume example don't use polygon offset and when I carefully look at the model I can't detect any flickering polygon.

If other people use a polygon offset too, I'm happy, if not, I've to crawl trough my code.

(if one really likes to see the xth shadow volume demo i post it when I've fixed all flaws. Currently the source looks a bit odd.)


April 28, 2005, 05:42 AM

About polygon offset, I have to use it and the flickering problem disapears for me, but anyway I also have problems with some ATI 9600 / 9800 cards, the polygon offset situable values were diferents.


April 28, 2005, 03:32 PM

PolygonOffset shouldn't be needed, I've never had any problem. But, flickering occurs when you draw the shadow volume caps and the model with different primitives (triangles, triangles strips).


April 29, 2005, 07:35 AM

Not really, I use the same primitive, but on some situations the flickering appears, so I decide to use it.


May 01, 2005, 01:46 PM

I use the same primitives, too.
One thing I was wondering in the NVIDIA sample that there is a commented glPolygonOffset. Maybe they had the same problem and solved it somehow (special designed model, ...). Perhaps I've to analyze the whole sample.


May 02, 2005, 01:02 AM

Okay... are you guys using shaders to shade the model? If you do, use the position invariant option (ftransform() in GLSL; OPTION ARB_position_invariant in ARB_vertex_program).


May 02, 2005, 05:18 AM

No. Old school fixed function path.

Erik Faye-Lund

May 02, 2005, 05:22 AM

i think the general solution is to inset-the non-extruded vertices a tad. this flickering IS a known problem. polygon offset will also most likely do the trick.


May 02, 2005, 03:39 PM

Do you guys use the light-facing faces of the shadow caster as the front cap for the shadow volume? If so, you might want to try using the faces that are back-facing with respect to the light, instead. These faces ought to be in shadow anyway, so the flickering shouldn't be visible.


May 20, 2005, 03:53 PM

What you're seeing is just plain old z-fighting between your shadow volume and your surface. You have a shadow volume extruding from your geometry on the same plane as the geometry casting the shadow. The polygon offset helps avoid this, but I don't think that is the right solution. I think the right solution is to evaluate how you're handling lighting.

For diffuse light, you have: dot( Normal, Light ). At that high of an angle, you should get approximately zero (dot of 90 degrees...). However, this will still be a problem if you have a normal that varies across the surface of the triangle causing the fighting.

For specular light, things get tricky. I'd suggest turning off specularity (if you have it on) to see if that is what is the most noticable. In this case, you can have a vector pointing to the light that is tangent to the surface being rendered, yet specular highlights are still very visible, even though they shouldn't be. For instance, you can have a light that is 90 degrees off of the normal of a surface, and a view that is directly along the normal of the surface, and get sqrt(2)^2 from dot( Half, Normal ), where Half = ( View + Light ) * 0.5. This case is physically wrong as the pixel is still illuminated even though it shouldn't be. In this case, throwing shadows in the mix yields some nasty results, and polygon offset may be your only real choice.

If you're using shaders, you can do some simple things to make specular both more physically accurate, as well as more friendly for shadows. I'll touch that in another post if it's desired. If you can do this, then the z-fighting issue becomes moot.

Also, depending on how you have your system set up, you may want to have the ability to turn off self shadowing for some objects. I think you'll also find having the ability to turn off casting shadows for given lights and casting shadows for given objects to be very useful (as you can add little lights to the environment without the penalty of shadows for instance).

If none of the above options are available to you, then you should:

1) Be careful when placing lights.
2) Be careful when using specularity.
3) Be careful when placing objects containing specularity.
4) Use polygon offset where needed, but be aware, this may not behave the same from card to card, and the problems may still show up in some cases that are more awkward to find and deal with.

Sorry I can't provide a better solution for fixed function, but I hope the above info helps!


Erik Faye-Lund

May 23, 2005, 06:05 AM

ah, yes Reedbeta. I guess that's the best solution. It's what we did at work IIRC.

This thread contains 14 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.