Rotation Order in Messiah?

[Ulven]

Messiah has a fixed rotation order, so if you want to change it, you have to rotate the parent. 's a bit kooky, but it works. I usually make a 'pivot null' to do this if I need the parent free of rotation.

[Pixelclown]

Mhm, ok. Sounds a little bit weird for an animation package. I think it should be definitely adjustable in the next version of messiah.

Thx again Ulven for the fast reply.
cheers!

Jonas

[Ulven]

Yarr, it's a bit strange, I know.
If you're experiencing gimbal issues, the best way to work around them most of the time in messiah animation is to use parent coordinates for rotation. But I often use a null to change the rotation order on things like the fingers so I can get a better natural range of motion on local rotation by using heading as pitch.
Where are you studying by the way? Are you one of David's students?

[koots]

Do you guys have an example of why you want to do this. I do not understand the reason this would be helpful.


Excuss the Noob trying to learn:)

Thanks!

[Ulven]

Sure. Though it's a bit technical so bear with me:
Say you have a joint that will go beyond 90 degrees on pitch quite often, like a finger or your lower arm. If you do that in local coordinates, you will experience a pitch flip, which is messiah's way of dealing with gimbal lock.

You'll see that the rotation angles when you go beyond 90 degrees in local mode is something like Heading:180, Pitch: 80, Bank: -180, when you've rotated 10 degrees past 90 degrees. What you really wanted to happen is for it to be Heading:0, Pitch: 100, Bank:0.

Both coordinates describe the same orientation in space, but they will interpolate quite differently if you had a keyframe at say Heading:0, Pitch:60, Bank:0 orientation before it. The object will sort of twirl around to it's new orientation instead of going directly between the two.

One way of solving this is choosing 'quanternion' angles instead of euler, but this makes the curves much less readable while animating. It will also interpolate the shortest route between the two orientations instead of taking the full rotation (with euler you can make something spin thousands of degrees with just two keyframes, whereas with quanternions the object will just turn the shortest route from orientation A to orientation B. no matter what degrees of rotation your keyframes say.)

However, in euler angles, none of the other rotation angles will flip! This is because of the rotation order. So if you were able to change the rotation order, you could choose which rotation channel should be the flipping one, and thusly you could pick the one that was least likely to be used beyond 90 degrees. So on a finger, typically you use pitch for the up and down 'nodding' movement of the finger. But if the animator wants to use local coordinates when he's animating, he'll continiously go dangerously close to and often over the 90 degrees on pitch, and the fingers would be twirling around with bad interpolation continiously. If, however, you make a parent null that rotates -90 on bank before the fingers in the hirearchy, your fingers can use heading instead of pitch to rotate on, and thusly not flip or twirl around with bad interpolation anymore.

[Pixelclown]

Yes, actually it's very important for character setup. With the rotation order you can avoid a gimble lock for a specified axis.

The euler rotation rotates one axis after another. For example, if you have a rotation order XYZ the z-rotation is first rotated, after that the y-rotation and finally the x-rotation (Rotation Order from right to left). Now comes the tricky part.


The first axis (Z) is the parent of the second (Y). And the second of the third (X). So if you rotate the first axis, you can rotate it as long as you want. You get no gimble lock. No problems.

In messiah the rotation order is HPB (Heading Pitch Bank). Try it in messiah and rotate a cube on bank. You see that the value of Bank is linear. In other words, you can rotate on Bank like you want, till 360 degrees or further.

Now reset the cube and try to rotate the third axis (Heading). It's the same, totally freedom. This is because of the hierarchy. The first axis controls all others, the third just itself. But the second axis is the problem.

Reset the cube and rotate on Pitch. You'll notice that the value of Pitch goes till 90 degrees and than back again while you are rotating in the same direction. The same for negative values. This is because the second axis controls the third but the first stands still. So when you rotate the second axis about 90 degrees, it has the same orientation like the first. And that's a gimble lock. Because now you have two axis with the same rotation and therefore one is missing to complete a rotation in a three-dimensional space.

What the euler rotation in messiah is now doing (like in the other apps as well), is rotating the other two axis the way that the object has the same orientation but with a rotation within all three axis. You can see how the rotation is solved if you animate the cube jsut on Pitch over 90 degrees. Crazy math :)

The main thing about it is to set your rotation order that the second axis is used fewer than the other two or even better that it's not used.

Mhm, I hope that doesn't sound to confusing. Maybe its hard to understand for the first time. Especially if it's explained by me. :D

[Pixelclown]

Therefore Ulven explained it as well :thumbsup: cheers!

[koots]

Ulven,
This seems like a great place for you to do a video tutorial. Because I am very confused. Both Ulven and Jonas spent a lot of time explaining this but it comes across very confusing.

for me one of those things I need to see to understand.

What do you think Ulven?

[lanosrep1]

Thanks to all who replied to this thread.. great answers to a difficult subject :)

Wondering if you rotate the object in setup so that pitch becomes say...bank.. does that work as well..

In other words, can you modify the solve order and or avoid the gimbal problems this way too?
Not in front of Messiah now to check..

G.

[Ulven]

Just about to head home to Norway for the holidays. But maybe after the holiday season I can show you how it works.
This is a technical aspect of rotation, and is something that's described in depth around the web. Best thing to do is search for 'gimbal lock' 'euler angles' and 'quanternion angles' if you're interested in learning more. It might take a bit of time to fully understand, but is really quite fundamental theory, especially in rigging, to be aware of.

Merry christmas and happy new year everyone.

[Sil3]

lanosrep1:

I dont think that would work... its hard to describe it when the program we use dont have this function... download XSI MOD tool and take a look at this on their manuals, you can even keyframe its change (not sure if is helpfull).

When I have items that will rotate a lot on all 3 axis, like usually a hand does, the best is to break them into at least 2 Controlers for the hand, one will only Rotate in one axis and the other will Rotate on the other two, this is one way of dealing with it and the best way IMO.

Another that I use to do is try to come up with a situation where I know I will go there and see waht Axis gets Locked on Gimbal, then change the Rotation Order to try to minimize the damage, of course this needs to be done before animating, if I change the Rotations Order i need to redo all my animation for that Item, or it will rotate everywhere.

ps: sorry for the XSi bring up, but I was explaining something and its easier like this to me.

[peksi]

I did a little example scene for you, as Messiahs sphere doesn't show you how the axes are really aligned. It helps you to visualize the how rotations are handled and why gimbal lock is problematic.

Red circle is heading, green pitch, blue bank. On frame 0 all rotations are 0, on frame 10 pitch is 90 degrees. You can see how bank and heading are aligned. Go ahead and try to rotate null in PARENT coordinates about bank, try also heading. As you can see they both rotate abou same axis. Okay go back to h 0 p 90 b 0, switch to LOCAL coord and try to rotate about axis that you couldn't rotate in parent coords (it should be heading on edit sphere). Hopefully that helped?

[koots]

peksi,
After looking at that. Damn that could be frustrating. I have a lot to learn when it comes to animation. Thanks everyone for helping me on this!

[lanosrep1]

Sil3 said:

"When I have items that will rotate a lot on all 3 axis, like usually a hand does, the best is to break them into at least 2 Controlers for the hand, one will only Rotate in one axis and the other will Rotate on the other two, this is one way of dealing with it and the best way IMO."

This has been the tried and true method.. but having to animate multiple items for this is kind of thing is a hastle.. can add up quickly in terms of extra items to keep track of.. .. but it works!

G.

[dobermunk]

for those just getting into the commands and scripts:
the rotation channel of that parent null you mention can be automatically linked to the middle rotation axis and the middle axis itself negated. This way, you have the anti-gimbal setup with one control null.
Perhaps this is an approach to creating a gimble-less null that is created in one go but is actually a double null set-up.

[Sil3]

Sil3 said:

"When I have items that will rotate a lot on all 3 axis, like usually a hand does, the best is to break them into at least 2 Controlers for the hand, one will only Rotate in one axis and the other will Rotate on the other two, this is one way of dealing with it and the best way IMO."

This has been the tried and true method.. but having to animate multiple items for this is kind of thing is a hastle.. can add up quickly in terms of extra items to keep track of.. .. but it works!

G.

Well a good and pleasent Rig to me have Controls for almost everything, 2 or 4 more items to keep track is a price to pay to not have a serious case of pulling hairs when dealing with Gimbals.... Its a bit like Automation, its cool to have it there but it needs to be abble to be overriden whenever I want/need or else dont give me Automations in a Rig please :D

I dont know any Software that doesnt have Gimbal issues... maybe Character Studio...

[Suricate]

Gimbal lock is a fact of life if you are using Euler rotation, there's no way to avoid it. Changing the rotation order helps a bit, but cannot totally avoid.

Chnaging the rotation order in messiah can be done using expressions or you can just use a pivot null to change to axes (so that e.g. bank becomes heading).

On the other hand, waht exactly are the problems of gimbal lock ? There is:
1. Difficulty to preview a rotation when posing and
2. Weird interpolation.

Since messiah's edit sphere in parent mode doesn't really let you preview rotations anyway, I am a great fan of using local coordinates. That way you always know which way you are rotating. The pitch flip interpolation problem can be adressed with the 'EP_PitchFlipKey' command that is part of my 'ExpressionPack' plugin.

[Sil3]

Gimbal lock is a fact of life if you are using Euler rotation, there's no way to avoid it. Changing the rotation order helps a bit, but cannot totally avoid.




Yap... its used to try to minize the "damage" hehehehe, 2 Controls one of the best ways to deal with it like I explained before, no confusion, no expressions, just another thing to animate thats all.

[lanosrep1]

Edited... The pitch flip interpolation problem can be adressed with the 'EP_PitchFlipKey' command that is part of my 'ExpressionPack' plugin.

And what a great set of plugs they are.. especially when used in the AutoRigger.. nice!!!
Thanks for your hard work Christopher!!!

G.

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