[Bf-funboard] ] constraints
Tue, 8 Jul 2003 23:57:14 +1000
Sorry, maybe I didn't explain well - let me clarify.
I wasn't suggesting to simply remove the parenting function, and leave
things as they are (with copy location/rotation constraints).
My suggestion was to remove the parenting function, and in its place create
*new*, additional constraints that add/inherit (I guess that's the same
thing) transformation from the object, which would function in exactly the
same way as parenting currently does (child object inheriting
transformations from the parent object, but still free to be transformed on
To keep the interface backwards compatible, using CTRL-P could automatically
create an 'inherit location', an 'inherit rotation' and an 'inherit scale'
constraint, which would then function in exactly the same way as the current
parenting system does (without the track-following, dupliverting, etc.
etc.). For extra flexibility, you could then turn off selected constraints
to do things like inheriting the location, but not rotation (which we now
have to do with messy vertex parents).
Is this what you were concerned about?
----- Original Message -----
From: "Jean Montambeault" <firstname.lastname@example.org>
Sent: Tuesday, July 08, 2003 10:16 PM
Subject: Re: [Bf-funboard] ] constraints
> Ton Roosendaal wrote:
> > Hi,
> > Sorry, but I miss the point as well Jean...
> > Please elaborate the statements below:
> >> split up it's kind of constraints
> >> (which are and utterly different animal than what we call
> >> constraints in Blender for now, I hope that we can agree on that at
> >> least)
> The way parenting 'constraints' its children let us free to transform
> the children at will.
> The way our present constraints operates, if you 'Copy location' the
> constrained object can't be moved independantly.
> From the user's point of view the difference is absolute although it
> could not be so from the programmer's point of view.
> Something else that probably has no meaning from the programmer's point
> of view but makes a lot of sense from the user's :
> when defining a mini-coordinate system, I fine tune my animation and,
> once satisfied, give to every element a parent, usually an empty.
> From the programmers standpoint this is just constraining as usual.
> From my user's point I have no use for the concept of constraint at all
> ; it wouldn't be fertile. What I'd rather see is a bunch of children
> *using* the parent to extract coordinates from it. Other than that the
> parent has no influence and could be in China for what I care.
> If you accept that conceptualisation you get an unexpected extention of
> the tool that can proove very rich.
> I understand that this is not what the algorithm says but it has no
> importance. The use extends the tool : always.
> I am sure that if we go Matt's way and invent all kinds of constraints,
> even when some may seem to be of limited usefullness at first, you never
> know what side effect might develop, you never know what the creativity
> of the user will extract out of them. The perspective really fills me
> with enthousiasm.
> > and:
> >> But entirely getting rid of a simple, efficient , universally
> >> understood and used tool won't ever make the smallest bit of sense
> >> to me.
> Then again this must be seen from the user's point of vue, who, sorry to
> say, doesn't care for the underlying algorithms.
> The user's may come from another software and chances are that he is
> familiar with parenting since it is of an almost universal use : why
> make his life difficult when leaving a minimal parenting system to greet
> him would make the transition so much easier : universality and
> efficiency since it facilitates the communication.
> ( Not to worry : with a powerful constraining system as discussed here
> nobody will want to live without it.)
> 'Make parent' is also a quite simple way to access to an often used set
> of constraints : simplicity and efficiency.
> Give the poor soul that much no matter how it is achieved : use your new
> constraint system at will but make it transparent on that occasion for
> the user.
> Hope this is clearer.
> Bf-funboard mailing list