GSoC 2018 - Bevel Improvements

Zuorion - OK, I understand what you mean but he Shift jump. I had forgotten the Shift key handling in modal bevel, as I don’t use it myself, even though I coded this a long time ago. It’s tricky to get the code right to handle transitions between the different value modes, and I seem to have a bug here.

Yes, I should add spread and loop slide to things that you can control with keys.

As to the property values settings and parameters for keymap - I’m not sure how to do that right now.

Rekov and michealknubben - yeah, some kind of ‘keep quads after bevel’ has been an oft-requested feature. In the example you show, that connection edge makes sense if the original face there was a nice convex quad, but maybe not in other cases. Anyway, such things could be added but it is a bunch more programming and there are other things on my TODO list (see earlier in this long thread).

Wazou: the next major thing that I will do to Bevel is make it merge properly. This is a long, hard task. (People might be interested in the “Inset Straight Skeleton” addon, used to be “Inset Polygon” addon, that I just ported to 2.8. It does collisions and merging, but only works on planar or near planar faces or groups of faces. And it doesn’t quite work in all cases – the special cases get very hairy here.) But will likely do better Booleans before tackling this work on Bevel, as Booleans are more urgently sort-of-broken right now (since Carve went away).

kio: Interesting examples; thanks for writing them up. I feel a little lost about what to do about it, though. I must admit that while I added these new mitering options because people said that they were better for subdivision, I was not really sure why. And your examples show that it is not necessarily the case. There is some subtle art/math involved in figuring out what geometry is going to yield the desired subd results, and I am far from understanding that.

As you suspect, it would not be easy to allow per-edge miter choices. The problem is almost entirely a UI problem, however – internally, the code could handle it just fine. And while I could probably figure out a UI to allow this spec on a per-edge basis for the Bevel Tool, the real problem comes with how to specify it for the modifier. I’m open to ideas here. But again, this is not going to be on the top of my TODO list, probably.

Another approach would be to try to figure out an “auto” mode for choosing the miter type. If there’s some rule we could figure out about when one type of miter would be better than another, then it would be easy to implement such a rule in the modifier and tool. But I have no idea what such a rule would be. Your examples in this post show that it is not easy, because I don’t see what the differing feature is between cases where we got good results vs cases where we got bulges. Any reader of this thread have any ideas here?

5 Likes