I try to find a solution on the french group Blenderlounge, but nobody have the answer.
I work in the industry of the archviz. Often i use the object mapping to have textures on the 3d models.
But i can’t rotate a texture in Blender in this mode. I must use Photoshop to rotate them or make a unwrap in cube projection and put the mapping in UV.
What do you think about this? There is a solution in Blender to rotate a texture with the object mapping?
might depends also on the projection use
this is a cube in object mode so it will try to map from the center of the cube !
it is not that simple need some work to get what you want
for a cube like that there is a modifier that will do the 3 planes unwrap
but not certain about the rotate
better way assign one mat per face then use the Mapping to do the rotation!
RickyBlender’s suggestion of mapping each face will give you more control, but if you are just wanting to match up the sides with the top, you can simply rotate the object in edit mode, or rotate it 90* in object mode and apply rotation.
Now I understand better what pass on the textures.
Actually I can’t imagine your solutions in my workflow because they are more complicated than to make a projection in cube projection and have the textures coordinates in UV. RickyBlender’s solution take the time and need 3 materials with the assigment. CgCody’s solution loose the result when you apply rotation on you model (often needed).
There is’nt a possibility to just rotate the image in Blender without changing the method of assigmend on the model?
Yes, but the next step is to rotate your wall in object mode. Because you need to have the wall in the right direction.
I think in Archviz production that’s a big problem to can’t easily rotate a material. Do you think it’s possible to create a addon that’s make the result I search?
Because we can’t have a shader library in double with 0° and 90° images and when you habe the PBR workflow with a lot of map solutions are limited.
I see your point. Does your pipeline require that you apply all object rotations? If not, problem solved, just don’t apply transforms. The issue is that object mapping maps to the objects local co-ordinates, so as soon as you apply the rotation, it’s now aligned to the world co-ordinates.
I suppose it would be possible to isolate and only apply the rotation to part of the object via nides, but I haven’t tried something like that.
I think I get it. The coordinates are mapped to a box so xyz coordinates are mapped to x and y. Then when the xyz coordinates are rotated, the wrong ones get mapped to xy. It’s a bug. It should be possible to redo the box mapping proceduraly with nodes. That should fix it. If I am not mistaken, which may be.
It’s not a bug. It’s a limitation of object space mapping.
When you rotate that mapping cube 90* on Z, the X and Y are still mapped to the same vectors, but they’re now at a right angle to them, so only the first column of pixels get mapped across those faces.
I would consider it a bug. It is possible to rotate the image in it’s coordinates and it is possible to rotate object space coordinates. Correct behavior is possible to achieve.
It is not a bug nor is it sensible to modify the object or assign multiple materials.
Default mapping for images is to interpret u and v as x and y, or r and g. If you want the image projected from a different side, just swap the channels around. Whatever face has the mix between red and green will show the texture projected on it.
In particular, if you want a texture projected on to vertical faces from both x and y, you can mix between two texture coordinates where G increases with height and R increases with distance from the left edge. Use object normals to get your mix factor
The image is projected from all sides with box mapping. If the coordinates are rotated it stops being projected from all sides. How is it not a bug of the box mapping algorithm? It stops functioning. I am sure there is a perfectly understandable explanation behind the math, however as a function, box mapping stops functioning correctly in these circumstances. Is it not logical to consider it a bug of that particular box mapping function then?
Yes it is box mapping, but in “object space” is the key. That is going to behave differently than a box mapped object in UV space.
In object space when you rotate the mapping 90* on Z, you’re effectively rotating that virtual mapping box. But the X side of the mapping box and the Y side of the mapping box are still mapped to the X and Y sides of the mesh. Now they’re at a 90* angle to the faces they are mapped to.
The only way around this is to either rotate the object in edit mode, which effectively swaps the X and Y vectors, or swap the channels using vector separate and combine nodes as smilebags suggested.
That’s good to have more detailed explinations. Thank you!
The problem is still there. Now we talk about just one cube, but inforunately make architectural visualisation isn’t just to play with cubes. Sometimes the geometrie are more complicated. If you want to go to the edit mode to make a rotation, you need to have a pivot point to make the same invert rotation as you make after in object mode.
Actually I think we have all the knowledge to find a problem to reach the result. But imagine you teach blender to an trainee. All your model is fine, but you ask him/her to rotate the wood floor. Logically you just want to put 90° somewhere, no?
If you rotate object space coordinates it would be logical for the box mapping to take the rotation into account. It does not if I understand it correctly. It uses the original object space and that is why the result is not as expected.That is what I consider to be a bug. Does this not make sense?
