[Bf-funboard] ] constraints
Douglas Bischoff
bf-funboard@blender.org
Tue, 8 Jul 2003 14:00:35 -0400
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,
etc.
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
other)
(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
constraint.
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!
-Bish
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!