Why not have the Bounding box “themed” and the wireframes “User Defined”?
Or switchable depending on use, “themed” colors for some operations like grouping or selecting, then “User Defined colors” for general display?
EDIT: Sorry if its been mentioned on this thread TL;DR
If it is thought different themes might mess things up when passing blend files between users how about if coloured wireframes are only available when the std blender 24x theme is used and therefore this a std or default for scientific/technical users, or perhaps we have a special technical theme? This is sort of a half way solution to branching for artist and technical users which is probably unnecessary. Really I don’t see that this type of user would want to do rigging and ‘organic’ stuff and therefore it would result in the conflicts imagined my some or indeed that users would pass around their files except to people doing the same type of work.
You make the assumption here that a theme based wireframe color scheme would take away the ability to directly assign color to wireframes which is not the case.
Take cycles materials, just because they are node based does not mean you cannot directly assign a specific diffuse color as you did with the old materials.
Another big mistake that I see people make here a lot is to assume that software becomes popular because it is familiar because it implement features other software have. Thats simply is not true, its actually quite the contrary , software is always in a race of unfamiliarity , trying to add new features all the time that optimise user workflow.
None was familiar with nodes when they were first appear, or ngons, or procedural modeling , or scripting etc etc. The development of software is completely driven by developers , not users. Users dont make any decisions on what is added to a software. They are just at the receiving end. So what they are used is completely irrelevant to the success of a software. What really matters is whether the new approach and new feature really enhances the workflow of the user. If it does then people will embraces and it will become part of their “familiarity zone” while they will abandon old approaches.
What is Blender primary function?
Create 3D content or UI themability?
Why is theming taking precedence over a simple content organization tool like wireframe colors?
@kilon, I am also a coder and I think your code editor analogy is slightly wrong because in code editors coloring is defined by a set of rules that apply to a limited set of known items. 3D objects in a scene are not a limited set.
Also, code editors have rules for different languages because no rule would apply to all languages. In some editors, the rules can have an arbitrary amount of customizable colors because nobody knows how many colors you may need for next language. 3D scenes are not languages, and all scenes are different with an arbitrary amount of objects.
That said, if wireframe color has to be themable, then your analogy somehow applies and it would be much better if it was like on some code editors. Fully customizable with an arbitrary amount of named colors. Like this:
That of course would be a bigger patch than current one.
Or, this could also replace layers if designed that way.
If themability comes with a limited set of user definable colors then the feature is crippled and the current patch offers much more versatility to the 3D content creator. How can anyone know how many colors are enough for a scene? That would be like limiting the amount of materials, shapes or polygons on a scene because a limited number is enough. Or worse, making materials themable because somebody doesn’t like the materials some other user put in a scene.
Actually my code editor analogy could not be more spot on and thank you for going to the trouble displaying these image to make it clear to people what I mean.
You say that that code editor syntax color themes are finite while 3d objects are infinite. Thats not the correct analogy because also a syntax element can be expressed in infinite amount of possibilities and a colored data type can have a value in an infinite range of values. Actually my example is spot on because the analogy is spot on. Both colored wireframes , if i understand their usage correctly, and syntax color have the same goal of identifying by color “kinds”.
So basically what you saying is " a code editor only has 30 colors, I want to use 1000 diffirent colors for my wireframes". My question is “do you ? really ?” because I can tell you that code editor has 30 color options because if it did have 1000 the code would end up looking like a color rainbow mess . By the way a text is easier to see than overlapping wireframes so a color mess for wireframes would be even bigger than for syntax colored code where each code command goes in its own line anyway.
As coder you should know that nothing out (3d asset wise ) there can beat the complexity of code, an application like Blender has over 1 million lines of code, each line has roughly 3-6 words that can be colored separately. Please talk to me about your complex 3d scene , it wont be able to compete in complexity even with a simple addon. Everything should be done with a measure.
This is what makes people like Ton and me so sceptical about how wireframe coloration . I dont worry for me personally neither Ton is worried for him, because I most likely wont use the feature so much and if I did I doubt I will end up assigning even 100 colors in a complex scene. But still it should be implement in a way that is efficient because when the time comes to use I dont want to use a messy implementation just because its the same crap in other 3d software as well or some people made a 41 pages noise in BA. Just saying.
Also from the start of your post you seem to confuse UI theming with Wireframe theming, as xrg said in his video there is some relation because UI themes can affect how easy to view a specific colored Wireframe but as concepts should be separate. I agree with that video very much.
Blender is rarely limiting in any way, everything is accessed via the Blender python API and scriptable this is why you see all these amazing addons pop up from time to time and I am sure we will see some for Colored Wireframes as well.
Also Ton does not appear to have a specific idea of how this will be implemented so everything is still open on suggestions. Even my idea of a tag bases system is far from a mature idea and if I was to build such system I would spent a serious amount of time carefully thinking it through and at the same time reading blender source to make it as intuitive as possible.
Debating on BA is one thing, the easy part, thinking how to implement it is where the real challenge is.
I think this is overcomplicating with theming.
Just have checkbox under themes saying Use Coloured Wireframe, and if checked for every object there will be colour chooser to chose wireframe color, and if you send .blend file to someone else he will see the same.
If do not want Coloured wireframe uncheck that option and have wireframe controlled with theme.
What is wrong with that?
Yeah this is perfect than. Viewport option works fine also.
In future there could be added colouring per layer, I think something like that works in 3dsmax.
Yes and no. Syntax elements can be expressed in an infinite amount of possibilities, but on code editors the coloring is on the syntax level, not on the possible combinations. In this analogy wireframe coloring would be like coloring different functions, loops, structures on the code and this would be much harder to do on text code than on 3D objects. In fact, this is what blender already has, coloring depending on the object type.
You ask my if I want to use 1000 colors? My answer is I don’t know if I will ever want to use 1000 colors. 1000 colors in this regard is a silly number. The limit could be much lower as have already been mentioned on some discussions. If the limit is 1000 then it can be considered unlimited but if there is a limit then it will not be 1000 and you know it. There will always be a limit in code depending on the type of the var used to store the value. Why add an artificial limit over that?
The phrase ‘X is enough’ has been proved wrong so many times in history that I wonder why it’s still being used. 64K is enough. 20 layers is enough. 64 undo is enough. 40 pages is enough in this thread.
The images that make clear what you say show an interface for an arbitrary number of themable colors, they don’t show a limited amount. Did you notice the scrollbar on the C++ example? That’s what I mean. Variable/arbitrary/unlimited amount of customizable colors.
Stop worrying about users so much. Users are not kids that have to be protected from themselves or other users. It’s condescending.
Edit to quote what you added afterwards:
Scenes can be complex and code can be simple. You can create a scene with code and you can save a scene to a format that resembles code. There is no point on comparing. Blender is very complex and so are scenes from a big studio film.
Coloring each word of each line separately is like coloring each face of each object on a scene, and you know what? You can do that on blender. And you can do that on text code using a word processor if you want.
What is hard to do is do it with coded rules.
What is more intuitive?
Select object -> set object wireframe color
or
Select object -> assign themed wireframe color slot -> go to wireframe color theme editor -> edit color slot
Not only it is less intuitive, it adds a layer of complexity, is harder to implement and it hasn’t been decided yet the best way to implement it due to it’s complexity. And if it has limits it’s crippled when compared to the other option.
Meanwhile a patch for the simpler solution has already been coded and goes straight to the point of allowing the user set a wireframe color to an object, is optional and unlimited.
From a workflow point of view, this is not what you have to do. The colors are stored in the theme which means they are usually already set up or you can define them on your own. If you are then using the wireframe colors, you only need to:
Select object -> Assigne themed wireframe color from slot
The consequence of this approach is that if you find out that the first color from the palette is not good for some reason, you can modify it in the theme and it will automatically be adjusted everywhere. It won’t be necessary to change the wireframe color in one object after another. One of the use cases of colored wireframes is huge scenes with lots of objects. As such, it is required that colors can easily be modified without the need to change them one after another.
As a side effect, it will be easy to exchange the Blender files with people who are using different themes.
I don’t see how this introduces an additional complexity level.
Separating the color from the object to make it themable has de side effect of breaking the scene context. Maybe the user wants to color wireframes in a way that only makes sense for one scene and differently on another scene.
With that in mind, if the themable wireframe colors are limited in amount and hardcoded in the theme configuration, then it’s just UI theme colors polluting the scene objects breaking the scene context. Limited functionality that will not fit all possible scenes and users.
If themable colors are not limited in amount and can be defined on a scene basis, like a library of scene wireframe colors, then it works the same way the current patch but with bigger code complexity and the only benefit of an easy editable palette. The UI for that would be like the screenshots I posted of code editor UI, a variable length UI that allows editing all scene wireframe colors. I have nothing against this solution, it’s only far from being implemented adn doesn’t seem to be ‘The vision’ because it’s ‘per scene’ not ‘per theme’.
I don’t see the trouble on changing all objects colors with the current patch. It’s not hard to select all objects with the same color and then you can edit one and copy value to selected. What’s the problem with that?
@ideasman42, is it possible to add the option to color the wireframes with diffuse color? Does it make sense to you? I think it could provide an easy way to see the objects based on already set colors from materials but I understand this could be difficult for objects that have different materials on faces. I ask this just as an additional option to what is already in the patch, of course.
I think the question / issue is whether it will stay that way. Ton is still against it as implemented (at least according to the AMA) and we’ve trodden this road before.
@kilon:
I’m a code-monkey myself and I strongly disagree with the majority of your arguments. Please stop this “as a developer” nonsense as if it gives you some authorative insight into the issue because, “as a developer”, I’m finding most your arguments shallow and invalid at even a cursory examination of the facts.
For example, coding languages have a fixed & finite grammar that must be adhered to in order to compile. Syntax highlighting makes use of that grammar for separating out the components. Different language, different grammar, different syntax highlighting parser. The key point to remember is that one doesn’t write a new language for every project - there are a small number of popular languages and their grammar is computationally finite with fixed keywords, variable semantics, etc. Not so with Blender projects which, as the Blender conference showed, range from a wide variety of computer game & animated film genres, through architecture (with different firms having different standards), to representation of medical & engineering data. One cannot write a grammar that will work for all of them and, frankly, most artists aren’t going to.
Modelling a building for arch-viz shouldn’t need coding experience. If they want window wireframes green, they should just be able to do that. You know just like custom bone colours that have been a part of Blender for some time now. It’s good enough for riggers and animators using armatures, what is so special about meshes they cannot have the same freedom?
According to my understanding that is what Ton had in mind at the Blender conference. He also mentioned custom colors which can override the ones from the theme per object.
It is not hard, but pretty time consuming and clearly not user friendly even in a scene with around 100 objects.
You wouldn’t edit the theme colors. There would just be swatches. When you load files in different themes it assigns whatever colors that theme has set for the swatches.
Mockup example of what the UI might look like:
So in one theme, you might have a red swatch, but in another theme it might be blue – the theme author can set up several that work well with that theme. It’s a bit like palette swapping in old NES games. The entire point of it would be to avoid needing to deal with situations like this:
Definitely overcomplicated…
Just do it as in 3dsMax which is already in Gooseberry. And than create tool that will help you to easily select by color, and change color if you do not like it. This way with theming is just one layer of complexity that does not help but just make thing more convoluted.
If you are in the situation that you are working regularly with an artist who uses wireframe colors that conflict with your theme colors, it is most likely the simplest solution and doesn’t overcomplicate anything because it just works.
So Ton has in mind ‘per scene’ wireframe colors? But, limited or unlimited amount of color swatches?
It’s not time consuming with a small script that selects all objects with the same color. Not time consuming at all. It could go on the select menu under a new option named ‘Select same color’.
This seems ‘per theme’ and limited. It would not fit all possible scene or user criteria.
Breaks scene organization where the user could have selected the colors according to some criteria that is scene based and uses specific colors for objects.
It’s also limited in the amount of swatches available. 20 swatches is enough? Depends on the scene.
Nothing prevents the user from creating a bad theme.
Or you could talk to the artists you work with regularly. Talking helps.
I already said that, but I don’t understand why devs dos not put the wire color with the layers.
If you have an undred meshes, you need to change the color of each mesh, if we have this on layers, we have only one color to change.
If the theme is not good with those colors, we have only several color to change with layers, not on each objects.
It’s simpler with layers and logical.
I never change the wire of objects in other programs, I change le wire on the layers because my objects are in layers and it’s faster and cleanner.
An object can live in multiple layers. How would you choose which layer’s color gets used? The same goes for groups.
It could also be different artists. And if you talk to people they may always miss that kind of details at first, but it could easily be avoided. Having a small script to select object sounds like an unnecessary layer of complexity. Depending on the situation, you may always find something that is unnecessarily complex and could be avoided with another solution.
However, I said everything and won’t continue to discuss because it is just a waste of time. The people working on the Gooseberry project will see whether the current implementation works for them. I am sure they have more than one theme and might come up with a practical solution.
