Rigify - basic.raw_copy bones with ORG prefix are not generated correctly #80764

Closed
opened 2020-09-14 07:38:33 +02:00 by Todor Nikolov · 6 comments

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 452.06

Blender Version
Broken: version: 2.83.6, 2.9 & 2.91
Worked: (not sure)

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

Short description of error
basic.raw_copy bones with ORG prefix are not generated correctly (or at least not as I expect)

Exact steps for others to reproduce the error

  • activate rigify
  • Create a new single bone
  • give the bone basic.raw_copy rig type
  • rename the bone "ORG-bone"
  • press Generate Rig
    Expected behavior:
    The bone is moved to layer 31 and it retails the name "ORG-bone" in the generated rig.
    Actual behavior in the current version of Rigify:
    The bone remains in the same layer as in the meta rig. It also loses the "ORG-" prefix. So "ORG-bone" is renamed to "bone".

I started trying to figure out raw_copy recently so it could be that I misunderstood something.
But this is inconsistent with the raw_copy's that have MCH or DEF prefix.
Bones with MCH- prefix are moved to layer 30 and retain the prefix.
Bones with DEF- prefix are moved to layer 29 and retain the prefix.
Only ORG bones don't follow this pattern.

**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 452.06 **Blender Version** Broken: version: 2.83.6, 2.9 & 2.91 Worked: (not sure) **Addon Information** Name: Rigify (0, 6, 1) Author: Nathan Vegdahl, Lucio Rossi, Ivan Cappiello, Alexander Gavrilov **Short description of error** basic.raw_copy bones with ORG prefix are not generated correctly (or at least not as I expect) **Exact steps for others to reproduce the error** - activate rigify - Create a new single bone - give the bone basic.raw_copy rig type - rename the bone "ORG-bone" - press Generate Rig **Expected behavior:** The bone is moved to layer 31 and it retails the name "ORG-bone" in the generated rig. **Actual behavior in the current version of Rigify:** The bone remains in the same layer as in the meta rig. It also loses the "ORG-" prefix. So "ORG-bone" is renamed to "bone". I started trying to figure out raw_copy recently so it could be that I misunderstood something. But this is inconsistent with the raw_copy's that have MCH or DEF prefix. Bones with MCH- prefix are moved to layer 30 and retain the prefix. Bones with DEF- prefix are moved to layer 29 and retain the prefix. Only ORG bones don't follow this pattern.
Author

Added subscriber: @TodorNikolov

Added subscriber: @TodorNikolov
Author

Added subscribers: @angavrilov, @icappiello, @Mets

Added subscribers: @angavrilov, @icappiello, @Mets
Alexander Gavrilov was assigned by Ivan Cappiello 2020-09-16 09:03:32 +02:00
Member

@angavrilov is there a specific design reason for that? can't exactly tell if is a bug or an intended design.

@angavrilov is there a specific design reason for that? can't exactly tell if is a bug or an intended design.

This is a technical limitation of implementing raw_copy using only the 'public' rig API: it works by removing the ORG prefix that is added as usual by generate, which doesn't add the prefix if the bone already has it to avoid creating 'ORG-ORG-whatever'. This can only be fixed by adding a special case check for raw_copy directly in generate code, or maybe saving a table of the 'true original names' for the bones so raw_copy can use it.

I didn't give this case much thought because I wanted to showcase the power of the generic API, and thought there is no point creating ORG bones with raw_copy - functionally they aren't any different from MCH.

This is a technical limitation of implementing raw_copy using only the 'public' rig API: it works by removing the ORG prefix that is added as usual by generate, which doesn't add the prefix if the bone already has it to avoid creating 'ORG-ORG-whatever'. This can only be fixed by adding a special case check for raw_copy directly in generate code, or maybe saving a table of the 'true original names' for the bones so raw_copy can use it. I didn't give this case much thought because I wanted to showcase the power of the generic API, and thought there is no point creating ORG bones with raw_copy - functionally they aren't any different from MCH.

This issue was referenced by b757daf681

This issue was referenced by b757daf681b0c39c67b3ed2391ff8437a46e237e

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

Changed status from 'Needs Triage' to: 'Resolved'
Sign in to join this conversation.
No Milestone
No project
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#80764
No description provided.