-1
$\begingroup$

I have an IK constraint with a target at the hand, the problem is that the IK solver will prioritise getting the hands rotation right over getting the arms position right. For example if it is impossible with the constraints to have the hand at the desired location and rotation, it will move the hand in other ways to get the rotation right. I would prefer it get the rotation as accurate as it can after getting the position perfect first. So if I enable the IK for targeting position it will work, if I then enable rotation too, it will only work in very few cases - where it can acheive both rotation and position accurately. A huge majority of the time though the movement will break and the resulting position will be random to get the IK rotation to work. I want it the other way around, get the position right always and rotation if it can.

Thanks!

$\endgroup$
  • $\begingroup$ You should include your bone and constraint setup. If you did setup it right there is no such problem. $\endgroup$ – Jaroslav Jerryno Novotny Nov 4 '15 at 13:15
  • $\begingroup$ I am making an example file that demonstrates a proper IK arm setup. $\endgroup$ – Italic_ Nov 4 '15 at 19:31
0
$\begingroup$

What you're describing sounds like an IK arm done wrong. When done right, an IK arm will allow you to translate the hand, rotate the elbow into position, and rotate the hand into the right orientation. I've included an example file to demonstrate.

Axis Alignment

When you make a bone chain for IK, it is best to create them on a single plane (x,y plane) to keep them all lined up. An IK constraint is dependent on the angles between bones, so having bones misaligned will spell disaster for the solver. In my demo file, enable axis display in the armature properties and go into a right-side orthographic view. You should see all the X and Z axes aligned to the global axes. Y axis does not matter in this particular instance.

enable-axis-display

axis-alignment

This axis alignment matters because the solver calculates the best position for the intermediate bones based on the angle between arm.up and arm.low (in the demo file). It tries to get the bones as close to their original angle difference as possible. If the axes are misaligned, this is unpredictable and easily breaks.

Pole Target

There are multiple elements that play into the pole target's functionality, too. The first and most obvious is the need for a target in the first place. This allows you to manually adjust the position of the elbow after positioning the hand. In the IK constraint settings, there are settings for target object, target bone, pole target object and pole target bone. In my demo the target is the pole.target bone, visualized as a pyramid in the viewport.

In order for a pole target to work, you need to have some sort of angle between the intermediate bones. In my demo file, select arm.up and go into edit mode. Open the properties (N) and look at the difference between the Y value of the tip and base of that bone. This one centimeter difference (could be less, actually) creates an angle on the bone's Z axis between arm.up and arm.low. This angle gives the pole target a starting point on its math. It uses this angle to determine the direction the bone chain will point during calculation.

bone-head-tail-offset

Hand Transforms

This last piece will get your hand to orient in the right direction. In the IK solver, there are two options for the IK weight: position and rotation. By default, position is selected and has full weight, and rotation is disabled with zero weight. Leave these the way they are. Enabling rotation behaves unexpectedly and unpredictably. We solve this with a copy rotation constraint. Select ik.target, then shift-select hand.ik. Add a copy rotations constraint. This adds a constraint to hand.ik with a target bone of ik.target. At the bottom of the constraint options, you have an option to change the space. This means the transform coordinates of the object. By default, they are set to world space <-> world space, which is what we want in this case. This copies the exact world orientation of the ik.target bone into hand.ik.

constraints

Conclusion

By now, your arm IK should be aligned, safe and predictable to handle, allow translation of the hand, allow manual control of the elbow and allow manual rotation of the hand independently from the arm. This is a proper IK setup. Obviously, every case will be different in its specifics, but this is the idea.

I will edit this answer with one more piece of information when I get back to the computer.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy