Transform Inverse node. Explanation ?

[FXHochban]

So I have been working on implementing the movement system from Lyra into my character. I have almost completed the implementation and I am currently working on the control rig portion for the FootPlant.
In Lyra there is a portion where the RigGraph …

It is actually working, and it makes sense except for the inverse function shown below with the value and results inspected.

The tooltip simply says Returns the Negative Value. Well not sure why the Z value (the main value of interest) is just not negative Z, but it evaluates to negative X? And the angles are changed too, but not how I would expect.

Clearly there is some order of operations here to perform the ‘Inverse’ and there is no documentation that I could find explaining what is going on.

I would appreciate some explanations so that if I try to use it in the future I will know what to expect.

A bonus question here is how does this Put the offset in pelvis space? The pelvis offset is calculated based on the lowest foot, so I understand that we want this relative to the pelvis, but when I read pelvis space, I have been reading it as in its local coordinate space ie x is up. Which confounds my attempt to understand the Inverse function as coincidently the Z value became the -X value? My best understand is Must be Magic.

Thanks

[High500]

hi @FXHochban

Its tooltip is right and wrong. If the value is positive it returns negative. if the value is negative it returns positive. Therefore inverse (reversed signs).

The changing of rotation on 1 axis can alter the resulting forwards axis (or any)because of something called Gimbal Lock, which appears like a kind of axis flip. Therefore depending how far you rotate 1 axis it can flip one of the others ie. Z becomes X.

Euler rotations confuse many using unreal or any other animation package.

Euler (gimbal lock) Explained - YouTube

[FXHochban]

Thanks for the reply, that helps a lot. As it is set to use the Rotator which is a Quaternion I think this is supposed to avoid gimbal lock using magical 4th dimensional space or something LOL. Any other comments on this part would be appreciated.

The video was useful since I never understood why there were different choices of Euler axis orders to pick from, so that will be better understood in the future by me hopefully.

In regards to the use of the Inverse node to put the offset in pelvis space, If I only think of the Inverse Node as a black box but understand that its intent is to create the negative or opposite direction of its input.

So in this case, if I understand correctly…

1. We get the pelvis bone transform in global (world) space (z is up).
2. We create a vector V(x,y,z) in global (world) space using z= CurrentPelvisOffsetZ value and some possible x value depending on the slope of the floor in the forward direction.
3. We then rotate this vector V using the Inverse Transform from the Global (world) bone transform which rotates V to the opposite direction of the bone transform.
4. We can use this Result as the vector location to apply to the PelvisCtrl that will affect the location of the Pelvis (eventually).
   
   

I still have a problem understanding Step 4 as shown above, we set the transform of the Pelvis Control using local space. Local to what? The rig? or the pelvis control (which matches the orientation of the pelvis bone).

Lets assume CurrentPelvisOffsetZ = -40 as one of the feet is lower than the root. We create the vector V (0,0,-40) and rotate by Inverse(pelvis Transform). I am at a total loss here of how the Result
(screen captured ignore the z= bit) = (-41,-5,0.79)

and happens to be in the proper local space translation for the control.

Like it works because the local X direction of the pelvis (and control) is Up , but what is the logic? Seems pretty random, and never would have reasoned this to be the setup.

Help is appreciated.

[FXHochban]

Ok, I figured out the Inverse Node.

It very simply is providing the negative of the rotations as expressed by the quaternion. This is the only part we are interested in. See below (near the bottom) for final explanation.

This explains more.
Quaternions.

The order of operations of this is also important.
So first it takes the input rotation as quaternion and multiplies it by -1. Except for the ‘w’ term which represents its magnitude. This provides us the inverse rotations.
Then this quaternion is then applied to the input translation as a rotation to the vector3.
and finally the resulting translation is multiplied by -1.

The return value is then the “negative value” of the Quaternion Rotation and the “negative value” of the translation that resulted from that rotation.

This result is very strange for sure as we go through imaginary space, but it avoids gimbal lock and if we rotate by this value we will return to the original orientation.

Giving credit to the following for explanation and solution to the Quaternion rotation of a vector.

Rotating vector3 by a quaternion

A dot product calculator to help

Vector Dot Product Calculator

A cross product calculator to help some more.

Vector Cross Product Calculator

Capture of Excel computing

And a screen capture of the input and inverse to confirm result.

I like to note that this is sensitive to the precision of the values so use all the decimals available.

All of that is interesting and discovery on the way to figuring this out.

---

So the comment of “Put the offset in pelvis space” is accurate, but the explanation is lacking.

The important part of the Inverse Node in this use is actually just the negative value of the rotation of the bone relative to the global axis.

The local bone space is rotated by angles a,b,c from the primary global axis x,y,z. Therefore, if we have a vector that is expressed relative to the global axis we can then use the negative values of the angles a,b,c (ie -a,-b,-c) to rotate that vector to align with the local bone space axis.

The result is a vector that is in the pelvis axis orientation and it is applied to the LOCAL space of the pelvis control (ie it’s zero point is the origin of the control) so our global CurrentPelvisOffsetZ is now oriented in the appropriate direction and placed at the appropriate origin of the control to affect the needed adjustment.

Hopefully this helps anyone else, or prompts the devs to add more documentation on simple looking but powerful little nodes like Inverse.

Cheers