Pole target and Inverse Kinematics limits


As you may be aware, currently adding a pole target in an IK constraint effectively ignores the bone limits set under the bone properties “Inverse Kinematics” panel, for any bone in the IK chain.

Bug or feature?

One could argue the very purpose of setting a pole target is so as to give the chain a point to lean towards (or in a relative direction depending on pole angle), and as such, chain bones should not abide by their IK limits in order to meet the pole setting. On the other hand, one may argue that setting per-bone limits, as a whole, is a more restrictive action since it involves purposefully tweaking one or more (and I put the emphasis on “more”) settings, and as such these limits shall be prioritized over the pole target. But then again, why would one set a pointless pole target should the latter case be the currently applicable one, right? Or why would one set an IK limit in any bone when the pole target will completely take over anyways? Well, it’s because both reviewed arguments are opposing oversimplifications; and no matter which one is the current default, both fail to provide a more satisfactory solution for cases that may fall in middle grounds. So it’s not so much a matter of discussing whether the current design is a bug because it fails to meet these latter cases, or whether it’s not because it effectively satisfies the case it was designed to satisfy. But thing is, there appear to be some cases that aren’t being completely satisfied, and this tool could be improved on to meet these and therefore become more flexible and versatile.

Use case example

The shoulder problem.

There’s this case where we’d want to move a whole arm, including the shoulder, by pulling or pushing from the hand. We can set an IK constraint on the forearm to this effect, set the target on the hand or on a helper bone after the forearm, then simply set some IK limits on the shoulder so as to limit it’s rotation since as we know, below around 90 degrees (being zero at the bottom), the shoulder stops going down and the arm takes over. Of couse we would also like to use a helper bone as a pole target our elbow will point towards, and at this point our IK limits become ignored and we’ll start scratching our heads wondering what’s wrong and how to work around it.


A simple solution is to choose one over the other and simply put up with it. This means you’ll either stop using the convenient elbow pole target and manually rotate your bones to meet your needs, or you will stop using your arm limits and manually correct your shoulder-arm junction every time you need it after positioning your elbow pole target. Now this is cumbersome.

Another solution would be to use drivers or a script to automatically perform the necessary changes to your pose as you move some bones. This has the drawback of requiring a little more experience or knowledge. I have personally tried this solution, and it could very well be that I have a very limited experience with Python and Blender scripting, but it didn’t work all that well and it performed rather slow.

Yet another potential solution would be (not)… Well, one might be tempted to use two overlapping IK constraints on the forearm (with a target on the hand or helper bone), by setting a pole target in one, with a chain up to and including the arm, and no pole target in the other one, up to and including the shoulder. This simply doesn’t work, and whichever constraint is set first is the one that will work, while the second one seems to be ignored.

Now, based on the aforementioned invalid solution, we can come up with a more satisfactory solution that for the most part will get the job done: Just like before, we can set an IK constraint on the forearm with an elbow pole target, with its chain set up to and including the upper arm, and we can then set another IK constraint on the upper arm with no pole target with its chain set up to and including the shoulder, both constraints with the hand or helper bone as a target. In this way, we still get our shoulder IK limits to work while the elbow will still lean towards our elbow helper bone. I was personally using this approach which seems to be satisfactory enough until 2.8 (where it doesn’t seem to work (yet?), as the forearm comes apart as if it was disconnected and positions in strange ways). However, this is still far from perfect: we can not enforce limits on our upper arm nor on our forearm since both belong in the chain of the first IK constraint where a pole target is used. As such, these bones may rotate in undesirable ways (for example, spinning around their longitudinal axis, local Y) depending on the location of the pole target.

Proposed solutions and reflections

So, assuming it is desirable to have IK limits work along with pole targets, here’s a couple of approaches to go about it. Note, however, I have absolutely no knowledge of how IK works internally, so these are mainly a depiction of potential desirable outcomes.

