<p>This issue looks like standard shadow map acne artifacts. Additionally your's lighting equation is incomplete or wrong. Light shouldn't influence faces with normals facing away from it. This also means that with a proper equation the "dark" side of the sphere shouldn't have any acne artifacts.</p>

<p>There are three sources of acne artifacts:</p>

<ul>
<li>First acne source is shadow map precision. Make sure that near and far planes of shadow casting light are as tight as possible. All objects before the near plane can be pancaked, as their exact depth isn't important.</li>
<li>Second acne source is shadow map resolution. For a directional light you should be doing cascaded shadow maps with at least 3 1024x1012 cascades for ~100-200m of shadow distance. It's hard to cover similar shadow distance with one shadow map with uniform projection.</li>
<li>Third acne source is wide shadow map filter like PCF, as using a single depth depth comparison value across a wide kernel is insufficient. There are many methods to fix it, but none of them is robust.</li>
</ul>

<p>To sum up, a tight frustum with a few cascades and some bias tweaking is enough to get the general case working (directional light). Start tweaking by disabling shadow filtering and tweak for filtering only when basic shadow maps are robust enough. </p>

<p>Additionally apart from the constant depth bias (which you currently use) you should also add slope depth bias and max slope depth bias. Both can be be implemented either as render state or as shader code during shadowmap rendering. Slope depth bias is simply a magic bias value scaled by dot( normal, lightDir ).</p>

<p>There are some additional interesting methods and most of them are implemented in the excellent demo: <a href="https://mynameismjp.wordpress.com/2013/09/10/shadow-maps/">Matt Pettineo - "A sampling of shadow techniques"</a>.</p>

<ul>
<li>Flip culling during shadow map rendering (trades acne for Peter panning).</li>
<li>Normal offset shadow mapping does wonders for bias issues, but requires to have vertex normals around during shading.</li>
<li>Variance based methods (ESM, VSM, EVSM) completely remove bias issues, but have other drawbacks (light leaking and/or performance issues).</li>
</ul>

CC BY-SA 3.0
2015-08-31T19:56:41.090Z
2015-08-31T22:01:39.200Z
2015-08-31T22:01:39.200Z
Krzysztof Narkowicz
<p>I've been playing around with shadow mapping in OpenGL using depth textures. The depth texture is fine and I can map it onto the scene but I have some strange artefacts on the back of the object:</p>

<p><img src="https://i.sstatic.net/5mvOl.png" alt="Sphere casting a shadow, with artefacts on rear"></p>

<p>My question is what is causing this and how can I fix it?</p>

<p>The fragment shader I'm using is fairly straightforward (I stripped out the colour for simplicity in case you're wondering why there's no blue here):</p>

<pre><code>in vec4 vShadowCoord;

uniform sampler2DShadow shadowMap;

out vec4 fragColor;

void main()
{
    float bias = 0.005;
    float visibility = 1.0;
    if (texture(shadowMap, vec3(vShadowCoord.xy, vShadowCoord.z / vShadowCoord.w)) &lt; (vShadowCoord.z - bias) / vShadowCoord.w)
        visibility = 0.25;

    fragColor = vec4(visibility);
}
</code></pre>

<p>Edit: As requested, minimum working example screenshot that uses only the above code (no colour).</p>

<p><img src="https://i.sstatic.net/DdrCy.png" alt="Same sphere, minus colour"></p>

CC BY-SA 3.0
2015-08-30T17:23:05.893Z
Can you confirm whether the code shown (with blue removed) also causes the artefacts? If you have narrowed down the code then showing the image from the narrowed down code will help exclude any irrelevant details and highlight the problem.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-31T04:54:39.483Z
Yes it does, I figured I'd take a screenshot with colour in there otherwise it looks even uglier :)
Blarglenarf
CC BY-SA 3.0
2015-08-31T11:04:49.763Z
I can understand that, but since it's the ugliness that you're asking for help with, you might have a better chance of someone seeing the problem if you include the screenshot that matches the code too.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-31T13:35:00.863Z
Fair enough. I've added an extra screenshot.
Blarglenarf
CC BY-SA 3.0
2015-08-31T19:36:47.713Z
Have you tried playing around a bit more with the bias?
cifz
CC BY-SA 3.0
2015-08-31T19:49:59.960Z
This looks like shadow acne https://msdn.microsoft.com/en-us/library/windows/desktop/ee416324(v=vs.85).aspx - this is what the bias factor is supposed to alleviate, as cifz suggests try adjusting the value.
mattnewport
<opengl><glsl><shadow-mapping><shadow>
Shadow Mapping artefacts
Blarglenarf
# Shadow Mapping artefacts

