I wonder if anyone tried capping at z-near plane? There’s an old technique in “Red Book” but it fails for non-convex objects. This would be useful whith stencil shadows (capping the volume).

I have idea how to do that, but want to know others experience.

Hi,

The best way I can think of requires depth testing, so it’s out for the shadow volumes. The easiest way to get around this is using the zfail approach, then you don’t need to cap at near plane.

The algorithm is very much like the one you’re propably using, except now you draw the backfaces first, increasing stencil where the depth test fails. Then the front faces, decrease on fail.

Unlike in the zpass approach, you will have to draw closed volumes. This is easiest to do by drawing the front faces of an object, as seen from the light, at the other end of the shadow volume, and the backfaces at the other end. Then you should use the infinite projection matrix trick to avoid far clipping, nvidia has a paper on this somewhere.

You can use both methods simultaneously, using zpass for volumes that you know the viewer is not in. This helps, because in general zfail is a little bit slower.

-Ilkka

Thanks for your answer.

I saw lot of talking about this technique here, but I think the old zpass isn’t explored enough, especially when you count requirements for zfail.

Can zfail manage situation in which camera “see” inside of volume but isn’t actually in it, i.e. it’s near clip plane clips the volume?

Here is my idea : project volume cap on camera’s z-near plane toward light direction vector. You can do this simply by applying appropriate matrix; so shadow volume is always capped, and you never see inside of it, even if in previous situation…

Yes, the zfail method handles that case too. But the zpass does have it’s advantages, so if you find a fast and robust way to cap the volume, go ahead.

It looks like in your technique you somehow need to find the cap on cpu, which might cancel out the speed increase gained by the use of zpass. You might also get some cracks on the edges of the cap, since the volume polygons don’t have vertice there. I’m a little sceptic about this, but feel free to prove me wrong

-Ilkka

Generating an actual cap ( geometry ) on the CPU is very, very… very difficult. I attempted this in early 2000 and was never able to handle all cases.

Though I did manage to generate a cap on the near plane and use the zpass approach by using the stencil buffer. The way to do this is by rendering those shadow volumes that require capping twice. The first rendering is done exactly like the original zpass method. The second rendering is done with depth testing disabled ( or set to always ) and reversing the stencil operations ( not like zfail but simply by using INCR where you used DECR and using DECR in place of INCR ). This method requires closed volumes ( in both renderings ) just like the zfail method. Diefenbach developed this method except he didn’t use closed volumes, so it didn’t always work. By using closed volumes, it is just as robust as the zfail method ( but much less efficient ).

Anyway, it’s much better to keep things simple. That is, use zfail where required and zpass when possible.

I’m very close to realise my idea, so i’ll go for it… The way of rendering caps in z near is to use matrix similar to one that is used in flat shadowing. All you need is light vector and plane equation of camera’s local z near plane in world coordinates and you can get it by inverse transform of just one vector. So additional costs are:

find camera’s inverse matrix

transform plane by it

render cap (once)

Maybe reality will bite me , but for now it looks good to me…

If you really want to render a cap on the near plane, then this might interest you

http://developer.nvidia.com/view.asp?IO=cedec_stencil

It shows how to avoid getting the caps clipped by the near plane.

Now that I come to think of it, generating an actual cap shouldn’t be too difficult after all ( it seemed impossible at the time ).

PH:

This text file: http://developer.nvidia.com/docs/IO/2585/ATT/CarmackOnShadowVolumes.txt

Shows you that Carmack came up with the zfail method by doing exactly what you mentioned wrt drawing the volumes twice.

If you think about it, what you are doing is:

INCR front faces on depth pass

DECR back faces on depth pass

INCR all back faces

DECR all front faces

This can be written as ( by simply rearranging the passes):

INCR all back faces

DECR back faces on depth pass

INCR front faces on depth pass

DECR all front faces

Which collapses to:

INCR back faces on depth fail

DECR front faces on depth fail

Which is exactly the standard zfail approach.