Contradictory UI display of functional properties in the Inverse Kinematics Panel, despite Auto IK Option being Enabled #119678

New Issue

Pxy-Gnomes · 2024-03-19T20:19:45+01:00

Pxy-Gnomes commented

2024-03-19 20:19:45 +01:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: AMD Radeon(TM) Graphics ATI Technologies Inc. 4.6.0 Core Profile Context 23.4.3.230420

Blender Version
Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: 9be62e85b727
Worked: (newest version of Blender that worked as expected)

Short description of error
The Inverse Kinematics Panel is displaying contradictory information, about the potentiality, availability (or 'Enableability') of most Inverse Kinematics' properties for Bone(s), when we are using the more straightfoward solution for Inverse Kinematics which is called Auto IK on Pose Mode (i.e., whenever Auto IK Option is Enabled, the Inverse Kinematics Panel information doesn't adapt to match the reality: which is, that Bones which are Connected by Parenting become temporarily part of an IK Chain (but only for Enabled Auto IK). The properties DO WORK! But they are being displayed, in the Inverse Kinematics Panel, as if they wouldn't.🙀

for Auto IK Option

Exact steps for others to reproduce the error

In order to correctly visualize the incoherent UI display in the Inverse Kinematics Panel (found on Pose Mode: Properties Editor > Bone Tab), we need to compare how the properties of that Panel are displaying for Bones, on two different, separate Inverse Kinematics Rig setups:
i) one setup would be a very simple IK Bone Constraint setup, with, for example 2 or 3 Bone (IK Chain) and 1 Target Bone (Control Bone)(Pole Target is optional);
ii) and the other setup would be a simple Chain of Bones (e.g., 3 Bones), with Connected Parenting, except that, for this setup, we'll be using no Bone Constraints at all, and the Auto IK Option (on Pose Mode, 3D Viewport Editor > Sidebar Region > Tools Tab > Pose Options).

The problem is that:
Although both setups (IK Bone Constraint Rig, Auto IK Rig), allow for each of 'IK Chain' Bones to employ effectively any (or most) of the properties in the Inverse Kinematics Panel, in the particular case of the Auto IK Rig, the UI can become pretty confusing, because... differently from the 'IK Chain' Bones of the IK Bone Constraint Rig, the 'IK Chain' Bones of the Auto IK Rig have nearly all of their Inverse Kimematics Panel's properties dark-greyished even when Auto IK Option is being Enabled!! The most confusing thing, is that... their Inverse Kinematics properties WORK, despite being dark-greyished.
To my understanding, whenever we are using Auto IK Option Enabled on Pose Mode, a/the Selected Bone(s) are sort of temporarily turned into 'IK Chain' Bones, because Posing them, if they have Connected Parent Bones, works in Inverse Kinematics. This suggests that, whenever Auto IK Option is Enabled, if not the following behavior for all of the Bones of the Skeleton, at least the Bones which are 'IK Chain' edible, should have their Inverse Kinematics Panel's properties display, not as regular Bones that do not possess Inverse Kinematics features, but just as the state of the 'IK Chain' Bones which make part of an IK Bone Constraint Rig: their properties aren't dark-greyish.

Important note (I've took 2 compartive screenshots): Looking more carefully into the Inverse Kinematics Panel UI, and comparing directly between the two setups, there are 3 tones of grey: 1) free to Enable (lighter grey), 2) Disabled (medium grey), and 3) Disabled 'extra' (darker grey).
In the case of Auto IK Rig, if we look for their 'IK Chain' Bones, the Lock IK X/Y/Z are the only Options which show as 1) free to Enable (lighter grey); **Stiffness **X/Y/Z show as 2) Disabled (medium grey); while, for some reason, the Limit X/Y/Z Checkbox show as 3) Disabled 'extra' (darker grey); whatever that means, they WORK! Although showing as Disabled, and Disabled in different ways.

So, in conclusion, why when we use Auto IK Option on Pose Mode, the UI is telling us that a Bone's properties for Inverse Kinematics are Disabled or suppressed, when actually... they are working perfectly and what we Edit in the Inverse Kinematics Panel is affecting them? The user gets pretty confusing. If that matters, my rational take to improve this thing (which seems contradictory to the UI behavior and is confusing), would be that, whenever Enabling Auto IK Option, this should make such display behavior of Bones, in the Inverse Kinematics Panel, work just as in the case of 'IK Chain' Bones of an IK Bone Constraint Rig (screenshot "Setup-IKBoneConstraint"), and not as if the Bones were appearing prohibited from Inverse Kinematics (screenshot "Setup-AutoIK") while they're actually not prohibited.

Thanks for your attention!
Best regards.

