RE: [Algorithms] Perspective shadow maps

[Thatcher U. <tu...@tu...>]

On Thu, 26 Sep 2002, Jon Watte wrote:
>
> > The problem with that is, in order to render the shadows into the
> > scene you do a projective mapping of the shadow buffer... because of
> > the perspective transform used to draw the buffer, there's a
> > difficulty in making the images of those objects to put in the buffer.
> > I.e., those objects are behind the near-clip plane of the
> > shadow-buffer frustum.  So you need to clip; otherwise the shadows of
> > those objects will be upside down and/or all screwed up in the shadow
> > buffer.
>
> I don't quite get it (I just may be dense here).

I'm pretty sure I was being dense, and made a very confusing post.  I
think there's still an issue though, that I was clumsily groping
towards.

> -The objects behind the viewer camera, are still in front of the light,
> right?
> -When rendering the shadow buffer, the viewer for that is at the light?
> -Thus, the objects casting shadows are always in front of the viewer when
> rendering the buffer.

All agreed so far.

> -Modulo precision issues, you could push your shadow map near clip plane,
> when rendering the buffer, as close to the light source as necessary to
> avoid clipping out objects. Or you could use depth clamping.

So the problem here may be that when rendering into the shadow buffer,
objects in the scene *still* need to observe the *camera* near-plane
(not just the light near-plane); if any faces cross that camera
near-plane, you will get wacky projection.  Maybe, I think.  I need to
check the math to be sure, so don't take my word for it.

> -Now, when rendering into the color buffer, you have to do a per-pixel
> projection from screen space into the shadow buffer.
> -This projection has to use the inverse _light_ projection matrix.
> -Thus, all objects in the shadow buffer are guaranteed to be closer than
> the light at this point.

Yup, I believe you are correct here.

> -I concede that I don't have the projective shadow mapping paper in front
> of me to see if it changes these rules in some fundamental way, but I
> thought that it didn't; it just "stretched" the shadow buffer on creation.
> -It does this stretching into a unit cube in screen space, which projects
> down to a point at the viewer.
> -Now, let's consider: how does this technique support lights behind the
> camera?
> -I thought the idea was to make the shadow map loosely cover the post-
> projection unit cube, but not fit it exactly to any specific face or area
> of the cube.

Agreed.

> -Thus, the projection for the shadow map is actually such that it correctly
> deals with anything between the light and the scene, that further from the
> light than whatever your near clipping distance is when rendering the map.

Not sure I agree here; see comment above.  If you visualize the unit
cube in screen space, and the light is somewhere in that space
(outside the cube), you can see how some object also outside the unit
cube can cast shadows into the unit cube.  Now, an object that crosses
z==0 in camera space transforms to some infinitely huge misshapen
thing in screen-space, so that makes it impossible for the
shadow-buffer frustum to completely encompass that object.

The paper talks about doing some analysis to figure out just what type
of volume the shadow buffer needs to take an image of, which IIRC is
where the earlier-mentioned near-plane hijinks come in.

> -If this is indeed a reasonable set-up, then clamping depth to 0 when
> rendering the map seems like it should work fine.

Yeah, the depth clamping part sounds like a worthwhile and workable
thing, I'm just not sure about the rest of it, i.e. fitting the
necessary image in the shadow buffer.

> > the appeal.  Maybe one perspective shadow buffer, and one conventional
> > shadow buffer could do a decent job for everything?  I.e. classify
> > each casting object according to which technique will give better
> > results for the current light & view position.  Then add them together
> > on-screen.
>
> -I thought you needed one shadow buffer per light anyway?

Yes.

> -Am I missing something really major here?

Nope; I'm only saying I'm scared of 2+ buffers per light, instead of
just one...

> -Your comments are making me very confused. That's a sad feeling.

Sorry, like I said I think I was confusing my clip planes in the
earlier post.  My grasp on this topic is very tentative, especially
since I haven't actually worked on it in months, so don't assume I
know what I'm talking about :)

-Thatcher