[Bf-funboard] ] constraints
Tue, 8 Jul 2003 20:30:56 +0200
Thanks for the very good description of what probably this discussion
could not reveil well until now.
The past two hours, via IRC, Matt and me have been bothering an artist
(thanx green!) to deconstruct how relationships work in Maya. They seem
to follow the same approach as you describe so nicely below. In fact,
they 'parent' a constraint within the hierarchy, to give it some
location... or order in evaluation... we didn't grasp that concept
Our 'replace parent with constraint' concept, was mainly born out of
transparency towards a user; to give him a single unified relationship
system. But we forgot which other useful meaning you can give to a
I have to think this over a bit more... also because it is related to
the concept of 'Linking' which is used in Blender a lot to (i.e.
scene->object->mesh->material). It could mean that we'll have to manage
3 methods for 'links' or 'relations':
- data linking (object->mesh etc)
- hierarchical linking (Object->Object, Object->Bone, Bone->Bone)
- constraint relationships
Hierarchical linking is a difficult topic still, because it involves
Objects as well as Armatures and Bones in Blender...
I'll let it sink in... :)
On Tuesday, Jul 8, 2003, at 20:00 Europe/Amsterdam, Douglas Bischoff
> Hello, all!
> Been watching this discussion with great interest, as there is a lot
> of potential. As someone who makes a living translating instructions
> from one group to another, I thought I might take a stab at a proposal
> that might satisfy the group. Please read this with an open mind and
> see if perhaps it does achieve what you want, even if it isn't exactly
> what you would do if you were the only user of the program. *grin*
> As I see it, there are two basic concepts being interchangeably
> discussed here:
> A) Defining a hierarchical relationship for the application of various
> other functions (i.e. "parenting")
> B) Causing an object to duplicate change made to another object in
> specific ways (i.e. "constraining")
> First, I do think that these two need to remain separate. Currently,
> though, Blender mixes the two together somewhat (to the new user
> especially) arbitrarily. Let me discuss case A first.
> A) Parenting Proposal - Hierarchical Relations
> Having an object be "higher" in the hierarchy (a "parent") or "lower"
> (a "child") provides an instantly understandable idea of who is
> affecting whom. This brings up "Rule Number One"
> 1) The effector hierarchy travels DOWN the tree ONLY. (i.e. a child
> cannot affect an object higher in the hierarchy (such as its parent)
> than itself. This must be in order to prevent circular references.)
> That said, once an object is said to be a "child" of another object, a
> specific set of functions can be clearly delineated that describe what
> buttons or functions apply to whom. For example:
> Dupliverts (Do you hit "Follow Path" button for the child or parent?
> Group these buttons by which they should effect!)
> Lattice Deformations (which is deformed? The child or the parent?)
> I think it would clear up the interface a great deal to have wireframe
> coloration that would indicate parent/child relationships and buttons
> that would appear/disappear/ghost only if a parent was selected or a
> child was selected, etc. Then you would KNOW which would have an
> effect, and on what.
> This allows for neat effects where an object is dupliverted and then
> passes through a lattice, etc. It would need more discussion to know
> the limitations that would be placed on multiple-parent relationships,
> Suggested Parent/Child effects might begin with:
> * Dupliverts
> * Dupliframes
> * Lattice Deformations
> * Armature Deformations
> B) Constraints Proposal
> Constraints can have as simple as current Parenting ability, or as
> complex as a full IPO window. If you constrain object X to object Y,
> the constraints window might look like this:
> Duplicate Follow F R D
> Movement X Y Z X Y Z _ _ _
> Rotation X Y Z X Y Z _ _ _
> Scaling X Y Z X Y Z _ _ _
> Tracking X Y Z _ _ _
> Deformation O O _ _ _
> Materials O O _ _ _
> Collision O _ _ _
> (Duplicate = copy values EXACTLY from one object to the other)
> (Follow = apply delta from one object to the other.)
> (F = Factor - a value to multiply delta of one object to the values of
> the other: 1 = exactly delta)
> (R = Randomize - Amount of variation from one object to permit in the
> (D = Delay - For animation purposes, follow delta with this many
> frames of lag)
> The "X Y Z" represent buttons: if it's pressed, it's an active
> O represents a boolean: on or off, with X, Y, and Z meaningless
> _ represents a text area that can have a value typed in.
> Certain combinations would be meaningless and therefore should either
> ghost as soon as they become so (hard to figure) or beep if the user
> tries to select them (i.e. you can't duplicate an object's rotation on
> all 3 axes and Track to it as well).
> For ease of use, using the existing ctrl-P and ctrl-T would create the
> same effect as they do now as a default in the Constraint and Parent
> setups here, but then (as someone else correctly pointed out) the
> details could be changed as the user desired.
> Anyway, this may or may not have helped. Hope it was clear enough!
> P.S. On a related note, and not to sound sycophantic, but one of the
> people related to blender we LEAST want to see aggravated by these
> discussions is Ton Roosendaal. I suspect he doesn't make any money off
> of the time & effort he puts into Blender's open-source life, and so
> avoiding frustrating HIM or antagonizing ANY of the dedicated coders
> is high on my list of "things to do to keep this amazing program
> viable." Just my thoughts!
> Bf-funboard mailing list
Ton Roosendaal Blender Foundation email@example.com