Those would not be hard coded colors, but selected colors for a certain theme in order to get a usable result among users who have different themes. This would certainly not be consistency within Blender, but consistent user experience. Certainly consistent doesn’t mean equal in that context, but it would mean usable.
Thank you jedfrechette.
You formulated it much better than me.
As implemented the patch we are discussing hard codes the background color to 18% gray when using colored wires:
if (V3D_IS_WIRECOLOR(scene, v3d)) {
const float value = 0.18f;
glClearColor(value, value, value, 0.0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
}
So far we don’t have any other concrete proposals for the sort of ‘rule based’ system you seem to be referring to so it’s hard to say anything about how much consistency it may or may not add. I’m all for a rule based system that provides consistent sensible defaults. However, in my experience while these types of systems work great most of the time, inevitably there will be corner cases where the user needs to override the default colors because they aren’t showing what the user wants to see. If that, I would argue very important, use case is to be supported than we are right back here with potential conflicts between user defined colors and theme settings when exchanging files. The question is: Can the user who manually changed their object colors be trusted to fix any problems they may introduce or do they need to be protected from inconveniencing themselves and others?
Typically, people feel more motivated over creating something than changing it. So, I wouldn’t expect that similar discussion be had over existing implementations. This doesn’t mean that such a feature makes sense to include because of this reasoning, this is much more of an analysis of human behaviour.
Regarding your reply specifically, (after inferring some points from my previous statement), if users do feel motivated to make a comment, which for the most part people do not as stated, then they rely on a strong user-developer relation. Some companies have this, others do not.
There are many different ways to develop a strong user base, and this isn’t necessarily because your application is “the best”. Other words such as “the standard”, “no alternative” or “we just use this software, get used to it” are all commonplace.
I think that there is a lot to be said for both sides of the argument, and it doesn’t seem like any unanimous conclusion will be reached across the user base, even if the development decision is already somewhat in place.
This just sounds like a cop out to me (sorry to say).
I didn’t mention the background color at all. All I wrote is that it is important to find a solution that works among users with different themes which is not really an exotic use case.
The main application of colored wireframes seems to be to make objects distinguishable among each other. A straight forward idea for a theme based solution would be to define e.g. 4 sets of colors and within each set you would have e.g. 6 colors that have a sufficient contrast among each other and to the background to be recognizable. Let’s say we want to color car parts for the wireframe mode, we could decide to only use colors from the first color set. The tires may get the first color, the body the second color, the windows get the third color, the doors get the fifth color, …
If one changes the theme, all the car parts may get a different color, but would still be distinguishable.
Of course that kind of approach almost certainly misses relevant use cases, but it would provide usable results among all kinds of themes.
I’d like to share some of my experiences using the patch (juicyfruit’s build), but before I kinda need to make sure I didn’t miss something. 
Is it “normal” behavior that wireframe colors do not apply to meshes in Edit mode, but only in Object mode?
Fair enough, although you did seem to be arguing for consistency over user freedom and we were talking about the freedom to choose any combination of wire and background color we want.
I also want to correct my earlier statement about no concrete proposals for a rule based system. I had forgotten the proposal Ton made back in 2005 based on discussions occurring at that time. I think that proposal is quite solid so I’ve quoted it below. Although just an outline I would be quite satisfied with what he has proposed. If any new proposals have been made since then I would be grateful if someone could point me to them.
http://lists.blender.org/pipermail/bf-committers/2005-January/009137.html
In the context of the current discussion I would just like to highlight two features of that proposal:
- There is no suggestion that anything other than the wire colors should be changed in the viewport.
- The default setup allows users to assign arbitrary colors to every individual object in the scene.
The actual point of my post was to bring in the consistency of Blender as another aspect that is relevant for the discussion.
I have understood your point. But the wireframe colour as it is implemented in other 3D software does not introduce inconsistency. It introduces a common standard. There is no problem really. That was the actual point of my post.
When it’s about consistency then most of the things in Blender needs to be fixed. Blender is the mother of being inconsistent. We have several types of dropdown boxes, several types of buttons for the same thing, missing hotkeys for lots used tools, and so on.
That is correct.
There is no suggestion that anything other than the wire colors should be changed in the viewport.
Interesting find 
Don’t beat me since I obviously don’t understand: why has it to be turned off in Edit mode?
@agoose77 I am not even sure if we are talking about the same thing at this point. In the post I previously quoted you came off (to me at least) as stating that users of other software don’t have a working solution but are just not interested in voicing their opinion of the problem, which is completely wrong. Colored wireframes in software like 3Ds Max works perfectly well, no-one is complaining because there is nothing to complain about. If they had the same issues that are raised here they would complain loudly and have the developers fix it.
@DruBan Thank you. 
I kinda “overlooked” it in the discussion 
But I share your point, that it would be useful to have it in Edit mode, too.
Of course there is the option to hide parts of a mesh or use local view, but especially for rather complex models (not scenes) it may be useful to see your mesh in its relation to other mesh parts (so one does not need to hide parts or use local view) and be able to distinguish them easier.
I love the idea and especially Campbell’s work.
This is just my personal opinion, but I didn’t use it to organize my scene, I use it as a visual helper to distinguish the respective meshes among the “wire chaos”. I found myself to use not more than 4 colors at one time.
The patch works really good so far, I had no crash, no slow downs.
Also in this state this feature is and can be quite helpful (I’d just prefer to have it in Edit mode, too, as mentioned.)
This isn’t about giving users “lots of freedom just for the sake of it”. It’s about giving them a specific & narrow freedom to change wireframe colours in the same way they can change other elements of a Blender scene right now. Unless someone is talking about removing the custom colour options from bone groups - this is simply the same feature applied to wireframes with the added restriction (i.e. less freedom) of requiring the user to toggle into a special mode in which to see said colours (unlike the extra freedom given in bone groups).
Also, it might do the conversation a little better if people on both sides stop exaggerating their position. Just as Tiles was (rightly) told to stop going on about forking Blender over this, I think it detrimental to keep dismissing the feature as “freedom for the sake of freedom”. That is not the case. Several real world use cases have been presented for which people want this feature. It’s “freedom for the sake of an improved workflow” - which I’m sure you’ll find a much better reason for adding features to Blender.
Onto actual comments from the developers:
Default rule is “Free”, which allows a menu per Object to assign a free color (pop-up menu with swatches choices in Object buttons).
Interesting point to note here is that the coloured wireframes at the moment implement part of the proposed rules system that has never eventuated. No requirement for colours from a theme, but I do like the idea of the swatch (which could come from the theme I suppose). Ton actually didn’t have a problem once upon a time with what we have here, he just wants more as well. Why is this? Why not commit what we have already and then add rules later? It’s not like the “free” colour rule is going away, it’s just getting added to.
Again, serious questions to ponder for him & others, not trolling or looking for dissension.
Regarding freedom vs. the enforcement of common sense, I think the very nature would punch a big hole in the idea of random colors, you never know what color the app. is going to throw onto the next mesh when it gets created (though limiting any randomness to slight HSV variations may be tolerable).
For strictly user-controlled colors though (and other concepts like value changes based on the pixel size of the bounding box in viewspace, I think there’s plenty of reason to include wireframe coloring in that sense.
That’s what I’ve been getting from recent pages, again, the random colors option shouldn’t be considered at this point because the user would not actually have control to make sure everything can be seen with the theme they have in place, it’s almost like if someone threw up some wacky idea of random interface colors for each window type :spin:
I didn’t think there was any real push for random colouring, just the ability to colour the wireframes as the user desires. I’d like to see a real use case where the colours are going to break something that the users cannot handle as a normal part of a multi-personnel project. Assuming the users all have different themes, what is the workflow breaking issue with toggling in & out of the new view with it’s own colours?
It is notably odd that custom bone group colouring wasn’t complained about until AFTER people raised them as an example of the very thing being used to reject coloured wireframes. People are getting hung up on the theory that coloured wireframes will ruin the UI whilst the practice of allowing said freedoms with bone groups has demonstrated it rarely, if ever, is an issue.
Why not commit what we have already and then add rules later?
I tried to. I was told that the patch is already rejected.
The curious part here is that it gots rejected without a single official statement from the module owner. Magic …
The second curious part is that it gots rejected by a reason that doesn’t make sense to most of us, while the whole cg industry uses exactly what gots rejected. But that’s Blender
Just a thought:
AutoCAD. Does anyone ever complained that autocad is Themable (Background, for example), but the wireframes colours are custom?.. I don’t think so. I still think that’s such an insignificant issue that it’s not even worth thinking about…
Rule based colouring:
I see no issue here either. Just switch between the two (Custom or rule based) manually. No contradiction.
Why this patch was rejected is a complete shocking mystery to me…
+1
Also 3dsmax has customizable colors and with all the problems has it and its development, the coloured wireframe has never been reported as an issues… I really don’t understand why it should be for Blender.
About the color palette, I think it’s good to have a single colour to the same “special” object.
For example: all the lights should have the same colour (yellow like now), all the cameras the same and so on.
I’ll leave the different colours just for modelled object(or curves)