If you want to do a fair comparison with C4D, make sure to delete the Phong tag… It slows things down a lot…
In my tests, C4D (R23) is still faster than Blender v3…
I removed the phong and material tags. Makes no difference on my machine in the dragon scene. Running C4D R24.037.
What are your hardware specs?
edit I also tried C4D 23, but exact same results.
The scene that I tested before (Wright Flyer) actually chokes C4D 24 when I select the entire wing’s mesh and attempt to move it: it takes 6 seconds before C4D responds, and 4 or 5 seconds before it updates. No such issues in Blender: performance degrades a bit, but still very usable.
Just now I removed the phong tag to test whether it makes a difference, and again: no discernible difference, as far as I can tell.
That said, my video card is rather old (1080 GTX) - perhaps C4D works better with a more modern card? Not sure, and I cannot test this.
~20% performance improvement commit
~16% performance improvement commit
Not very sure if these are localized percentages or an overall. They are already in master so test… you will need to compile it yourself or wait until an up-to-date version is built …
3 Likes
Updated previous post with test data from latest improvements in master, including speedup factor versus 2.79b and 2.93.0.
edit: adding the image here for easier reading. Not sure if it’d be better to keep updating the one post or make a new reply each time, but I guess if I’m replying anyway to say “hey I updated it” each time I might as well include the newest image at least…
4 Likes
Finally! 3.0 has performance ready for editing high quality real time assets (not all) but most. Nice update.
1 Like
it’s actually happening. I’ve seen the commit logs. It’s grandiose. Like peeing in a mountain lake after a long summer hike, overlooking the ocean
9 Likes
Another test of moving a selection of the dragon scan model to see if there are any differences :
2.79 - about 450ms per frame - 2,2fps
2.82 - about 1350ms per frame - 0,74fps
2.83 - about 910ms per frame - 1,1fps
2.90 (June 12 2020) about 670ms per frame - 1,5fps
2.90 Release - about 670ms per frame - 1,5fps
2.91 (Sept 4th 2020 build) - about 670ms per frame - 1,5fps
2.91.2 - about 920ms per frame - 1,08fps
2.93 Alpha (January 22nd 2021 build) - about 845ms per frame - 1,18fps
2.92 - about 920ms per frame - 1,08fps
2.93 about 860ms per frame - 1,16fps
I’ve retested 2.79b - someting had to change (Windows update etc) cause now I’m getting less than half of the performance than before (I did not change the hardware)
2.79b about 1060ms per frame - 0,94fps
3.0 alpha (June 14th build) about 340ms per frame - 2,94fps
I’m very happy that 3.0 looks to be the fastest Blender version ever (finally!).
I’m just wondering why my 2.79b test is so much worse now… I had problems with infamous april Windows update which ruined gaming performance, but it’s all good now.
1 Like
Here’s a quick comparison i made (Subdiv mesh editing performance) between the latest 3.00 alpha (as of today) and 2.79b. (Base mesh is a 64 side cylinder with a level 2 subd modifier enabled)
10 Likes
I tried your test in my branch. The GPU version is a bit faster than the CPU one (then I don’t have the fastest CPU in the west). Note that for rendering I chose to put subdivision settings in the Mesh panel, so the modifier will only be for modeling.
23 Likes
That is a significant improvement already the way I see it (especially since you used what is close to a worst case scenario for subdiv modeling as of the current builds).
Keep it up.
2 Likes
I am so confused. Why is there such an exception that opensubdiv is a mesh property instead of modifier? Literally everything else is modifier, so I don’t get why this one is hardcoded as a mesh datablock property… 
That’s looking very promising! Thank you for your effort!
1 Like
There are multiple reasons to make subdivision a mesh property:
- separate subdivision as used for modeling and subdivision as used for rendering (when the modifier is last in the stack, but with geometry nodes there is no “last node” to inherit subdivision settings from)
- better import and export for Alembic and USD (where subdivision is first class citizen), for Alembic the current importer is messy, whereas the Cycles Alembic procedural I implemented handles subdivision more gracefully
- simplify/improve smooth normals handling
- for GPU acceleration, and also for Cycles adaptive subdivision, not having the settings in the modifier helps avoid subdividing the data twice as the modifier will do the subdivision anyway (not to mention that for OpenGL you need to in the main thread, whereas modifiers are executed in parallel)
Then more things in the future might be ported to the GPU (e.g. transforms), but this is yet to be discussed and planified by the GPU/render team.
14 Likes
While the improvements are indeed very appreciated and looks really promising, as modeler, I can’t help but think how will it affect modifier stacks having opensub as property and not as modifier.
The modifier is not going to be removed, this is for rendering only. So you can still have intermediate subsurf modifiers between other modifiers as a way to add details. This is the last step, after the modifier stack, if you want to see it that way.
17 Likes
I am reading this thread from time to time, and each time I see new performance improvement, that’s great, keep it up 
2 Likes
Honestly, to me, all these points sound more like workarounds/excuses than real solutions. It’d very sad if Blender had two different subdivisions at two different places which would have different performance in different cases and different unique settings.
But then again, that sounds like very Blender way of doing thigs, so it will most likely end up that way indeed.
Autosmooth is available as data property, edge split is object modifier so there already was something similar before so they didn’t add exception just for subdiv.
As long as subdiv modifier is kept for flexibility and data property subdiv is clearly named separately to not create confusion for users I don’t see downsides.
When you say “for rendering” You mean, the display rendering? Like the way “autosmooth” option is applayed?
Cause you mentioned Cycles few times and i dont know how and why is this even related (subdiv to cycles).
These are not workarounds as well as not solutions. It’s problems of current implementation.
“Make subdivision a mesh property” is solution.
Yes, people often wants choice, that’s why they ask for checkbox in preferences. If there are no significant advantage it’s indeed gonna have both at the same time.
At some point there might be purge of those choices since there are too much of them but that’s entirely different topic.