Rigify 2.8 - general improvements. #63485

New Issue

Luciano Muñoz Sessarego · 2019-04-11T11:11:20+02:00

2019-04-11 11:11:20 +02:00

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, asimple 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 @JulienDuroure) 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 @JulienDuroure '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?,
- >
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 @pepe-school-land

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,

***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.** ![FootWrong.gif](https://archive.blender.org/developer/F6970764/FootWrong.gif) Foot done Wrong ![FootRight.gif](https://archive.blender.org/developer/F6970767/FootRight.gif) 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 @JulienDuroure) 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: ![roll.gif](https://archive.blender.org/developer/F6929219/roll.gif) >> 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 @JulienDuroure '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?, - > ![2019-04-10 20_28_26-Window.png](https://archive.blender.org/developer/F6928837/2019-04-10_20_28_26-Window.png) 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: ![2019-04-10 20_24_57-Window.png](https://archive.blender.org/developer/F6928831/2019-04-10_20_24_57-Window.png) and with the tweaks: ![2019-04-10 23_39_09-Window.png](https://archive.blender.org/developer/F6929240/2019-04-10_23_39_09-Window.png) >> 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 @pepe-school-land >> > 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,

Luciano Muñoz Sessarego commented

2019-04-11 11:11:20 +02:00

Added subscribers: @LucioRossi, @JulienDuroure, @pepe-school-land, @LucianoMunoz, @icappiello

Jonathan Romer commented

2019-04-14 05:06:23 +02:00

Added subscriber: @AnsettAnimation

Luciano Muñoz Sessarego commented

2019-04-17 16:24:48 +02:00

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

Jonathan Romer commented

2019-04-18 08:41:09 +02:00

In #63485#662252, @LucianoMunoz wrote:
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?

> In #63485#662252, @LucianoMunoz wrote: > 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?

takeshi funahashi commented

2019-04-18 12:40:56 +02:00

Added subscriber: @TakeshiFunahashi

takeshi funahashi commented

2019-04-18 12:40:56 +02:00

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)

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)

Alexander Gavrilov commented

2019-05-08 16:47:22 +02:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2019-05-08 16:47:22 +02:00

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 #63138 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.

> 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 #63138 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 ](https://github.com/angavrilov/angavrilov-rigs/blob/master/rigs/limbs/spline_tentacle.py) 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.

Luciano Muñoz Sessarego commented

2019-05-08 22:07:04 +02:00

Hey @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.

Hey @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.

Alexander Gavrilov commented

2019-05-08 22:26:17 +02:00

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.

As a quick test I went and implemented [a class ](https://github.com/angavrilov/angavrilov-rigs/commit/6ebd3773ec6b75e4890fa19b6b2f3db0a38fa5d3) for managing parents based on my API, following the first 'rigs register' approach, and used it in my demo rig. Here is the [generated ](http://pasteall.org/blend/index.php?id=51709) 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.

Ivan Cappiello commented

2019-05-09 10:19:53 +02:00

@LucianoMunoz
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 @angavrilov ).
I'll try to answer each thread separately once they are splitted.

Cheers,
Ivan

@LucianoMunoz 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 @angavrilov ). I'll try to answer each thread separately once they are splitted. Cheers, Ivan

Ivan Cappiello commented

2019-05-09 10:22:09 +02:00

@TakeshiFunahashi i am not sure to understand either the problem and the suggested fix you are proposing.

takeshi funahashi commented

2019-05-09 10:44:17 +02:00

Added subscriber: @ivan-14

takeshi funahashi commented

2019-05-09 10:44:17 +02:00

This comment was removed by @TakeshiFunahashi

*This comment was removed by @TakeshiFunahashi*

Luciano Muñoz Sessarego commented

2019-05-09 12:00:35 +02:00

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?

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?

Alexander Gavrilov commented

2019-05-12 00:55:47 +02:00

@LucianoMunoz: 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

@LucianoMunoz: 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

Luciano Muñoz Sessarego commented

2019-05-12 01:45:45 +02:00

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

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

Luciano Muñoz Sessarego commented

2019-05-12 01:46:42 +02:00

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

Jonathan Romer commented

2019-05-12 04:37:58 +02:00

In #63485#676970, @LucianoMunoz wrote:
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. ?

> In #63485#676970, @LucianoMunoz wrote: > 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. ?

Luciano Muñoz Sessarego commented

2019-05-12 11:19:38 +02:00

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

Jonathan Romer commented

2019-05-12 11:35:56 +02:00

In #63485#677033, @LucianoMunoz wrote:
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.

> In #63485#677033, @LucianoMunoz wrote: > 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.

Alexander Gavrilov commented

2019-05-12 20:48:45 +02:00

@LucianoMunoz As a test suggested by @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.

@LucianoMunoz As a test suggested by @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.

Christophe Swolfs commented

2019-07-23 11:05:11 +02:00

Added subscriber: @ChristopheSwolfs

Alexander Gavrilov commented

