[Bf-funboard] In parent-child relationships, relationship properties should belong to child

Bassam Kurdali bassam at urchn.org
Wed Jun 24 18:53:17 CEST 2015


In a parent child (or 'virtual' parent child, such as constraint or
modifier) the properties of the relationship should belong to the
child, not the parent * : that way:

1- different children can have different relationships to the same
parent
2- when parenting a new child, you don't get surprised by a sudden
change in behavior of previous children.

Blender often gets this right, for instance, modifier settings, but
sometimes not so right:

1- curve deform options (stretch, bounds clamp, etc) are on the curve,
not the child:
  
 - this means multiple children e.g. a road and a car that could be on
the same curve, need different parent curves, indeed, the options are
on the curve data so they can't even be linked-data; changes to one
curve need to be redone for the other.

2- bone relative parenting feels like a bug not a feature currently. If
you had previously parented some objects without the relative parent
option, and you reparent using it, get ready to see a bunch of
seemingly unrelated objects in your scene change without warning.
Worse, they could be on hidden layers, mysteriously breaking a rig
without the user knowing why.


There could be other cases like this. I propose try to collect them in
a wiki and see if they can be backwards-compatibly fixed in some way
(for instance, by a redundant property on the child that overrides the
parent, similar to armature modifier options)


* It could be that some of the benefits of doing it the 'wrong  way'
are:

1- convenience of changing one option for multiple objects, imo this is
obsolete now we have multiple object editing.
2- 'logical sense': putting bone related options on the bone seems more
sensible, but, it could be only revealed on the child when bone
parenting is enabled.



More information about the Bf-funboard mailing list