Rigify improvements in Blender 3 and beyond #88711

New Issue

Demeter Dzadik · 2021-05-31T21:55:57+02:00

Demeter Dzadik commented

2021-05-31 21:55:57 +02:00

Preface
In this post I describe (most of) my contribution plans to the Rigify addon into a somewhat coherent document so if anyone finds something controversial, they can raise their concerns. Note that I'm not a full-time developer, I'm just a rigger who enjoys Python a lot, so I mostly work on Rigify patches in my "free time", so expect slow progress.

A lot of these things have already been done in my Feature Set, so that will be mentioned and linked to sometimes.

If a topic turns out to be more complex or elicit a lot of discussion, I can create child tasks to split the discussion into appropriate places. Also, when a patch shows up, feel free to discuss it within the patch rather than here.

Code Quality

- Remove Legacy Mode (D11516)
Remove all other Legacy Code: Veto'd by Alexander.
Split off Space Switcher (D11605)
rigify/ui.py and __init__.py could use some splitting.

Mistaken use of name mangling?
I believe function names starting with __ are unintentionally using Python's name mangling syntax. At least I see no justification for it, but I see in the function rigify_report_exception uses the dunder prefix for a different purpose (perhaps code was written before python had name mangling?). This should be looked into.

Resource Blend File over Text-Encoded assets
Metarigs and Rig samples could be loaded from one or more resource .blend files that are part of the addon or feature sets, rather than the current encoding to text workflow.

Less ugly code in rig .py files
Easier to maintain and expand
Current system doesn't account for a lot of things like constraints and bbone display size, custom properties.

UI/UX

Use sub-panels instead of flooding the Properties editor with top level panels. (D13914)
Set appropriate 'ANIMATABLE' and 'LIBRARY_OVERRIDABLE' flags for all properties.
- Operators should be searchable and in a header instead of the sidebar (D9094)
- Operators should be distinguishable from other UI elements.
- UI strings should always be in Title Case.

Generating UX

- To promote the non-destructive, procedural rigging workflow that Rigify was designed for, it should be as clear as possible that one Metarig is interlinked with exactly one Generated Rig. This, along with some of the above points are the reason behind D11356.
- Generation shouldn't fail just because the target rig is hidden. (D11355)
Generation failures shouldn't destroy the target rig. Instead, the rig being generated should only be replaced with the previous rig at the end of the generation process, when successful. This can be done safely and cheaply with the user_remap() function. I've been doing this in CloudRig for some time now, works great.
Rigs should look consistent at any reasonable scale and with any armature display type. Currently, BBone display size and envelope display size are totally ignored.

Bone Organization UX

Blender's bone layer and bone group system is fairly lackluster. We should provide both rig authors and animators an abstraction layer over Blender's 32-layer system, where layers can be named and organized into rows and columns. This already exists, but it could be better.

Removing "Rigify Bone Groups" panel
- Blender already has Bone Groups, and the extra functionality that Rigify adds does not require re-defining them.
  The Unified Selected/Active Color can work perfectly fine with regular bone groups - It does not even need an "Apply" button.
Reworking Rigify Layer Names panel
- Add a preview UI so you can see what you're doing.
- Indicate Protected Layers.
- "Hidden Layers" for riggers to organize their mechanism bones.
- Preserve Selection Sets from one rig generation to another.

Customizing bone group and layer assignments

Currently, most bone group names and bone layer assignments are fully hard-coded.
Could be exposed as parameters with the ControlLayersOption class.
- This is done in CloudRig, see Bone Sets. The naming could be different to avoid confusion with Selection Sets.

New Operators

These are speed-ups to my workflow that I use on a daily basis.

- Copy and Mirror Rigify Parameters (D11606)
Switch to Target Rig/Metarig (Hides the current one and puts you into the same mode in the other one) (D14004)

New Features

- Ability to disable feature sets without entirely removing them from the file system (D12260)
Add some addon hotkeys for the above operators These can be exposed in the addon prefs UI so users know about them. This would make for a much smoother transition from new user to power user.
- Post-Generation script: Allow specifying a text datablock that gets executed at a very late stage of the generation. (Done by Alexander)
Rigify Log, to list warnings or errors that were caught during rig generation, and even provide one-button solutions when possible.
Rigify Actions, to automatically create Action-based control setups, including correctives.

