[Bf-committers] Custom Transform Alignment

[Martin Poirier]

<standard salutations\>

--- GSR <gsr.b3d at infernal-iceberg.com> wrote:

> theeth at yahoo.com (2007-12-28 at 1158.01 -0800):
> [...]
> > Aside from this, there was a couple of redraw
> issues
> > and stuff like that which I've fixed (locally).
> 
> The video driver seems to be pretty stuffed latelly,
> so I started to
> blame any drawing issue to it. :]

Don't, sometimes bad drivers point to real issues.
There used to be an occasional crash in snap that was
often blamed on drivers but turned out to be a real
bug.

So moral of the story is if you can reproduce it more
than once, please write a bug report.

> [...]
> > > Sorry, but these new align options are not very
> > > useful with the widget off
> > 
> > Why do you think so?
> 
> Cos you have to act blindly, key constraints (and
> mb2, to a lesser
> extent) become try and error.

Right, it's less directly visible, so you have to make
a mental model of the different orientations.

Mileage may vary wildly on how easy doing that is.

> But they also have all the buttons in the right.
> OTOH, looking at the
> screenshot and new patch, having all the radio
> button as a inverted L
> does not look too bad, and places the name near the
> activity button.

Alrighty then.

> > I've used "?" for "Select" because it's sort of
> what
> > the "?" button does in the material assignation
> panel.
> 
> Now that you mention it, that one could go with
> Assign (in the group
> of 5 buttons below) and a text like Activate or
> Pick, they seem to be
> 3 pairs of related actions.

Note to people who are looking for easy stuff to do:
READ THE ABOVE QUOTE.

> > That is: Z axis is defined as the normal (or
> edge),
> > other axis are perpendicular but not strictly
> defined.
> 
> I was talking about that lack of strictness. ;]

It's a bit stricker than I explained at first, but you
raise a good point.

For a potential manual, it would probably be better
just to say that the usable axis is Z and others are
there for completeness sake but not strickly defined.

> Well, I see the commit just took the other path,
> make all static. So
> now if things have to be aligned to a given object
> at different
> moments of animation, user has to recreate multiple
> align settings,
> and if the animation changes, he has to manually
> update them. Simpler
> code, stiffer workflow.

Simpler code wasn't really the issue. Other people
have commented that the differing behavior between
mesh elements and objects was harder to explain (and
document) too.

Copy on creation sounded like a good compromise
between lots of features and ease to understand.

Martin


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs