GSoC 2018 - Bevel Improvements


When I tried to go over 1 by an increment of .01 blender crashed, Is there any reason to go over a normal strength of 1.Howard the crash occured when I went “over” 1 by.01. Thanks for answering my post.


Yes, I can see in the code why it crashes when the strength goes to 1.0. Am checking with Rohan for the right fix in this case.


Thank you Howard and Rohan for your work so far! :slight_smile:
This will be such a leap forward, once stable!

I just wanted to add that the “normal strength” crash on the “face area” mode never occurs for me when the “segments” are 1.
Something greater then 1 and I can reproduce the crashes. Autosmooth doesnt even matter for the crash.

Also the “Fixed Shading” mode seems to produce split normals for faces where all edges are adjacent to faces generated by the bevel modifier.
create suzanne head => activate autosmooth => add bevel modifier => “Fixed Shading”.



In case you missed the bugs that came in on thursday for the face area crashes: and (dupe)


Thanks rbx775 for reporting the Fixed Shading problem.

Fix for the crash is still pending.

I just fixed the problem reported by Alberto about vertex-only bevels on cube corners. Thanks for reporting that, Alberto. I can do a better job on such corners if profile=0, but that is more work so just did a quick fix for now.


As someone who’s relatively new to blender (coming from Modo, whose bevels are a bit behind other software), I’ve noticed a couple of strange issues with bevels in Blender. Consider a basic example- a cube with a cylinder subtracted out of one face. If I try to select the resulting intersection ring and bevel it in blender, I end up with some really nasty geometry, where Modo seems to handle this case just fine:

Modo 10.2 (a bit outdated, but the version i own):


And the same operation in Blender 2.79 (recent nightly build, maybe a week old or so):


For this case, turn off the ‘Loop slide’ checkbox when you bevel. That option tries to slide along attached non-beveled edges, and that makes the vertices attached to the edges that join to the outer square be angled – and it doesn’t take a very large offset amount before it then overlaps the adjacent one.


Perfect! not sure how I overlooked that setting, now it behaves exactly as I expect. Thanks!


Hi Howard, I know you are only on the bevel modifier but I would like to know if you could edit a little the triangulate modifier.

It could be relly nice to have an option to triangulate only Ngons.
There is some example.

As you can see the workflow works pretty well with Bevels and booleans, for concepting, this is really great.
I’m using CGstrive’s custom build to add this triangulation only on Ngons and help me to keep everything editable.
This + weighted normal modifier make the workflow with bevel and boolean really great.

I know this isn’t for the bevel and I’m sorry for that, but I think this could be perfect with the new Bevel.
So, tell me what do you think about that, please.


Yes, I agree that it is very little work to add an option to triangulate only ngons to the triangulate modifier. I’ll see if the other developers have any objection to me adding that.

But another possibility would be to modify the boolean modifier so that it optionally triangulates (or quadrangulates, where possible) the faces where intersection happens. I am working on the boolean modifier right now, but am quite a ways from being finished with my changes. In fact, the current code works internally on fully triangulated models, and then painstakingly dissolves the internal triangulation wherever it can, afterwards (but removing that part would not mean that everything would be triangulated, unfortunately).


That would be really great, thak you :wink:

Note sure it is necessary to add a triangulate to booleans, most of the time it’s better to not have any connected edges when adding booleans.

I made a fast test by adding one, and the second and another with the triangulate modifier.

To not polute this thread, if/when you will work on the triangulate we could continue to a new post.


Booleans triangulating by default would be undesirable as Wazou demonstrates by stacking multiple boolean modifiers(only as a checkbox perhaps).

Triangulate Ngeons is not just useful for stabilizing booleans, but also closely relates to WN(and Bevel) topic. For example if have a very common Cylindrical shape game asset, you could apply WN/Bevel, but it would become corrupt after export as ngeon gets triangulated. The solution is modifier stack as such:


Hi Howard. Yes, It would be perfect to have a triangulate modifier in the modifier stack as a single modifier. Then youre able to use it in a pipeline. So external data can be used, too... that wouldn t be possible if its only integrated in the Boolean modifier…


Something with this workflow, a Welder Modifier, simple but really useful!!!


Maybe I’m wrong, but maybe an option to triangulate only quads would be useful too ? And if it’s easy to do… Yolo ! :blush:


(And maybe another option to triangulate triangles too…)


One of most common game objects is probably a beveled box ( crates, beams, wood etc). Currently adding Bevel modifier to UVd box causes a glitch with Corners:

Tested in both 2.79 and 2.8. Would great if it can be addressed.


Could you please submit a bug report for this, with a .blend (to show how you UV mapped before the bevel) and the map you think should be the result? You can assign the bug to me (howardt).
Getting the UV map to do the right thing after bevel is harder than it appears - I’ve spent a lot of time and code on fixing problems with that. But happy to see if this is a case that can be fixed. As you say, it is an important common case.


I have made a bug report as requested:

Please also note that there’s a bug with UV distortion using Normal mode in 2.8:

Thank you for looking into it!


I very hope this is possible, some update or create new bevel modifier, because it will all peoples make the hardsurface models quick and easy. Thank.