[Bf-committers] Revisions for the final 2.78: Rigify super_arm super_leg

Lucio Rossi lucio.rossi75 at gmail.com
Mon Sep 26 12:37:15 CEST 2016


Hi,
1. No, we don't apply the same child_of twice. It think it depends on the
interaction between the single constraint and the IK chain.

2. The fix "corrects" the ik-fk snapping functions in the case hand or foot
ctrl bones have the child_of constraints on top of it. Unfortunately we
very recently noticed that, independently of the modifications we made,
adding the two child_of constraints on top of the IK ctrl bones messes up
with the apply visual transform. This is not, I repaeat, dependent on the
fix or on the previous code, it's just the interaction with the constraints
(IK and Child_of) and the transform functions.

3. By not-default I mean that when the user chooses a Pitchipoy rig the
arms and legs are marked as super_limb (arm) and super_limb (leg) same as
before the commits. If, and only if, the user wants to try the new
functionality he/she has to give, esplicitly, the super_arm or super_leg
property to the those bones.

To sum up everything works as before the commits unless anyone wants to try
the new sub-rigs...

2016-09-26 12:16 GMT+02:00 Sergey Sharybin <sergey.vfx at gmail.com>:

> Hi,
>
> On Mon, Sep 26, 2016 at 11:46 AM, Lucio Rossi <lucio.rossi75 at gmail.com>
> wrote:
>
> > About the double matrix multiplication IMO it depends on the fact that
> two
> >
> extra child_of constraints have been added to the IK controller bones.
> > Though it works together with the fk/ik snaps we're experiencing some
> other
> > issue in the apply visual transform we're trying to address.
> >
>
> That would be weird if same child_of matrix is applied twice. If it's two
> different child_of, then multiplying matrix by itself is not a correct way
> to go to a proper space.
>
> You mention some other transform issues, so the fix is not even complete?
>
>
> > Finally, please consider that the two subrigs introduced are not (up to
> > now) default for arms and legs in the Pitchipoy rigs.
> >
>
> We've passed two release candidates and few hours from calling a final
> release. We have to be strict, meaning: the fix should either be fixing
> regression or be dead-simple for inclusion. Currently this doesn't seem to
> be the case here (especially assuming even with the fixes applied there are
> still other issues).
>
> Did i understand correctly, that the fixes are in the area which is now
> became default? In this case, how much unusable things are prior to the
> fix? How much it's unusable after the fixes (you mentioned some issues
> still)?
>
> 2016-09-26 10:46 GMT+02:00 Sergey Sharybin <sergey.vfx at gmail.com>:
> >
> > > Hi,
> > >
> > > First two commtis are quite some code which does not address regression
> > or
> > > trivial fix. So it is rather really risky to accept it now.
> > >
> > > The code itself is also weird:
> > >
> > > - You can clearly simplify the layer mask creation, and don't have it
> > > inlined as a list of False, False, False.... in multiple places
> > > - Multiple subsequent try/catch could be replaced with a single check
> > > whether `rigify_parameters` is in pbone. Using exceptions for that is
> > > totally wrong!
> > > - The goal is to have code pep8-compliant, and the new code is clearly
> > not
> > >
> > > Remaining two commits is clearly less code, but they are still
> > suspicious.
> > > Never heard of getting square of a transform matrix (mat*mat), and not
> > sure
> > > code was tested well enough after the change was done by all the users.
> > >
> > > On Sat, Sep 24, 2016 at 3:16 PM, Lucio Rossi <lucio.rossi75 at gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > > Adding to the last mail two commits that were missing...
> > > >
> > > > If it's possible include the following commits in the 2.78 release.
> > > > They add a new super_arm and super_leg rigs with switchable child_of
> > > > parenting:
> > > >
> > > > rBAff11927e8e07a46c8199d9681af639be52b6b1af
> > > >
> > > >
> > > > rBAfecd5c9f566e0075e91d6d5830ccc0a622932736
> > > >
> > > > And as said in the previous mail:
> > > >
> > > > rBA816df6cfe1054acffad2ec23edd63ae504ab325f
> > > >
> > > > rBA4ed120fafb157aeeb9fbdb072a0e75375d658e24
> > > >
> > > > Lucio
> > > > _______________________________________________
> > > > Bf-committers mailing list
> > > > Bf-committers at blender.org
> > > > https://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards, Sergey Sharybin
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list