[Bf-committers] colored wire patch

Theodore Schundler tschundler at scu.edu
Thu Sep 9 11:57:25 CEST 2004

Regarding their use, the idea is to be able to differentiate meshes. I preffer working with wire frames rather than shading, mostly because it's nice to see through objects. But when there are a lot, you frequently just have a big mess of black on the screen. Doing it automatically using the object's color, isn't actually all that useful, since in my most recent project I have a robot that is blue, and so if everything is blue it's just as complicated to manage as if it were all black. Here is an example of my use of mesh coloring on the robot:

Also, as a workflow issue, anything done in that panel where the color option is I think should be applied to all selected objects. So the colors, or the layers they are in or "draw extra" options can be changed at once for a group of selected objects. Having to move groups objects from one of my scratch layers to one of my actual scene content layers is a little annoying having to select each object separately and change the layer options for it, so even if colors don't become a part of official blender, having those other operations work on all selected objects would be help speed things up. (Usually its only like 4 meshes that I want to change stuff on at once, but it is still annoying.)
Also per layer coloring is a useful automatic coloring. And if it could be intergated into colored layer buttons that would make layer coloring even more useful.

As for objects from libraries, maybe they could be presented in a lighter form of the color, or just not use the coloring. It's primary helpfulness I think is in the modelling stages.

One other imprivement may be to make a fixed pallette of 16-32 colors. That simplifies picking a color and makes that aspect faster (the point is to easily differentiate the colors, so there is no need for a full palette). Then special cases like imported objects and the like that should be colored differently are lighter or darker or more or less saturated.


>>> jlp at nerim.net 09/08/04 1:10 PM >>>

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.


Bf-committers mailing list
Bf-committers at projects.blender.org

This message scanned for viruses and SPAM by GWGuardian at SCU (MGW2).

More information about the Bf-committers mailing list