Are we every going to see rotation order control in Cinema?

[LucentDreams]

The simple fact is its not an easy task. Yes rotation orders are reasonably easy to code themselves, but to the update a 10+ year old application for every single rotation reference etc is a massive task that could lead to a lot of problems if not done right. to implement such a thing will require the right timing on when its best to take such a drastic change of the core, and make sure there is time to properly test the whole app. Theres also the concerns of how it can affect existing scenes

[Horganovski]

What do you think about the possiblity of introucing it as a Tag or special kind of rotation constraint, kind of like the Quaternion tag but with the ability to ease it?

In my search for a workaround I've tried making an extra copy of the FK controllers, adding Quaternion tags to them and then using rotation constraints to blend between the regular FK controllers and the ones with the Quaternion tags.. this almost works..but not quite.. and it's very messy.

Cheers,
Brian

[xfon5168]

What do you think about the possiblity of introucing it as a Tag or special kind of rotation constraint, kind of like the Quaternion tag but with the ability to ease it?

In my search for a workaround I've tried making an extra copy of the FK controllers, adding Quaternion tags to them and then using rotation constraints to blend between the regular FK controllers and the ones with the Quaternion tags.. this almost works..but not quite.. and it's very messy.

Cheers,
Brian

If you want to simulate Rotation Orders, Make 3 Null Object(X,Y,Z) in the order you want to use for each bone or controller, or however you're animating your FK. Then Add all of the Nulls to a Selection Object, and then Right Click on The null's corresponding rotation(so Z represents the B rotation, so you'd right click on the R.B. Attribute) and choose Animation>Add Keyframe selection. Now If you click the Red Key with a ? on it, switch it to your selection object. Now whenever you make a keyframe, it will Key all the Nulls and only on they're proper Rotation Attribute. A bit Tedious, but hey, it's essentially rotation orders.

[Suricate]

I'm sorry to say, but in my opinion the importance of rotation order is overrated. You cannot completely avoid gimbal lock by changing the rotation order, you can only make it less likely.

As a workaround, there is the possibility to use nested controls (as was already pointed out) or simply by adding pivot nulls so that the most important axis of rotation is set to heading and the least important axis is set to pitch.

[51M0N]

I agree with the above, gimbal lock is pretty much unavoidable... I haven't tried changing rotate orders to whatever app I've animated so far, and I've never really heard this being a common practice either. What I have heard though, is that if gimbal lock happens "just muscle through it", by using the editor's view to rotate or using nulls, or whatever else fits the situation.

Putting this aside, I find far more important the issue that we can't have world coordinate manipulators on the editor, and only have object coordinate ones.
I find it much easier to animate ik in world coordinates, and fk in local, and I hope this helpful option will be added soon, like the tons of options that exist when using poly/edge/point mode.

[Horganovski]

Thanks guys, I appreciate the info.

I've built nested nulls rigs before for this, like this one (http://horganovski.blogspot.com/2008/07/gramps-free-cinema-4d-rig.html)
but a problem I find is that using the sliders is unituitive, I'd much prefer to be able to just rotate the controller in the viewport and pose the character like a stop motion puppet.
I guess I could use 3 different controllers with two rotation axis locked out in each but that would be pretty tedious to animate and tweak in the F Curves.

One other issue I get with the nested nulls rig is that when I scrub the timeline I can see the arm rotating eratically as it transitions from key to key, it works fine when the timeline is playing but I like to scrub back and forth to approximate the equivalent of flipping in 2D and this won't work cleanly when using the nested setup. Maybe I need a faster computer so that I don't see this..

@Suricate, I'm curious that you said 'the most important axis of rotation is set to heading and the least important axis is set to pitch.' In this case would the nested nulls setup work better if the top parent rotates in H, the next child in B and the last in P ? The way I usually do it is just H, then P, then B.

Cheers,
Brian

[Cactus Dan]

Howdy,
In this case would the nested nulls setup work better if the top parent rotates in H, the next child in B and the last in P ? The way I usually do it is just H, then P, then B.
In my opinion your order for nested Nulls should be B,P,H. If you remember back to my rigging tutorials, and the section on rotations, the Bank angle is the most stable, so that one should come first.

The reasoning behind BPH order is:
You can rotate an object to some arbitrary orientation, and then set rotation keys of the object rotating on the Bank (Z axis), and it will behave as expected:
http://www.cactus3d.com/BankRotation.mov

The next one should be the Pitch, because if you remember, as long as the Heading is 0, the pitch will always rotate as expected:
http://www.cactus3d.com/PitchRotation.mov

So then that would make the Heading the only one left. ;)

I hope that helps.

Adios,
Cactus Dan

[Horganovski]

Many thanks for that Dan, that's very helpful, definitely makes it clearer, I do remember that from your tutorials but it had slipped my mind. I'm trying it now on my Gramps rig and it does work better, it seems that one rotation always gets unpredictable when the other two are rotated, even when they are nested but I see the logic of making the B and H the 'main' ones. Now that I've adapted the Gramps rig I can make him swing his arm forward and back from the shoulder predictably but the twist behaves differently depending on how his arm is pointing. I suppose I shouldn't twist from the shoulder too much and twist the hand/forearm more instead.


I hate to mention the 'M' word, but if it's not just a question of rotation orders as mentioned above, how does this work in Maya? I watched a tutorial recently where the author did everything on the arms in FK and was rotating the shoulders through many extreme poses and only had one or two gimbal issues which I think he fixed by selecting the offending keys and applying some kind of filter to them.

Cheers,
Brian

[Per-Anders]

Good rig setup to begin with, the joints need to be correctly zeroed and oriented so that gimbal lock is less likely to occur. Most people just set up their joint chains in C4D, and then lock in place as it and expect the IK to just behave as it should, but the trick is the zeroing out and setup before applying the IK. Using Quaternions and rotation order changes will help to a degree, but only during animation (their benefit is in transforms and blends). simply changing how your chain is oriented to begin with will have as much effect and the options are already there in C4D. What MOCCA does lack is dual transforms, which is much more of a help when setting up that good rig than the rotation order.

[Suricate]

@Suricate, I'm curious that you said 'the most important axis of rotation is set to heading and the least important axis is set to pitch.' In this case would the nested nulls setup work better if the top parent rotates in H, the next child in B and the last in P ? The way I usually do it is just H, then P, then B.

Brian, 'most important axis' and 'least important axis' refer to the way the joints rotate naturally in a character. For example, let's say you have a character in a T pose with the thumbs pointing forward. If you draw the joints in an arm straight down from the shoulder to the hand, your hand axes most probably are like this:

- heading: hand is rotating to the side
- pitch: hand is rotating up and down
- bank: hand is twisting

However, keeping in mind that in a hand the most important rotation (the rotation with the widest range) is twisting and the least important is the rotation to the side, I would add a pivot null betwen the arm and the hand in such a way that:

- heading: hand is twisting
- pitch: hand is rotating to the side
- bank: hand is rotating up and down

Another issue is that indeed you should always zero out the axes. In fact, when placing joints, I usally don't 'draw' the joints with the mouse, since this introduces some unwanted alignment. I rather copy the joints and translate/rotate them manually and add pivot nulls where needed.

[LucentDreams]

suricate, turn off the align axis in the joint tool and you can draw it with no rotations at all.

[Jannis]

does lack is dual transforms, which is much more of a help when setting up that good rig than the rotation order.

Amen to that for more ways than one!

[Suricate]

suricate, turn off the align axis in the joint tool and you can draw it with no rotations at all.
Ahh, that's cool, I wasn't aware of that option. Thanks!

[Horganovski]

Thanks for the reply Suricate, that's useful to know.

I'd agree with Per too that dual transforms would be great. Cactus Dans' Transfer Tools plugin offers a very usable workaround for this in the meantime.

Cheers,
Brian

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