IK/FK Switch Causes Mesh and Heirarchy Misbehaviour #70599

New Issue

Chris Jones · 2019-10-07T05:56:46+02:00

Chris Jones commented

2019-10-07 05:56:46 +02:00

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce 9600 GT/PCIe/SSE2 NVIDIA Corporation 3.3.0

Blender Version
Broken: version: 2.81 (sub 14), branch: master, commit date: 2019-10-06 14:05, hash: 54a9649e26
Worked: version: 2.79 (sub 7), branch: blender2.7, commit date: 2019-06-27 10:41, hash: e045fe53f1b0

Short description of error
I have a bone configured as an IK/FK switch (i.e. it's driving the IK Influence of an IK chain), and this bone is parented to the IK bone in the chain. When set to FK mode (so that the IK influence is 0), rotating the IK bone causes the mesh to glitch and deform incorrectly, as if it is fighting to decide which mode it is in. Additionally the switch bone stops following its parent.

This problem occurs in 2.80 onwards, and I have included a 2.79 version of the test file that does not display the issue (loading the 2.79 version into 2.8x reveals another bug that I'll report separately). It should be noted however that both versions display possible cyclic dependency behaviour, in that the mesh and the switch position can be refreshed by moving to another frame and back again.

Exact steps for others to reproduce the error

Load "IK FK Switch 2_8 1a.blend" and move the green bone in Z until it stops. This sets the IK influence to 0.

Select the yellow IK bone and rotate it. Notice that the mesh twitches and does not follow the bone, nor does the green switch bone.

Move the green bone back down so that the IK influence is at 1.

Move the small target bone at the top of the chain. Now the mesh is deforming correctly and the green bone follows its parent.

Load "IK FK Switch 2_79 1a.blend" into 2.79 and repeat these steps for comparison.

I've made a short 15 second video displaying the issue here: https://blenderartists.org/t/possible-ik-or-driver-regression/1183489

IK FK Switch 2_79 1a.blend

IK FK Switch 2_8 1a.blend

Thanks!

Chris

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce 9600 GT/PCIe/SSE2 NVIDIA Corporation 3.3.0 **Blender Version** Broken: version: 2.81 (sub 14), branch: master, commit date: 2019-10-06 14:05, hash: `54a9649e26` Worked: version: 2.79 (sub 7), branch: blender2.7, commit date: 2019-06-27 10:41, hash: e045fe53f1b0 **Short description of error** I have a bone configured as an IK/FK switch (i.e. it's driving the IK Influence of an IK chain), and this bone is parented to the IK bone in the chain. When set to FK mode (so that the IK influence is 0), rotating the IK bone causes the mesh to glitch and deform incorrectly, as if it is fighting to decide which mode it is in. Additionally the switch bone stops following its parent. This problem occurs in 2.80 onwards, and I have included a 2.79 version of the test file that does not display the issue (loading the 2.79 version into 2.8x reveals another bug that I'll report separately). It should be noted however that both versions display possible cyclic dependency behaviour, in that the mesh and the switch position can be refreshed by moving to another frame and back again. **Exact steps for others to reproduce the error** # Load "IK FK Switch 2_8 1a.blend" and move the green bone in Z until it stops. This sets the IK influence to 0. # Select the yellow IK bone and rotate it. Notice that the mesh twitches and does not follow the bone, nor does the green switch bone. # Move the green bone back down so that the IK influence is at 1. # Move the small target bone at the top of the chain. Now the mesh is deforming correctly and the green bone follows its parent. # Load "IK FK Switch 2_79 1a.blend" into 2.79 and repeat these steps for comparison. I've made a short 15 second video displaying the issue here: https://blenderartists.org/t/possible-ik-or-driver-regression/1183489 [IK FK Switch 2_79 1a.blend](https://archive.blender.org/developer/F7794172/IK_FK_Switch_2_79_1a.blend) [IK FK Switch 2_8 1a.blend](https://archive.blender.org/developer/F7794171/IK_FK_Switch_2_8_1a.blend) Thanks! Chris

Chris Jones commented

2019-10-07 05:56:46 +02:00

Added subscriber: @ChrisJones

Chris Jones commented

2019-10-07 07:00:29 +02:00

Addendum: It turns out the other bug I was going to submit may be related, so I'll include those details here.

When loading "IK FK Switch 2_79 1a.blend" into 2.8x, the IK chain no longer functions regardless of switch position, unless a keyframe is set on the switch bone, or the driver is deleted from the IK Inluence value and reapplied with the exact same settings (copying, deleting and pasting the same driver doesn't work however, it must be deleted and added again from scratch).

Steps:

Load "IK FK Switch 2_79 1a.blend" into 2.8x and move the IK target bone. Nothing happens.
Select the green switch bone and make a keyframe.

Move the IK target again, and the IK works.

In both this instance and the aforementioned one, unparenting the switch bone also allows the rig to function as it does in 2.79. There are still signs of possible cyclic dependency though, even with the switch disconnected from the hierarchy.

Addendum: It turns out the other bug I was going to submit may be related, so I'll include those details here. When loading "IK FK Switch 2_79 1a.blend" into 2.8x, the IK chain no longer functions regardless of switch position, unless a keyframe is set on the switch bone, or the driver is deleted from the IK Inluence value and reapplied with the exact same settings (copying, deleting and pasting the same driver doesn't work however, it must be deleted and added again from scratch). Steps: - Load "IK FK Switch 2_79 1a.blend" into 2.8x and move the IK target bone. Nothing happens. - Select the green switch bone and make a keyframe. # Move the IK target again, and the IK works. In both this instance and the aforementioned one, unparenting the switch bone also allows the rig to function as it does in 2.79. There are still signs of possible cyclic dependency though, even with the switch disconnected from the hierarchy.

Brecht Van Lommel commented

2019-10-07 08:47:52 +02:00

Added subscribers: @Mets, @angavrilov, @dr.sybren, @brecht

Brecht Van Lommel commented

2019-10-07 08:47:52 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2019-10-07 08:47:52 +02:00

Brecht Van Lommel self-assigned this 2019-10-07 08:47:52 +02:00

Brecht Van Lommel commented

2019-10-07 08:47:52 +02:00

There's a cyclic dependency here, open Window > Console to see details. It may have worked in 2.79 (with a delay and likely problems for render farms, motion blur, ..). But it's not supported and incompatible with multithreaded rig evaluation.

Dependency cycle detected:
  OBArmature/Pose Component/POSE_INIT_IK() depends on
  OBArmature/Bone.001/BONE_LOCAL() via 'IK Constraint -> Init IK Tree'
  OBArmature/Parameters Component/DRIVER(pose.bones["Bone.001"].constraints["IK"].influence) via 'Driver -> Driven Property'
  OBArmature/Bone.003/BONE_DONE() via 'Bone Target -> Driver'
  OBArmature/Bone.003/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone.003/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature/Bone.003/BONE_POSE_PARENT() via 'Pose -> Constraints Stack'
  OBArmature/Bone.001/BONE_DONE() via 'Parent Bone -> Child Bone'
  OBArmature/Bone/POSE_IK_SOLVER() via 'IK Solver Result'
  OBArmature/Pose Component/POSE_INIT_IK() via 'Init IK -> IK Solver'

The Bone.003 Y location drives the IK solver influence on Bone.001. But the Bone.003 Y location is also determined by this IK solver because it is a child of Bone.001.

What you can do is drive the IK influence with the Y location as specified by the user, before constraints and parenting. This would be done by adding a Single Property driver with path pose.bones["Bone.003"].location[1].

@angavrilov, @dr.sybren, @Mets, it would be great if Transform Channel drivers had an option for this, also to communicate that this distinction exists.

There's a cyclic dependency here, open Window > Console to see details. It may have worked in 2.79 (with a delay and likely problems for render farms, motion blur, ..). But it's not supported and incompatible with multithreaded rig evaluation. ``` Dependency cycle detected: OBArmature/Pose Component/POSE_INIT_IK() depends on OBArmature/Bone.001/BONE_LOCAL() via 'IK Constraint -> Init IK Tree' OBArmature/Parameters Component/DRIVER(pose.bones["Bone.001"].constraints["IK"].influence) via 'Driver -> Driven Property' OBArmature/Bone.003/BONE_DONE() via 'Bone Target -> Driver' OBArmature/Bone.003/BONE_READY() via 'Ready -> Done' OBArmature/Bone.003/BONE_CONSTRAINTS() via 'Constraints -> Ready' OBArmature/Bone.003/BONE_POSE_PARENT() via 'Pose -> Constraints Stack' OBArmature/Bone.001/BONE_DONE() via 'Parent Bone -> Child Bone' OBArmature/Bone/POSE_IK_SOLVER() via 'IK Solver Result' OBArmature/Pose Component/POSE_INIT_IK() via 'Init IK -> IK Solver' ``` The Bone.003 Y location drives the IK solver influence on Bone.001. But the Bone.003 Y location is also determined by this IK solver because it is a child of Bone.001. What you can do is drive the IK influence with the Y location as specified by the user, before constraints and parenting. This would be done by adding a Single Property driver with path `pose.bones["Bone.003"].location[1]`. @angavrilov, @dr.sybren, @Mets, it would be great if Transform Channel drivers had an option for this, also to communicate that this distinction exists.

Chris Jones commented

2019-10-07 10:30:24 +02:00

Hi Brecht, thanks for the fast response!

I suspected cyclic dependency was to blame, although I couldn't find anywhere in 2.79 (or in 2.81 until you now mentioned it) that confirmed it.

In 2.79 I can still produce frame lag that indicates cyclic dependency even without Bone.003 parented to anything though, e.g. by keyframing the bone chain in a couple of positions and Bone.003 in up and down positions, subdividing the mesh until it sufficiently slows the frame rate, and then scrubbing the timeline. While I thought I had reproduced this in 2.81 as well, it seems I can't now, so perhaps this indicates some other cause that has since been fixed.

Thanks also for your suggestion - I'll try that out once I get my head around where and how to apply such scripts. :)

EDIT: Ok I got it working. Thanks again!

Hi Brecht, thanks for the fast response! I suspected cyclic dependency was to blame, although I couldn't find anywhere in 2.79 (or in 2.81 until you now mentioned it) that confirmed it. In 2.79 I can still produce frame lag that indicates cyclic dependency even without Bone.003 parented to anything though, e.g. by keyframing the bone chain in a couple of positions and Bone.003 in up and down positions, subdividing the mesh until it sufficiently slows the frame rate, and then scrubbing the timeline. While I thought I had reproduced this in 2.81 as well, it seems I can't now, so perhaps this indicates some other cause that has since been fixed. Thanks also for your suggestion - I'll try that out once I get my head around where and how to apply such scripts. :) EDIT: Ok I got it working. Thanks again!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

IK/FK Switch Causes Mesh and Heirarchy Misbehaviour #70599

Load "IK FK Switch 2_8 1a.blend" and move the green bone in Z until it stops. This sets the IK influence to 0.

Select the yellow IK bone and rotate it. Notice that the mesh twitches and does not follow the bone, nor does the green switch bone.

Move the green bone back down so that the IK influence is at 1.

Move the small target bone at the top of the chain. Now the mesh is deforming correctly and the green bone follows its parent.

Load "IK FK Switch 2_79 1a.blend" into 2.79 and repeat these steps for comparison.

Move the IK target again, and the IK works.