Developer Forum

Blender 3+ bevel modifier ngon overshoot regression?

Through the course of evaluating 3.0 LTS for use at our studio I noticed that we have some 2.93 LTS files where the bevel modifier is overshooting in some very interesting ways. Digging deeper and I’ve discovered that the root cause seems to stem from the use of a decimate modifier before the bevel to act as a non-destructive ‘limited dissolve’, which sometimes doesn’t always remove interior verts such as this one:

As you can see, In 2.93, the bevel modifier doesn’t really care- it happily handles it without any issues. 3+ is a much different story:

This overshoot seems to be caused by the Loop Slide option. If I disable it on the bevel modifier the results are as I would expect (minus the loop slide behavior of course).

Now obviously, the underlying geo wouldn’t have these extra verts or the model could be fixed manually, etc. I’m mainly concerned about whether or not this is a fundamental change in how the bevel modifier works in 3+ compared to 2.93.

If the bevel modifier functionality changed, I’m not here asking for it to be changed back, I know that major revisions are opportunities to ‘break things’ for future improvements. I just need to know if this a regression that I should bug, or is there new functionality with the bevel modifier that would cause these wild overshoots? For clarity, the bevel modifier here is set to a very small amount (as you can see in the first screenshot) but the overshoot are insane… observe:

If this is a bug, I have a min-repro .blend I can submit with a bug report. Thanks!

2.93 is so long ago that i can’t remember all the changes I made since then. There was one where someone was complaining that my code to control overshoots was overly aggressive, stopping a desired behavior, and I remember changing a threshold to a lower value, knowing that it would cause more overshoots in certain circumstances. I have a suspicion that that is what is causing the difference for you. If you have a small-as-possible example where this happens, file a bug and I can decide whether or not it is a bug or just the consequence of trying to balance many desired behaviors.

Loop slide is quite problematic as far as the math of bevel. It is there because people want bevels to slide along existing edges to maintain a desired silhouette. But it means that there is usually no way to satisfy the requirements that bevel offset the same amount parallel to all the beveled edges once loop slide comes into play. So there is massive compromising going on in the loop slide case.

Ok, thanks Howard- I went ahead and submitted it- if this seems like something within Loop Slide’s normal operation feel free to close it. Thanks!