GSoC 2018 - Bevel Improvements


I want to look at this, but my brain’s not up to it right now. I’ve set a reminder and will get to it later, if nobody else does!


@Howard_Trickey Great change to Bevel modifier! Thank you very much for this one.


You should also consider checking AutoSmooth along Harden Normals automatically and maybe deselect it as well with it. Now user can’t see any result by clicking on new option.


I’ve also had a play with the new options and honestly couldn’t find anything new that actually did what I expected/anything at all.

What I imagine the most useful feature would be for a hard-surface modeller is a “flatten original faces” checkbox with different wording. This would have the following behaviour:

a, b, c, d, e (assuming c, d and e refer to the normal of the vertex joining A, B, C and D): retain A’s normal
f: in this case, be a weighted sum 1/3A + 2/3RightFaceNormal
B: not sure what I would do here… but I think it would work out that the true normal would end up equalling what I would expect to see.
C: this gets tricky. I’m not familiar enough with how face normals are generated and used to say for sure how this one would work. Are face normals not just either an average of the it’s vertices normals, or perpendicular to the plane made by the vertices (if they are coplanar)?

I’m not sure if I’ve contributed anything you wouldn’t already know, but I think I understand how I would expect the output to be.


Note that there’s also a thread on BlenderArtists where I asked the same question and got more input than here up to now. See

Also note that after I submitted the changes, I realized that things don’t always work at all as expected if the faces are marked as smooth shaded and autosmooth is on before doing a bevel with hardening. I apologize for that and will hopefully fix soon. A scenario that I do think works pretty well, for testing now, is: take a model with all faces flat shaded and turn on autosmooth. Then do a bevel and enable ‘harden normals’. Use the overlap option to see per-vertex face normals to see the effect of hardening on the normals.

Answering the above questions/comments:
cgslav: I agree, I should automatically select autosmooth if it isn’t already checked. I want to do that in a separate commit, though, and check it well before doing it.

smilebags: I’m not sure if it is clear to you what a,b,c,d,e,f represent in my diagram: these are “loop normals” or sometimes called “per-vertex-face-normals”: each of them can be independently set to whatever we want – that is, c, e, and d can all have different loop normals.
What I have implemented now is that a, b, c get the normal they had at those corners before beveling – those are probably the same as the A face normals, if autosmooth thinks the edges involved are sharp; d and e get the same loop normal that c gets (i.e., the orignal loop normal at that corner of A before beveling). f gets the average of the face normals of the two “long edge” faces adjacent to it: B and the unlabeled long edge just to the right of B. I think this will be the same or approximately the same as your formula but with weights reversed: 2/3(A’s face normal) + 1/3(unlabled grey face pointing right-ish face normal).


@Howard_Trickey loving the work so far, I don’t know if you are looking at profiles and this may be an old issue but are you aware of the odd bevels when using Profile = 0 and indented extrusions?


AnadinX, I’m not sure there is a good one-step solution to what you are trying to do there. I could get something that looks better by first beveling only the square loops of the insets (unselecting the connecting diagonals and short extrusion edges) and then separately beveling the short extrusion edges.



Just pinging, maybe you have some insights into this:


I have changes ready to allow different miter patterns. An example:

and another:

I will probably push these changes in a day or two unless people think this is too big a functionality change for a period when we are in beta (?).


It’s fine, we’re still a while away from final release.


Could we have something like that with your changes?


Wazou, yes, you can get that picture with my changes. Well, almost. The one edge that won’t be achievable is the arc on the front corner of the back top face. You can get arcs like that but if enabled they have to be on all non-reflex angles, and the rest of the 90 degree angles in your picture don’t have an arc there.

Right now you can independently set the miter for (all selected) reflex corners (those with angle > 180) to either patch or arc (your picture shows arc; my first picture showed patch), and for (all selected) non-reflex corners to arc or no arc – and the width of the arc is controlled by a ‘spread’ parameter.

There is no easy way to choose subsets of vertices to get different treatment. I suppose something could be done with vertex groups or bevel weights, but I don’t want to go down that path unless there is strong demand for that.


A really big, big improvement Howard, thanks!


This is a great improvement! Thank you, Howard!


Looks amazing Howard! I hope you choose to push those changes. :slight_smile: Thanks for your hard work on improving bevels!


Awesome news!

I hope it will make it to 2.80 :3. I believe there are several months left.

Mittering method could be determined per vertex or is it more complicated (corner’s side?)?

If Yes i guess they could be controled by several vertex groups like that:

default uniform
or maybe by new kind of vertex data?

Anyway whats your TODO priority list?



Something like you propose (Vertex group) could indeed offer more control over which miter patterns happen where, though it doesn’t allow the ultimate flexibility that people might want. Because really, the miter type could be different for each “sector” around a bevel, where a “sector” is the group of faces between two successive beveled edges. So for ultimate flexibility, you’d need to be able to specify both a vertex and which beveled edges start the sectors for which you want to apply a given pattern.

With this change (which I’ll push soon – but want to work a bit more on fixing some profile=1 cases, on corner-of-cube cases, on overlap clamping, and then more thoroughly testing), I am about done with my current high-priority TODO list for bevel. I want to get back to a half-done project I’ve been working on to make BMesh Boolean work a lot better (e.g., work when some intersections are coplanar).

If I do do anything more on Bevel in the short term, my priority list is something like:

  1. Some tie-breaking rules for what happens to materials and UV seams when you have an odd number of segments.
  2. Maybe add “termination” pattern types for how to terminate a beveled edge when only that edge at the vertex is beveled. Currently it makes a little triangle into the adjacent face, usually. Other possibilities I could add are: (a) just stop (no triangle); (b) extend the triangle’s third point along an opposite edge until it hits another vertex;
  3. Maybe add another miter type, which I’d call “polar” and some people call “quad”, which only applies when three edges are beveled: the idea is to pick one of the three as a “pole”, and spread that vertex apart in an arc there, and then do a kind of latitude/longitude pattern with the equator at edge between the two non-poles. This is the pattern that MESHmachine uses. The big problem here is how to specify the pole. It is similar to what I discussed at the beginning of this post: one has to be able to specify both a vertex and an edge at that vertex to be special. I could add a new vertex data layer especially for this (but this seems pretty heavyweight, and I’d need UI commands to edit that data layer); or I could say that it applies to all three-beveled-edge corners and pick the pole by whichever edge has the biggest bevel weight. This all seems kind of complicated and I wonder whether the new arc miter option (which would turn a 3-beveled-edge corner into a hexagonal pattern with arcs in each face) is sufficient? Also maybe the new harden normals options reduce the necessity for fine control over the miter patterns in general? Or maybe instead of a special polar pattern, I should just bite the bullet and figure out how to give users the “ultimate flexibility” that I described above: then you could pick exactly one vertex to have an arc and the effect would be like a “quad” corner.

Longer term, but probably after I work on Boolean, I’d like to work on these. These are quite a lot harder, which is why they aren’t on the short-term priority list.

  1. Letting bevel flow past existing edges (cutting away pieces of encroached faces) and avoid self-overlap.
  2. User-defined profile curves.

That’s my own personal priority order. I’m happy to take suggestions from users, especially on whether or not I should try to do items 2 and 3, because at the moment I’m thinking probably not (now, at least).


Did you just say Co-Planar Booleans!!!? Wohoo!