[Bf-committers] colored wire patch
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
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