Rigify: feature proposal: allow registration of custom rig types #52758

New Issue

Nathan Vegdahl · 2017-09-15T00:56:44+02:00

Nathan Vegdahl commented

2017-09-15 00:56:44 +02:00

First, I'm super appreciative of the work that's gone into improving Rigify for Blender 2.79! It's a great release, and a great new version of the addon. Definitely an improvement!

However, do I miss my old rig types. I have my own way of rigging things, and for me personally Rigify is now less useful. But I don't think this is actually a problem--rather it's an opportunity to do something I always intended to do with Rigify.

When I first designed Rigify, I didn't actually intend for it to only have a finite curated set of rig types (arms, legs, etc.). My intent was more for it to be an API and framework where anyone could create there own rig types, and mix-and-match as they pleased. After all, a production at studio A will probably have different requirements than a production at studio B. They should each be able to maintain their own rig types, metarig presets, etc..

In practice, I never got around to fulfilling this vision of Rigify--largely because it never came up. But I don't think it will actually be that much work. Rigify has, I think, a fairly stable rig type API now (unless I've missed something, I don't think it's changed in quite a lot of releases). Moreover, the rig types are already automatically registered simply by traversing a directory in the addon directory, so most of the relevant code already exists.

PROPOSAL:
I would like to add a single field to Rigify's addon preferences that specifies a directory to look for custom rig types and metarigs. Any rig types or metarigs found there will then be registered along-side the built-in ones.

This will make Rigify much more flexible, without having to include every possible use-case in Rigify's default curated set of rig types. And for me in particular, it will let me get my rig types back without cluttering the defaults for everyone else.

Does this sound good? Are there any objections if I take a crack at this?

First, I'm super appreciative of the work that's gone into improving Rigify for Blender 2.79! It's a great release, and a great new version of the addon. Definitely an improvement! However, do I miss my old rig types. I have my own way of rigging things, and for me personally Rigify is now less useful. But I don't think this is actually a problem--rather it's an opportunity to do something I always intended to do with Rigify. When I first designed Rigify, I didn't actually intend for it to only have a finite curated set of rig types (arms, legs, etc.). My intent was more for it to be an API and framework where anyone could create there own rig types, and mix-and-match as they pleased. After all, a production at studio A will probably have different requirements than a production at studio B. They should each be able to maintain their own rig types, metarig presets, etc.. In practice, I never got around to fulfilling this vision of Rigify--largely because it never came up. But I don't think it will actually be that much work. Rigify has, I think, a fairly stable rig type API now (unless I've missed something, I don't think it's changed in quite a lot of releases). Moreover, the rig types are already automatically registered simply by traversing a directory in the addon directory, so most of the relevant code already exists. PROPOSAL: I would like to add a single field to Rigify's addon preferences that specifies a directory to look for custom rig types and metarigs. Any rig types or metarigs found there will then be registered along-side the built-in ones. This will make Rigify much more flexible, without having to include every possible use-case in Rigify's default curated set of rig types. And for me in particular, it will let me get my rig types back without cluttering the defaults for everyone else. Does this sound good? Are there any objections if I take a crack at this?

Lucio Rossi was assigned by Nathan Vegdahl

2017-09-15 00:56:44 +02:00

Nathan Vegdahl commented

2017-09-15 00:56:44 +02:00

Changed status to: 'Open'

Nathan Vegdahl commented

2017-09-15 00:56:44 +02:00

Added subscribers: @cessen, @icappiello, @LucioRossi

Brendon Murphy commented

2017-09-15 08:34:21 +02:00

Added subscriber: @BrendonMurphy

Brendon Murphy commented

2017-09-15 08:34:21 +02:00

@cessen hi, your proposal sounds good to me. +1
Your continued involvement in Rigify will be most welcome.
@icappiello and @LucioRossi have been my main contacts with the 'new rigify' and often we spoke and tested in irc, we knew issues and made some hard decisions. Then we found more issues and had bugs solved in Blender, again after much discussion, testing and identifying issues.
Your first comment is really appreciated, thanks.

If your going to bconf, rigify guys are presenting this: https://www.blender.org/conference/2017/presentations/383

Thanks Again

@cessen hi, your proposal sounds good to me. +1 Your continued involvement in Rigify will be most welcome. @icappiello and @LucioRossi have been my main contacts with the 'new rigify' and often we spoke and tested in irc, we knew issues and made some hard decisions. Then we found more issues and had bugs solved in Blender, again after much discussion, testing and identifying issues. Your first comment is really appreciated, thanks. If your going to bconf, rigify guys are presenting this: https://www.blender.org/conference/2017/presentations/383 Thanks Again

Lucio Rossi commented

2017-09-15 12:16:38 +02:00

Hello @cessen ,

It's wonderful to hear from you!!! Rigify has always been a tremendous addon and I'm glad you appreciate the improvements we introduced to make it even better.

Talking about the modularity feature, we didn't of course change this behaviour which is the basis of Rigify philosophy. Users can still introduce their own rig_types, besides, if anyone started a project with an old Blender version or prefers using the original Human or Pitchipoy metarigs and related rig_types he/she can still use them by activating the legacy mode...

Nonetheless, to make the software aware of the presence of old rig_types and suggest the User either to update them or to switch to legacy (a feature we considered important in the transition from the old to the new version) we introduced some "forbidden" rig_type names which correspond basically to the rigs we left in the legacy directory.

Here's a little test:

take for example the biped directory of the legacy mode and copy-paste it into rigs
Rigify will show you the biped.arm rig_type (as it should for modularity) back again.
If you assign biped.arm to a sample though, Rigify will give you a warning telling you that "old" rig_types are present in your Metarig and won't let you Generate it
Change the name of the 'biped' directory to anything else like 'ye_olde_biped' for example and you can use the old rig_types again. The rig_type name would be ye_olde_biped.arm, and some change is needed in the create_sample function, but the Metarig will be Generated normally.

About your proposal I like it! We will discuss about it and see what we can do to make it happen

Thanks
Lucio

Hello @cessen , It's wonderful to hear from you!!! Rigify has always been a tremendous addon and I'm glad you appreciate the improvements we introduced to make it even better. Talking about the modularity feature, we didn't of course change this behaviour which is the basis of Rigify philosophy. Users can still introduce their own rig_types, besides, if anyone started a project with an old Blender version or prefers using the original Human or Pitchipoy metarigs and related rig_types he/she can still use them by activating the legacy mode... Nonetheless, to make the software aware of the presence of old rig_types and suggest the User either to update them or to switch to legacy (a feature we considered important in the transition from the old to the new version) we introduced some "forbidden" rig_type names which correspond basically to the rigs we left in the legacy directory. Here's a little test: - take for example the biped directory of the legacy mode and copy-paste it into rigs - Rigify will show you the biped.arm rig_type (as it should for modularity) back again. - If you assign biped.arm to a sample though, Rigify will give you a warning telling you that "old" rig_types are present in your Metarig and won't let you Generate it - Change the name of the 'biped' directory to anything else like 'ye_olde_biped' for example and you can use the old rig_types again. The rig_type name would be ye_olde_biped.arm, and some change is needed in the create_sample function, but the Metarig will be Generated normally. About your proposal I like it! We will discuss about it and see what we can do to make it happen Thanks Lucio

Ivan Cappiello commented

2017-09-15 12:17:37 +02:00

Hello @cessen ,
thanks for the feedback.

First i want you to know that your advices are, and will always be, more than welcome. You are the creator of this tool and probably the more expert rigger blender had.

