Rigify: choose regenerate target by rig_id, and clean WGT- objects up after generation and fix minor bug #51094
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#51094
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
rigify has 'rig_id' property, but rigify makes always new armature object. this patch fix this behaviour.
and after rig was generated, many WGT object remains in scene. this patch makes rigify to clean these objects up.
and this patch makes WGT objects have unique name per metarig. if multiple metarig is in same scene, generated rig has correct bone shapes.
and this patch avoid runtime exception that I experienced. (some addon (not rigify) makes weird property, that like key exists but rna_idprop_ui_prop_get returns None)
rigify-patch.diff
Changed status to: 'Open'
Added subscriber: @SAMtak
Added subscribers: @cessen, @mano-wii
These improvements are indeed good.
@cessen, do you still maintain the rigify? Could you take a look?
Added subscriber: @ideasman42
Added subscribers: @LucioRossi, @BrendonMurphy
@LucioRossi hi could you have a look at this please
Added subscriber: @icappiello
looking into the patch right now.
from a first look i have some big concerns about rigify WGT patch proposal:
WGT objects are left in the scene because if the user wants to manually edit them, he could do it since rigify generate function will not overwrite the WGT when the object already exists in the scene. When the object is deleted from scene and the generate function is invoked again to fix or edit the rig, then the user WGT edit will be lost.
Appending the rig-id before the WGT name would create a mess for the user when he is looking for a specific WGT. The rig id is a random string (like imqsu8wj1a1d9195) that will be shown in the outliner before the WGT name itself. I think this would generate more confusion than the problem the patch is trying to fix.
About tidying up the scene and the outliner, the best solution for now is to parent all the WGTs under an empty. This is already committed for 2.79 release.
I consider at least this part of the patch as rejected.
About the rig-id part:
Seems you are writing the rig-id on the meta-rig and then the meta-rig passes it to the rig. Even if the idea seems cool at a first glance, again, the consequence of this change are breaking other rigify features.
It seems you never generate again the rig-id on the meta-rig once is created. This is bad. Rigify metarigs are created to be shareable through blender files. For example, you have rigged your character with rigify, the next one is similar to the first, so you append your meta-rig form the first to the second file, then edit it as needed and generate. Standing to your patch in this case the metarig will bring in the second file the same rig id and - even not finding the rig itself - will always generate rigs with same rig-id. Since there is no rule to know when to re-create the rig id, you will force the user to manually delete it.
The idea behind the patch is good though.
I'll try to think a workaround for this second part, but for now -as this patch is submitted - I consider this part rejected too.
Changed status from 'Open' to: 'Archived'