[Bf-funboard] ] constraints

Jonathan Bartlett bf-funboard@blender.org
Thu, 10 Jul 2003 09:30:32 -0700 (PDT)

> 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.

I don't think dupliverts matters to this at all.  I think that dupliverts
should be handled by

Selecting the mesh
Going to AnimButtons
Have an Ob field in there
Have the user type in what object they want to duplicate over their

Now, this leads to the good thing about parenting - it's easy to use with
a GUI - you don't have to know object names.  Perhaps the Ob field needs a
little graphical help, so you can select your object instead of typing in
it's name.

Also, this leads to the real need for hierarchies - basically hierarchies
are used to group multiple objects together as one.  That way, when you
do dupliverts and similar operations, you are doing it with the entire

So, I think that leads to several concepts:

Parenting/Hierarchies - Group distinct objects together "as if" they are
Constraints - show relationships between objects
Object Links - used for "other" type purposes, where the original object
is only being referenced, not directly used.


> 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")
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard