Rotate procedural texture in node editor

I have a question: how do I rotate a procedural texture that is mapped using UV coordinates?
Here’s a simplified example below, where I would like to rotate the texture with other nodes to be placed at the red frame. I know that the texture can be rotated in the earlier nodes, but for what I have in mind it needs to be done after the node tree. Since it’s in UV space, I can’t seem to just use a rotation or mapping node.

Any help is much appreciated!
Rotate texture.blend (1.1 MB)

You can switch the mapping node to texture and use the Z rotation property

What happens when I rotate the texture, it changes the colours and does not rotate, so I must be doing something wrong here:

To rotate texture, it should be done after the vector and before the texture.

Use the mapping node you already have, it has to be on the left of your texture

This is as input to the texture, but I need to rotate it after the original, since I need both the original and the rotated version. And I don’t want to copy the nodes, provided I can rotate the texture after the fact.

The only way to change the placement of a texture is change the vector that control it. I don’t think there is a way after the texture.

That’s unfortunate. In Grasshopper I can use that technique to reduce computation time and the number of nodes. The idea was to rotate the texture and than mix it with a non-rotated version, but this doesn’t work.

All you need are two Vector nodes. One for rotated texture, other for non-rotated. Then you can mix them together as you wish. Everything else can stay as it is. I see no benefit in doing it the way you explained. It has zero performance impact and the addition of one single node is no overhead.

That layout does not make sense. To read what nodes do, you can start from the rightmost and spell it out : “color is a voronoi texture whose coordinates are a mix between original and rotated, blended by a checker texture”.


Actually this makes perfect sense in geometry with nodes (Grasshopper). I presume you can do this in Substance designer too.
I mean, duplicating the node tree to create both this version and a rotated version that is perpendicular to this one, that doesn’t make sense! Consider a complicated shader, you don’t want to edit each copy of the node tree seperately. Neither does it makes sense to create a input slider node tree hooked to a bunch of math nodes attached to each copied tree so you only have to edit these input sliders…

Where do you see duplication ?

You would need to duplicate the entire node tree to have
A) Texture in direction A
B) Texture A with rotation

Instead of Tree A > Rotation > result B.

I understand what you mean. To avoid the duplication of the voronoi texture you use the checker texture as a mask to blend the rotated and the unrotated coordinates and feed those into the texture:

You need to understand that the texture nodes aren’t outputting images that have transform attributes. They are simply functions that take a vector as input and give you a color/value in return.

In addition: colors, values and vectors are basically arbitrarily interchangeable.
When plugging a white color into Vector rotate the node will read white (RGB: 1.0, 1.0, 1.0) as the vector (1.0, 1.0, 1.0) and then perform a rotation on that vector.
Therefore rotating the output of the texture node afterwords to rotate it doesn’t make much sense.
The manipulations of the transformations of the procedural textures rather have to be done on their input coordinates.

It can take some getting used to, when coming from other systems, since the order of operations sometimes seems reversed, but it is logically consistent and pretty powerful in the way its set up.


I’m sorry, this is confusing. What does A stand for ?
I thought the node tree above would help. Doesn’t it solve your problem ?

Now this makes sense to understand why it’s the way it is, thanks. Maybe there should be a new node capable of transforming a procedural texture after the fact to make things easier and to simplify the node tree. We’ll see.
I also think the order is reversed for geometry nodes in certain operations.

@Hadriscus it solves the rotation by changing the input first. Thing is I would like to do it last for the reasons stated in the opening post.

You’re not stating any reason, you’re just saynig “I would like to do it last”. The thing is it’s not how it works. As long as you get your results, why would you care where it is done ?
Did the node tree I supplied help with your issue ?