The number given is in seconds or rather ml second, not fps, but I do get your point …
I still think it’d make a lot more sense to keep it in the modifier and simply display a warning if the modifier is not the last one, instead of going this schizophrenic way of cluttering the mesh datablock UI with one special snowflake modifier which user may, or may not need to use
Warnings in modifiers are not something new anyway:
If cycles X moves adaptive subdivision out of experimental mode and streamlines how it works (like octane) then we won’t need to add a subdiv modifier to get adaptive subdivision.
Latest test :
400 000 poly model with subdiv modifier
Blender 2.75 beta with open subdiv mode that works in edit mode and GLSL mode : Subdiv level 1 : 5,3 fps. Subdiv level 2 : 5 fps
Blender 3.0 alpha : Subdiv level 1 : 0.9 fps. Subdiv level 2 : 0.4 fps
I hope that Blender 3 perfs will reach the perfs of this old B 2.75 beta build
I’d hope at least 25 fps/40ms frame time for a ~500k vertices model.
Hi all, I opened a thread to talk about GPU OpenSubdiv acceleration (and a couple extra features), if you want to try it out. I was forced to rewrite the implementation, so there is one expensive computation that still is done on the CPU, however it is cached and only reevaluated when the topology changes (e.g. adding or removing an edge loop) so only Edit Mode is really affected, Pose Mode should be fine.
Unlike in my previous post in this thread, the subdivision settings are back in the modifier. Putting them in the mesh datablock will be done later.
Great! Can we not mention subdiv ever again in this thread from now on?
None of the examples I’ve posted have been with a subdiv modifier active, and performance has still been showstopping levels of bad (comparing with Max that we use at work).
Who wrote that?
As this topic is actively being worked on, it makes a lot of sense to disentangle the different aspects which are the cause of the performance issues. This makes it a lot easier to understand what is going on, rather than having everything in one bucket and trying to guess the context.
Nevertheless, that doesn’t mean subdivision can’t be mentioned in this thread anymore. I am sure there are plenty of reasons why that would make sense. For the sake of clarity, it makes sense though to use the other thread when it is clearly about subdivision.
Testing shows a significant overall speedup when transforming:
~1.5x with a subdivided cube 1.5 million vertices.
~3.0x with the spring mesh (edit-mode with modifiers disabled, duplicated 10x to drop performance).
Important to note for future from parches:
Currently only mesh data blocks are supported,
other data-blocks can be added individually.
Armatures might be able to skip a full COW copy too.
Updated previous post with test data from latest improvements in master. Also added comparison between latest and previous tested master (rightmost column).
I think changing proportional radius size felt a bit snappier too, but didn’t test for it.
Thanks for testing with such a detail.
The numbers on this patch is huge
During a mesh transformation in edit mode (Move, Rotate…), not the entire draw cache needs to be recreated.
But this occurs because DEG_id_tag_update(tc->obedit->data, ID_RECALC_GEOMETRY), chain a call to BKE_object_data_batch_cache_dirty_tag that tags all the batch cache to be redone
This patch proposes not tag dirty All, but only what participates in the deformation of geometry.
Currently, the graph can be compared to this simplified one:
Where DEG_id_tag_update(id, ID_RECALC_GEOMETRY) triggers geom_eval_mesh or geom_eval_obj_init.
And DEG_id_tag_update(id, ID_RECALC_SELECT) triggers update_select or update_select_obj.
This patch proposes to separate “tag_dirty” from “geom_eval” and create a separate node for it (update_all in the image bellow).
In addition to adding an node to update_deform
The graph becomes something like this:
|large_mesh_editing:||Average: 16.727632 FPS||Average: 26.424897 FPS|
|rdata 9ms iter 26ms (frame 60ms)||rdata 0ms iter 19ms (frame 38ms)|
|large_mesh_editing_ledge:||Average: 17.761902 FPS||Average: 28.070558 FPS|
|rdata 9ms iter 24ms (frame 56ms)||rdata 0ms iter 18ms (frame 36ms)|
|looptris_test:||Average: 5.537827 FPS||Average: 5.456050 FPS|
|rdata 11ms iter 26ms (frame 169ms)||rdata 11ms iter 28ms (frame 172ms)|
|subdiv_mesh_cage_and_final:||Average: 2.095824 FPS||Average: 2.140402 FPS|
|rdata 7ms iter 21ms (frame 242ms)||rdata 0ms iter 20ms (frame 237ms)|
|rdata 7ms iter 22ms (frame 233ms)||rdata 0ms iter 21ms (frame 227ms)|
|subdiv_mesh_final_only:||Average: 6.626541 FPS||Average: 7.974115 FPS|
|rdata 3ms iter 13ms (frame 145ms)||rdata 0ms iter 10ms (frame 122ms)|
|subdiv_mesh_final_only_ledge:||Average: 6.590914 FPS||Average: 7.978224 FPS|
|rdata 3ms iter 13ms (frame 143ms)||rdata 0ms iter 10ms (frame 121ms)|
The scoffers who were skeptical of serious performance boosts for the next release may have pie in their face now. A couple of the benchmarks will soon be over 20 times the speed of Blender 2.8 (and don’t forget the big OpenSubDiv performance boosts coming in from Kevin).
This looks very promising so far but I really hope this means edit mode speed ups across the board including proportional editing, sculpting and whatnot - not just here and there for certain modifiers or modelling functions/modes.
Expectation were low because target was to “bring 2.7x speed”, whose performance was em… not amazing. And there were no such performance sprint before.
According to tomjk’s test we are now at 1.5x 2.79 speed with up to almost 4x in some cases.
And there are still a lot of bottlenecks, but i’m glad that there are finally nice editing performance improvements.
Sculpting is a different system but there are some patches.
In my tests proportional editing also gets a significant boost - PE’s performance was indeed hobbled by the slow mesh processing rather than anything else.
In my tests even 2.93 is already over 4 times faster than v2.79. I am unsure what kind of test files he is using, but I am basing this on a “real world” scene (the Wright Flyer which can be download in an earlier post of mine here). v2.79 is horribly slow compared to even 2.93. Much slower than the purported 1.5x comparison with 3.0 alpha!
The same result when I work with the dragon model: v2.79 runs as slow as a slug in molasses in edit mode. Again, even 2.93 is much faster to edit with.
I do not understand the discrepancy between my testing and Tomjk. I test the same Dragon mesh, and in my case the speedup factor is far greater than their measurements.
2.79 is just really, really slow to edit with in edit mode. Already at least 4 times slower than 2.93, and the latest build (before the patches mentioned just earlier) is again about 3 times faster than 2.93.
An improvement of around at least a factor of 12. Hardly the 1.5 times @tomjk reports.
Entering Edit mode is also twice or thrice as fast in v3 alpha on my system - which his figures indicate is identical in 2.79 vs v3 alpha.
So what gives? Am I missing a setting in 2.79 that causes it to perform that bad in openGL on my system? I also compared LightWave Modeler, and as expected Modeler performs worse than v.2.79 - which in my book means 2.79’s mesh editing mode is indeed operating at the expected pace (Modeler was always slower than 2.79).
I just tried downloading it but it just says folder empty. Am I missing something or is the flyer file gone?