[tuhopuu-devel] Constraints UI

[Matt Ebb]

Great! just committed - let us know if there are any probs.

The other things you mention (also in that other email) sound really good
too.

I'd definitely agree about seeing all constraints at a time! It may be nice
though to keep one influence slider per (collapsed or not) constraint. The
thing about influence IPOs is that it makes it easy to blend from one
constraint to another (like in the 2.25 demo of the hand picking up the ball
using influences on copy location constraints). It'd be much easier to tweak
if you had access to the influence sliders of all the constraints that you
are blending between.

Matt

----- Original Message ----- 
From: "Martin Poirier" <theeth@yahoo.com>
To: <tuhopuu-devel@blender.org>
Sent: Friday, October 17, 2003 6:53 AM
Subject: Re: [tuhopuu-devel] Constraints UI


> I think all these would be perfect addition to the
> constraint system.
> For one thing, adding a paramter to the
> add_new_constraint function would make it more useable
> but auto-constraint function. This could be pushed
> further by creating a "add_constraint_to_object"
> function that would take a constraint and an object
> and add the constraint to the object (instead of
> having to add it to the listbase object manually each
> time).
>
> In fact, I just did that during my prog course *cough*
>
> commiting soon.
>
> Martin
> PS: Also regarding the constraint UI, Ton asked Hos
> and myself for opinions, so I'll forward my reply to
> you too. That would probably save some repetition.
>
> --- Matt Ebb <matt@mke3.net> wrote:
> > Hi there,
> >
> > I'm sending this out first rather than just going
> > ahead and doing it because
> > I wanted to check with contraint guru theeth that it
> > wouldn't break
> > anything, and see if there are any problems I may
> > have overlooked.
> >
> > I think the UI/workflow for adding constraints is
> > backwards and I want to
> > fix it. It's nothing complex, but last week after
> > going through the
> > frustration of rigging a character and adding 30
> > action constraints to just
> > finger bones I realised it could be improved.
> >
> > Rather than 'adding a constraint', getting a default
> > of Track To, then
> > changing it to what you want, you should be able to
> > choose the constraint at
> > the time of adding it. Reasoning: Users don't want
> > to 'add some abstract
> > notion called a constraint', they want their objects
> > to track others, or to
> > follow paths or whatever. Imagine if when you added
> > a 3D object you had to
> > do 'add object' then go change it to a mesh, camera,
> > lamp, whatever, in a
> > menu somewhere.. yuck. It's also nice to be able to
> > see all the choices
> > there before you add it. A bit more explorable.
> >
> > Also for efficiency reasons - to add action
> > constraints to my fingers, I had
> > to click on add - move mouse to the menu on the
> > constraint - click, drag to
> > change from Track To to Action. I should have just
> > clicked on add
> > constraint - drag across a menu - release mouse on
> > 'Action'. It's also much
> > more understandable when the constraints seem more
> > concrete: "this is my
> > copy location", rather than "this is a variable
> > thing that can change
> > between all sorts of tangentially related
> > functions".
> >
> > The idea of having these amorphous abstract
> > constraints that can be changed
> > from one type to another is silly anyway since
> > between themselves, the
> > constraints are functionally very different. How
> > many people add a
> > constraint to make their object copy another's
> > location, then later on
> > change their mind and realise "no, actually I want
> > this object to be an IK
> > solver for a chain!"...? Not many. Besides, when you
> > change a constraint
> > type, none of the settings persist anyway.
> >
> > So my proposal:
> > * Change the add_new_constraint function in
> > editconstraint.c to accept an
> > argument describing the constraint type, for example
> > int constraint_type or
> > whatever it needs to be.
> > * Change the line con->type =
> > CONSTRAINT_TYPE_TRACKTO;
> > to con->type = constraint_type;
> > * Change the 'Add' button into 'Add Constraint'
> > (clearer) and when clicked,
> > make it fold out a menu with the different
> > constraint types listed. This can
> > work in a similar way to the pulldown menus, for
> > speed  - click+hold on add
> > constraint, drag mouse right over the menu, release
> > on the entry you want.
> > The menu entries will just use
> > add_constraint(*relevant constraint type*) or
> > whatever is necessary.
> > * Remove the 'constraint type chooser' menu from the
> > constraint panels, to
> > simplify, streamline, make the UI more 'concrete'.
> > (If people really do want
> > to change their constraint type for some obscure
> > reason, it's only one more
> > click to delete it and add a new one).
> >
> > I mention this now, because I think it would be nice
> > to go along with the
> > new constraints when they get ported over to bf.
> >
> > So, any issues or gotchas I should worry about? Or
> > just get in there and do
> > it?
> >
> > Cheers
> >
> > Matt
> >
> > _______________________________________________
> > tuhopuu-devel mailing list
> > tuhopuu-devel@blender.org
> >
> http://www.blender.org/mailman/listinfo/tuhopuu-devel
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> _______________________________________________
> tuhopuu-devel mailing list
> tuhopuu-devel@blender.org
> http://www.blender.org/mailman/listinfo/tuhopuu-devel