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$ Apr 20 '17 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$ Apr 20 '17 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$ Apr 20 '17 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$ Apr 20 '17 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$ 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.

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$ Apr 23 '17 at 18:26
  • $\begingroup$ Note: This solution fixes the translation issues, but rotating the object still causes the texture to shift. $\endgroup$ Apr 23 '17 at 18:28
  • $\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$ 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.

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.

  • $\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$ Apr 24 '17 at 5:52
  • $\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$ Apr 24 '17 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$ Apr 24 '17 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$ Apr 24 '17 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$ Apr 25 '17 at 3:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.