How to calculate relative rotation from original?

Question

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.

Then how to understand this?

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

UPD.

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.

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?

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:

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:

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:

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:

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.

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].