“If you build it he will come…” http://www.imdb.com/title/tt0097351/quotes
One day Ton might agree, who knows.
On one hand Ton appeared to me (from the reply he gave in the developers QA session) that he was against the idea that Wireframe colors be static , instead he prefered them to be Theme based, which as far as me is concerned looks like a very sensible idea and how I would like Wireframe colors to be implemented. I did not see any of the developers disagree with him either.
On the other hand Ton made a remark that metaballs does not deserve more love because people do not use it. Of course beyond the fact that metaballs are so badly implemented in blender that even I who I am a fan of metaballs dont use them there is also another software that shows beyond any doubt that if you have a software that people dont want to use but has real practical potential and go on to do the actual hard work of implementing all the cool ideas people will come in swarm.
That example is zbrush, I am one of the first customers of Zbrush , I purchased version 1.15 or something in a time when Zbrush was viewed by the industry as nothing more than a toy, looked completely unfamiliar to artists and most of them even questioned its purpose. For me digital sculpting was the way to go if zbrush really improved and it did and nowdays not using digital sculpting looks as pointless as it was back then to use digital sculpting. So I think in the end is that visioners , like pixolator (main developer of Zbrush), know a lot more about what users need and want than actual users.
So in that respect I completely disagree with Ton. Definetly does not work that way.
Please can the latest patch go into trunk and get wide testing through buildbot? It will not hurt anybody who don’t want colors in the end…
What if I color code my stuff? Like doors yellow, windows bright red. How does rule and theme based come into play? I don’t agree thats a good way to implement it.
Colors should either come from the object parameters into the scene if they are object attributes (as they should be on my advise), or they have to be mastered by the scene; just in the latter case we can take into consideration their themability, IMHO.
paolo
This. 10,000%.
So when you decide to color code your items and give the file to someone, what is easier:
- Give them the file and tell them that all distant static objects are orange?
- Give them the file and tell them that all distant static objects are theme palette #17?
As I mentioned before, the answer is a simple per object setting: Wire Colors: (x)Custom | ( )Theme Palette
So basically you dont agree with something you don’t know what it is.
Ton was very clear about this, your color scheme of things in the scene should not polute my color scene of things in your scene. So when I get your blender file it will use my scheme and it will be easier for me to make sense of your scene instead of me adjusting to your “awkward” way of coloring things.
How that will be implemented is completely up to the developers but how I would do it as a coder would be for the user instead of choosing the color directly , to tag his objects and then color would be assigned based on the tags used. Preferences will allow the user to associate tags to colors and also offer different schemes of colors.
Ton thinks about it like a coder and he is correct. For example if you open a source file in any self respecting code editor it colorise some specific commands that are essential to the syntax of the language used. So a string will be a diffirent color to an intiger, a for loop diffirent color to an if statement. The user never choose the color of the code directly but he can choose how diffirent kind of syntax is colored.
This gives the advantage over a static system of choosing the colors directly of very easily selecting diffirent color schemes for wireframes of objects. So that means a wireframe can change through diffirent scheme of color depending on the way its is viewed. So diffirent color scheme if viewed based on material, based on parenting, based on visibility in the camera etc etc.
Theme based is way more flexible, more powerful and less intrusive. Its actually very difficult to debate against it and why Ton’s idea has not been resisted by the developers .
Of course this idea is more difficult to implement and will take more time. But for me its in the credit of Ton that he choose the less easy way in favor of keeping Blender highly versatile.
It’s in the gooseberry branch for testing.
Campbell
Experimental color wire-frame (for testing in the studio)
Cheers,
~Tung
I’m all for doing things the right way the first time, but there has to be some sort of balance. When I hear Ton’s description of how he would like it to work, it makes sense why we have no colored wireframes: It would take tons of time to implement.
It’s frustrating to see a fully functional patch shot down because it doesn’t fit a standard that nothing else adheres to in blender. What if I’m working on someone elses files and they have a confusing panel layout. I think there should be a window layout pallet that automatically converts user’s window layouts into other users window layouts! or I guess we could have a single checkbox on load to disable loading the UI from the blend file, to stick with the loader’s UI. Is it just me, or does that second one make more sense?
Does the theme editor automatically adjust colors that the user chooses so that they don’t clash? Certainly not, and I have seen tons and tons of hideous color schemes that people use. Shouldn’t we take control away from the users so that they can’t make poor decisions?
How about we remove Ngons because what if users make something with bad topology?
The only downside to the patch as it stands, that Ton has brought up time and time again, is this very specific use case where one user opens another user’s files and is completely overwhelmed by the second users color scheme. How often does that happen? If you are working with another users files regularly enough to be bothered by it, then you are probably working in some sort of studio environment. In which case, shouldn’t color theme consistency be the studios responsibility?
I work in autocad daily. where I work, we have standard color schemes: metal is blue, acrylic is cyan, electrical componenents are yellow, cabinetry is green. when I open cad files from somewhere else, the colors are totally weird, but I don’t expect autocad to correct that for me.
The analogy with the text editor is deeply flawed. Editing code follows a very specific syntax, every single time. How can I program a rule that turns every window in my scene blue? How can I program a rule that will know which empties I want to have tinted green for rig handles and which ones I want to turn red for camera targets? Blender is a creative program, where people are going to want to do creative things. Do you think they should strip out the text coloring options in Word? No, because people utilize those colors for a reason. I agree that giving users the ability to add their own color coding on top of syntax highlighting in a text editor would be very confusing, but that isn’t what is happening with this patch.
I fail to see how having no custom colors is better than having custom colors. If Ton wants to outline exactly what he has in mind, then maybe it might be worth waiting, but from how I have heard him describe it, I’m not sold.
Sounds like you dont know such a feature is used. Thats key here, not how you imagine it or what you feel, but how its USED. I amazes me how often people on here forget how things are used in the real world as opposed to what fits into some type of emotion based logic.
Ton was very clear about this, your color scheme of things in the scene should not polute my color scene of things in your scene. So when I get your blender file it will use my scheme and it will be easier for me to make sense of your scene instead of me adjusting to your “awkward” way of coloring things.
Here is why I think Ton and you as well are wrong. Rather, it seems like you just dont grasp the usability side of it.
-
Colored wireframes are for the user, they are picked by the user depending on type of content and scene. The purpose is to IDENTIFY different meshes/objects in a scene. Its not for rendering out pretty pictures, its not for comforting your emotional state with your color scheme of pinks and purples… Its about functionality. Would you argue SVG masks should also be based on someones emotionally preferred color pallet? I mean really now… Focusing on a theme and putting it before functionality, while also ignoring the functionality tied to it is beyond absurd. These 3d asset creation programs are tools, not tumblr accounts.
-
Having the user pick their colors on a per object per scene basis is important for various reasons. It should have nothing to do with a theme. By having the user pick the colors on a scene by scene basis, even ones the need to stand out for whatever reason, is extremely important. The act of picking the colors they NEED for that object literally means they can recognize it and what it is faster (as well as remember that information). Having it automated actually destroys that.
-
In a REAL WORLD work environment, where you might need to work with a group or other users…or even follow instructions… having colors match parts in a scene is extremely important, even more so if documentation is attached to the project. Tell me, how do you think it will play out if you get a project file with a document which lays out the specifics of every item identifiable by their colored wireframe, and you load it up and have it be completely ruined because your theme is making changes?
What that does is create INCONSISTENCY in favor of someones color preferences. Please think about how absurd that is. Themes do nothing for a project, its just a personal preference. If someone is bothered by the wireframe colors picked by another individual on a group project, and they want it to match up to be “pretty” with their theme…they are in the wrong line of work. In fact, its unrealistic that they would get work to begin with.
Finally, I dont think Ton thinks about it like a coder. Coder’s know the importance of consistency between eachother. Imagine if one coder doesnt like the variables x, y, z and instead prefers c,v, b. Imagine if he/she preferred to use the object name CUBE instead of BOX, but another coder prefers to use BOX instead of CUBE. Sounds absurd right? Because it is, and if its acted upon…say a project is put on hold because they want to create a system that automatically changes those variables and object names on their end… then its beyond stupid. I’d argue that projects with multiple programmers needs to have consistency in naming, in layout, in syntax. Is it then logical to suggest its the coder mindset that would want colored wireframes to be changed per user so that “ugly colors” (his words) wont offend them or ruin whatever emotional state they have tied to their theme? I dont think so.
I see Ton coming more from a sentimental and subjective point of view, often which is why some of the decisions with Blender seem so weird. Even the desire to be different for the sake of being different rather than conventional.
Anyways I digress, I hope you can find the above a solid argument as to why the theme equation is a silly thing to give importance to and that it shows a LACK of understanding how colored wireframes are used in a workplace setting… Lets let reality kick it.
As someone has mentioned, the Gooseberry build now has the colored wireframes as a native element and any final conclusion may well depend on what the artists working on the movie will think.
It will also probably mean that Ton will see it in action as well in a studio environment, it might be enough to soften his stance on wireframe colors if he can mess with it on a complex scene himself and see just how much easier it is to find certain objects.
The thing is that visual creative people (3d artists for instance) don’t think like a coder. They like direct visual control over their scene. Just pick and choose a color you like, no rules and relations to figure out. That is at least how I see it.
Can only say that its easy to write over a few lines how easy and flexible this system will be. It goes for you, and it goes for Ton - 10 years in the making and no concrete detailed proposal from him. And did Campbell look that convinced by Ton’s ideas at the Developer AMA ?
At last I will add that simple custom (user defined) colored wireframes is implemented in a lot of 3d programs out there - so maybe this is a implementation that just work well. So implement this as the baseline/basic feature. And you can later on add a advanced - never seen before but believe me it will be awesome - rule based function as a secondary mode. If you can make it work, that is.
Edit :
@ SterlingRoth - Some good and detailed observations you have in your post.
Huh the goosberry build has it ???
Is there another version of blender out there made just for one movie ?
I believe that all of the open movies had custom builds that they were made with, though I’m not certain.
Colored wireframes would really be a boon, especially for techinal stuff, like Archviz. But I’ll up the ante by saying that each object should be able to contain a number of colors for its wireframe to represent its different aspects or functions, if you will.
(For simplicity’s sake, let’s leave the layers out of it for now.) Take, for example, a building, where you might want to group all doors in one color group, but some of them might be emergency exits, so they would have an additional color for that. You might also want to color-code all objects that belong to the same floor, aso. Tagging them by function, then assigning a wireframe color to that particular function would make working with complex scenes so much easier!
How you know that , you are a coder ? I am a coder and I don’t know how long it will take.
It’s frustrating to see a fully functional patch shot down because it doesn’t fit a standard that nothing else adheres to in blender.
yeah agree, apart from cycles materials, compositor, layers, python scripting, blender data, scenes, screens, gui customisation and the 99% of Blender that is fully dynamic. But yeah for the rest 1% I agree, static all the way.
What if I’m working on someone elses files and they have a confusing panel layout. I think there should be a window layout pallet that automatically converts user’s window layouts into other users window layouts! or I guess we could have a single checkbox on load to disable loading the UI from the blend file, to stick with the loader’s UI. Is it just me, or does that second one make more sense?
no need blender can ommit loading the gui layout when you load a blend file by uncheking the load GUI option in the open file window. This is part of that 99% of Blender being dynamic I am afraid so you will have to find an example from that 1%.
Does the theme editor automatically adjust colors that the user chooses so that they don’t clash? Certainly not, and I have seen tons and tons of hideous color schemes that people use. Shouldn’t we take control away from the users so that they can’t make poor decisions?
Thats a bug/limitation of the theme editor , who said that Blender is perfect ?
How about we remove Ngons because what if users make something with bad topology?
I think we can go even further with this and argue it this way “why make blender at all if users make something ugly with it ?”
The only downside to the patch as it stands, that Ton has brought up time and time again, is this very specific use case where one user opens another user’s files and is completely overwhelmed by the second users color scheme. How often does that happen? If you are working with another users files regularly enough to be bothered by it, then you are probably working in some sort of studio environment. In which case, shouldn’t color theme consistency be the studios responsibility?
I work in autocad daily. where I work, we have standard color schemes: metal is blue, acrylic is cyan, electrical componenents are yellow, cabinetry is green. when I open cad files from somewhere else, the colors are totally weird, but I don’t expect autocad to correct that for me.
All hail the tyranny of standards. People love doing things their own way. Cant say I can blame them . Theme based wireframes wont correct anything, I never use such word in my post, all they offer is a more dynamic approach. Dynamism is not AI. Its not anywhere near that. Dynamic means you can be flexible of how you do things.
The analogy with the text editor is deeply flawed. Editing code follows a very specific syntax, every single time. How can I program a rule that turns every window in my scene blue? How can I program a rule that will know which empties I want to have tinted green for rig handles and which ones I want to turn red for camera targets? Blender is a creative program, where people are going to want to do creative things. Do you think they should strip out the text coloring options in Word? No, because people utilize those colors for a reason. I agree that giving users the ability to add their own color coding on top of syntax highlighting in a text editor would be very confusing, but that isn’t what is happening with this patch.
The goal is the same to make things stand out, to make it easier to figure out what the hell is going on. By the way my idea of a tag based themed wireframe color yes would be able to do all you describe . I know how to do it, cant say how long because I have no clue about the Blender internals (I know how to make blender addons but I am not a C coder and never read the blender source code).
See I am a developer so I have a rough idea what is possible to do with software , if you are not a developer its very hard to know what is possible with a software and how it should be done. This is why developer very rarely ask users for opinion on features.
I fail to see how having no custom colors is better than having custom colors. If Ton wants to outline exactly what he has in mind, then maybe it might be worth waiting, but from how I have heard him describe it, I’m not sold.
Yeah I know you fail to see I think this has been crystal clear from your whole post but as a developer I can tell you there is nothing worse than rushed code. Its code that is ugly designed, limited and a pain to upgrade later on. For a user the faster the better, for a developer the slower the better. Of course users always end up using features that are well though and beautiful designed.
For example I have to confess my first reaction to the blender cursor was disgust , now you can take it away over my cold dead body.
So following the crowd is definitely not the way to drive progress forward. So I say wait for Ton’s implementation maybe , just maybe, he will make it worth the wait.
yeap exactly what I mean, actually tags go way further than colored wireframes and they can help with organising any kind of complex data in massive numbers. Actually the conference had a talk by a Scientist visualisation molecular structures of the brain and had the exact same problem huge amount of objects in a scene with tons of data each , big mess because blender has no serious categorisation system. Definitely an are where Blender will improve as complex scenes become more and more usual.
You are confusing things with the analogy, mixing subject and action. Rule based systems are fine for finite types like code syntax. Wireframe color is a property of an object and should not be limited artificialy. Its like saying lets limit the scale to 400% or X.pos to max 1000, because hey as a coder I think its fine.
I’ve been playing with the patch, and I made a rambly scatter brained video with thoughts. It’s not perfect, but works pretty good in most cases, but I still need to mess with it more.
Agreed, someone pointed out many pages back that adding color wireframes is a bandaid on the broken leg that is Blender’s organizational tools. Even some hypothetical theme based objected coloring would only go a small way towards addressing these issues. Nonetheless, these bigger issues are somewhat orthogonal to problems that are solved by a basic implementation of colored wireframes.
A simple object color property that solely effects viewport rendering would satisfy the people who want full control to set each object’s color as they see fit. This simple implementation would also enable theming via simple Python scripts. These themes could be as simple as automatically assigning an arbitrary color to each object (example themes like this have already been posted in this thread). More advanced themes could assign color based on various semantic information like object types or names that might have specific meaning within a given facility. In fact, to me, it seems likely that most useful themes would be facility specific, as described by SterlingRoth.
Basic completely manual control over viewport object color does not exclude the use of advanced themes, it is a prerequisite for it.