I'm working on a procedural wood texture, and it's become clear that I don't understand cycles vectors at all :( I'm hoping someone will see an obvious problem or at least point me to a good resource for learning about vectors in details.

I used this post's answer to create a wood texture node, and I'm using it to generate my rings. The issue is that the texture doesn't move with the object. Moving an object with this material applied is like cutting the object out of a different section of the same log.

Below is a picture of two objects sitting near center followed by a picture of the same two objects moved 5 units along the X axis.

Initial PositionsInitial Positions

New PositionsNew Positions

I expect this issue is caused by one of the three vectors (or a combination of them) that are involved in the wood texture node. Below is a picture of the noodle. Any of the Less/More or PBR nodes can be ignored for this post. They are convinence node groups I made by following the Blender Guru PBR tutorial.

In the main noodle, we care about the blue node and the two vectors feeding into it: enter image description here

Entering that node, we can see how it works. The distance node is used to calculate the distance between the center of the texture (core of the log the wood was cut from) and the surface of the object. enter image description here

The third vector I mentioned is hidden inside the distance node, and I think it is intended to represent the objects 3D center or something like that. enter image description here

Try It Yourself!

Here is a link to the full blend file.

  • 6
    $\begingroup$ can you upload your blend file? I believe object_info->location is the world space location of the object, so obviously your calculations are dependent on the world-space location of the object. Have you tried using texture_coordinate->generated instead? $\endgroup$ Commented Apr 20, 2017 at 3:54
  • 3
    $\begingroup$ Was about to mention the same, I think I've seen Location sockets being used on several places under the nodetree. Those a scene coordinates in world space, so whatever they control will vary depending on where the object sits in 3D space. $\endgroup$ Commented Apr 20, 2017 at 4:18
  • 2
    $\begingroup$ Yep - Location and Position and also a Vector Tranform from Object to World are all using world-space coordinates. To make the objects consistent regardless of location and orientation/scale would need to use local coordinates such as Object. However, in itself this would mean they would have identical wood grain. To avoid that you would need to use something like Object Info Random to generate a 'seed' for each mesh. $\endgroup$ Commented Apr 20, 2017 at 6:19
  • $\begingroup$ I haven't had a chance to work on this since these comments, but I wanted to thank you for them instead of just leaving you all hanging. @DavidJeske: I've added a link to the blend file to the end of the post. $\endgroup$ Commented Apr 20, 2017 at 20:11
  • $\begingroup$ @RichSedman: The Vector Transform only applies to the grain, and isn't important to this post, but you're absolutely right. I've muted it for now. It was a failed attempt to associate the scale of the grain with size in blender units instead of having to rescale for each scene. Also, I will totally add Object Info Random once I get this vector issue sorted out. $\endgroup$ Commented Apr 20, 2017 at 20:12

2 Answers 2


The problem you are having is that the two inputs to the Wood Rings Texture are two world-space points that the "core" of the wood passes through.

You are currently supplying a world-space point (the object location, aka center), and a normal vector. However, the normal vector is being used as a point, not a vector. As a result, you are defining a line which passes through the object-center and a point within 1 unit of the global origin.

One part of the solution is to convert the calculations into object space, making these two core endpoints object space coordinates. This can be done by going into the distance node and replacing Geometry->Position with TextureCoordinate->Object. This supplies the object-space position of the texel to the distance calculation.

using object-space distance calculation

Then we need to remove the object position, because the core-definition points are now in object space. We can define core-origin as an arbitrary x,y,z point in object space. Further, the normal node (aka core orientation) needs to be added to the core-origin to create the second core-endpoint.

create two object space core endpoints

Here is a fixed blend file.

This solution is a bit limited, in that it has only one core orientation per shader, and we'd prefer to have one per object instance.

One alternative is to use script nodes to read the object positions of empties, which can be created per object instance.

Another alternative is to randomly generate core orientations per object.

  • $\begingroup$ Thanks for the work you put in. This solution helped me understand what's going on with the center line a lot better. The info you gave me and some info from another post (link below) has helped me to redsign this texture's input vector. Other post: blender.stackexchange.com/questions/65801/… $\endgroup$ Commented Apr 23, 2017 at 18:26
  • $\begingroup$ Note: This solution fixes the translation issues, but rotating the object still causes the texture to shift. $\endgroup$ Commented Apr 23, 2017 at 18:28
  • 1
    $\begingroup$ Good find. Yes. To sop that, the orientation of the line needs to be transformed by the object rotation. I'll look at this today. $\endgroup$ Commented Apr 23, 2017 at 19:21

Ok, thanks for all the help! I've managed to fix the problem. I still don't fully understand these vectors, so please comment on anything I say that shows a misunderstanding of how they work.

The below image shows the new noodle. I left it in groups so it'd be easier to see what's going on, but all three of the new groups should be combined into a custom node just like the original blue node they've replaced.

enter image description here

I think what I've basically done is to define the object's local Z-axis as the core line. That means the rings are centered around the object's 3D-center along the Z-axis. The mapping node allows you to move that center line around manually.

The reason I didn't just make this change inside the existing node is because the distance can be calculated much more simply, as shown in the Distance From Core group. The new setup puts out the exact same texture as the broken one for objects at the origin and for tightness values of 1/3 of the original.

Fixed Blend

Here's a link to the fixed blend file.

  • 1
    $\begingroup$ By calculating the distance more simply, you lost the ability to have the core orientated at any angle. Now it must always be along the Z-axis. Though I do think your approach of using object-space coordinates is better. I don't see any easy way to transform the word space normal orientation by the object rotation matrix. $\endgroup$ Commented Apr 24, 2017 at 5:52
  • 1
    $\begingroup$ I updated my answer to use object-space core locations, so now the core can have any position and orientation and it handles object translation and rotation. $\endgroup$ Commented Apr 24, 2017 at 6:10
  • 1
    $\begingroup$ ...I just realized both of these solutions are a bit limited, because you can only have one core orientation per shader, when you'd really prefer to have one per object instance. One solution to this is to use empties to specify the core orientation, and have one set of empties per object. blender.stackexchange.com/questions/26388/… - another solution is to randomly generate core orientations per object. $\endgroup$ Commented Apr 24, 2017 at 6:18
  • $\begingroup$ ohh, and it's kind of weird that i spent a bunch of time to help you solve your problem, and then you selected your own answer instead of mine. you didn't even uptick my answer. cest la vie $\endgroup$ Commented Apr 24, 2017 at 6:35
  • $\begingroup$ @DavidJeske: At the time I posted my answer, you're post was still incomplete, so I couldn't flag it as the answer. (Though I did forget to mark it as useful, which I've fixed now.) With the rotation issue fixed, I've marked your post as the answer because it fixes the core issue by fixing just the 3 vectors that were in the wrong space and explaining what was wrong. Thanks! $\endgroup$ Commented Apr 25, 2017 at 3:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .