Page MenuHome

Rigify: store advanced options in armature instead of window manager
ClosedPublic

Authored by Damien Picard (pioverfour) on Sep 4 2019, 4:32 PM.

Details

Summary

By storing the Rigify advanced generation options (name, target rig, target ui script) in the armature data instead of the window manager as before, multiple rigs can have different options. Additionnally, these options are stored in the blend file, and not lost when reloading.

Also, the rig name is not automatically suffixed with _rig, which doesn’t make sense as far as I can tell.

Diff Detail

Event Timeline

Since I committed the refactoring that heavily touches generate.py, this definitely has some merge conflicts now.

@Alexander Gavrilov (angavrilov) Yes, I thought so. I’ll update it as soon as possible.

storing the data on the armature is ok. The whole system is designed to make appending of metarig as simple as possible.

i am more concerned about the naming issue:

Since the source rig is by default named metarig, when it generates use to default rig as name. Most people uses it like that.
If you do not append _rig at the end, when making a proxy it will became very difficult to get what you are looking for.
So, yes, it could be removed, but then you have to explain the users they have to put something there to find it later on.
i think this is not good so, in my opinion, _rig should stay.

i am more concerned about the naming issue:

Since the source rig is by default named metarig, when it generates use to default rig as name. Most people uses it like that.
If you do not append _rig at the end, when making a proxy it will became very difficult to get what you are looking for.
So, yes, it could be removed, but then you have to explain the users they have to put something there to find it later on.
i think this is not good so, in my opinion, _rig should stay.

I don’t think I understand the problem. Say I create character Char. I’ll want to proxy only the armature when linking the character to a shot scene. It makes sense to me that the object I’ll manipulate is named the same as the character, so the rig will be named Char as well. The meshes might be called Char_mesh.001 or something. Then the armature’s not particularly hard to find in the list: the rig object appears first in alphabetical order since it doesn’t have a suffix.

I’m not saying mine is a perfect use case, or even a typical use case, but it is a use case different from yours. I don’t think all users will name their objects the same, and this scheme shouldn’t be imposed on them. What if they want to have a rig_ prefix instead of a suffix? what if they want to have a .rig with a dot as a separator? what if they want to name it in their native language _squelette? what if they use two armatures for the same character? And what about the ui script: there is no ambiguity there, it should be Char_ui.py and not Char_rig_ui.py. EDIT: never mind the last part, it’s another issue.

As you said, there is a default name, rig, which is fine. The custom name is in Advanced Options. I think an advanced user will know if they need a suffix added for them.

I’m not saying mine is a perfect use case, or even a typical use case, but it is a use case different from yours. I don’t think all users will name their objects the same, and this scheme shouldn’t be imposed on them. What if they want to have a rig_ prefix instead of a suffix? what if they want to have a .rig with a dot as a separator? what if they want to name it in their native language _squelette? what if they use two armatures for the same character? And what about the ui script: there is no ambiguity there, it should be Char_ui.py and not Char_rig_ui.py.

As you said, there is a default name, rig, which is fine. The custom name is in Advanced Options. I think an advanced user will know if they need a suffix added for them.

@Damien Picard (pioverfour) i am trying always to define a predictable user pow scenario. I am not against your concept, just saying this could be elaborated a bit before removing the defaults.
Advanced mode is not used only by experienced users, it is the gateway for useful not-so-advanced utilities too, like define a second rig in the scene.
i think this can make better, and you point in a right direction, but let's discuss a bit on how to make it more obvious.

what about a naming section with "suffix" checkbox, a text field and an append/prepend option?

what about a naming section with "suffix" checkbox, a text field and an append/prepend option?

It would be better than the current options, but I think it would make the system less flexible and more complicated, with little benefit since they will need to set the naming options for every rig they create anyway. Setting three options is neither faster nor simpler than just one.
I believe naming things properly is the user’s responsibility, whether creating objects by hand or using an add-on.

Perhaps we should ask other users on devtalk.

It would be better than the current options, but I think it would make the system less flexible and more complicated, with little benefit since they will need to set the naming options for every rig they create anyway. Setting three options is neither faster nor simpler than just one.
I believe naming things properly is the user’s responsibility, whether creating objects by hand or using an add-on.

i believe that exposing the need of using a prefix or suffix is better support for the user than answer to all fake bug reports related to a wrong usage of the add-on. If you let people understand what the add-on should work like, they usually learn how to do it. Rigify has suffered for long time of undocumented feature and obscure feature options in the ui.

i think we can at least use an "auto suffix" option to let the user decide if they want to handle this manually or not.

i believe that exposing the need of using a prefix or suffix is better support for the user than answer to all fake bug reports related to a wrong usage of the add-on. If you let people understand what the add-on should work like, they usually learn how to do it. Rigify has suffered for long time of undocumented feature and obscure feature options in the ui.

Of course, features should be documented so the user knows how they work, but that’s not what this issue is about. It’s about whether there is a need for an affix, which I don’t believe there is. Hence my proposition to ask other users’ opinion, because we disagree on this. :)

i think we can at least use an "auto suffix" option to let the user decide if they want to handle this manually or not.

This is a better option than a checkbox and text field, and it would keep the same behaviour as before, but I still think it is unnecessary.

My point is this: when I create anything in Blender (object, modifier, constraint, etc.), it has a logical default name (Circle, Array, Copy Location, etc.). I then choose whether I want to use this name or rename it as I see fit. Rigify is a bit different in that I can rename the object before I actually create it, using the Rig Name option. But it’s otherwise the same: if I choose a name, I expect the rig to use the name I choose, not an arbitrary suffix.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 15 2019, 1:03 PM
This revision was automatically updated to reflect the committed changes.