What causes shadow acne?

Question

I was looking through shadow matching and found the following tutorial:

http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/

This makes sense to me until the author starts discussing the shadow acne artifact. They explain the reason with the following diagram (without words):

I still have a lot of problems understanding what really causes the shadows and why adding an offset eliminates it.

Shadow card resolution does not seem to affect acne. What then? Maybe floating precision, or is it something else?

Answer 1

Yes, this is a problem of accuracy. Not a problem with the float, just the ultimate accuracy.

In theory, the shadow map stores the "distance to the nearest object from the light." But in practice, it stores "distance-eps from light."

Then, when testing, you have a distance to the same light. But then again, in practice ± eps2. Therefore, if you compare these two values, it turns out that eps changes differently when interpolated to render or shade the shadow map. Therefore, if you compare d ± eps < d2 ± eps2 , if d2==d , you may get the wrong result, because eps!=eps2 . But if you compare d ± eps < d2 + max(eps) + max(eps2) ± eps2 , everything will be fine.

In this example, d2==d . This is called self-defense. And it can be easily fixed with the aforementioned bias or simply not to test yourself in raytracing.

This gets a lot more complicated with different objects, and when eps and eps2 are significantly different. One way to deal with it is to manage eps ( http://developer.download.nvidia.com/SDK/10.5/opengl/src/cascaded_shadow_maps/doc/cascaded_shadow_maps.pdf ). Or you can just take a lot more samples.

To answer the question: The main problem is that the shadow mapping compares ideal distances. But these distances are not ideal, but quantized. And the quantized values ​​are usually beautiful, but in this case we compare them in two different spaces.