[Bf-committers] colored wire patch

[Jean-Luc Peurière]

Le 8 sept. 04, à 12:34, Ton Roosendaal a écrit :

> Blender currently uses wire colors in a way that conflicts with 
> user-defined coloring. I am also not convinced such a manual-labour 
> feature would really work for Blender.
>
> I rather see some design/research efforts on a general requirements 
> level. What do you want (wireframe) colors to communicate? How does a 
> selection/active status cope with it? Or Objects that are not 
> selectable (in a set, or duplicated, or generated)? Objects from 
> libraries? Objects that denote keypositions?
>
> My preference would still be a functionality-visualizing and automatic 
> coloring system, which can be adjusted or set according to what you 
> are doing or need to see.

Other 3D packages (3DS, i'm sure, other i'm almost) and all CAD systems 
use colored objects in 2 ways :

1/ user definable colors on a per object basis
2/ user definable default color on a per layer basis.

Some packages uses color to defines other values (like width of strokes 
in Autocad) but it is of no concern for us.

you dont need to use it, but if you do, it allows to identify a mesh a 
single glance. It's very useful when you have very intricated objects 
or want to group object in a visual way (eg color window in red, while 
the walls are blue).  Automatic coloring dont really fit with this use, 
as the program cannot guess what is the logical group it goes with. And 
once fixed, the color should never change unless the user request it 
(or he will be confused)

Typically the number of colors available is a reduced palette (from my 
industrial use, 32 is a good value), and it is only really useful in 
object mode (choosing the mesh to work on), and wire (solid could be 
usefull too but would lead to confusion with shaded and textured). In 
all other modes,  colour should stay the one defined in theme.

  I'm used to find this in CAD, and wont be able to work without on 
industrial designs with thousands of objects. Note that, in the case of 
blender, you cannot use eg the material color, as 2 near object sharing 
same material (which happen often) wont be distinguishable at a glance, 
which is the sole purpose of the feature.

Now about the conflict with blender select/active or other special 
colors, it's quite easy to reduce, by not allowing those colors (and 
the ones nearby) to be choosen on palette.

My patch provides 1/ (without the palette restriction part) and 2/ is 
in the attribution of a layer manager.

In my point of view, doing it the crude way (manual labor + layer 
manager colors) is in this case the right way to do it. Automatic 
coloring would miss the target as it does not rely on user memory. And 
it cost nothing (well 8 byte per object) if you dont use it.

Now, I can live without it, but it's a feature request seen in wiki, on 
elysiun and feature request tracker, and as i said quite common in 
other apps.

-- 
Jean-luc