PDA

View Full Version : new technique paper - for stenciled shadow volumes



cass
03-12-2002, 10:08 PM
Mark Kilgard and I have a paper on robust stenciled shadow volumes that's probably a good read for anyone thinking of implementing them. We'll be talking about this at the Advanced OpenGL course at GDC next Wednesday. So come and bring your questions. http://www.opengl.org/discussion_boards/ubb/smile.gif

This link will be live sometime tomorrow: http://developer.nvidia.com/view.asp?IO=robust_shadow_volumes

But you can look at the paper at: http://cvs1.nvidia.com/OpenGL/doc/whitepapers/RobustShadowVolumes.pdf (2.1 MB)

And the hard-to-find "personal communication" reference to Carmack's Reverse: http://cvs1.nvidia.com/OpenGL/doc/whitepapers/CarmackOnShadowVolumes.txt (7 kB)

And Heidman's original article on using stencil for shadow volumes. http://cvs1.nvidia.com/OpenGL/doc/whitepapers/RealShadowsRealTime.pdf (9.1 MB)

Thanks -
Cass

robert
03-13-2002, 12:13 AM
I have on thing to say....

Thank you Thank you Thank you Thank you Thank you Thank you Thank you Thank you
http://www.opengl.org/discussion_boards/ubb/biggrin.gif


I really wanted to make it to the conference, but it costs too much for a plane ticket from this side of the world to san jose http://www.opengl.org/discussion_boards/ubb/frown.gif and im just a poor University student, so this is the next best thing, yay!

Also, how long will it be before the material covered in the conference becomes availabe to those of us who couldn't go?


[This message has been edited by robert (edited 03-13-2002).]

kon
03-13-2002, 12:22 AM
Thanks for the info. And what I really like now is that the whole sdk is 'browseable' online! cvs1.nvidia.com (http://cvs1.nvidia.com)

kon

Pentagram
03-13-2002, 12:31 AM
I love it!
Especially that infinite projection-matrix trick is neat!

cass
03-13-2002, 01:03 AM
We should have all the material that we present at GDC on the NVIDIA web site within the following week.

Glad you like the paper. The demo(s) used to generate the images need a little bullet-proofing before we release them, but hopefully in the same timeframe.

Thanks -
Cass

SirKnight
03-13-2002, 08:14 AM
Well i think that paper is just awesome! You guys did an excellent job on it and the demos. I was kind of suprised on the low framerates on that one demo with the q2 models, but its just a demo, its not like that is a fully optimized game engine. http://www.opengl.org/discussion_boards/ubb/smile.gif But even then, i would have figured the geforce 4 could push it faster with what it was having to do. Oh well. Speaking of that, i sure hope my geforce 4 ti comes in this week. Yay!

-SirKnight

Gorg
03-13-2002, 10:00 AM
Great paper. I understood everything in one reading http://www.opengl.org/discussion_boards/ubb/smile.gif which is very rare for me with white papers.

Well the document has a very practical approach to it and ALL the details are there. Good job.


[This message has been edited by Gorg (edited 03-13-2002).]

PH
03-13-2002, 10:41 AM
I've had the paper for just over a month now and was also surprised by the simplicity of this new method. Mark Kilgard gave me a thorough explaination of a particularly obscure technical point. I was expecting this technical point ( with Mark's detailed explanation ) to have been included in the paper. Personally, I think it's an important point.

The only thing that I was worried about was the performance. It definitely consumes more fill but it can be implemented entirely and robustly on the GPU. And that's a good thing.

Lighthouse
03-13-2002, 11:26 AM
Thank you! I've been looking for that Heidman article for ages!

I like the Iris GL listing at the end. http://www.opengl.org/discussion_boards/ubb/wink.gif

Gorg
03-13-2002, 12:23 PM
Originally posted by PH:
I've had the paper for just over a month now and was also surprised by the simplicity of this new method. Mark Kilgard gave me a thorough explaination of a particularly obscure technical point. I was expecting this technical point ( with Mark's detailed explanation ) to have been included in the paper. Personally, I think it's an important point.

The only thing that I was worried about was the performance. It definitely consumes more fill but it can be implemented entirely and robustly on the GPU. And that's a good thing.


Please tell us more http://www.opengl.org/discussion_boards/ubb/smile.gif

PH
03-13-2002, 12:48 PM
Gorg,

Cass has a copy of the e-mail I got from Mark too. You could try to convince him to post the explanation here http://www.opengl.org/discussion_boards/ubb/smile.gif. Mark said they really wanted to address the technical point in the paper but wanted to keep it 8 pages ( the newly released paper is slightly different, so I wonder why it wasn't added ).

cass
03-13-2002, 01:12 PM
Ok, this is actually an interesting point, so here's the relevant email thread.
http://cvs1.nvidia.com/OpenGL/doc/whitepapers/projected_shadow_volume_caps.html

Thanks -
Cass

Lars
03-13-2002, 01:57 PM
Thanks for that damn good paper !!!

Now some questions, hints and calculations...
From The Paper:


In the case of a directional light, all the vertices of a possible silhouette edge loop project to the same point at infinity. In this case, a TRIANGLE_FAN primitive can render these polygons extremely efficiently (1 vertex/projected triangle).


This would also mean, that it isn't necessary to draw the light-backfacing polygons of the occluder to save additional fillrate, or am i wrong there?

In my current approach i use a special edge structure, where i only have those edges that could get possible silhouette edges. That means i pre-filter edges out, that connect triangles which have the same face normals.
This is a very common case, and saves some CPU computations.

But i also see the problem of the fillrate hit. If i summerize all drawing operations i get the following:

1. ambient pass (no backfaces)
2. The Volume sides (only stencil but very unpredictable in their size, and also front and back)
3. volume caps pass (only stencil, but front and back)
4. the light pass (no backfaces, no depth)

ambient-front + volume-front + volume-back + volumecaps-front + volumecaps-back + lighted-front

This would mean a maximum of over four times the passes then without shadows.
And i don't know how much you gain by only drawing to the stencilbuffer, is it a relevant factor in the equatation ?

Thanks
Lars

[This message has been edited by Lars (edited 03-13-2002).]

cass
03-13-2002, 11:14 PM
Lars,

That's right. No reason to draw a projected end cap on the shadow volume because they'd all be degenerate triangles anyway. http://www.opengl.org/discussion_boards/ubb/smile.gif

Shadow volumes definitely eat fill. If you're working with bounded light sources, be sure to use the scissor test to avoid wasting fill on regions that *cannot* be illuminated. There are additional tricks for limiting the geometry you actually send down too.

The real potential for making shadow volumes fast is figuring out when you don't have to draw a shadow volume. Some approaches will take advantage of early culling hardware. Others will require detailed scene-level analysis of occluder geometry.

Because stenciled shadow volumes are becoming commonplace (especially in future games), you can expect the mode of writing stencil only to get faster as well.

Thanks -
Cass

Cab
03-13-2002, 11:47 PM
Fine, Cass. Next Wednesday, I will be there to see it.
By the way, how many of you will be at GDC?

cass
03-13-2002, 11:50 PM
Cab,

Looking forward to it. There are 8 guys in my group that will be presenting at the OpenGL course. Lots more for other sessions and the dreaded booth duty. http://www.opengl.org/discussion_boards/ubb/wink.gif

Cass

Julien Cayzac
03-14-2002, 12:31 AM
Originally posted by cass:
you can look at the paper at: http://cvs1.nvidia.com/OpenGL/doc/whitepapers/RobustShadowVolumes.pdf


Cass,

Thanks for releasing this paper. However, could you please make it available in a PDF format that is readable by recent versions of GhostView ? Not everybody runs Windows here.

It's sad but true, many NVidia papers are unreadable without the PDF reader from Acrobat :p

Julien.

cass
03-14-2002, 12:59 AM
Julien,

I'll see what I can do - but you may have to remind me again. Preparing for GDC is taking all my time right now.

Thanks -
Cass

PH
03-14-2002, 06:40 AM
If you're interested in seeing what the geometry of clipped vs. infinite shadow volume geometry looks like, I just uploaded two wireframe shots,
http://www.geocities.com/SiliconValley/Pines/8553/ClippedShadowGeometry.html

The fill rate savings from clipped shadows is quite a lot for common bounded lights.
The difficulty with the clipping approach lies in trying to avoid clipping the front faces of the shadow volumes. If front faces are clipped, the original occluder geometry must be modified to avoid cracks.

PH
03-14-2002, 06:44 AM
PS. This is important for creating perfect beam trees. With an approximate beam tree, you can avoid clipping front faces.