PS: I'll make sure to follow up the sequence of this text exchange if necessary; I had issues on previous Bug Reports I've made, in which cases I wasn't prepared to follow up a conversation, and I apologize for that to the team.
I suggest warning messages to the users, before they post (or as part of instructions), so that people that Report Bug, get better prepared: sometimes: it's not just about writing a single Bug Report and that's done (for the use): sometimes, the author must be ready to develop further, answering questions, because communication problems do exist and Blender issues can be complicated to explain.

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: AMD Radeon(TM) Graphics ATI Technologies Inc. 4.6.0 Core Profile Context 23.4.3.230420 **Blender Version** Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: `9be62e85b727` Worked: (newest version of Blender that worked as expected) **Short description of error** The Inverse Kinematics Panel is displaying contradictory information, about the potentiality, availability (or 'Enableability') of most Inverse Kinematics' properties for Bone(s), when we are using the more straightfoward solution for Inverse Kinematics which is called **Auto IK** on Pose Mode (i.e., whenever Auto IK Option is Enabled, the Inverse Kinematics Panel information doesn't adapt to match the reality: which is, that Bones which are Connected by Parenting become temporarily part of an IK Chain (but only for Enabled Auto IK). The properties DO WORK! But they are being displayed, in the Inverse Kinematics Panel, as if they wouldn't.🙀 for Auto IK Option **Exact steps for others to reproduce the error** 1) In order to correctly visualize the incoherent UI display in the Inverse Kinematics Panel (found on Pose Mode: Properties Editor > Bone Tab), we need to compare how the properties of that Panel are displaying for Bones, on two different, separate Inverse Kinematics Rig setups: i) one setup would be a very simple IK Bone Constraint setup, with, for example 2 or 3 Bone (IK Chain) and 1 Target Bone (Control Bone)(Pole Target is optional); ii) and the other setup would be a simple Chain of Bones (e.g., 3 Bones), with Connected Parenting, except that, for this setup, we'll be using no Bone Constraints at all, and the **Auto IK** Option (on Pose Mode, 3D Viewport Editor > Sidebar Region > Tools Tab > Pose Options). The problem is that: Although both setups (IK Bone Constraint Rig, Auto IK Rig), allow for each of 'IK Chain' Bones to employ effectively any (or most) of the properties in the Inverse Kinematics Panel, in the particular case of the Auto IK Rig, the UI can become pretty confusing, because... differently from the 'IK Chain' Bones of the IK Bone Constraint Rig, the 'IK Chain' Bones of the Auto IK Rig have nearly all of their Inverse Kimematics Panel's properties dark-greyished even when Auto IK Option is being Enabled!! The most confusing thing, is that... their Inverse Kinematics properties WORK, despite being dark-greyished. To my understanding, whenever we are using Auto IK Option Enabled on Pose Mode, a/the Selected Bone(s) are sort of temporarily turned into 'IK Chain' Bones, because Posing them, if they have Connected Parent Bones, works in Inverse Kinematics. This suggests that, _whenever Auto IK Option is Enabled_, if not the following behavior for all of the Bones of the Skeleton, at least the Bones which are 'IK Chain' edible, should have their Inverse Kinematics Panel's properties display, not as regular Bones that do not possess Inverse Kinematics features, but just as the state of the 'IK Chain' Bones which make part of an IK Bone Constraint Rig: their properties aren't dark-greyish. Important note (I've took 2 compartive screenshots): Looking more carefully into the Inverse Kinematics Panel UI, and comparing directly between the two setups, there are 3 tones of grey: 1) free to Enable (lighter grey), 2) Disabled (medium grey), and 3) Disabled 'extra' (darker grey). In the case of Auto IK Rig, if we look for their 'IK Chain' Bones, the **Lock IK X**/**Y**/**Z** are the only Options which show as _1) free to Enable (lighter grey)_; **Stiffness **X/**Y**/**Z** show as _2) Disabled (medium grey)_; while, for some reason, the Limit **X**/**Y**/**Z** Checkbox show as _3) Disabled 'extra' (darker grey)_; whatever that means, they WORK! Although showing as Disabled, and Disabled in different ways. So, in conclusion, why when we use Auto IK Option on Pose Mode, the UI is telling us that a Bone's properties for Inverse Kinematics are Disabled or suppressed, when actually... they are working perfectly and what we Edit in the Inverse Kinematics Panel is affecting them? The user gets pretty confusing. If that matters, my rational take to improve this thing (which seems contradictory to the UI behavior and is confusing), would be that, whenever Enabling Auto IK Option, this should make such display behavior of Bones, in the Inverse Kinematics Panel, work just as in the case of 'IK Chain' Bones of an IK Bone Constraint Rig (screenshot "Setup-IKBoneConstraint"), and not as if the Bones were appearing prohibited from Inverse Kinematics (screenshot "Setup-AutoIK") while they're actually not prohibited. Thanks for your attention! Best regards. PS: I'll make sure to follow up the sequence of this text exchange if necessary; I had issues on previous Bug Reports I've made, in which cases I wasn't prepared to follow up a conversation, and I apologize for that to the team. I suggest warning messages to the users, before they post (or as part of instructions), so that people that Report Bug, get better prepared: sometimes: it's not just about writing a single Bug Report and that's done (for the use): sometimes, the author must be ready to develop further, answering questions, because communication problems do exist and Blender issues can be complicated to explain.

Setup-AutoIKRig.png

