# Texture Changes When Object Position Changes

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.

# New 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:

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.

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.

# Try It Yourself!

Here is a link to the full blend file.

• 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? – David Jeske Apr 20 '17 at 3:54
• 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. – Duarte Farrajota Ramos Apr 20 '17 at 4:18
• 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. – Rich Sedman Apr 20 '17 at 6:19
• 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. – Tyler Abair Apr 20 '17 at 20:11
• @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. – Tyler Abair Apr 20 '17 at 20:12

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.

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.

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.

• 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/… – Tyler Abair Apr 23 '17 at 18:26
• Note: This solution fixes the translation issues, but rotating the object still causes the texture to shift. – Tyler Abair Apr 23 '17 at 18:28
• 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. – David Jeske Apr 23 '17 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.

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.

• 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. – David Jeske Apr 24 '17 at 5:52
• 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. – David Jeske Apr 24 '17 at 6:10
• ...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. – David Jeske Apr 24 '17 at 6:18
• 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 – David Jeske Apr 24 '17 at 6:35
• @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! – Tyler Abair Apr 25 '17 at 3:32