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 
).
Current NVidia papers can be viewed with version 4, but it would be too sad if that changes in the future…
Great paper, btw 
Julien.
[This message has been edited by deepmind (edited 03-14-2002).]
Originally posted by PH:
[b]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.[/b]
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
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 
). 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.
-SirKnight
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 ).
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.
Here an old light scissoring test screenshot,
http://www.geocities.com/SiliconValley/Pines/8553/ScissorLights.html
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 or have you got a very busy site?
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 ).
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
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^
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
Originally posted by cass:
[b]
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[/b]
Of course!
I am so stupid Thanks Cass.
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.
-SirKnight
I’ll soon register a domain and get some more bandwidth & space for demos
Demos are good , especially for me to learn from
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
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.
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
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).]
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 ?
Originally posted by cass:
[b] 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[/b]
Ok, here are a couple of test shots …
http://www.geocities.com/SiliconValley/Pines/8553/ScissorInf.html
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 ).