thinking about this, in the last few days, in conjunction with other things regarding the editing of objects in edit mode … I think that the whole way of managing editable objects should be redesigned: I thought in particular of this:
when entering edit mode, especially in objects with a high density of geomentry, blender recalculates the position of each single vertex, so if we select a nest of few vertices to move them, blender, when moving these vertices, calculate in the loop all the geometry and vertices contained in the whole object. this is bad, because it creates that famous lag that makes objects with a high density of geomentry practically non-modellable.
a simple solution to which I thought is this:
when moving the vertices, (during the execution of the function: movement or rotate or scale) blender must only calculate the vertices involved in the displacement, and must consider the rest of the geometry of the object as if it did not exist, and only at the "mouse release - execution confirmed " then it calculates the new position of all vertices of the object
I do not know how complex it is to insert this change but I think it is of priority importance … I really did some tests and the geometries are unmanageable, even hiding the vertices of the object that are not needed, the situation does not improve much … in some ways it’s even worse than how things work on blender 2.79
When devs began with EEVEE about a year ago, I talked to some developer about it and it didn’t seem to get much importance. That there were no plans to improve the situation, beyond the optimizations the viewer receives. Although it was something that users clearly ask for because with 50-100k model editing is almost impossible.
I tried to know if the problem was for GPU or CPU, and although I get the impression that the problem is CPU (because it only happens when you try to edit), he told me that it was a GPU problem because more geometry data was loaded into the graphics card (That’s the answer I received). I don’t really know the origin of the problem, I don’t think it’s a GPU issue, because it doesn’t improve no matter how much graphics you have, and I don’t see much sense in it either.
Something tells me that we won’t see changes in this for quite some time, despite its importance. Because I probably need deep changes in many parts of blender.
I want to clarify that for passion I’m monitoring daily progress that are doing in this sense … and actually in the last few weeks have improved a lot … and I’m doing tests on a gpu of a laptop that now can be defined obsolete. …
having said that … making explicit the particularity of using also “tricks” that give priority to the interaction during editing, it’s my first priority dream
If it is true that the last few weeks have improved, but also because in the last month had fallen quite the performance of the visor, at least in my case. If I were you I wouldn’t waste time, I used to monitor git for the same as you, but after 1-2 years I did… it’s a waste of time.
I asked the person who was implementing some multi-threaded operations, and as I said, I don’t think we’ll see any improvement in that regard. Besides that we have never received any answer about whether they will take care of this problem although it has been very recurrent in the community. So except for surprise, I don’t think we’ll see anything in the next versions of blender.
Hate to judge until I learn more. But I do know that this is very difficult and the developers have done amazing work so far in 2.8. They should definitely be focused on functionality and stability for the beta and beyond. I’m sure performance enhancements will follow. In order to remain competitive with other systems Blender will need to be able to perform and scale. I have confidence it will get there. In the meantime I got myself a faster machine and better GPUs.
Yes I know they are doing a good job.
Although I do not have the capacity to develop code, I like to think about possible causes and solutions when they occur …
Even if mine could then be not feasible or mismatched theories