DANG SWILLIES! [Edited by - Name_Unknown on October 28, 2005 9:33:35 AM]

Changing the direction of the depth test is logically equivalent to changing the stencil operation from pass to fail. However, most GPUs will disable hierarchical z-buffering for the rest of the frame if you change the direction of the depth test, so doing that will probably cause a performance hit.

DORFMAN, KEE KEE WAKO CHIK?

I LIKE WAFFLES AND CHICKEN!

[Edited by - Name_Unknown on October 28, 2005 9:02:59 AM]

Shoot me too if my approach is also already well known. For my shadow volumes (using the big gray square overlay method), I've changed the stencil operation from Compare.Less to Compare.GreaterEqual when rendering the overlay for the case that the camera is in the shadow volume.

This seems to invert the shadow, so it's giving the correct effect, though I haven't implemented a 'camera in shadow check' yet. So maybe a reason for still using Z-fail might be that it is more forgiving on the cam-shadow check, a check which is (as far as I understood) only needed to increase performance by switching to the Z-pass method when possible.

My method would require an exact computation of whether the camera is in shadow or not, but on the other hand it doesn't require capped shadow volumes so the computational expense should be about equal to the Z-fail approach, maybe even faster with optimisations (i.e. only calculating cam-shadow intersection when shadow and/or cam pos changed).

I'm using this technique for my demo, which renders an outdoor scene. For this it seems to be the way to go, since the dimensions of the landscape require a very 'far' far clipping plane, so this is not an issue for my shadow volumes. Maybe this approach is ignored because it just doesn't work well for indoor environment shadows?

Could anyone with some more theoretical background shed some light on this, if it really would work? I just realized I don't even know exactly why the Z-pass algorithm fails when the camera is inside a shadow volume, only that it does.

Quote:Could anyone with some more theoretical background shed some light on this, if it really would work? I just realized I don't even know exactly why the Z-pass algorithm fails when the camera is inside a shadow volume, only that it does.

Shadow volumes make use of the property that, for a closed volume, a ray that intersects the volume will pass through a back facing polygon for every front facing polygon it travels through. An area receiving shadow is where the ray intersects another surface before leaving the volume. Thus, by counting the number of front and back facing polygons between the camera and the shadow receiver, you can calculate which parts, if any, are in shadow.

The z-pass method effectively compares the numbers of front and back facing planes between the camera and the receiver. The receiver is in shadow if they are not equal. Have a look at the diagram from this article and convince yourself that, for any point outside the volume, a ray to any shadowed area passes through only one plane, and a ray to any part outside passes through both a front and back facing plane.

This is no longer the case when the camera enters the volume, and typically the values calculated by the stencil buffer are reversed.

The z-fail method instead counts the number of planes between the shadow receiver and "infinity". Thus it does not matter how many planes lie between the camera and the receiver, so the camera can enter the volume.

Quote:My method would require an exact computation of whether the camera is in shadow or not

You could still have problems here. There are cases where the volume intersects the viewport, so that half of the screen lies within a volume and half without. This may not be a problem depending on the type of game your engine is designed for, but for a typical FPS you will probably notice the effects.

Thanks for the info, MumbleFuzz.

I am only using a directional light (for the sun) and an overview camera for my terrain scene, so the volumes are typically extruded away from the camera with no risk of intersection with the viewport. In fact, I haven't had to use anything else than Z-pass so far and chances are I never will, but I just wanted to check my approach.

I just re-read the topic start however and noticed Name_Unknown's comment that everyone is using shadow maps now-a-days. Is this true? I did some quick reading on shadow maps and the results do look good, but it seems quite an expensive technique and very hard to (efficiently) implement for < SM2 hardware... Would that assumption be correct? :)

Shadow maps are becoming popular, but I haven't yet implemented them myself. If done well the visual quality is probably a little higher than using volumes (soft shadows are easier to implement, for example). Depending on your engine requirements, implementing shadow maps well may be harder than implementing shadow volumes, but I think in your case you shouldn't have many problems.

I can't tell you much more than that. For more, I recommend you search the forums for Yann L's comments on shadow maps.