Bevel edges sluggish

only 100 000+ triangles, Is it typical for others too and i am not only one? 2.83.4 I just want some confirmation, nothing more. RTX 2060, 32GB ram, 3700x

Here is my another experiments, i intentionally stopped dissolving(optimizing) edges to show with large amount of triangles causes bevel to be especially sluggish. Try to bevel last selected edge. CTRL-B
experiment_178.rar (881.8 KB)

(I’m one of the main Bevel developers.)
I didn’t look at your file since I don’t want to have to install software to unpack .rar files.
Bevel has not been optimized for high performance, nor has it been written to take advantage of multiple cores. This is actually the first complaint I’ve seen about bevel performance on high-poly models, which I actually find surprising because I knew the performance is not great. I figured it meant that it is actually rare that people want to bevel all edges of a high poly model. Do you have a practical use for this, or is this just something you are curious about?

One particularly slow aspect of bevel right now is that when you have the ‘loop slide’ option checked, there is a computationally intensive optimization problem to solve in order to try to satisfy an unsatisfiable set of constraints. If you have that option checked, try unchecking it to see if it runs faster.

There are many cases where bevel goes over the whole mesh, over and over, where it could restrict itself to only the parts that have changed, and I have long wanted to fix those. A problem with doing that is that it might cause non-backward-compatible changes to positions of vertices, so I have held off doing so. At any rate, I suspect you are beveling all edges in your tests, in which case the optimization I just mentioned would not likely help at all. An optimization that would help would be to use multiple threads and do some beveling in parallel. I am interested in trying that, though it will also have the backward-compatibility problem.

Thank you for info, maybe it is worth to sacrifice backward compatibility to get multithreading? That thing was meant to be hi poly version anyway and if you see some places deleted edges then those are when i descided to stop dissolve them to prove hi poly editing is quitw slow. 7z this time.

experiment_178.7z (949.0 KB)
Try to bevel this edge and it is sluggish, my 16 thread core would love multithreading if possible in future

Sorry 7z is equally bad in the sense of needing new software. I find the software for unpacking .7z and .rar tends to be either something one has to buy or seems risky at installing crap I don’t want, so I’m not going to install anything that requires those. Please, .blend or .zip or .gz

experiment_178.zip (2.1 MB)

1 Like

I looked briefly at your file. I agree that it is slower to bevel that edge than I would expect or want. I don’t have time right now to profile this and figure out definitively why it is so slow, but I suspect it is the first thing I mentioned: that there are several places that loop over the entire mesh when that isn’t necessary. When I have a break in my other current project (boolean), I will try to speed this up. Thanks for the example.

1 Like