Your rig types are not gone. They are just a click away in the add-on preference panel where you (and anyone else who needs them) can enable the legacy mode and run Rigify as you left it. So this is not a problem right now, it's just an option. But i see the wider idea in your proposal.

Before coming to that let me explain you what was the vision behind the changes we made, so you can have a better focus on what may or should change.

Making Rigify easier to use for blender users.
Rigify should not be a tool just for expert riggers, but a concrete help for users out there that need a fast and as easy to use as possible way to rig their characters even if they don't code or know everything about rigging itself.
This was not easy for some reasons.

Rigify never had a documentation (except the general notes in the GitHub pages and the comment lines in the code).
The Pitchipoy definitions added confusion in the lists duplicating all the samples and adding and some incompatibility issues (fk-ik snapping), bugs (typo errors and incomplete code like the super_limb/paw or super_spine/tail).

Documenting is crucial. While you document a tool you understand which grade of knowledge the user should have to use your tool. We realized that to use rigify you probably should first become a rigger and have a general coding knowledge. We came to the conclusion that we should simplify the process of metarig creation/editing by keeping it as much as possible relied on bone position instead of asking user to understand bone rolls and matrices.

We also fixed all the errors in the Pitchipoy code, but while doing that we found some things couldn't be easily fixed (like fk-ik snapping) and that the coexistence between standard rigify samples/types and Pitchipy ones was really tricky to be kept in some cases. Specifically the rig_ui generation should keep track of which limb type you were using and implement the corresponding fk-ik snap part for each limb. In mixed types case scenarios this led to a not consistent ui.

So we tried to first understand why there should be 2 different types/samples to do the same thing and if there were a way to merge both in one and then extend its functions. We decided to start with the newer Pitchipoy types as base since they all features b-bones deformation and a more cartoony result (i.e. you can tear the limbs apart from the chest). Basically, from an user point of view, the main difference between the standard limbs and the Pitchipoy limbs is the pole vector. So we implemented the pole vector part as an user toggle option in the Pitchipoy limb. Then more useful features were added like ik isolation modes and ik following. Where possible we also added the "automatic" alignment option that will take care of bone rolls and foot/hand alignment.

Keeping Rigify a powerful tool for expert riggers
Rigify should definitely continue to be a tool for expert riggers and coders. This means all the basic options - like automatic bone roll and alignment - are enabled by default but still offer the expert user a way to manually set them as desired.
Not a part of the rigify api is changed. This was crucial. We just created in the add-on directory a legacy subdirectory so that the previous code can be run without compromises. This will not, and should never will, limit the ability for developers to add, remove or modify types/samples. It just sets a new default standard for blender users.

Finally coming to your proposal:
Loading a "custom" feature set is for sure an useful option and i have no objections in doing that since it will just add one more option for expert users to replace the standard rigify type/samples with their own.
But if i understand it correctly the problem at this stage is not reviving your types/samples (since you can already use them through legacy), but having a mixable rig types/samples that include both of the worlds.
I think in general is a good idea but as you may have read (hopefully) in my extremely long and tedious post, there are some incompatibility issues that always pop up in mixed cases scenarios. The most evident ones are with rig-ui(s). The code, in my opinion, could become very chaotic if the rig_ui has to handle so many different cases in one single rig (and it did in our tests!). I think we rather need a long term plan on how replace the rig_ui generation code to make it more flexible in hybrid metarig cases.

I'll wait for your comments!

Ivan

Hello @cessen , thanks for the feedback. First i want you to know that your advices are, and will always be, more than welcome. You are the creator of this tool and probably the more expert rigger blender had. Your rig types are not gone. They are just a click away in the add-on preference panel where you (and anyone else who needs them) can enable the legacy mode and run Rigify as you left it. So this is not a problem right now, it's just an option. But i see the wider idea in your proposal. Before coming to that let me explain you what was the vision behind the changes we made, so you can have a better focus on what may or should change. **Making Rigify easier to use for blender users.** Rigify should not be a tool just for expert riggers, but a concrete help for users out there that need a fast and as easy to use as possible way to rig their characters even if they don't code or know everything about rigging itself. This was not easy for some reasons. - Rigify never had a documentation (except the general notes in the GitHub pages and the comment lines in the code). - The Pitchipoy definitions added confusion in the lists duplicating all the samples and adding and some incompatibility issues (fk-ik snapping), bugs (typo errors and incomplete code like the super_limb/paw or super_spine/tail). Documenting is crucial. While you document a tool you understand which grade of knowledge the user should have to use your tool. We realized that to use rigify you probably should first become a rigger and have a general coding knowledge. We came to the conclusion that we should simplify the process of metarig creation/editing by keeping it as much as possible relied on bone position instead of asking user to understand bone rolls and matrices. We also fixed all the errors in the Pitchipoy code, but while doing that we found some things couldn't be easily fixed (like fk-ik snapping) and that the coexistence between standard rigify samples/types and Pitchipy ones was really tricky to be kept in some cases. Specifically the rig_ui generation should keep track of which limb type you were using and implement the corresponding fk-ik snap part for each limb. In mixed types case scenarios this led to a not consistent ui. So we tried to first understand why there should be 2 different types/samples to do the same thing and if there were a way to merge both in one and then extend its functions. We decided to start with the newer Pitchipoy types as base since they all features b-bones deformation and a more cartoony result (i.e. you can tear the limbs apart from the chest). Basically, from an user point of view, the main difference between the standard limbs and the Pitchipoy limbs is the pole vector. So we implemented the pole vector part as an user toggle option in the Pitchipoy limb. Then more useful features were added like ik isolation modes and ik following. Where possible we also added the "automatic" alignment option that will take care of bone rolls and foot/hand alignment. **Keeping Rigify a powerful tool for expert riggers** Rigify should definitely continue to be a tool for expert riggers and coders. This means all the basic options - like automatic bone roll and alignment - are enabled by default but still offer the expert user a way to manually set them as desired. Not a part of the rigify api is changed. This was crucial. We just created in the add-on directory a legacy subdirectory so that the previous code can be run without compromises. This will not, and should never will, limit the ability for developers to add, remove or modify types/samples. It just sets a new default standard for blender users. Finally coming to your proposal: Loading a "custom" feature set is for sure an useful option and i have no objections in doing that since it will just add one more option for expert users to replace the standard rigify type/samples with their own. But if i understand it correctly the problem at this stage is not reviving your types/samples (since you can already use them through legacy), but having a mixable rig types/samples that include both of the worlds. I think in general is a good idea but as you may have read (hopefully) in my extremely long and tedious post, there are some incompatibility issues that always pop up in mixed cases scenarios. The most evident ones are with rig-ui(s). The code, in my opinion, could become very chaotic if the rig_ui has to handle so many different cases in one single rig (and it did in our tests!). I think we rather need a long term plan on how replace the rig_ui generation code to make it more flexible in hybrid metarig cases. I'll wait for your comments! Ivan

Nathan Vegdahl commented

2017-09-15 21:10:08 +02:00

Thanks for your explanations, guys! Yeah, I think what you did absolutely makes sense. I hope I didn't come across as complaining, because that is the opposite of my intent. I am incredibly grateful for all the hard work you guys have put in, both in the code and the documentation. Rather, I think this is a great opportunity to make even further improvements to Rigify.

Documenting is crucial.

Yes, this has been a real problem for Rigify up to this point. I'm so happy that you guys have tackled this!

We also fixed all the errors in the Pitchipoy code.

Yeah, when I consulted with Pitchipoy, and eventually included their rig types in Rigify, it was with the understanding that they would maintain them. And then... they didn't. :-( And I never had the time to clean them up and fix them. Alas.

But that's actually a good example of where this proposal would come in handy. Pitchipoy was effectively having to maintain their own version of Rigify to be able to use their own rig types, which was really inconvenient. That's what motivated their inclusion in Rigify. In the end, I'm glad they were included, because they expanded Rigify's functionality. But moving forward, having a "external library" approach to rig types will allow a much better workflow for studios.

And over time, if a rig type from an external library gets used heavily and turns out to be really useful, it can then be pulled into the curated default set. So it allows a more conservative approach to vetting new rig types for inclusion in Rigify itself.

If your going to bconf, rigify guys are presenting this: https://www.blender.org/conference/2017/presentations/383

Oh, that's awesome! I am indeed going to Bconf this year.

Would you guys be interested in getting together to discuss and possibly hack on this in person at the conference? I think collaborating in person is always more fun. :-)

Thanks for your explanations, guys! Yeah, I think what you did absolutely makes sense. I hope I didn't come across as complaining, because that is the opposite of my intent. I am incredibly grateful for all the hard work you guys have put in, both in the code and the documentation. Rather, I think this is a great opportunity to make even further improvements to Rigify. > Documenting is crucial. Yes, this has been a real problem for Rigify up to this point. I'm so happy that you guys have tackled this! > We also fixed all the errors in the Pitchipoy code. Yeah, when I consulted with Pitchipoy, and eventually included their rig types in Rigify, it was with the understanding that they would maintain them. And then... they didn't. :-( And I never had the time to clean them up and fix them. Alas. But that's actually a good example of where this proposal would come in handy. Pitchipoy was effectively having to maintain their own version of Rigify to be able to use their own rig types, which was really inconvenient. That's what motivated their inclusion in Rigify. In the end, I'm glad they were included, because they expanded Rigify's functionality. But moving forward, having a "external library" approach to rig types will allow a much better workflow for studios. And over time, if a rig type from an external library gets used heavily and turns out to be really useful, it can then be pulled into the curated default set. So it allows a more conservative approach to vetting new rig types for inclusion in Rigify itself. > If your going to bconf, rigify guys are presenting this: https://www.blender.org/conference/2017/presentations/383 Oh, that's awesome! I am indeed going to Bconf this year. Would you guys be interested in getting together to discuss and possibly hack on this in person at the conference? I think collaborating in person is always more fun. :-)

Ivan Cappiello commented

2017-09-15 21:43:34 +02:00

In #52758#459731, @cessen wrote:
Would you guys be interested in getting together to discuss and possibly hack on this in person at the conference? I think collaborating in person is always more fun. :-)

YES! Absolutely!

> In #52758#459731, @cessen wrote: > Would you guys be interested in getting together to discuss and possibly hack on this in person at the conference? I think collaborating in person is always more fun. :-) YES! Absolutely!

Nathan Vegdahl commented

2017-09-16 01:41:54 +02:00

YES! Absolutely!

Awesome! Looking forward to it! See you guys there. :-)

> YES! Absolutely! Awesome! Looking forward to it! See you guys there. :-)

Lucio Rossi commented

2017-09-16 11:26:40 +02:00

Wonderful!!! See you in Amsterdam :)

Nathan Vegdahl commented

2017-11-20 07:43:35 +01:00

Quick update:
I've started work on this, and discovered that getting Python to load completely external modules isn't quite as simple as I assumed. However, I believe I have a solution, so hopefully I should have something to show in the next couple of weeks.

Quick update: I've started work on this, and discovered that getting Python to load completely external modules isn't quite as simple as I assumed. However, I believe I have a solution, so hopefully I should have something to show in the next couple of weeks.

Julien Duroure commented

2017-11-20 08:03:41 +01:00

Added subscriber: @JulienDuroure

Lucio Rossi commented

2017-11-20 12:28:13 +01:00

Hi @cessen !!!

Actually I implemented a version of the feature on my repo. I had to put the external directory in the sys.path though... So I'm not sure if it's the right way to handle it (python imports are a mess!)
Could you please check it out?

cafd248851

Hi @cessen !!! Actually I implemented a version of the feature on my repo. I had to put the external directory in the sys.path though... So I'm not sure if it's the right way to handle it (python imports are a mess!) Could you please check it out? https://github.com/eigen-value/rigify/tree/cafd248851abd0b4fc9f85cfeb3b6b18237bace9

Nathan Vegdahl commented

2017-11-21 04:03:22 +01:00

Hi @LucioRossi !

Oh, ha ha! If I'd known you were going to do it, I would have left it to you. Thanks for putting in the time. :-)

I took a quick look, and from what I can see it mostly looks good. But I haven't examined it super closely yet.

The only thing that makes me a little nervous is that the machinery for loading the external library is a little different than for loading the internal one. Specifically, I would remove the mode parameter from get_rig_list() and make it always load via absolute paths (for internal library as well), and also move the sys.path modification code into get_rig_list(). That way the internal and external library get loaded identically, and we can be sure that any rig type that loads correctly as part of the internal library will also load correctly as part of the external one, and vice-versa. For example, if that causes the internal rig types to stop loading correctly, then we should iron that out so both internal and external work.

Also, we'll eventually want to add support for custom metarigs, etc. as well. But we can do that as a separate pass. Let's get this polished first. :-)

Hi @LucioRossi ! Oh, ha ha! If I'd known you were going to do it, I would have left it to you. Thanks for putting in the time. :-) I took a quick look, and from what I can see it mostly looks good. But I haven't examined it super closely yet. The only thing that makes me a little nervous is that the machinery for loading the external library is a little different than for loading the internal one. Specifically, I would remove the `mode` parameter from `get_rig_list()` and make it always load via absolute paths (for internal library as well), and also move the `sys.path` modification code into `get_rig_list()`. That way the internal and external library get loaded identically, and we can be sure that any rig type that loads correctly as part of the internal library will also load correctly as part of the external one, and vice-versa. For example, if that causes the internal rig types to stop loading correctly, then we should iron that out so both internal and external work. Also, we'll eventually want to add support for custom metarigs, etc. as well. But we can do that as a separate pass. Let's get this polished first. :-)

Lucio Rossi commented

2017-11-21 10:12:00 +01:00

Hi @cessen

You're right I'm sorry I didn't tell you first... I started thinking about a solution to the problem right after Bcon, but thinking leads to coding and you're down the rabbit hole before you know it. One should NEVER start thinking! :D
I agree with you get_rig_list() and maybe get_rig_type() as well should be recoded to work in both cases (omg how hate those functions!) if this doesn't disrupt the relative imports in the internal rig_type modules

Do you feel like doing the polishing and the custom metarig pass?

Hi @cessen You're right I'm sorry I didn't tell you first... I started thinking about a solution to the problem right after Bcon, but thinking leads to coding and you're down the rabbit hole before you know it. One should NEVER start thinking! :D I agree with you `get_rig_list()` and maybe `get_rig_type()` as well should be recoded to work in both cases (omg how hate those functions!) if this doesn't disrupt the relative imports in the internal rig_type modules Do you feel like doing the polishing and the custom metarig pass?

Damien Picard commented

2018-01-04 11:38:38 +01:00

Added subscriber: @pioverfour

Damien Picard commented

2018-01-04 11:38:38 +01:00

Hi guys, happy new year.
We met during the Blender conference, I'm the cutout guy.

I had a bit of time at the end of last year to implement the metarig imports, basically copying what @LucioRossi did with the rig import. More info in this pull request . At the time I hadn't read this thread, and didn't know where things were at. I hope this isn't redundant.

