Numbers problem in max

[Chris]

It could be due to the rotation controller on the object? Try assigning an euler XYZ controller to it...

[Lord Whorfin]

It is euler....and still the problem presists. :(

[LFShade]

It's a common problem with euler rotation. Basically, it's a mathematical phenomenon where the x and z axes end up pointing the same direction. Thusly, you end up with the equivalent of two usable axes of rotation.

To fix the problem in MAX, assign a new EulerXYZ controller to the object, then set its axis order to ZYX (it's a listbox found further down on the motion panel). This gives the same results as the local Euler controller from earlier versions of MAX: no gimbal lock. Sadly, you'll lose any keys you had set on the locked-up controller, unless you're able to script up a way of saving out the old controller's keys and pasting them back into the new controller.

[Lord Whorfin]

Nope....it isn't gimbal lock. When you go through the steps I noted above you'll see that the numbers go wonky before the y and z axis meet. Gimbal lock is the phenomenon of two rotational axis of an object pointing in the same direction. With the problem we're having the y and z are not pointing in the same direction. Now I could be wrong so I tried it again only rotating the y -60 degrees. Next I rotated the x and right away the numbers went wonky again. In fact when only rotating the x by one degree the numbers are:
x 90
y-91
z-90

and I never touched the z at all. The window I'm using to view the numbers is called "Rotate Transform Type-In" but the numbers go the way of the wonky in the graph editor too. Hmm....I have no idea.......anyone else?

[LFShade]

You're right -- my original answer was premature. I apologize, but at that time I didn't have MAX in front of me to go through your steps, and it just sounded an awful lot like gimbal lock. Especially when you mentioned you were using Eulers.

I think that understanding the problem would require knowing how the transform type-in dialog displays values (e.g., what coordinate space is it showing offsets from in a given situation). I do have to agree that it seems counter-intuitive, though. I thought maybe it was showing to what degree the local matrix was offset from world axes, but that doesn't seem to be the case. It's really bizarre. (scratches head)

Anyhow, it looks like a temporary workaround would be to make sure you do your rotations in local coordinate space. The values seem to read the way you'd expect when you do this. In other words, when you rotate on X, only the X values change, etc.

What's really confusing is that the left side of that darn transform type-in floater always says Absolute:World, even when it's clearly not displaying or operating in absolute world coordinates. What's that about?!!!

Anyway, good luck to your roommate on that project:)

[Lord Whorfin]

From what I now understand the reason why this is happening is because there is no such thing as gimbal lock in MAX. According to my roomate when they built MAX they decided to use some funky math workaround to make it impossible to have gimbal lock. Apparently that wanted to be able to say "no gimbal lock" more then they cared about how the numbers worked. At least thats what he told me. I could be wrong.

[adam3d]

try using the "freeze rotation" and "rotation to zero" commands available in the Customize UI/Animation tools section. This makes a List Controller with an "initial pose" controller for the rotation and a "keyframe" controller for your animation. this is pretty standard workflow for characer rigs. Check out comet-cartoons.com for lots of info.

it's also a way to layer animations. real cool stuff

[LFShade]

Thanks, adam3d, but I don't see how your suggestion relates to this thread? Even if you use freeze transform, you still have the EulerXYZ controller behavior to deal with. Freeze transform also could potentially blow out any keyframes you have created, so it's not the kind of thing you want to use mid-project!

[AJ]

If you reset the transform settings (0,0,0) - does the object return to the position in which it was created?

If it doesn't then this is a result of Max having an "ideal" angle from objects to be created... if you create an object in the front viewport then it may be rotated 90/-90 degress in one axis already (before you've changed anything). One way around this is to go to the Tool panel and "Reset Xform" - then "reset selected" (your object), then collapse the stack...

Other factors may be the axis you are rotating around - do you have it set to View? or Local? or another...?

One final thing - irrespective of the values presented in the window... if the object displays a rotation of say -90 (yet you have not rotated it at all), and you wish to change that rotation from it's current position to an angle of 60 degrees say, then you can type in that transform window "r60" - and it will alter the degrees by 60... Not the easiest way to work but it may help.

Hope any of this is of use,

:D

[Ls3D]

Expression controllers can be used for this sort of thing, check em out if you have not.

Can't you just setup a dummy to handle a second axis (of evil) rotation, and then make the transform tracks (including translate and scale) an instance of each other by copy/paste in track view?

Duplication the dummy setup on obj two could also be instanced in this way to handle the second axis. Hope this is usefull.

-Shea
Ls3D

[Lord Whorfin]

Well here is how it was fixed. A sepreate bone for each axis. each one parented to the one before it. That way when you rotate one the others (which are in the same space) move along with it but do not take on any rotational information. The animations all had to be done over but it was the only thing that could be done to get the rotational data.

[subagio]

What you were seeing WAS gimbal lock in a way, and there was a grain of truth to each of the above posts, though it seems to have come through a few chineese whispers.

The root of the situation is that Max uses TCBs to store and manipulate it's rotational information. TCBs work by specifying a specific orientation in space, rather than an offset from 0, which is rather good in a lot of ways. It's faster to calculate than Eulers too, which is why almost all realtime applications (games) use them. TCBs are axis order independant, so they cannot gimbal lock. Proof that it's rather a good thing to have around is that Maya finally added them in this release :) My guess is this was more than likely a result of the gamers asking for it.

Now, viewport interaction is a little weird. What you were doing was rotating the object in the world axis, which is the default max behavior, but not the default on most other programs. As you dragged the mouse, you were describing a rotational matrix to apply to the object in world space, which is why rotating around the world x was affecting the local x, y and z. I just tried it and got the same values. The reason for this is that the matric you're building is applied it seems to the current rotation as a quat, before it's converted back to Euler. It's actually the conversion back that is suffering from gimbal lock, as the TCB smoothly moves through it's range, but the resultant Euler angles flip axes. Switching to the local axis context (drop down on the toolbar) and rotating in the object's x space causes the behaviour you're looking for.

Breaking out the axis into 3 nodes essentially does exactly what using a Euler controller set with that axis order (the order you have the nodes linked) and working with it in it's local coordinate system.

--C

[Gilgamesh]

wow. that hurts my brain. I like it when i move the mouse on the pad, and the thing on the screen moves too. ;)

[LFShade]

Thanks, subagio, that clears up the issue pretty well for me. I remember reading that gimbal lock was supposed to be eliminated in MAX through the use of quaternion rotation rather than euler angles, but I was never quite sure how that was implemented. Now I know:)

It also explains why $object.rotation always returns a quat value, no matter the controller.

Cheers!

[subagio]

Aikh! Now I'm really going down the evil route. Thanks for the nomenclature clarification. Everywhere in my last post I said 'TCB' I did mean a quaternion value. TCB refers to the tension, continuity bias controller that stores quats and let's you alter the interpolation between the, with said 3 values per key.

--C

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.