228 KiB

BugReport-AutoIK-InverseKinematicsPanel-00.mp4

113 MiB

Setup-IKBoneConstraintRig.png

169 KiB

Pxy-Gnomes added the

labels 2024-03-19 20:19:45 +01:00

Philipp Oeser commented

2024-03-20 14:33:37 +01:00

I can confirm the behavior, however this is a bit hairy since the way to determine if a bone is affected by IK ( BKE_pose_channel_in_IK_chain) depends on the constraints already being present. For AutoiK, this is not the case (they are temporary, added only when you start transforming).

You can also tweak the chain length on the fly with AutoIK.

So the only way to have this approximated is showing it for all bones if Auto IK is enabled (instead of greying out), but this will not have to "proper" bones enabled/disabled.

This could be an improvement, but in a way the code is working as intended atm.

@dr.sybren : opinions? (pretty sure this would not be considered a bug though)

I can confirm the behavior, however this is a bit hairy since the way to determine if a bone is affected by IK ( `BKE_pose_channel_in_IK_chain`) depends on the constraints already being present. For AutoiK, this is not the case (they are temporary, added only when you start transforming). You can also tweak the chain length on the fly with AutoIK. So the only way to have this approximated is showing it for all bones if Auto IK is enabled (instead of greying out), but this will not have to "proper" bones enabled/disabled. This _could_ be an improvement, but in a way the code **is** working as intended atm. @dr.sybren : opinions? (pretty sure this would not be considered a bug though)

Philipp Oeser added

Module

Animation & Rigging

Status

Needs Info from Developers

and removed

Status

Needs Triage

labels 2024-03-20 14:33:58 +01:00

Wayde Moss commented

2024-03-20 21:16:40 +01:00

I wouldn't call it a bug. That solution seems good to me.

(Blender.chat) Question about Auto IK UI (should bones -- which ones?) show their IK settings if Auto IK is enabled?

All of them since you can autoIK any bone at any moment.

I wouldn't call it a bug. That solution seems good to me. >(Blender.chat) Question about Auto IK UI (should bones -- which ones?) show their IK settings if Auto IK is enabled? All of them since you can autoIK any bone at any moment.

Sybren A. Stüvel commented

2024-03-21 09:50:21 +01:00

Regarding the different levels of 'darkness': there's the overall "is this bone part of an IK chain?" that can darken, and then there are the per-limit properties (like 'limit loc X'), that are darkened when that limit is inactive.

I agree that this is not really a bug, but it is something that's a bit confusing. Fortunately the solution is very simple, so it's not a big deal to work on this. I will discuss this during an Animation & Rigging meeting, though, as just doing the naieve thing (show the settings as enabled whenever Auto IK is on) also has the potential of confusing people; they might read 'enabled' as 'has an IK constraint', which would no longer be true.

The code change:

diff --git a/scripts/startup/bl_ui/properties_data_bone.py b/scripts/startup/bl_ui/properties_data_bone.py
index c776316d7f0..495f1d9e27d 100644
--- a/scripts/startup/bl_ui/properties_data_bone.py
+++ b/scripts/startup/bl_ui/properties_data_bone.py
@@ -431,7 +431,7 @@ class BONE_PT_inverse_kinematics(BoneButtonsPanel, Panel):
         bone = context.bone
         pchan = ob.pose.bones[bone.name]
 
-        active = pchan.is_in_ik_chain
+        active = pchan.is_in_ik_chain or ob.pose.use_auto_ik
 
         col = layout.column()
         col.prop(pchan, "ik_stretch", slider=True)

Regarding the different levels of 'darkness': there's the overall "is this bone part of an IK chain?" that can darken, and then there are the per-limit properties (like 'limit loc X'), that are darkened when that limit is inactive. I agree that this is not really a bug, but it is something that's a bit confusing. Fortunately the solution is very simple, so it's not a big deal to work on this. I will discuss this during an Animation & Rigging meeting, though, as just doing the naieve thing (show the settings as enabled whenever Auto IK is on) also has the potential of confusing people; they might read 'enabled' as 'has an IK constraint', which would no longer be true. The code change: ```diff diff --git a/scripts/startup/bl_ui/properties_data_bone.py b/scripts/startup/bl_ui/properties_data_bone.py index c776316d7f0..495f1d9e27d 100644 --- a/scripts/startup/bl_ui/properties_data_bone.py +++ b/scripts/startup/bl_ui/properties_data_bone.py @@ -431,7 +431,7 @@ class BONE_PT_inverse_kinematics(BoneButtonsPanel, Panel): bone = context.bone pchan = ob.pose.bones[bone.name] - active = pchan.is_in_ik_chain + active = pchan.is_in_ik_chain or ob.pose.use_auto_ik col = layout.column() col.prop(pchan, "ik_stretch", slider=True) ```

Philipp Oeser commented

2024-03-21 10:12:33 +01:00

Shall we label this Confirmed and TODO then?

Shall we label this `Confirmed` and `TODO` then?

👍 1

Philipp Oeser added

and removed