Since I wasn't aware of this thread I made no attempt at polishing the get_rig_list() function, but I didn't modify it either so it shouldn't be hard to merge any cleanup.

As I explain in the PR, and as I mentioned at the conference, it is crucial in some cases (eg. ours) to be able to define custom rig_ui templates. So I implemented this as well. It shouldn't change anything for people not using additional rigs, though.

Hi guys, happy new year. We met during the Blender conference, I'm the cutout guy. I had a bit of time at the end of last year to implement the metarig imports, basically copying what @LucioRossi did with the rig import. More info [in this pull request ](https://github.com/eigen-value/rigify/pull/1). At the time I hadn't read this thread, and didn't know where things were at. I hope this isn't redundant. Since I wasn't aware of this thread I made no attempt at polishing the `get_rig_list()` function, but I didn't modify it either so it shouldn't be hard to merge any cleanup. As I explain in the PR, and as I mentioned at the conference, it is crucial in some cases (eg. ours) to be able to define custom rig_ui templates. So I implemented this as well. It shouldn't change anything for people not using additional rigs, though.

Lucio Rossi commented

2018-01-04 11:51:36 +01:00

Hi @pioverfour,
I got your PR but didn't have time to look into it, sorry.
No redundancy, Metarigs imports had to be done so it's fantastic you had time to spend on it.
I don't know about custom rig_ui templates though, is it something you discussed at Bcon as well?

Hi @pioverfour, I got your PR but didn't have time to look into it, sorry. No redundancy, Metarigs imports had to be done so it's fantastic you had time to spend on it. I don't know about custom **rig_ui** templates though, is it something you discussed at Bcon as well?

Damien Picard commented

2018-01-04 11:52:28 +01:00

This comment was removed by @pioverfour

*This comment was removed by @pioverfour*

Damien Picard commented

2018-01-04 11:57:36 +01:00

I don't think it was retained as a priority but I mentioned it at the meeting we had after the conferences. Not during my talk, though.

I understand your reluctance, and the cutout rigs really are an edgy use case, but they are so far in usage and implementation from the core rigify that keeping the original rig ui wouldn't make much sense, although some parts of the ui_templates are identical. I think it would be a nice addition anyway, for advanced riggers to be able to tweak the ui without modifying the addon.

I don't think it was retained as a priority but I mentioned it at the meeting we had after the conferences. Not during my talk, though. I understand your reluctance, and the cutout rigs really are an edgy use case, but they are so far in usage and implementation from the core rigify that keeping the original rig ui wouldn't make much sense, although some parts of the ui_templates are identical. I think it would be a nice addition anyway, for advanced riggers to be able to tweak the ui without modifying the addon.

Luciano Muñoz Sessarego commented

2018-08-03 12:40:37 +02:00

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented

2018-08-03 12:40:37 +02:00

Hey!,
so how are these custom rig definitions possible? as i was reading in the documentation
https://en.blender.org/index.php/Extensions:2.6/Py/Scripts/Rigging/Rigify#Add_a_new_armature_object
under EXTENDABLE FEATURE SET, it says that the user can save and encode their own metarigs, is that something that is planned or is it available and im just not seeing it?
i really want to be able to make my own face rig and have it available for rigify.

you guys rock,
L

Hey!, so how are these custom rig definitions possible? as i was reading in the documentation https://en.blender.org/index.php/Extensions:2.6/Py/Scripts/Rigging/Rigify#Add_a_new_armature_object under EXTENDABLE FEATURE SET, it says that the user can save and encode their own metarigs, is that something that is planned or is it available and im just not seeing it? i really want to be able to make my own face rig and have it available for rigify. you guys rock, L

Ivan Cappiello commented

2018-08-03 15:37:06 +02:00

Hey @LucianoMunoz,
The feature is there. If you switch to edit mode, in the tool panel you will find a 'Rigify Dev Tools' panel displaying the 'Encode Metarig to Python' and 'Encode Sample to Python' buttons.

Encode Metarig to Python will create a python script in the text editor with the encoded metarig. If you run this script (with the rigify add-on loaded), it will create the metarig for you in the scene.
Encode Sample to Python will create a python script in the text editor with the encoded sample. If you run this script (with the rigify add-on loaded), it will create the sample for you in the scene.

Known limitations:

At this moment rigify will ignore any constraints applied to your metarig while encoding. This is a to-do fix that for one reason or another (read: available time) was always kept on hold.
Making your encoded metarig (or sample) appear in the Add menu is a bit tricky right now and you probably have to know what you are doing to make it work. In effect yourmetarig.py file has to be placed in the correct folder in the add-on directory on your computer. As i am writing, doing this (as other similar things) will break the digital signature of the application, resulting in blender not launching (at least on OSX). We are working on a completely new approach to manage the rigify libraries in the next update. I cannot tell you right now when it's going to be released. Most probably we will do a final 2.79 update (containing this and more) and then move on to 2.8 with a completely redesigned rigify workflow.

cheers,
Ivan

Hey @LucianoMunoz, The feature is there. If you switch to edit mode, in the tool panel you will find a '**Rigify Dev Tools**' panel displaying the '**Encode Metarig to Python**' and '**Encode Sample to Python**' buttons. * **Encode Metarig to Python** will create a python script in the text editor with the encoded metarig. If you run this script (with the rigify add-on loaded), it will create the metarig for you in the scene. * **Encode Sample to Python** will create a python script in the text editor with the encoded sample. If you run this script (with the rigify add-on loaded), it will create the sample for you in the scene. ***Known limitations***: * At this moment rigify will ignore any constraints applied to your metarig while encoding. This is a to-do fix that for one reason or another (read: available time) was always kept on hold. * Making your encoded metarig (or sample) appear in the Add menu is a bit tricky right now and you probably have to know what you are doing to make it work. In effect yourmetarig.py file has to be placed in the correct folder in the add-on directory on your computer. As i am writing, doing this (as other similar things) will break the digital signature of the application, resulting in blender not launching (at least on OSX). We are working on a completely new approach to manage the rigify libraries in the next update. I cannot tell you right now when it's going to be released. Most probably we will do a final 2.79 update (containing this and more) and then move on to 2.8 with a completely redesigned rigify workflow. cheers, Ivan

Luciano Muñoz Sessarego commented

2019-02-07 00:00:00 +01:00

Cool sorry for the delayed response i actually never got an email from this system!

amazing Ivan I have a question:

So when I created a "Rigify Type" that I want as a result, how do I specify what is this result coming from?
To make myself more clear: I want the user to put one bone, and when you add the rigify type to it and then generate the rig 5 more bones should be created and connected / constrained to and relative to that original bone.

How is that achieved ?

thank you so much!, any updates coming on the horizon for rigify?, I have some little features that i believe we should implement mostly concerning how layers, space switching and other little things work, we should talk

Cool sorry for the delayed response i actually never got an email from this system! amazing Ivan I have a question: So when I created a "Rigify Type" that I want as a result, how do I specify what is this result coming from? To make myself more clear: I want the user to put one bone, and when you add the rigify type to it and then generate the rig 5 more bones should be created and connected / constrained to and relative to that original bone. How is that achieved ? thank you so much!, any updates coming on the horizon for rigify?, I have some little features that i believe we should implement mostly concerning how layers, space switching and other little things work, we should talk

Ivan Cappiello commented

2019-02-08 00:43:20 +01:00

Added subscriber: @PaoloAcampora

Ivan Cappiello commented

2019-02-08 00:43:20 +01:00

