Can anyone explain why swapping X and Y coordinates breaks box mapping?
Logically, I was expecting it to just mirror the image. It works top down but not on the sides?
$\begingroup$
$\endgroup$
$\begingroup$
$\endgroup$
The Box mapping uses the direction of the face to determine the mapping. This means that the faces parallel to, say, the Y-axis are mapped as X,Z to the image's coordinates, while those parallel to the X-axis are mapped as Y,Z to the image's coordinates.
By swapping the input coordinates in that way you are upsetting the mapping so that, say, for the faces parallel to the Y-axis are mapped as Y,Z to the image's coordinates - but since the face is parallel to the Y axis, Y is constant - so the image becomes distorted on that face (as only one axis of the image coordinates varies; the other is constant).
answered Oct 12 '18 at 6:27
$\begingroup$
$\endgroup$
Another way of looking at it is: the box mapping algorythm works only with the actual object space. It uses surface normals and their coordinates are not changed according to how you change the object space coordinates. It expects original object space coordinates and stops working correctly if it gets anything else, because it also uses normal vectors that remain the same when you change object space. You can reconstruct box mapping with nodes to be able to control normal vectors it uses as well. If you changed the noramls in the same manner as the object space it should work:
answered Oct 12 '18 at 7:11
-
$\begingroup$ I've tried this but it's still not doing what I was expecting. Although I noticed the useful Rotate Vector node group, would be useful as a built in node. $\endgroup$ – mistajolly Oct 12 '18 at 10:03
-
-
$\begingroup$ By flipping the X & Y it is mirroring the image, so in the case of your example the arrows would rotate 45 degrees. This works on the XY plane but as explained in Rich Sedman's answer it won't work on the sides of the cube. Rather naively I thought box mapping took just one plane and re projected this on all sides. $\endgroup$ – mistajolly Oct 12 '18 at 10:15
-
$\begingroup$ Yes. That is what happens because box mapping does not take your change of the object space into account. However, if you have a look, my example has the normal vector changed as well, so it works. Or you could delete the split and combine vector nodes at the beginning of Normal and Object outputs and flip the texture with the big Vector Mapping node in a frame that says 'Do whatever you want to the texture' You can just scale X by -1 for example, or as it says do whatever you want with the texture that is mapped to the box. $\endgroup$ – Martynas Žiemys Oct 12 '18 at 10:31
-
1$\begingroup$ The mapping node already has more than 9 inputs, they are crippled and nothing can be connected to them. There are great many examples where inputs like that can be very useful. The node is also the only one like that and is not consistent with the rest of the nodes. As for the number of inputs - Principled BSDF has 20 of them and it's fine. I think a very strong case can be built about the current mapping node not being logical at all. But the separate rotate translate and scale nodes are really great as well. $\endgroup$ – Martynas Žiemys Oct 13 '18 at 18:31
