IK - can you prioritise position targeting over rotation?

Question

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!

Answer 1

Yes, you can do this by building some extra bones into the IK chain to "relieve pressure."

Here's what we'll start out with, based around the idea of an arm IK with rotation, including the clavicle and hand:

Bone 4 will do anything it can to match the rotation of ikT, including, failing to meet the position of ikT (which might happen because of the chain bones' angle limits or locks.) But if we add two more non-deforming bones to the IK chain, we can relieve rotational pressure on 4:

Bone 6 is axis locked in all axes, so it will never have any local rotation. But its parent, bone 5, faces exactly opposite, and is the exact same length as bone 4 and as bone 6. It can rotate to relieve rotational pressure on the 1-4 components of the chain. But doing so never relieves positional pressure on the chain, because 4, 5, and 6 in conjunction can never affect the position of the tail of 6, because the bones are all the same length, and bone 6 is axis locked. Bone 5 can rotate as needed to match the IK constraint, but no matter how it rotates, the tail of bone 6 will always lie at the same position as the tail of bone 4.

This gives some strong rotational pressure relief. This will relieve pressure even when it is not necessary to do so. But if we increase the stiffness of bone 5, it will avoid rotating unless necessary to meet the needs of the constraint-- needs that include both position and rotation. We could give bone 6 a high stiffness in all three axes. at which point it will pretty much never rotate unless it absolutely has to. (However, using stiffness in conjunction with rotational constraints can create IK twitch, and I recommend against it. If you can fudge rotation but not position, just let it fudge the rotation. You'll still get something that is mostly what you want.)

Answer 2

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.

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.

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.

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.