Colored Wireframe discussion

(SterlingRoth) #82

Regardless of the colors being selected, if there are 4+ layers of partially transparent geometry blending together, it’s gonna lose contrast. Especially with flat surfaces. I work in a lot of rectangles, so I don’t have surface shading to rely on to distinguish objects, Which is why I have the wireframe overlay.

Here is that scene with no wireframes, and random color x-ray shading:

(polyboy) #83

No need for discussion here, build it in. Everyone Comes to the point were colored wires are usefull for a certain project.


Do you think it would be practically usable if the color of the colored wireframe could something like “Single”, “Object”, “Random”? Or would more options be necessary?

(SterlingRoth) #85

For me, I have no desire for random colors. I used 3d studio viz a long time ago, and I never liked the random colors, looks like clown barf. But to keep consistency with the solid shading color options, I could see including the option.

Object based and collection based would be all that I need.

Per material doesn’t seem worth it, as materials are applied to faces, not edges. Plus it certainly would increase complexity.

Having per object colors accesible via the python api opens up plenty of power for whatever weird coloring I want to do. Color coding by size, vertex count, distance from camera, etc. There’s a lot of potential for some great visualization addons.

(burnin) #86

Have you looked at the pigeon build - that would suffice…

(Mr_Flamey) #87

For some reason I thought we already had coloured wireframes, but after trying to access them I realised I was wrong and came here.

It would be really nice to have collection colour in addition to material and object, and be able to use this to colour both solid and wireframe, as not only would it help readability in the outliner, but using the same colour in the viewport as in the outliner would make it much easier to see which objects belong to which collection without having to select them. Not only does this make it easier to understand one’s own scene, but is very helpful when you can quickly see at a glance which objects are which in a scene created by another artist. Currently the only colour separation in wireframe mode is between selected and unselected objects, so wireframe is of limited practical use in large scenes with many objects, which was also an issue with previous versions of Blender :confused:

(William) #88

Collection colors will be possible in 2.81, which will include a feature called Collection Overrides. From here you could override material colors for a given collection.

(Blender Foundation CERTIFIED TRAINER) #89

What about object wireframe colors? Could it be possible?

(Lumpengnom) #90

At least we could write a script that automatically places every object into its own collection and automatically sets this collection color to something random.
It´s a bit silly but better than not having per object colored wires at all.

(Herbert123) #91

Ah, this thread reminds me of making this meme video out of frustration in 2014. Just now re-watched it, and it made me giggle. I must have been quite ticked off. :grin::wink:

At that time, a client asked me to work with a heavy CAD model, and a custom coloured object wireframe mode would have been extremely useful back then. In the end, I prepared the model in an older version of Cinema4D, and imported it into Blender for rendering/animation.

All joking aside, I still have some hope left that the devs will add coloured wires in 2.8x. Even Collection Wire Colour Overrides sound good to me.

(William) #92

I don’t see why not.

We could re-use this section from the Solid mode overlays for wireframe mode too.


Colored wireframes have been added to Blender before, such as in the Gooseberry branch.

The tricky part with colored wireframes has always been making the selection stand out. Obviously we would need to handle the selected/active states differently.

(Lumpengnom) #93

This is not really problematic. There is no mechanism preventing the user to make wireframes the same color as the selection in other programs. It can be an inconvenience and you might have to change the colors by hand but compared to not having colored wires at all it is minuscule.
It would be trivial to write a script that changes all wire colors that are too similar to the selection color to something else, so that the user only has to run this script in case of color overlap.

(William) #94

Hm well, that solution does sound somewhat problematic and not trivial to do either. Some other solutions could be:

  • only use the hue for the wire colors. The brightness can then be used for selected & active states
  • use a different method for showing the selection, such as wire thickness

(asknarin) #95

oh, god, not that )))

(Lumpengnom) #96

Ok. May i ask why it doesn´t sound trivial? If we get python access to wire color per object and python access to which color is set in the preferences it is just a matter of looping through all objects or optionally all selected objects, comparing the current color to the wire color. If they are similar the color is changed to a random color which is not similar to the preferenced selectoin color.
If the user then changes the preferences or gets a file from someone else, he would have to run this script again of course, but really, how often does that happen?

Using only the hue, or perhaps the hue and a range of brightness sounds fine to me. So that lower brightness values can be set up to - perhaps 60% - but full brightness is reserved for selected objects.

Regarding wire thickness, I´m not sure if it works. It´s worth a try but I suspect that it could be bothersome in tightly packed scenes where you really want to generate as little wire overlap as possible.

(William) #97

The non-trivial part is what you said - you said to avoid color collisions with selection states by automatically altering colors that get too close to the selection color. IMO this sould like a weak solution, because all your orange-ish wire colors by default will be distorted and altered. And the selection just won’t visually stand out even so.

Selection wire colors can be changed in the theme, so some complex logic would be needed to avoid this collision in all cases.

That’s why I suggested to not try and do that, but use a different, more consistent and deterministic way to differentiate between selection states vs wire colors.

(burnin) #98

Could outlines for wire selections be possible?

(Lumpengnom) #99

Well, isn´t distorting all colors too similar to the selectoin color precisely what we want?
This works fine in 3ds Max for example.

  • Default selection color there is white
  • Imported objects are often white for some reason
  • You run a script by pressing a button and the colors change to something else.

Now, if you change your color theme which most people probably don´t do all the time you simply have to press that button again.

This seems like a really good solution to me because the user doesn´t have to do more than select the objects and then press a button.

Now, as for it not standing visually out: Look a the following viewport and imagine the bright green was the selection color. There are objects of similar color - that is the dark green for example - but imo the bright green still stands out sufficiently.

Using only hues or hues combined with a range of brightness values is fine as well. It comes with the “problem” that some of the colors will be turned into the same color when importing objects from a different program which uses the whole range of hues and brightnesses. So if you want more differentiation you will again have to select the objects and press a button. So it is not 100% automatic for all cases either.
I think this “problem” is just as miniscule as in the solution in the first example, though, and seems like a fine solution to me as well.

I can´t see why it is necessary for this process to be 100% automatic.

(William) #100

Well, if we use the same options as in Solid mode, to use Single Color / Material Color / Random Color, then users have to manually make sure they don’t make anything orange in the scene (if you use the default theme), or they need to run a command that changes all materials to not be orange. To me this solution sounds weak.

I would prefer a solution that is smarter, requires no extra steps or setup for users, and which is as clear as possible, making it always clear which is the selected and active object, and doesn’t limit using a specific set of colors.

Take an example like this. If we just keep using orange to mean selected, the third from last mesh here is the selected one:

But it doesn’t stand out at all. It’s just another color. And if you unselect an orange mesh, it looks the same as if it is selected. So, it has to be smarter than that.

We could do things like only take the hue, make unselected objects darker, and selected ones brighter, and possibly make the wire thicker:

Something like this, that is generally applicable and requires no setup and will work with any theme.

Other ideas:

Draw some kind of box around selection:

Fill selected with a faint fill:

(Lumpengnom) #101

I can offer you nothing more than my word regarding this. From a decade and half of using exactly such a system I can tell you that it is not problematic. The user is responsible for not making objects too similar to the selection color which is trivial. He simply has to select a different color than organge. There is porbably nothing easier than doing that in Blender.

You suggestions with brightness is fine too. I´d try if it works in a scene with gazillions of objects and check if multiple selected objects are still distinguishable there or if it would be better to have some unique selection color.

Drawing boxes around selected objects is not usefull when zoomed in beause then you can not see the box.

Filling objects is not useful for densly populated scenes because you´d have multiple filled objects behind each other which would defeat the purpose of wire frames.