# Rotation Order for joints

#1

HI…
I would like to know the standard rotation order for the shoulder, elbow, Hip n knee joints in such a way tht the movement leads to clean animation curves along all axes… even if we wanna move for example the shoulder 1st along the X and then the Z axes… is there ay way we can prevent the Y axes rotation values from being disturbed…? Cause such a method will also benefit in skinning and deformations of the muscles am I right…?? I’ve been eatin my headd here tryin to figure it out n I’m only gettin deeper n deepr into a muddle…!!
This is for a human Biped character…
Thanks so muchh…
Regards,
Nikhil.

#2

The animators that I’ve been rigging for like to work in GIMBAL mode instead of local mode. Interesting thing, orders that work for local mode, don’t react the same in gimbal, but orders that work in gimbal work for local. In other words test your rot order in gimbal mode, and all will be well. We’ve found that xzy order tends to be the best for preventing gimbal lock in both modes.

#3

We’ve found that xzy order tends to be the best for preventing gimbal lock in both modes.

Doesnt this also depend on the choices you make when orienting the joints local axes? FunkyT, what alignment do you use in your rigs? For example in mine, I point x down the bone, z becomes the main axis of rotation and y tends to be the “up” axis. I had never considered reordering my rotation (whats the default? xyz?), but after you comments I have started wondering about it.

#4

You’re right about that, it changes depending on the way you oriented them. I orient mine the same way you described. With xyz order the problem is, when you rotate your y-axis then your x and z start becoming the same axis (gimbal lock). So I switch to xzy which makes it less likely. Bottom-line no matter the order, gimbal lock is always possible, you just need to find the order that has the gimbal with the least likely scenario for it happening.

#5

Ok, I can see what you mean. I will certainly give this a go. Thanks for the info.

#6

Well I was jus doin some research lookin into my own self… n I found that these following rotation orders would work best for basic biped rigs…:

Shoulder : XZY
Wrist : ZYX
Hip : YZX

n well I feel Gimbal Lock should not really occur under the biped’s natural movement if these rotation orders are set…

I would appreciate ur feedback on this though…
Thanks…
Nick.

#7

Hello,

Recently I was with the same problem of Gimbal Lock. I sugest a little frankstain that result in a solution that lets us just a simple arm to control (without gimbal lock problem). Its based in a Cris Landreth tutorial, and I think that its a cool solution. Here I go:

I created a control arm (simple three joints) and a “real” arm (six joints).

First the “real” arm:

play attention on three joints at right of the image.
the red is responsible for wrist x rotation.
the green is responsible for wrist y rotation.
the blue is responsible for wrist z rotation.

I colored and resized the joints just for selection and visualization:

after create this joints I just positioned the axis (insert key) of the joint “wrist_rotate_y” to the same place of the joint “wrist_rotate_z”:

Now I have one joint to each axis of the wrist. This prevent the gimbal problem because the rotation order of each joint responsible for this respective axis is arranged for each case separetely.

Its easy just use the rotation order to the joint that begin whith the name of the joint:

Now its just creat the control arm and in the connection editor connect the attributes:

Its done. Now remember to rotate the control wrist with gimbal rotatio. the gimbal will behave likely gimbal lock ( he still there ) but with only one joint you will create right rotations an clean rotation curves dribbling the gimbal problem.

I hope that this help.

#8

jadecilcleton ,that’s very intresting can you post a simple file as exemple…would be nice.
thanks for that explanation anyway, where did you got that tut BTW? is it from the Bingo DVD? or the Ryan one? something else maybe.
thanks anyway

cheers

#9

yes was based on chris landreth’s tutorial.
the difference was on three joints on the wrist, to try to dribbling the gimbal lock.
I forgot to post the file, lol, sorry, now here go the link:

http://www.pingo.art.br/_beta/cg/arm_frankstain.mb

we still having the gimbal lock on ctrl wrist joint, but thats dont confuses no more, because we have the x , y and z animation curves to your own functions, without all that mixture in some axis. Remember to use gimbal rotation particularly in the ctrl wrist joint. You will see that its behave wrongly on ctrl joint and rigth on the real joints

I realy hope that this help

#10

hey Jade nice clean pic by pic tutorial - great work

dont think it was mentioned in this thread yet but worth pointing out to ppl reading it that these notes are assuming the characters facing the Z axis so his arms/fingers point along the X axis. I know its a rigging page1 note but worth reminding ppl. It isn’t written but its definitely widely accepted lol!

one question - I’m not sure if its been adjusted in later versions of maya but I remember watching a video and they said that Maya’s rotation order dropdown box is the other way around!! So if it reads XYZ its actually calculating Z first, Y second then finally X is that correct? jadecilcleton can you shed any light on this - I notice your rotation orders are set differently for each joint in the wrist but they seem to read the wrong way around (thats IF what I saw on the video was true!)
hope this makes sense great approach to arm rigging

cheers
ant

#11

hello ant!

Thanks for the feedback
Maybe I was wrong with my though about the rotation order. Just it seems thats all right because works well. But its cool to take feedback about it to try to understand better this problem. I thougth that the rotation order was exactly what the letters order was showing, because seems more logical… but now I realy dont know, lol.

What I know its with the rotation order that I choose for each joint, I preserved the orientation of the “important” axis. Maybe with this approach, the rotation order of three wrist joints doesn’t matter.

thanks ant!

cheers

#12

I was delivered a Maya rig from a sister studio, and broke it all down, but saw these “extra” joints in the same locations like this. Now I know what to look for.
On most of these situations I have changed xyz to xzy to fix it. … with limited results. Sometimes it works, and sometimes not.
The new rig I created for our studio used most of the old rig, but I will try your setup to see if it fixes some of the problems… thanks.

Any direct link to chris landreth’s tutorial?

#13

Sorry john,

I dont have a direct link…

#14

Hello all,

i’m gonna post a little question in here just not to make a useless thread for a little thing.

Question is: i’ve seen in a few free full rigs that there are bones (joints) that have a nurbs circle as a control fully attachted and integrated into this bone. You can adjust the verteces and all, but in hypergraph and hypershade you only see the joint and circle as one. I am searching like hell but can’t find how to do this.

At the moment i’m building a standard rig (i’m not a rigger nor animator) for the latest Challenge Strange behaviour. I learned to use the IkFk blend from maya, but it sucks way too much. I’ll do the classical way with 3 sets of arms, but to maje stuff less likely to get messed up, i would want to make it all as clean as possible.

At the moment the rotations of the controls start to flip the arm completely over during the IkFk Blend. So that’s why i need a different approach.

cheers all

#15

Nothingness…
that is a trick where you use the joint as the transform for the shapeNode of a nurbs curve controller.

1. create a joint (joint1)
2. create a nurbs circle (nurbsCircle1)
``````
parent -r -s nurbsCircle[b]Shape1[/b] joint1 ;

``````

make sure your curve is zeroed at the position where you want it to before this because it will assume the component space of the joint.

#16

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.