Pole targets could be assigned a length of affected bones, thereby ignoring any other bones in the IK chain and thus their IK limits would still apply. Theoretically this means, first the IK chain will adapt to satisfy the pole target, and then the IK limits of the bones unaffected by the pole chain will be applied (and pull from pole affected bones), thereby deforming the IK chain to respect the IK limits yet still providing (hopefully) the maximum admissible pole target influence.

A possibly more desirable variation of the aforementioned solution could be to simply discard the pole target chain length idea and operate as before: Come up with the most satisfying solution to fit the pole target, then apply IK limits for each and every bone. This has the “disadvantage” (or not) of being able to totally ignore the pole target influence. A possible consideration regarding this might be the order of bones in which limits are applied: forwardly, inversely or even outwardly/inwardly from/into the IK bone. Note that the aforementioned statement stems from a lack of understanding of how IK operates internally, and a lack of good enough an understanding of how IK operates generally, so it might be entirely disregardable; yet, if there’s a point to it and it’s indeed possible to apply these limits in different orders while making sense, it may be interesting to expose these to users through options.

A possible improvement upon the firstly proposed pole target limited chain length solution, could be the inclusion of the possibility to add several pole targets, to which each of them a given junction would be assigned as a point where the pole target would hold the maximum influence, and a chain length which may or may not be symmetrically laid on this first point; meaning the pole target chain may extend outwardly from the selected junction one or more bones in either direction, and the junction wouldn’t necessarily need to lay on the dead center of these (as long as there’s at least one bone in each direction, I suppose). While this might sound a little convoluted, it may have the potential to create more interesting and flexible rigs. Again, this “improvement” might be entirely disregardable if it’s indeed possible to recreate it by adding different IK constraints with different target poles and they would work well together. However, it may still be worth to give a little consideration to whether this scheme may be friendlier for users.

A call for help

I’d like to hear what experienced riggers have to say about these reflections, and I welcome them to join this discussion to refute, agree, add and whatnot… I’d also like to know what experienced developers have to say about this too, especially those who have ever been involved with IK in Blender.

Now, assuming something in the IK needs to be changed: as much as I’d like to help bringing about this, I have a somewhat limited experience in C/++ and definitely nearly no experience with the Blender code base nor an understanding of how IK works internally, and a very limited time to devote to the cause. So reading the relevant code over and over will make little to no difference for me. At the very least I would need assistance from experienced developers previously involved in IK to get a glimpse of how everything works at least on the surface, and then again, as previously stated, I’m not the most suitable person for this task. That’s why I’d beg these developers to do it instead.

References and related

This discussion originates mainly from here: https://developer.blender.org/T28313 with special consideration to the comment and .blend by koil.

There are also some discussions on BA that might be relevant: https://blenderartists.org/t/how-do-i-limit-the-rotation-of-an-ik-constrained-bone/631003 , https://blenderartists.org/t/pole-target-and-ik-limits-problem/546861 and possibly others.

Thanks for reading and best regards,



Only discovered this thread after spending days trying to figure out why limits don’t work in some cases.

There should be some warning or info in tooltip when adding pole target inside blender and it should be added to documentation: ik_solver and inverse_kinematics/introduction.

1 Like

As someone who’s been struggling with this for hours now, I consider it a bug. It makes no sense that I can only have rotation limits or pole targets. In other words I can have my character’s elbow point in the correct direction or I can have their shoulders not rotate 180 degrees. Some rigs I’ve seen use a Limit Rotation constraint to work around this, but why does it need to be worked around? Between this and trying to figure out what the heck bone roll is all about, rigging in Blender is infuriating.


Is there any update for this? This problem still exist in 2022.

1 Like

There is something of a “canonical workaround” now listed on the inverse kinematics documentation page. Make a second copy of your armature, name it “puppet” or something, and set up all the IK settings on that; then, use Copy Transform to reflect the IK transformations to your actual armature. Then, set Limit Rotation constraints on your actual armature. Now the armature will be “clipped” to the constraints.

In theory there’s supposed to be a way to use the iTaSK solver to make the solver itself aware of the constraints, but I haven’t managed to get it working yet…