[Bf-funboard] ] constraints

[Matt Ebb]

Hiya,

I've been thinking over this issue to myself a bit more and tend to agree
that there is a need to keep the idea of hierarchies (it's useful in quite a
few situations like IK), however I think your examples don't really match
what you've talked about here.

To separate theses out, as Ton mentioned too, the different concepts are:

* Standard objects (Object A takes properties from user input)
* Constraints (Object A takes properties (with perhaps some
modification/manipulation along the way) from Object B)
* Hierarchies (Object A takes properties from B, which takes them from C,
... all the way up a chain)

And add the datablock linking to all of this and it gets a bit confusing...

I don't think parenting (heirarchies) is necessary for the examples you
give, since constraints already have the idea of whom is affecting whom. The
constrained object is always the way that is under the influence of another.

It's always a one-way process i.e. If Object A has a copy location
constraint with Object B as the source object, then only moving Object B
will affect Object A. It doesn't work in the other direction (attempting to
move Object A will not move Object B).

Perhaps this one-directional process needs to be communicated better in the
interface (perhaps by optionally drawing a dotted arrow in the viewport
similar to the current dotted line for parents/children), but I don't see
anything too unclear about the concept. In your example of the lattice, the
mesh is what is getting it's properties derived (constrained) from the
properties of the lattice, so the mesh would have a 'Deform with Lattice'
constraint attached to it, and the Lattice object would be filled in the
potential OB: field.

For the dupliverts example it's not so clear, depending on how the
constraint would be worded, but this is the same (just as confusing) as the
current parent/child system. Depends on how you look at it, I guess - is the
mesh object being affected by having another object placed at all it's
verts, or is the source object being affected by being duplicated at all
these other places.

The main reason I'd like to see the constraints system used more is that
it's much less opaque and confusing from a UI perspective. By looking at the
constraints window, a user can easily see all of the different constraints
that are currently being applied, and a user can also see all of the
potential constraints too, by looking in the menu. Using the current
parenting method, there are no clues as that what happens when you make an
object the parent of another  - you just have to *know* that it enables path
following, dupliverts, etc. etc. (and only in certain situations, like if
the parent is a path, or a mesh, etc.)

I also like the extra flexibility that the constraints offer (choose which
ones you'd like to apply, unlike parenting which automatically makes your
object inherit transformations, follow paths, duplivert, etc. whether you
want it too or not). Of course there's also the brilliant Influence IPO.

The main problem that I personally see in reconciling all of this is how to
manage the idea of a one-way link (A -> B) and the idea of a heirarchy (tree
like structure).

As an initial brainstorm idea, perhaps a possible solution would be to
divide up the constraints window into two halves: one-way / hierarchy
(parenting). The interface would be similar to the current constraints
window with the modification that adding a block in the 'one-way' section
would work identically to the current constraints system, but adding a block
in the 'hierarchy' section would cause the
transformations/modifications/whatever to flow all the way down the chain.

Sorry for the long post... It looks to be a much trickier subject that it
initially seems. I think it's really worth coming up with a good system
that's relatively easy to understand conceptually, rather than adding on
hack after hack though.

Matt


----- Original Message ----- 
From: "Douglas Bischoff" <bischofftep@mac.com>
To: <bf-funboard@blender.org>
Sent: Wednesday, July 09, 2003 4:00 AM
Subject: Re: [Bf-funboard] ] constraints

> 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")