Normalmap artefact with identical UV coordinates (perturbNormal2Arb)

Hi everybody,

First i want to apologize for my poor english…
So, i work on a 3d model (not created by myself).
This is an embossed curved text for a logo.
I don’t understand why, but i’'ve a good render like you can see in pictures below but when i add a normalmap, a lot of white dot artefact appears ! I tried with a lot of differents normalmap, but no change ! The artifacts seem to be due to the angle of view. (i post the wireframe to help you to understand.)
I checked the normal (ok), test with a lot of different normal map (same result)…

Please somebody could help me cause it’s an really important project and i tried everthing to solve it…

The pictures to understand :

Do you mind demonstrating the issue with a live demo?

This could be a shader precision error. Also a bad light, camera or material configuration could cause these artifacts. The following thread at the Unity forum is probably related:

Hi Mugen87,
thanks for your response. I found the reason of it this night. For your information, it was due to the mapping unfold. Some point was overlapping other one. I did the correction and the artefacts desappear !

Thanks again for your investment in this forum !
Have a good day !

1 Like

Hi Mugen,

In fact, I just found another reason for this and I would like to know if someone could help me.
I discovered that when you use a 3d model with identical UV coordinates for each vertex, and you add a normal texture that is fully filled with average values (128,128,255), you get the results of the cube below.
Is it a bug of THREE JS ? Is there a way to modify the calculation code so that in this case, the rendering engine doesn’t take into account the value of the normal texture ?
I’m attaching a gltf file of the cube and just add a normal map filled with (128,128,255) to see this reaction .
For your information, i use MeshPhysicalMaterial.

Thanks in advance to those who could help me

The gltf to test : Cube.gltf (3.2 KB)
And the normal to use :

Just a precision, we obtain the same bug with a model compress with gltf pipeline due to the textcoord compression…

I continued my investigation. It’s seem’s to be due to the perturbNormal2Arb that in this cas return bad normals…

Do you need these identical UV coordinates and the empty normal map? I’m not sure how three.js could realistically detect and handle this. It might be worth trying to exporting the glTF from Blender with the “Geometry → Tangents” option enabled.

1 Like

Hi donmccurdy,

Unfortunately, the project I’m working on is going to receive 3d models that we don’t know. And since the normal textures will be generated in real time, I can’t avoid this case. The idea would be to find a solution so that it doesn’t treat the texture as normal in this case but I don’t really know how to do that…

This is the same result with tangent in export.

It seems to be a bug in this case in the perturbNormal2Arb function when S and T is normalize with very close UV. i found a topic aboiut it :
but i don’t know how exactly it will be possible to correct that or find a solution to avoid this case by modifying this function… I tried the solution with the conditionnal statement of this topics but it doesn’t solved in all case…

My skill are not enough to find the solution but this problem is a real stop on my project…
An idea ?

Thanks to you !

perturbNormal2Arb requires that UVs form non-degenerate triangles —broken UVs are going to give broken results, I don’t think it’s possible to assign a normal map to a material and also tell that material to ignore the normal map without manually patching the shader.

You could avoid using perturbNormal2Arb and compute tangents offline with BufferGeometryUtils.computeTangents, then set material.vertexTangents = true. That might help, but I’m not sure if it allows degenerate UVs either. :confused: