Will be perfomance a main target in 2.81?

Getting a pretty nice increase in edit speed in the latest build (cb7ead2e3b62) cube subdivided 8 times, applied, 5.2 fps instead of 3 fps I had before.

Bump. No way this thread gets unacknowledged :bulb:

1 Like

Don’t bother

First changes in the new branch (maybe temporal) for undo.

https://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/undo-experiments

2 Likes

For the work I do/have tried to do, it seems the biggest performance/issues I run into are Undo delays and SubD Modifier performance. Maybe Multi-Res is a better one to use? But with Subsurface Modifier, the performance/delay of going in and out of Edit mode can be quite slow. Then as everyone already knows, doing a simple thing as moving an Object and hitting Undo can take 20-40 seconds.

Coming from 3DS Max, these are the 2 things I notice right away, and pushes my back into Max vs. Blender. I CAN work with it in 2.8, but will waste more time than normal, mainly just on those delays. I should be able to hit Undo in Object mode and not really expect any delay. In Edit mode, if it’s dense/collapsed mesh, I would expect some delays. Although Blender handles Undo in Edit mode “fine” it seems, or hasn’t been much of an issue for me.

I’m very happy to hear Global Undo is a High Priority now and hopefully can be resolved sooner than later and fix the issue for the most part/completely. I think SubSurf Perf. is also on the books, but not sure when that will be addressed…?

It appear to be the most important thing for blender foundation right now. So we can expect change in few times, maybe 2.82 (4 months). Except that they cannot solve the problem easily, of course.

But I think that they have seen the problem with new undo system and the edit high dense meshes. And the problem with OpenSubD is a main part of the undo. So they will try to solve all that at same time.

2 Likes

Any news about the extremely low performance of the Open Subdivision?

Same mesh in 2.79 (first example) is slow, but enough to work, with 2.80 Open Subdivision objects it have less than 1 fps

IIRC OSD on GPU is target for 2.82.

But the original subdivision works in CPU and had better perfomance. The idea of add GPU to OSD is to had better perfomance in the OSD, if not what is the reason to add OSD if the performance is the same as the old system and also consumes the GPU?

1 Like


Baking a simple AO ambient-occlusion is FFF… SLOW in cycles.
we need a faster AO generation !!!
(wait - does eevee (almost) do that already ?? )

unrelated, just for information, someone is doing better, using the intel denoiser with cycles for baking and real time

Just a heads-up, that link wont work as https request on my end, but worked as http.

Check out this thread: Why is texture baking so mind meltingly slow?

Big issue is not slow speed, it’s fact what baking settings are tied to render settings and defaults are very very inefficient for baking.

thanks, megalomaniak

related AO – nvidia tech
wiki.polycount.com/wiki/Texture_Baking

some thesis PDF

.

https://learnopengl.com/Advanced-Lighting/SSAO
.

1 Like

some improvements in sculpt mode.

https://developer.blender.org/T68873

2 Likes

Another “improvement” is that now blender 2.81 works decently on Linux, on a whole generation of radeon HD, 10 years of GPU from 2006 to 2016
I found a workaround by activating strings for Mesa opensource drivers

I tested a radeon HD 7670m and a radeon HD 2600 XT 512 mb ram. from 2007!
I made a video showing the performances (obviously related to these old GPUs) and wrote the instructions here.

Unfortunately the subdivision surface modifier is very slow in the 2.8.
I did a test. Shape animation of an object with 10,000 quadrangular faces with a 2 subdivision (160,000 faces).

2.8 = 6 fps
2.79 = 60 fps

with 3 subdivisions
2.8 = 2 fps
2.79 = 60 fps

with 4 subdivisions
2.8 = 0.6 fps
2.79 = 60 fps

It seems to be back to the problems that had been solved a few years ago:

2 Likes

We can see one of the first optimizations commits, until now blender duplicate the mesh when you entered in edit mode, and don’t liberate the memory after the edit. It created situations like you have a highpoly mesh that use 700mb of memory, enter in edit mode, so you have now 2000mb of memory used and when you go out of edit mode you still having 2000mb, and if you enter in edit mode of other object it still increasing the memory used.

Now with this patch the vertex are not duplicated and the memory is free when you go out of the edit mode. So, in my test, the memory is constant when you go out of the edit mode.

No improvement in speed, by now.

https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/ffcf39e3b5dbe7f12d04a350c629055ad21d40ce

1 Like

I am not sure if this is related directly to the viewport performance or not but in Blender if you move one object a bit faster it gets delayed and drags behind the Cursor for micro seconds but it’s noticeable.

So i did a quick comparison with Maya student version and there is no delay even Navigating in the Viewport is much more smoother,
so it is completely different, could that be improved? please.