I've been trying out various shadow mapping methods for quite some time, but haven't found one that would handle very long view distances gracefully. It would seem that it is simply not possible with a single shadow map. My attempts at implementing a system that would split the view frustum into multiple sections along the depth axis have mostly failed so far. My current approach assigns each primitive batch to a single section. Since each batch can only belong to one section, the sections must be expanded to overlap a bit. This can be done either by pushing the far planes, pulling the near planes, or both. The problem is that some of my batches occupy a huge volume in world space, thus causing the sections to which they are assigned to grow far too big. Often either the section closest to the view or the one after it get depth ranges on the order of [1, 1000]. A seemingly better alternative would be to allow each batch to belong to multiple sections. This way the sections would never have to overlap. Unfortunately it's not trivial to implement. Pixel shaders that sample e.g. 2-4 shadow maps instead of one seem a bit heavy, not to mention that you'd have to have 2-4 large render target textures instead of reusing just one. Clipping planes could in theory be used to enforce section boundaries, but in practice they would introduce gaps to objects that straddle the boundaries of two sections. Also different rendering passes (depth-first pass, other lights, etc) might not clip the geometry in the same way, causing z-fighting due to differences in vertex positions in different passes. The last approach I can think of would be to use the texkill (or equivalent) instruction in the pixel shader. Since such "clipping" is done after rasterization, there would be no z-fighting. In theory there should not be any gaps between sections either, but in practice I suspect floating point inaccuracies would again cause pixels to be discarded slightly differently for neighboring sections. Furthermore, injecting texkill instructions into shaders that need them might be messy. Has anyone else encountered the problem, and if so, come up with a solution to it? Or perhaps someone has solved the original problem of shadow mapping very large view distances using another method?

I do use a projection that enhances resolution near the viewer. More specifically I've tried the original Perspective Shadow Maps, the enhanced version described in the GPU Gems book, and Trapezoidal Shadow Maps with numerous custom tweaks for each.

I'm most interested in shadows for large directional light sources, such as the sun, so in practice there are no limits to their extents.

mrmuk, what is your experiences with TSM, I've been thinking of looking into implementing it as described here : http://www.comp.nus.edu.sg/~tants/tsm.html, but I'd be interested to hear any experiences you might have with it.

/ Anders

I found the main advantage of Trapezoidal Shadow Maps over PSM was the fact that there are no singularities. With PSM you transform the light position into the normalized device coordinates of the view (i.e. into clip space followed by the homogeneous divide), which means view space z coordinates of the light close to zero are problematic. A special case occurs when the view space z of the light equals zero, in which case an orthographic projection can be explicitly constructed for the light. TSM can be thought of as always having this special case. You can think of the trapezoid as a 2D projection of a frustum whose local space is defined so that the light's z is always zero. After that the rest works like PSM with the explicit orthographic projection.

The '80% rule' defined in the paper is similar to the 'virtual slideback' trick suggested for PSM in the GPU Gems book.

As mentioned in the paper though, TSM does not address the issue of very large view distances or the cases where the light direction is nearly parallel to the view's z axis (the 'dueling frusta' case.)

It's worth noting that the National University of Singapore has a patent pending on the TSM algorithm, as mentioned on this page: http://www.paprika.com.sg/intro/get_tech.php?tid=170

Interesting indeed.

I wonder what they intend to do with the patent, I hope they won't be going for royalties in case someone wants to implement it, only one way to find out I guess =)

Thanks

/ Anders