Blender Edit Mode Performance

More features ? sure, but at least have the base package working as intended, and then think about extra “nice to have”. (when there are enough dev. members to cover the base).

Geometry nodes, Asset Browser and the likes are core features that blender is lacking, whereas line art, greace pencil, VR are in the “nice to have” category (just my opinion again)

let’s be realistic here, who would want to put a VR headset for 4-8 work hours trying to create stuff ? how many games were published using blender game engine ?

1 Like

Although grease pencil is a nice to have(This debatable), It is almost entirely community driven with only one of the developers being funded by the development fund.


There is a lot of secondary benefit to grease pencil, the fact that it attracted a lot of 2d artists and studios, means more exposure and more funding to blender… and the reality is a lot of work is being done by volunteers who are scratching an itch, blaming the BF for work done by them is not logical…

The same can be said about the open movies, a lot of people keep saying they are a waste of BF resources, that Ton likes to make movies and is abusing his position. The reality is, the open movies have been immensely successful in generating PR, in guiding development, and in generating revenue and documentation. Most people who join the Blender Cloud don’t do it as a way to fund Blender, but to have access to the open movies assets and tutorials…

Frankly, the BF have no way of knowing for sure which feature of blender is ok to neglect, without losing numerous users and their funding or even just the bad publicity from a lot of them.


“Working as intended” is vague. Who decides that? Edit mode was working as intended, more performance is “nice to have” - that could be opinion of many users.

Geometry nodes is not “base package” in my opinion. While other DCC like Maya have nodes it’s not really all that useful or necessary, you can perfectly live without them.
On the other hand, Grease Pencil recieved very well as storyboarding tool by animation studios like Ubisoft. That’s not just some opinion but practical implication. I don’t use it myself but I personally see it as one major entry point for Blender to become “industry standart” along with concepting.

The point is, Blender used in many, many ways and users will think that what they’re doing is main usecase of Blender and should be prioritized. Hence there are no “main usecase” for Bender but a set of usecases with no particular order of importance.


The auto-smooth normals speed up patches were committed :grinning: .


I don’t see any speed ups after this patches to be honest, if anything a loss of 10% :frowning:

What CPU do you have ?

Intel I7 4770k…

Did you compile your own master? Because the patches aren’t in the Buildbot builds as of now.

Yes I compile on windows

There was a revert change of a major opimization patch earlier this week, maybe thats why?

Yes, I have 3 versions, the one before the revert, the one before auto-smooth normals patch from yesterday, and the one after. No improvement on this patches. Maybe I need a 20+ threads cpu to notice any improvement…

Maybe the curse of multi-threading? Multi-threading can actually slow down the task if the data to process is not enough.

The original iteration of the patch (which was not the one that was committed) saw editmode become slower for meshes with under a million polygons, but it was significantly faster when very high polygon counts were involved.

Sergey and Bastien though took issue with it, because the number of polygons that were needed for users to see a benefit was far higher than what is seen in the average model outside of sculpting. I believe the version that was committed had significant tweaks based on feedback from them and Ravi.

There are cases where a balancing act comes into play, because code that can boost performance for huge amounts of data can actually slow things down when the scene is simpler. It helps for making film-quality assets (which good performance for is where we want to get to), but not for low-poly stylized modeling.

1 Like

Sounds like a justification for having those additional modes and object types for specific use cases.

1 Like

That’s difficult to judge. I have implemented plenty of algorithms where I could say with certainty that the previous version is faster below a certain threshold and the new one above. Usually when that happens, the threshold is not absolute and heavily depends on the hardware. But it also happens that there is hardware where one of the versions is always clearly faster.
Optimizations can be very ugly. You need a very strong case to get a justification for an additional mode.


Did anyone test with the latest and greatest?

Here is a quick comparison with a previous v3 alpha build BEFORE the autosmooth performance patch, and the latest build.

The improvement in performance is quite obvious.
(without autosmooth it is still a fair bit more performant)




Wait a min. I thought only 1 change was reverted. Are all those 8 changes reverted?

Yes since those commits were based on initial “ID_RECALC_GEOMETRY_DEFORM” commit. Many of them are fixes of bugs caused by initial commit so it’s natural they have to be reverted.