Blender Edit Mode Performance

General Forums Blender Development Discussion
1547

Yep, that’d be long overdue.

The list is pretty long, weight painting performance, mesh/surface deform and other modifiers not using the gpu (as opposed to lot’s of other softwares), simulation speed, editing in general, no anim cache, even shader node editing (even moving the nodes) getting annoyingly slow in large scenes.

Can’t do much except waiting. To be honest I’m fairly happy with Blender right until my scenes get big or meshes heavy. Past that point I loose way more time optimizing than I’d like.

7 Likes
1548

I think Blender needs own benchmark, like they have for cycles, but actualy useful - test file that performs macros like, viewport rotation, Edit mode selections and actions, heavy modifiers , sculpting strokes across heavy model and at the end shows how many minutes it took, memory and average cpu/gpu usage. That would be definitive way to argue about performance.

10 Likes
1549

The long list is possible why editmode performance hasn’t seen serious attention yet, because in the last year or so the devs. have been fixing various performance issues like in the undo system and in the UV/image editor.

However, this is being slowed down by the fact that we were promised a well defined roadmap and better organization for the Blender project, instead there were cases where old-school organic development (which rarely produces anything that satisfies professionals) was preferred to their own roadmap items.

Blender 2.9x has a mind-boggling number of features now and has (on paper) nearly everything a professional could wish for, I do think it is time for the devs. to slow down on the new stuff and begin a heavier focus on polishing and performance. The only exception to this would the Everything Nodes stuff which is also needed to replace the old and dusty particle system. With 20 devs. in the core team now, performance could generally be well above 2.79 in everything by the end of the year if the BF would stop being so FOSS in some of their decisions and step up to the plate.

As of now, the single biggest thing separating Blender from Autodesk solutions (in terms of professional viability) is performance. Autodesk isn’t willing to change their licensing to encourage a mass exodus from Blender, so the BF needs to take advantage while it can.

5 Likes
1550

The image editor speedup was pretty impressive. Undo was a solid start but I hope that’s not labeled fixed yet :slight_smile: .

I guess this is where it can become tricky. Obviously I’m no coder, but with many other packages focusing on using the GPU I fear that better performance for certain fields like simulation, particles, modifiers and so on might be a bigger endeavor than one might think.

I agree though, I’d much prefer the kinks ironed out, and catching up on the performance end.

1 Like
1551

As a long time maya user, I find blender edit mode usually better. Of course, max is way better but maya is really slow in that area.

Maya is only way faster when using subdivision. This should be the main issue developers need to tackle when it comes to performance in my opinion.

3 Likes
1552

That’s why no one should model in Maya.

1553

Performance got better in 2020 and 2021, and it’s alright for doing retopo but ye, it’s not exactly lightning fast (for modeling).

1554

Not only animators.:slight_smile: Also for modelling subd performance was much faster in 2.79.

2 Likes
1555

Looking at their planning as it is currently visible to us (https://developer.blender.org/T73360), the next main subject would be (Minimize GPU Transfer Overhead). Knowing that Clément is currently working on Vulkan, I wonder whether this has consciously been pushed back, such that it can be handled properly in Vulkan.
I don’t know whether this is actually the case. However, it appears reasonable to me and personally, I would agree with such a decision. At the same time, it would mean that their public communication needs to be improved.
I know from experience how difficult it is to keep everyone up to date internally. It is not getting simpler, if huge parts of the planning are public. It is unavoidable for those to be lacking behind, unless there are more or less continuous update reports or something like that.

1 Like
1556

Making “GPU Transfer” faster is not a solution.
It is just an workaround.
What it need to happen is updating only the data that changed in smart way which requires pretty heavy commitment and expertise.
I doubt this would happen anytime soon since Blender developers focused more on adding the items on the releases list than making solid fundamentals.

1557

It is an open source project. They get code contributions from outside developers, so regardless of how the devs spend their time, there will always be new features.

2 Likes
1558

There is no problem of how many features are there or coming in Blender.
The problem is how many of them are usable in production.

3 Likes
1559

That is a optimization that would be categorized as “GPU Transfer speed” work.

1 Like
1560

It need to happen in bmesh level even before transferring to GPU.
Whereever it happens, it is not a simple task.
It requires years of multiple dedicated developers .
It is unfortunate that it was not there from the beginning.

1 Like
1561

I also think we deserve an update on this. I’m the first person to defend the development team when it comes to projects being vaguely postponed, but I think this is taking too long. Has it even started ? the task page is the vaguest of all. The benchmarks speak for themselves, there is a real problem and it has to be worked on.
@dfelinto apologies for the ruthless ping, can we please request an update ? is this not a showstopper issue for Institute artists ?

6 Likes
1562

Yes of course. I never stated otherwise.

1563

According to the development task, what you are referring to is mostly covered under Milestone 2. What I mentioned is a large remaining portion of Milestone 1. Usually when when such tasks are structured in this kind of manner, there are technical reasons for the order. I don’t know whether it is the case here as I don’t know the relevant parts of the code.
As the GPU Transfer takes a huge junk of Milestone 1 by the developers, it appears to be more important than just being a workaround.

Being busy adding new functionality like Vulkan might indeed be the explanation here, though that would be a fundamental one.

1 Like
1564

Well, it looks like he was occupied by Depth of Field refactor, this month, trying to respect roadmap to include it in 2.92. But that will not be the case.
2.92’s EEVEE feature will be support of Cryptomatte and AOVs.

There is no doubt there is a delay compared to what was scheduled.

Workload induced by 2.8 codequest design was underestimated.
Technical debt accumulated during previous releases until 2.79 and not solved by new design was underestimated.
Increase of community members and amplitude of pertinent feedback that is calling a reply, as a result, were underestimated.
Communication and reorganization needs to welcome new developers were underestimated.

In spite of that, I found pretty amazing that they succeeded to deliver roughly what was announced during one year, by postponing only few features per release and introducing some stuff as first milestone.
But now, that can not be hidden, anymore.

People were not expecting gizmos in 3D view only for few tools.
They were not expecting retopology improvements limited to Quadriflow.
They were not expecting a buggy Mantaflow and UDIM that were not supporting baking.
They were not expecting just a Volume Object but also promised Hair Object, too.
They were not expecting Geometry Nodes but particle nodes.
They were expecting better performance with huge scenes, motion paths improvements, painting improvements…

There is no doubt all those lacks will not be filled after this summer.

2.93 and 3.0 will not look like what was expected at all.

If they want to provide a solid Blender 3.0 release ; they probably should postpone it, to next year and make 2.94,2.95,2.96 releases dedicated to performance and polishing.
Otherwise, people will continue to say that Blender 3 is worst than 2.79 for performance, not just UI and UX preferences, and that would be true.

23 Likes
1565

I have missed that, thanks for the info!

1566

well said! they need to focus on performance releases after the 2.93, for god sake stop adding new features, invest your man power on performance improvements

14 Likes