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

[Sergey Sharybin]

Ok, have a more clear picture now.

Let's port those changes over and call it all settled :)

On Mon, Sep 26, 2016 at 12:37 PM, Lucio Rossi <lucio.rossi75 at gmail.com>
wrote:

> 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin