Bevel Improvements


I want to make a small suggestion to the material distribution on generated faces with uneven segment count (1, 3, etc).

Left picture shows the bevel lines in edit mode, right shows the final material distribution for Segments:1.
As you can see, the automatic behavior can turn out a bit chaotic between different materials.

But adjusting the material index setting results in this:

You can see one color always interrupts the other two. In this case its not useful either.

To make generated faces more sorted I suggest to give materials with lower material slot index priority over the other.
So in my example: red would be first, green second, yellow third.
The standard Bevel result is much nicer:
BevelMaterialColor 3
This also allows the user to sort via the material slot list.
I would be happy to have this.


I almost implemented that method of dealing with this problem (it only happens with an odd number of segments). Some user told me it wouldn’t be useful, so I didn’t do it.


Even if it’s a niche use I’d think it’s useful some of the time.


I almost implemented that method

Is there a downside in implementing it?

The downside is: what if this method turns out to be not very useful and I later implement a more useful one; but meanwhile people had started depending on this behavior. Now we get into the situation where we have to maintain two methods to solve a similar problem. And worse, probably have to add yet another option to choose between them to the already long list of options that Bevel has – in some people’s opinion, too long already.

Here is the discussion the last time we discussed this issue, where I was persuaded not to do the material index method: GSoC 2018 - Bevel Improvements

This discussion has led me to think it is probably time for me to take a small break from my Boolean improvement project and fix several of the requests that keep coming up - this one, and the one for an ‘absolute leg length’ amount-mode.


I started implementing something, and realize there is actually a need for a series of tie-breaking rules, each to be used if the previous one ends in a tie. I ended up using the material-slot-based tie-breaker as one of them. What I’m thinking of is lexicographic minimum of a vector of the following values, in this order:

  1. UV islands id (id numbers are assigned in order of the lowest indexed BMesh face in the island).

  2. Material slot number.

  3. z-coord of face center

  4. x-coord of face center

  5. y-coord of face center

The lexicographic minimum looks at the first value first, and if they are different, the minimum side in that coordinate wins. If they are the same, then move on to the value and repeat. At the very end, if all were equal, make an arbitrary choice.

I’m debating, for the last three, whether I should instead use the absolute distance of the corresoponding coordinate’s face center from the object center. That might make for more symmetric looking choices on something like an oblong box; but would lead to no choice at all for a cube.

I’m interested to hear whether users would find a fixed ordered set of rules like this adequate. I’d really like not to have to put a “face tie breaking rule” option into the Bevel UI. For one thing, it is hard to explain what it is for, and for another, harder to explain what the choices mean,


@JustDoItLater I had to remove your post as it was a video showing proprietary software, that could be considered a copyright violation. We have to be careful about that.

See .

For others, the video was a request for bevel to continue past collisions with existing geometry. Certainly a popular request, but a very large project.

1 Like

Can we please resurface this: Bevel Improvements

The current bevel tool not only cannot get me a consistent radius around all corners of an object, the resulting bevels even at profile=0.5 aren’t circular - they’re weirdly distorted and even with a custom profile, its well nigh impossible to achieve that result (let alone repeat it elsewhere).

This one just landed in master and it’s (IMHO) a big one:

“This allows users to use a collection for the boolean modifier and gets rid of the long modifier stack.”

I wish there was the same for the (voxel) remesh modifier and others, yummy!


It’s not really a matter of resurfacing it, the problem is on the surface, and I have a patch to address it here:

It works for those very simple 2D examples, but as usual with Bevel those become quite complex in the general case in 3D. In other words, there are still problems with the patch that I’m trying to work out. I’ve been working on it every few weeks and I think I’ve made a bit of progress. It’s also hard to prioritize it over more pressing things, but I’m hoping I can get it finished for 2.92.


Will bevel modifier deal with this kind of issues with the next modifier refactoring?


It is a medium/long term goal, afaik

Wow, yes, the ability of using collections to define object ranges and also assign a Boolean type for the Remesh modifier would be very welcome.

1 Like

Just in case you want a workaround today:

It’s a brilliant add-on, with an equally brilliant name for the tool.


Yes, I’m using this addon, but I want to keep bevel live and of course if bevel modifier will do it automatically, it will solve all similar issues immediately and faster when applying modifier and deal with it with MESHmachine.

I think Blender chamfering needs to be improved, the lack of dynamic Clamp Overlap, and the inconvenience of asynchronous chamfering strength, which is only possible in Percent mode, where the values don’t support precise settings.