Page MenuHome

Rigify: Strange Palm behavior when parent's Rig Type is set manually
Closed, ResolvedPublicBUG

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 446.14

Blender Version
Broken: version: 2.83.0, branch: master, commit date: 2020-06-03 12:23, hash: rB82e3bd4bbb82
Worked: (newest version of Blender that worked as expected)

Addon Information
Name: Rigify (0, 6, 1)
Author: Nathan Vegdahl, Lucio Rossi, Ivan Cappiello, Alexander Gavrilov

Short description of error
When I setup a Rig type for an Arm manually and then connect it to a palm rig type, the palm is not steadily connected to the arm.
When the Arm is created from Sample the problem does not occur.

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]
Create a chain of 3 bones, give them limbs.arm rig type.
Create a limbs.super_plam from sample or manually and parent it to the hand.
Generate the rig.
Move the IK control in the generated rig. The palm floats around the hand bone in an unpredictable manner.
If limbs.arm is created from a sample this problem does not occur.
In the attached file I have a generated rig, created as described above:


Interestingly I am sure I have created arm+plam manually before without getting this error.

Event Timeline

Todor Nikolov (ToshiCG) renamed this task from Strange Palm behavior when parent's Rig Type is set manually to Rigify Strange Palm behavior when parent's Rig Type is set manually.Wed, Jun 24, 7:36 AM
Todor Nikolov (ToshiCG) renamed this task from Rigify Strange Palm behavior when parent's Rig Type is set manually to Rigify: Strange Palm behavior when parent's Rig Type is set manually.
Demeter Dzadik (Mets) changed the task status from Needs Triage to Confirmed.Wed, Jun 24, 12:55 PM
Demeter Dzadik (Mets) claimed this task.
Demeter Dzadik (Mets) triaged this task as Low priority.
Demeter Dzadik (Mets) changed the subtype of this task from "Report" to "Bug".

I didn't look into this very deeply, but at a quick glance it feels like the parenting of the finger bones does some kind of name-based search and ends up with the wrong bone. In this case, Bone(which is a finger control) should be parented to Bone_ik.002 (which is the wrist control) but instead ends up parented to DEF-Bone.002 (which is the first deform bone of the elbow).

Renaming either the elbow or the wrist in the setup to something unique seems to fix the issue. Generally a good rule of thumb with Rigify imo, is to avoid .00x names in the metarig when possible.

That said, this still shouldn't happen ofc. I'm up for looking into it a bit more later, but for now, can you confirm that after renaming either elbow or wrist generates the rig as expected?

Thank you for the workaround. Now I understand why this didn't happen before. I just named my bones properly.
But yeah, ultimately it shouldn't be something that the user has to worry about.

@Demeter Dzadik (Mets) if i remember correctly, palm should search for its siblings (meaning all unconnected bones that shares the same parent) and try to search for them in a direction starting from the one that has the app property. Naming shouldn't be relevant cause those are all siblings of the same parent. But this may have changed over time or this check is not happening correctly.

So, the issue is that super_palm.py->parent_bones() tries to find the DEF bone corresponding to an ORG bone by naming convention; the DEF bone of ORG-Bone.002 must be DEF-Bone.002, which is a wrong assumption because in this case that is an unrelated bone, and the correct one would be DEF-Bone.004.

My solution would be to store a reference to the corresponding DEF bone's name in the ORG bone in a bone data custom property, eg. in this case, data.bones["ORG-Bone.002"]["def"] = "DEF-Bone.004"
Question with this is, how far to go? ORG bones could start storing references to all sorts of corresponding bones, sometimes multiple of the same type (eg. multiple DEF bones). For this single case it may seem overkill, so I wonder if this would have other uses. Maybe there are already other places in the code that also rely on name-based matching that could fail with non-unique names.

CC @Alexander Gavrilov (angavrilov) Thoughts?