*** 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 ***
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) 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:
{F6929219}
>> 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 '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 @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.
>> - 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/)
>
> 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?,
---> {F6928837}
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:
{F6928831}
and with the tweaks:
{F6929240}
>> 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 @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,