I always thought that relative info gives us information about the object relative to the object's local coordinate system. And by this logic, if both objects have Y rotation 0, then relative rotation should give 0 in Y, as well. enter image description here enter image description here

Then how to understand this?

enter image description here

How is relative info actually converted from original info, if not by subtraction?

Here is file-example:Test

Ok, as I see, without explaining the global problem it is not very clear what I need. I'm trying to pull information about an object (loc,rot) (hereafter gradient) through an attribute from another object (hereafter controller). Obviously, the relative info of the gradient will be considered for the controller, not for the main object. So I pass the original info through the attribute, and then I need to somehow calculate the relative for the main object inside its GN. To get the same data that the object info node gives. Loc, I was already able to convert from original to relative. (Maybe I'm doing a total crap and it could be much simpler, but at least the values are the same). And the ultimate goal in general is to replicate the "Texture coordinate" Object output in GN.

Here is a new example file: Test 2


Okay, apparently it is impossible or very difficult to do exactly what I asked. But it is possible to calculate relative rotation of one object to another without using relative object info inside one of the objects. Actually this post is a subpost of How to "unhook" position node in math calculations from attribute "parent"? so the answer will be there.

  • $\begingroup$ Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Blender Meta, or in Blender Chat. Comments continuing discussion may be removed. $\endgroup$
    – quellenform
    Jan 4 at 14:35

1 Answer 1


How is relative info actually converted from original info, if not by subtraction?

I cannot emphasize this enough, so I'm going to start with it: subtracting two Euler values does not give the rotation needed to turn one rotation into the other.

Now, the actual question, how are the relative rotation values derived?

enter image description here

The rotation of Suzanne here is turned into a rotation matrix (see wikipedia "rotation matrix".) Conversion to a matrix allows it to-- is necessary to-- convert that rotation into a different space. The matrices of all of an object's parents are multiplied together to provide the final, world-space rotation matrix, which is then re-evaluated in the transformed space of the GN object. That converted matrix is then decomposed, reverse engineered, into XYZ Euler rotation values. That's how they're derived.

The process of converting Euler values into matrices means that some information from the original rotation values are lost. For example, values outside -180,180 are remapped to inside of that range:

enter image description here

720 degrees of rotation in a single axis is the same orientation as no rotation at all, so we see 0,0,0.

Less intuitively, many orientations inside -180,180 can be described by multiple Euler values. The precise Euler values used to create the rotation are lost, and are recreated by Blender according to whatever method it prefers:

enter image description here

We're inputting XYZ 0,180,180 and Blender is reading back 180,0,0. They happen to be the same orientation; once we convert it to a matrix, Blender only knows the orientation, not the values used to create that matrix.

These objects are unparented. When we rotate Suzanne, we see the values change; but when we rotate Suzanne and the cube together, we won't. (Well, not beyond small precision issues.) When we rotate those objects together, Suzanne's rotation exactly counteracts the rotation of the space in which we're measuring that rotation:

enter image description here

In addition, even though I have been showing the values in the sidebar with unparented objects, transform values are measured in local space. When we parent an object and rotate its parent, the object may have rotation relative to the GN object without having any local rotation:

enter image description here

Suzanne has no local space rotation-- that is, she has no rotation relative to her parent. But her parent has rotation. Thus, she has rotation relative to the rotation of the cube. She has inherited rotation from her parent, which doesn't show up in the sidebar.

In many cases, an object can end up hidden rotation contained in its "inverse," a hidden matrix that measures the relationship of an object to its parent. Depending on how parenting is established, an object may appear to have no rotation relative to its parent, yet still have transform values.

enter image description here

Because I parented the left sphere to the left cube while the cube was rotated, rotation was built into the inverse. On the right, even though both empties appear to be in default orientation, we see that the sphere needs rotation transforms to reach that orientation.

Now, let's get into the gravy of why subtracting Euler values is not the same thing as relative rotation.

Eueler rotations are three sequential rotations. The output of those rotations depends on the order in which we make those rotations. That's why there are six different flavors of Eulers: those are all the different orders that we can perform three rotations.

We can think of an Euler angle as being three rotation matrices, multiplied together. [x][y][z] represents an ordered rotation about three axes; the matrix multiplication product of those rotations gives us our final orientation.

Let's go back to unparented cube and Suzanne, to avoid complications with local vs. world space. [xC] is the rotation, in the X axis, of our cube; [xS] of Suzanne; [xD], a rotation, in a single axis, of the difference of those values. And we have those for y as well. We'll skip z, it doesn't matter.

Now, what happens when we [xC][xD][yC][yD]? We get Suzanne's orientation. [xC][xD][yC][yD] = [xS][yS]. But, what happens we [xC][yC][xD][yD]? We are rotating in a different order, and we get a different orientation. It will no longer be Suzanne's orientation.

But there are values that would solve for that. Rather than providing you xD etc, Blender is providing you x?, such that [xC][yC][x?][y?] = [xS][yS].

  • $\begingroup$ First of all - Thank you, finally someone has written down exactly how this works. However, it is very difficult for me to perceive it in the form of text, can you please create a group of nodes, which will calculate from two world coordinates, relative (it does not really matter what to what. I will just understand how it work in the form of math). $\endgroup$
    – Dmitriy
    Jan 5 at 6:54
  • $\begingroup$ Sorry, no, I can't. The most anyone does with this is write several functions that each do a part of it, check that they work, and then forget about it. More commonly, they use library functions that they've never read. This is 3D math, 3D engine work, and I'd recommend gamemath.com, a free online book on the same. You need to understand it conceptually, as text; there are too many ways to go wrong if trying to deal with it as just f(x,y,z) etc.-- even if I could provide you that, which I can't, you wouldn't want that. Especially not as nodes. $\endgroup$
    – Nathan
    Jan 5 at 16:33
  • $\begingroup$ Fair enough, especially since I got what I wanted. $\endgroup$
    – Dmitriy
    Jan 8 at 7:35

You must log in to answer this question.

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