Not sure why they would need pressure. According to the roadmap, performance is a very important topic in several modules. When it comes to modelling, “Fast Highpoly Mesh Editing” and “Open Subdiv” are both on the list. Even if they were delayed, it would still be clear those sorts of topics are very important for the core developers.
3 Likes
The only thing we need is gpu acceleration open subdiv ,this is the most important feature
2 Likes
I wonder if it’s out of the question to hire someone dedicated to increasing performance. Right now, it feels like different people will tackle parts here and there to speed things up when they have time in the midst of their other projects.
1 Like
For performance improvements, it is usually necessary to understand the code quite well. That’s why I believe, it wouldn’t make sense to hire someone for the current performance issues, as they seem to be from different areas of the code.
I don’t know how they manage themselves exactly. However, it is the not unusual in my experience that developers work in one area and after a task has been finished, they are working on another one, possibly quite different one. In my experience, working like that often gives better results.
One way to organize performance related improvements is to treat them like a major release on their own rather then just being “scrapped” here and there, in that all module owners (or those that really are in need of performance boost) focus ONLY on performance related development.
Something similar to this:
- bcon1: New features.
- bcon2: Stability & improvements.
-1st bug sprint -
bcon3: performance optimization.
-2nd bug sprint - bcon4: polishing & final tweaks
- bcon5: Release.
This might take a few extra months per new blender release (1-3 months) but it would insure a much more healthy development cycle where each new release is running Smooth, Stable and clean.
Think of it like a car on a never ending journey, if you keep adding more and more baggage while neglecting the tires and engine it won’t go far…
2 Likes
According to roadmap, they plan to focus even more on performance in the upcoming releases.
Your suggestion is interesting. From my point of view the “Performance Optimization” would need to be bcon2 and “Stability & Improvements” bcon3. Optimizations are often the cause of bugs, that’s why they clearly should be handled before the stability bits.
At the same time, I am not sure whether bcon2 isn’t too late. Optimizations require often a deep dive into the code, possibly refactorings and not just minor changes. So it wouldn’t be possible to work on larger topics and after a few iterations, you would likely run out of low hanging fruits.
That’s why I believe, it makes more sense to handle optimizations in the currently planned way. They work on them, add them during bcon1, maybe bcon2, and treat them like everything else (except for bugs).
Around 2012 the 3dsMax development team introduced a new dev route/revamp for Max called ‘XBR’. This was when the Nitrous viewport(that regularly gets raised a a point of performance reference) was introduced. This ‘XBR’ initiative almost killed Max entirely as a product and it’s only now in the last 1-2 years that the devs have started to bring Max back to life. It’s taken 8 years to reverse a lot of that damage and there are still performance issues that beta users regularly complain about. Max’s undo buffer/flusher was broken for years, the Nitrous viewport broke all the existing DirectX game lookdev shaders(best around at that time), and even today - despite the eye candy promo vids you might see - is an outdated ‘deadend’ technology regarding modern PBR. The material editor in Max is also ancient and slow and it could be years before it’s rebuilt. The modeling workflows are old and clunky compared to Blender and that’s currently being overhauled(will also take years)…
My point being that it took Max 8 years(and counting) to reinvent itself, and there is still a LOT of work to do, but yes, performance is so massively important. You can have all the bells and whistles, but when vital areas of the program are sluggish it’s a big red flag. The roadmap addresses this, but oftentimes users are impatient and expect miracles. My anecdote above is to put that expectation into perspective. These performance issues can take many, many years to eradicate, and are always ongoing even at that.
4 Likes
Because it was an old plugin NodeJoe made by one person. Autodesk Just bought that plugin and there were no any improvements to it since then.
Yes, Slate certainly is old. I’ve been dealing with it for as long as it’s been around 
They’ve made a handful of tiny tweaks.
Ironically, Pflow, MCG, and Bifrost are all using the new Adesk Slate GUI SDK, while Slate itself isn’t.
I did a quick text with a 600 000 poly mesh in edit mode with soft selection (Geforce Rtx 2070, win 10)
Blender 2.79 : 6.6 fps
Blender 2.80 : 1.75 fps
Blender 2.90 : 3.9 fps
Blender 2.91 : 4.1 fps
4 Likes
//Mod work:
Is it necessary to rename the title of this thread? Talking only about 2.8 is outdated.
Thx
It could be also renamed just “Blender Viewport Performance”, after all the comparisons are made based on 2.79 performance as the “peak” with tests made on 2.8x and 2.9x and will probably keep going for 3.x and up (the thread is more then two years old with 1470+ posts).
5 Likes
Yeah. We will only be having the same conversation of changing the title name next year when 3.0 will become more relevant.
2016:
„… Three pillars of this project
- [Performance and responsiveness]
- [Task appropriate shaders]
- [Integration with external engines]
https://code.blender.org/2016/09/blender-2-8-viewport-development
2020:
Objectmode is better now but edit has even still much lower performance than 2.79 (which was already bad)
Iam afraid this thread will accompany us for longer future times.
If there was a funding just to improve raw mesh editing viewport performance, I would join✌️
8 Likes
NodeJoe in reality were 2 guys, that sold the plugin and they start working for Autodesk. They developed a new node editor, only used in pflow, and some tiny bits in MCG (and now Bifrost). They also spent a lot of time on the Qt porting of the UI. I’m not on par of the new developments of Max, but don’t remember at least to the public of seeingany plans for address any of the material editors (which are dinosaurs now).
NodeJoe was actually cool for it’s time I used it then. Don’t know if they have anything to do with maya’s new hypershade. Because it was bad, but somebody in AD put some tremendous effort to make it even worse.
What fund? They already have $108k monthly fund ,
This is more than enough ,they need to dedicate one or two developers for that task , but it’s seems performance it’s not in theyr priority 
3 Likes
I doubt blender would have enough funding with even twice that amount. Supposedly maya has 30 full time devs working on its team.
The fund it’s pretty impressive 
, before blender 2.8 blender had only $7k monthly fund
That’s just relative to what we had before. Blender development never really had much money to work with. I remember when I first started learning blender it was something like 5500 euros a month. Anyway, while they do seem to be able to pull off a lot with little funding, it still falls short in terms of the development power maya supposedly has.
2 Likes