2019-07-25 11:21:23 +02:00

@LucianoMunoz I wonder if you have any ideas about what changes in blender itself would remove the need for that 'space switching' feature? Space switching as described is obviously a workaround, as it is limited to a fixed lists of potential parents, and incurs a constant performance cost even when not used. The root issue here is that it's difficult for animators themselves to add a switch between parents in blender as need arises, so how do you think it should ideally work?

For instance, one issue I imagine with how things currently are is that switching parents requires adding e.g. Child Of constraints, which are not attached to actions containing the animation. Do you think that is important?

Edit: If, for example, you could design a totally new constraint for switching parents (possibly with additional UI for convenience), how should it work? This constraint can allow multiple targets if needed, like Armature.

@LucianoMunoz I wonder if you have any ideas about what changes in blender itself would remove the need for that 'space switching' feature? Space switching as described is obviously a workaround, as it is limited to a fixed lists of potential parents, and incurs a constant performance cost even when not used. The root issue here is that it's difficult for animators themselves to add a switch between parents in blender as need arises, so how do you think it should ideally work? For instance, one issue I imagine with how things currently are is that switching parents requires adding e.g. Child Of constraints, which are not attached to actions containing the animation. Do you think that is important? Edit: If, for example, you could design a totally new constraint for switching parents (possibly with additional UI for convenience), how should it work? This constraint can allow multiple targets if needed, like Armature.

Luciano Muñoz Sessarego commented

2019-07-25 11:52:29 +02:00

In #63485#677178, @angavrilov wrote:
@LucianoMunoz As a test suggested by @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.

nice!

In #63485#734720, @angavrilov wrote:
@LucianoMunoz I wonder if you have any ideas about what changes in blender itself would remove the need for that 'space switching' feature? Space switching as described is obviously a workaround, as it is limited to a fixed lists of potential parents, and incurs a constant performance cost even when not used. The root issue here is that it's difficult for animators themselves to add a switch between parents in blender as need arises, so how do you think it should ideally work?

For instance, one issue I imagine with how things currently are is that switching parents requires adding e.g. Child Of constraints, which are not attached to actions containing the animation. Do you think that is important?

Edit: If, for example, you could design a totally new constraint for switching parents (possibly with additional UI for convenience), how should it work? This constraint can allow multiple targets if needed, like Armature.

I have to say it is a complex question, and a long one, so to answer:
one the guys with the clear ideas, raf anzovin that detected the issue you described way longer than i did, and explains it extensively here: https://www.justtodosomethingbad.com/
to be more specific check out this particular post which is a little bit more "down to earth":
https://www.justtodosomethingbad.com/blog/2018/10/25/clip-show
and on the other hand someone started experimenting something very similar in blender based on his own research he came down to a really similar setup
https://blenderartists.org/t/freeik/1157419

> In #63485#677178, @angavrilov wrote: > @LucianoMunoz As a test suggested by @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. nice! > In #63485#734720, @angavrilov wrote: > @LucianoMunoz I wonder if you have any ideas about what changes in blender itself would remove the need for that 'space switching' feature? Space switching as described is obviously a workaround, as it is limited to a fixed lists of potential parents, and incurs a constant performance cost even when not used. The root issue here is that it's difficult for animators themselves to add a switch between parents in blender as need arises, so how do you think it should ideally work? > > For instance, one issue I imagine with how things currently are is that switching parents requires adding e.g. Child Of constraints, which are not attached to actions containing the animation. Do you think that is important? > > Edit: If, for example, you could design a totally new constraint for switching parents (possibly with additional UI for convenience), how should it work? This constraint can allow multiple targets if needed, like Armature. I have to say it is a complex question, and a long one, so to answer: one the guys with the clear ideas, raf anzovin that detected the issue you described way longer than i did, and explains it extensively here: https://www.justtodosomethingbad.com/ to be more specific check out this particular post which is a little bit more "down to earth": https://www.justtodosomethingbad.com/blog/2018/10/25/clip-show and on the other hand someone started experimenting something very similar in blender based on his own research he came down to a really similar setup https://blenderartists.org/t/freeik/1157419

Rombout Versluijs commented

2019-09-11 02:10:31 +02:00

Added subscriber: @RomboutVersluijs

Rombout Versluijs commented

2019-09-11 02:10:31 +02:00

I just bumped into this thread looking at some updates done on addons. Last year i made an addon which allows for much easier custom MetaRig save. This option is already in the addon, but it only saves a py file and thus not handy for reuse. Therefor i made the addon which easily saves your custom MetaRig so you can load when Blender is reloaded, it will show in the add menu. The addon can also save rig settings.

Perhaps something like this could be implemented, i think its a missing feature.

You can find it here on my GitHub

{F7732869, size=full, alt=preview of interface}

I just bumped into this thread looking at some updates done on addons. Last year i made an addon which allows for much easier custom MetaRig save. This option is already in the addon, but it only saves a py file and thus not handy for reuse. Therefor i made the addon which easily saves your custom MetaRig so you can load when Blender is reloaded, it will show in the add menu. The addon can also save rig settings. Perhaps something like this could be implemented, i think its a missing feature. You can find it here on my [GitHub ](https://github.com/schroef/Rigify-Save-Presets) {[F7732869](https://archive.blender.org/developer/F7732869/rigify-save-presets.png), size=full, alt=preview of interface}

Demeter Dzadik commented

2019-09-18 15:03:03 +02:00

Added subscriber: @Mets

Andrea commented

2019-09-20 10:56:57 +02:00

Added subscriber: @Giro

Andrea commented

2019-09-20 11:09:10 +02:00

Hi everybody,
I am Andrea Giro rom Italy, I am a professional animator and blender user since the very beginning of this open software.
I am approaching animation in blender this very last month and I wanted to try to have an easy rigging tool to do my personal project so I approached Rigify as it seems very nice and easy to me.
If I can I would like to give my contribute as a tester if it can help and on this I would spend my first word about the foot pivot :)

definitely it shoulden't be at the base of the toe but on the ankle. In 12 years of carrear as animator I never saw it like the rigify default is now.
And about this can I change the pivot to bring it back where it should be?
Another thing is about the spine: normally I always animate with 3 controls 1 the hip 1 the torso and 1 more or less in the place of the shoulder to give some more mobility to the chest and shoulder.
Another is the IK arm follow, they should follow the hip (if you need to constrain them to the hip), but mostly I should parent them to the torso as I want them to follow the body part they are attached to. I f I rotate the torso now they stay parented to the hip, so is useless in my opinion.

this are some of my opinion based on my experience, but I wanted to thanks everybody involved in the development of this great tool anyway.
thanks

Andrea

Hi everybody, I am Andrea Giro rom Italy, I am a professional animator and blender user since the very beginning of this open software. I am approaching animation in blender this very last month and I wanted to try to have an easy rigging tool to do my personal project so I approached Rigify as it seems very nice and easy to me. If I can I would like to give my contribute as a tester if it can help and on this I would spend my first word about the foot pivot :) - definitely it shoulden't be at the base of the toe but on the ankle. In 12 years of carrear as animator I never saw it like the rigify default is now. And about this can I change the pivot to bring it back where it should be? - Another thing is about the spine: normally I always animate with 3 controls 1 the hip 1 the torso and 1 more or less in the place of the shoulder to give some more mobility to the chest and shoulder. - Another is the IK arm follow, they should follow the hip (if you need to constrain them to the hip), but mostly I should parent them to the torso as I want them to follow the body part they are attached to. I f I rotate the torso now they stay parented to the hip, so is useless in my opinion. this are some of my opinion based on my experience, but I wanted to thanks everybody involved in the development of this great tool anyway. thanks Andrea

Alexander Gavrilov commented

2019-09-20 11:20:31 +02:00

Did you test Rigify in the latest development builds? I recently committed a big refactor that significantly improves performance, and also adds new features like more complicated parent switching for IK.

Andrea commented

2019-09-20 11:57:40 +02:00

In #63485#780533, @angavrilov wrote:
Did you test Rigify in the latest development builds? I recently committed a big refactor that significantly improves performance, and also adds new features like more complicated parent switching for IK.

I am using the 0.5.1 version
didn't test the dev builds. I'll do, promise!

> In #63485#780533, @angavrilov wrote: > Did you test Rigify in the latest development builds? I recently committed a big refactor that significantly improves performance, and also adds new features like more complicated parent switching for IK. I am using the 0.5.1 version didn't test the dev builds. I'll do, promise!

Ivan Cappiello commented

2019-09-20 12:14:42 +02:00

In #63485#773371, @RomboutVersluijs wrote:
I just bumped into this thread looking at some updates done on addons. Last year i made an addon which allows for much easier custom MetaRig save. This option is already in the addon, but it only saves a py file and thus not handy for reuse. Therefor i made the addon which easily saves your custom MetaRig so you can load when Blender is reloaded, it will show in the add menu. The addon can also save rig settings.

Perhaps something like this could be implemented, i think its a missing feature.

You can find it here on my GitHub

{F7732869, size=full, alt=preview of interface}

I think this is useful but a more robust and general solution has to be found to make rigify handle custom widget/metarigs/colorschemes. A giant step forward was done implementing the import of custom rigs from rigify preferences.
I think is nice to hace this addon out there while we figure out what can be done to make this options available in rigify itself.
Cheers,
Ivan