**Preface** In this post I describe (most of) my contribution plans to the Rigify addon into a somewhat coherent document so if anyone finds something controversial, they can raise their concerns. Note that I'm not a full-time developer, I'm just a rigger who enjoys Python a lot, so I mostly work on Rigify patches in my "free time", so expect slow progress. A lot of these things have already been done in my [Feature Set](https://gitlab.com/blender/CloudRig), so that will be mentioned and linked to sometimes. If a topic turns out to be more complex or elicit a lot of discussion, I can create child tasks to split the discussion into appropriate places. Also, when a patch shows up, feel free to discuss it within the patch rather than here. ### Code Quality - - [x] Remove Legacy Mode ([D11516](https://archive.blender.org/developer/D11516)) - Remove all other Legacy Code: Veto'd by Alexander. - Split off Space Switcher ([D11605](https://archive.blender.org/developer/D11605)) - `rigify/ui.py` and `__init__.py` could use some splitting. **Mistaken use of [name mangling](https://docs.python.org/3.7/tutorial/classes.html?highlight=name%20mangling#private-variables)?** I believe function names starting with __ are unintentionally using Python's name mangling syntax. At least I see no justification for it, but I see in the function `rigify_report_exception` uses the dunder prefix for a different purpose (perhaps code was written before python had name mangling?). This should be looked into. **Resource Blend File over Text-Encoded assets** Metarigs and Rig samples could be loaded from one or more resource .blend files that are part of the addon or feature sets, rather than the current encoding to text workflow. - Less ugly code in rig .py files - Easier to maintain and expand - Current system doesn't account for a lot of things like constraints and bbone display size, custom properties. # UI/UX - Use sub-panels instead of flooding the Properties editor with top level panels. ([D13914](https://archive.blender.org/developer/D13914)) - Set appropriate 'ANIMATABLE' and 'LIBRARY_OVERRIDABLE' flags for all properties. - - [x] Operators should be searchable and in a header instead of the sidebar ([D9094](https://archive.blender.org/developer/D9094)) - - [x] Operators should be distinguishable from other UI elements. - - [x] UI strings should always be in Title Case. **Generating UX** - - [x] To promote the non-destructive, procedural rigging workflow that Rigify was designed for, it should be as clear as possible that one Metarig is interlinked with exactly one Generated Rig. This, along with some of the above points are the reason behind [D11356](https://archive.blender.org/developer/D11356). - - [x] Generation shouldn't fail just because the target rig is hidden. ([D11355](https://archive.blender.org/developer/D11355)) - Generation failures shouldn't destroy the target rig. Instead, the rig being generated should only be replaced with the previous rig at the end of the generation process, when successful. This can be done safely and cheaply with the user_remap() function. I've been doing this in CloudRig for some time now, works great. - Rigs should look consistent at any reasonable scale and with any armature display type. Currently, BBone display size and envelope display size are totally ignored. **Bone Organization UX** Blender's bone layer and bone group system is fairly lackluster. We should provide both rig authors and animators an abstraction layer over Blender's 32-layer system, where layers can be named and organized into rows and columns. This already exists, but it could be better. - Removing "Rigify Bone Groups" panel - Blender already has Bone Groups, and the extra functionality that Rigify adds does not require re-defining them. The Unified Selected/Active Color can work perfectly fine with regular bone groups - It does not even need an "Apply" button. - Reworking Rigify Layer Names panel - Add a preview UI so you can see what you're doing. - Indicate Protected Layers. - "Hidden Layers" for riggers to organize their mechanism bones. - Preserve Selection Sets from one rig generation to another. **Customizing bone group and layer assignments** - Currently, most bone group names and bone layer assignments are fully hard-coded. - Could be exposed as parameters with the ControlLayersOption class. - This is done in CloudRig, see [Bone Sets](https://gitlab.com/blender/CloudRig/-/wikis/Organizing-Bones#bone-sets). The naming could be different to avoid confusion with Selection Sets. # New Operators These are speed-ups to my workflow that I use on a daily basis. - - [x] Copy and Mirror Rigify Parameters ([D11606](https://archive.blender.org/developer/D11606)) - Switch to Target Rig/Metarig (Hides the current one and puts you into the same mode in the other one) ([D14004](https://archive.blender.org/developer/D14004)) # New Features - - [x] Ability to disable feature sets without entirely removing them from the file system ([D12260](https://archive.blender.org/developer/D12260)) - Add some addon hotkeys for the above operators These can be exposed in the addon prefs UI so users know about them. This would make for a much smoother transition from new user to power user. - - [x] Post-Generation script: Allow specifying a text datablock that gets executed at a very late stage of the generation. (Done by Alexander) - [Rigify Log](https://gitlab.com/blender/CloudRig/-/wikis/Troubleshooting), to list warnings or errors that were caught during rig generation, and even provide one-button solutions when possible. - [Rigify Actions](https://gitlab.com/blender/CloudRig/-/wikis/Actions), to automatically create Action-based control setups, including correctives.

Demeter Dzadik commented

2021-05-31 21:55:57 +02:00

Added subscriber: @Mets

Daniel Salazar commented

2021-06-01 01:04:02 +02:00

Added subscriber: @zanqdo

Demeter Dzadik commented

2021-06-01 01:35:48 +02:00

Added subscribers: @icappiello, @angavrilov, @BassamKurdali, @cessen

Demeter Dzadik commented

2021-06-01 01:35:48 +02:00

Pinging people who pop into my mind when I think of Rigify.
@angavrilov @icappiello @BassamKurdali @zanqdo @cessen Feel free to ping anyone I might've missed.

Although thoughts about any part of this wall of text are welcome from anybody, let's assume that I would like to work on these issues roughly top to bottom. That means for now I'm most interested in what's the deal with Rigify Legacy:

Am I good to go to rip out Legacy and all of its backwards-compatibility related UI and operators?
Am I correct that this feature set on Nathan's github is basically Legacy Rigify, in the form of a feature set?

Pinging people who pop into my mind when I think of Rigify. @angavrilov @icappiello @BassamKurdali @zanqdo @cessen Feel free to ping anyone I might've missed. Although thoughts about any part of this wall of text are welcome from anybody, let's assume that I would like to work on these issues roughly top to bottom. That means for now I'm most interested in what's the deal with **Rigify Legacy**: - Am I good to go to rip out Legacy and all of its backwards-compatibility related UI and operators? - Am I correct that [this feature set on Nathan's github](https://github.com/cessen/cessen_rigify_ext) is basically Legacy Rigify, in the form of a feature set?

Philipp Oeser commented

2021-06-01 13:35:54 +02:00

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

Nathan Vegdahl commented

2021-06-01 20:57:59 +02:00

All-in-all, I really like this proposal.

Am I good to go to rip out Legacy and all of its backwards-compatibility related UI and operators?

As far as I'm concerned, absolutely yes, please rip it out. Ha ha.

Am I correct that this feature set on Nathan's github is basically Legacy Rigify, in the form of a feature set?

Yes, that's exactly what it is. The down-side is that I'm not offering support for it (I'm mostly maintaining it just for personal use), but I suspect that in practice the legacy feature set wasn't getting used much and probably wasn't a support priority anyway.

Splitting off Space Switcher

I'm also in favor of this.

(Or, alternatively, if the space switcher is considered critical to the functionality of some of the rig types, then IMO we should continue with the principle that Rigify itself isn't required for using the rigs it generates, and have that functionality moved into the generated rig's Python code so that it's bundled with the rig itself.)

Text-Encoded assets

I don't feel strongly about this one way or the other. But I want to bring up some questions that I think are worth considering before making such a move:

How would this impact the end-user experience? From the user's perspective, such a change ought to (IMO) be transparent. Users would still add samples, example meta-rigs, etc. with a simple menu or button, and be blissfully ignorant of the fact that the data is actually now held in an external blend file somewhere. Also when e.g. installing new feature sets, the appropriate blend files would be bundled, and not require any extra steps from the user for installation.
Will this notably improve the workflow for people creating new rig types? The current workflow certainly isn't ideal, but I wonder if in practice we'd just be trading old problems for new problems. For example, with external blend files I imagine there could be complexities in making sure the samples etc. are registered in the menu entries the right way, pointing to the right things in the right blend files.

I think I'm slightly in favor of moving away from text-stored data, but only if we can make sure we're not degrading either the end-user or rig-type-developer experience.

Anyway, again, over-all I really like this proposal! Getting Rigify cleaned up and updated for Blender 3.0 would be really great!

All-in-all, I really like this proposal. > - Am I good to go to rip out Legacy and all of its backwards-compatibility related UI and operators? As far as I'm concerned, absolutely yes, *please* rip it out. Ha ha. > - Am I correct that this feature set on Nathan's github is basically Legacy Rigify, in the form of a feature set? Yes, that's exactly what it is. The down-side is that I'm not offering support for it (I'm mostly maintaining it just for personal use), but I suspect that in practice the legacy feature set wasn't getting used much and probably wasn't a support priority anyway. > Splitting off Space Switcher I'm also in favor of this. (Or, alternatively, if the space switcher is considered critical to the functionality of some of the rig types, then IMO we should continue with the principle that Rigify itself isn't required for using the rigs it generates, and have that functionality moved into the generated rig's Python code so that it's bundled with the rig itself.) > Text-Encoded assets I don't feel strongly about this one way or the other. But I want to bring up some questions that I think are worth considering before making such a move: * How would this impact the end-user experience? From the user's perspective, such a change ought to (IMO) be transparent. Users would still add samples, example meta-rigs, etc. with a simple menu or button, and be blissfully ignorant of the fact that the data is actually now held in an external blend file somewhere. Also when e.g. installing new feature sets, the appropriate blend files would be bundled, and not require any extra steps from the user for installation. * Will this notably improve the workflow for people creating new rig types? The current workflow certainly isn't ideal, but I wonder if in practice we'd just be trading old problems for new problems. For example, with external blend files I imagine there could be complexities in making sure the samples etc. are registered in the menu entries the right way, pointing to the right things in the right blend files. I think I'm slightly in favor of moving away from text-stored data, but only if we can make sure we're not degrading either the end-user or rig-type-developer experience. Anyway, again, over-all I really like this proposal! Getting Rigify cleaned up and updated for Blender 3.0 would be really great!

Nathan Vegdahl commented

2021-06-01 21:17:04 +02:00

Also, if I can add another item of my own:

Many of the rig types' names are a bit confusing, and could be more straightforward/descriptive. For example, "super_limb". I've received emails from people asking what's "super" about it, and what that even means, and I never really have a good answer for them.

For context: these names aren't special or meaningful in any particular way. They're just a weird historical hold-over from when I initially integrated PitchiPoy's rig types--PitchiPoy liked to name their rig types whimsically. At the time I distinguished these from the other rig types with the "pitchipoy" prefix to make it clear that they were studio-specific. But because they are now the main supported rig types, I think this is a good chance to name them properly. For a lot of them, just dropping the "super_" is probably enough. But some of them would likely benefit from a bit more thought as well.

Also, if I can add another item of my own: Many of the rig types' names are a bit confusing, and could be more straightforward/descriptive. For example, "super_limb". I've received emails from people asking what's "super" about it, and what that even means, and I never really have a good answer for them. For context: these names aren't special or meaningful in any particular way. They're just a weird historical hold-over from when I initially integrated PitchiPoy's rig types--PitchiPoy liked to name their rig types whimsically. At the time I distinguished these from the other rig types with the "pitchipoy" prefix to make it clear that they were studio-specific. But because they are now the main supported rig types, I think this is a good chance to name them properly. For a lot of them, just dropping the "super_" is probably enough. But some of them would likely benefit from a bit more thought as well.

Demeter Dzadik commented

2021-06-01 23:23:57 +02:00

In #88711#1169252, @cessen wrote:
All-in-all, I really like this proposal.

Thanks for taking the time to read and respond!!

if the space switcher is considered critical to the functionality of some of the rig types

No, as far as I'm aware no part of Rigify references the space switcher operator or its bl_idname.

Text-Encoded assets

Users would be blissfully ignorant of the fact that the data is actually now held in an external blend file somewhere.

Agree, this change should have no issue being unnoticable on the user-facing side.

Will this notably improve the workflow for people creating new rig types? The current workflow certainly isn't ideal, but I wonder if in practice we'd just be trading old problems for new problems. For example, with external blend files I imagine there could be complexities in making sure the samples etc. are registered in the menu entries the right way, pointing to the right things in the right blend files.

The way I imagine it is this:

During addon registration, the resource blend files are opened in the background with python, to build lists of available metarig and sample names, based on naming conventions that must be adhered to in the blend files' paths, and the object's names.
Those lists can then be used by the UI.
The new workflow for adding a new metarig or sample becomes:
- Open the resource file, or create a new one in some specifically-named folder
- Create what you want, adhering to a simple naming convention
- Hit Reload Scripts in your working file and the new sample/metarig will become available.
  Note that I haven't looked into the technical feasibility of this, but it sounds doable?

If we wanted to go one step further, we could wait for the asset system to be done, which I believe will establish a convention for storing datablocks in a centralized way, where they become available to the user in any blend file. This would be awesome for metarigs and samples, so even users could create their own totally within Blender's UI, without any file opening shennanigans. But, for now this is of course science fiction!

> In #88711#1169252, @cessen wrote: > All-in-all, I really like this proposal. Thanks for taking the time to read and respond!! > if the space switcher is considered critical to the functionality of some of the rig types No, as far as I'm aware no part of Rigify references the space switcher operator or its bl_idname. >> Text-Encoded assets > Users would be blissfully ignorant of the fact that the data is actually now held in an external blend file somewhere. Agree, this change should have no issue being unnoticable on the user-facing side. > * Will this notably improve the workflow for people creating new rig types? The current workflow certainly isn't ideal, but I wonder if in practice we'd just be trading old problems for new problems. For example, with external blend files I imagine there could be complexities in making sure the samples etc. are registered in the menu entries the right way, pointing to the right things in the right blend files. The way I imagine it is this: - During addon registration, the resource blend files are opened in the background with python, to build lists of available metarig and sample names, based on naming conventions that must be adhered to in the blend files' paths, and the object's names. - Those lists can then be used by the UI. - The new workflow for adding a new metarig or sample becomes: - Open the resource file, or create a new one in some specifically-named folder - Create what you want, adhering to a simple naming convention - Hit Reload Scripts in your working file and the new sample/metarig will become available. Note that I haven't looked into the technical feasibility of this, but it sounds doable? If we wanted to go one step further, we could wait for the asset system to be done, which I believe will establish a convention for storing datablocks in a centralized way, where they become available to the user in any blend file. This would be awesome for metarigs and samples, so even users could create their own totally within Blender's UI, without any file opening shennanigans. But, for now this is of course science fiction!

Andy Cuccaro commented

2021-06-02 00:51:37 +02:00

Added subscriber: @AndyCuccaro

Todor Nikolov commented

2021-06-02 12:35:39 +02:00

Added subscriber: @TodorNikolov

Nathan Vegdahl commented

2021-06-02 15:44:29 +02:00

The way I imagine it is this:

If that's doable, and can be done in a way that's reliable and clean, I'm all for it! Sounds great.

> The way I imagine it is this: If that's doable, and can be done in a way that's reliable and clean, I'm all for it! Sounds great.

Ivan Cappiello commented

2021-06-03 10:20:12 +02:00

@cessen always great to have your thoughts and suggestions on how to improve rigify!
since i answered @Mets in chat and this was probably missed, i'll repost my opinion about legacy here.

removing the legacy rigs in my opinion is part of a rigify redesign. Even if i am not a fan of the older modules, i believe that removing those should be done carefully. Also raises some questions about how to do it and what should happen when rig sets became deprecated (or just not maintained anymore)
my idea of sorting this out would be to have the source repos available in the rigify preferences. This way we could still have legacy rigs in, but would be Nathan's choice if he want those to be maintained or not. I'd go at this point remove the legacy code from rigify itself and ask cessen to make his featureset compliant with new rigify. If so we can at least give users a quick way to enable it by including for a couple of releases the link to cessen's repo in the prefs
also we could include as default @angavrilov 's repo and cloudrig
this also led me to te conclusion we should have a sort of load/unload or enaled/diabled state for featureset
this way rigify can start with only the bundled rigs pre-loaded and can grab the latest "featured" rigs from @Mets, @angavrilov and @cessen 's repos
i believe that removing the legacy rigs is the occasion to upgrade rigify preferences in a way all user base can benefit and prevent future mantainment of legacy code

@cessen always great to have your thoughts and suggestions on how to improve rigify! since i answered @Mets in chat and this was probably missed, i'll repost my opinion about legacy here. removing the legacy rigs in my opinion is part of a rigify redesign. Even if i am not a fan of the older modules, i believe that removing those should be done carefully. Also raises some questions about how to do it and what should happen when rig sets became deprecated (or just not maintained anymore) my idea of sorting this out would be to have the source repos available in the rigify preferences. This way we could still have legacy rigs in, but would be Nathan's choice if he want those to be maintained or not. I'd go at this point remove the legacy code from rigify itself and ask cessen to make his featureset compliant with new rigify. If so we can at least give users a quick way to enable it by including for a couple of releases the link to cessen's repo in the prefs also we could include as default @angavrilov 's repo and cloudrig this also led me to te conclusion we should have a sort of load/unload or enaled/diabled state for featureset this way rigify can start with only the bundled rigs pre-loaded and can grab the latest "featured" rigs from @Mets, @angavrilov and @cessen 's repos i believe that removing the legacy rigs is the occasion to upgrade rigify preferences in a way all user base can benefit and prevent future mantainment of legacy code

Ivan Cappiello commented

2021-06-03 10:22:54 +02:00

In #88711#1169254, @cessen wrote:
Also, if I can add another item of my own:

Many of the rig types' names are a bit confusing, and could be more straightforward/descriptive. For example, "super_limb". I've received emails from people asking what's "super" about it, and what that even means, and I never really have a good answer for them.

For context: these names aren't special or meaningful in any particular way. They're just a weird historical hold-over from when I initially integrated PitchiPoy's rig types--PitchiPoy liked to name their rig types whimsically. At the time I distinguished these from the other rig types with the "pitchipoy" prefix to make it clear that they were studio-specific. But because they are now the main supported rig types, I think this is a good chance to name them properly. For a lot of them, just dropping the "super_" is probably enough. But some of them would likely benefit from a bit more thought as well.

Totally agree on removing super_ prefix. We just kept it as is since we knew you worked on it and seemed to be a sort of description of new rig capabilities (bendy and stretchy rigs). But honestly we just kept it as we found it.

> In #88711#1169254, @cessen wrote: > Also, if I can add another item of my own: > > Many of the rig types' names are a bit confusing, and could be more straightforward/descriptive. For example, "super_limb". I've received emails from people asking what's "super" about it, and what that even means, and I never really have a good answer for them. > > For context: these names aren't special or meaningful in any particular way. They're just a weird historical hold-over from when I initially integrated PitchiPoy's rig types--PitchiPoy liked to name their rig types whimsically. At the time I distinguished these from the other rig types with the "pitchipoy" prefix to make it clear that they were studio-specific. But because they are now the main supported rig types, I think this is a good chance to name them properly. For a lot of them, just dropping the "super_" is probably enough. But some of them would likely benefit from a bit more thought as well. Totally agree on removing super_ prefix. We just kept it as is since we knew you worked on it and seemed to be a sort of description of new rig capabilities (bendy and stretchy rigs). But honestly we just kept it as we found it.

Ivan Cappiello commented

2021-06-03 10:37:33 +02:00

about metarigs, samples, and i'll add widgets too, i have mixed opinions.
for sure picking those from a blend file is easier to manage for users, but i don't know if it has to be encouraged without a basic knowledge of what a metarig or sample is.

I would first try to analyse the clear pro and cons we have with current method and see if it can be enhanced without a complete redesign.

what i see as main flaws here is that "encode metarig" and "encode widget" operators are doing only half of the job since they create the .py scripts, but they are not able to place those in any useful place. Moreover "encode metarig" is not including custom informations like constraints and so on that are instead now explicitly supported by some types like raw_copy or basic_pivot.

i wonder if we could make all this workflow more manageable, but at same time i believe it was cleverly designed to expose the user what rigify actually is and how it works. I believe this is a plus.

what i'd inspect is where user's custom samples and metarigs should be stored, cause inside rigify folder in blender package is something to be totally avoided (at least on mac builds it would break the app signature).

if this part can be sorted out i believe that a basic usage could be:

• user encodes metarig and adds it to his local metarig folder / package
• user encodes widgets and adds them to his local widget folder making those available in selected rig-types whose can use them (basic_copy, basic_pivot ?)

also this could affect rigify preferences:
• user can pack his customs in a zip
• user can load custom metarigs/widgets from preferences

i honestly don't know how complicated this could be, but i'd like to discuss it a bit.

about metarigs, samples, and i'll add widgets too, i have mixed opinions. for sure picking those from a blend file is easier to manage for users, but i don't know if it has to be encouraged without a basic knowledge of what a metarig or sample is. I would first try to analyse the clear pro and cons we have with current method and see if it can be enhanced without a complete redesign. what i see as main flaws here is that "encode metarig" and "encode widget" operators are doing only half of the job since they create the .py scripts, but they are not able to place those in any useful place. Moreover "encode metarig" is not including custom informations like constraints and so on that are instead now explicitly supported by some types like raw_copy or basic_pivot. i wonder if we could make all this workflow more manageable, but at same time i believe it was cleverly designed to expose the user what rigify actually is and how it works. I believe this is a plus. what i'd inspect is where user's custom samples and metarigs should be stored, cause inside rigify folder in blender package is something to be totally avoided (at least on mac builds it would break the app signature). if this part can be sorted out i believe that a basic usage could be: • user encodes metarig and adds it to his local metarig folder / package • user encodes widgets and adds them to his local widget folder making those available in selected rig-types whose can use them (basic_copy, basic_pivot ?) also this could affect rigify preferences: • user can pack his customs in a zip • user can load custom metarigs/widgets from preferences i honestly don't know how complicated this could be, but i'd like to discuss it a bit.

Demeter Dzadik commented

2021-06-03 13:09:37 +02:00

In #88711#1170152, @icappiello wrote:
my idea of sorting this out would be to have the source repos available in the rigify preferences
we should have a sort of load/unload or enaled/diabled state for featureset

These are both ideas I've wanted to add as the follow-up for D8519, so I'm totally in agreement.

where user's custom samples and metarigs should be stored

I would hold off looking for an answer to this until the upcoming Asset Browser arrives, since I think that would make a lot of sense for this. And I think it's very close!

> In #88711#1170152, @icappiello wrote: > my idea of sorting this out would be to have the source repos available in the rigify preferences > we should have a sort of load/unload or enaled/diabled state for featureset These are both ideas I've wanted to add as the follow-up for [D8519](https://archive.blender.org/developer/D8519), so I'm totally in agreement. > where user's custom samples and metarigs should be stored I would hold off looking for an answer to this until the upcoming Asset Browser arrives, since I think that would make a lot of sense for this. And I think it's very close!

Nathan Vegdahl commented

2021-06-03 20:34:18 +02:00

Totally agree on removing super_ prefix.

Yay! Those names have always kind of bugged me, ha ha. I can put together some renaming suggestions if you guys would like.

removing the legacy rigs in my opinion is part of a rigify redesign. Even if i am not a fan of the older modules, i believe that removing those should be done carefully.

I'll defer to you guys on this one. But from my perspective, part of the reason I designed Rigify to generate addon-independent rigs was precisely to avoid having to worry quite so much about backwards compatibility. The rigs that Rigify has already generated will continue to work, no matter what we do with Rigify.

So from my perspective, at least, I would be happy to see the legacy stuff ripped out. It would allow both the code and user experience to be simplified, and people can always install my feature set if they want those rig-types in newer Rigify.

but at same time i believe it was cleverly designed to expose the user what rigify actually is and how it works. I believe this is a plus.

I think you're giving me too much credit here. I only wrote "encode metarig" and "encode widget" because, at the time, it seemed like the easiest/most-reliable way to bundle armature and mesh data with Rigify. I don't even think of the resulting Python as code, it's just Python-encoded data. So, for me at least, I'm totally fine with moving that data to blend files, as long as it doesn't impact anything negatively.

But yeah, it depends on whether it can actually be pulled off in a transparent way. I'm most concerned about samples (which in retrospect isn't a great name for what they really are). Keeping the workflow where you can create an empty armature, and just toss in a bunch of rig-type samples and plug them together like legos to create a new metarig is really important IMO. That workflow needs to be fast and streamlined, with each sample quickly accessible from within armature edit mode and tightly associated with its respective rig-type. Not something where you navigate a separate asset system.

(I'm also happy to have samples become more than that as well, but IMO that's the minimum functionality.)

> Totally agree on removing super_ prefix. Yay! Those names have always kind of bugged me, ha ha. I can put together some renaming suggestions if you guys would like. > removing the legacy rigs in my opinion is part of a rigify redesign. Even if i am not a fan of the older modules, i believe that removing those should be done carefully. I'll defer to you guys on this one. But from my perspective, part of the reason I designed Rigify to generate addon-independent rigs was precisely to avoid having to worry quite so much about backwards compatibility. The rigs that Rigify has already generated will continue to work, no matter what we do with Rigify. So from my perspective, at least, I would be happy to see the legacy stuff ripped out. It would allow both the code and user experience to be simplified, and people can always install my feature set if they want those rig-types in newer Rigify. > but at same time i believe it was cleverly designed to expose the user what rigify actually is and how it works. I believe this is a plus. I think you're giving me too much credit here. I only wrote "encode metarig" and "encode widget" because, at the time, it seemed like the easiest/most-reliable way to bundle armature and mesh data with Rigify. I don't even think of the resulting Python as code, it's just Python-encoded data. So, for me at least, I'm totally fine with moving that data to blend files, as long as it doesn't impact anything negatively. But yeah, it depends on whether it can actually be pulled off in a transparent way. I'm most concerned about samples (which in retrospect isn't a great name for what they really are). Keeping the workflow where you can create an empty armature, and just toss in a bunch of rig-type samples and plug them together like legos to create a new metarig is really important IMO. That workflow needs to be fast and streamlined, with each sample quickly accessible from within armature edit mode and tightly associated with its respective rig-type. Not something where you navigate a separate asset system. (I'm also happy to have samples become *more* than that as well, but IMO that's the minimum functionality.)

Ivan Cappiello commented

2021-06-04 16:56:33 +02:00

In #88711#1170506, @cessen wrote:
Yay! Those names have always kind of bugged me, ha ha. I can put together some renaming suggestions if you guys would like.

please do!

I'll defer to you guys on this one. But from my perspective, part of the reason I designed Rigify to generate addon-independent rigs was precisely to avoid having to worry quite so much about backwards compatibility. The rigs that Rigify has already generated will continue to work, no matter what we do with Rigify.

i learned from contributing to maintain rigify for some time that i can't predict what people do with the tool. So as long as your featureset is mantained by you i'd like to have it in.

So from my perspective, at least, I would be happy to see the legacy stuff ripped out. It would allow both the code and user experience to be simplified, and people can always install my feature set if they want those rig-types in newer Rigify.

If it becomes a featureset and you maintain it, we can remove the old code and make everyone happy

I think you're giving me too much credit here. I only wrote "encode metarig" and "encode widget" because, at the time, it seemed like the easiest/most-reliable way to bundle armature and mesh data with Rigify. I don't even think of the resulting Python as code, it's just Python-encoded data. So, for me at least, I'm totally fine with moving that data to blend files, as long as it doesn't impact anything negatively.

What i mean is that, intentionally or not, you created a tool that's very consistent and also helped me at the time to understand how it was meant to work. I consider this good design.

But yeah, it depends on whether it can actually be pulled off in a transparent way. I'm most concerned about samples (which in retrospect isn't a great name for what they really are). Keeping the workflow where you can create an empty armature, and just toss in a bunch of rig-type samples and plug them together like legos to create a new metarig is really important IMO. That workflow needs to be fast and streamlined, with each sample quickly accessible from within armature edit mode and tightly associated with its respective rig-type. Not something where you navigate a separate asset system.

I think the add-on should be as self-contained as possible. Wouldn't look too far to integrate with asset manager.

(I'm also happy to have samples become more than that as well, but IMO that's the minimum functionality.)

Please continue to elaborate more what you'd like to have. Most of the latest added features came from a chat made with you at a bcon table.

> In #88711#1170506, @cessen wrote: > Yay! Those names have always kind of bugged me, ha ha. I can put together some renaming suggestions if you guys would like. > please do! > I'll defer to you guys on this one. But from my perspective, part of the reason I designed Rigify to generate addon-independent rigs was precisely to avoid having to worry quite so much about backwards compatibility. The rigs that Rigify has already generated will continue to work, no matter what we do with Rigify. > i learned from contributing to maintain rigify for some time that i can't predict what people do with the tool. So as long as your featureset is mantained by you i'd like to have it in. > So from my perspective, at least, I would be happy to see the legacy stuff ripped out. It would allow both the code and user experience to be simplified, and people can always install my feature set if they want those rig-types in newer Rigify. > If it becomes a featureset and you maintain it, we can remove the old code and make everyone happy > I think you're giving me too much credit here. I only wrote "encode metarig" and "encode widget" because, at the time, it seemed like the easiest/most-reliable way to bundle armature and mesh data with Rigify. I don't even think of the resulting Python as code, it's just Python-encoded data. So, for me at least, I'm totally fine with moving that data to blend files, as long as it doesn't impact anything negatively. > What i mean is that, intentionally or not, you created a tool that's very consistent and also helped me at the time to understand how it was meant to work. I consider this good design. > But yeah, it depends on whether it can actually be pulled off in a transparent way. I'm most concerned about samples (which in retrospect isn't a great name for what they really are). Keeping the workflow where you can create an empty armature, and just toss in a bunch of rig-type samples and plug them together like legos to create a new metarig is really important IMO. That workflow needs to be fast and streamlined, with each sample quickly accessible from within armature edit mode and tightly associated with its respective rig-type. Not something where you navigate a separate asset system. > I think the add-on should be as self-contained as possible. Wouldn't look too far to integrate with asset manager. > (I'm also happy to have samples become *more* than that as well, but IMO that's the minimum functionality.) Please continue to elaborate more what you'd like to have. Most of the latest added features came from a chat made with you at a bcon table.

Nathan Vegdahl commented

2021-06-06 21:06:02 +02:00

So as long as your featureset is mantained by you i'd like to have it in.
[...]
If it becomes a featureset and you maintain it, we can remove the old code and make everyone happy

Unfortunately, I can't make any commitments to maintaining my feature set. For now, I plan to maintain it to the extent needed for my own personal use, but that's all I can really say. And even then, that may involve e.g. changing the rig types in non-backwards-compatible ways. If that's not enough for you to be comfortable removing the legacy mode, that's totally fair.

Having said that, Rigify has been around for almost 11 years now, and the legacy rig-types have been hidden behind legacy mode for a good chunk of that time. Rigify isn't an operating system or long-term critical piece of infrastructure, and at some point backwards compatibility isn't worth the maintenance burden, I think. And removing legacy mode at the same time as these other changes and the transition to Blender 3.0 seems like good timing. But... I'm also not the one doing the hard work of maintaining Rigify anymore, so I don't want to really push the point. It's totally up to you guys, since you're actually doing the work!

Incidentally, thank you so much for all of your work over the years!

I think the add-on should be as self-contained as possible. Wouldn't look too far to integrate with asset manager.

I definitely agree. If we do switch to blend files to store the data, it should be done in a way that doesn't affect Rigify (or feature sets) being self-contained.

Having said that, I wouldn't be totally against the pre-built metarigs (not samples) being integrated into an asset browser. I think if anything, that would actually make it easier to find the ones you want, with preview images, descriptions, etc.

What i mean is that, intentionally or not, you created a tool that's very consistent and also helped me at the time to understand how it was meant to work.

I guess it just surprises me that the Python-encoded data was a useful tool for learning how Rigify works. I would expect that e.g. looking at the actual rig-type code would be more useful to that end. But I believe you!

(I'm also happy to have samples become more than that as well, but IMO that's the minimum functionality.)

Please continue to elaborate more what you'd like to have. Most of the latest added features came from a chat made with you at a bcon table.

Ah, I didn't mean I had any additional ideas myself. I just meant that if other people had ideas, I'm fine with that, as long as the samples also continue to serve the functionality I outlined. In other words, I was trying to make it clear that I wasn't advocating for specifically limiting their functionality.

> So as long as your featureset is mantained by you i'd like to have it in. > [...] > If it becomes a featureset and you maintain it, we can remove the old code and make everyone happy Unfortunately, I can't make any commitments to maintaining my feature set. For now, I plan to maintain it to the extent needed for my own personal use, but that's all I can really say. And even then, that may involve e.g. changing the rig types in non-backwards-compatible ways. If that's not enough for you to be comfortable removing the legacy mode, that's totally fair. Having said that, Rigify has been around for almost 11 years now, and the legacy rig-types have been hidden behind legacy mode for a good chunk of that time. Rigify isn't an operating system or long-term critical piece of infrastructure, and at some point backwards compatibility isn't worth the maintenance burden, I think. And removing legacy mode at the same time as these other changes and the transition to Blender 3.0 seems like good timing. But... I'm also not the one doing the hard work of maintaining Rigify anymore, so I don't want to really push the point. It's totally up to you guys, since you're actually doing the work! Incidentally, thank you so much for all of your work over the years! > I think the add-on should be as self-contained as possible. Wouldn't look too far to integrate with asset manager. I definitely agree. If we do switch to blend files to store the data, it should be done in a way that doesn't affect Rigify (or feature sets) being self-contained. Having said that, I wouldn't be totally against the pre-built metarigs (not samples) being integrated into an asset browser. I think if anything, that would actually make it easier to find the ones you want, with preview images, descriptions, etc. > What i mean is that, intentionally or not, you created a tool that's very consistent and also helped me at the time to understand how it was meant to work. I guess it just surprises me that the Python-encoded data was a useful tool for learning how Rigify works. I would expect that e.g. looking at the actual rig-type code would be more useful to that end. But I believe you! >> (I'm also happy to have samples become *more* than that as well, but IMO that's the minimum functionality.) > > Please continue to elaborate more what you'd like to have. Most of the latest added features came from a chat made with you at a bcon table. Ah, I didn't mean I had any additional ideas myself. I just meant that if *other* people had ideas, I'm fine with that, as long as the samples also continue to serve the functionality I outlined. In other words, I was trying to make it clear that I wasn't advocating for specifically limiting their functionality.

Guilherme Prestes commented

2021-06-07 20:07:02 +02:00

Added subscriber: @Guilherme-Lacerda-Prestes

Paolo Acampora commented

2021-10-05 22:03:12 +02:00

Added subscriber: @PaoloAcampora

Ajlan Altug commented

2022-01-08 16:50:59 +01:00

Added subscriber: @noc2

Ajlan Altug commented

2022-01-08 16:50:59 +01:00

Why, oh why would you remove Legacy mode? What does anyone do if they need simpler rigs without the rubber hose limbs? What possessed you to make that decision? I mean even the simple arm and leg option yields those stupid rubber hose controls... Why take out that option? Why are you guys so overzealous at times? Why???

Ivan Cappiello commented

2022-01-08 17:39:45 +01:00

@noc2 as you can read from previous comments, the reason is due to the fact that the author of the legacy code is no longer actively mantaining the featureset. Keeping this included in blender itself woukd have meant for the current rigify mantainers to mantain those potentially unsupported features along with their actively mantained code.
I personally requested in the above discussion to make the legacy module an external featureset directly loadable inside the addon itself to ease the removal downsides. In that case the legacy fetureset could have been downloaded directly from the author repository and its life would have been decided directly by the author intention to actively mantain it or not.
Can’t tell how difficult this was to achieve though and if this has been done or not.

That said i can assure you that:

You can download and install the legacy featureset from the author repository. You can ask @cessen for a working link.
The current rigs can be reduced to simpler ones by going in the rig options and set the segment split to 1

@noc2 as you can read from previous comments, the reason is due to the fact that the author of the legacy code is no longer actively mantaining the featureset. Keeping this included in blender itself woukd have meant for the current rigify mantainers to mantain those potentially unsupported features along with their actively mantained code. I personally requested in the above discussion to make the legacy module an external featureset directly loadable inside the addon itself to ease the removal downsides. In that case the legacy fetureset could have been downloaded directly from the author repository and its life would have been decided directly by the author intention to actively mantain it or not. Can’t tell how difficult this was to achieve though and if this has been done or not. That said i can assure you that: 1. You can download and install the legacy featureset from the author repository. You can ask @cessen for a working link. 2. The current rigs can be reduced to simpler ones by going in the rig options and set the segment split to 1

Todor Nikolov commented

2022-01-25 12:56:30 +01:00

I am not sure if this is a good place for suggestions but have you considered a meta rig option to set the bendy bones number in the spine?
Legs and arms and paws have this setting, why not the spine?

I have seen people who were confused because they weight a mesh100% to a spine bone but it keeps bending. :)

I am not sure if this is a good place for suggestions but have you considered a meta rig option to set the bendy bones number in the spine? Legs and arms and paws have this setting, why not the spine? I have seen people who were confused because they weight a mesh100% to a spine bone but it keeps bending. :)

Nathan Vegdahl commented

2022-01-28 23:59:55 +01:00

In #88711#1284993, @icappiello wrote:

You can download and install the legacy featureset from the author repository. You can ask @cessen for a working link.

Yes, no problem! Here's the link to the legacy feature set (I don't expect this link to change for the foreseeable future):
https://github.com/cessen/cessen_rigify_ext

> In #88711#1284993, @icappiello wrote: > 1. You can download and install the legacy featureset from the author repository. You can ask @cessen for a working link. Yes, no problem! Here's the link to the legacy feature set (I don't expect this link to change for the foreseeable future): https://github.com/cessen/cessen_rigify_ext

Roman commented

2022-02-11 22:16:25 +01:00

Added subscriber: @rwman

Trung Phạm commented

2022-06-27 21:14:49 +02:00

Added subscriber: @zNight

Demeter Dzadik commented

2023-11-15 12:10:36 +01:00

A good chunk of these changes have been implemented, which is great. My rigging workflow has transitioned to a standalone system, so I probably won't be making direct contributions to Rigify anymore, so, closing this task.

👍 1

Demeter Dzadik closed this issue

2023-11-15 12:10:39 +01:00

Blender Bot added

and removed

labels 2023-11-15 12:10:41 +01:00

Sign in to join this conversation.