I’m making a randomizator script with a pretty advanced UI.
In this UI I have buttons to turn on or off the randomization on a certain transform axis (for example, I can set it to randomize just the x and y positions and the y and z rotation at once).
In this script, the user can choose which axis to do the randomization on the fly, and can turn any of them on or off at any time. So here begins the problem:
While writing the script I came to the conclusion that rotation order matters on the end result. What I mean is, if I rotate a cube 30º on the X axis, and then rotate it another 30º this time on the Y axis (assuming World Coordinates System) I end up with a different result If I rotate it first on the Y axis and then on the X axis.
So my question is – is this a mathematical limitation? Is there a workaround it? This is not a deal breaker on my script but it surely is a nuisance.
Of course, you come up with different results, the problem is well known as “Gimbal Lock”.
To avoid that 3D programs such as 3D Max calculate rotations as quaternians (quat) and this will solve your problem.
If you know your rotations you can calculate a quat from a simple euler rotation and pass the quat to the max-rotation track, I guess there is the Max-Command like <eulerangles> as quat…
Or if you want to rotate your object around XYZ you would do that in quat-space and everything stays always the same. The last step requires you to have a basic knowledge about quats, the MaxScript Help might be a good place to start.
Best regards
-k.
Thanks for the response, Kogen, but maybe I didn’t express myself properly.
The “problem” is, if you create an object in 3dsMax, like a cylinder, and you rotate it using World coordinates system 30 degrees in X and the another 30 degree in Y you’ll end up with a different rotation than if you first rotate in Y and then in X. You don’t have to use Max to test it, just do it with any object you have in your reach.
I guess this is something normal, but I need a logical (algorithmic) solution for the script to work.
absolutely normal… that’s exactly why the conversion a quaternion value to an euler angles needs the XYZ axis order. because of that the Euler XYZ controller has the axisOrder parameter. so you technically can read this value and apply rotations in the specified order.
(the MAX default rotation order is XYZ regardless of the fact that Leonhard Euler originally described the orientation with 2 coordinates rotation ZXZ)
Uhm, in this case, it is not possible to solve it (as far as I know). You stated it right, turning the object in X and then Y is different from turning it first in Y and than in X when you’re dealing with axis-rotation.
That’s why I put the quaternions into the game because a rotation in this space is always unique. But of course also in quaternion space A + B != B + A.
But you might randomize their vector parts and apply the whole quat to your object, instead of saying “1st transorm application”, “2nd transform application”, “3rd…”.
-k.
Thanks for the replies Kogen and Denis. Regarding your suggestion, Kogen, that’s exactly what the script was supposed to make until a friend of mine suggested to “make the randomization happen in real time, while I adjust the parameters” so there it goes – the script begins to randomize the rotations as soon as you enter any value in the spinner. This way is nice because your get a good feeling of how your values change the randomization output.
Anyway, I just happened to have an idea of how “circumvent” the axis rotation order. It will require a few more cycles and if statements in the script but hopefully it won’t give unexpected results to the user.
If any of you would like to test/peek at the script I more than gladly would post it here. Sure, with the condition you guys give some input or feedback on how the code can be improved!
Cheers!