# Linear or non-linear shadow maps?

This topic is 3169 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I asked this on the back of someone else's post but didn't get much response, so thought I'd see how it gets on in its own thread. I understand that, for aliasing mitigation, it might be beneficial to use linear depth maps as opposed to non-linear depth maps when rendering to a shadowmap floating point texture, but how is that normally achieved? Is it as simple as converting the regular float depth value to a 16.16 fixed point float or something like that? Secondly, I've read in several places that there is some hardware-assistance when dealing with shadowmaps - could someone please explain what this assistance is exactly? Thanks in advance

##### Share on other sites
I don't have any direct experience with shadow mapping, but I have written linear depth buffer shaders before: the projection matrix requires a couple of elements to be tweaked, the vertex shader requires a custom transform function, and the pixel shader needs to manually write the depth value after calculating it correctly. This eliminates the possibility of Z early out (afaik). If you can't find anything via google I can dig up the shaders and matrix code, but I am in work atm.
The only hardware assistance I know of for shadow-maps is the special shadow map texture and sampler types that use a single bit per pixel (iirc).

##### Share on other sites
Quote:
 Original post by RobMaddisonI understand that, for aliasing mitigation, it might be beneficial to use linear depth maps as opposed to non-linear depth maps when rendering to a shadowmap floating point texture, but how is that normally achieved? Is it as simple as converting the regular float depth value to a 16.16 fixed point float or something like that?

First, some background on depth buffers. The "problem" with depth buffers is that with a perspective projection, the resulting depth value you get by dividing z by w will increase non-linearly from 0 to 1 as you move from the near-clip plane from the far-clip plane. So you end up with most of your viewable range ending up in the [0.9, 1.0] range which gives you a very uneven distribution of precision for your depth buffer. See this and this for more info.

Now for shadow maps, whether this is an issue depends on how you're storing your shadow maps and also the type of light source. For lights where you use a perspective projection for generating the shadow map (usually spot and point lights), this can be a problem if you store z/w in your shadow map. If you're manually writing the depth to a floating-point render target the problem is even worse...this is because floating-point values have more precision closer to 0 than they do closer to 1, and this compounds with the perspective projection problem to give you even more error. But for this particular case you have a very simple remedy: just store something other than z/w. For instance you can store the world-space distance from the light position to the pixel position, or you can store view-space z. For directional lights an orthographic projection is typically used, and with an orthographic projection your z/w value will be increase linearly so you won't have precision distribution problems.

Quote:
 Original post by RobMaddisonSecondly, I've read in several places that there is some hardware-assistance when dealing with shadowmaps - could someone please explain what this assistance is exactly?Thanks in advance

This typically refers to Nvidia's hardware PCF extension, which has been around for a long time. Basically it performs 2x2 PCF on the depth values for you in the texture unit, so that you don't have write pixel shader code for doing the 4 samples, the 4 compares, and the filtering. It's still available as a "driver hack" in D3D9, but in 10/11 it's no longer necessary since the API has generalized support for performing a compare operation during a texture fetch. ATI actually supports the D3D9 hack for their most recent hardware.

##### Share on other sites
Great explanation, Matt. Thanks both.

1. 1
2. 2
3. 3
Rutin
15
4. 4
5. 5

• 13
• 26
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
633723
• Total Posts
3013556
×