Hi, I encountered a behavior I’m not sure if it’s a bug or not. In my workflow I tend to use UV-less texturing a lot. To do this I use a combination of either generated texture coordinates or object texture coordinates with box mapping, I’m sure most here is familiar with that technique.
Anyways, it works just fine for any regular textures, no issues at all, blending works correctly and so on. But as soon as I do this with a normal map and slot it into the normal map node I don’t get the result I expected.
As it turns out the normal map node still uses the UV coordinates even when you’re using procedural texture coordinates. Depending on how the UV is mapped I get wildly different result, and If I the mesh does not have a UV map at all, the normal map node ceases to function completely and outputs nothing.
This to me seems like wrong behavior. Shouldn’t the normal map node only care about the color values that are put into it and not try and apply its own set of coordinates? Right now this defeats the purpose of using box mapping since I have to apply a UV map anyways. It just seems very odd to me and I have not noticed this behavior before.
Only the normal map node showcases this behavior everything else works just fine.
Care to include a screen shot for an example of exactly how you are using the normal map node? Also for future reference this is the sort of topic better created at blenderartists.org support section.
It’s hard to replicate but depending on how bad the UV’s are you get a terrible effect with random seams everywhere and so on. I don’t understand why the UV should matter when you’re using a procedural texturing workflow. That just seems wrong.
PS:
I want to clarify that this ONLY happens with the normal map node. If I output the contents of the Image texture node directly then it works exactly as expected. So the normal map node is for some reason re-sampling whatever is put into it depending on your UV. That is a behavior that screws with procedural workflows.
Not a bug, just hardcoded to use UV’s. Notice that there is no socket for mapping, just the list of UV’s. It is no accident.
I think you want to use the bump node instead.
In as far as bugs go that is what the tracker is for. Though again, might want to create a topic like this @ blenderartists.org first then if others confirm that it’s a bug you can check to see if someone has already reported it on the tracker, if not - report it yourself.
It doesn’t make sense to me why they would do that. It really screws over procedural workflows unless you have perfect UV’s for your mesh.
The bump node has terrible noisy artefacts in EEVEE and you don’t always have a good height/bump texture available for your project.
It just does not make sense at all why the Normal Map node would do this. It should be corrected.
I need developer input on this and I doubt I will get that at blenderartists. Else it’s just gonna be a thread that drops 10 pages deep and nobody ever sees it and the issue is never confronted.
This is simply because the Normal Map node uses Tangents (hence you can use the blue tangent space normal maps) and those tangents are picked from the UVs. Therefore the option to change the UV channel to get different tangents.
This is a nuisance for me as well but haven’t had enough energy to push this to developers as usually you’ll hear “not a bug, this is intended behavior” and you really need to fight for it to see it implemented.
I believe that if there is no UV Map you should simply generate Cube Projected UVs with scale 1.000 and hide it from the user until he/she creates a new UV Map. But such stuff is a bit of a workaround and can generate lots of problems and again, this is not a BUG! It is working as intended. You see? If you have no UVs, it’s wrong. That’s intended xD
the cubemap workaround wont work if you intend a blend between the angles. but you could use 3 different projections in your setup, instead of one generated uv coordinates, and create three different normal maps, each for one axis (x,y,z), blend the different normals (the outputs of the 3 normal map nodes) together instead of their input.
if no uvmap is present at all, then there is no way to go through a tangentspace (since there is no tangentspace) the normal you plug into the shader is in objectspace anyway. simply calculate it directly from your procedural vectorspace.