> In #63485#773371, @RomboutVersluijs wrote: > I just bumped into this thread looking at some updates done on addons. Last year i made an addon which allows for much easier custom MetaRig save. This option is already in the addon, but it only saves a py file and thus not handy for reuse. Therefor i made the addon which easily saves your custom MetaRig so you can load when Blender is reloaded, it will show in the add menu. The addon can also save rig settings. > > Perhaps something like this could be implemented, i think its a missing feature. > > You can find it here on my [GitHub ](https://github.com/schroef/Rigify-Save-Presets) > > {[F7732869](https://archive.blender.org/developer/F7732869/rigify-save-presets.png), size=full, alt=preview of interface} I think this is useful but a more robust and general solution has to be found to make rigify handle custom widget/metarigs/colorschemes. A giant step forward was done implementing the import of custom rigs from rigify preferences. I think is nice to hace this addon out there while we figure out what can be done to make this options available in rigify itself. Cheers, Ivan

Ivan Cappiello commented

2019-09-20 12:31:45 +02:00

@Giro,
Thanks for joining the discussion.

As i already answered in previous posts, regarding the spine i totally agree, this is a todo. Was put on hold since @angavrilov made a giant upgrade to rigify api and blender bone/constraint system itself.
Think is time to come back to this.

About the limb parent and domain switching, @angavrilov has already done a great job in his branch. This was impossible to do before his api rewrite. Have a look at it.

For the foot pivot i’d still like to keep the discussion about benefits/issues rather than “standards”, “anatomy” and “usual”. I am not saying anyone is right or wrong about it, i’d just like to know what’s the issue of having a different pivot point and what’s the benefit of having it elsewere.
I see @LucianoMunoz quoting raf anzovin. Well setup machine for maya (made by anzovin studio) has the foot pivot out of the ankle. So again i don’t think anyone can be so absolutely sure on what has to be done.

Given that, i think that this can now be easily solved since rigify can import custom feature sets so we can create a “pro” custom feature set where we take care of all this requests without changing default behavior or forcing people to agree on a standard.

Ivan

@Giro, Thanks for joining the discussion. As i already answered in previous posts, regarding the spine i totally agree, this is a todo. Was put on hold since @angavrilov made a giant upgrade to rigify api and blender bone/constraint system itself. Think is time to come back to this. About the limb parent and domain switching, @angavrilov has already done a great job in his branch. This was impossible to do before his api rewrite. Have a look at it. For the foot pivot i’d still like to keep the discussion about benefits/issues rather than “standards”, “anatomy” and “usual”. I am not saying anyone is right or wrong about it, i’d just like to know what’s the issue of having a different pivot point and what’s the benefit of having it elsewere. I see @LucianoMunoz quoting raf anzovin. Well setup machine for maya (made by anzovin studio) has the foot pivot out of the ankle. So again i don’t think anyone can be so absolutely sure on what has to be done. Given that, i think that this can now be easily solved since rigify can import custom feature sets so we can create a “pro” custom feature set where we take care of all this requests without changing default behavior or forcing people to agree on a standard. Ivan

Andrea commented

2019-09-20 13:10:07 +02:00

Thanks Ivan,

and thanks for your great work on this tool. I agree that for some reason some animator would prefere to have the pivot on the tip of the foot. As for my experience I never saw a setup like this one, so I thought it was strange, is just this :)
Anyway I still think that if you are standing and want to do a small weight shift and opening the feet or one foot it is usually done starting from the place where the weight is (the heel under the ankle).
The rotation of the foot is used also in the walk cycles,, and you shouldn't use the rool because you would have to counter animate the toes - so if you want to drag your foot during the up position of the foot is much easier to do that from the ankle because if you do from toes you will need to add rotation and also translation, complicating the animation curves (I hope I explained myself well).
Also please think that most of animators (as far as I know :) ) usally are not very good in technicall matters (there are exception to this :)) so normally they try to considerr the rig as a real puppet (like stop motion puppet), so it is more natural to have the rotation from the ankle (you don't even have the roll in a real puppet).

So this is my little explanation for my preference of pivot, but I have also to admit that in complex rig you have both the option, for example if you need to push and jump with your character keeping a foot on tjhe ground and for some reason the effort of the movement want you to rotate the foot pivoting on the toes(rotating in another axes then the one of the rool) , would be nice to have this option on top of the other, but in my experience this kind of action in term of probability is less easy to have.

I hope I explained myself well.

thanks guys

Thanks Ivan, and thanks for your great work on this tool. I agree that for some reason some animator would prefere to have the pivot on the tip of the foot. As for my experience I never saw a setup like this one, so I thought it was strange, is just this :) Anyway I still think that if you are standing and want to do a small weight shift and opening the feet or one foot it is usually done starting from the place where the weight is (the heel under the ankle). The rotation of the foot is used also in the walk cycles,, and you shouldn't use the rool because you would have to counter animate the toes - so if you want to drag your foot during the up position of the foot is much easier to do that from the ankle because if you do from toes you will need to add rotation and also translation, complicating the animation curves (I hope I explained myself well). Also please think that most of animators (as far as I know :) ) usally are not very good in technicall matters (there are exception to this :)) so normally they try to considerr the rig as a real puppet (like stop motion puppet), so it is more natural to have the rotation from the ankle (you don't even have the roll in a real puppet). So this is my little explanation for my preference of pivot, but I have also to admit that in complex rig you have both the option, for example if you need to push and jump with your character keeping a foot on tjhe ground and for some reason the effort of the movement want you to rotate the foot pivoting on the toes(rotating in another axes then the one of the rool) , would be nice to have this option on top of the other, but in my experience this kind of action in term of probability is less easy to have. I hope I explained myself well. thanks guys

