Blender Edit Mode Performance

Always turn off adaptive degradation:P. Editable mesh is pure prehistory, still, sometimes faster than editable poly. Using modifier as simulation of multi edit is not exactly fair. Oppositon on beta forum? Tell them to fix edit poly modifier:P

1 Like

Did you join a few hours ago just to post about Max specifically? :rofl:

1 Like

Yes.I like to read, but…

FWIW, for me subdiv modifier with “Use Limit Surface” active adds 20 seconds to going to the second subdiv level on a 3950x. Considering that option is active by default, that’s a lot. Blender 2.92

This is a simple tissue dual mesh, 18.500 verts

1 Like

If your mesh isn’t going to ‘shrink’ when subdivided(i.e - creases/control edges maintain the baseshape) then you can disable it. It’s just a workaround though, as Limit Surface is a key feature of OSD and you shouldn’t have to disable it. Another example of why OSD has been poorly implemented in Blender.

Blender is the only DCC that doesn’t have its own native sub-D algorithm. What was here before OSD, and why was it removed? I never used Blender prior to 2.80.


It was removed to not have to maintain 2 time the code that do (‘on paper’) the same thing.
It’s not just about subdiv it also multiresolution modifier that use also OSD now.

In it’s crappy implementation OSD was significantly faster in 2.7* than native subdiv, because it uses some GPU accelerations. There was some downsides, I’ve tried it but never used it in productions because of that, one of them was that there was a lag when geometry was uploaded to the GPU (like going in - out edit mode) . It’s not the case anymore in current implementation.

Probably devs assumed that OSD would be faster and better than old implementation, getting rid of old subdiv was propably easing the process and also it would have been more complicated to get rid of the old subdiv past 2.8 because of compatibility this second modifier would have stayed for a very long time (because old subdiv and OSD doesn’t give exacly the same result) and they probably would have needed to be both maintained. 2.8 was the perfect time to get rid of old subdiv but it turned out not as good as it should be.

If devs could have seen the future and that for now OSD is slower, they probably would have done it differently. I’m confident that with time all this will improve, it’s just that it seems complicated to optimize mesh handling as it’s the core of blender and it’s impacting most parts of the software.

I’m sure having this thread , doing proper tests and providing tests files is a good starting point and raise awareness around the subject.

They don’t go to BA very often since a very long time, I’m sure they aware of this thread anyway.


If you manage your project properly, you don’t need a high poly count.

1 Like

This post was flagged by the community and is temporarily hidden.


This kind of argument is what the old guard used to use when they argued against everything from Ngons to raytracing. High polygon counts may not be needed if what you are doing is rendering minecraft scenes or doing low-poly art, but it is quite common for today’s CG scenes to contain millions of polygons at minimum. If the editing tools are sufficiently advanced to work with dense topology, then there’s no reason to not have editmode see the same performance boosts received by many other areas since 2.79.


You’re right, and when you need to do some high poly work, just use Maya or 3ds Max, the right tools for the right job. For texturing there’s also Substance Designer and Painter, and for Sculpting ZBrush, perfectly valid alternatives to Blender.

1 Like

To be fair, veiwport performance is an issue in most apps these days. XSI tackled it early with what was I believe gigacore or something like that. Maya is actually only slightly better than Blender. And for animation, rather then rebuild the app at the “core level” they leveraged the concept of caching animation to speed up performance. This is an idea that Blender could probably leverage as well. Won’t help edit mode for modeling. But this is no small task as I understand it. Even LightWave had this issue which was addressed by the Hydra core which it is supposed to have now. So what I am saying is that Blender might be bad. But in component mode Maya also has issues and is only slightly better.

What Blender needs is a major development effort in this direction. It is no small task or small trivial issue.


Even without caching, Maya animation playback is far better than Blender. Caching is essentially an workaround. That’s the option to be used when there is nothing more to try.

But, Maya sucks at modeling performance. In fact, I don’t understand why anyone model in Maya.


I would find it hard to make that an unqualified statement. Far better with our without subdivision level? Many people making this statement might just use the default Subdivision Surface Modifier settings.

It is also not as much as the viewport at this point as it is the speed of calculation of the modifier. Probably for non-subdivided objects I would say Maya is still better. But you’d have to be more scientific and compare model by model. Subdivision on or off and other factors to say Maya is far better - showing frame rates.

But the point is, Maya is still not fast enough. And this is the major criticism: Cache is a workaround, yes… And it speaks to the point here. Improving viewpornt performance is not a trivial issue. As far as I understand it would require a complete rewrite of Blender at a very basic level to accomplish this. And this is why they didn’t do it in Maya. And it is part of why LightWave development failed. It is not a trivial - “oh lets just focus on this now”. It is a potential show stopper if you don’t allocate resources.

I hate to use LightWave as an example, but it is a perfect case because it illuminates what can happen if it is not taken seriously at the management level.

And very few apps have been able to pull that off so deep in development. I actually don’t know what it would take for Blender. This is just an educated guess that it would be a major decision that would effect - and possibly even stop - all other development until it was done.

By the way, the absolute best animation performance I have ever used was MotionBuilder which pretty much smokes anything. But then again it was designed for animation from the ground up. Blender and other apps have not been. Another close contender would have been Messiah pro which was also build specifically for animation.

Gigapoly was WAY ahead of its time. Even 10 years ago the performance was better than most DCCs today. Max has the best modeling performance, but it took alomost 10 years of constant dev work to get to that stage, and it’s still far from perfect in a lot of areas. Blender UI still feels a lot snappier and more responsive than Max and Maya for general UI day to day. The material editor, for instance. Max’s Slate editor is over 10 years old and badly in need of an overhaul. Maya HyperShade is ancient, and even with the cosmetic facelift it got a few years back, it can be such a pain to work with.


Please be an editmode performance improvement. Please be an editmode performance improvement.

No description, but this patch by Campbell was dropped onto the developer site this evening. I do not know exactly what it does, so it may or may not be relevant for this thread.

1 Like

Don’t hold your breath… this looks like a fix for this… :thinking:

Hi, this thread is very long, can someone please tell me is Blender working as it should for me or something is wrong?
I have an RTX 2080, Ryzen 7 2700, 16 RAM, but I can edit only meshes with less than 60k vertices without any lags. 50 - 60k vertices seems to me unacceptably small for a modeling software. 400k mesh is a slideshow. Just a subdivided mesh without modifiers. Blender 2.92

There are plenty of aspects to it and there is no simple answer. Edit mode was faster in 2.7x and it should not have been getting slower after that. That’s clearly an issue. Even though the developer started to address the issue, it seems they underestimated it and couldn’t resolve it yet.
However, even the 2.7x performance was not outstanding. So getting better performance than that is likely even more complicated.
You can also add the subdivide modifier to the mix which was a lot faster in 2.7x and didn’t make use of the GPU after that.
(Hope I somewhat correctly summarized the situation. Anyone is welcome to correct me if I messed something up!)

As always, there are things that need to be improved. Though, this is for sure very uncomfortable for quite a few people. Whether you want to say that something is wrong with Blender because of that is quite subjective in my opinion.


Does it happen with any scene/mesh?
For example, what is the fps number (play animation) you get while constantly Grab this vertex?
90k edit mode.blend (4.3 MB)