@LucianoMunoz,
i think there's a misunderstanding about rigify samples, metarigs and rig types.

i'll try to explain this in a simple way:

rig types are built-in rigify modules identified by a property you can add to your chain's first bone to instruct the generate function about what to do after. Meaning that placing a "super-limb>arm" rig-type property on a 3 bone chain's first bone will tell rigify to execute what's inside the rig-type code identifying the first bone as upper-arm, the second as forearm and the last as hand.
rig samples are a predefined set of bone chains with rig-type properties correctly applied, so that adding a rig sample to an armature (in edit mode) and clicking generate will result in the corresponding sample rig. If you often create, let's say an arm with just three fingers applied directly to the hand, you probably don't want always add the arm sample and remove the undesired palm and finger bones. In this case you can just do it once, encode your sample to python for example as "my_super_arm" (with all the limitations described above) and from then on just add one or more "my_super_arm" sample to your characters from the add sample menu.
metarigs are technically the same thing of rig samples but at a higher level since they exist and can be added in object mode as a full bundle. metarigs are intended as all the required features to be used to create that specific rig so that the user should not bother about rig-samples and rig-types but should only place the bone in correct positions on his model and click generate to create the full feature rig.

from what i understand reading your message you are trying to define a new rig-type. There's no way except python coding to do so. Moreover you have to take in account that the process you are trying to teach rigify (through blender APIs) should be bone-name independent and should work on a given set of bone. So before actual programming you should think about how to build up a process that blender can accept through rigify framework. This means that in your scenario, given we have only one bone in this sample, you should probably start duplicating an N number of times the original bone, rename the bone according to your needs, create constraints, and parent the original bone to its possible other sample's parent.
I simplified a bit the process hoping it will be easier to understand, in order to better understand how this happens, you should probably have a look at other rig-types python scripts that are triggered by the generate function.

about rigify updates, there are lots of new features in the working. Mostly a new set of tools/samples/utility for a modular cartoony face rig. Unfortunately we have to work on it in the spare time between a production and another and bug-fixing maintenance. The 2.8 migration process is not helping in that way too. So i can't tell when those updates will be stable enough to go in master. If you have suggestions the best thing should be creating a feature request thread where you explain it in detail, keep me @LucioRossi and @PaoloAcampora as subscribers and i'll try to give a look at what can be done in a reasonable time.

hope it helps.

cheers,
Ivan

@LucianoMunoz, i think there's a misunderstanding about rigify samples, metarigs and rig types. i'll try to explain this in a simple way: 1) rig types are built-in rigify modules identified by a property you can add to your chain's first bone to instruct the generate function about what to do after. Meaning that placing a "super-limb>arm" rig-type property on a 3 bone chain's first bone will tell rigify to execute what's inside the rig-type code identifying the first bone as upper-arm, the second as forearm and the last as hand. 2) rig samples are a predefined set of bone chains with rig-type properties correctly applied, so that adding a rig sample to an armature (in edit mode) and clicking generate will result in the corresponding sample rig. If you often create, let's say an arm with just three fingers applied directly to the hand, you probably don't want always add the arm sample and remove the undesired palm and finger bones. In this case you can just do it once, encode your sample to python for example as "my_super_arm" (with all the limitations described above) and from then on just add one or more "my_super_arm" sample to your characters from the add sample menu. 3) metarigs are technically the same thing of rig samples but at a higher level since they exist and can be added in object mode as a full bundle. metarigs are intended as all the required features to be used to create that specific rig so that the user should not bother about rig-samples and rig-types but should only place the bone in correct positions on his model and click generate to create the full feature rig. from what i understand reading your message you are trying to define a new rig-type. There's no way except python coding to do so. Moreover you have to take in account that the process you are trying to teach rigify (through blender APIs) should be bone-name independent and should work on a given set of bone. So before actual programming you should think about how to build up a process that blender can accept through rigify framework. This means that in your scenario, given we have only one bone in this sample, you should probably start duplicating an N number of times the original bone, rename the bone according to your needs, create constraints, and parent the original bone to its possible other sample's parent. I simplified a bit the process hoping it will be easier to understand, in order to better understand how this happens, you should probably have a look at other rig-types python scripts that are triggered by the generate function. about rigify updates, there are lots of new features in the working. Mostly a new set of tools/samples/utility for a modular cartoony face rig. Unfortunately we have to work on it in the spare time between a production and another and bug-fixing maintenance. The 2.8 migration process is not helping in that way too. So i can't tell when those updates will be stable enough to go in master. If you have suggestions the best thing should be creating a feature request thread where you explain it in detail, keep me @LucioRossi and @PaoloAcampora as subscribers and i'll try to give a look at what can be done in a reasonable time. hope it helps. cheers, Ivan

Luciano Muñoz Sessarego commented

2019-02-08 01:49:38 +01:00

thank you for the thorough explanation ivan!,
i will submit a proposal for some rig types that would be nice to have and other small features that will take the rigs to the next level, also I think we could have just a few more "general options" like the ones you have for ik / fk matching same principle but for switching spaces and so on!
I'll explain it further and get you guys in the loop
again thanks, and hope to see you in bcon!

thank you for the thorough explanation ivan!, i will submit a proposal for some rig types that would be nice to have and other small features that will take the rigs to the next level, also I think we could have just a few more "general options" like the ones you have for ik / fk matching same principle but for switching spaces and so on! I'll explain it further and get you guys in the loop again thanks, and hope to see you in bcon!

Alexander Gavrilov commented

2019-02-11 09:56:59 +01:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2019-02-11 09:56:59 +01:00

In #52758#615714, @icappiello wrote:
about rigify updates, there are lots of new features in the working. Mostly a new set of tools/samples/utility for a modular cartoony face rig. Unfortunately we have to work on it in the spare time between a production and another and bug-fixing maintenance. The 2.8 migration process is not helping in that way too. So i can't tell when those updates will be stable enough to go in master. If you have suggestions the best thing should be creating a feature request thread where you explain it in detail, keep me @LucioRossi and @PaoloAcampora as subscribers and i'll try to give a look at what can be done in a reasonable time.

About that, being the official maintainer implies a responsibility for timely review and intergration of changes contributed by others. The patches by @pioverfour for custom rigs discussed here have already been 'accepted' to a branch by @LucioRossi months ago, but there has been no movement for actually committing that to the addons repository for months. I have also submitted a pull request for a new more flexible base rig api intended to allow interaction between rigs, but that has also been stalled for two months now, despite promises to look at it. I here insist that these core features (with already existing implementation too) be reviewed and committed before 2.8 release, irrespective of the readiness of any other planned or intended features.

P.S. Regarding 2.8 migration, updating rigify to work with 2.8 API changes has been handled directly in the addons repository by blender developers including myself. I have also done a 2.8 merge for the already 'accepted' changes on github, and will help with merging my pull request, so that's not an argument either.

