Box Mapping a Normal Map looks different whether object has UV map or not #124656

New Issue

JanvandenHemel · 2024-07-13T13:00:25+02:00

JanvandenHemel commented

2024-07-13 13:00:25 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 552.22

Blender Version
Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: e1743a0317bc
Worked: (newest version of Blender that worked as expected)

Short description of error
Hey, so when I use Generated coordinates and Box mapping, my Normal map has a column of seemingly flipped Normals on the front. This is with any primitive object, like a UV sphere. When there's a UV map, everything looks fine. Without it, there's this flipped Faces column. It's Generated coordinates and box mapping in both cases, so (in my understanding) it should just look the same.

Exact steps for others to reproduce the error
Please see attached file. It's more visible when using an HDRI in either Eevee or Cycles.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 552.22 **Blender Version** Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: `e1743a0317bc` Worked: (newest version of Blender that worked as expected) **Short description of error** Hey, so when I use Generated coordinates and Box mapping, my Normal map has a column of seemingly flipped Normals on the front. This is with any primitive object, like a UV sphere. When there's a UV map, everything looks fine. Without it, there's this flipped Faces column. It's Generated coordinates and box mapping in both cases, so (in my understanding) it should just look the same. **Exact steps for others to reproduce the error** Please see attached file. It's more visible when using an HDRI in either Eevee or Cycles.

Box Mapping Normal Map Bug.blend

22 MiB

JanvandenHemel added the

labels 2024-07-13 13:00:26 +02:00

Martijn Versteegh commented

2024-07-13 14:52:00 +02:00

After a lot of back & forth on the chat, I've come to the conclusion that this is just an inherent limitation of the tangent space. I'm not exactly sure how the x and y directions of the tangent space are generated in the absence of a UV map but it looks like a default 'uv' based on polar coordinates is used where the interpolation from 1.0 back to 0.0 creates a flipped tangent space in that segment of the mesh.

On some normal maps it seems to work ok, but it turns out this is just because the seam gets hidden in the pattern.

The attached picture shows the effect for a constant normal pertubation. Showing very clearly that the tangent space is flipped in the segment where the polar coordinates flip.

I'm tempted to close it just as 'known limitation' but I'll leave it open for now in case someone knows of some trick to get the tangent space be defined in box-mapped terms as well.

After a lot of back & forth on the chat, I've come to the conclusion that this is just an inherent limitation of the tangent space. I'm not exactly sure how the x and y directions of the tangent space are generated in the absence of a UV map but it looks like a default 'uv' based on polar coordinates is used where the interpolation from 1.0 back to 0.0 creates a flipped tangent space in that segment of the mesh. On some normal maps it seems to work ok, but it turns out this is just because the seam gets hidden in the pattern. The attached picture shows the effect for a constant normal pertubation. Showing very clearly that the tangent space is flipped in the segment where the polar coordinates flip. I'm tempted to close it just as 'known limitation' but I'll leave it open for now in case someone knows of some trick to get the tangent space be defined in box-mapped terms as well.

Screenshot from 2024-07-13 14-42-58.png

557 KiB

Martijn Versteegh commented

2024-07-13 16:34:06 +02:00

It looks like the normal map node first generates radial UV coordinates in the absence of a UV map, and then generates a tangent space based on the UV coordinates interpolated between the vertices.

If you 'manually' reproject the normals from the normal map directly to a radially generated tangent space , as demonstrated in the attached blend the problem more or less goes away.

It should be possible for the 'normal map' node to just always calculate the tangent space this way (in the absence of a UV map) I think.

It looks like the normal map node first generates radial UV coordinates in the absence of a UV map, and then generates a tangent space based on the UV coordinates interpolated between the vertices. If you 'manually' reproject the normals from the normal map directly to a radially generated tangent space , as demonstrated in the attached blend the problem more or less goes away. It should be possible for the 'normal map' node to just always calculate the tangent space this way (in the absence of a UV map) I think.

manuallyreprojectednormalmap.blend

3.7 MiB

Richard Antalik commented

2024-07-15 09:49:52 +02:00

@Baardaap I barely follow what you said, but I would agree, that such manual setup should not be necessary to use the node. So, I will confirm and let module decide, whether this is something that can be improved.

Also not quite sure what module this would belong to. There are some differences between Eevee and Cycles. None With the file you have provided, these are even bigger.

@Baardaap I barely follow what you said, but I would agree, that such manual setup should not be necessary to use the node. So, I will confirm and let module decide, whether this is something that can be improved. Also not quite sure what module this would belong to. There are some differences between Eevee and Cycles. None With the file you have provided, these are even bigger.

Richard Antalik added

and removed

labels 2024-07-15 09:52:00 +02:00

JanvandenHemel commented

2024-07-16 15:18:05 +02:00

Okay, so in the end it turns out, that the issue indeed was with the Normal map texture itself. At some point, it was probably saved incorrectly. Interestingly, you can add a Mix Color node to it, before the Normal Map node, and set it to Add and the value to 1. This more or less fixes the issue visually (though you can still faintly see that seam). But of course the real "fix" is just re-baking the Normal map and paying attention to making sure it gets saved correctly in terms of color spaces. My sincere apologies for wasting your time on this. And full credit to Jim Morren for the Mix Color node solution. Apparently this is a common issue he runs into this when importing game textures.

Drum_mulitplied.png

4.9 MiB