Shadow Mapping, why don't you move the shadow View matrix?

Started by
2 comments, last by Funkymunky 8 years, 6 months ago

I'm digging into shadow mapping again. The standard procedure I've followed is to:

  • Extract the 8 frustum corners of the view frustum
  • Get the centroid, move away from this in the direction of the light by the far clipping distance
  • Create a LookAt matrix using this distance and the centroid as the from/to
  • Transform the frustum corners by this Shadow View matrix i've created
  • Get the min and max x/y/z values from the transformed frustum corners to generate an off-center Ortho Projection Matrix
  • Use these Shadow Projection and Shadow View matrices for rendering to the shadow buffer.

I've always gotten strange clipping issues in the shadows when doing this method, and I've realized (after rendering the frustums in question) that it's because the Shadow View Matrix is translated substantially farther away from the camera frustum than the Ortho bounds can tolerate for the near/far distances.

Why isn't there generally a step in there to translate the Shadow View Matrix such that it aligns with the calculated Ortho near plane? Am I missing something?

EDIT: Well, duh, because the near/far values calculated are already in terms of the Shadow View Matrix.

Advertisement


  • Get the centroid, move away from this in the direction of the light by the far clipping distance
  • Create a LookAt matrix using this distance and the centroid as the from/to

This offsetting isn't necissary as your ortho projection is already handling min/max Z.

As a similar point, you don't need the technically don't need the centroid at all, you could just use the origin and still get the same result, as the projection matrix would handle min/max X &Y, the view matrix just needs orientation. (Although, depending on the size of your scene using the origin could cause floating-point precision issues)


Get the min and max x/y/z values from the transformed frustum corners to generate an off-center Ortho Projection Matrix

As a slight heads up on this point too, if you're relying only on the frustum corners, you will be potentially culling out shadow casters that are offscreen, but who's shadows would intersect with the visible frustum. This is usually solved by modifying the near-z to fit the scene boundary.


Why isn't there generally a step in there to translate the Shadow View Matrix such that it aligns with the calculated Ortho near plane? Am I missing something?

EDIT: Well, duh, because the near/far values calculated are already in terms of the Shadow View Matrix.

Close, its handled by the ortho projection matrix being aligned to min/max x&y.

If you want more precision at the near plane though, there's a number of tricks to explore.

Cascaded shadow maps is a small extension to what you already have. Instead of having the one shadow map for the whole frustum, split the frustum into a few depth layers (4 is a pretty typical number here) then calculate the "frustum corners" for these split regions, and render a shadow map for each.

Theres also Perpsective Shadow Maps, which works via transforming the shadowmap uv space to fit the cameras' post projected space. I can't think of an easy way of wording that, but theres plenty of documentation online for this one. Depending on your requirements it may or may not work well though.

If you want precision look up Sample Distribution Shadow Maps (SDSM).

Basically you analyze the depth buffer for one or two frames back to get min/max depth and use this to tighten the view frustum. It's like night and day. smile.png

SDSM looks good, but does anyone have any experience with Camera Space Shadow Mapping? Eliminating the massive texture usage of cascaded shadow mapping while still maintaining high quality shadows seems like a major win...

This topic is closed to new replies.

Advertisement