<p>I am generating a normal map for a texture for use in a PBR shader.  I have a map for the diffuse texture, and I am estimating the normal at each point using the derivative of the texture's brightness.  I store the result in a new texture and read the values out of it as a standard normal map.</p>
<p>This is the method used by tools such as <a href="https://www.smart-page.net/smartnormal/" rel="nofollow noreferrer">SmartNormap</a>.  It works quite well and I am happy with the quality of the result.</p>
<p>However, there is a caveat.  In the same shader, I am also using a <a href="https://www.shadertoy.com/view/MdyfDV" rel="nofollow noreferrer">hex tiling algorithm</a> to generate an infinitely repeating, seamless output.  I currently run this algorithm on both the diffuse map as well as the normal map.  Since it is an expensive algorithm, this is causing a significant perf impact.</p>
<p>To try to mitigate the perf impact and avoid the double lookups, I had the idea of generating the normal map on the fly within the fragment shader based on derivatives of the fragment colors.  I have created an implementation that looks something like this:</p>
<pre><code>float diffuseMagnitude = length(diffuseColor);
float dDiffuseX = dFdx(diffuseMagnitude);
float dDiffuseY = dFdy(diffuseMagnitude);

float computeNormalBias = 0.1;
vec3 mapN = normalize(vec3(
  dDiffuseX,
  dDiffuseY,
  1.0 - ((computeNormalBias - 0.1) / 100.0)
));
mapN.xy *= normalScale;

normal = perturbNormal2Arb( - vViewPosition, normal, mapN, faceDirection );
</code></pre>
<p>Here is what the results looks like for that.</p>
<p>Before:</p>
<p><img src="https://ameo.link/u/acj.png" alt="" /></p>
<p>After:</p>
<p><img src="https://ameo.link/u/ack.png" alt="" /></p>
<p>You may have to expand the images to see the impact in more detail.</p>
<p>This does work and I find it to be a great improvement, but there is a rather severe issue.  Since these derivatives are computed in screen space, the world space distance between pixels can become quite large at higher distances and sharp angles of incidence with the camera.  This results in severe aliasing when moving in certain directions.</p>
<p>Demo video: <a href="https://ameo.link/u/bcafbfde12486f95388b5c448db2c1dbb037f9b4.mp4" rel="nofollow noreferrer">https://ameo.link/u/bcafbfde12486f95388b5c448db2c1dbb037f9b4.mp4</a></p>
<hr />
<p>I think I understand the reason this issue issue is happening, but I don't know how to solve it - or if it's even possible to solve it.</p>
<p>Normally, I'd solve aliasing by oversampling, but there's no way to really oversample when using the <code>dFdx</code>/<code>dFdy</code> functions that I know of.</p>
<p>I know that my use of that expensive anti-tiling algorithm really limit things but it's very important to my use case and I can't do without it.  If I am unable to find a solution with this dynamic normal generation idea, I will probably go back to pre-generating normal maps and doing the double lookups and then turning it off in low detail mode or something similar.</p>
<p>If anyone has any ideas or pointers, though, I'd love to hear them!</p>

CC BY-SA 4.0
2022-09-04T16:06:43.683Z
You could try `dFdxFine`/`dFdyFine` to see if those give you better results. However you might also be interested in this recent paper: [Practical Real-Time Hex Tiling](https://jcgt.org/published/0011/03/05/) which is supposed to be faster and addresses normal maps in particular.
Nathan Reed
CC BY-SA 4.0
2022-09-05T01:32:57.737Z
Oh wow, that paper is recent indeed!  Does seem to be improvements/continuations over the version I'm using. Tyvm for pointing that out!

wrt. the fine versions of those derivative functions, I gave it a try but didn't have much impact.  I've figured out a decent solution, though, by packing texture data as grayscale into the R channel and putting normal map in the GBA channels.  That works out alright for what I'm doing.

Ty again for the info and suggestion!!
Ameo
<glsl><antialiasing><normal-mapping>
Is it possible to reduce aliasing in derivatives used to estimate normals from a texture?
Ameo
# Is it possible to reduce aliasing in derivatives used to estimate normals from a texture?

(Asked by: username_0 on 2022-09-04)

I am generating a normal map for a texture for use in a PBR shader. I have a map for the diffuse texture, and I am estimating the normal at each point using the derivative of the texture's brightness. I store the result in a new texture and read the values out of it as a standard normal map.

This is the method used by tools such as [SmartNormap](https://www.smart-page.net/smartnormal/). It works quite well and I am happy with the quality of the result.

However, there is a caveat. In the same shader, I am also using a [hex tiling algorithm](https://www.shadertoy.com/view/MdyfDV) to generate an infinitely repeating, seamless output. I currently run this algorithm on both the diffuse map as well as the normal map. Since it is an expensive algorithm, this is causing a significant perf impact.

To try to mitigate the perf impact and avoid the double lookups, I had the idea of generating the normal map on the fly within the fragment shader based on derivatives of the fragment colors. I have created an implementation that looks something like this:

```
float diffuseMagnitude = length(diffuseColor);
float dDiffuseX = dFdx(diffuseMagnitude);
float dDiffuseY = dFdy(diffuseMagnitude);

float computeNormalBias = 0.1;
vec3 mapN = normalize(vec3(
  dDiffuseX,
  dDiffuseY,
  1.0 - ((computeNormalBias - 0.1) / 100.0)
));
mapN.xy *= normalScale;

normal = perturbNormal2Arb( - vViewPosition, normal, mapN, faceDirection );

```

Here is what the results looks like for that.

Before:

![](https://username_0.link/u/acj.png)

After:

![](https://username_0.link/u/ack.png)

You may have to expand the images to see the impact in more detail.

This does work and I find it to be a great improvement, but there is a rather severe issue. Since these derivatives are computed in screen space, the world space distance between pixels can become quite large at higher distances and sharp angles of incidence with the camera. This results in severe aliasing when moving in certain directions.

Demo video: <https://username_0.link/u/bcafbfde12486f95388b5c448db2c1dbb037f9b4.mp4>

---

I think I understand the reason this issue issue is happening, but I don't know how to solve it - or if it's even possible to solve it.

Normally, I'd solve aliasing by oversampling, but there's no way to really oversample when using the `dFdx`/`dFdy` functions that I know of.

I know that my use of that expensive anti-tiling algorithm really limit things but it's very important to my use case and I can't do without it. If I am unable to find a solution with this dynamic normal generation idea, I will probably go back to pre-generating normal maps and doing the double lookups and then turning it off in low detail mode or something similar.

If anyone has any ideas or pointers, though, I'd love to hear them!

**Tags:** glsl, antialiasing, normal-mapping

> **Comments:**
> **username_1**: You could try `dFdxFine`/`dFdyFine` to see if those give you better results. However you might also be interested in this recent paper: [Practical Real-Time Hex Tiling](https://jcgt.org/published/0011/03/05/) which is supposed to be faster and addresses normal maps in particular.  
> **username_0**: Oh wow, that paper is recent indeed!  Does seem to be improvements/continuations over the version I'm using. Tyvm for pointing that out!  wrt. the fine versions of those derivative functions, I gave it a try but didn't have much impact.  I've figured out a decent solution, though, by packing texture data as grayscale into the R channel and putting normal map in the GBA channels.  That works out alright for what I'm doing.  Ty again for the info and suggestion!!  

---

## 0 answers

