(thanks Dave F.)
Utility for Finding Center of Edge Loop
//from otto leffler
SelectEdgeLoopSp;
ConvertSelectionToVertices;
CreateCluster;
select -cl;
Managing Multiple Skeleton Poses (TD Matt)
Craig Monins talks about COG:
http://www.youtube.com/watch?v=509huTkNcVY
- global node for all positioning
- cog/main control should be right between the 'hip' (or 'upleg', on my rig) controls.
- your independent 'hip swinging' control should be PARENTED to the main cog control, but placed a little higher up than the upleg joints.
- add offset object to root node so if your root gets into gimbal lock, you can animate more rotation on top of it.
- you can also move this offset object so that you can move the center of rotation for your char.
(and here's his whole standard rig--the offsets are a nice touch)
http://www.youtube.com/watch?v=Ug3ilGJczCE
"I find setups of things like animatable pivot setups a bit alien sometimes for some animators who'd rather just grab something and pull than mess with more "technical" controls, and since my main app doesnt do such things as animated pivots with any ease I just use this whole hierarchic solution that gets me around it, and gimbal lock, and a whole host of other thigns at the same time, the aim being to have a rig where the animator can just grab a bit, and move it somewhere."
(Charles Looker) "Same here, Animatable Pivots are one of those technical holy grails for a TD, but in practice not that great. For animators - what i've really found working with animation is that they like to see really what system your in, and where that system came from. Things that are tucked away or hidden under layers of 'offset' and 'pivot' etc cause lots of pain in the end."
From Brad Clark:
- cog should be a control, not the root of the character
- if you want to take in mocap data or rig a muscle system, your skeleton should be as anatomically correct as possible.
- try to make the leg a straight line, but you will get nicer deformation if you run it to the outside.
For a cartoony spine, you can run it close to the center.
For a more realistic human spine, makes sense to run it closer to the back of the mesh, where your real spine runs. Bear in mind that in real anatomy the ribcage is not very flexible, and the thoracic vertebrae will barely move at all.
As a rule of thumb, halfway between a position central to the mesh and true anatomically correct position is a good starting point for areas such as the spine. (TD Matt)
Hip
main hip joint is located at top of pelvis, more or less at the point where the coccyx (tailbone) attaches to the pelvis
For cartoony chars, you can cheat it lower..
T-bar position: The legs are in the same ty & tz as the hip joint. Advantage is that you can turn the hip control without having the characters feet leave the floor. Also the ideal position for motion capture. (TD Matt)
Disadvantage is that it's not as anatomically accurate and may not work with the model.
-your rig should be able to lift the elbow above your head and wrap it around, grab a giant sword on his back, hands should be able to meet behind back
-so, put clavicle up out front where real clavicle starts its rotation
(Brad Clark)
ie, it should be very close to the center of the body, which is where your real clavicle rotates from (touch it!), and somewhat to the front of the body center.
From Brad Clark:
-place in middle of joint area, and slightly higher
-build two pivot points--one (higher) for lifting and one center for arm 'roll joint'
**very tricky! strongly recommend test skinning to make sure it looks ok.
(Adv. Rigging & Deformations)
put slightly out from where arm attaches to torso
- run twds the back, close to the surface for hard weighting.
(Adv. Rigging & Deformations)
Try bending the elbow up- the length of the elbow & hand should be slightly greater than length from shoulder to elbow.
Is there a good way to orient the thumb automatically?
As a rule of thumb (haha) you can angle it at about 45 deg. from the rest of the fingers..
place high and forward in the mesh. Add metaCarpals.
(Adv. Rigging & Deformations)
At least add one for the pinky finger so that you can cup the hand. And add others if you are aiming for realism. Cartoony characters may not need it, but more realistic chars. will.
T-bar position: The legs are in the same ty & tz as the hip joint. Advantage is that you can turn the hip control without having the characters feet leave the floor. Also the ideal position for motion capture. (TD Matt)
Disadvantage is that it's not as anatomically accurate and may not work with the model.
For arms and legs with roll joints set up you will find that very off-centre joint positioning will give undesirable deformation when twisted.(TD Matt)
- upper leg joint (technically hip joint?)starts more forward than the base of the spine
- try to make the leg a straight line, but you will get nicer deformation if you run it to the outside.
(Brad Clark)
In a human-type biped, your two leg bones should be approximately equivalent in length so the leg can fold well. Try it on your own legs!
video ref from NoneCG
If possible, keep lengths of three main bones close to the same, and make the first and third bone parallel to e. other. This way you will have better movement with an ik solver (Josh Carey)
- the real one orbits around the lower leg bones, so it can be placed a little higher in the setup.
(Brad Clark)
If it's a barefoot character, try n place it near the "lump", aka the tibia, 'cuz if that part moves it looks kind of weird. In real life, that stays still while your foot rotates around it as if on a hinge.
In humanoid characters, near the bottom of the ear
Q.
I'm having an issue where an ik RP solver on a leg will sort of
'freeze up' when the ik handle and the character hit a certain pose.
For instance, everything will work fine when you scrubbed up to frame
50, and then the knee joint would 'lock' to whatever the preferred
angle was set at (i.e., <<0,30,0>>). The kicker is that you could
then scrub *backwards* and the solver would still be locked. If you
changed any other inputs to the joints being solved, like the scale
for a stretchy leg, the solver would seem to 'pop' back to solving
correctly.
When rigged, the joints are oriented to a plane, the handle is
connected while the joints are bent, the pole vector is placed along
this plane, and a preferred angle on the joints is set...so I think
I've got my bases covered there.
So IMO, there's some black magic happening in the ik solver
computation that I don't understand. Another oddity is that setting
the preferred angle for the joints at, say, 30 degrees wouldn't fix
the problem, but setting it at 90 degrees would (at least for now, but
who knows when this will rear its head again?). My guess from the
scrubbing issue is that the node doesn't do a full computation unless
certain input plugs change. It's hard to say, because an ik handle is
one of those nodes that (for some reason) doesn't actually have
connections to what it's changing.
I would LOVE to get my hands on the algorithm that's used to compute
and set the joint rotation values. Any Autodesk people in the
house ? :)
(JP)
A.
Yes, I have seen this happen a few times before.
All I can say from my experience is that when you're scrubbing the timeline,
the IK RP solver does not do a full calculation, similarly if you did a
dynamics solve and scrub the timeline without maya doing an initial
iteration for each frame. From my understanding the rotate plane is just a
way to get out of the gimbal lock with the IK algorithm (Im guessing, it is
because the solver uses euler angles in its maths)
Id bet it would be extremely difficult to get a hold on Mayas IKRP solver
algorithm. There are a few studios out there that uses their own in-house IK
solver plug-in to workaround Maya's.
****
Yeah, I too had the impression that the preferred angle is based on the
slightest value.
But by the way, the popping occurs only when you scrub the timeline. The
popping wont occur if you allow the solver to do its necessary computations,
so playblasting would be ok. So its not a major issue, just annoying when
you animate
Do you have joints fully lined up straight?
Its also possible if you imported your rigs, there is another IKRP solver in
there? Preferably the one scene (or the one rig) should have on IKRP solver
solving for all IKRP handles
Is it a flipping issue you are having? The pole vector simply tells the
rotatePlane where that plane is (eucledian space). So what my workflow is
simple
(i) Set up preferred angle
(ii) Copy joints before setting up ikHandle
(ii) Point the pole vector so it works for you. (eg X=1.0, Y=0, Z=0) The
joints will twist.
(iv) Play with the twist until the joints lined up with the copied joints.
It is not super accurate, but it works out for an animation context as
opposed to an cad engineering context.
(Jeremy YeoKhoo)
Preferred Angle
I have had this EXACT same thing happen recently. RP IK locking when
the joints are straight scrubbing through the timeline. I fixed it in
the exact same way, as well : set preferred angle to 90 degrees. I
first tried a slight angle of 1 degree then 30 degrees figuring it
wouldn't matter the actual value. However, only 90 degrees worked all
the time.
Another clue,though, was that I had an expression controlling the
scale value of the joints in the IK (typical stretchy IK). This
problem went away when I broke that scale connection. So, that has
something to do with it, for sure. My assumption ended up being that
the scale was changing the inputs (joints) to the IK solver thus
triggering a re-initialize process of some kind and when the scene was
scrubbed to a frame where the joints were straight, the solver needed
the preferred angle to know what plane to use. I have no idea why it
works with 90 degrees and not with 1 degree
(Todd Taylor)
In most cases (ie., chains with three or more joints), you can solve this problem by setting the preferred angle of the middle joint. However if you are trying to set up an RP Ik chain betw. two joints, it can calculated the pole vector randomly, which can be irking.
The best solution I found so far (tried messing with rotation order as selected below but it didnt' seem to make a difference) is to note the 'ikHandle.poleVector' attribute. if the value is not in the axis where you want it to be--for instance, you want the vector to be constrained forward in Z, but it is created in neg. X--then you can constrain the chain as planned. Get the rotation value that occurs on the joint, and then feed the reverse of this back into the 'twist' attr of the ikHandle.
This will only work for clean chains that have joint orient vals in only one axis. For setting up constraints on joint chains that move in many different planes:
The SOLUTION is to point constraint the pv controller to the first and last joints [shldr and wrist] and then aim constraint to the joint in the middle [elbow]. Then translate the controller back and create the constraint on the ik handle.
(dragst)
Meghdad Asadi on Lester Banks - EZ No Math Calculate your Messed Up Pole Vector
Marco Giordano on Lester Banks -Perfect Pole Placement with Python (Requires Math)
***************
I think you have to set preffered angle on your joints to avoid this. I encountered the same problem setting up RP solver IK's on every joint in a spine (for divine spine).
The problem becomes accute on joints which are pointing straight up relative to worldspace, and also when you are applying rp Ik's between just two joints, I guess because maya has a hard time figuring out how they would bend.
Setting the preffered angle before IK-ing should fix it.
Ooops. Have tested it out and it dosen't work either. Hmmmm.
What I did find out is that the root joints which have the problematic pole vectors seem to be doing it because of gimbal lock. You could test this out by temporarily parenting your root joint to the world (if it isn't there already) and checking the joint rient values. Try imputing these into a null or empty joint's rotation values and test the rotation. Voila. Gimbal lock.
I suspect that maya has a hard time placing rp IK's on single joint chains with joint orient values that produce gimbal lock. I don't know if this also affects joint chains with more than two joints.
(isoparmB)
Skeleton Layout (TD Matt)