Julien Cayzac
03-14-2002, 07:24 AM
Thanks Cass, but as I wanted to read that paper I installed the linux version of Acrobat Reader 4 (Linux isn't supported anymore by Adobe in version 5 http://www.opengl.org/discussion_boards/ubb/frown.gif ).
Current NVidia papers can be viewed with version 4, but it would be too sad if that changes in the future...

Great paper, btw http://www.opengl.org/discussion_boards/ubb/smile.gif

Julien.

[This message has been edited by deepmind (edited 03-14-2002).]

cass
03-14-2002, 09:19 AM
Originally posted by PH:
If you're interested in seeing what the geometry of clipped vs. infinite shadow volume geometry looks like, I just uploaded two wireframe shots,
http://www.geocities.com/SiliconValley/Pines/8553/ClippedShadowGeometry.html

The fill rate savings from clipped shadows is quite a lot for common bounded lights.
The difficulty with the clipping approach lies in trying to avoid clipping the front faces of the shadow volumes. If front faces are clipped, the original occluder geometry must be modified to avoid cracks.

Paul, can you also show a picture that uses a screen-space scissor box to limit fill?
This should improve things significantly without doing geometric clipping.

Cass

SirKnight
03-14-2002, 09:34 AM
Does the top screenshot represent the infinite volume technique? Also by common bounded lights do you mean attenuated lights by that?

Cass, could you explain more about the 'screen-space scissor box to limit fill' thing? Im not sure i quite understand what that does (well besides limit fill http://www.opengl.org/discussion_boards/ubb/wink.gif). If that is described in the article im sorry.

Now with this paper ill be able to finish some kind of shadow volume code, now that a few things are more clear. I just need to fix my model code, darn thing is giving me some really psychedelic results. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

PH
03-14-2002, 09:49 AM
Cass,

I haven't done any graphics work for quite a while ( I just finished writing an optimizing compiler which has taken up most of my time ).
I do have an old shot of this scissor technique applied to a portal face.
http://www.geocities.com/SiliconValley/Pines/8553/PortalScissorBox.html

About six months ago, I did do some tests with scissoring and lighting and the performance increase was quite encouraging ( it's definitely worth the effort ).

PH
03-14-2002, 09:53 AM
Originally posted by SirKnight:
Does the top screenshot represent the infinite volume technique?


It represent the infinite volume but with the backfaces drawn without culling ( to show it's size ).



Also by common bounded lights do you mean attenuated lights by that?


Yes that's correct.

PH
03-14-2002, 10:03 AM
Here an old light scissoring test screenshot,
http://www.geocities.com/SiliconValley/Pines/8553/ScissorLights.html

robert
03-14-2002, 10:21 AM
The web site you are trying to access has exceeded its allocated data transfer. Visit our help area for more information.
Access to this site will be restored within an hour. Please try again later. http://www.geocities.com/SiliconValley/Pines/8553/ClippedShadowGeometry.html

wow, they don't seem to allow as much as they used too http://www.opengl.org/discussion_boards/ubb/biggrin.gif or have you got a very busy site?

PH
03-14-2002, 10:40 AM
robert,

Actually, I probably have the most boring site on the Net. The only hits that I get are from the OpenGL board. I'll soon register a domain and get some more bandwidth & space for demos and such ( Geocities is also kind of annoying with the popups ).

Lars
03-14-2002, 11:42 AM
I think with using Scissoring, he means that you project the bounding of an attenuated light to window coordinates and restrict fragment operations in the resulting rectangle, for all but the ambient step.
This would give you some fillrate especially in situations where the range of the light is relatively small compared to the screen size.

It could also help in other cases, where you can encapsulate the light/shadow recieving geometry with a scissor box.
For example in a flight over a terrain, you can ignore everything above land (as long as nothing flys around there, and you aren't looking to the ground).
In this case, you only save some of the stencil draws of the volume. Hope i described it clearly ;-)

If you wan't to know how scissoring works in OpenGL, just look in the specs on Page 158. Or lookup glScissor() somewhere else.

Lars

Gorg
03-14-2002, 12:41 PM
I don't see how scissoring can help you if already only render the objects in your light frustum or light bounding volume.

Am I missing something^

cass
03-14-2002, 01:10 PM
Gorg,

You're rendering infinite shadow volumes -- that is, they stretch to infinity -- which can cover a lot of pixels. If the light source is fully attenuated at some finite distance, you can use those bounds to clip the shadow volume to avoid needless increments and decrements over pixels that cannot possibly be illuminated by the light.

One way to clip the shadow volumes is a complex CSG intersection between the light volume and the shadow volume. I suggest a simpler approach that just uses the scissor rectangle that fully encloses the light volume. That way you can render simple, infinite shadow volume polygons and let the GPU do most of the fill reduction for you.

Thanks -
Cass

Gorg
03-14-2002, 02:39 PM
Originally posted by cass:

Gorg,

You're rendering infinite shadow volumes -- that is, they stretch to infinity -- which can cover a lot of pixels. If the light source is fully attenuated at some finite distance, you can use those bounds to clip the shadow volume to avoid needless increments and decrements over pixels that cannot possibly be illuminated by the light.

One way to clip the shadow volumes is a complex CSG intersection between the light volume and the shadow volume. I suggest a simpler approach that just uses the scissor rectangle that fully encloses the light volume. That way you can render simple, infinite shadow volume polygons and let the GPU do most of the fill reduction for you.

Thanks -
Cass
Of course!
I am so stupid http://www.opengl.org/discussion_boards/ubb/smile.gif Thanks Cass.

SirKnight
03-14-2002, 03:50 PM
Thanks Cass, now i understand. Using scissoring and infinite volumes together sounds to be to be a pretty good technique. I may just have to try it. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

robert
03-14-2002, 04:21 PM
I'll soon register a domain and get some more bandwidth & space for demos


Demos are good http://www.opengl.org/discussion_boards/ubb/biggrin.gif, especially for me to learn from http://www.opengl.org/discussion_boards/ubb/wink.gif

zeroprey
03-15-2002, 01:40 AM
Great paper and novell idea. I'm not sure I really see how infinite volumes with scissor test would be better than capped volumes with scissor (At least for me this still would help with fill on the models that are part out of the light). It was meantioned that this is easy to do all on the gpu but it seems to me so is capped volumes.
Thanks,
zeroprey

PH
03-15-2002, 03:19 AM
Scissoring infinite volumes will definitely increase performance. It might even be as fast as using a clipped volume ( depending on how scissoring is handled by the hardware ). Once I get the time, I'll do a comparison between the two.

bpeers
03-15-2002, 03:27 AM
One way to clip the shadow volumes is a complex CSG intersection between the light volume and the shadow volume. I suggest a simpler approach that just uses the scissor rectangle that fully encloses the light volume. That way you can render simple, infinite shadow volume polygons and let the GPU do most of the fill reduction for you.

I didn't actually try it, but I was wondering a while ago if it would be possible to do this using the stencil as well. First the stencil is cleared to zero. Next the light volume is rendered; that's just a pyramid. This increases stencil where depth fails for back facing, and decreases for front. This effectively marks all fragments that would be lit in an unshadowed but finite-volume light setting, by setting stencil to 1. Next the zfail stencil algorithm runs for the shadows, except that it has an additional condition that they only pass if stencil != 0 as well, ie a back-facing zfail test increments iff it's on a fragment that was "lit" earlier, (use != 0 for fragments already incremented from an earlier shadow zfail that passed).

This could be a bit faster because whenever stencil == 0, there is no increment-and-write-back in the second (regular zfail) part -- that could save some bandwidth.

Another thing, but I'm not 100% sure about this, is that it may eliminate the need to cap shadow volumes altogether, since the uncapped shadow volume is basically being CSG-and'ed with the light volume ? As long as the shadow planes are 'larger' than the light volume, it may work....

...does this make any sense at all http://www.opengl.org/discussion_boards/ubb/smile.gif


Edit : forgot to mention, you would obviously need to cap the light volume for the first part, but that would presumably be much easier than capping a volume extruded from a general mesh...

[This message has been edited by bpeers (edited 03-15-2002).]

rIO
03-15-2002, 05:42 AM
gr8 !!!

I was just looking in my (crappy) code to make better stencil shadows routines.

I tought some times about a probabilistic method for non interactive rendering of stencil shadows (non interactive means that path,speed of obj,light and eye are NOT interactively modified).

I'll try to explain, how harder could be to determine the visibility of shadowing faces of the object (and so select directly the shadowing faces) using a deterministic algho ?

Let's say I perfectly know theese variables :

obj current/last position - path/speed,
light c/l position - path/speed,
eye c/l position - path/speed.

Do you people think it could be possible to determine without testing all the faces in connectivity tree, which of them are visible in THIS frame, knowing which of them where visible in the last frame, and knowing exactly what's the difference in position/rotation delta for obj,light,eye ??

Ok, my explaination was a mess, do someone understood what I mean ?

PH
03-15-2002, 06:46 AM
Originally posted by cass:
Paul, can you also show a picture that uses a screen-space scissor box to limit fill?
This should improve things significantly without doing geometric clipping.

Cass

Ok, here are a couple of test shots ...
http://www.geocities.com/SiliconValley/Pines/8553/ScissorInf.html

PH
03-15-2002, 07:05 AM
The scissor box should actually have been half the size of that shown in the shots ( the clipped shot had the light set at half that range ).

SirKnight
03-15-2002, 08:29 AM
What parameters would you set in glScissor for doing this? I know i would have to put in the light attenuation size somewhere in there. Probably in the last two params (width and height) but im not 100% on that.

-SirKnight

PH
03-15-2002, 08:38 AM
Use the projection of the "light sphere" in screen-space to compute the values. A sphere is the most efficient way for point lights. For spot lights you could calculate the 2D bounding rectangle of the 8 frustum corners of the light volume. There are lots of ways ( just make sure you specify screen-space values ). Also, you will have to "clip" the 2D scissor box to the screen edges otherwise glScissor will fail.



[This message has been edited by PH (edited 03-15-2002).]

Pentagram
03-15-2002, 10:33 AM
What do you do when a light is behind you and you are scissoring, it should still cast shadows on visible geometry but the light is't visible.
But then the camera must be in the bounding sphere of the light and I could project the "inside" of the light sphere.
Is this correct?

PH
03-15-2002, 11:04 AM
If the light sphere is not entirely within the view frustum, I simply call glScissor with the screen size ( the default values but I keep it enabled ).

PH
03-18-2002, 12:30 PM
Pentagram,

Nice work on the Quake modification. Instead of checking if the sphere is completely within the frustum, just check if it's in front of the near plane ( that way it's more efficient ).

Pentagram
03-19-2002, 05:52 AM
How do you mean? I can now throw the whole light away when it's out of the frustum. If it's before the near plane I can only limit it with scissoring.

Btw my "shadow visibility" has a lot of overlapping cases, I just kept adding ways to cut shadowed polygns.

PH
03-19-2002, 06:18 AM
Culling the light when the sphere of influence is entirely outside the frustum is as it should be ( trivial reject ). What I meant is instead of just using glScissor( .. ) when the light is entirely within the frustum, a check of the near plane is enough for glScissor to work ( if not culled ). Imagine the sphere partially of one side of the screen but still in front of the viewer - this case could use the projected sphere method ( clipped to the screen edges ) rather than using the entire viewport.

okapota
03-20-2002, 12:46 AM
why is it better to use infinite volumes, instead of relatively small and capped shadow volumes, if i use attanuated light?
i mean, the volumes extend a little bit behind the light's reach, and i cap them by projecting the back facing polys as far as i project the sil' edges. and if the caps are always out side the light volume, and i scissor using the light volume, i dont need to draw the front capping right?

PH
03-20-2002, 06:50 AM
There are only two ways to implement stencil shadow volumes robustly ( in general ), one is to use infinite shadow volumes and the other is by clipping ( both using z-fail ).

Infinity is the only thing that would guarantee that the extension is far enough for all cases. As a lights distance from a surface approaches zero, the distance to extend shadow volumes approach infinity. Clipping handles this case. The new infinite shadow volumes method ( in conjunction with the Pinf projection matrix or NV_depth_clamp ) removes the need to clip.

You don't _have_ to extend to infinity all the time ( hint http://www.opengl.org/discussion_boards/ubb/smile.gif ).

cass
03-20-2002, 07:15 AM
Paul is right. And he also makes a good point that may not be completely clear in the paper -- but we tried to make the point.

The infinite shadow volumes technique is one technique in your shadow volume tool box. Its properties are that it's robust and automatic and works for all cases. You can often find more efficient techniques for specific cases. For example, you can use zpass without drawing end caps for either end if you know that the infinite cap is not in the (infinite) field of view.

An important observation is made in the paper: as long as you are consistent with your incr/decr scheme, you can change the actual technique you use for rendering each shadow volume.

The infinite volume approach is there to fill in the gaps where the other techniques fail or are very difficult to implement robustly. For best performance you should select the most efficient technique on a shadow volume by shadow volume basis.

Thanks -
Cass