Alexander Gavrilov commented

2019-09-20 13:32:56 +02:00

About pivoting on the toes, I once did an experiment with adding a 'toe roll' option, which would basically switch between the foot roll control bending at the toe joint like now (keeping the toes on the ground while the foot bends up), and on the tip of the toes (the whole foot rigidly rotates, keeping the tip of the toes on the ground.

Ivan Cappiello commented

2019-09-20 14:26:07 +02:00

so if you want to drag your foot during the up position of the foot is much easier to do that from the ankle because if you do from toes you will need to add rotation and also translation, complicating the animation curves

I totally agree on that.

I was wondering if having it on aligned on the ankle on Y and X axia but shifted on the ground on Z like anzovin does in setup machine would be of any use for animators.

Still, to be clear, no problem in fixing it (foot ik pivot in ankle) in a custom feature set.
I’d just like to keep the discussion goin on this ground for understanding if there could be some more useful think we can do and no one ever thought about before.

Once in old blender HQ there was a quote in a frame on a wall “if everyone else is making it, it must be stupid” (ton).
Think it was from the right click select era.
But nowadays we are back to left click, and there are good reasons for it (touch input devices). Time may change our opinions about things.

And, ironically, last time i saw it the frame was moved on the man’s toilet wall at sometime.

Let’s keep discussing for a better design.

Will look into spine fix first and then foot pivot as soon as the face modules are complete. Can’t tell exactly when but i hope will not take too long.

Ivan

> so if you want to drag your foot during the up position of the foot is much easier to do that from the ankle because if you do from toes you will need to add rotation and also translation, complicating the animation curves I totally agree on that. I was wondering if having it on aligned on the ankle on Y and X axia but shifted on the ground on Z like anzovin does in setup machine would be of any use for animators. Still, to be clear, no problem in fixing it (foot ik pivot in ankle) in a custom feature set. I’d just like to keep the discussion goin on this ground for understanding if there could be some more useful think we can do and no one ever thought about before. Once in old blender HQ there was a quote in a frame on a wall “if everyone else is making it, it must be stupid” (ton). Think it was from the right click select era. But nowadays we are back to left click, and there are good reasons for it (touch input devices). Time may change our opinions about things. And, ironically, last time i saw it the frame was moved on the man’s toilet wall at sometime. Let’s keep discussing for a better design. Will look into spine fix first and then foot pivot as soon as the face modules are complete. Can’t tell exactly when but i hope will not take too long. Ivan

Andrea commented

2019-09-20 18:54:43 +02:00

thanks guys,

I keep testing stuff, when I can :)

cheers,

Andrea

thanks guys, I keep testing stuff, when I can :) cheers, Andrea

Rombout Versluijs commented

2019-09-20 19:18:16 +02:00

In #63485#780587, @icappiello wrote:
I think this is useful but a more robust and general solution has to be found to make rigify handle custom widget/metarigs/colorschemes. A giant step forward was done implementing the import of custom rigs from rigify preferences.
I think is nice to hace this addon out there while we figure out what can be done to make this options available in rigify itself.
Cheers,
Ivan

More robust, in what method? The current method is sort of hidden and to tedious. The only thing my addon does is save your adjust Meta Rig using the operator which is already in Rigify, but sort if hidden, than its saves it to a preset folder. Because i prefer more customized saving method, it looks perhaps to complicated. You can use Blender standard method for saving presets, but than means one big messy folder. Mine looks a bit messy cause of the naming i guess. Its quite simple what it actually does, nothing fancy

Also currently you cant not save Rigify Rig settings, mine does that. So it will save custom coloring naming etc etc, Not sure if you guys are making this better, why such features are not added?

But on the other hand, i can keep it apart. It will be useful for people who dont want that manual hustle it currently has. I bet99% of its users dont even know that you can make custom Meta Rigs.

PS you mean you can now import rigs which arent setup like a Metarig and they will be transformed so you can still make use of Rigify?

PS
What my addon does is this button "Encode metarig to Python" but automates all the other parts. It adds it to your custom folder and can be loaded on either Blender restart or F8.

Did you actually test the difference between current method and my addon. Mine is so much faster and will benefit users. Current method is tons of clicking, just like many new and added options etc in bl 2.80 currently. Seems to be a new thing, lets make things easier by let the user click more

> In #63485#780587, @icappiello wrote: > I think this is useful but a more robust and general solution has to be found to make rigify handle custom widget/metarigs/colorschemes. A giant step forward was done implementing the import of custom rigs from rigify preferences. > I think is nice to hace this addon out there while we figure out what can be done to make this options available in rigify itself. > Cheers, > Ivan More robust, in what method? The current method is sort of hidden and to tedious. The only thing my addon does is save your adjust Meta Rig using the operator which is already in Rigify, but sort if hidden, than its saves it to a preset folder. Because i prefer more customized saving method, it looks perhaps to complicated. You can use Blender standard method for saving presets, but than means one big messy folder. Mine looks a bit messy cause of the naming i guess. Its quite simple what it actually does, nothing fancy Also currently you cant not save Rigify Rig settings, mine does that. So it will save custom coloring naming etc etc, Not sure if you guys are making this better, why such features are not added? But on the other hand, i can keep it apart. It will be useful for people who dont want that manual hustle it currently has. I bet99% of its users dont even know that you can make custom Meta Rigs. PS you mean you can now import rigs which arent setup like a Metarig and they will be transformed so you can still make use of Rigify? PS What my addon does is this button "Encode metarig to Python" but automates all the other parts. It adds it to your custom folder and can be loaded on either Blender restart or F8. ![Screen Shot 2019-09-20 at 13.23.45.png](https://archive.blender.org/developer/F7761124/Screen_Shot_2019-09-20_at_13.23.45.png) Did you actually test the difference between current method and my addon. Mine is so much faster and will benefit users. Current method is tons of clicking, just like many new and added options etc in bl 2.80 currently. Seems to be a new thing, lets make things easier by let the user click more

Ivan Cappiello commented

2019-09-20 22:39:19 +02:00

@RomboutVersluijs

Did you actually test the difference between current method and my addon. Mine is so much faster and will benefit users. Current method is tons of clicking, just like many new and added options etc in bl 2.80 currently. Seems to be a new thing, lets make things easier by let the user click more

I think i already wrote that is nice to have an addon for that.
In my opinion there is an easier (probably the easiest and safer) way to store metarigs. Save a blend file. Append the metarig in new one. Everything will be set. No need for addon or everything else. This is the “current method”
The operators you are referring in the pictures are just tools laying there for pro riggers and were never documented or fully implemented.

Storing rigify preferences is a delicate matter. Where on the disk should this preferences be stored is just a little part in a more general design.

Just few question from the bunch this feature would rise:

• will those metarig file be reachable by users?
• if a metarig contains errors or require upgrades to work with new rigify versions should stay there and add a crashing metarig to the scene? If so how the user can easily understand if it’s rigify fault or just the custom metarig?

Designing and mantaining a feature in an open source project is a complex thing.

With the custom feature set import we designed a way to easily add or remove the whole imported feature set, and we do this using blender’s designed folder relative to the user’s OS. We also (sort of) check the feature set structure before import to significantly reduce import errors. Then there is a clear way in the ui to classify and order the different features.
Just to make an example of what i call a more robust and general way to do things.

Btw you have a working addon to do this job and, as i already wrote, is nice to have it. Why are you complaining?

Make a video and post it so people can reach it!

Still i think appending a metarig from a saved file will do this easier and faster.

Cheers,
Ivan

@RomboutVersluijs >Did you actually test the difference between current method and my addon. Mine is so much faster and will benefit users. Current method is tons of clicking, just like many new and added options etc in bl 2.80 currently. Seems to be a new thing, lets make things easier by let the user click more I think i already wrote that is nice to have an addon for that. In my opinion there is an easier (probably the easiest and safer) way to store metarigs. Save a blend file. Append the metarig in new one. Everything will be set. No need for addon or everything else. This is the “current method” The operators you are referring in the pictures are just tools laying there for pro riggers and were never documented or fully implemented. Storing rigify preferences is a delicate matter. Where on the disk should this preferences be stored is just a little part in a more general design. Just few question from the bunch this feature would rise: • will those metarig file be reachable by users? • if a metarig contains errors or require upgrades to work with new rigify versions should stay there and add a crashing metarig to the scene? If so how the user can easily understand if it’s rigify fault or just the custom metarig? Designing and mantaining a feature in an open source project is a complex thing. With the custom feature set import we designed a way to easily add or remove the whole imported feature set, and we do this using blender’s designed folder relative to the user’s OS. We also (sort of) check the feature set structure before import to significantly reduce import errors. Then there is a clear way in the ui to classify and order the different features. Just to make an example of what i call a more robust and general way to do things. Btw you have a working addon to do this job and, as i already wrote, is nice to have it. Why are you complaining? Make a video and post it so people can reach it! Still i think appending a metarig from a saved file will do this easier and faster. Cheers, Ivan

Demeter Dzadik commented

2019-09-20 23:38:42 +02:00

Removed subscriber: @Mets

Rombout Versluijs commented

2019-09-21 03:45:59 +02:00

It does sound like I'm complaining didn't I.

Does meta rigs and rigify only works when it's build like a meta rig or doesnt it do anything otherwise?
My presets are saved according to the old rigify, the pitchypoy version that is I believe. All settings are saved aside in the regular preset folder unless a user wants a different location..
Your right about that metarig to python operator. I bumped into it and could believe this was more extended and user-friendly, that's why my add-on exists actually.

