Blender Edit Mode Performance

Max’ switching to subobject mode also takes a performance penalty at times it takes a second or so to load the interface properly, but I have yet to use Blender on the same mesh sizes so I cannot compare those. Recent versions of Max were more stutter free, 2016-2018 were quite bad in my experience.

Offtopic
Apart from edit mode speed, things like linking in files, automatic material propagation (where if you manually assign material Y to Material A, it will stay like that upon relink) and UV propagation upon relinking (through a UV modifier) are also major time savers that Blender has to do without. Same goes for a Edit poly for iterating non-destructively. For me those are the main features that would need to be added alongside performance gains.

If your opinion about Max is based on 2016/2018, you need to check 2022. 2022 is so much better than 2016 in any case.

1 Like

Yeah, haven’t used it enough yet, but I know they improved performance anyways. But I think still got laggy modifier panel for me/some similar UI issues.

Latest pulled branches. Ryzen 5800x, 32gbs of ram at 3000mhz, rtx 3070. All other industry grade tools work perfectly fine. I get the complete opposite results from you.

Fresh installs and everything. Cleared preferences. Can even take a video for you. It clearly lags and staggers when it reaches 50k to 60k quads when editing and using subdivision.

Visible stuttering and clear lack of performance on my end. Doesn’t change whether I use 2.93 or latest pulled branches. Wish I could see the outcome you’re seeing. Would change my mind on a heartbeat.

But to say blender has same performance as Maya… That is simply not true right now. Would love to see that. Cause I’d be off Maya in quick fashion.

2 Likes

What’s your scene like?
I assume you have other objects, too?
Multiple mapping channel?
Modifiers?

I think Herbert123 simply tested with a mesh.

Specifically about mesh editing which is what this topic is about.

1 Like

I did. However, I just tested a 100k mesh with a subd modifier in Blender 3 alpha, as well as Cinema4D 25 and Houdini (mesh + subd node). In these cases Blender is faster to update moving 1 face. It is not smooth in any of these three.

I’ll check in Maya and Max next, and the newest Blender subd branch.

2 Likes

Testing on a single mesh doesn’t represent the real production case. You may have other objects in the scene, and they could affect the performance of editing a mesh. That’s why I asked what the scene looks like.

I’d love to see a video of a 100k mesh with a subd modifier.

Yup, Maya and Max provide a smooth subd when editing a 100k mesh. OpenSubDiv is GPU accelerated, and it shows: while B3 alpha performs a little better compared to C4D and Houdini (but I am still rather unfamiliar with Houdini, and perhaps it supports openSubDiv as well? A toggle - could not find it), both Max and Maya are in another league.

I also tested the subd branch, and editing remains smooth on my system at 2 subdivisions. It is a marked difference, and easily allows for realtime smooth editing of a subd’d mesh with 100k meshes. I tested with a 300k mesh, and it was still quite nice to work with at level 2!

So… Let’s hope that subd branch is merged ASAP in Blender. :slight_smile:

From the point of view of raw mesh editing performance, a 2 million scanned mesh object chokes both Cinema4d and Maya when I attempt to translate the entire geometry, while B3 chugs happily along at a workable speed. Smaller selections translate faster in Blender 3 compared to Maya.

Max, however, easily outperforms anything else here.

But really, as far as I can tell the differences are becoming less pronounced between various DCCs once B3 is out.

Then the only thing to finally address is the subd performance.
I believe the new enhanced subd is expected in 3.1.

1 Like

Not really worth it: in 2.93 I hit 1.47fps when translating a single face at level 1 subd. Which plummets to a 0.52fps at level 2.

In the new optimized subd branch, I get a clean 10fps at level 2.

LightWave and Cinema4D perform worse than Blender 2.93, though.

Errata: I forgot that C4D does opensubdiv since R18. When I turn on opensubdiv, I get 12fps at level 1, which is pretty good. Suprisingly enough, only 4fps at level 2. I expected it to perform better when compared to Max and Maya.

True. I use simple 1-object scenes mostly as a baseline. I do have a larger multi-object scanned mesh as well that I tested, and it didn’t affect the single object performance in all the DCCs that I tested it in.

Yeah testing a single face and moving it around is good and all. But use it in real world context. You’re not just moving one face in real applications of modelling and one face only.

Try inserting a complete edge loop and sliding it while viewing in subd.

Or even a multiple face selection. Actually model something with it. Make a complex object while at those figures. The performance I’ve been experiencing does not simply hold up. But works perfectly fine night and day difference in Maya and max. Even modo.

There is clear amounts of stuttering too which Kevin confirmed in the opensubd thread that is unavoidable due to how blender is currently handeling the mesh data. I’m not understanding where this performance is that you’re getting is coming from.

Maya doesn’t use smoothing groups.

1 Like

Oh I’m aware… It’s the closest thing you can call it though for those that use blender and 3ds to understand.

1 Like

One of reason why Maya sucks.

Why this thread sidetracked from edit mode performance without modifiers to just subdiv performance?

2 Likes

:slightly_smiling_face: Intro: To be clear, I’m not trying to lecture you or boss you around. :slightly_smiling_face:

Is it possible that some of the performance issues with Blender are associated with improper vertex array stride?

So far as I understand things, when textures aren’t power of two, they have to be padded by the GPU driver to get decent throughput because the pathways they travel through are built in power of two format. Like a shipping container being loaded on a train. If the container size doesn’t match the cargo hold size, workers have to come in to install adapters. More work, more time.

Now if this is accurate, shouldn’t the vertex arrays also be power of two before they’re submitted to the video card for every frame?

For example, if the vertex array has a 44 bit stride, then it could be padded to 64 bits once by Blender so the GPU driver doesn’t have to do it every frame. All the copying and calculations needed for data padding every frame will add up for extremely large arrays.

I assume the lengths of the vertex arrays and the index array should also have to be padded to match the binary pathways.

I’d investigate this myself but I don’t know how to get it done. The Blender code base is too big for my brain.

If we had the diagnostics tools in the UI, when needed, I’d manually add a Vertex Color group; and maybe a weight group or two, to get the needed 64 bit stride. We also wouldn’t have to pinch polys so much if the arrays have to be padded with dummy info anyways.

Just a thought, I’m wrong all the time. :wink: Cheers.

1 Like

Line project is not boolean actually… but yeah, voxel boolean is something I’ve been requesting for a long time too… they actually have the infrastructure for that in place with openvdb, but I guess no dev is willing to implement that… :slightly_frowning_face:

1 Like

Is the voxel functionality in openvbd different from the level set?

https://developer.blender.org/D12100

1 Like

First time hearing about this “level set”…. but yes, it’s the same functionality…
Too bad they are just geometry nodes…If some of those functions could be implemented as tools and operators in sculpt mode it would be amazing…

1 Like

Smoothing groups are a primitive way to display edges with different normal angle values.

Can you do this with smoothing groups?