I’ve recently switched to Blender (from C4D) and made my first scene over the holidays. I have a really, really weird shading issue in one of my materials in this scene. I know how to fix it, that’s not the issue. What I do not understand is how and why this happens. Either I do not understand Blender and Cycles as much as I think I do, or this is a bug.
So please enlighten me!
The issue:
There are some polygons on a specific mesh in the scene that have completely broken normalmapping. The material is nothing special, the topology of the mesh is fine as far as I can tell (at least not so bad that it should induce errors like this).
The solution: simply unwrapping the mesh. And I mean super basic righclick → unwrap on the entire thing.
What am I missing here? How is UV-Unwrapping in any way connected with Triplanar Mapping? In every renderengine I’ve used so far the UVs are completely irrelevant for the Triplanar Mapping. I mean… that’s the entire point?
Can somebody enlighten me what the technical details are here? Or is this simply a bug?
Of course I’ve also (tried to) attached a reduced version of the scene… if you want to take a look. New users can’t attach scenefiles unfortunately, so here’s a downloadlink: DOWNLOAD
thanks for the reply. Unfortunately no, that’s not it. I’ve tried that already. The texture shifts a bit (of course) but the issue still remains. With Generated it looks like this:
As I said, I can’t see a reason why it would do this, other than this maybe being a bug! As far as I know Triplanar Mapping has nothing to do with UV Mapping.
How curious.
I just opened a new project with an elongated cube. Added a normal map with box mapping. And deleted the default UV map. BOOM! - got the same issue.
You don’t even need to unwrap per se, it’s enough to just add a new UV map through Object Data Properties panel Oo
Maybe it has something to do with that UV map field in Normal Map Node?
Generally, if you use normal maps you should set the colorspace to non color within its texture node.
Beside that your problem starts cause your uvmap is a bad one, it contains distorted faces. The ones that dont work have are collapsed ( area =0) in the uv map.
You said you dont need the uvs. Thats partially correct. A triplanar mapping does not need stored uvs as some other reliable system is used instead if its now worldspace coordinates or a bounding box driven value.
But the problem with your setup lies in the normal map node. You are using the tangent space there. You should have better used Object Space or World Space. Tangent space utilizes the UV Map. Thats where your bad uv mapping comes into play and everything goes wrong.
Oh man, that is exactly the kind of explanation I’ve been looking for, thanks for that!
Generally, if you use normal maps you should set the colorspace to non color within its texture node.
It is.
You said you dont need the uvs. Thats partially correct. A triplanar mapping does not need stored uvs as some other reliable system is used instead if its now worldspace coordinates or a bounding box driven value.
But the problem with your setup lies in the normal map node. You are using the tangent space there. You should have better used Object Space or World Space. Tangent space utilizes the UV Map. Thats where your bad uv mapping comes into play and everything goes wrong.
That’s where an additional question comes up, if you don’t mind. How come I’ve done this exact setup for years in other render engines (Octane, Redshift, Corona) and I never had this issue, no matter how bad the UV’s were? There’s tons of projects where I had way worse topology and way more complex meshes and never touched the UVs in any way, but it still always worked perfectly. Because as far as I understand Triplanar does nothing else but a box project with some fading over a certain color range that is coming from the world space normals of the mesh.
Now when it comes to the normal node, my technical understanding thus far is (not only in Cycles but in everything else as well) that the “Tangent Space” setting is only there to tell the system how to interpret the texture that is fed into the node. If it’s tangent space normalmap I set it to Tangent Space, if it’s a world space normalmap I set it to World Space, etc. And as I expected, changing this value in the nodegraph made everything look awful which makes sense.
I still just don’t get how the UVs have any impact on a texture that is projected via Triplanar, especially since the advantage of tangent space normalmaps is that they don’t care what they’re projected on, since they’re relative to the geometry tangents.
Well these are simply two different things. The one thing is to map a 3dimensional position to a 2dimensional one and that allows to determine the color. So your texture space axes are called u ad v and lets say we use the worldcoordinates, take the vectors components that make sense for the projected view and a modulo to get the 3dcoord turned into a 2d coord in a range 0…1 per component.
And yeah thats why you never need stored uvs for a triplanar mapping its extracted from the vertex positions directly.
The other thing is how a color value has to be interpreted. And for tangent space blenders node internally needs the uvs. Its needed for the calculation of the tangents and bitangents. Whats still left is that the boxmapping is still treating it as a std color, so the axes encoded in color wont be adapted.
The normal maps node takes UV as input, it’s the black field under Tangent Space in your screenshot.
You can select different UV maps here, and if it’s not set it will fall back to the active one.
When you use Box mapping, it’s messed up because it tries to map the colors from the texture using the UV. That can sometime give a result that seems to work(you get some bumps) but generally it will respond badly to some camera angles or lighting in the end.
Another thing is , ask yourself what append to the normal maps values when they are blended by the box mapping ? As it’s vectors it will give some artifacts because you can’t mix them using transparency. Same with previous comment, it can give the impression that it’s working in some cases, but at some point you can get lighting artifacts.
If you really want to use box mapping you can use a bump/displace map plugged into a bump node and you won’t have to unwrap.
I don’t know why it worked in Octane or Redshift, they either do something really clever, or it just gives the impression that it works but it’s as broken as here… (As said, sometime it’s not working
in a more subtle way)
This video explain a bit the relation between UV and Normal, not the most straightforward explanation, but maybe it will help a bit …
Thanks a lot to both of you. This has been very enlightening and I was indeed wrong… it happens in Redshift as well. I’ve not tried other renderers though, but I assume it will be the same for all.
What’s interesting is that in Blender it’s very very obvious when this happens but in my small test with Redshift I had to really, really take a close look at the seams to even notice this effect. However, these artifacts that happen when you rotate the UV also happens in both of them, equally as bad in Redshift.
Oh well, another case of “you never stop learning in 3D”
Yes , in some cases it behaves quite naturally ( in blender too) , until some point were you may realize that the lighting is wrong or other issues.
So it’s possible sometime that it goes unnoticed, you’ve found a particularly good example with your scene !
Just a note, I had another look at your setup. And the tangent space normal map mode also works without an uvmap in the uvmap list of the object, that was what made me come back and have a look at it again. Just make sure that its field is not still filled with the old uvs name, cause that also breaks it.
Be careful with that. Sometimes (at least in the past) something could appear to work, but when it was used as an asset later on it would fail miserably. While working with it, it might have had useful data going into coords. But used as an asset and it doesn’t get connected, you could get “garbage data” from an unconnected input socket. Kinda why we use a dummy bump map node in our own custom PBR setups, it somehow fixes nonexistent garbage data going into it to something that just outputs nothing. Sometimes nothing is better than garbage
Thanks, good to know. It indeed did behave strange here and there. So I wrote a custom triplanar shader that does all by itself, it is not in need of uvs and works with tangent space normal maps. Quite happy with the results so far, but its still work in progress.
