The thing to bear in mind is that it’s taken Max years of constant development to reach decent viewport performance. Not too many years ago the performance wasn’t great and the undo buffer was completely broken for quite a while. Even now in Max 2020.2 there are other areas of the UI that suffer from flickering/lag/redraw/refresh problems. Max performance is finally getting decent all round, but it’s taken a LONG time and is still far from perfect.
This function of the polygons that have a scalar performance, “is just a trick” that only needs to be studied well the best technique to implement it.
“a hack” that tells the system: “hei, consider in the editing step that there is only this number of selected polygons to be calculate.”
A trick would be to temporarily and automatically split the mesh in the editing step and then, after moving it, make a join and remove doubles at the end of the editing step (what actually I do physically and manually to edit the highpoly meshes)…
Damn it, if I knew how to program I would write the code.
I have teeth but no bread.
I don’t even think it takes too long to implement it.
Performance improvements for SubDiv appear to be en-route.
This commit for instance tweaks the BLI threading API to take into account the fact that some operations (like evaluating the subsurf modifier) are not lightweight. The commit message also indicates that another change will come that improves the situation a little more.
man, I have been trying for 20 years, I have always been a man of great insights, but at the same time my memory “loses water from all sides like a sieve” , therefore my mind is not made for these things, at a certain point one can only resign itself to the despair.
Try again in R21. There’s a good performance improvement in sculpt mode in r21.
R20 was garbage.
Just installed the R21 trial to test. Sculpting is much improved in R21, and workable now. Still not nearly as smooth as Blender’s sculpt mode, though.
Edit mode performance in R21 doesn’t seem to be faster - even somewhat slower, perhaps? As fast/slow as in Blender 2.81.
Editmode slowing down in Cinema4D, I would see as something far worse for those users than what Blender users saw in 2.80.
The reason is that C4D has become a rather expensive application that still has just one release a year (which has changes other than bugfixes). The Blender devs. meanwhile are slowly, but surely tackling some of 2.80’s performance issues and those who can’t afford to wait can just download from the buildbot. Then there’s the fact you didn’t pour hundreds or even thousands of dollars into licensing and/or subscription costs.
If I had an app. with a 4-digit pricetag and a subscription, then it better have far greater performance than the FOSS or lower-cost alternatives.
Yesterday i just clock my longest undo ever on a 31 millions scene, moving one mesh in object mode took 1 min 33 seconds.
I really don’t understand why it was so long in object mode since i had move some objects in other heavy scene and it was never more than 20 to 30 seconds.
C4D is one of the most expensive DCC app to maintain of all - this is exacerbated by the fact that many parts have not been updated much or at all for a long time, and that C4D users have to rely on a couple of external (costly) plugins to balance out the outdated parts.
Many C4D users rely on external render engines such as Octane or Cycles to render their images because the standard render engine is old, slow, and cannot compete with modern engines in terms of quality, and the ProRender engine in C4D just doesn’t provide the speed either (aside from other issues).
And let’s not mention the ancient UV tools, particle system, or BodyPaint tools. Maxon’s demo reel implies it was all done with native C4D, but that is just not the case: external render engines, the Thinking Particles plugin, and so on, are pretty much an essential requirement for a C4D user to keep up with the competition.
It most redeeming feature is still MoGraph, but it is hampered in the current versions object scene handling slows down C4D to a crawl (Blender, while it has edit mode issues, generally is very efficient with scenes with large amounts of objects). And even MoGraph is only slowly receiving new features.
Anyway, my intention is not to bash C4D. It arguably is the easiest 3d app to learn for a beginner, and it is quite polished. Maxon is aware of all the performance issues, and has been working on updating the core for the better part of the last decade. So far the benefits haven’t panned out yet in any big way yet, but hopefully things will improve for them in the next few years.
The main problem is really Maxon and how management seems to mistreat their loyal user base, both financially as well as the lackluster updates the past years. It has scared away many of them. I used to be an avid C4d user as well, but the financial upkeep just made it impossible for me as an occasional 3d freelancer to justify using it. And by now Blender has outpaced C4D in a number of key areas (unless you slap on another $1000 or more on the base price).
Thing is, Blender’s development is by far outpacing C4D or Lightwave at the moment. This is troublesome for both. And I don’t want to see these DCC apps leaving the market for many reasons. Competition is good.
Well, part of my point is the fact that most people would expect an app. to have very high quality across the board if they dropped that much money to get it. This is even more true now with the quality of FOSS in general on the upswing.
Any app. I would spend money on these days I would expect to have a quality and performance that is objectively a lot better than the closest FOSS equivalent (in nearly all areas). The reason is simple, a company that makes millions of dollars a year should be able to have a paid dev. team and an R&D budget beyond what is possible for FOSS organizations.
Blender 2.8 might be a bit disappointing in some performance areas, but at the least we have the core team taking a look at the bottlenecks (and making some commits) rather than just ignoring them.
Good to hear some progress is being made! Almost 2x speed up according to the notes.
However I did not notice any improvement with armature modifier + subsurf. Does it only affects edit mode, anyone can confirm?
Sergey has been looking at speeding up OpenSubDiv, but any commits related to it will be in 2.82.
I assume @lucky tested a recent master… in any case… I’m buying any improvement, albeit small, on the current situation.
I mostly agree with what you’re saying.
Only a couple of things I’d like to add.
With the subscription the price is changing and I don’t think at that point it will be one of the most expensive DCC anymore. The whole year will cost about $700, which is good. Whether the subscription model is a good thing or not it’s another story (I personally don’t like it).
As for the argument that C4D is at this point a HUB I totally agree. On top of C4D, I also own Redshift and Xparticles to get the job done. Still, the cost for all of this once the subscription will start will be around 1k, which is quite good considered the quality of RS and XP. Then again, I couldn’t get any of the particles stuff I do in C4D with Blender with the same simplicity in the same amount of time.
That said, if it wasn’t for the mograph thing, fields and volumes, in other words, if I wouldn’t be working in the motion graphics industry, I wouldn’t see any reason to justify the cost for C4D. At the moment I can’t wait to get home and play with Blender. I never had so much fun with a 3D software, and I tried and liked for respective reasons other 3D packages as well. I wouldn’t have also thought I would end up buying addons, my ideas was always “what’s the point of buying addons in a free system like Blender?”. How wrong I was! Blender devs have to focus on Blender. They have their agenda and they’re doing a great job. For whatever else they cannot cover there are the addons and oh boy, how much better the experience gets!
cmon guys let us leave some clout on the blender developer forums!
LibOverride: Make diffing several times faster.
Diffing on undo steps is a critical performance point of override
system, although not required for override itself, it gives user
immediate feedback ove what is overridden.
Profiling showed that rna path text search over overrides operations was
by far the most costly thing here, so now using a runtime temp ghash
mapping for this search instead.
Seems to give at least 5 times speedup on big production rig.
Depsgraph: Ignore action time dependency if it’s not needed
It is possible to have action which is not nullptr but which have no
f-curves in it (for example, animate cube’s location, then delete all
Such situation should not add time dependency as it could slow down scene evaluation on frame change.
in general less use of CPU, greater use of GPU
this should speed up EEVEE final rendering when we press F12
Most of the renderpasses in EEVEE used post-processing on the CPU. For final image rendering this is sufficient, but when we want to display
the data to the user we don’t want to transfer to the CPU to do post
processing to then upload it back to the GPU to display the result.
This patch moves the renderpass postprocessing to a GLSL shader.
This is the first step to do, before we will enable the renderpasses in the viewport.
When doing viewport rendering the color management happens on the CPU.
This has overhead in downloading a float texture from the gpu and
performing color management on the CPU.
Based on the scene fileformat bit depth the result will be rendered to
a byte texture where the colormanagement happens on the GPU or a float
texture where the colormanagement happens on the CPU.
This is only done during Viewport Render Animation in other
cases a float texture is being used.
Baseline (HD render of wanderer.blend workbench engine no samples) 15.688038 s
After changes: 9.412880s
Workbench; Small performance boost for Nvidia users.
Bastien continues to dissect the undo performance issues, but it’s all in its own branch for now
Undo improvements got moved from long term to medium term, would be cool if someone has some more information on what that’s about -
Also, alembic playback performance seems to have decreased significantly since 2.79-2.80-early 2.81 for deforming geometry. Anyone else has issues with that?