Page MenuHome

Multiple IK chains influencing the same bone don't work
Closed, ResolvedPublicBUG

Description

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: Intel(R) UHD Graphics 620 Intel 4.5.0 - Build 25.20.100.6472

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash: rB26bd5ebd42e3
Worked: 2.79

Short description of error
I have a rig for a human. In blender 2.81 I set IK constraint (chain length 5) on the wrist and when I move it the finger bones follow. I set another on the thumb (chain length 4). Now when I move the wristIK the thumb bones stay where they are, they don’t follow. If I lower the chain length to 3 the thumb bones start to follow the wrist.

Exact steps for others to reproduce the error
Open this file with blender version 2.81a:

Select wristIK and move it around. The bones that are the thumb (finger1-1.R, finger1-2.R, finger1-3.R) doesn't move.
Select finger1-3.R and set chain length to 3. Now when the wristIK is moved around the bones follow.


Open rig_support_blender2_79.blend

with blender version 2.79b. In this blend file the bones follow when wristIK is moved even when chain length is set to 4 for finger1-3.R.

I hope this is a bug and chain length should work the same between the versions. Because this is an animated character and I was hoping to be able to append it in newer blender versions and get the same result. With this behaviour the vertices gets wrong and if I lower the chain length I have to redo everyting.

Event Timeline

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Jan 13 2020, 1:55 PM
Germano Cavalcante (mano-wii) triaged this task as High priority.

I can confirm.
In blender 2.79 this used to work.
And it's broken since the early versions of 2.80

Sybren A. Stüvel (sybren) claimed this task.

The finger1-1.R bone is not connected to its parent. The IK section of the manual states:

The IK chain can only extend from a child to a parent bone if the child is connected to it.

As far as I can see, this has been in the manual for three+ years.

The fact that something used to work in 2.79 is thus mere coincidence. You could argue that an unconnected chain shouldn't even be allowed, and that the user interface should show a warning about this, but that would be a new feature and not a bug fix.

@Sybren A. Stüvel (sybren) Please take another look. The issues remain if you connect finger1-1.R to its parent. If you need, I've done this for you in the attached file.

Note the behavior in the file: moving the IK target for the thumb isn't a problem, but moving the IK target for the hand leads to the thumb becoming disconnected.

In playing with this trying to troubleshoot BlenderAmateur's problem, I noticed some weird twitchy behavior that looks like Blender's behavior when faced with dependency loops, although the console shows none. The IKs seem to fighting rather than equally contributing, with whichever being manipulated most recently taking precedence. Given this and when the issue arose, I would suspect a bug in the dependency code.

And, in anticipation....

All bones connected (about three seconds of work), issue persists. Tested in 2.81 release, 2.81a release, 2.82 beta hash 0ef881cc5782, 2.83 alpha hash f6aac92ab828.

Sorry, every time I type those hashes it does that inappropriate automatic markup, don't know how to tell it not to do that.

I also hope you can take a new look and consider what Nathan is writing.

Sorry, every time I type those hashes it does that inappropriate automatic markup, don't know how to tell it not to do that.

That's not inappropriate, that's a link to the actual commit. Very helpful for us.

I also hope you can take a new look and consider what Nathan is writing.

We always consider what people are writing.

@Sybren A. Stüvel (sybren) Please take another look. The issues remain if you connect finger1-1.R to its parent. If you need, I've done this for you in the attached file.

Thanks for that.

In playing with this trying to troubleshoot BlenderAmateur's problem, I noticed some weird twitchy behavior that looks like Blender's behavior when faced with dependency loops, although the console shows none. The IKs seem to fighting rather than equally contributing, with whichever being manipulated most recently taking precedence. Given this and when the issue arose, I would suspect a bug in the dependency code.

This isn't a dependency cycle, but that doesn't necessarily mean it's a supported situation. I've discussed this with our in-house rigger @Demeter Dzadik (Mets) and he confirmed that two IK constraints influencing the same bone is not a good idea. @Alexander Gavrilov (angavrilov) do you know whether this was ever officially supported?

Sybren A. Stüvel (sybren) reopened this task as Confirmed.Jan 20 2020, 4:57 PM
Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".

Checked with @Brecht Van Lommel (brecht), and this is supposed to work indeed.

Sybren A. Stüvel (sybren) renamed this task from Child bones doesn’t follow parent when setting IK and chain length to a specific value to Multiple IK chains influencing the same bone don't work.Jan 20 2020, 4:58 PM

I'm still trying to get a grip on what is supported and what is not. Here is a simple test file made in Blender 2.79b:

This file has two chains, and the left/right tip bones are IK-targeted to the toruses. As long as both IK chains are equally long (in this case 3, left image), it all works fine. However, when one chain ends in the middle of the other chain (in this case 3 and 4 for resp. the left and right bone, right image) things also break in 2.79b:

Opening the above file in current master (rB2e9d5ba2115ceabdc) also works fine:

@Brecht Van Lommel (brecht) can you shed some light on what is actually supported and what isn't?

Bone parenting should never break like that, so this means there is a bug in 2.79 too.

The IK solver does not support a way to limit the influence of an IK constraint within an tree structure, it will always go all the way to the root of the tree structure. So I think the fix for this is automatically increasing the length of the shorter chain internally, so it goes up to the same root bone.

Actually I'm not sure about the solution of making the chain lengths the same. In the rig_support_blender2_79.blend file there is useful behavior without that. I believe evaluating it as two separate IK chains one after the other like that was an intentional feature.

The problem in rig_support_blender2_79.blend is in the new dependency graph, if you use --enable-new-depsgraph in 2.79 it fails as well. Seems like a missing dependency, where it's re-evaluating only one of the two required IK chains when moving the wristIK object.

The case in simple_279.blend is a bit different in that there is no obvious order in which to evaluate the two IK chains like there is in rig_support_blender2_79.blend. So for that case it probably still makes sense to treat it like a single tree structure, though it's not as important to fix since it's easy to solve manually by tweaking the chain lengths.

I think the most important thing is to fix what seems to be a missing dependency for the rig_support_blender2_79.blend case.

@Sybren A. Stüvel (sybren)

That's not inappropriate, that's a link to the actual commit. Very helpful for us.

Markup on the hashes is now gone, but I still have the original page up; on that page, it links not to a build for me, but to a particular issue. First links to Fix T71620: broken particle collisions due to rB0666ece2e2f9 ( https://developer.blender.org/rB0ef881cc57829471c441367ada6bf88119eaf26a ) which, of course, is not relevant to this issue. But of course it doesn't matter, if it links you to what you want, I'll continue to post hashes in the same way in future comments. Just offering because whatever behavior is going on might lead to users posting fewer hashes than they otherwise would, and of course hashes are going to be useful to y'all. (And because there might be some back-linking code setup that joins unrelated issues inappropriately, confusing folks incl. devs.)

Markup on the hashes is now gone, but I still have the original page up; on that page, it links not to a build for me, but to a particular issue.

I see where the confusion comes from, I agree it's not that clear. It is a particular revision in Git, which fixes that particular issue. And yes, it does sometimes cause links between unrelated things.

if it links you to what you want, I'll continue to post hashes in the same way in future comments.

👍