Has anyone figured out how to get UVless box mapping to work with tangent space normal maps?

Hi there! I’m fairly new to Blender and am loving it so far!
I was wondering, as the thread topic implies, whether anyone has gotten correct normal map directionality using mapping types other than UV mapping. In the screenshot above you can see the issue - each projection works for laying down the normal texture, but the way the normal is being read means it looks rotated/inverted depending on the projection. I think -x, -y, -z are “backwards” and +x,+y,+z are correct.

It seems for tangent space normal maps, looking at the documentation, they intend for the texture input vector to always be UV because whatever’s happening under the hood uses the uv information to derive the normal map directionality. I was wondering if anyone has been able to re-derive the tangent basis using hack node chains or if there was some other way to get normal maps to not invert along certain projections when using box mapping. Alternatively ,as anyone found a way to apply a normal map to a model in a UVless way? I’ve tried out bump mapping and, while it fixes the inversion issue, the banding is pretty terrible so I don’t think that will work.

Any Blender gurus willing to school me on this? Thanks!

I’m not sure if it will work, but you could try triplanar mapping which is a manual setup of box mapping. With that you plug in the texture for each of the cardinal direction, which would allow you to control swizzle coordinates independently.
Make sure to use cubic interpolation and full range for 8-bit bump maps. If that’s not enough to get rid of stepping at reasonable views, make them 16-bit instead.

@CarlG Thanks for the help! I’ll try out the manual triplanar projection today and see if i can rotate each projection be correct WRT TSNormals. As for bump, I’ve been getting the banding issue with 32 bit exr heightmaps derived directly from geometry, and if I apply the same map as a displacement it’s perfectly band-less. Setting interp to cubic helped, but I was reading about the bump node and it looks like bump is inherently pixelated because the normal direction is derived using each pixel with its neighbours, so the “banding” is actually just chunky pixelation from how the bump is derived from height. Unless they add a higher quality bump node that allows a larger grid of pixel sampling to gather normal, (ex 4x4 rather than 2x2) I think the bump node might be doomed to be banded? Or I could just be totally wrong, have you been able to use a bump map with an EXR and have it be perfectly smooth when you look closely?

Where is your normal map? If we will see, we will can say anything.

I tend to use math nodes instead of maps when I need completely stepfree bumps at reasonable closeups. I use maps when I don’t care about the steps because they’re mixed with other normal modifications, or they wouldn’t be visible due to reasonable zoom levels. If you’re obsessed with insane closeups, then you’re forced to use normal maps or very high resolution 16/32 bit bump maps.

2x2 isn’t really bad. You have to consider that the 2x2 samples aren’t actually individual texels, but filtered texels that actually include data from a larger group of texels. (Generally speaking, a texture lookup is actually a box-blurred sample of a rectangular subsection of the texture, where the size of the box depends on your image resolution, your FoV, the camera-space true normal, and the depth to the sample.)

The main problem with bump mapping comes about from magnification, when that filtering stops playing any relevant role. So you can have a bump map that looks fine from a particular distance, but zoom in and it gets all pixellated (possibly, depending on the bump map, all banded.)

The solution to that isn’t so much increased bit depth, but increased image resolution. However, there’s always going to be a limit to that-- there’s always going to be some zoom level where you get magnification artifacts, even with an 8k texture.

1 Like

Stepping occurs when there is not enough bit depth to create the angle for the distance. In a normal map, you only need a slightly more or less red or a more or less green channel to create any angle offset from the surface normal. On an 8bit bw bump map, the same angle is created with a gradient. If that gradient is spread across more than 255 pixels, somewhere there will be a step. It’s the same reason we use dithering on a screen gradient - 255 levels does not cover 1080 pixels smoothly.

1 Like

Right. I understand that. However, Liam talked about getting artifacts with 32 bpc float .exr textures. (If I understand correctly.)

Stepping on 32 bit float textures is not a bit depth issue. But it may be a resolution issue. At a sufficient zoom, even 32 bit textures are going to get stepped, as adjacent samples stop sampling different texels.

1 Like

Ahhh, thank you both, @bandages and @CarlG makes a lot more sense now. So bump maps are texture resolution & bit depth limited (because of the shader filtering going on), I guess procedural nodes don’t have the pixelation problem with bumps because they aren’t actually sampling a texture with pixels, their functions are continuous and have as much bit depth as you want.

And yes, I was using 32 bit displacement heightmap for the input of the bump, captured from real geo, so the stepping was (almost) certainly not from bit depth stairstepping. I’ll mess around with bit and post my learnings!