I remember that XSI made an explicit record on a visible database … which could, if it wanted to be edited directly via text, put everything on a database even in modeling, every single vertex that was moved … to allow non-destructive modeling. …
so much so that from time to time you had to do “step freeze” to clean up and lighten the mesh …
Then you will have to store brush strokes into disk and read it back into memory and apply it in reverse ( which is a whole can of worms ) and if it is a high 4k texture doing disblasment on a mesh it will take time and you get precision errors lots of them and you won’t get performance.
2d application don’t use the parameters system , They do delta backups too. However in there case they are doing it on one kind of data (pixels) which is easy.
On blender you have , mesh , carve, images. Procedurals and so on. And of course the different modes as will
1 Like
yes but I believe that the problem in the undo is not in the “restoring of things” but in a sort of scanning of all the objects that there is … to see what needs to be put back to the previous step … before restoring.
this becomes evident precisely in the scenes when they become very heavy and full of objects …
This is delta as will it’s just presented to you in editable format… So if you moved an object as a whole, why is it giving you undo steps for verts?
it was useful for modeling techniques … to make model variations and more
I’m sure it was , but the fact it was stored as part of undo , the cleanup and freeze operations is simply indicative of them storing too much of it into ram … And maybe exceeding the cache lemits for the undo steps on disk
no it was not, or maybe yes, I don’t remember, but it was not strictly related to the undo system, it was something potentially useful to do also animations, scripting with nodes and other things with modifiers
What’s that?
Alright, I think I get it… 
Not related to performance, but the eevee dev created a bunch of interesting todos. 
https://developer.blender.org/tag/gpu_viewport/
3 Likes
Yep, that’s why this thread has been created for future discussions about Eevee news:
3 Likes
The first part of the Mesh Batch Cache work is up for review
https://developer.blender.org/D5424
The result is dense meshes with subsurf will update around 25-30 percent faster, it’s still not great but it’s a decent first step.
He also did some profiling and found OpenSubDiv is indeed the big bottleneck the way it is implemented now. I’m left to wonder if there’s room for optimization before implementing the GPU acceleration.
5 Likes
I have the same problem but it seemed to be an issue with transforming an object with an armature. Try deleting the armature modifier and see if performance improves.
In Blender 2.79, open subdiv is 2 or 3 times faster even on CPU (in conjunction with deforming modifiers such as armature modifiers). So there should be room for optimization, it seems something is currently wrong… Then GPU acceleration should reach light speed, hopefully.
1 Like
I suspect that if the opensubdiv at the cpu level are not already faster, there is little to do, because it is “external code” that probably cannot be touched, otherwise with the next future upgrades by the pixar would be a problem … so hopefully the same pixar will leap forward … or that someone will optimize the open source code of the pixar, so “the dev that creates the optimization on cpu in blender in the opnsubdiv code” provides the patch to the pixar and these accept it …
It’s not that much of the OSD code causing the slow performances than the way it’s implemented, IMHO. In Blender 2.79 the OSD code run fast, then we can easily make this assumption, unless the OSD performances regressed in the latest version, but that’s very unlikely.
One way or another the open subdivision performance it’s sergeys job ,so I expect some more job from sergey ,
This is very important to be done as fast as possible
1 Like
The Opensubdiv checkbox in 2.79 was the hardware acceleration of subdivision surface code that 2.8 doesn’t have right now. In 2.79, they were using their own subdivision surface code with whatever code the opensubdiv project uses to enable hardware acceleration. That’s why it’s faster in that version.
The current issues with opensubdiv in 2.8 stem from the fact that they’ve completely replaced their in house subdiv code for it. They have to re-implement the hardware acceleration as well as fix any issues caused by swapping their code for opensubdiv.
1 Like