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
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).]
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?
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 ).
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 ).
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.
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.
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?
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 
).
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