Page MenuHome

Fix parenting objects to bones/vertices causes offset

Authored by Philipp Oeser (lichtwerk) on Tue, Feb 5, 3:50 PM.



This reverts part of rBbc5482337669.
Problem with the commit is that the evaluated object seems to not have
partype, par1, par2, par3 copied from the original. Using original
object instead now.

Fixes T60623 (and part of T59352)

Diff Detail

rB Blender
T60623 (branched from master)
Build Status
Buildable 2849
Build 2849: arc lint + arc unit

Event Timeline

Maybe @Sergey Sharybin (sergey) would know, too?
(about the fact that partype, par1, par2, par3 are not copied from the original)

Seems correct to me, when this function is called the dependency graph has not been updated yet. And so ob_eval does not have all these settings updated set.

This revision is now accepted and ready to land.Tue, Feb 5, 6:29 PM

Just noticed there is now an offset with parenting Bone Relative...
Need to check this first before commiting...

Problem seems to be setting the parent to the evaluated object, but the BONE_RELATIVE_PARENTING flag on the bone is set on the original object.
Thus in ob_parbone() which is called twice (once from ED_object_parent_set, once from depsgraph BKE_object_eval_parent) we have this inconsistency...

Working on a fix...

Second issue (when parenting to 'Bone Relative') is that the bones
BONE_RELATIVE_PARENTING flag is set on the original, but not the
evaluated bone (yet), setting this on both now.

@Brecht Van Lommel (brecht): I know this was accepted already, but spotted a second issue (see above), could you check again?
[sloution of setting flag on both evaluated and original bone feels clumsy, but couldnt find another way...]

also noticed we have offsets when parenting to curve, but will do a separate report for that

Campbell Barton (campbellbarton) added inline comments.

IIRC modifying the evaluated data should be avoided unless they're runtime structs to store cache, @Sergey Sharybin (sergey) is it acceptable in this case & is there some policy here?


Evaluated data is to be evaluated by the dependency graph.

Solution which will follow the design is to modify original bone, tag object for update.


Seems like we are doing BKE_object_workob_calc_parent() / BKE_object_where_is_calc(depsgraph, scene, workob) before depsgraph evaluation has done its thing... (so flags are not correct there [yet])
[Also see my/brechts comments above...]

Can do some more digging, but a bit out of ideas here I'm afraid...

Philipp Oeser (lichtwerk) marked an inline comment as not done.Tue, Feb 12, 11:52 AM

I have reassigned T60623 and T59352 to @Sergey Sharybin (sergey) now (since I am not sure how to solve this in the desired way [using depsgraph alone]...)