Multiple IK chains influencing the same bone don't work #73051

New Issue

#73051-multiple-IK-constraints.blend

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: 26bd5ebd42
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 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.

**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: `26bd5ebd42` 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: [#73051-multiple-IK-constraints.blend](https://archive.blender.org/developer/F8291785/T73051-multiple-IK-constraints.blend) 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. ![blender281_rig_support.jpg](https://archive.blender.org/developer/F8270490/blender281_rig_support.jpg) ![blender281_rig_support_chain_length.JPG](https://archive.blender.org/developer/F8270492/blender281_rig_support_chain_length.JPG) Open rig_support_blender2_79.blend [rig_support_blender2_79.blend](https://archive.blender.org/developer/F8270500/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.

Novice commented

Added subscriber: @BlenderAmateur

blender-admin commented

#67232 was marked as duplicate of this issue

blender-admin commented

#61621 was marked as duplicate of this issue

blender-admin commented

#63136 was marked as duplicate of this issue

blender-admin commented

2020-01-13 13:55:59 +01:00

#73262 was marked as duplicate of this issue

Germano Cavalcante commented

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-01-13 13:55:59 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2020-01-13 13:55:59 +01:00

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

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 commented

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

Changed status from 'Confirmed' to: 'Archived'

Sybren A. Stüvel closed this issue

Sybren A. Stüvel self-assigned this 2020-01-13 16:36:38 +01:00

Sybren A. Stüvel commented

2020-01-13 18:03:18 +01:00

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.

The `finger1-1.R` bone is not connected to its parent. [The IK section of the manual](https://docs.blender.org/manual/en/dev/animation/armatures/posing/bone_constraints/inverse_kinematics/introduction.html) 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.

Nathan Vasil commented

Added subscriber: @vasiln

Nathan Vasil commented

2020-01-13 18:03:18 +01:00

@dr.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.

rig_support_blender2_81_16(1).blend

@dr.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. [rig_support_blender2_81_16(1).blend](https://archive.blender.org/developer/F8275973/rig_support_blender2_81_16_1_.blend)

Nathan Vasil commented

2020-01-13 18:57:31 +01:00

And, in anticipation....

allconn.blend

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

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

And, in anticipation.... [allconn.blend](https://archive.blender.org/developer/F8276071/allconn.blend) 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.

Novice commented

2020-01-14 08:31:34 +01:00

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

Sybren A. Stüvel commented

2020-01-20 15:54:21 +01:00

Added subscribers: @Mets, @angavrilov

Sybren A. Stüvel commented

2020-01-20 15:54:21 +01:00

In #73051#847932, @vasiln wrote:
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.

In #73051#848263, @BlenderAmateur wrote:
I also hope you can take a new look and consider what Nathan is writing.

We always consider what people are writing.

In #73051#847795, @vasiln wrote:
@dr.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 @Mets and he confirmed that two IK constraints influencing the same bone is not a good idea. @angavrilov do you know whether this was ever officially supported?

> In #73051#847932, @vasiln wrote: > 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. > In #73051#848263, @BlenderAmateur wrote: > I also hope you can take a new look and consider what Nathan is writing. We always consider what people are writing. > In #73051#847795, @vasiln wrote: > @dr.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 @Mets and he confirmed that two IK constraints influencing the same bone is not a good idea. @angavrilov do you know whether this was ever officially supported?

Sybren A. Stüvel commented

Changed status from 'Archived' to: 'Confirmed'

Sybren A. Stüvel reopened this issue

Sybren A. Stüvel commented

Added subscriber: @brecht

Sybren A. Stüvel commented