[Bf-committers] Custom Transform Alignment

[Jean Montambeault]

Martin Poirier a écrit :
>> [...]
>>     
>>>> 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.
>   
A mental model is a lot to ask, especially when there
(It would be nice it the grid followed... I know, not likely feasible... 
just some user humor)
Anyway, in practice, these orientation are created for specific tasks, 
like modeling 'in situ' and they refer to existing elements of the 
scene. Likely there are even some of those elements that were even used 
to create the orientation in the first place. So it is not that 
confusing unless one has to model/texture in the void of space... Maybe 
you could integrate 3D stellar cartography in it...
> 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.
>   
That won't help for use but there are good workarounds.
>   
>> 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.
>   
And I was one of them. Now GSR makes a good point although creating new 
orientations may not be that much more work, especially if the behavior 
or keeping the same name but with suffix is adopted. It would go pick up 
the reference Object, orient, hit Ctrl+Shift+C, with just the last step 
added.
It also has the advantage of documenting the process used to set up the 
animation with all those successive orientations remaining: they can be 
traced using their increasing suffix number. This may come in handy when 
one has to go back and make some adjustments.
> Copy on creation sounded like a good compromise
> between lots of features and ease to understand.
>   
Look, ease to understand and document is one important thing but, as 
long as there is a good work flow that comes out of it, then it can be 
explained. I still don't think that a different behavior attached to 
Objects is that much necessary though.
> Martin
>
>
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page. 
> http://www.yahoo.com/r/hs
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>