Rigify Update and Fixes #48892
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
15 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#48892
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello,
MAD Entertainment is a young but growing company fuelled by the talent flowing into it from a variety of creative and professional backgrounds. Since its founding in 2010, the company has been a creative hub for 2D and 3D animation, producing adverts and videoclips, special features and tv series, as well as short films and feature length movies for the cinema. Our last animated feature "The Art of Happiness" won the 2014 European Film Award.
We are now developing our next movie "Cinderella the cat" and we are using blender for all the 3D CGI. All of our characters (human and non-human) are rigged with our hombrew version of rigify. During our work we found big room for fixes, improvement and redesign. After meeting Francesco Siddi in Annecy this year during our panel, we spoke with him about bringing our work on the add-on to all the blender users.
Our purpose is summed up as follows:
• Fixing missing or broken code (already submitted as patch)
• Expanding the rigify pitchipoy version with new custom features (next patch coming)
• Redesign the rigify add-on to merge (where possible) the original one with the new pitchipoy (removing the differences between this two methods) and make possible to rig easily non-human and non-standard characters. We already have done a good part of this work and as for now it's already possible to generate quadrupeds and birds rigs from our new meta-rigs samples. We are open for a wider discussion about this topic.
Changed status to: 'Open'
Added subscribers: @icappiello, @fsiddi
Added subscriber: @LucioRossi
Added subscribers: @cessen, @Sergey
That is surely nice to see interest and contribution from studios, but not exactly sure what's this patch ticket is about. Doesn't see code you're mentioning here..
Also, rigify addon is done by Nathan, so worth dropping him into the discussion.
I have invited MAD Entertainment to submit the patch. The patch is here D2114. The idea (discussed with @ideasman42) was to submit a patch and then have a more broad design discussion in a dedicated task.
If you expect this process to be different, please let us know.
Then the task should be a Design and patch referenced from here.
All right! It looks like the first patch was accepted :)
From a previous conversation I recall there was another small patch ready for integration. At this point you could go ahead, commit it and then link the commit id here (so we have some history for this conversation). After that we can talk about more long-term plans.
Great!
We will proceed (tomorrow probably) with committing the improvements on the Paw limb(s), then we will discuss the fk/ik switch implementation on pitchipoy rigs which is just a notch more complex.
Hello! I'm about to commit the paw.py fixes, do you prefer that I push the current master on origin and branch from there, or I keep on committing on master?
As discussed on chat, any commit that does not break compatibility and introduces improvements/fixes can go in master.
After some struggle I've added a new branch called rigify_fixes on which we can work happily ever after...
You can find the following 3 commits there:
Paw Limb Code Review and Fix.
https://developer.blender.org/rBAd1dafb1ec7fe
The paw limb sub-rig was generating errors. We code reviewed it, fixed the bug in the generation phase and changed its behavior slightly. Paw has now 4 base bones and some more tweaks where we reckoned they were missing. We also made a different front and rear paws, but we will put them in a future commit.
Pitchipoy FK/IK switch implemented
https://developer.blender.org/rBAefd386991e12
On the Pitchipoy rigs there was no FK/IK switch at all. We tried extending Nathan's code, but had no pole vectors to solve the snapping problem so we exploited the fact that ik and fk ctrl bones rotate on one axis only in axis_angle mode. We used a minimization function to match ik to fk position or vice versa. The solution works fine for our needs but we think it could be maybe refined by someone who knows pose bones internals better.
Fixes: Set rot_mod to ZXY (ctrl&tweaks) & Spine tail_pos
https://developer.blender.org/rBA48ab09e86010
the rotation mode on main ik ctrls (arrows) was set to quaternion though X and Z axis were locked. This gave errors in the quaternion math representation so we decided to switch it to Euler ZXY. (maybe @icappiello wants to add something about it)
The code of super_torso_turbo.py looked incomplete. This rig lets you generate a "tail" (working options were just 0 or 1), but you could not specify the tail position. With this fix we give the possibility of finely placing the torso master control. All this modifications are totally backwards-compatible and are absolutely needed to generate birds and quadrupeds.
TESTING
In order to test the last two commits you can use a normal Human Pitchipoy rig.
About the paw limb refer to the cat rig made by @icappiello:
pitchipoy_cat_TEST.blend
Added subscriber: @JulienDuroure
I did not have time to check on the commits. Did you get any feedback from others?
If the code is proven to work, I think you should go ahead and merge into master.
Hello everybody,
No I didn't get any feedback up to now, but the code has been extensively tested during the movie production so... as you suggested, I pushed the 4 commits (I added a last one about front and rear paw limbs):
https://developer.blender.org/rBA319a2dbf9ef2
https://developer.blender.org/rBA867321259dd0
https://developer.blender.org/rBA3a10cb2852e3
https://developer.blender.org/rBA55b51984a619
Cheers!
Added subscriber: @ideasman42
Added subscriber: @JohanTriHandoyo
Hello Lucio, thank you very much for the updates. I really like Pitchipoy rigify for the smoothness of arm and hand deformation, and also the way we could move the limb freely.
A couple of things i found during try out :
1). I found that IK/FK snap is working perfectly.
2). The teeth doesn't seems to have a deformer bones though. Only the controller. So i change the controller to become a deformer too.
If you don't mind i also would like to share my experience as animator on Garfield animation series, Dr. Contraptus, which is i think that the rigs have a unique and clever approach on how to handle hand IK. The hand rig is actually very simple, the hand IK controller will have an option to be parented to the Chest bone or the Root bone. When the hand IK parented to the Root, it will act like a normal IK, but when parented to the Chest bone, it will behave like FK but with fewer control, and it was very efficient for the animator because we can pose the hand more quickly. So yeah, basically it was just only IK controller for the hand, but with an option to parent it. I also try to add this funtionality manually by adding Child of constraint, but i'm sure the riggers our there will be happy if this method can be done automatically.
Cheers,
Johan
Hello Johan,
i maybe didn't understand well what was done on the rigging side on the garfield series, but i suppose it wasn't done in blender. About your method:
I also try to add this functionality manually by adding child_of constraint, but i'm sure the riggers our there will be happy if this method can be done automatically.
this can't work that easy on rigify rigs (and, as far as i know, on any blender rig) due to the blender dependency graph. To be more clear, this method can only work if the animator is not moving the character's root from the origin. When the character's root is moved, the IK hand control will be moved two times, once for the direct parent>child relationship it has with the root, then it will be moved the second time for the child_of constraint. There are few tricks we are experimenting but each of those would break backward compatibility with previous rigify versions.
If you have some rigs where this doesn't happen, please let me know and i will look in to it with Lucio.
2). The teeth doesn't seems to have a deformer bones though. Only the controller. So i change the controller to become a deformer too.
As far as i know this was intentional behavior. Teeth and eyes are designed to be parented trough child_of constraints. The eyes should be parented to "master_eye.L/.R" and teeth to "teeth.T" and "teeth.B". This was by design and it's used to retain relationships when you re-generate the rig without deleting it. It can be changed but this will require a more deeper look into what will be happening in other rigify data-structures and dictionaries. I suggest for now to leave it as is.
Cheers,
Ivan
Hi Ivan,
Thank you for the teeth and eyes information. I just thought it will behave like the other deformer bones :D Will do as you said.
About the "Garfield" rig, i think the closest to the same feature of its hand IK is the one character that i made for another tv series project. I try to mimic the same funtionality with two Child Of constraints, and then add some driver in it. This was made long before i know rigify though.
Feel free to play around with it and please let me know what you think.
boy.blend <--- .blend file
Cheers
Johan,
i tested your rig.
As i wrote in the previous post, this cant't work "out of the box" with rigify rigs.
The reason is when rigify executes the generate function (and subsequently all the sub-rigs as the limbs), every bone that has no parent will be parented to the root bone (and moreover rigify creates this root bone for you in background).
In your rig the switch is working because the hand IK has no parent and all the relations are created through constraints.
As i wrote in the previous post, few tricks are possible to avoid this dependency mess, but we need some more time to look which part of rigify code will be affected and be sure it won't break backward compatibility.
I'll put it up on our to-do list, since the feature is useful for animators and was someway already planned to happen.
in the while, the easiest solution if you want to do it could be clear the parent of "hand_ik.L/R" (alt+P) in edit mode, then make your child_of constraints and drivers.
regarding my previous post:
This is not correct, the parenting should be done to "ORG-eye.L" and "ORG-eye.R".
For any other geometry that has to retain location and scale of the eye, but not inherit its rotation, "master_eye.L/.R" are good parents.
I am sorry for my previuos misleading information.
Keep in mind that since eyes and teeth geometries doesn't supposedly deform, but just have transformations in LocRotScale, not having an armature deformer on them is a good design idea since it will make the rig interaction a bit faster.
If you need those bone to deform, then your solution is fine. To make this easier you can enable/disable the deform option on multiple bones by selecting them in pose mode, using the shortcut "shift+W" and select "deform" from the list.
Ivan
Added subscriber: @AditiaA.Pratama
Thanks for your thought and tips Ivan, it's good to know about this information behind the Rigify. And thanks again for your work on this rigify updates.
The feature suggested by @JohanTriHandoyo is now committed.
https://developer.blender.org/rBAff11927e8e07a46c8199d9681af639be52b6b1af
It basically works this way:
two more properties are added in the rig_ui when any of the ik control is selected. We also kept the ui consistent with the rest of rigify.
1 - IK_follow (boolean) enables the limb following. When enabled (=1, True) the ik limb will follow the parent according to slider n°2. When disabled (=0, False) the ik limb will stay as is in world space. Disabling the ik_follow will let the user create his own constraint (like parenting the hand to the hips and so on…) without creating conflicts with the root movement. By default the ik_follow is enabled.
2 - root/parent (float, min=0 / root, max=1 / parent) let the user choose which parent to follow. When set to zero the limb will follow the root, when set to 1 the limb will follow its inherited metarig parent (in the pitchipoy human is the shoulder bone by default). By default is set to 0 and follows the root so that it acts just like before this commit and legacy with old rigs is retained. When IK_follow is disabled this slider has no effect.
All this properties are individual and can be set up differently on each limb.
Hi guys,
Just an addendum about the latest commit.
It needed a fix on the main generate function: the controls should not be parented to root anymore.
This was added here:
https://developer.blender.org/rBAfecd5c9f566e0075e91d6d5830ccc0a622932736
PS Since we added two new subrigs (super_arm and super_leg) if you want to try them, on the Pitchipoy metarig you have to assign the correct Rigify Type to the proper pose_bones (upper_arm and thigh)
cheers
OMG! This is super cool Ivan! Is it going to be in 2.78 RC2? Can't wait to play with it ;)
This is a very nice addition for Pitchipoy's rigify. The super arm and super leg type are work as expected. Thank you very much.
Just uploaded the video tutorial for this lovely addition :) https://www.youtube.com/watch?v=eejLUWRdwfk
Thank you Johan!!! That's fantastic :D
Hey there!
It's so great to see progress :) Are there any plans to write some docs about the updates here? https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.78/Add-ons
This is the commit of an urgent fix that will make the snapping functions work with new additions to the super_limbs:
https://developer.blender.org/rBA816df6cfe1054acffad2ec23edd63ae504ab325f
@fsiddi i will proceed with documentation in the next days, hopefully we can have som before the conference!
BTW we are still waiting for some comments on the wider design purpose:
Are there any objections bit this?
Hi there,
Quick comment to say hello to Ivan & Lucio that I met last week-end at Blender Conf.
I will contact you in next days/weeks to talk about we can manage any integration of my work on rigify.
Maybe the simplest way is that I propose some patches directly.
Hello Julien!
It was nice to meet you in Amsterdam. Can't wait to start working together on rigify!
I agree with you, the best and easiest way is that you propose patches so we can test them and then push on the addons repo.
Added subscriber: @LucianoMunoz
Hey guys, are you patching this stuff up ? is there a way that you can submit it for 2.79 ?
@LucianoMunoz,
All the major changes presented at the conference are already in master since 2.78.
We have minor updates non yet in master. These are currently used in production but could require a wider test to be sure all cases are correctly handled. If 2.79 is upcoming i would not suggest to merge it right now. The features are:
• auto bone grouping and color themes
• auto selection sets
• minor fix to super torso to rig animals neck and tail
More work could be done after a decision about the legacy code is taken. Hope @fsiddi can help us making clear on how we have to move.
As far as i know the old original rigify code is not updated from nathan vegdal anymore. All our efforts and updates are directed to the "pitchipoy" version also written by cessen and intended to replace the old one.
I am still proposing to remove the "pithcypoi" tag from the samples and metarigs and let this be the standard rigify from now on.
Another option could be to split the code and let the old rigify as it was before the pitchipoy additions and create a separate rigify 2.0 addon (using only the pitchypoi code but removing "pitchypoi" label) without the legacy code.
This will also help a lot with the documentation (still missing).
Let me know what you think about it.
Laters,
Ivan
So if i understand right all of these changes are under the pitchipoy rig instead of the regular rigify?
@LucianoMunoz:
Yes all our work relies on the pitchipoy code.
But keep in mind that at this moment the different modes are triggered just by wich attribute the user sets on the metarig bones. So the use our specific features you have to replace the generic 'pitchypoi_super_limb' with a specific one like 'pitchypoi_super_arm'. For leg and paws it's the same process.
Hope this simple example lets you understand why this code NEEDS to be cleaned up and simplified for a standard user.
oh gotcha, that should be fixed, replacing all the mess by a unified way should be done in the near future, shall we plan on it for 2.8? since it seems there isnt enough energy to do it for 2.79
Hi all,
I just reported 3 different bugs found on Rigify :
https://developer.blender.org/T50500
https://developer.blender.org/T50501
https://developer.blender.org/T50502
Plus an old one that I reported few months ago:
https://developer.blender.org/T48286
@JulienDuroure
The firts 3 reports should be all grouped into a single thread since are all related.
I would not define them as bugs because tey rather are pitchypoi's rigify meta-limbs limitations.
The leg types seems to be designed to work only if the meta-legs are correctly aligned with the foot and all the bone rolls are correctly set. The same is with the arms but the shift you get if you are misaligning the metabones is really subtle.
I think most of these could be fixed, but that should be done with a more seriuos refactor of the limbs generate script that willl probably break backward compatibility.
I think your posts should be moved in 'feature request' or 'design' rather than bug. Moreover i'll try to accelerate the documentation process so that is clear how it was supposed to work.
I'll then try to contact francesco to understand how to have those tasks assigned.
In the while the easiest way to have a correctly working twisted leg is:
• generate the rig with the meta-limb in the aligned position
• enter pose mode in the generated rig
• rotate the foot in the desired position
• ctrl+A (apply pose as rest pose)
The rig is now updated with the desired position and all the controls are working correctly.
Hi Ivan,
About 3 first reports : there are 2 on pitchipoy, 1 on Human. And the 2 one on Pitchipoy are related to limbs, but 1 is about global orientation of leg, the other is about orientation of foot regarding leg. That's why I created 3 different tickets, for me these bug/feature request are not linked (except that they are all on legs).
No problem to move them to "feature request/current limitation" if leg system is design to work only on aligned way. But for me, this is a reel limitation for "common users". I saw your workaround. OK for me (as a rigger), but this is a reel limitation for "out of the box" rigging system. Many users that are not rigger are using Rigify, and currently there is no documentation that say that system is only working for aligned leg /foot.
I assigned tickets to you ;-)
@JulienDuroure
i will have a look at the standard rigify bug. But that part if the code is untouched since nathan coded it.
About the pitchypoi legs i am not arguing on how it should work, just looking at what the code assume it will find in the scene to correctly generate the rig. For sure this should be documented and users should be warned about that, but that is simply how was meant to work at the time was created (and i also think to understand why btw...).
This is the correct place to have a wide discussion on how it should be re-coded and re-designed, but as i said before i would like to collect all major changes and wrap them up in a new version rather than continuing to patch this code that has lot of good things but also start to showing its limits.
Cheers,
Ivan
@JulienDuroure
I looked into the FK toe snap problem.
The snap will not work on the toe in any condition because the toe_ctrl bone is shared between the FK and IK chain. So it should copy its own transformations in other space. This could be done but then you will have it in the correct position only when the FK is active after the snap.
The only real solution is to have a "Toe_FK_ctrl" and a separate "Toe_IK_ctrl" like all the rest of the chain. This way the snap will be easily done updating the snapping function.
This could be done pretty easily, but
The impact of this fix involves multiple parts of the system and new generated rig will not be compatible with rigs animated prior to this fix.
@icappiello
Ok, let's say that all these stuff is my 2 cents for requirements of next version ;-)
Added subscriber: @BrendonMurphy
@icappiello
hi, as you are aware of the bugs/limitations/requests I'm closing all 4 tasks from @JulienDuroure you can still access them from this task.
I'm also interested, are you now the maintainer of rigify?
your welcome to drop in irc #blenderpython for a chat about it.
Thanks.
@JulienDuroure
We could have a fix that adds the feature you requested on the pitchypoi leg.
• The foot will stay oriented as the world. This is a correct and consistent behavior since we don't want local axis to diverge from character direction. We don't even want that re-generating a rig would destroy previous animations.
• the IK_pole, the Heel_Crl, and the relatives mch will be correctly oriented
Could this be ok for you?
in the attachment you can find a sample of the new leg.
Let me know,
I.
leg_fixed.blend
@icappiello : Seems to be a first step !
Regarding local axis that diverge from character direction: This is something that need to be discussed for the new version. By example, this is not how Human metaRig works: local leg axis is different from character axis if you rotate leg in metarig.
Rigging is not an easy science ;-) So many possibilities :)
Julien
Assigned to Current maintainer @icappiello
I will make mention of other reports from here:
https://developer.blender.org/T49317
https://developer.blender.org/T50511
I'll assign these to you also
Added subscriber: @adrian2608
Hi,
About whole PitchiPoy and the latest bug.
Take also a look at how hands controls are done. They are bad for animators to work with. I mean very bad.
The best solution for hand is as in regular rigify. With one big controller for whole finger flexion. And one bone for each finger section.
Also custom shapes are always too big, and anyway visually to "thin"? We need to think about better shapes. I know I can fix it by myself, but a little work on them will save a lot of time for many users.
What else? Pitchipoys elbow controls, are also bad. The ones from regular rigify are much better to have.
If possible We should have one metarig for humans, with the option to have or haven't controls for face, and stretch. I don't know if is possible to add some option before generating rig from metarig.
Kamil.
@adrian2608
You can use the method you prefer. Rigify can make mixed rigs.
now you have what you want.
you could also specify on Pitchypoi Human that you want old fingers and limbs method but it will take more time to set-up.
about widget sizes, it could depend on your character size. Didi you scale the metarig up? It is meant to represent 1 blender unit = 1 meter. So a standard character should be tall about 1.8 or 2 units.
It can be fixed but most likely expect this to happen in next version.
about elbow and fingers, pitchypoi rig can do things standard human rig can't.
Each animator prefers its own method, each solution have its downsides. Let the user choice is the best solution we can find i guess,
Again the problem i see here is documentation, Rigify has none, so using by eyeballing can be frustrating. I'd like to have more time to spend on documentation and expose benefits and limits of the addon.
In next version i'd like to let the user switch between elbow modes whilst animating.
Cheers,
I.
@adrian2608
About the finger, have you tried to replace basic fingers with the pitchypoi super finger?
That should do exactly what you asked for.
If you don't know how to do it:
Add a human metarig
in pose moe select a finger base bone (ex: f_index.01.L). Go into the bone tab and scroll down till you find the 'Rigify Type' menu.
select 'pitchipoy.super_finger' from the drop list
repeat for each finger
generate.
now you have stretchy fingers and master ctrl for bending.
Thank You Ivan for all the explanations, it will help Me alot. I don't know why I don't thinks about this solutions.
One more time thank You for help.
Best wishes,
Kamil.
I wonder about the arm twisting, i still get that with the regular rigify, is that going to be patched?
@LucianoMunoz
please provide the blend file with the metarig that's generating the error. And a detailed description.
Added subscriber: @TomokazuHirano
Hi,
Constraints on metarig are copied to ORG bone.
What does it mean?
Custom properties are copied to genarated bone.
Copied constraints reference them.
I think that is cool behavior! But on ORG bone.
I also want the constraints to copy to the generated bone.
@JulienDuroure with the next 2.79 release all your requests should be addressed. Have a look at the release notes and follow the upcoming wiki page to know how to use it.
Cheers,
Ivan
@TomokazuHirano, i am not sure to understand the request. Can you please rephrase the sentence explaining it more clearly?
Added subscriber: @karlisstigis
Hello,
We are a small studio and usually used this rig for one or 2 characters at once with no real need for linking, bet recently we had a project with more than 10 characters and it made sense to do things properly this time.
I must say, the rig worked great, but we had a few problems we did not know how to solve.
The main one was with the rig layers panel which after linking all those characters in the scene was not showing up for some of them and for others there was as many panels as there where characters.
I found that for those without panels the only solution was to open up and run the script it came with, but sometimes it was not working and you have to go through all those scripts and try which one correspods to what character, for some it was still not working. Can someone suggest what we should have been doing differently?
Another thing - when grabbing an object and releasing it or holding onto something, you have to use constraints on the hand for example, but when releasing the object and disabling the constraint, the hand jumps back to its original transforms.. is it possible to snap it to the location it is in at that frame? We kind of solved that by using a helper bone to whick we could attach those objects, but is that the right way?
I don't know if this thread is still active, but would appreciate an answer very much, thank you!
Karlis
yeah linking and multiple rigify rigs are a bit messy.
for the second problem, I found a little addon, that aids in the process of creating the constrain, and putting the keyframes so the object stays there called Dynamic Parent, It'd be nice if it were a normal tool that would come in blender by default (unless there is a better solution built in) but this has worked for me a couple of years. https://lollypopman.com/2016/03/29/add-on-dynamic-parent/
Cheers!
@karlisstigis
This is due to the rig_ui.py names. I already answered to that in this topic:
https://developer.blender.org/T51729
In the upcoming 2.79 release you will find the advanced generation options that will address all the above issues. I am writing the wiki pages so keep an eye on it to know how it works.
I am not sure to understand correctly the problem, but if i got it right you could just use the FK chain to store the position of the IK before the object release frame and then snap back the IK to the FK to get that position again at the released object frame.
So let's say at frame 10 you have the IK hand parented to the Object and and at frame 11 the IK hand free, i suggest the following:
Hope it helps.
Cheers,
Ivan
@karlisstigis
Another option for the child of problem is having a look at new limb features at: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Rigging/Rigify#Limbs
In particular, if you use the IK following option setting it to 0 (Zero), the hand will not follow any part of the rig anymore acting like any other object in the scene, so when the child of constraint is turned off that position should be retained. This could help in particular situations. Keep in mind that this is a boolean value so no interpolation can be done. Moreover this could not work in an already animated file, but i thought it might be useful while planning future animations tough.
Added subscriber: @0o00o0oo
Added subscriber: @StephenHamacek
Just a small bugfix needed for the bird rigify. There is a double deformation problem in the foot after generating—looks like the DEF-toe.R and .L are set to deform and this causes the visible problem with the middle toe. Unchecking this fixes the problem, but I don't think this bone is even needed, since the toe controller already moves the regular toe def bones.
@StephenHamacek
That's not correct. In your picture there's just a bad auto-weight caused by the DEF-Toe bone size.
the bone is needed. This is part of the super_limb sample. A metarig is just an assembly of parented rig samples. Removing the deformation for the toe will affect all the other limb types sharing that sample. Moreover, there are cases you adapt the bird metarig bones position to fit your model and you may want to use that bone to take care of the deformation at the base of the toes (or claws).
This problem can be avoided selecting and hiding the bone you don't want to deform before invoking the auto-weight algorithm.
To do so:
Now the algorithm will use only displayed bones.
to make the bones visible again, in armature pose mode, hit alt+H
Cheers,
Ivan
Changed status from 'Confirmed' to: 'Resolved'
closing it since the design proposal was approved and gone in master long ago