<p>For anyone having the same problem:
I calculated the normalized texture coordinates by</p>
<pre><code>vec2 imgSize = imageSize(img_output);
vec2 normtc = vec2(gl_GlobalInvocationID.xy) / imgSize;
</code></pre>
<p>this is of course wrong, the last line should be:</p>
<pre><code>vec2 normtc = (vec2(gl_GlobalInvocationID.xy) + vec2(0.5)) / imgSize;
</code></pre>
<p>since we want to sample the center of the pixel. This solved the problem for me.</p>

CC BY-SA 4.0
2022-03-07T17:47:25.823Z
2022-03-07T17:47:25.823Z
Sprinklerkopf
<p>I wrote an ssao algorithm with compute shaders and view-position-reconstruction from the depth buffer. It works great for objects near by but results in strip or banding artifacts for large planes further away:<a href="https://i.sstatic.net/RJrut.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/RJrut.png" alt="enter image description here" /></a></p>
<p>This does <strong>not</strong> happen if i use an explicit position buffer. I don't think this is because of floating point accuracy. My methods to reconstruct the position for the original pixel and the z coordinate for the pixels in its hemisphere:</p>
<pre><code>vec3 calcViewPos(vec2 texCoords, float depth){
    vec3 clipPos = vec3(texCoords, depth) * 2.0 - vec3(1.0);
    vec4 viewPos = vec4(vec2(invProj[0][0], invProj[1][1]) * clipPos.xy, -1,
                                   invProj[2][3] * clipPos.z + invProj[3][3]);
    return(viewPos.xyz / viewPos.w);
}
</code></pre>
<p>I use a <code>GL_DEPTH_COMPONENT32</code> depth texture. I could solve the problem by a little hack:
Comparing the normal of the original pixel and the normal of the neighbourhood pixels and skipping those which have a too similar normal solves this problem (since this only occurs on those large plains), but causes an additional texture lookup in a for loop, which costs too much (and would make using a position buffer again more efficient).</p>
<p>Did any of you experience a simillar problem or have ideas of how to solve this smarter?
Thank you very much :)</p>

CC BY-SA 4.0
2021-12-03T12:05:08.693Z
Are you offsetting the depth positions with a bias value? And are you using any depth clamping? And what is your depth slope factor?
pmw1234
CC BY-SA 4.0
2021-12-03T21:51:35.733Z
@pmw1234 yes i tried to increase the bias already, but that just shifts the banding along the view-z-axis and of course lowers the quality of the remaining ao. No i don't use depth clamping. If you mean the fov, its 70 degree
Sprinklerkopf
<opengl><shader><compute-shader><ambient-occlusion><ssao>
SSAO with reconstructed depths yields strip artifacts
Sprinklerkopf
# SSAO with reconstructed depths yields strip artifacts

(Asked by: username_0 on 2021-12-03)

I wrote an ssao algorithm with compute shaders and view-position-reconstruction from the depth buffer. It works great for objects near by but results in strip or banding artifacts for large planes further away:[![enter image description here](https://i.sstatic.net/RJrut.png)](https://i.sstatic.net/RJrut.png)

This does **not** happen if i use an explicit position buffer. I don't think this is because of floating point accuracy. My methods to reconstruct the position for the original pixel and the z coordinate for the pixels in its hemisphere:

```
vec3 calcViewPos(vec2 texCoords, float depth){
    vec3 clipPos = vec3(texCoords, depth) * 2.0 - vec3(1.0);
    vec4 viewPos = vec4(vec2(invProj[0][0], invProj[1][1]) * clipPos.xy, -1,
                                   invProj[2][3] * clipPos.z + invProj[3][3]);
    return(viewPos.xyz / viewPos.w);
}

```

I use a `GL_DEPTH_COMPONENT32` depth texture. I could solve the problem by a little hack:
Comparing the normal of the original pixel and the normal of the neighbourhood pixels and skipping those which have a too similar normal solves this problem (since this only occurs on those large plains), but causes an additional texture lookup in a for loop, which costs too much (and would make using a position buffer again more efficient).

Did any of you experience a simillar problem or have ideas of how to solve this smarter?
Thank you very much :)

**Tags:** opengl, shader, compute-shader, ambient-occlusion, ssao

> **Comments:**
> **username_1**: Are you offsetting the depth positions with a bias value? And are you using any depth clamping? And what is your depth slope factor?  
> **username_0**: @username_1 yes i tried to increase the bias already, but that just shifts the banding along the view-z-axis and of course lowers the quality of the remaining ao. No i don't use depth clamping. If you mean the fov, its 70 degree  

---

## 1 answers

### Answer by username_0 on 2022-03-07. Score: 2 | Accepted answer

For anyone having the same problem:
I calculated the normalized texture coordinates by

```
vec2 imgSize = imageSize(img_output);
vec2 normtc = vec2(gl_GlobalInvocationID.xy) / imgSize;

```

this is of course wrong, the last line should be:

```
vec2 normtc = (vec2(gl_GlobalInvocationID.xy) + vec2(0.5)) / imgSize;

```

since we want to sample the center of the pixel. This solved the problem for me.


---

