[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!