How to handle Cascaded Shadow Mapping with small Field Of View

Question

I have a simulation software where the user can set the camera parameters such as the field of view. If the field of view is about 90°, the cascaded shadow images fit perfectly, as in Figure 1.

Figure 1: Three shadow cascades on a 90° FoV.

However, if the field of view is very small, most of the pixels of the shadow map are outside the frustum. See figure 2.

Figure 2: Three shadow cascades on a very small FoV.

I played around a bit and figured that this problem could be easily solved by changing the projections of the shadow map to fit better into the frustum (see Figure 3).

Figure 3: The three shadow cascades are scaled in order to better adapt them to the frustum.

Then I noticed that the shadow flickers when you move / rotate the camera. So the cascades have to be aligned in a voxel grid, and when you move / rotate the camera, the cascade jumps to the neighboring grid cell. From now on, the cascades are no longer rotated. This works very well for square cascades and large fields of views. However, this is not possible for scaled cascades.

So I came up with the idea of using many more cascades with a lower shadow map resolution (see Figure 4)

Figure 4: Many square shadow cascades on a very small FoV.

I haven't tested it now because there are so many things to change in the code, but I think the downside is that if the sun and the camera are aligned the same (directly behind the camera), the geometry that is close to the camera will be projected onto all the shadow maps. Due to the high number of shadow maps, this would slow down my renderings.

At the moment I have a texture2D_Array assigned to my framebuffer, and within the geometry shader the triangles are duplicated via the shadow cascades.

What is the best way to cascade shadows when the field of view is small? How to deal with telephoto lenses? (FoV < 1°). Or is there a better algorithm than cascaded shadow mapping? (should work without raytracing)

Answer 1

I'll attempt to do a clear writeup of this, however, there is a lengthy explanation in the book fged2 that is much better then what I can do.

---

The first piece is making sure the shadow projection matrix has a constant size in light space for both the x and the y directions. This step keeps the physical size of each Texel constant in each cascade. If we just compute them using pure floating point math then there is a fractional part that can cause the Texel positions of the final calculation to move fractionally between different positions depending on the camera position and results in shadows that pop from one place to another as the camera moves.

To get rid of the fractional part the book uses the ceil function, but I think the code could probably get away with floor. At any rate use $d_c =ceil(d)$ on the x and y sizes of the parallel projection. $d_c$ should be the same for both, ie $2/d_c$.

The second piece is to figure out the physical size of each Texel of the shadow map in light space and use that to guarantee the shadow camera's x and y position is an integral multiple of the Texel size. The physical size of each Texel after computing $d_c$ is just $P=d_c/s_d$ where $s_d$ is the shadow map size. This gives $P$ as the physical size of each Texel. Now use that to snap the camera to the grid. To do this we compute the cameras x and y grid position, then multiply that by the grid size to snap the camera into place for both x and y positions. Where the grid size is the physical size of each Texel $P$. Here is the calc for $x$ but $y$ is basically the same $x_p=floor(Xsize/(2P))*P$ Where $Xsize$ is the projections x dimension (the distance across it) in light space. Also the floor function is doing the same function as it did in part 1 above. Do the same thing for y and use the usual value for z. This gives us the camera position.

Finally we need a stabilized cascade matrix. Normally you would compute the matrix then takes its inverse but that process will put a fractional piece back into the matrix equation and cause popping again so instead the book recommends just computing the inverse directly using the negative of the camera position computed above for the last column of the matrix. (really you can get away with just computing the inverse and then just put the negative of the camera position in the last column)

One last detail is the shadow map size must be a power of 2. Power of 2 fractions can be represented exactly on the GPU. ie $1/2^n$

This sounds pretty involved when I write it up like this, but all it is really doing is snapping the camera and the projection to a grid that guarantees Texel's always map to the same locations. If you implement these one at a time. Part one only gives a minor improvement, part 2 gives a significant improvement, and part 3 makes shadows more stable then what I have seen in a lot of games. In fact I think it has made me into a shadow snob.

---