[tuhopuu-devel] Constraints UI
Matt Ebb
tuhopuu-devel@blender.org
Sun, 19 Oct 2003 03:45:10 +1000
> You're right about the influence sliders. I thought
> about it again, and he's what I have in mind now:
> http://clubinfo.bdeb.qc.ca/~theeth/Temp/Constraints.jpg
>
> This would better fit in the panel layout of 2.3 too
>
> What do you think?
Looks great! Much more compact for the panels, yes. Hrm, maybe it would be
nice to invent a new compact 'insert key' icon in case buttons to insert
keys get used more often throughout Blender (I hope they do! Pressing I Key
over the material buttons isn't that intuitive...)
> Martin
> PS: Regarding the quit message, I think what people
> where complaining about mainly is when you press the
> [X] to close the whole window, not only the quit
> hotkey. A good start though.
Ah, of course! Forgot about that. Just committed a fix to enable it now.
Opinions, anyone? Annoying? Useful?
Cheers
Matt
>
> --- Matt Ebb <matt@mke3.net> wrote:
> > 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
> >
> > _______________________________________________
> > 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