1
$\begingroup$

I can't get the IK arm to behave the way I'd like. There are bones behind the arms that are used as pole targets. When the pole targets are active the elbows behave nicely but the shoulders rotations were no longer locked the way I set them. I know that I could replace the shoulder (that only rotates along the one axis) with a ball joint. Then the Pole Targets would work, but this isn't the look I'm going for.

enter image description here

In the FK example on his right arm, it's simple to rotate the shoulder 360 degrees along the global X while maintaining a persistent elbow direction relative to the shoulder.

Is there some kind of deep knowledge wizardry that would allow my IK elbow to animate this way? Something like a pole target that respects the axis locks on the shoulder and is parented to the rotation of the shoulder? Maybe constraints???

$\endgroup$
5
  • 1
    $\begingroup$ I'm not sure what you really want. It appears that you disconnected 'Hand.R' connected from 'Arm.R.001'. We generally want all FK connected to inherit position and location from the parent bone. I then did what you already had on the left arm: IK to the 'Arm_IK.R'. If you correct this: what then is the problem you're facing? $\endgroup$
    – james_t
    Jan 19 at 19:20
  • $\begingroup$ The disconnected hand was an accident, but I reconnected it, reactivated the IK, and the elbow was still flipping all over the place especially when you raise the IK handle over the shoulder with the arm pointing forward or backward. I turned off the IK on the right arm to demonstrate the kind of elbow behavior I'm hoping to get out my IK. The left arm has my best attempt at the IK which was on both arms before $\endgroup$
    – Zach Bowen
    Jan 19 at 20:56
  • $\begingroup$ There are bones behind the arms that are used as pole targets. When the pole targets are active the elbows behave nicely but the shoulders rotations were no longer locked the way I set them. $\endgroup$
    – Zach Bowen
    Jan 19 at 21:33
  • 1
    $\begingroup$ Repost your corrected blend file with your corrections and I'll take a look. In the file I saw, there was not keyframes on 'Arm_IK.R'. so I also could investigate further. You animated the left side using IK, but right side using FK bone rotations? Why? Name a bone where you are using pole targets. $\endgroup$
    – james_t
    Jan 19 at 21:33
  • $\begingroup$ Thanks for your help James! I swapped out the .blend in the question for the one with the changes. $\endgroup$
    – Zach Bowen
    Jan 19 at 22:02

1 Answer 1

1
$\begingroup$

You basically have two options to get rid of IK twitch on this model.

Your first option is to use the ITASC solver in simulation mode. With armature selected, look on properties/data/inverse kinematics. When you use the ITASC simulator, the IK will prefer angles relative to the last frame, rather than to rest or pre-IK orientation. This will eliminate any IK twitch for your structure. You will probably want to discard your angle limits on Arm.L.001 if you do so-- they can only hurt the solver in this case.

If you want to control the "elbow"-- keeping in mind, you have very limited ability to control it-- you can sandwich in a parent to Shoulder.L and locked track a marker. This will change the position in which the IK is evaluated. Keep in mind that any changes to this are going to be discontinuous, because of the nature of your arm, and that any live changes are going to be disregarded by the ITASC IK, because it's going to just prefer the smallest legal angle to last frame, regardless of what the parent of the chain does.

enter image description here

Keep in mind that ITASC simulation relies on a running cache of bone orientations. If you just jump through the timeline, the solver will not be showing you what it will really do. To see what it will really do, you need to play the animation all the way through from frame 1. It's basically all the headache of physics-- in a way, it is physics, a simulation of bone inertia.

Your other option is to just cheat. It seems to me that the reason that Blender cannot find the proper angles in some frames for your structure is because the actual range of motion is really, really tight, and I think Blender is getting into precision issues. So how to cheat? Make it a ball joint, but just small enough of one that it won't look wrong: give Arm.L some Z or Y axis allowance, in the -3, 3 degree range or something. This is enough for Blender to get over its precision problems (when used in conjunction with proper angle limits or base angles to make sure that Blender chooses a consistent direction of bend.)

$\endgroup$
1
  • $\begingroup$ Thank you so much for taking an in depth look at this for me. I really do appreciate it. The ITasc solver seems to be cleaning things up a lot, but I'm not seeing the effect of the locked track constraint on the shoulder. The cheat option sounds really nice but the elbow is still losing its mind. With this quirky set up I've got here, I'm considering just giving in and going FK. Maybe I'll try a more simulation assisted animation solution like Cascadeur. $\endgroup$
    – Zach Bowen
    Jan 23 at 0:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .