PDA

View Full Version : rigging counter IK_Arm twist w/exposeTM


malcoda
08-24-2007, 07:42 PM
Greetings,

Max8 sp3, windowsXPpro

I'm currently working on a rig. I would like to add in a Counter UpperArm twist for the IK arm. My upper arm has two bones, and I'd like the top bone ( at the shoulder area ) NOT to twist on it's X axis when the IKarm twists.

Currently I'm using the ExposeTm helper to find out the IK arm's total twist and then subtracting that value from the upper arm bone. It appeared to be working great, but then I noticed that if I simply pull the IKarm down into a resting position by the character's side...I'm seeing really strange X rotational values in my exposeTM helper, which of course is making my upperarm bone counter twist in a strange manner also.

Am I not using the ExposeTM helper correctly? Why are there such strange values showing up in the x rotation when the IK arm is simply pulled down to rest at the characters' side. I can clearly see that the IK bone is NOT twisting that much in the viewport.

Anyone have any thoughts on this?

malcoda

eek
08-26-2007, 04:08 AM
What is this upper arm bone relative to? thats that key. Because if it has a parent its x is relative to its parent space - so if you rotate it into a position where basically its relative x is getting gimbal'd then your twist value - gimbal'd 'x' may give you some problems.

Its best to alway give the animator a node, they can key which is a reference for the twist i.e a parent space for the twist so they can key out any pops and flips.

cheers,

Loud
08-29-2007, 01:18 AM
I think I'm trying to do something similar and I'm having the exact same problem. I'm trying to attach a "sleeve bone" on my character so that the sleeves won't twist when the arm does (the shirt and sleeves are part of the same mesh).

I don't mean to hijack this thread, I'm pretty sure that we're having the same issue though.

I captured a video to illustrate the problem. The movie first shows how my rig works in that the sleeve bone rotates with the upper arm in all axes except X. Then when I rotate over 90 degrees down the sleeve bone spins on X, which is a problem...

http://lunatech3d.com/temp/sleeve_bone.avi
(5 mbs, sorry I don't have time to make it smaller right now)

I have started from scratch a few times and I have tried several different ways of rigging this bone but each gives the EXACT same result.
1- Attached the sleeve bone to the upper arm and turned off inherit X rotation in the Link info.
2- LookAt controller looking at the elbow bone
3- Wire Parameters for the Y and Z axes using a ExposeTm helper

PEN
08-29-2007, 11:41 AM
What you are seeing are problems created by rotations. This happens in all software that deals with 3D rotations.

The Expose TM sounds like it is working correctly, you might just have to add another node to reference.

Q: When the arm is in the relaxed pose is the angle between the clavicle bone and upper arm bone past 90 degrees? I going to assume so as this is when you will start to see these sorts of problems.

What I would do is add a point helper and align it to the shoulder bone in position and rotation at the base pose. Link the point helper to the clavicle. In the Expose Tm (ExTm) helper uncheck use parent and then press the pick button and select the point helper that was just made. You are now getting the rotation value compared to the point helper and the local euler rotation value should read [0,0,0]. The idea of this is you know that you are starting as far from any rotational problems as you can be. If you do run into a situation where the angle is getting to tight then you can just rotate the point helper a bit to correct it.

Another issue is that the axis order could be wrong. Gimble problems are cause by the middle axis of any given axis order. For the default the ExTm is returning the rotation based on an XYZ order. If the Y axis is pointing forward at the shoulder joint then the X value is passing the gimble point. Change up the axis order so that Z is the middle axis and you are using an order of XZY. This will also help your problem.

Loud
08-29-2007, 02:55 PM
Thanks Paul! You're a godsend. I've had two miserable days working on this, but today is a good day.

What you said makes sense, and I was wondering about those axis orders. I can't wait to get home to try it out.

Thanks again, I'll have to buy your DVDs.

Aearon
08-29-2007, 10:54 PM
another solution to improve the behaviour of these twist bones is to actually change the upvector based on where the driving bone points. i'm using lookat constraints to do this so i'm talking upvectors, but the same would apply to the exposeTM method

a specific example for the shoulder:


let's say by default the upvector is pointing straight to the back. when you rotate the arm very far forward (more then 90 degrees), e.g. the character is touching his opposite shoulder, you will inevitably get flipping.

to fix this for a whole lot of situations you can add an automatic behavior to the upvector object: when the arm is pointing forward, you can rotate the upvector forward as well, when rotating the arm back, rotate it as well. this can be done fairly easily with expression or script controllers.

what i do is when the upperarm is rotated 135 degrees forward, so it's reaching over to the other side, i have the upvector point to the side in the direction of the clavicle bone. when the arm is rotated 90 degrees back the upvector is rotating 45 degrees in that direction. up and down motion shouldn't be a problem using this upvector system.

the same would apply to using exposeTM, you could apply this to the point PEN described, what you are doing is automatically changing your parent space to be able to read better rotation values.

eek
08-30-2007, 02:51 AM
another solution to improve the behaviour of these twist bones is to actually change the upvector based on where the driving bone points. i'm using lookat constraints to do this so i'm talking upvectors, but the same would apply to the exposeTM method

a specific example for the shoulder:


let's say by default the upvector is pointing straight to the back. when you rotate the arm very far forward (more then 90 degrees), e.g. the character is touching his opposite shoulder, you will inevitably get flipping.

to fix this for a whole lot of situations you can add an automatic behavior to the upvector object: when the arm is pointing forward, you can rotate the upvector forward as well, when rotating the arm back, rotate it as well. this can be done fairly easily with expression or script controllers.

what i do is when the upperarm is rotated 135 degrees forward, so it's reaching over to the other side, i have the upvector point to the side in the direction of the clavicle bone. when the arm is rotated 90 degrees back the upvector is rotating 45 degrees in that direction. up and down motion shouldn't be a problem using this upvector system.

the same would apply to using exposeTM, you could apply this to the point PEN described, what you are doing is automatically changing your parent space to be able to read better rotation values.

Its kinda like what Valve did with the shoulder skinning, they had a look at pointing to an object that was driven by the elbows world space postion - it allowed for better deformation.

Aearon
08-30-2007, 06:48 AM
yes this is very similar, internally i use the upperarm transform, x-axis and see where it points in the clavicle-bones space.

eek
08-30-2007, 04:04 PM
With an animation rig, im more in thinking that you should free up the 'bias' control of an animation twist rig to the animator. When automating it - i inevitably will always find a pop somewhere - and keying this pop out on as an overlay to automation only makes the problem worse.

The key is to layer controls but to free them up, this is where transform space play a vital role.Its the transform space you work in thats key - i.e you dont want to drive the control to fix the bias' rotation/position automatically, only then to hand key out the pops it generates. This is mainly due to adding up the rotations - you'd hit gimbal sometime - because itself still has to be relative.

You could underdrive the control, but then animators would just break it to allow more extreme twist - so its a fine balance.

CGTalk Moderation
08-30-2007, 04:04 PM
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.