Maxplus to pymxs help for GetLocalRotation()

[steve.samuelRJH8Y]

Hi,

I'm trying to port over a max python script to work with Max 2022, and am having issues with porting the INode function node.GetLocalRotation().GetEuler(). I have tried using pymxs runtime to run :

in coordsys local $node_name.rotation as eulerAngles

However the rotation results I get are different from the GetLocalRotation().GetEuler() function. 

Any help with the right maxscript equivalent would be appreciated.

Thanks,

Steve

[Swordslayer]

First, the MaxPlus method returns the value in radians, not degrees; second, obj.rotation is the inverse of obj.transform.rotation (see Using the Node Transforms in MAXScript in the reference for details); third, one single quat value can be expressed through many different eulerAngles values, which is why the quatToEuler function has nine different methods to convert between the two and why there's another quatToEuler2 method to get closer to display values. All in all, what you ask for is maybe something like this (but it might not be what you actually want, especially if you don't care about displaying the values only - in that case, you'd be better of using quats only):

degrees = quatToEuler2 obj.transform.rotationPart
radians = Point3 (degToRad degrees.x) (degToRad degrees.y) (degToRad degrees.z)

[steve.samuelRJH8Y]

Hi @Swordslayer,

Thank you for the info shared. The method suggested worked well to display the values shown in the transofrm type-in in UI.

However what I'm trying to do is to replicate the same results of the Inode MaxPlus function node.GetLocalRotation().GetEuler() which we have been using successfully so far in one of our max python scripts.

The results from the functions suggested still did not match .GetLocalRotation().GetEuler() in all cases.

If you have any suggestion or if you can share the detailed documentation link for inode.GetLocalRotation().GetEuler() for MaxPlus, that will also help me figure out a solution for this.

Thank you,

Steve

[Swordslayer]

If you are feeding the rotation to another script, why do you want to use euler angles in the first place? The main pro of euler angles is that they are (sort of) human readable.

There's no documentation. Some of the MaxPlus methods mirror SDK ones but not this one. But it seems to be dividing the rotation by the scale in node space:

quatToEuler2 (obj.transform.rotationPart / scaleMatrix (in coordsys obj obj.scale))

[steve.samuelRJH8Y]

Hi @Swordslayer 

Thanks for the suggestion. I tried the latest formula shared, but that too doesn't seem to be matching the getLocalRotation().getEuler() result.
Also, for some context, we are pulling the Euler values here to be used later on a threejs web viewer and be human readable as well. So I am trying to get the same process to work with Max 2022, but am facing the Max Plus function discrepancy.

Any other suggestions would be welcome. Thanks!

[Swordslayer]

Eh, in that case just ditch the eulers, the human readability is only true with eulers in simple cases when the object is rotated along one axis only (in which case the value will be the same anyway) or along two axes by some 'perfect' amounts like 90°. Use the quat to transfer the rotation and for display values, convert it on the threejs side - it's not like there's a single 'correct' answer, several euler values can represent the exact same rotation in space. And again, did you convert the values to radians? MAXScript gives you degrees, MaxPlus gives you radians. Which begs another question - if you use the radians for display values, it already beats the purpose, not only I cannot really imagine what object orientation is let's say 27 -211 68 in degrees, I already have to do a double take if I have to imagine what rotation would be 0 0 1.17 in radians...