Perhaps other do find it useful to add to rigify. I'm not sure who decides here actually

It does sound like I'm complaining didn't I. Does meta rigs and rigify only works when it's build like a meta rig or doesnt it do anything otherwise? My presets are saved according to the old rigify, the pitchypoy version that is I believe. All settings are saved aside in the regular preset folder unless a user wants a different location.. Your right about that metarig to python operator. I bumped into it and could believe this was more extended and user-friendly, that's why my add-on exists actually. Perhaps other do find it useful to add to rigify. I'm not sure who decides here actually

johan tri handoyo commented

2019-12-06 11:31:38 +01:00

Added subscriber: @JohanTriHandoyo

Roman commented

2019-12-31 16:55:44 +01:00

Added subscriber: @rwman

Fin O'Riordan commented

2020-01-03 13:36:31 +01:00

Added subscriber: @FinbarrORiordan

Philip Guin commented

2020-01-29 06:09:25 +01:00

Added subscriber: @Frizzil

Philip Guin commented

2020-01-29 06:09:25 +01:00

Are we still taking requests? If so...

Feature request 1: Support for limbs of length > 4. The documentation says it's supported, but "Generate Rig" fails if attempted (in 2.81). After generating a normal rig, however, you can inspect the generated code, such as the IK>FK operator, and see hard-coded array indices into FK bone lists that would be incompatible with limbs of greater length. Smells like a doc issue to me, not a code issue, but would still be great to have.

Feature request 2: Spline IK generation. Useful for tails and hose arms, necessary instead of BBones since BBones currently can't be exported to game engines (making this a regular stumbling block for game devs.) Not sure what the "correct" solution is, but in my current rig, I have spline IK and regular IK on the same bone on the same chain, for hose-like arms, and drivers and sliders for both. The IK > FK might be a challenge though (perhaps it could be omitted.)

Thanks for your hard work!

Are we still taking requests? If so... Feature request 1: Support for limbs of length > 4. The documentation says it's supported, but "Generate Rig" fails if attempted (in 2.81). After generating a normal rig, however, you can inspect the generated code, such as the IK>FK operator, and see hard-coded array indices into FK bone lists that would be incompatible with limbs of greater length. Smells like a doc issue to me, not a code issue, but would still be great to have. Feature request 2: Spline IK generation. Useful for tails and hose arms, necessary instead of BBones since BBones currently can't be exported to game engines (making this a regular stumbling block for game devs.) Not sure what the "correct" solution is, but in my current rig, I have spline IK and regular IK on the same bone on the same chain, for hose-like arms, and drivers and sliders for both. The IK > FK might be a challenge though (perhaps it could be omitted.) Thanks for your hard work!

Ivan Cappiello commented

2020-01-29 09:33:24 +01:00

@Frizzil

Are we still taking requests? If so...

we are always listening to user requests

Feature request 1: Support for limbs of length > 4. The documentation says it's supported, but "Generate Rig" fails if attempted (in 2.81). After generating a normal rig, however, you can inspect the generated code, such as the IK>FK operator, and see hard-coded array indices into FK bone lists that would be incompatible with limbs of greater length. Smells like a doc issue to me, not a code issue, but would still be great to have.

this is not supported at all. Limbs.super_arm supports only a chain of exactly 3 bones (upper_arm, foreArm, hand). What is supported instead is the split of this bone in a more detailed chain. This can be done per limb in the upper_arm bone Rigify Type panel. Here you can set the number of additional control will be generated for upper_arm and foreArm and it's probably what you are looking for.

The documentation says it's supported,

There's an error in documentation as it states that:

Arm
requirement: a chain of `at least` 3 connected bones (upper_arm, forearm, hand)

and should probably state:

requirement: a chain of at **exactly** 3 connected bones (upper_arm, forearm, hand)

Feature request 2: Spline IK generation. Useful for tails and hose arms,

If i remember correctly @angavrilov is working in its own additional featureset on a spline ik tentacle rig. You can check his repository for the featureset, install it and give it a try

necessary instead of BBones since BBones currently can't be exported to game engines (making this a regular stumbling block for game devs.)

This assumption is not true.
The issue with exporting to game engines in not that much related to b-bones in rigify. Rigify in fact doesn't rely on b-bones per bone's additional attributes, uses b-bones to interpolate the bend, so technically exporting to a game engine would result in a slight change in deformations in most of the cases. Setting the b-bone split length to 1 in each metarig sample will just disable b-bones in the final rig and will make the deformation act as in the target engine.
The real problem with exporting to game engines is related to parent-child relationships on stretching bones that results in skewed bones in game engine.

We are investigating a solution to this. At this moment there's a nice addon by @angavrilov that can create a slave-deformonly-armature that (combined to the split length = 1 setting) can make the rig exportable to game engines.

