[Bf-funboard] Object color proposal

[Ton Roosendaal]

Hi,

> To be tactless and blunt, knock this crap off.  We've already agreed (I
> thought) that states like "non-selected active" shouldn't exist.
> There's non-selected, selected, active (a subset of selected) and
> (because I don't know the real name) currently manipulated.

Tsk tsk! If you think people post crap here just ignore it. :)

Currently there is an 'unselected active' state. This makes the  
interface less 'nervous', for example when you deselect-all (AKEY) the  
buttons or IpoWindow and other editing windows are not emptied. You can  
also SHIFT+click twice at an Object to switch selection state, also in  
that case the UI doesn't change.

We can drop that of course. I've tried it once in the code, and it  
really didn't feel good... what we *can* do however, is defining that  
all tools in a 3d window (parenting etc) don't operate when the active  
Object is not selected. The 'unselected active' state then only is for  
communicating context to the rest of the UI.

Next point:
We don't have a simple decision process here. When there's no consensis  
on topics it will mostly depend on someone being able to write a  
proposal that's widely endorsed. Look at Matt's work, with only  
discussing a pulldown system at this list we never would have found a  
solution. Good research, and a good proposal with nice images then is  
the way you can get it done.
When still proposals are not generally endorsed;
1- the admins here (Matt, me) and of bf-blender (phase, sirdude,  
larstiq) can decide.
2- Personally I reserve the right to reject proposals or enforce  
decisions, but won't likely do that without being backupped.

-Ton-

>
> Now... on to business...
>
>> Sounds good! What do you mean by SOC? Do you mean the object is  
>> brightened
>> using the appropriate light? (e.g. that it is brightened with yellow,
>> magenta or white light?)
>
> SOC = Shaded Object Color.  I mean (as was suggeted by someone else) to
> draw the wireframe over the shaded version of the selected object.
>
>> I don't really like the tri-colour idea... I mean I'm not sure how  
>> useful it
>> would be.
>> I think your centerpoint colours should be changed... I think they  
>> should
>> match - so the non-selected objects could have a dark grey centre  
>> (similar
>> to black), the selected objects could have a magenta (purple) centre,  
>> the
>> active objects could have a yellow centre (even if they are  
>> unselected...
>> note that it is possible for active objects to be unselected)  
>> Manipulated
>> objects could have a white centre. If people want to see what  
>> position it is
>> going to they can look in the header bar. The problem with tri-colour  
>> things
>> is this - what if you get to the end of the scale - e.g. to the end of
>> green - or to black - does it just go back to the start again? And  
>> our eyes
>> can't distinguish between many shades of colours, especially blues  
>> and dark
>> colours... but on the other hand, the numbers in the header bar would  
>> be
>> very useful.
>> Well actually you can't manipulate the centre point over a long  
>> length of
>> time - unless you are moving the entire object... the way you  
>> manipulate the
>> centre is just through instant things like "Centre Cursor" and "New  
>> Centre".
>
> The reason for NOT making the centerpoint color similar to the  
> wireframe
> color is to distinguish it from the wireframe.  Otherwise, it will be
> too hard to pick out.  The tri-color idea was something I'd just  
> thought
> up.  Thorsten noted that it might cause a bit of undo overhead to
> implement.  While it might, I think the axis style of indicating the
> centerpoint would be helpful in determining orientation.  I like the
> idea of implementing the tri-color for each axis throughout the rest of
> the interface (good suggestion, Thorsten).
>
>> The problem with tri-colour things
>> is this - what if you get to the end of the scale - e.g. to the end of
>> green - or to black - does it just go back to the start again? And  
>> our eyes
>> can't distinguish between many shades of colours, especially blues  
>> and dark
>> colours... but on the other hand, the numbers in the header bar would  
>> be
>> very useful.
>
> I think you're misundertanding my suggestion, I think the centerpoint
> should look something like this image (apologies for the
> quick-n-dirtiness):
>
> http://www.mrhostbot.com/f.php/517,117/blender_centerpoint.png
>
>> Well actually you can't manipulate the centre point over a long  
>> length of
>> time - unless you are moving the entire object... the way you  
>> manipulate the
>> centre is just through instant things like "Centre Cursor" and "New  
>> Centre".
>
> The tri-color suggestion here is for when the object is being
> manipulated in non-editmode.  See below for comments on moving the
> centerpoint in editmode.
>
>> There shouldn't be a "currently manipulated" colour since the centre  
>> can
>> just be moved using "centre cursor" rather than being gradually moved  
>> like a
>> vertex. (Or you can move the vertices manually, leaving the cursor  
>> where it
>> is) In edit mode you shouldn't be able to select the centerpoint at  
>> all (in
>> fact you can't select it ever... but with shift-s you can move the  
>> cursor to
>> the centerpoint, etc.) So there should only be one colour for the  
>> cursor in
>> editmode. It could be purple or something... and it could be an X so  
>> that it
>> isn't confused with the vertex dots. Or maybe it should be gray which
>> implies that it can't be selected and moved. (it is "grayed out")
>
> Just because it cannont currently be selected and moved is not a reason
> that it shouldn't be.  I think it should.  There's a big benefit to
> being able to actively translate and rotate the centerpoint of an
> individual object.  Granted, it *can* currently be done using the
> 3D-cursor, but I think being able to select and move it interactively
> would be more powerful and more naturally fit the current editing
> workflow.
>
> I could be wrong, though.  What does everyone else think?
>
> Later.
>
>   Groo
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org