Page MenuHome

Rigify: IK2FK / FK2IK - not working on 2.8
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 419.35

Blender Version
Broken: version: 2.80 (sub 51), branch: blender2.7, commit date: 2019-03-24 00:06, hash: rB79f67acccb36
Worked: (optional)

Short description of error
The buttons to transfer animation from one to the other dont work, also they are named incorrectly the one to transfer from IK to FK is named FK2IK and vice versa

Exact steps for others to reproduce the error
Open up a rigify rig, do some animation on the IK hand, push FK2IK or IK2FK and you'll get an error like the ones here

I can privately send a file for testing upon request.

Details

Type
Bug

Related Objects

Event Timeline

Brecht Van Lommel (brecht) renamed this task from IK2FK / FK2IK - not working on 2.8 to Rigify: IK2FK / FK2IK - not working on 2.8.

The code generated by rigify doesn't work in latest 2.8, it needs to be regenerated or manually updated. Not sure if there is a problem with newly generated rigs too.

any pointers on how to update the code?
though I have to mention that panel is the rigify addon panel, it isnt generated on the go when the rig is created.

That panel still uses code in the generated script object. It should be updated by re-generating the rig.

ah okay, I'll try that!, thanks!

This is more a backward compatibility issue.
The affected part is the rig-ui and Rigify tools python script generated in previous versions.

By design since its origins Rigify rigs are created so that using the rig should not require the add-on to be loaded (or even installed at all). This means that the python scripts generated by rigify are locally stored inside the blend file.
There have been few radical changes between 2.79b, nightly 2.79 build and 2.8 as noticed by my comments here:
Fix for T48988 - Enabling bbone easing for posemode

As for now current nightly build of 2.79 and 2.8 seems to be aligned (at least on this crucial thing) and could be more easily handled in the conversion.

As noticed by @Alexander Gavrilov (angavrilov) re-generating the rig can solve the issue since it re-creates from scratch python utils too. In my opinion this could be designed to work in a better way. We dealt with similar design issues moving from 0.4 to 0.5. In that case opening a blender file containing an old rigify rig/metarig would have displayed a warning giving the user the option to

  1. upgrade the rig/metarig to make it work in new version (displaying also a confirm pop-up disclaiming feature may change)
  2. run rigify in legacy mode and ignore new features

From an user point of view i think would be better if we could create a similar feature for 2.8 too. On an armature level Fix for T48988 - Enabling bbone easing for posemode and Fix T62284: apply a retroactive fix for T57366 to old files. seems to take care of everything. Makes sense to let blender handle this on load since it's about armatures in general. Unfortunately the script part is from rigify. So we have here 2 options in my opinion:

  1. automatic: if rigify is enabled, and detects an old rig, re-generates the python scripts
  2. manual: if rigify is enabled, and detects an old rig, displays the user a warning and the option to re-generate the python scripts
Ivan Cappiello (icappiello) triaged this task as Confirmed, Low priority.Mar 25 2019, 11:03 AM
Ivan Cappiello (icappiello) raised the priority of this task from Confirmed, Low to Confirmed, High.

Seems there's more than one issue here:

"The buttons to transfer animation from one to the other dont work, also they are named incorrectly the one to transfer from IK to FK is named FK2IK and vice versa"

In my tests there's no error on newly generated rigs, but still seems it just does nothing at all.
This will require a more in depth investigation. Hope @Lucio Rossi (luciorossi) find some time to have a look at it.

EDIT:
the functions are working. start and end frame needs to be set.
Also it seems to work quite right with newly generated rigs. Can't see a mismatch in description/functions.

@Luciano Muñoz Sessarego (looch) can you explain better where is the mismatch?

Maybe I can have a look later too - what is the correct way to use those buttons?

Regarding updates, the problem is that unlike with blender files, the script have no version information in them.

okay the panel now works if i generate it in 2.8.

the thing about the buttons is that FK2IK Action and IK2FK Action should snap all the FK keys to the IK positions, and the IK to the FK positions, but now it's vice versa.
In contraposition the FK2IK & IK2FK Pose buttons are correct.

Would you guys consider it if I would do a video talking about small improvements to rigify that I think would make it much better and more flexible?

@Luciano Muñoz Sessarego (looch)

the thing about the buttons is that FK2IK Action and IK2FK Action should snap all the FK keys to the IK positions, and the IK to the FK positions, but now it's vice versa. In contraposition the FK2IK & IK2FK Pose buttons are correct.

There’s a difference between the two functions. If you read the descriptions overing the mouse on the buttons it will be clear.
• The pose buttons are intended to snap, so ik2fk means snap the ik to the fk position.
• The action button are intended as bake, so ik2fk action means transfer the ik action to the fk controls. This is also similar to what the operator calls inside the code actually using blender’s bake operators.

