Blender edit mode performance problems. Updated: kind of resolved

Hi guys

I have a model with ~695k tris. Modifier stack are emply.
Just selecting polygons/edges or vertex took approx 1+ second and more. And i mean just selecting 1 single poly/edge/vertex, not even loops or something like that.
FPS in the viewport are unknown, but its really high, no slideshow or something like that.

My specs are:
3900x, 64Gb RAM, which im pretty sure normally more that enougth for ~700k polys.
WIndows 10, all latest updates, drivers, motherboard BIOS.
GPU are pretty weak, its a GTX1060 3Gb, but again FPS are high, and i dont think what GPU can cause those problems.

Blender version are 2.91.0 downloaded from official site.
Preferences are default except UNDO levels (set to 64).
Memory cache limit doesnt change anything, and i guess shouldnt cause task manager shows what blender use less than 2Gb or RAM.

What i was trying:
Setting priority for blender to High - didnt change anything.

Wow, @SoundDifferent! That is a wonderfully detailed support post! First off, I just want to confirm that the only thing you see a slowdown with is selecting, correct? There is no slowdown while navigating the 3D Viewport, correct?

Next, there is a setting in Preferences under Viewport - Selection to use OpenGL to perform selecting. Can you try to enable that setting and let us know if there is any difference? Here is a link to the manual page for that setting:

It’s not your hardware, it’s Blender. That sad performance in edit mode is just what we get, at the moment.

1 Like

Yes, its only selecting. Navigation in edit mode are same (for eyes) as in object mode. I cant feel any differences here.

I check those OpenGL settings. I guess its enabled by default. Uncheck it doesnt change anything.
Im also try to uncheck > save preferences > restart Blender just to be sure. No differences.

More of that:
Also i notice what sometimes selecting are happened way-way faster, almost instantly. It can happen after you open and close Preferences, or even alt-tab from browser. Its super wierd.
Any ideas? :slight_smile:
I will post a link to video when its converted on youtube.

Here’s the video. Still converting, but anuway its clearly show those wierd behavior.

Maybe there some problems with drivers anyway? Cause im on clear WIndows installation.
Im install recommended GPU drivers from GeForceExpirience utility, and its GRD version (Game Ready Drivers). Maybe i should switch to default one?

I know what Blender have many performance issues but… i dunno its really-really wierd. I can understand 2-3m of polygons but 700k its really not that much.

There’s nothing weird at all. Edit mode wasn’t designed for handling large amounts of geometry efficiently. A small part of it is already solved - at least as far as navigation and redrawing is concerned (compare viewport responsiveness in edit mode with the same mesh in 2.79b). All other parts still remain to be done. Someday. Eventually. Perhaps.

1 Like

Intheresting update

i remade those mesh which you saw in video and realize what performance are significantly better!
Polycount are the same.
Only differences between the two is 1 vertex group in object data in previous mesh. Vertex group was containt ~23к vertices.

Just deleting vertex group* INSTANTLY change how fast blender select polygons/edges/vertex on the mesh.
Its still laggy but its anyway a HUGE difference.

Now i wonder - why? From the user side, vertex groups are let say “static data”, i.e. it doesnt update every frame/tick, its only updated when you assign or remove something from there.
Why vertex groups create that performance drops?

*deleting means: we not remove vertex from vertex group, we click on “-” button and remove vertex group .

1 Like

Everything is always so simple from the user side…

When you change selection, the 3D view needs to be redrawn. It’s done in a deferred fashion, meaning that any panels that are redrawn because of it do not possess the same data as the select operator. If there are vertex groups, the whole selection has to be looked at again (i.e. the whole mesh needs to be traversed) to see how many verts are selected (whether to draw the vertex groups panel in the side bar), active vertex needs to be found and for it - all vertex group data extracted to display in the panel. There are quite a few other things that go on under the hood as well.

I’ll reiterate, again - current edit mode was not designed for efficient work with large amounts of geometry. That is the answer to all “why so slow, why such differene”, etc. questions.

1 Like

That sounds like a bug to me. I suggest creating a bug report and sharing an example blend file here:


Okay did you write this as a blender dev crew member? Cause despite the fact im not a software programmer, the needs to look up at data which containts in vertex group every single time when we just selecting polygons - doesnt see reasonable and correct way to me and anyone :man_shrugging:

I think Stan maybe right and that your issues are considered «normal», having said that my computer specs are worse than yours and I get much better performance with 786k model (even with a 50k vertex group assigned). I start to get a lag like yours at about 3,000,000 vertexes.
Deleting the vertex group does speed it up.
My specs i7 -3770, 32G RAM, GeForce GTX 650 Ti (1G)
This might be due to the fact I use Linux (opensuse – xfce) but it still seems a big difference.
Edit: I only had one object in the scene.

I heard what blender on linux works a bit faster, maybe thats the reason, i dont know. Anyway, what version you are using?
I was trying 2.82.a and 2.79b - same results.

As I edited I only had that one object in the scene I do not know if you have more going on in your file.

I have tons of objects in the scene, but its defenitely not the reasons of lags. When i try 2.82 and 2.79 i just copy&paste only 1 object. So in scene with 1 objects performance are the same.

I’m not the Blender dev crew member, no. I am a programmer though, and the source is right here. All two million lines of it (give or take). There is a lot more going on during selection than, well, just selection. Even beyond vertex groups. I just gave you the scant summary. Vertex groups and the need to access them aren’t the actual problem here. The way the mesh data is organized and traversed is.

Just for comparison, enter the sculpt mode on the same mesh and use some sculpt tools on it. You’ll see a drastic difference in responsiveness. Even, say, draw a mask on it, which is, from “user perspective”, selection. It’s not going to lag the same way the edit mode does. That’s because the sculpt mesh is organized and traversed in a different fashion. Which is, partly, inherent in the way sculpting works, but most importantly because it was (and is) actually actively improved on.

Whether you see it as reasonable or not, it is what it is, and is going to stay that way until someone does something about it. I dunno, maybe they need to make the next movie with dense editable geometry to nudge that mountain. They kind of have big plates as is though.

If your mesh has a lot of geometry, you can hide part of the mesh, in Edit Mode, that you are not working on.

it doesnt change anything in this case. Absolutely same performance on selecting.

Now that doesn’t make sense to me. That’s a bummer.

It won’t make a difference for selection. Geometry isn’t segregated into explicit, distinct hidden and shown sets. It’s done implicitly in the same data (that is, it’s just a flag for each vertex/edge/face). In other words, hidden geometry is still looked at during mesh traversal. And it should be.

1 Like