Page MenuHome

Rigify 2.8 - general improvements.
Open, Needs Triage by DeveloperPublic

Description

  • disclaimer, this will change and evolve based on the feedback received by the maintainers and animators, for now it's a quick draft to get the conversation going ***

first a question: will the legacy rig be ported as a rig to the new rigify, so we can get rid of the legacy one as a different setup and have it all unified into one?, be able to mix the old pieces with new ones would be beneficial in many ways like being able to use the "new coloring setup", and bring old rigify pieces to the new rigs that used to work better in some case.

The short answer is no.
The 'old' rigify samples implies a lot of code review and maintenance to work flawlessly with the new ones (most troubled area is rig ui generation). Since nobody seems to maintain that part anymore we decided to leave it as-is for blender heads relying on it.
The way i look at this is make a step ahead in the future instead of rolling back in the past.
Let's put it this way, we can implement missing feature on new rigify types if they are needed. We already did with the pole vector option.

Makes total sense and definitelly improving the current stuff is the way to go.

So here are some things in the old legacy rigify that I find more solid in many ways:

  • the legacy FK spine is more "proper" than the Ik spine from the new one.

This is already implemented in our private test branches. Last conference i worked temporarily on a rig at the institute with hjalti that required the same feature. I think this is the way to go.
Why you don't see it anywhere thought, yo may ask. Well the spine code is a total mess, we inherited this from Pitchipoy and never had time to rewrite it from scratch. At this moment i have a script that converts a standard human spine in your suggested one. I think this should be the new spine standard, still there's the problem of too many option in the spine generation. So this feature was put on hold in favour of a facial rig system rewrite (almost done).
I mark this as a todo in medium priority,

great to hear this!

  • the foot pivot in the legacy rig is in the correct position (at the ankle), and in the new one is in the heel which is wrong, so whenever you create a rig then you need to go back and correct the position

Given that "wrong" and "right" shouldn't be used in this kind of discussions since anyone animates and rigs in his way, i remember this too was requested by hjalti for his rig.
I honestly don't agree on that on the whole line. I understand the benefits of putting it there but there are also benefits in keeping it where it is.
Keep also in mind that such changes in the default behaviour would have fallback on previously generated rigs (if you upgrade it) and ik-fk snapping code. So even if it's easy to put the bone where you like (easier also to do it post generation) it's not that easy to foresee what you may have to fix after the bone is placed elsewhere.
Again i have a post script that makes it as you like, but since is a debatable question i'd prefer to set this as an option for the user. This will take time, can't tell when it will happen.

shouldnt but it's necessary in this particular case, anatomy isnt about how you animate, anatomy is right or wrong.
I've talked to several animators like beorn, and sarah so on and i have yet to find an animator that doesn't believe that the foot controller should pivot at the ankle, I've worked in shows with hyper real characters where the main concern is making it realistic or for the lack of a better word accurate, guess where the foot control pivots from.

Also lets remember it's 2.80 we can and should definitelly break backwards compatibility if it's needed to right some wrongs.
Either way, a simple check box in the creation rig that makes it be in the heel or at the ankle (hopefully by default), would solve this issue.

Foot done Wrong

Foot done Right

  • the torso has the pivot slide which allows more flexibility in animation.

I never understood the use of that slider. Before implementing something i should understand first what the user should intend to do with it. Maybe there's a new and better way to accomplish that.
A sort of this was also implemented in hjalti's version for both spine and feet. It's like an arbitrary pivot for rotation, similar to what they already have in agent's rig. Would it help?

that could help, also, what I like about the one in the legacy rigify is that it's simple, what i dont like is that the default value seems very arbitrary though it's in the "right" default place, it's really hard to tell what was the original place it would sit for starters.

The idea of this is that you can move the character in different ways , in the case of a human, think of a character leading with the chest, is much easier pushing that controller to the chest area, and then moving it from there,, I think maybe the one like in the agent rig would help but I find that one a bit cofusing, though it seems that it could be more flexible.

  • the default setup for the fingers in the new rigify is pretty bad, because it forces you to counter animate the falanges to pose the hands correctly.

This is again for backward compatibility. The standard (as discussed at the conference with @Julien DUROURE (julien)) should rather be the super-finger type. That type was not working as expected though, so we fixed it a couple of commits ago. Now it also supports auto-roll detection on generate so you can spend less time rolling bones in edit mode. Give it a try.

yes super finger is what i've been using, why is this not default?
coz this is unacceptable:

Things that I would definitely improve in both systems.

  • the snap ik-fk button that appears when a limb is selected shouldn't exist on a "per limb basis" but should just detect the selected limb and switch that into fk if the ik is selected and vice versa, also it could sit in the "rigify animation tools" panel and be permanent.

This is another complicated one. The solution used here is clever and made by Nathan and Campell i think. The thing is there's an operator that is drawn and run by the interface. To make it work you should pass the operator the arguments. So the button is designed in the ui specifically for the limb you are using and on button press use the operator. I am not saying it's not possible to rework it (i.e. the rigify tools detects the ik form the fk and viceversa if i remember correctly...) but this will require a recode of the whole snapping system.
todo, lowest priority.

sounds fair, it's not a big issue, Im just stating it could be improved.

  • in both systems the space switching is very limited, I modified a new rigify rig to allow multiple spaces in a more flexible way: with the help of @Julien DUROURE (julien) 's add-on to create space switches, with a bit of tweaking of the rig, now each controller has several different spaces that the animator would usually need like: head, chest, hips, cog (center of gravity), root. I have replicated the process manually but instead of a dropdown with just a slider that indicates different spaces like: 0 root, 1 torso, 2 hips.... etc. Here is a sample video of the one i created with Juliens add-on.

i may agree on that, still there is a huge complication in this. Julien can do this since his script is acting POST rig generation. So it can act on existing bones. Rigify generate function doesn't know what other parts are going to be created. So You may (basically from parenting) know that there will be some bone your rig type is attached to, from that you can crawl to the control during the generate function. The way it works now it's crawling to the first root-parent bone that has a type (so the spine) and crawl during the generation to its top level control (torso). I can't see any easy way to sort this out. We tested a forecast feature for bones that has to be generated during the process but it will mean to have a runtime redraw of the ui to constantly analize the meta-rig. And still user should select the correct parent form a very long list. Not usable in my opinion.
The best thing for now is making an addon or better a script that handles that part post generation.
About this i am discussing with @Lucio Rossi (luciorossi) the possibility of adding in the advanced generation panel a post-script slot that can be automatically executed at last in rig generation, letting users customize their rigs in an automated way whit little coding.

that sounds like it could work.
Usually for space switching the best way not to have blending but a snap tool similar to the one for ik and fk, but it's much simpler to do, an other is a "space switching" tool that enables animators to do it with ease, with no such thing existing in blender i usually constrain the controllers to be switched to empties, switch spaces in the frames needed or across the entire animation (what i usually preffer), and then bake back to the controllers so that allows me to keep the animation while having that space changed.

  • about the IK / FK spine it's very important to have an FK spine like the one from the legacy rigify on top of an IK spine like the current one so you use the FK spine for the main motion because it gives more naturalistic motion, but then with the IK spine you can tweak and cheat on top.

I agree. Read my answer obit spine.

yes ! <3

  • the shapes for the shoulder controls is terrible, always hidden in the body, they should be out of the top of the shoulders or across the torso, but in a way you don't need to turn on and off the xray to find them.

Given that the 'shoulder' is not a rig-type and it's using a super_copy rig-type, the widget part has to be rewrote. We just used the already implemented ones, but i think we can make a drop list to select the correct one. The rest should be handled by a revamped (but already present in an object's edit mode) 'encode widget' function.

makes sense, it isnt a biggie, but the bone widget thing i talked about would just ease on this pain.

This could be implemented in 'encode widget' as i wrote above.

totally

  • the bone groups should be colored on a more "industry standard" way, red for left, blue for right, yellow for center, and then an arbitrary color for the face main controllers, and an other color for the secondary controls

Can't tell why it is like that, but since rigify can handle it i can't see why this is in the list of rigify thing you don't like. Just create your standard.

as you say you cant tell why it is like that, i'll tell you
In a rig an animator needs to differentiate things, coloring is used to separate 3 big areas: left, right, and center,
the way rigify is now, if i have two feet on top or close to each other, both have the same shape and the same color, i cant tell wich is wich, why add a layer of color with no meaning?,
--->


Can you tell from this picture which controller is left and which one is right?

The idea is that colors will separate big areas, like side, tweaks, facial etc, and then the shape of the control will tell you or try to tell you what it does or how it works.
So a bare main rig can be:

and with the tweaks:

I'm not going to talk about the face just yet, that's a whole different subject, I think with some tweaks we could have a usable face, and if we give the users a very simple new rigify type we could have a lot more flexibility to build faces like this one: https://vimeo.com/190801903 from @Daniel Lara (Pepeland) (pepeland)

this is EXACTLY what rigify modular face is. Plus automation for eyes and mouth. I am using it right now in studio and seems awesome. After a more in depth test it will go in master. Hold on for it.

<3 <3 <3 <3 <3 <3
if you need testers, i'm always up for it!.

again thank you for your patience,
I wish all these thing plus whatever the guys are talking in the blender animation studio will make for a great animation year in blender.
all this I say and push because I think blender is getting to a great state and we just need to polish it a bit more!
best,

Details

Type
Design

Related Objects

Event Timeline

Should this be separated in a bunch of different tasks?, if so let me know how and ill do it :)

Should this be separated in a bunch of different tasks?, if so let me know how and ill do it :)

I have the original 2.79 file with my created rigs. Would you like to test it out?

Can I add request here, as really non- pro fessional but hobby user for rig-fy rig?

What I often hoped is, adjust "heel positon" without change "zero pose mesh", about rigi-fy rig. (when remove armature, it should show same mesh, not change base shape which only fit current shoes zero pose)

Maybe it is not problem for pro (yours easy rig and generate as you like) to adjust meta-rig, and generate again. or make many character too.

but as basic hobby user, hope to re-use same "character mesh and rig" without many trouble, but easy add some variation (use shape key etc,,)