Would you guys consider it if I would do a video talking about small improvements to rigify that I think would make it much better and more flexible?

Can’t see the real benefit of this since the discussion will be going on as a text thread, maybe sample files would help more.

Cheers,
Ivan

Hi guys, thanks for all the great work on rigify,
Here i'll try to detail a few things I keep on finding that could improve rigify a lot.

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.

Good things about the new rigify that i like:

  • being able to switch between pole vector and rotational axis is cool, actually having them be optional in the rig is great because it allows animators to pick when they're animating which style is best for them or the particular shot.
  • the palm control having freed up rotations
  • having an Ik spine is great, but just as an option that can live with the FK one.
  • the unified active and selected coloring system is a thing that should become a blender default 100%, I honestly do it to all my rigs and my blender now.

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.
  • 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
  • the torso has the pivot slide which allows more flexibility in animation.
  • 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.

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.
  • 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.

  • 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.
  • 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.
  • Also rigify should probably have the "bone widget" add-on or a new improved version of it embedded to easily work out the shapes. (https://lollypopman.com/2016/09/26/addon-bone-widget/)
  • 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

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 Martinez Lara (pepeland)

I think that's it!, thank you for your patience!
best,
L

@Luciano Muñoz Sessarego (looch)

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.

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,

  • 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.

  • 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?

  • 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.

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.

  • 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.

  • 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.

  • 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.

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

  • 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.

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 Martinez Lara (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.

I think that's it!, thank you for your patience!
best,
L

cheers,
Ivan

  • 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.

About this: it's not clear how this will work in animation.
• How the animation is working when you switch a owner space? i guess already placed keyframes will not work anymore. I sorted out no solution for this (as i told julien at the conference) did you find one?
• How do you blend between the modes? rigify has an animatable slider for the root/parent relation and a boolean operator for letting the limb out of the rig and let the user make his own child of constrains on it. Right now it seems to handle lot of more complicated case scenarios and it' highly customizable than what i see here. Sure lacks of an easy-ui drop lists like this.

One thing is, now that Rigify supports external rig packages, you have to ask the question why everything has to be in base rigify? E.g. the legacy rigs can be converted into a feature set package that can be used with new rigify enabled.

Regarding spine, it seems the main reason it's so messy is it tries to handle three unrelated components (spine, head and tail) in one rig. It should really be split into separate parts, and as an example in my API redesign patch I made separated spine and head rigs, which use the rig interaction features of the new API to preserve the only rational reason to merge the rigs I could think of, i.e. that they form a continuous B-Bone chain: https://developer.blender.org/D4624#104956

Edit: Splitting the spine rig allows having multiple different implementations of the actual spine section, which is the part that people are the most likely to have different ideas about.

One thing is, now that Rigify supports external rig packages, you have to ask the question why everything has to be in base rigify? E.g. the legacy rigs can be converted into a feature set package that can be used with new rigify enabled.

Exactly.
Still... who will maintain that? who will keep this mergeable with other samples from other packages? who will take care of rig-uis merging?

Regarding spine, it seems the main reason it's so messy is it tries to handle three unrelated components (spine, head and tail) in one rig. It should really be split into separate parts, and as an example in my API redesign patch I made separated spine and head rigs, which use the rig interaction features of the new API to preserve the only rational reason to merge the rigs I could think of, i.e. that they form a continuous B-Bone chain: https://developer.blender.org/D4624#104956

@Alexander Gavrilov (angavrilov) there is a reason why it is done like that in fact. There are cases in which you may want to have a single b-bone chain for all the spine (snakes, fishes, birds) accomplish this with split rigs is difficult (until your recode, that has to be tested for other potential fallbacks)
I'd like instead (for now) on having BOTH the super-spine and the tail and neck types available.
I appreciate your redesign can handle it.

Ivan Cappiello (icappiello) closed this task as Resolved.EditedApr 10 2019, 3:02 PM
Ivan Cappiello (icappiello) claimed this task.

i am closing this as resolved since after more than a week no more related issues are reported
Will move my proposal:

Unfortunately the script part is from rigify. So we have here 2 options in my opinion:
automatic: if rigify is enabled, and detects an old rig, re-generates the python scripts
manual: if rigify is enabled, and detects an old rig, displays the user a warning and the option to re-generate the python scripts

into a separate topic 2.8 auto/manual upgrade rig-ui for Rigify (as @Luciano Muñoz Sessarego (looch) should have made for his design proposal) to keep track of it.

Hey thanks for the great feedback and seems that we're mostly on the same page.

Please take my further comments with a little grain of salt as I dont intend to be offensive.

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.

  • 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 Martinez Lara (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,

oops i just saw the other message,
tell me if i posted it in the wrong place