I've been working on an anatomically accurate armature system for some time and I'm about 90% of the way there mechanically speaking, but now I've encountered a rather strange phenomenon whilst trying to render a sample animation. I had noticed this happening while I was making the armature, but I assumed it was lag, and wouldn't show up in a rendered animation, but observe below:

I tried to make this a gif but it kept spitting out at 4.6mb for some reason, so here's a link to three seconds of .webm to demonstrate my problem. Weird fingers

I have seen this question, but I have a hard time accepting that the only solution is to add more bones to the fingers. And I'm not even sure how I would do so to achieve the same results in that case.

One thing I tried to do was keyframe the IK target and pole bones in line with the rest of the animation, but that changed nothing. The affected bones seem to be the actual finger bones, just after the knuckles.

If I move the hand guide bone to somewhere, the fingers won't update until I select another bone, then they catch up and go where they're supposed to. Is there a way to force an update like that every frame?


I read some more and I began to suspect that the IK may be part of my problem, so I tried 2 things. First I tried disabling the IK entirely, and that seemed to solve it, though of course then I'd have to control the fingers some other way (eyeroll). Then I tried setting the IK to include the bone before the knuckle area, which also solved the lag issue, but then of course that bone moves entirely too much to be realistic, and when I try to constrain it, it looks even worse.

So obviously neither of those are ideal, but if I have to do without the IK, I could make some overcomplicated driver stack to perform the same functions, like freaking rigify, eugh.

Here's a sample file.

Update #2

I have done some more experimentation and discovered that I had a dependency cycle with a Maintain Volume constraint on the main finger bone. Now, I can't tell why that's creating a dependency cycle, but if I disable the driver, the fingers don't lag anymore. But then of course, the squish I made that driver to combat comes back, and I really don't have any other way to fix that.

I really wish Blender's armature and Driver system could do more than elementary school math.

Anyway, knowing that's what was doing that doesn't really solve the problem, because now I need a way to drive that constraint that won't create a dependency cycle.

  • 1
    $\begingroup$ it's hard to tell without seing your setup. I suggest you to upload a sample file on Blend-Exchange and share the link here with us so that we can dig in. $\endgroup$
    – L0Lock
    Jan 3, 2023 at 21:30
  • $\begingroup$ I don't like blend exchange, but I can put up a copy of the rig on litterbox and link it. $\endgroup$ Jan 3, 2023 at 22:11
  • 1
    $\begingroup$ Why don’t you like blend exchange? It’s literally the official site for sharing blend files on the blender stack exchange. $\endgroup$
    – TheLabCat
    Jan 3, 2023 at 22:21
  • $\begingroup$ Oh, I guess I was thinking of one of the blender marketplaces. Well alright, I can put it there. Nope, never mind, I just read the terms, I don't like giving them "unrestricted rights" to whatever I upload. $\endgroup$ Jan 3, 2023 at 22:24

1 Answer 1


Your metacarpals and proximal phalanges bones all have a Maintain Volume bone constraint:

maintain volume constraints

I'm not sure exactly why you use them, but removing them seems to fix the evaluation issues. Might be a bug, or a normal behavior. Maybe try to report it as a bug via the menu Help > Report a bug and see what the devs say about it.

To quickly remove them, select all the concerned bones and press ⎈ Ctrl⎇ AltC.

On another note, your fingers IK setup seems really weird to me:

ik setup

Each of your fingers' IK is setup to influence from the wrist up to the finger nail. That's a very odd way to rig, and definitely not very animator friendly.
Common IK fingers often lets the animator control either the whole finger (from proximal to distal phalanges) or even better: the distal phalanx is the IK controller. This way, the distal phalanx can be moved and rotated around, while the IK solver influences only the proximal and intermediate phalanges.

In other words, I would reduce the IK Constraints' Chain Lenght to 3 if I were you. Or make the distal phalanx the IK controller, and reduce the Chain Lenght to 2.

The optimal IK chain length in terms of balance between controllability and accurate result is 2 anyway.

  • $\begingroup$ Yeah I figured out the modifiers were causing the dependency loop yesterday, but removing that brings back the finger squish problem, as noted in one of my updates to the OP. I've since removed all the constraints and drivers from the armature, and have begun from the base bones and am trying to make an independent set of volume maintenance bones that can't have dependency loops. $\endgroup$ Jan 5, 2023 at 0:57

You must log in to answer this question.

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