Fall 2019: Bevel Constant Radius Project

[HooglyBoogly]

I’m planning to work on the bevel operator for a class this semester at school. In the spirit of involving the community I thought I would make a post here so people can get involved.

The Problem

The way bevel handles non-square corners doesn’t reflect bevels from the real world. In the real world, bevels usually have a constant size and shape defined by the tool, and they don’t change based on the angle of the corner being beveled. But in Blender, the beveled corners do not necessarily have a consistent radius.

@Howard_Trickey

This is a choice I made at the beginning about how to handle bevels between faces that do not meet at 90 degrees. The way Blender does this is to always make a profile that is a quarter of a circle (or quarter of a superellipse, if the profile parameter is not 0.5). Then if the faces don’t meet at a 90 degree angle, a transformation is applied that takes the 90 degree angle into the actual angle. This gives the effect you note in your diagram.

Requests

1. Right-Click Select — Blender Community
2. Bevel Improvements - #22 by Angeldust This request talks about using a constant number of segments per arc degree, which would work well with a single vertex bevel, but in a sequence of consecutive bevels with different size arcs, this wouldn’t work.
3. GSoC 2018 - Bevel Improvements - #365 by z01ks

The Solution

Currently, bevel globally specifies how far along a vertice’s adjacent edges to attach the ends of the profile. Instead, with this solution applied, bevel will specify a global bevel radius. A circle of that radius will be placed between the adjacent edges at the location where each edge connects tangentially to the circle. Then the profile becomes a different portion of a circle depending on the angle of the corner.

To simplify the user interface, it’s possible that one of the current “Width Methods” for specifying the size of the bevel will be close enough to this “constant radius” option that they could be merged. I’ll advocate for this as a way to tackle the increase in complexity that comes with every new feature, but others might disagree.

Non-Global Profile Shape

The current bevel code relies on using the same profile definition for the entire operation, contained in the ProfileSpacing struct, which stores the 2D location of each of the profile’s points. The profile is stored this way because of the high computation cost of sampling the super-ellipse function for the variable profile.

I propose bypassing the step of storing a global profile shape and instead calculating the profile’s points directly for each profile. This sounds slower, but only using circular profiles as discussed below should simplify the calculation, and some slow-down is probably inherent in the solution to this problem anyway.

Only Circular Profiles

This solution connects a circular arc tangentially to each of the adjacent edges. Because of the requirement of a constant radius together with these tangents, it doesn’t make sense for a profile to have any shape besides a portion of a circle. Any profile could be contorted so its profile meets its adjacent edges tangentially, but with any shape besides a portion of a circle, those tangents wouldn’t continue meaningfully into the profile.

This “circular arc” requirement nullifies the two bevel settings that control the profile, the superellipse parameter and custom profiles. Without these options bevel is simpler, which is an argument for having this project’s “Constant Radius” option be the default. Although that would makes those profile features less accessible.

[Howard_Trickey]

There’s a good argument to making this always the case (with caveat about maybe only for profile 0.5), not dependent on some width method or new option checkbox. Though that would not be backward compatible and may mess up current models with bevel modifiers.

But if only for profile 0.5, then will get a jarring effect as one changes the profile ever so slightly. Not sure about what to do about that.

[ThatAsherGuy]

On the UI and feature exposure side of things, adding a constant radius mode would make a profile drop-down feel reasonable. Putting it on the same row as the arc profile slider, using prop_menu_enum and a disclosure arrow as the icon, would be an easy way to do it. I played around with a similar layout when I was experimenting with tool header operator popovers:

[justastatue]

Awesome, I look forward to this.
I don’t quite understand how it would all work, so I’m curious to know, will this have an effect on situations like this?:
There are times I want a “radial” bevel, where the edges radiate from a point. The best way I know to do that is to add “bounding” loops to enclose the bevel and then use the Percent width mode and bring the bevel to 100% width.
See here, I do a normal bevel first, then I use this technique to get a “radial bevel”:

@HooglyBoogly

A circle of that radius will be placed between the adjacent edges at the location where each edge connects tangentially to the circle.

I guess what I’m wondering is, will this circle-placement take into account connected edges in such a way that it will be possible to get this radial effect without adding the extra edge loops?
I’m guessing that it would make no difference in this example, as each corner angle is the same, and the radius shouldn’t change…
But do you think this would be a realistic extension to this circular profile behavior?

[HooglyBoogly]

It would obviously be best if everything still used the same code path. So if this feature worked with generic profiles, but I’m just seeing problems with using this solution generically. First of all because it’s no longer simple trigonometry without circular arcs you can’t use the simpler math to fill the profile. Instead you get back to the idea of a “map” to deform the profile for the angle, which is where we already are!

Even ignoring that problem there are other issues with applying this solution to non-circular profiles.

• Custom Profiles: For angles greater than 90 degrees you need to use a bigger arc than 90 degrees, but custom profiles don’t contain that information. And for less than 90 degrees, using a smaller arc means you only use some of the custom profile? This just seems like some strange complexity.
• Concave Super-Ellipse Profiles It’s hard to imagine how to sample more than 90 degrees of a concave super-ellipse, and I’m not sure what benefits it would give vs. stretching a quadrant of the function.

Not to mention the problem that anything besides a circle can’t even be described with a radius!

[HooglyBoogly]

@justastatue

I don’t quite understand how it would all work, so I’m curious to know, will this have an effect on situations like this?:

Ok, I see what you mean. Thanks for the descriptive video! This feature isn’t necessarily about solving that situation. This is more about being able to specify a consistently sized bevel for corners that aren’t 90 degrees.

Another way to do that would be to use separate operations for the inner and outer bevels. If you knew the ratio of the wall thickness to the bevel radius/offset you would know the right size for both bevels. This feature might make that situation a bit more clear because you are more directly specifying a radius, but that’s really just a words thing in your situation.

I’m not really sure how we could generalize the behavior you’re looking for. Maybe make a post about it in the Bevel Improvements thread?

@ThatAsherGuy

On the UI and feature exposure side of things, adding a constant radius mode would make a profile drop-down feel reasonable.

I like that bit of UI, it’s a good way to condense stuff. I think this might be more of a “Width Method” option though, rather than a profile option. The profile that works for this is already described by profile=0.5, and it’s really just a question of where to place the ends of the profile and what to do in the middle of it. We will need a new width method option because with this feature it needs to depend on the corner’s angle.

[ThatAsherGuy]

Presenting it as a “radius” width mode could work. Grouping the option with the other profile modes (and automatically changing the width descriptor to ‘radius’ when it’s enabled) might communicate what can or cannot be controlled better, though.

[LOLDO]

Was there ever any development done on this? I would be interested to take a look at the code.

[modmoderVAAAA]

Bevel V2 Geometry Nodes

I don’t see a discussion here yet for the WIP bevel node, so thought it would be useful to have it, similar to the exact boolean discussion. Tagging @Howard_Trickey and @weasel, the contributors of the code bcon 23 talk: [Progress on a new Bevel Geometry Node] Task: I am particularly excited about this node, as from what I understand, it will also be able to give a proper offset in Blender taking care of the offset vertices interesections, which if often used in architecture.