why x-down?

[PEN]

Not really, but why would you? The biggest thing that will affect anything is axis order when it comes to eulers

[Buexe]

I thought it was y-down ... no?

[underearth]

i am with x down,only reason i follow is it goes well with splineIk adv twist.
plus with default rotation order XYZ . twist along axis(X-Axis) gets last priority.

buexe.. tell us whats advantage of having y as down axis.. i have also seen michael comet does his most script for Y-down.....pls enlighten us.

[edwardG]

Really, it all comes down to preference.

By default, it's X down. I think this started because X points to the left, and most people model the Left side and then Mirror to the Right side (positive X down to negative X).


Y down is used because people tend to start rigging at the spine, see that it points up, and figure that it makes sense to have things rotate that way.

Some game engines read Z down, and you have to conform that way.

My teacher taught us to do no rotation down the bones... and this was ok as long as the model was in a "perfect" T-Pose. I've abandoned his methods since delving deeper into rigging.

I now prefer X-Down. In maya, that's the default and it makes sense to me, so I use it.

[Buexe]

This is true. Technically there is no transform orientaion/layout to rule them all. The only thing that matters is that you use the appropriate rotation order for what EACH individual joint is supposed to behave. Pointing x-down and using xyz as rotation order is a good choice, but depending on the movement/behaviour one tries to achieve, it may not be the most optimal ( for example when twisting the joint). Ànother thing that is important that one chooses the best rotation order BEFORE animating, since changing it later will most likely change the result.

The reason why I humbly asked, is that on various Maya Techniques DVDs ( Hyperrealistic creature rigging et al. ) Y-down and z-up is being promoted as "standard" orientation. The most important reason why I use that as my "personal standard" is like underearth pointed out the Micheal comet stuff uses Y-down. Since there is access to the source code one could change it, but then again "Never change a winning team" : )
Again, I dont`t think anybody should use a certain orientation layout, only make it work (know there is no über-combination, choose individually) and consistent within the environment it is being applied.
Cheers

[designingpatrick]

So what I understand is that the down axis will change based on the environment, and there is no reason to cling on to one.

[edwardG]

Not exactly, the orientation of the down axis will change depending on the requirements and standards set forth by either your production company or by yourself. They will choose an axis for whatever reason, and they will expect you to keep consistent with the standard they have set. In the case of game studios, the game engine will dictate that decision.

If it's for yourself, just choose an axis for all characters in your project to keep things consistent and organized. It's a good habit to form early on!

[joeedh]

x-down makes lots of sense to me. . .that way you can accurately get the bone's "twist" along it's main axis just be reading the x rotation (if your using xyz rotation order).

y-down is really inconvenient this way if your app lacks a custom rotation order. as I know from painful experience, this makes rigs that rely on knowing the twist (e.g. an upper arm rig) really, really difficult to figure out and a lot more complicated.

Joe

[twedzel]

Actually X Y or Z down have no inherent advantages or disadvantages over each other when deriving twist values. The only advantage X down has is when using splineIK advanced twist options (they only work with X down). Otherwise they all function exactly the same.

Jason Schliefer made Y down popular when he released his series of tutorials featuring some of the tools that went into Gollum at SIGGRAPH. It really makes no difference what you use. But your character pipeline will be based on it so pick one and stick to it.

[joeedh]

Actually X Y or Z down have no inherent advantages or disadvantages over each other when deriving twist values. The only advantage X down has is when using splineIK advanced twist options (they only work with X down). Otherwise they all function exactly the same.

Jason Schliefer made Y down popular when he released his series of tutorials featuring some of the tools that went into Gollum at SIGGRAPH. It really makes no difference what you use. But your character pipeline will be based on it so pick one and stick to it.

Eh that's not true. If your app only does xyz rotation order, then you can get the twist just by reading the x value (if working with x-down), but if working with y-down it gets a lot more complicated. Unless I'm completely misinterpreting what "down" means in this context, I thought it meant the bone's main axis. The one it "points" along.

Joe

[designingpatrick]

So X down. You mention the splineIK twist, is this a Maya feature, or does it exist with the x-down dependency across other applications.

I wonder what Todd Widup has to say about the Gollum rig, I think that he had a hand in it as well.

Not to open another can, but if X is "down", then Z tends to follow the positive normal.

[Buexe]

You mention the splineIK twist, is this a Maya feature
yes, though I would rather call it a bug : )

[twedzel]

Sorry yes I am refering to Maya.

Eh that's not true. If your app only does xyz rotation order, then you can get the twist just by reading the x value (if working with x-down), but if working with y-down it gets a lot more complicated. Unless I'm completely misinterpreting what "down" means in this context, I thought it meant the bone's main axis. The one it "points" along.

Joeed we are talking about two things here. Frist you are right, if your app only has one rotation order, then that one is your only option. However the second point is even with XYZ rotation order X isn't always twist (assuming it is down or the twist value). The moment you derive your rotations by using IK or constraints on different axis joints, then the solver will try to solve the rotation as best as it can. This can cause X to no longer be pure twist values. So if you are deriving twist values right off of a joints rotation values, you will have some slippage which will be more noticable at extreme angles. This problem is inherent to all the rotational axis regardless of rotation order. Its a mathematical thing.

[designingpatrick]

can't we keep math out of it?

[joeedh]

Sorry yes I am refering to Maya.



Joeed we are talking about two things here. Frist you are right, if your app only has one rotation order, then that one is your only option. However the second point is even with XYZ rotation order X isn't always twist (assuming it is down or the twist value). The moment you derive your rotations by using IK or constraints on different axis joints, then the solver will try to solve the rotation as best as it can. This can cause X to no longer be pure twist values. So if you are deriving twist values right off of a joints rotation values, you will have some slippage which will be more noticable at extreme angles. This problem is inherent to all the rotational axis regardless of rotation order. Its a mathematical thing.

Ah. So not being able to use x-down isn't all that bad? I did eventually figure out a good twist-interpolating rig with y-down (which I use for the upper arm on my character) which (as far as I've been able to test) does deal with the situation you describe pretty well (it had to, to work at all). It basically works by using a series of bones whose root uses a point constraint to point along the main bone, with another constraint to align the x axis with an object placed "in front" of it. The remainder of the bones then successively blend with a copy rotation constraint on the main bone (this is the interpolating step).

There's also some other stuff that allows you to rotate e.g. the lower arm around the upper and have it look like your just rotating the upper (I did this since I figured the IK solver would be doing a lot of that, probably). I can't remember the specifics though, would have to look at the rig.

Joe

[joeedh]

can't we keep math out of it?

You can never keep math out of rigging, not really :) At the very least you need to know what you *can't* do.

Joe

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