Ok, here is just my take on how this feature could be implemented.
The patch goes into the trunk pretty much as it is now. But the feature - user chosen coloured wireframes - is not turned on as default. And the feature tells that it is experimental, to signal that it is a feature you should be careful with.*
Then, later on, the feature can be expanded if necessary. It then includes a second mode, were the user only have a limited palette of colours to choose from. (Full range of colours are still a option).
At the same time as the feature gets expanded (coloured wireframes), the Blender theme will also get expanded.
In the place were you can choose your viewport colour, there is now also a second mode. It also have a limited pallete of colours to choose from, but these colours are not the same as the colours on the wireframe colour palette.
The coloured wireframe feature now stops with being labelled as experimental.
Personally, I donāt think there will be any trouble with this feature in reality. But if it makes people happy & feel more secure - letās just call it experimental.
Had a discussion with Ton and we will move forward with improved wire-frame display - most likely extending themes but also supporting customization, but not immediately. (I didnāt take holiday ~2 years, so will have a coding holiday for July).
Later this year Iāll be working for some months at the Blender Institute and then is probably good time to sit together and try different approaches.
Iāll work with Pablo Vazquez (VenomGFX), (who recently joined UI team) and we can plan this, test with artists in studio.
Pabloās worked on complex scenes before in a team and had to debug issues in Blender too, so I trust we can design something together which works well.
I realize this is all a bit vague, but we donāt plan exactly what to do right now, I like if Pablo makes a plan, I send him patch - he tests with some of his projects and we iterate a bit first before announcing anything, since its not really working so well to get feedback here, though there has been some very useful feedback too, which weāll take into account.
Iām glad to hear the BF has decided to devote some resources to this. Why not open a Design Task to nail down the conceptual details before coding begins? Isnāt that exactly what they are intended for? Having something in the tracker would also probably help assure the people who have wanted this the most that it wonāt be forgotten and that the design is progressing in a way that will meet their needs.
Good news.
Just open a development study is a good news.
Personally Iām not in hurry to have the colored wireframe viewport, Iāll wait. Itās important youāll development something. I canāt imagine it could be worst than now (in terms of readibility of scene with many objects).
Whether or not to open a design task is up to you. I just tend to think that Blender as a project would benefit from better communication and having tracker items for planned work seems like a pretty easy way to do that.
Personally, Iāve never understood the projectās reluctance to use the tracker for long-term TODO items, but I guess thatās a matter of preference.
@jedfrechette - the problem if we open a lot of design tasks which we donāt intend to work on, or allow anyone to open design tasks - is we end up with many pages which are poorly maintained, someone has to keep this in check, close tasks which are completed, reply to tasks, update them if blender changesā¦ its just overhead if we open design tasks a lot more.
So it keeps things much more manageable if design tasks are active issues someone is working on.
Donāt you already have this, theyāre just split between the Wiki and the Tracker? If everything was in the Tracker at least they would all be easily searchable in one place. Keeping things organized does take time, but a lot of those janitorial tasks are the type of things that, with a little instruction, could be delegated to inexperienced contributors.
@ideasman42:
Having listened to your opinion of us in the podcast, I know youāre probably going to take this negatively, but I think it needs asking anyway.
How long before the community should start pushing you on the feature again? This particular feature (custom coloured wireframes) has a decade long history of being implemented by someone, being rejected by BF, unhappiness expressed by members of the community, a plan expressed to look at it laterā¦ then forgotten/abandoned again. Iād rather not ārinse, repeatā that again.
I know this isnāt a feature that motivates you, but it does motivate us. As such, and given your plans, what is the timeline between now & when you plan to be actually working on it? Looking at it from the perspective of those that have watched this feature come & go multiple times, it shouldnāt be hard to imagine how we might find it hard to take the idea it is simply being delayed at face value. I donāt think that is the case at the moment, but a timeline on when we can expect to see action (and the ability to raise this thread again at that time) would be appreciated if possible.
@jedfrechette - we can move issues from one place to another, in this case donāt think it helps, also I didnāt see much evidence yet that less experienced contributors are more likely to help a lot with janitorial tasks.
@BTolputt - Iāll be at the blender-institude ~3 months this year, soā¦ this year sometime. This depends a bit on Pablo too.
@ideasman42: Appreciate it. I shall refrain from nagging you until Christmas holidays or the current patch becoming unreasonably difficult to keep up with current trunk (whichever comes first).
That said, Iāll still discuss the feature and the matter which prompted yet another reincarnation of it, Iāll just not be pushing you for action on the matter.
Most of the people working on blender do it out of passion. They really enjoy it. Problem is, there is a lot of maintenance work that must be done that is not āfunā, but somebody has to do it for the project to be successful. A ācoding holidayā is basically a chunk of time where devs can work on what they WANT to work on. I personally get very excited when these guys go on coding holiday. Yummy treats usually follow!
Coding holidays are good both in & out of open-source work. I occasionally have them for desired improvements in my commercial work.
Whilst the Blender Foundation needs to hire developers for the drudge work of maintenance, features that are unexciting but need implementation nonetheless, etc - the best developers are those motivated by passion and they need time to do what gets their creative juices flowing. If you keep people working only on the drudge work, they lose the passion for the project and you either need to encourage them to stay with money or the leave for better pastures. In the open-source world, whilst there is the potential for reasonable monetary incentives, they are few & far betweenā¦ so ācode holidaysā work to help retain developers working on both the exciting and not exciting things
first, sorry I have yet not read through the whole thread but I had raised a request some time back for hidden-line(hidden-wire) mode as one of the shading optionsā¦ See āhttps://developer.blender.org/T37531ā which was closed by bretch.
Now that since campbell is working on the wire-colours, I thought This might be incorporated as well.
In my opinion( and also of my colleagues) , this (hidden-line mode) is a must for serious matchmoving/ rotomation tasks.
Hidden Line mode( or hidden-wire ) is currenly only accessible in Edit mode.
Since the advantages of this are unclear, or even what implementation of it you are thinking of, it would be best if you started another thread to explain it and get feedback. Please leave this thread to discussions about Col Wire, which is sufficiently controversial that Campbell would never tack another feature onto the patch (as he has said before) and it would make things very confusing when submitting the patch for approval.
I have a queastion about Blenderās wireframe development =)
Blender can draw aesthetically pleasant thin good-looking wires - even without multisampling
(background wires, when Limit selection to visible (LSTV) feature is turned off)
Is it possible to make this thin wires optionally main, when LSTV is turned on?
Image
Left image - LSTV is off, default shading with thin background wires.
Right image - Option, when thin wires becomes main when LSTV is on.
