View Full Version : Strange stencilled shadow error

01-17-2003, 03:41 AM
Ive got a nice stencilled shadow engine going, like everyone else. But ive noticed a problem that looks like some sort of depth fighting error but its more coarse.
You can see a picture here: http://www.radiant-software.com/ShadowError1.jpg

On the top barrel you can see the volume triangles themselves are visible for some reason. This is drawn using an original GeForce3.

The program uses vertex programs that arent position invariant (as a side point, can vertex_shader_ext be position invariant??) but the actual vertex location is always written first with 4 dp4's

Cheers, M.

01-17-2003, 05:24 AM
i know this problem. it appears only on a geforce3. it looks like a HW problem. on a gf/gf2/gf4 you'll not see any errors.

01-17-2003, 08:16 AM
I fixed this problem by using polygon offset on one side of the shadow volume polygons (either front facing or back facing).

01-17-2003, 11:54 AM
Originally posted by Coriolis:
I fixed this problem by using polygon offset on one side of the shadow volume polygons (either front facing or back facing).

I had a similar problem occuring in my shadows (in mine you could just see the edge of the shadow volume that led from the object to the actual shadow) when I was using polygon offset on the front faces of the shadow volume.

01-17-2003, 05:29 PM
ARB_vertex_program and NV_vertex_program1_1 (supported on all platforms that support NV_vertex_program) both offer a position-invariant program options -- where the transform should match fixed-function transform exactly.

EXT_vertex_shader (supported by ATI and possibly others) doesn't seem to have a position-invariant option. I don't know what other vendors would recommend about the use of EXT_vertex_shader, but I think ARB_vertex_program should be available on all the relevant platforms.

On GeForce3 cards, 4 DP4 instructions will often not produce the same results as the fixed-function transform. The math is slightly different, and you can end up with LSB rounding errors. If you need the Z values to match up, use position-invariant transforms.

Note that depth fighting can also look very coarse -- often rounding errors can have a very predictable pattern. I've seen Z fighting where you could see all of the left half of a triangle and none of the right half, for example.