- User Since
- Jun 24 2016, 1:06 PM (48 w, 2 d)
Mon, May 15
About the rig-id part:
Seems you are writing the rig-id on the meta-rig and then the meta-rig passes it to the rig. Even if the idea seems cool at a first glance, again, the consequence of this change are breaking other rigify features.
It seems you never generate again the rig-id on the meta-rig once is created. This is bad. Rigify metarigs are created to be shareable through blender files. For example, you have rigged your character with rigify, the next one is similar to the first, so you append your meta-rig form the first to the second file, then edit it as needed and generate. Standing to your patch in this case the metarig will bring in the second file the same rig id and - even not finding the rig itself - will always generate rigs with same rig-id. Since there is no rule to know when to re-create the rig id, you will force the user to manually delete it.
The idea behind the patch is good though.
I'll try to think a workaround for this second part, but for now -as this patch is submitted - I consider this part rejected too.
from a first look i have some big concerns about rigify WGT patch proposal:
looking into the patch right now.
This is fixed in 2.79. Now the property is moved to a visible bone laying at the base of the limb.
- New rigs created starting from 2.79 code will work automatically.
- Old rigs should be upgraded re-assigning the rigify-types property in pose mode.
Feb 8 2017
This is the metarig i re-created from the ORG-bones in your file. That's how the arm bone should be oriented to make it correctly work. You can restart from there.
on the the sample file i see more problems than you reported. Most of the controls are turned in the rest pose and there is a dependency cycle on the right leg. I suspect the metarig is misaligned or some modifications were made after the rig-generation.
I can see from the ORG-bones (that are the exact metarig copy) that your arms have bone rolls not correctly aligned. the Z-axis should point downward, in your rig instead is flipped.
You can go in the front view (numpad 1) select the arm bone-chain on the metarig and hit CTRL+N > Recalculate Roll > View Axis. Then regenerate the rig.
Jan 28 2017
@Luciano Muñoz Sessarego (looch)
please provide the blend file with the metarig that's generating the error. And a detailed description.
About the finger, have you tried to replace basic fingers with the pitchypoi super finger?
That should do exactly what you asked for.
Jan 27 2017
Not sure it's a complete solution tough.
Then if hand_fk is not visible the problem remains. I guess exposing a separate bone at the limb's first bone to handle all the properties is a better idea. This bone can be on both FK and IK rig-layer meaning it's always visibile if at least one of them is.
Will look further into that.
You can use the method you prefer. Rigify can make mixed rigs.
- Add Human-Metarig
- in edit mode add a sample face
- parent the face bone to the head
I can confirm the bug. Looking if @Joshua Leung (aligorith) 's fix is breaking something else.
Following those steps i can't reproduce this error on 2.78a. All DEF and ORG bones are on the respective layers and correctly displayed.
Jan 24 2017
We could have a fix that adds the feature you requested on the pitchypoi leg.
Jan 23 2017
@Julien DUROURE (julien)
I looked into the FK toe snap problem.
@Julien DUROURE (julien)
i will have a look at the standard rigify bug. But that part if the code is untouched since nathan coded it.
@Julien DUROURE (julien)
The firts 3 reports should be all grouped into a single thread since are all related.
Jan 22 2017
@Luciano Muñoz Sessarego (looch):
Yes all our work relies on the pitchipoy code.
@Luciano Muñoz Sessarego (looch),
All the major changes presented at the conference are already in master since 2.78.
Sep 22 2016
This is the commit of an urgent fix that will make the snapping functions work with new additions to the super_limbs:
Sep 12 2016
The feature suggested by @johan tri handoyo (johantri) is now committed.
Aug 20 2016
i tested your rig.
As i wrote in the previous post, this cant't work "out of the box" with rigify rigs.
Aug 19 2016
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:
Jul 19 2016
adding the missing super_palm.py file.
@Campbell Barton (campbellbarton) @Nathan Vegdahl (cessen) the inherit scale modification is necessary to prevent undesired results after non uniform scaling on the hand control. If you want to check it just generate the rig leaving inherit scale values active, then rotate the hand and scale it non uniformly (ex: S Y Y) and you will see the fingers controls and deform bones exploding in all directions. Anyway our modification is applied to a new rig type with a different name. The old one is still there and will not be affected by the modification.