> In #52758#615714, @icappiello wrote: > about rigify updates, there are lots of new features in the working. Mostly a new set of tools/samples/utility for a modular cartoony face rig. Unfortunately we have to work on it in the spare time between a production and another and bug-fixing maintenance. The 2.8 migration process is not helping in that way too. So i can't tell when those updates will be stable enough to go in master. If you have suggestions the best thing should be creating a feature request thread where you explain it in detail, keep me @LucioRossi and @PaoloAcampora as subscribers and i'll try to give a look at what can be done in a reasonable time. About that, being the official maintainer implies a responsibility for timely review and intergration of changes contributed by others. The patches by @pioverfour for custom rigs discussed here have already been 'accepted' to a branch by @LucioRossi months ago, but there has been no movement for actually committing that to the addons repository for months. I have also submitted a [pull request ](https://github.com/eigen-value/rigify/pull/13) for a new more flexible base rig api intended to allow interaction between rigs, but that has also been stalled for two months now, despite promises to look at it. I here insist that these core features (with already existing implementation too) be reviewed and committed before 2.8 release, irrespective of the readiness of any other planned or intended features. P.S. Regarding 2.8 migration, updating rigify to work with 2.8 API changes has been handled directly in the addons repository by blender developers including myself. I have also done a 2.8 merge for the already 'accepted' changes on github, and will help with merging my pull request, so that's not an argument either.

Ivan Cappiello commented

2019-02-11 16:29:55 +01:00

Added subscribers: @lucio-3, @damien-2

Ivan Cappiello commented

2019-02-11 16:29:55 +01:00

@angavrilov,

being the official maintainer implies a responsibility for timely review and intergration of changes contributed by others.

I don't honestly know if there's such implication in mantaining a module, but i am sure it implies bug fixing, keep the add-on working, design, discuss and manage features implementations and request.

The patches by @damien-2 Picard (pioverfour) for custom rigs discussed here have already been 'accepted' to a branch by @lucio-3 Rossi (luciorossi) months ago, but there has been no movement for actually committing that to the addons repository for months.