If there is stable "adjust heel pos-system" ,after generate rig-fy rig, we can easy exchange shoes without change mesh (so all "morph shape" which fit zero posed base shape, can be re-use.with shoes variation. Sorry if it not much as this topic. (I hoped to request it to rig-fy developers long time)

Usually for space switching the best way not to have blending but a snap tool similar to the one for ik and fk, but it's much simpler to do, an other is a "space switching" tool that enables animators to do it with ease, with no such thing existing in blender i usually constrain the controllers to be switched to empties, switch spaces in the frames needed or across the entire animation (what i usually preffer), and then bake back to the controllers so that allows me to keep the animation while having that space changed.

About this space switching thing, the main objective of my T63138 Rigify API redesign proposal is to allow meaningful interaction between rigs. Thus, it should be able to support flexible generation of follow spaces.

The main question is how these spaces should be defined. Rigify is designed as a decentralized system based on individual rigs, so there cannot be a central hard-coded fixed list of locations, except 'rig root' and 'world'. The rest should come from rigs themselves, or maybe specified by the user somehow. These are some possible ways I can think about:

  • Rigs register their bones that should be provided as spaces to either all of their child rigs, or all rigs period.
  • User registers bones, either via per-bone settings, or some centralized list in the armature settings.
  • Rigs that have a controller that needs switched parents should be able to add some ad-hoc local parents specific to that controller.

I'm currently working on a Spline IK tentacle demo rig based on my API, and it's time to add parent switching to its controls, so I'm starting to actively think about this problem right now.

Hey @Alexander Gavrilov (angavrilov) yes, I know and i agree, I think any of ones you mentioned should work, I dont think post rigging operations are idea given that means that if you say save said setup to apply to different characters then you need to do 2 steps
I do like the centralized list one, seems that it could be a way that is clear and organized mostly taking in account that you can clearly and quickly see what will happen where.

As a quick test I went and implemented a class for managing parents based on my API, following the first 'rigs register' approach, and used it in my demo rig.

Here is the generated blender file (requires the very latest build of 2.8), although it only has one rig, so it basically just registers its master control as a parent for its own sub-controls, which isn't much of a demo. However if there were other rigs that used this manager class, they should pick up each other's parent options.

Of course, this all hinges on my API redesign, and at least the spine and head rigs will have to be replaced with versions that work with the new interfaces to provide the choices in your video.

@Luciano Muñoz Sessarego (looch)
I think this thread is confusional. I suggest to split the single tasks in separate threads.
before doing it let's try to summarize and file this list:

• spine FK controls and Pivot Slider (file under feature request)
• super finger as default in metarigs (design)
• ik foot pivot (design)
• snapping operators buttons (feature request)
• space switching (feature request)
• custom widget (feature request)
• add a new standard (left/right) color layout (design)
• modular face rig (feature request)

the main difference between feature request and design is the change you are proposing is conceptual (and requires devs to find a code/design solution fo it) or do you attach a proof of concept on how it is going to work in real case scenario (can be a diff patch if you code or a blend file if you are restructuring the armature).
To be clear the space switch problem is filed under feature request cause there is no given solution about how that should work in terms of armature/bone/constraints and moreover as cleared in previous posts too make this potentially happen you have first to face the rigify dictionary build to identify space owners. So this technically requires both an armature solution and a code improvement (as suggested by @Alexander Gavrilov (angavrilov) ).
I'll try to answer each thread separately once they are splitted.

Cheers,
Ivan

@takeshi funahashi (waitinfuture) i am not sure to understand either the problem and the suggested fix you are proposing.

Yeah ivan sorry for tha mess, that sounds like a proper structure, I totally get what you're going for.

Should this be the main task and have the others as a subtasks?

@Luciano Muñoz Sessarego (looch): I implemented a dropdown-like button in Rig Main Properties panel to switch spaces without changing the control position in my system, and added more tentacles to the file so there is a rig hierarchy.

I wonder what do you think about the interface? All spherical bones can switch parents: http://pasteall.org/blend/index.php?id=51720

How can i see the changes?
let me know i'm happy to help with feedback :)

doh its the blend file, hey that seems to work alright!

doh its the blend file, hey that seems to work alright!

Hey there Luciano, is this add-on pay-ware or will be included in Blender 2.81 on June? I'm more than happy to pay the rig or test the rigs? Thanks mate. 😊

Rigify?, its free and has and always be includad in blender:)

Rigify?, its free and has and always be includad in blender:)

Oh okay... Because I don't see sphere rigs when I have rigify active.

@Luciano Muñoz Sessarego (looch) As a test suggested by @Ivan Cappiello (icappiello), I hacked the use of the new parenting utility into the old spine and arm/leg rigs, and here is the result of generating the 'Basic Human' metarig: http://pasteall.org/blend/index.php?id=51732

I also added a second button to the right of the parent switch field that lets you update keyframes in the action with the parent switch (this may be buggy - not tested much). This is basically similar to the IK/FK switch action buttons in the rigify panel, but generated in the rig script itself. I feel this approach is more modular, as the panel in the rigify addon has to be hard-coded to support specific rig types, while the rig ui script is generated specifically for each rig.