Page MenuHome

Rigify: Clean up Legacy UI
AbandonedPublic

Authored by Demeter Dzadik (Mets) on Thu, Jun 18, 8:13 PM.

Details

Summary

The UI for Legacy Rigify types has been less than stellar. lower_under_case names in the UI, wrong checks to disable the wrong UI areas, properties having dodgy or missing tooltips and names, and not using the new 'LAYER' BoolVectorProperty subtype.

Comparison 1:


Comparison 2:


Diff Detail

Event Timeline

Demeter Dzadik (Mets) requested review of this revision.Thu, Jun 18, 8:13 PM
Demeter Dzadik (Mets) created this revision.
Demeter Dzadik (Mets) edited the summary of this revision. (Show Details)Thu, Jun 18, 8:17 PM
  • Fix the double colon on Rig Type::

I don't see any point doing anything to legacy - if you ask me, all still missing features should be ported to the new code base (or kept as a feature set), and legacy mode nuked completely.

I don't see any point doing anything to legacy - if you ask me, all still missing features should be ported to the new code base (or kept as a feature set), and legacy mode nuked completely.

This was the plan. We discussed a lot in a design thread about it and in the end i think that what we have now is a good base.
All potential missing features from legacy sets should be reported with a description of the main usage and a test file so we can discuss what's the best way to implement those.

A good example about this is the pole feature on limbs. We upgraded the pitchipoy stretchy rotational limb to support it instead of having two separate rig types for limbs.

@Alexander Gavrilov (angavrilov) also hosted a legacy features ported to 2.8x but the main thing is this is not maintained anymore by its author (@Nathan Vegdahl (cessen) i believe).
So unless someone claims it as new maintainer my vote is for removing it.

@Alexander Gavrilov (angavrilov) also hosted a legacy features ported to 2.8x but the main thing is this is not maintained anymore by its author (@Nathan Vegdahl (cessen) i believe).
So unless someone claims it as new maintainer my vote is for removing it.

As the author of the original (legacy) rig types, I'm also in favor of removing them. I actually personally still prefer the original rig types, and don't use the pitchipoy derived ones. But that's the whole point of the external libraries feature: it lets people like me and other studios maintain (and distribute) our own rig types without cluttering the main Rigify distribution with a bunch of confusing choices.

Moreover, @Alexander Gavrilov (angavrilov) already very kindly did the hard work of porting my rig types to an external library (which is maybe what you were referring to above?), which I nabbed off github and cleaned up for myself.

So yeah, as far as I'm concerned, nuke 'em. The external library feature covers all the relevant use cases.

One other note, that's not directly relevant here, but I think is somewhat related to removing the original rig types and legacy mode: I think one of the (as of yet) not fully realized benefits of the external library system is to better curate the official included rig types.

My impression from playing with the current rig types (and this is very true of their pitchipoy roots, at least, which I also helped to develop) is that they are very much "production rigs", in the sense that they get the job done and are powerful, but they are also targeted at a particular environment and aren't clean or principled and can at times be delicate. And to be very clear, I don't mean that in a demeaning way at all. I've made countless production rigs myself (including, as I mentioned, my contributions to the pitchipoy rigs). And they're critical to actually delivering finished animations in a studio environment that develops their own rigs with complex requirements.

However, as a tool for general users, these production rigs can be intimidating, overly complex, hard to understand, and difficult to properly utilize if you aren't part of the group that originally created them.

Moving these production-style rigs out into external libraries would pave the way for a more curated, cleaned up, user-oriented set of rig types to become the defaults, without (I think?) negatively impacting studios since they can maintain their own external library.

Having said that, actually accomplishing this would mean someone having both the time and expertise to create that curated set. And I certainly don't have that time, and I don't actually expect anyone else to put in that time either. So it's likely just a pipe dream. But I just wanted to put the idea out there, because if possible, it would be really nice to turn Rigify into something truly user-oriented and friendly, to the extent possible.

it would be really nice to turn Rigify into something truly user-oriented and friendly, to the extent possible.

I'm all for this! :) And if nuking legacy out would be a step towards this (while keeping it as an external feature set, ideally), I would be happy to help in whatever capacity is welcome.

(marked this patch as abandoned but feel free to discuss more even if off topic, or start a design task if you wish)

I'm all for this! :) And if nuking legacy out would be a step towards this (while keeping it as an external feature set, ideally), I would be happy to help in whatever capacity is welcome.

The original rig types are here, for people that still want to use them:
https://github.com/cessen/cessen_rigify_ext

I plan to semi-maintain them. That may mean making changes as my own preferences in rigging change, for example. And it may also mean they will bit rot on occasion when I'm not personally doing rigging work. But as long as Rigify in its current form is still relevant, I definitely plan to keep using them myself when I do rigging work, and I will maintain them as needed for that purpose.

The original rig types are here, for people that still want to use them:
https://github.com/cessen/cessen_rigify_ext

I plan to semi-maintain them. That may mean making changes as my own preferences in rigging change, for example. And it may also mean they will bit rot on occasion when I'm not personally doing rigging work. But as long as Rigify in its current form is still relevant, I definitely plan to keep using them myself when I do rigging work, and I will maintain them as needed for that purpose.

I added a page with links to the manual to make it more discoverable: https://docs.blender.org/manual/en/dev/addons/rigging/rigify/feature_sets.html

@Nathan Vegdahl (cessen), it’s always a great honor when you join a discussion about rigify!

I would like the users to have all available options, unfortunately this depends on mantaining all the included featuresets.
We have done it for a long time, but each day becomes more difficult beacuse since we are not the authors of the legacy featureset and don’t use it (and this is true for the majority of blenderheads afaik). Some of the original intents and most of the real usage scenarios of your glourious rigs became foggier for us as time passes by.
If you plan to mantain those, i’d have no objections to move it from legacy to an included featurset (disabled by default).
If you ask me, the best solution would be to make BF featured external rigs availbale through blender cloud. But this seems a bit off my jurisdiction.

Some of the original intents and most of the real usage scenarios of your glourious rigs became foggier for us as time passes by.

Yeah, that makes sense. Also, my rigs aren't that glorious, ha ha. :-) I think there are good reasons why most Blender users are using the current rig types more often, namely that they're more flexible and cover a wider range of scenarios. I certainly have my own rigging preferences, but I don't think they're objectively better in any way.

If you plan to mantain those, i’d have no objections to move it from legacy to an included featurset (disabled by default).

So, to be clear, I only plan to maintain them as needed for my own use. I don't have the time or energy to support them, and I also don't necessarily intend to maintain backwards compatibility. So I think, at least for the time being, it makes sense to keep them out-of-tree in my own personal github repo.

I would like the users to have all available options, unfortunately this depends on mantaining all the included featuresets.

That's totally fair! And it's completely up to you guys how you want to approach things. I'm not trying to butt-in or dictate anything here, I'm just tossing in my two cents in case it's valuable to you guys. :-)