I have spline IK and regular IK on the same bone on the same chain, for hose-like arms, and drivers and sliders for both. The IK > FK might be a challenge though (perhaps it could be omitted.)

Even if with 2.8 new depsgraph this setup could be supported i'd not suggest to implement spline ik for limbs as for now. This could heavily affect performance and could conflict with usability of FK controls most animators rely on (without considering space switching and fk/ik matching and all fancy features added in 2.82)

@Frizzil > Are we still taking requests? If so... we are always listening to user requests > Feature request 1: Support for limbs of length > 4. The documentation says it's supported, but "Generate Rig" fails if attempted (in 2.81). After generating a normal rig, however, you can inspect the generated code, such as the IK>FK operator, and see hard-coded array indices into FK bone lists that would be incompatible with limbs of greater length. Smells like a doc issue to me, not a code issue, but would still be great to have. this is not supported at all. Limbs.super_arm supports only a chain of exactly 3 bones (upper_arm, foreArm, hand). What is supported instead is the split of this bone in a more detailed chain. This can be done per limb in the upper_arm bone Rigify Type panel. Here you can set the number of additional control will be generated for upper_arm and foreArm and it's probably what you are looking for. >The documentation says it's supported, There's an error in documentation as it states that: ``` Arm requirement: a chain of `at least` 3 connected bones (upper_arm, forearm, hand) ``` and should probably state: ``` requirement: a chain of at **exactly** 3 connected bones (upper_arm, forearm, hand) ``` > Feature request 2: Spline IK generation. Useful for tails and hose arms, If i remember correctly @angavrilov is working in its own additional featureset on a spline ik tentacle rig. You can check his repository for the featureset, install it and give it a try > necessary instead of BBones since BBones currently can't be exported to game engines (making this a regular stumbling block for game devs.) This assumption is not true. The issue with exporting to game engines in not that much related to b-bones in rigify. Rigify in fact doesn't rely on b-bones per bone's additional attributes, uses b-bones to interpolate the bend, so technically exporting to a game engine would result in a slight change in deformations in most of the cases. Setting the b-bone split length to 1 in each metarig sample will just disable b-bones in the final rig and will make the deformation act as in the target engine. The real problem with exporting to game engines is related to parent-child relationships on stretching bones that results in skewed bones in game engine. We are investigating a solution to this. At this moment there's a [nice addon ](https://github.com/angavrilov/blender-scripts/blob/master/slave_armature.py) by @angavrilov that can create a slave-deformonly-armature that (combined to the split length = 1 setting) can make the rig exportable to game engines. > I have spline IK and regular IK on the same bone on the same chain, for hose-like arms, and drivers and sliders for both. The IK > FK might be a challenge though (perhaps it could be omitted.) Even if with 2.8 new depsgraph this setup could be supported i'd not suggest to implement spline ik for limbs as for now. This could heavily affect performance and could conflict with usability of FK controls most animators rely on (without considering space switching and fk/ik matching and all fancy features added in 2.82)

Ivan Cappiello commented

2020-01-29 09:34:25 +01:00

Changed status from 'Needs Triage' to: 'Resolved'

Ivan Cappiello closed this issue

2020-01-29 09:34:25 +01:00

Ivan Cappiello self-assigned this 2020-01-29 09:34:25 +01:00

Ivan Cappiello commented

2020-01-29 09:34:25 +01:00

since almost every request has been addressed in 2.82 i am closing it as resolved

johan tri handoyo commented

2020-03-16 09:02:03 +01:00

Hi everyone. I'm so happy to see a great improvement in rigify. Especially the super finger become default now, a time saver indeed. I don't need to change one finger at a time anymore LOL. Thank you a bunch!

So, i just recently follow Iker J. De Los Mozos on twitter (rigger on Frozen 2 and many of Disney's features) and he posted some interesting rig he made, and one particular video shows the facial rig which has 12 controllers on the lips. Now, i'm trying to figure out how Disney characters has that cute appealing "pinched" lips effect, and that's probably it. I think currently we only have 8 controlers, right? and it's really nice if rigify has 4 additional controllers to the edge lips like that. What do you guys think?

Hi everyone. I'm so happy to see a great improvement in rigify. Especially the super finger become default now, a time saver indeed. I don't need to change one finger at a time anymore LOL. Thank you a bunch! So, i just recently follow Iker J. De Los Mozos on twitter (rigger on Frozen 2 and many of Disney's features) and he posted some interesting rig he made, and one particular video shows the facial rig which has 12 controllers on the lips. Now, i'm trying to figure out how Disney characters has that cute appealing "pinched" lips effect, and that's probably it. I think currently we only have 8 controlers, right? and it's really nice if rigify has 4 additional controllers to the edge lips like that. What do you guys think? ![image.png](https://archive.blender.org/developer/F8409487/image.png)

Todor Nikolov commented

2021-01-12 04:40:42 +01:00

Added subscriber: @TodorNikolov

Sign in to join this conversation.