I’m not sure if it can be useful, some kind of gradient (red-blue for example) depending on the distance to the camera from the user’s view.
I always wanted to make a mockup to try it but I could never achieve the Cycles shader 
Let’s assume that in the future there should be colors for materials too, how should that be added to your concept? What you describe is the first step and if you continue, it should be as seamless as possible.
How and where do you switch between object and material color and how would you specify the material’s color? Should there be a color for every material or should the color be unique in the case the same material is used for several objects?
Is it possible to combine your idea with this use case without breaking the already created work of users?
If we add e.g. a color palette to the mix, does it still work? If we add rule based colors, are they going to screw everything up? Are those things even compatible? Is there even a way to create a user friendly UI with all those concepts? What should be offered by default and what should be left out for addons? Which use cases are going to work good like this and which ones not?
Hacking the first steps together is always easy. But if you continue the journey, you may find out that some of the ideas may just not work together with this early idea. Unfortunately, you already made a commitment.
From a coding standpoint I can not answer your question but from a UI standpoint none of these use cases are incompatible with individual object colors
1 Like
I can’t answer those questions either. That’s the reason why I am also not claiming that it is easy, because I don’t know.
What I know from experience is that you have to consider what could go wrong and what are the limitations for future extensions. That matters a lot, because you will have to rely on it! If you screw the first step up, it is going to be a nightmare to use it in the future or you have to piss off the users, because you may have to change it in a way, such that they lose their work. None of those situations is comfortable and you can only lose when you have to make a decision.
Over the years coders have learned a lot and there are lots of best practises to avoid that kind of uncomfortable situation as much as possible. Rule #1: “It works” is not good enough!
For me there are two most important things to have first regarding colors.
Possibility of transparencies in Solid mode.
Automatic sampling of the predominant color of the Cycles/Eevee shader to automatically be chosen as Solid viewport color of the object.
Ok, i see your point.
I hope this gets tackled somehow, though. The black wire mess is really time consuming.
With all due respect - Campbell did have a sound concept and implementation. It is better than what we have now. If someone wants to replace it with something else later, there is no more work involved in replacing his implementation than writing their one from scratch (likely less overall).
Blender didn’t wait until it had n-gons to release modelling tools for quads/tris. Not having OpenSubdiv integrated didn’t stop the implementation of subdivision surfaces. UV mapping was still implemented before LSCM was even a thing. And so on.
Waiting for perfection is how people who don’t want to say why they oppose something desirable prevent any progress on it. I’ve seen it actively used in commercial organisations throughout my career when management needs to kill projects they don’t like, but cannot actually argue the merits of their opposition. The way coloured wireframes was treated back in 2014 felt exactly like that kind of opposition.
5 Likes
Sorry not interested. I already wasted too much time in this thread.
As you wish. The point was not to engage you specifically, merely counter the claim there had been no sound concept and that Blender cannot implement a feature until it’s perfected it’s design. That’s what I did 
2 Likes
There is no such thing as a perfect design or concept. But if you know that there are obvious extensions for what you are doing and you are not even trying to consider them, that’s foolish.
There are so many use cases and ways in which colored wireframes might be used, it is impossible to consider them all. However, that does not prevent you from considering what the actual goal should be. If you know what the goal is, you can plan how you want to go there and you don’t have to randomly take a step which feels right.
Is there a clear goal or vision for colored wireframes? That’s the thing I am talking about. As far as I know, it does not exist.
I am sure Campbell had a plan, but that is worth nothing, because he abandoned it.
While the patch is indeed 4 1/2 years old, a lot of the concepts are still applicable. Have you reviewed the patch?
Who said anything about not considering the actual goal? The actual goal was presented at the time the patch was being developed. The goal was also achieved but the feature rejected by Ton because he wanted in place a vague, unspecced, undocumented “rules system” to decide on the colours because (apparently) users couldn’t be trusted to set their own colours.
Yes. That you do not know of it is apparently due to you not looking into the patch by Campbell, the discussions had at the time, and the iteration over that vision as we tested the feature.
Campbell didn’t abandon the plan. He was told it wasn’t going to be merged into the codebase. As a BF developer, there isn’t much point in working on code your boss has said he doesn’t want to see merged.
Ton had a vision. It was vague, not documented, and didn’t actually conflict with the work Campbell had done. It still doesn’t. Getting coloured wireframes is step one. Step two is allowing those coloured wireframes to be set by “smart systems”, but until you get step one (and/or actually spec out what you want from your smart system) - you get nothing.
I had a look at it. It uses the object’s viewport color or a custom wireframe color per object. I only had a quick glance over everything that is not actual code and I haven’t seen an overall goal.
It is also not unusual to just create a prototype to have something to try out and to find out whether it makes sense or if another approach should be tried too. I don’t know whether it was supposed to be almost final or just a prototype as a basis for a discussion.
In those years, the goal would have most likely changed. I am very confident that layers were never considered, but now that there are collections, it would definitely make sense to check whether they could be useful for artists. E.g. all objects in collection A should have a desaturated color as they are in the background, but are useful as a reference and all objects in collection B should have a unique/custom wireframe color for each material because they are going to be edited. It appears very natural to me to group objects in one or more ways if colored wireframes are used in the workflow. However, I am not an artist.
I literally don’t care about anything that is not relevant for the technical discussion. So, could you describe how that “smart system” is supposed to be used and in which use cases it supports and which ones are more difficult?
As a proponent of coloured wireframes, and as the feature is not being driven by a long-term BF plan, I don’t see why that would be the case. The issue is that wireframes are confusing and that allowing them to be individually coloured makes that view clearer. As per other applications. The goal hasn’t changed.
Layers were considered and ultimately considered irrelevant for a first cut of the feature. There was a long thread where we tested the feature, discussed it’s development, made suggestions to Campbell, etc. I suggest digging that up if you want to know what was and wasn’t considered at the time.
I think you’re over-complicating it personally, however I’m not adverse to you (or others) finding a way to do what you’re after provided it doesn’t block the primary use case - quick & easy differentiation of wireframes by user-selected colour.
As Pablo put it - we have object colours in the viewport already. If we can handle them for objects, it’s a little hard to argue that we cannot handle the wireframes being coloured. Just as we can leave room for auto-colouring of objects whilst starting with manual colouring - the same can be said of wireframes.
2 Likes
If this is the primary use case, wouldn’t it be more flexible to have colors per material instead of per object?
No. Neither could Ton at the time. Yet that was the reason we were given for vetoing the feature. That was the point.
Not really. Objects that share a material could need to be differentiated. We have per-object colours for the viewport. Coloured wireframes are at that same level of scene hierarchy (merely shown in a different mode of the viewport). It also neatly deals with the problem that edges can have multiple materials assigned to them by not overcomplicating the feature.
1 Like
Not interested in bullshit talk, sorry.
Firstly, it isn’t bullshit. Feel free to actually read the thread where the feature was developed, tested, and then ultimately put to bed. It was discussed at length. Coming in and telling those of us who were actually part of the development & testing process four years ago what you “assume” was & wasn’t considered is disrespectful enough without you flipping off people for answering questions you asked.
Secondly, there was more to the post than that. I’m guessing from your shallow deflection that you didn’t like that answer to that query of yours either.
3 Likes
I asked a question about the “smart system”. I expected it should be clear that I don’t care about conspiracies.
It is obvious that you have a very clear view on the topic and that for your use case, you don’t need much functionality indeed. I would be surprised however if all artists who would like to have colored wireframes agreed with you.