[Bf-funboard] Re: [Bf-committers] constraints
Mon, 7 Jul 2003 23:41:40 +1000
(cc-ing to funboard since it's relevant there too)
I agree with Ton on this one - I'd like to see parenting gotten rid of all
together and replaced by more generalised constraints.
I feel the current parenting system has lost it's 'meaning'. Rather than
just being used for transformations, where the idea of 'parent' makes sense
(child inheriting transformations from a parent), parent has become muddied
up with all sorts of things like dupliverts, path following and so on which
is using it more for a 'one-way link', rather than as something used to
inherit properties from another object. A side effect of being so
multi-purpose is that it makes it harder for the user to 'explore' the
interface since 'Make Parent' isn't very self-explanatory for what action
will take place (particularly when there are so many things it does, like
skinning with armatures, constraining to paths, dupliverting, etc.), however
constraints like 'Copy Location' are very clear in what they acheive.
Anyway, my main argument for replacing with constraints is that I think the
constraints system is much more in tune with the 'Blender way' - using more
generalised tools together in innovative ways, rather than one tool that
tries to do everything. Having a bunch of generalised constraints to choose
from is much more flexible, *especially* with the capabilities to animate
A hypothetical example could be what Jean mentioned in his message - using
parenting to make a mini co-ordinate system. This could be replaced by some
constraints - 'Inherit Location' 'Inherit Rotation' and 'Inherit Scale'.
This would be a lot more flexible since you could choose which ones to
apply, and would remove the need for dodgy workarounds like (eg.) having to
use vertex parenting in order to inherit the location, but not the rotation.
Additionally, by separating things out into constraints, you would get
things like a general 'constrain to path' constraint, which would then make
it very easy to (eg.) constrain an object to two different paths and
change/animate the influences of the constraints (cars changing lanes?
skateboards jumping over objects and landing back down on the pre-defined
You could even get tricky and instead of just 'copy' or 'inherit'
transformations, you also could include nifty things like 'Add Location',
'Subtract Location', 'Multiply Location', 'Mirror Location' or even more
complicated things like constraining an object within (or outside) another
object's bounding box, and so on.
The constraints system is *so much more* flexible than parenting, and just
by creating some basic building block tools, it would be very easy for users
(without delving into source code etc) to invent new functionality, all by
devising cool combinations of constraints within the interface.
Food for thought :)
----- Original Message -----
From: "Martin Poirier" <email@example.com>
Sent: Monday, July 07, 2003 12:13 PM
Subject: [Bf-committers] constraints
> > Hi Martin,
> Hey Ton
> > Thanks! Although I didn't have time yet to review
> > your patch, this
> > indeed was the purpose... replacing tracking &
> > parenting with
> > Constraints.
> Talking about replacing Parenting, I agree with what
> Jean said on the funtionality board. That is, Tracking
> is well suited for replacement by a constraint, since
> Tracking is really a constraint while Parenting is
> more a relationship that a constraint IMHO.