I don't now what do you mean by "accepted". Adding a new feature or making a radical change like the proposal from which this thread started it's not an easy process. We have to be sure both the feature is working in a real case scenario and that the modification is not going to break any compatibility with current workflow (even if 2.8 is allowed to break backward compatibility it doesn't mean it has to). This, as you may read in above answers, is done as volunteer contribution and is actually paid by our studio and personal jobs. We cannot guarantee a timeframe to do revisions.
We usually proceed as follow in order of priority/available time:

bug-fixing
add-on design / redesing
new feature implementation
pull requests
unfortunately the last months, despite our good will to do that, we didn't have the time to make a deep review of pull request. Sorry for that but blaming or complaining won't make this faster or easier.

I here insist that these core features (with already existing implementation too) be reviewed and committed before 2.8 release, irrespective of the readiness of any other planned or intended features.

You can insist, i take notice of that, still if we have small time to review the code you'll have to wait. Moreover, we usually keep an open and public discussion on feature request/modify/design proposal (see Rigify Update and Fixes for example). We did before being rigify mantainers and we keep this going on. Keeping the discussion open will not make the review slower or faster and can't harm in any way.

I have also submitted a pull request for a new more flexible base rig api intended to allow interaction between rigs, but that has also been stalled for two months now, despite promises to look at it.

Still as mantainer we also are in charge of design and give guidelines for making the feature merge easier, safer and faster. In this area i remember @LucioRossi gave you instructions you decided to bypass making the review less likely acceptable (for us) without an in depth revision and testing (meaning we have to find the time to do that. Write out where/why we disagree or modify your patch for approval. So you'll have to wait more).
With 2.7 we dealt with lots of bug fixing caused by radical changes on basic design. We'd like to keep this safe and sound.

I am sorry you are disappointend by the time it takes, but i have no easy solution for that. You can either follow more strictly @LucioRossi code guidelines and use some patience to wait for the revision or (as we did) just make your new branch without all design restriction imposed by current mantainers, make it public and testable and finally ask to move that branch to master.

P.S. Regarding 2.8 migration, updating rigify to work with 2.8 API changes has been handled directly in the addons repository by blender developers including myself. I have also done a 2.8 merge for the already 'accepted' changes on github, and will help with merging my pull request, so that's not an argument either.

I am glad to read that, so you can start by accepting @LucioRossi general code guidelines and make it easier for us.

To be clear, i think you have good ideas and great abilities, so i'd like to work on rigify with you, so let's ry to make this process easier.

Cheers,
Ivan

@angavrilov, > being the official maintainer implies a responsibility for timely review and intergration of changes contributed by others. I don't honestly know if there's such implication in mantaining a module, but i am sure it implies bug fixing, keep the add-on working, design, discuss and manage features implementations and request. > The patches by @damien-2 Picard (pioverfour) for custom rigs discussed here have already been 'accepted' to a branch by @lucio-3 Rossi (luciorossi) months ago, but there has been no movement for actually committing that to the addons repository for months. I don't now what do you mean by "accepted". Adding a new feature or making a radical change like the proposal from which this thread started it's not an easy process. We have to be sure both the feature is working in a real case scenario and that the modification is not going to break any compatibility with current workflow (even if 2.8 is allowed to break backward compatibility it doesn't mean it has to). This, as you may read in above answers, is done as volunteer contribution and is actually paid by our studio and personal jobs. We cannot guarantee a timeframe to do revisions. We usually proceed as follow in order of priority/available time: 1) bug-fixing 2) add-on design / redesing 3) new feature implementation 4) pull requests unfortunately the last months, despite our good will to do that, we didn't have the time to make a deep review of pull request. Sorry for that but blaming or complaining won't make this faster or easier. > I here insist that these core features (with already existing implementation too) be reviewed and committed before 2.8 release, irrespective of the readiness of any other planned or intended features. You can insist, i take notice of that, still if we have small time to review the code you'll have to wait. Moreover, we usually keep an open and public discussion on feature request/modify/design proposal (see [Rigify Update and Fixes ](https://developer.blender.org/T48892) for example). We did before being rigify mantainers and we keep this going on. Keeping the discussion open will not make the review slower or faster and can't harm in any way. > I have also submitted a pull request for a new more flexible base rig api intended to allow interaction between rigs, but that has also been stalled for two months now, despite promises to look at it. Still as mantainer we also are in charge of design and give guidelines for making the feature merge easier, safer and faster. In this area i remember @LucioRossi gave you instructions you decided to bypass making the review less likely acceptable (for us) without an in depth revision and testing (meaning we have to find the time to do that. Write out where/why we disagree or modify your patch for approval. So you'll have to wait more). With 2.7 we dealt with lots of bug fixing caused by radical changes on basic design. We'd like to keep this safe and sound. I am sorry you are disappointend by the time it takes, but i have no easy solution for that. You can either follow more strictly @LucioRossi code guidelines and use some patience to wait for the revision or (as we did) just make your new branch without all design restriction imposed by current mantainers, make it public and testable and finally ask to move that branch to master. >P.S. Regarding 2.8 migration, updating rigify to work with 2.8 API changes has been handled directly in the addons repository by blender developers including myself. I have also done a 2.8 merge for the already 'accepted' changes on github, and will help with merging my pull request, so that's not an argument either. I am glad to read that, so you can start by accepting @LucioRossi general code guidelines and make it easier for us. To be clear, i think you have good ideas and great abilities, so i'd like to work on rigify with you, so let's ry to make this process easier. Cheers, Ivan

Alexander Gavrilov commented

2019-02-11 17:14:39 +01:00

In #52758#617903, @icappiello wrote:
I don't honestly know if there's such implication in mantaining a module, but i am sure it implies bug fixing, keep the add-on working, design, discuss and manage features implementations and request.

Well, if you were an official maintainer of a module in the C core of blender, I would have already asked Brecht or Cambell to review it instead, and I feel like they would likely have done it. This is basically what happened with all my recent animation and NLA patches. Being an official maintainer without actually doing any code review is holding the module hostage.

I don't now what do you mean by "accepted". Adding a new feature or making a radical change like the proposal from which this thread started it's not an easy process.

The custom rig packages feature has already been implemented by @pioverfour, the pull requests have been reviewed and merged by @LucioRossi into a branch months ago. I have made a git branch merging that branch and the code in the 2.8 addons repository a couple of months ago now. However they are still not in the actual addons repository and there is no roadmap for doing that.

Custom rigs is a bigger feature than any kind of improvement in a specific built-in rig, or even a new built-in rig.

We usually proceed as follow in order of priority/available time:

bug-fixing

add-on design / redesing

new feature implementation

pull requests

Responding to pull requests (at least at the level of actually discussing it) should be at priority 2, because you are not the only person involved there. It's not like there are that many pull requests either.

I have also submitted a pull request for a new more flexible base rig api intended to allow interaction between rigs, but that has also been stalled for two months now, despite promises to look at it.

I am sorry you are disappointend by the time it takes, but i have no easy solution for that. You can either follow more strictly @LucioRossi code guidelines and use some patience to wait for the revision or (as we did) just make your new branch without all design restriction imposed by current mantainers, make it public and testable and finally ask to move that branch to master.

The work on the pull request has been completed two months ago now, with zero meaningful response either in the pull request, by email or chat since then (it feels as if the email chain basically died once I called it 'ready for review'). Don't you think that's enough waiting?

> In #52758#617903, @icappiello wrote: > I don't honestly know if there's such implication in mantaining a module, but i am sure it implies bug fixing, keep the add-on working, design, discuss and manage features implementations and request. Well, if you were an official maintainer of a module in the C core of blender, I would have already asked Brecht or Cambell to review it instead, and I feel like they would likely have done it. This is basically what happened with all my recent animation and NLA patches. Being an official maintainer without actually doing any code review is holding the module hostage. > I don't now what do you mean by "accepted". Adding a new feature or making a radical change like the proposal from which this thread started it's not an easy process. The custom rig packages feature has already been implemented by @pioverfour, the pull requests have been reviewed and merged by @LucioRossi into a branch months ago. I have made a git branch merging that branch and the code in the 2.8 addons repository a couple of months ago now. However they are still not in the actual addons repository and there is no roadmap for doing that. Custom rigs is a bigger feature than any kind of improvement in a specific built-in rig, or even a new built-in rig. > We usually proceed as follow in order of priority/available time: > 1) bug-fixing > 2) add-on design / redesing > 3) new feature implementation > 4) pull requests Responding to pull requests (at least at the level of actually discussing it) should be at priority 2, because you are not the only person involved there. It's not like there are that many pull requests either. >> I have also submitted a pull request for a new more flexible base rig api intended to allow interaction between rigs, but that has also been stalled for two months now, despite promises to look at it. > I am sorry you are disappointend by the time it takes, but i have no easy solution for that. You can either follow more strictly @LucioRossi code guidelines and use some patience to wait for the revision or (as we did) just make your new branch without all design restriction imposed by current mantainers, make it public and testable and finally ask to move that branch to master. The work on the pull request has been completed two months ago now, with **zero** meaningful response either in the pull request, by email or chat since then (it feels as if the email chain basically died once I called it 'ready for review'). Don't you think that's enough waiting?

Ivan Cappiello commented

2019-02-11 17:33:42 +01:00

@angavrilov

Well, if you were an official maintainer of a module in the C core of blender, I would have already asked Brecht or Cambell to review it instead, and they would likely have done it. This is basically what happened with all my recent animation and NLA patches. Being an official maintainer without actually doing any code review is holding the module hostage.

that's the point. This is an external add-on. We are not module owner. We volunteer and mantain the code since we were the only studio left using it. I think we did it well in the past years. As everything in this world could have been / be done better. If you feel like the code is hostage, i already suggested what to do. Test your branch publicly, become mantainer and feel free to do whatever you want. You can also ask for mantain the rigify module. That's not anyone's property, it's open source!

Responding to pull requests (at least at the level of actually discussing it) should be at priority 2, because you are not the only person involved there.

You can put that on your priority list as you prefer.

The work on the pull request has been completed two months ago now, with zero meaningful response either in the pull request, by email or chat since then (it feels as if the email chain basically died once I called it 'ready for review'). Don't you think that's enough waiting?

Do as all other contributors do (and we did) make a redesign proposal, make it public, make people involved. Making a pull request and complaining to have it approved without respecting design and code guidelines from the author is not a clear way to go. You got answers in that, just decided your code is good and can override guidelines. So you are assuming you approve yourself the code and its design and we are only here to say yes. That's not how i intend a collaboration basically because "you are not the only person involved there".

i am really sorry you keep going on this line.

Ivan

@angavrilov > Well, if you were an official maintainer of a module in the C core of blender, I would have already asked Brecht or Cambell to review it instead, and they would likely have done it. This is basically what happened with all my recent animation and NLA patches. Being an official maintainer without actually doing any code review is holding the module hostage. that's the point. This is an external add-on. We are not module owner. We volunteer and mantain the code since we were the only studio left using it. I think we did it well in the past years. As everything in this world could have been / be done better. If you feel like the code is hostage, i already suggested what to do. Test your branch publicly, become mantainer and feel free to do whatever you want. You can also ask for mantain the rigify module. That's not anyone's property, it's open source! > Responding to pull requests (at least at the level of actually discussing it) should be at priority 2, because you are not the only person involved there. You can put that on your priority list as you prefer. > The work on the pull request has been completed two months ago now, with zero meaningful response either in the pull request, by email or chat since then (it feels as if the email chain basically died once I called it 'ready for review'). Don't you think that's enough waiting? Do as all other contributors do (and we did) make a redesign proposal, make it public, make people involved. Making a pull request and complaining to have it approved without respecting design and code guidelines from the author is not a clear way to go. You got answers in that, just decided your code is good and can override guidelines. So you are assuming you approve yourself the code and its design and we are only here to say yes. That's not how i intend a collaboration basically because "you are not the only person involved there". i am really sorry you keep going on this line. Ivan

Alexander Gavrilov commented

2019-02-11 17:41:59 +01:00

In #52758#617998, @icappiello wrote:
Do as all other contributors do (and we did) make a redesign proposal, make it public, make people involved. Making a pull request and complaining to have it approved without respecting design and code guidelines from the author is not a clear way to go. You got answers in that, just decided your code is good and can override guidelines. So you are assuming you approve yourself the code and its design and we are only here to say yes. That's not how i intend a collaboration basically because "you are not the only person involved there".

I don't think in abstract proposals, I think in code. The reason my pull requests has all those rig changes in it is that I literally came up with details of the API by refactoring the rig code to look nice (for me, anyway), so the pull request is my proposal.

> In #52758#617998, @icappiello wrote: > Do as all other contributors do (and we did) make a redesign proposal, make it public, make people involved. Making a pull request and complaining to have it approved without respecting design and code guidelines from the author is not a clear way to go. You got answers in that, just decided your code is good and can override guidelines. So you are assuming you approve yourself the code and its design and we are only here to say yes. That's not how i intend a collaboration basically because "you are not the only person involved there". I don't think in abstract proposals, I think in code. The reason my pull requests has all those rig changes in it is that I literally came up with details of the API by refactoring the rig code to look nice (for me, anyway), so the pull request **is** my proposal.

Alexander Gavrilov commented

2019-02-11 17:59:05 +01:00

Btw anyway, what is the precise status of this repository, and the branches in it? https://github.com/eigen-value/rigify

If you are a module owner with exclusive rights to commit, it makes some sense to have a separate repository with pull requests and such. Otherwise, I feel like third-party changes (like ones discussed here, or my base rig refactoring) should be going via blender patch review system and be committed directly to the add-ons repository. As I mentioned, blender developers already commit 2.8-related changes directly to the add-ons repository, so it has diverged from that github one.

Btw anyway, what is the precise status of this repository, and the branches in it? https://github.com/eigen-value/rigify If you are a module owner with exclusive rights to commit, it makes some sense to have a separate repository with pull requests and such. Otherwise, I feel like third-party changes (like ones discussed here, or my base rig refactoring) should be going via blender patch review system and be committed directly to the add-ons repository. As I mentioned, blender developers already commit 2.8-related changes directly to the add-ons repository, so it has diverged from that github one.

Lucio Rossi commented

2019-02-11 21:27:48 +01:00

Hi guys!

Just a brief incursion inside the topic.
I promise I won't blame anybody, but accept no blame as well :D
First and foremost OS projects are fun! They should be...
But they're also kind of anarchic sometimes :S
Personally I got to meet all sorts of people from top-notch-devs to half-dev-half-riggers to code-breaker-full-time-artist to I-just-wanna-have-this-s*-working-like-magic kind of guys.
Interaction and collaboration with such diverse experiences can be deeply constructive, but boy, is it hard work!?.
Yup!
Whenever more than one person is working on a piece of code it gets to a point where a certain set of rules have to be agreed upon.
Do you get to cherry pick the rules?
Well... it depends on your idea of "openness".
Let's put it like this, if all sides agree on some basic rules and everybody sticks to them... Bingo! Let the fun ensue!
But what if all sides discard rules they don't like? The scenario changes back to a who-does-what-how-where messy kind of thing.
It can still go somewhere for sure, but questions like

Is it gonna be faster or slower?
Will it stick to a schedule?
Will it be a readable code?
Will it be optimised?
Will it be (reasonably) tested and bug-free?
Will it be useful for the artists?

Don't apply any longer

Only one question lingers in my opinion:

Is it still fun?

This is is just my 5c so no need to actually answer any - rhetorical :D - question or comment on my comment, If I know you guys a little, I guess you'd rather spend this time coding or rigging or making art

Cheers!

Hi guys! Just a brief incursion inside the topic. I promise I won't blame anybody, but accept no blame as well :D First and foremost OS projects are fun! They should be... But they're also kind of anarchic sometimes :S Personally I got to meet all sorts of people from top-notch-devs to half-dev-half-riggers to code-breaker-full-time-artist to I-just-wanna-have-this-s*-working-like-magic kind of guys. Interaction and collaboration with such diverse experiences can be deeply constructive, but boy, is it hard work!?. Yup! Whenever more than one person is working on a piece of code it gets to a point where a certain set of rules have to be agreed upon. Do you get to cherry pick the rules? Well... it depends on your idea of "openness". Let's put it like this, if all sides agree on some basic rules and everybody sticks to them... Bingo! Let the fun ensue! But what if all sides discard rules they don't like? The scenario changes back to a who-does-what-how-where messy kind of thing. It can still go somewhere for sure, but questions like Is it gonna be faster or slower? Will it stick to a schedule? Will it be a readable code? Will it be optimised? Will it be (reasonably) tested and bug-free? Will it be useful for the artists? Don't apply any longer Only one question lingers in my opinion: Is it still fun? This is is just my 5c so no need to actually answer any - rhetorical :D - question or comment on my comment, If I know you guys a little, I guess you'd rather spend this time coding or rigging or making art Cheers!

Alexander Gavrilov commented

2019-02-11 21:40:29 +01:00

In #52758#618153, @LucioRossi wrote:
Hi guys!

Hi, putting my base rig pull request aside since it's off-topic for this thread, I wonder if we can at least speed up committing the already accepted patches (including custom rig pack support from @pioverfour that is directly relevant to this bug) into the official add-ons repository somehow? For those it's been like half a year already since they were first submitted...

If at least something moved on I won't be feeling so exasperated ;)

> In #52758#618153, @LucioRossi wrote: > Hi guys! Hi, putting my base rig pull request aside since it's off-topic for this thread, I wonder if we can at least speed up committing the already accepted patches (including custom rig pack support from @pioverfour that is directly relevant to this bug) into the official add-ons repository somehow? For those it's been like half a year already since they were first submitted... If at least something moved on I won't be feeling so exasperated ;)

Ivan Cappiello commented

2019-02-15 12:38:57 +01:00

I wonder if we can at least speed up committing the already accepted patches (including custom rig pack support from @damien-2 Picard (pioverfour) that is directly relevant to this bug)

The reason why this is not committed is related to design issues. Even after review some question are raised during usage.
The proposed patch specifies an external custom path through the addon preference pane. This is not a great design idea in my opinion since will have to point to a specific folder where you should have to rebuild the rigify modules structure. I believe the correct behaviour should be a sort of install external module button (just like the install addon button) that will copy the external module in the correct syspath making the module local and available. Doing this will require also a list of installed modules and a remove module button in the preference.

This was never tested. @angavrilov if you want can try a better implemetation as described above. This would be more likely approved, even thought the feature should be extensively tested in a real case scenario before committing to master. The current (not committed to master) implementation made easier for other smaller studios to keep testing how their external libraries are working in the official rigify. Bringing this feature to common users require a bit more work on design.

Hope this clarify the situation,
Ivan

> I wonder if we can at least speed up committing the already accepted patches (including custom rig pack support from @damien-2 Picard (pioverfour) that is directly relevant to this bug) The reason why this is not committed is related to design issues. Even after review some question are raised during usage. The proposed patch specifies an external custom path through the addon preference pane. This is not a great design idea in my opinion since will have to point to a specific folder where you should have to rebuild the rigify modules structure. I believe the correct behaviour should be a sort of install external module button (just like the install addon button) that will copy the external module in the correct syspath making the module local and available. Doing this will require also a list of installed modules and a remove module button in the preference. This was never tested. @angavrilov if you want can try a better implemetation as described above. This would be more likely approved, even thought the feature should be extensively tested in a real case scenario before committing to master. The current (not committed to master) implementation made easier for other smaller studios to keep testing how their external libraries are working in the official rigify. Bringing this feature to common users require a bit more work on design. Hope this clarify the situation, Ivan

Damien Picard commented

2019-02-15 13:20:21 +01:00

In #52758#621084, @icappiello wrote:
I believe the correct behaviour should be a sort of install external module button (just like the install addon button) that will copy the external module in the correct syspath making the module local and available. Doing this will require also a list of installed modules and a remove module button in the preference.

Do you mean like this modification from last august ?

“you can add several feature sets by choosing a .zip file on disk. This will get installed to a new 2.79/scripts/rigify dir.”

> In #52758#621084, @icappiello wrote: > I believe the correct behaviour should be a sort of install external module button (just like the install addon button) that will copy the external module in the correct syspath making the module local and available. Doing this will require also a list of installed modules and a remove module button in the preference. Do you mean like [this modification ](https://github.com/eigen-value/rigify/pull/1#issuecomment-410130787) from last august ? “you can add several feature sets by choosing a .zip file on disk. This will get installed to a new `2.79/scripts/rigify` dir.”

Ivan Cappiello commented

2019-03-14 11:06:46 +01:00

Changed status from 'Open' to: 'Resolved'

Ivan Cappiello closed this issue

2019-03-14 11:06:46 +01:00

Ivan Cappiello commented

2019-03-14 11:06:46 +01:00

if @cessen has no objection I am closing this as resolved as the feature is implemented in 2.8 as reported at https://developer.blender.org/D4364