GSoC 2018 - Bevel Improvements


MACHIN3 has been working on a really nice bevel after boolean workflow…maybe you guys can combine forces to make this happen in the modifier.


Hi there @Howard_Trickey , I appreciate the hard work you are doing on Blender!

Concerning the Bevel topic I was wondering if there will be a QUAD Chamfer/bevel improvement for insets and extrusions. Currently they give an un-desired shading effect not suitable for Game Art normal maps.

Currently there is a workaround using MESHMachine script but its only a band-aid fix and destructive in nature (have to collapse the bevel modifier first).

Desired Bevel


(sorry for double post but it wouldn’t allow me to post 2 images in 1 post)

Current Bevel


I can’t predict when, but yes, there will be such an improvement in the built-in bevel with respect to toplogy oprions at vertices. This is now clearly the top requested feature, or maybe it is tied with having bevel “dp the right thing” when overlap occurs (but that’s rather harder to fix, in the general case). I am aware of the various addons that do some of this and will use them for inspiration, but would like to come up with solutions that work in the general case, and pay attention to the hard-to-get right things like what happens to the UV maps, edge data, etc.


If you take a look at this video, it shows a sphere with a chunk booleaned out. The mesh has hard edges where the boolean subtracted and has custom normals to fix shading issues as a result of triangles, ngons and uneven polygon density.

The problem is, the bevel modifier will mess up the custom normals. The only fix right now is to apply the bevel and fix the normals again manualy, on the mesh level.

And so I was wondering if it would be possible for the Bevel mod to use the existing custom normals, if there are any. This would be a live saver and add a lot of flexibility.

Grab the blend file from here. Thanks or your awesome work Howard!


I will look at this. But first I am working on the bug reported above by cgslav.


This, would be amazing for gamedev creation. 50% of my projects nowdays rely on weighted normals (then just normal decals) and being able to keep bevel modifier and still be able to tweak weighted normals would be amazing. Preferably with a value of 1-100 (like the 2.8 normal weight modifier). Or a simpler version like the y.a.v.n.e pluggin where its just a weak/medium/strong value.


There is no reason for that. You don’t want anything less than 100% of the previous, custom defined normals. It’s not about weighting face areas to influence the normal generation, just take the existing ones and set the normals at the bevel periphery accordingly.


Hi Howard, thanks for your work, it already already looks amazing !


im not sure it has been mentioned but the bevel behaves a little odd with the mirror.
In 2.79 you could mirror and also bevel in a stack. with mirror first.

In 2.8 it has a stack order issue. If the mirror is first (which helps further booleans connect) there is an issue with the bevel showing up on weight.

I love all the suggestions here so far. If any of these get added the modelling would be light years ahead.


Thanks, mx2. It seems that the mirror modifier in 2.8 does not properly propagate edge bevel weights. There was a big change internally for modifiers, getting rid of the concept of “derived mesh”, and I suspect that that is the reason for this oversight. I hope I can find time to look into this.


Hello, I have always wondered, is it possible to add a “Smart Clamp” check box? So rather than allowing one overlapping vert from stopping the entire bevel, it would instead detect and clamp only that one individual vert, so that way the bevel width can continue while preserving a clean mesh. I’m sure it would be expensive on the CPU when more and more overlapping verts add up, but that would still be something I think generally everyone would find worth the wait.


This would be possible (it would require me to change the code somewhat to keep a per-edge clamp value, rather than the global one I calculate now). One issue I foresee, though, is that if you go all the way to a clamp value then you get zero-length edges, which is not a “clean mesh”. A subsequent “remove doubles” might fix things, but no guarantee. And anyway, clamping anywhere means that there will be beveled edges that are not the bevel width the user really wants, so this isn’t really the right solution. The right solution is to actually change the geometry as the beveled edges sweep over vertices. But this is pretty hard, so I haven’t done it yet.


While I agree it would be better to solve it right, I have to say that I personally turn clamp off very often and honestly, in like 90% of cases the problematic spot isn’t visible (which is the reason why I turn clamp off).

Nathan’s solution would work great I think and I’m surprised I never thought about it. It’s not really about bevel width not being correct but more like bevel width being 90% correct and in the rest of cases at least not creating intersecting mesh or infinite spikes.

If remove doubles is implemented can it be made to really do it only locally on the 2 (or more) beveled vertices and not everywhere? Very often the mesh is split and some vertices share location so doing it globally might cause issues.

Writing all this and thinking about 10k meshes I fear the speed will suffer greatly…


Thanks and it actually might not be as CPU intensive as I originally thought since each vert clamped is one less path to calculate, so potentially it could even optimize the bevel modifier. If it turned out to be the worse case scenario it would still be faster than manual, not to mention a 90% fix is typically good enough for 90% of people (especially beginners).


There would be very little effect on CPU time – essentially none – if we were to clamp per-edge.


Well that’s awesome, I imagine the amount of time that would save people would be huge. Though I’m sure coding something like that would also be really time consuming, but still it is fun to imagine, thanks for the info!


cgslav, I just committed a fix to this bevel modifier with hardened normals bug that you reported on Oct 9. Sorry it took so long to fix. Thanks for telling me about it!