(Asked by: username_0 on 2015-08-30)

I've been playing around with shadow mapping in OpenGL using depth textures. The depth texture is fine and I can map it onto the scene but I have some strange artefacts on the back of the object:

![Sphere casting a shadow, with artefacts on rear](https://i.sstatic.net/5mvOl.png)

My question is what is causing this and how can I fix it?

The fragment shader I'm using is fairly straightforward (I stripped out the colour for simplicity in case you're wondering why there's no blue here):

```
in vec4 vShadowCoord;

uniform sampler2DShadow shadowMap;

out vec4 fragColor;

void main()
{
    float bias = 0.005;
    float visibility = 1.0;
    if (texture(shadowMap, vec3(vShadowCoord.xy, vShadowCoord.z / vShadowCoord.w)) < (vShadowCoord.z - bias) / vShadowCoord.w)
        visibility = 0.25;

    fragColor = vec4(visibility);
}

```

Edit: As requested, minimum working example screenshot that uses only the above code (no colour).

![Same sphere, minus colour](https://i.sstatic.net/DdrCy.png)

**Tags:** opengl, glsl, shadow-mapping, shadow

> **Comments:**
> **username_1**: Can you confirm whether the code shown (with blue removed) also causes the artefacts? If you have narrowed down the code then showing the image from the narrowed down code will help exclude any irrelevant details and highlight the problem.  
> **username_0**: Yes it does, I figured I'd take a screenshot with colour in there otherwise it looks even uglier :)  
> **username_1**: I can understand that, but since it's the ugliness that you're asking for help with, you might have a better chance of someone seeing the problem if you include the screenshot that matches the code too.  
> **username_0**: Fair enough. I've added an extra screenshot.  
> **username_2**: Have you tried playing around a bit more with the bias?  
> **username_3**: This looks like shadow acne https://msdn.microsoft.com/en-us/library/windows/desktop/ee416324(v=vs.85).aspx - this is what the bias factor is supposed to alleviate, as username_2 suggests try adjusting the value.  

---

## 1 answers

### Answer by username_4 on 2015-08-31. Score: 11 | Accepted answer

This issue looks like standard shadow map acne artifacts. Additionally your's lighting equation is incomplete or wrong. Light shouldn't influence faces with normals facing away from it. This also means that with a proper equation the "dark" side of the sphere shouldn't have any acne artifacts.

There are three sources of acne artifacts:

* First acne source is shadow map precision. Make sure that near and far planes of shadow casting light are as tight as possible. All objects before the near plane can be pancaked, as their exact depth isn't important.
* Second acne source is shadow map resolution. For a directional light you should be doing cascaded shadow maps with at least 3 1024x1012 cascades for ~100-200m of shadow distance. It's hard to cover similar shadow distance with one shadow map with uniform projection.
* Third acne source is wide shadow map filter like PCF, as using a single depth depth comparison value across a wide kernel is insufficient. There are many methods to fix it, but none of them is robust.

To sum up, a tight frustum with a few cascades and some bias tweaking is enough to get the general case working (directional light). Start tweaking by disabling shadow filtering and tweak for filtering only when basic shadow maps are robust enough.

Additionally apart from the constant depth bias (which you currently use) you should also add slope depth bias and max slope depth bias. Both can be be implemented either as render state or as shader code during shadowmap rendering. Slope depth bias is simply a magic bias value scaled by dot( normal, lightDir ).

There are some additional interesting methods and most of them are implemented in the excellent demo: [Matt Pettineo - "A sampling of shadow techniques"](https://mynameismjp.wordpress.com/2013/09/10/shadow-maps/).

* Flip culling during shadow map rendering (trades acne for Peter panning).
* Normal offset shadow mapping does wonders for bias issues, but requires to have vertex normals around during shading.
* Variance based methods (ESM, VSM, EVSM) completely remove bias issues, but have other drawbacks (light leaking and/or performance issues).


---

