psm

(after reading docs)

i just would like to know if there is a much more comprehensive recipe to build up modelview & perspective matrices that render the perspective shadow map?

with ssm i got current camera modelview (CM) & projection (CP) and also light modelview (LM) & light projection (LP). that works…

what are then the additional steps used for psm?
anyone successfull with them?

thx

Hi,

I’ve had some success with a similar method, see the end of this thread for details.

-Ilkka

OT: Have you seen http://www.comp.nus.edu.sg/~tants/tsm.html
(may be easier than PSM’s)

I’ve implemented PSM as described by Gary King ( http://download.nvidia.com/developer/presentations/GDC_2004/GDC2004_PerspectiveShadowMap.pdf ) and it works pretty great. It really solves the biggest issues with the original PSM approach (especially the objects behind the viewer problem). I haven’t implemented the TSM approach yet, but one thing I don’t like about it is that I must use a pixel shader for texture coordinate computation (and thus write my own PCF filter) because it uses a 2d projection only in one direction (and leaves the other untouched). This projection is (as far as I can judge) the real difference between the method JustHanging mentioned and TSM. It prevents the resolution problem for objects distant from the viewer. (Corrections are welcome!)

“…I haven’t implemented the TSM approach yet, but one thing I don’t like about it is that I must use a pixel shader for texture coordinate computation (and thus write my own PCF filter) because it uses a 2d projection only in one direction (and leaves the other untouched)…”

TSM uses an additional texture coordinate and pixel shaders only to address the polygon offset problem. This pixel shader is a “one-liner”. Don’t forget that PSM has polygon offset problems as well (due to the non-uniform distribution of the depth values). And contrary to PSM, in TSM this problem can be addressed very efficiently. PCF also shouldn’t be affected by doing that.

I played with PSM a couple of weeks ago, but couldn’t get it to work. I have no idea what I’m doing wrong. After lots of trouble, I implemented it exactly the way described here:
http://www9.informatik.uni-erlangen.de/Persons/Stamminger/Research/Research/psm

Still no luck though, so I gave up. And what’s up with the lack of sample code on the net for this technique? Is that a sign that very few have actually got it working?

Maybe someone who has it working could post a piece of code that sets up the matrixes?

LOL if even Humus is having trouble things are really bad for other people…

I think I saw a quote from a developer in an ATI slide from GDC2004: “Friends don’t let friends try to implement Perspective Shadow maps”

I wrote a demo that successfully used PSMs in Direct3D; most of the critical algorithmic code should be easily portable to OpenGL (a few matrix transpositions here, change a few constant values there, etc.):

http://download.nvidia.com/developer/SDK/Individual_Samples/samples.html

(there are a few minor bugs with the UI, and I didn’t implement good biasing for cards that don’t support depth-stencil textures)

Even with all of the improvements to PSMs since the original paper, they can still be difficult to deploy in some applications – YMMV. I’m probably going to do a TSM implementation next; these seem like a more thorough solution than PSMs (no singularities!), even though they are limited to ARB_f_p hardware.

Yep, just like Humus said, a nice & simple piece of code is sometime better than talks
What is missing the most is a clear code/desc of matrices setup (using known CM,CP;LM,LP) to proceed in others spaces (post persp, trapezoidal etc).
If i’ve well understood here are the advanced SM algorithm available (from simple to harder).

• Bounding Box approx. (Brabec S.[BAS02]) the most simple to implement i think, a bit of wastage btw, did anyone knows about any continuity problem with this technique?

• Trapezoidal approx. very low wastage, looks simple and efficient maybe the best method.

• PSM and LiSPSM looks simple in the docs but finally not trivial at all to implement.

Maybe a good shadow mapping FAQ would be cool covering all of these technique, let’s have non-aliased and continuous shadows for everyone!

In the process of writing my demo, I found that getting the matrices set up properly was the easy part .

The most painful issues with PSMs are handling cases where the shadow map has a huge field of view, and avoiding singularities (don’t let a transformation cause the post-projective viewbox to intersect the infinity plane; this is bad).

Originally posted by gking:
…I’m probably going to do a TSM implementation next; these seem like a more thorough solution than PSMs (no singularities!), even though they are limited to ARB_f_p hardware.
As mentioned above, TSM needs only ARB_f_p because it addresses the polygon offset problem. If you want to address the polygon offset problem in other shadow map approaches as well, then I guess you also have to use ARB_f_p.

For PSMs, I’ve found that slope-scale depth bias is sufficient.

@Gary: Some questions:

1. First regarding the special projection matrix with Zn=-a and Zf=a. I noticed in your demo something I also needed to tweak and I only understand by now (at least I think so). You’re calculating the distance from the light in PPS to the unit cube. And you also scale it down by some arbirtary factor. In my opinion this is necessary, because shadow casters may lay outside of the unit cube in PPS. If you set Zn=-a (where a is the distance to the unit cube) those shadow casters outside the unit cube may be clipped. (I guess this is why Simon Kozlov wrote “in the simplest case” when choosing a…). How to handle those cases correctly? (Do I e.g. need to find the minimum distance from the light to the intersection of the PPS light frustum with each bounding box?)

2. How does this new projection matrix compare to the other approaches where the convex hull of the scene and the light must be used? Is it (theoretically) more stable (i.e. independant of changes in the scene)

@A027298: In 6.2 (in my version this chapter is called “side lines” he proposes a perspective projection that should be applied to only direction to achieve a better distribution of values. I believe this can only be done in a fragment shader).

1. You could do this by searching for the nearest shadow caster in PPS; however, you can still end up with cases where the shadow caster is on both sides of the infinity plane. For this case, the only workable solution I can think of is virtually sliding the viewer back. In my demo, I always have the PSM viewer slid back so that Zinfinity is at 1.5 in post-projective space. This both redistributes depth precision and hides artifacts at infinity plane crossings.

As long as your shadow casters are small compared to the view frustum, I think the hack approach I used should work pretty well (reposition Zinfinity, scale a). If you want to handle terrain self-shadowing inside the PSM, then you may still run into some problems.

2. The inverted projection matrix is much more stable than the original approach. The only disadvantage to it is the increased depth precision requirement.