GSoC 2018 - Bevel Improvements

[HooglyBoogly]

Thinking about all these options, it seems a little unfortunate that we’re sort of locked into just adding new ones instead of tweaking existing options. Any change to the existing options will change people’s existing meshes with the bevel modifier.

But what I find worrisome is that after this new width method there will be even more choices to consider and a fair amount of redundancy between the options from most people’s perspectives.

1. Offset: Distance from the original edge to the new edge
2. Width: Total distance considering both sides of the new edge
3. "Adjacent": Distance along each edge adjacent to the beveled edge

I definitely don’t consider myself an expert bevel user, but I’ve been using it for a while, and I’ve been working with the bevel code too. I still sometimes find it hard to keep track of the differences between these methods! Offset and Width have always seemed especially redundant in terms of their use cases. What about replacing one of those (at least in the UI)?

I guess my question is how much more unfriendly are we willing to make the UI in order to pack in more features? Wouldn’t it be okay to make some sacrifices to continuity for a better user experience?

I’d be interested to hear what people think about this.

[Howard_Trickey]

I agree with HooglyBoogly that I’d like to hear about what people think about the proliferation of options.

Generally, Ton has been a strong voice in telling us to resist adding new options; rather, can’t the code just “figure out the right thing to do” without the need for options? And also, for options where I cannot find several people saying it would be useful, I have pushed back [e.g., there’s another thread here were someone is asking for an esoteric option for modifying custorm normals, and so far there has been no-one besides the original requester saying it would be useful, so I am not inclined to more forward with that right now.]

Bevel already is by far the tool with the most options. We keep having to increase an internal limit on the number of parameters passed through the operator system, just to accommodate new bevel options. So HooglyBoogly is making a good point here. Yet other DCC apps have similar numbers (or more!) options; bevel just seems to be inherently something for which many many use cases can be found, with many many requirements for each of those use cases. So I keep overcoming my reluctance to add new options, and users seem to appreciate the new ones (e.g., miter options; and now the coming custom profile).

If it weren’t for the fact that we have a bevel modifier, we could easily say for many of them: just do the bevels in separate groups, with different tweaks for each. Or tweak the bevel afterwards. But the modifier means we have to allow for the fact that many edges will all be beveled at once [I know, one can stack several bevel modifiers, and people do have to resort to that; but it isn’t always the answer].

For example, when beveling a single edge, the width amounts Offset, Width, and Depth all can be made to come up with exactly the same result – the only thing that changes is the value you enter in the Width box. (Percent will always be different; and the proposed “Adjacent” would also be different.) But the reason why Width and Depth were added over the initial implementation that had only Offset was that users complained about what happens when multiple edges are beveled at once. If the angles between the planes on either side of the edges differ then the relative sizes of the bevels will also differ, in different ways according to the Width Type. It is hard to know if any one of the types is so little used that we could remove it. I’d be interested to hear from users whether they occasionally use all of the width types.

See https://archive.blender.org/wiki/index.php/Dev:Source/Modeling/Bevel/ for some pictures that explain why there are different width options.

[megalomaniak]

I’d be interested to hear what people think about this.

I’d be all in support of granularizing these if we had easy to use visual macros we could build out of these more granularized operators. For an example using node trees/flowcharts to build macro operations out of.

But I dont consider nor expect it a trivial task to add something like this.

[Bobo_The_Imp]

I’m going to preface this by saying I THINK I’m for the added complexity.

I’m not as big of a power user when it comes to beveling, but I think having the extra options is probably a good idea. As you said, there is something inherent about bevel that brings up many different scenarios. It’s just a complicated tool, period.

That being said, its less the added functionality, and more the increased space that the modifier now takes that is what is a concern I think. One, it’s a bit unwieldy as a modifier, two, we are worried that starting users - intermediate users will feel overwhelmed by bevel, no? I can understand that, but I think this might bleed a bit into a everything nodes discussions.

As a node, not a modifier, all this added functionality will likely feel a bit easier to work with. And when it comes to parametric modelling all the added functionality will absolutely be welcome; you never know what you need when it comes to that.

The only problematic point that I heavily consider is how, in the future, we will decide to display the nodes. Blender has a tendency to expose all the elements in a node for easy access (shading, compositer). While this has its ups and downs, on the whole I like it because blenders nodes aren’t usually too big, and exposing all the parameters doesn’t take up too much space, plus it allows feeding parameters into one another very easily. That’s all great for procedural modelling. But when it comes to bevel, it may infact still be a hilariously large node…

That brings up the discussion of maybe having the nodes be closed, and their parameters be brought up in something like the N panel, which we already can. This way we could probably consider tabs and the likes to clean up all the features.

There is a lot to consider, and I hope that I can chat with Jaques Luckes on the blender today show that Pablo hosts, as you can leave questions that are answered on the show. Hopefully that can give some clarity for the future. But for the mean time, the bevel modifier will maybe just be a bit awkward in size.

To sum up: I think the changes are fine, the modifier might be a bit awkward right now, but it should become easier to work with as a node in the future. Those are my thoughts.

[Dev1]

@Bobo_The_Imp

I was thinking something quite similar. I have some ideas relating to other concepts/post that may help and give the user a lot more control. The modifier could end up being used for a lot more than beveling.

[HooglyBoogly]

Well said both of you, it’s definitely a tricky problem.

In general I’m not against the added complexity, but it’s always better if it can be accompanied by a simplification that also makes it easier or more pleasant to use. It’s too bad we don’t have a tally of how many times Blender users have clicked on each of the width methods. I wonder if it would be possible to do a poll or a survey to see if one of the options is used much less. I also really like that they’re all accessible, not in a drop-down menu, and once there are five that becomes much more unwieldy.

[Wazou]

On the bevel, I only use OFFSET since PERCENT isn’t fully supported with a merge threshold like I posted some time ago.

[Bobo_The_Imp]

I took the liberty of crating a new thread as Howard requested.

Bevel Improvements

[Screenshot_20190726-161901_Chrome] Howard has asked us to move the bevel improvement discussion to another thread, as it was continuing in a GSoC 2018 thread. So let’s let’s bring the discussion here. I’ll start with a request for the bevel node to have the option to output a vertex group containing the beveled vertexes.

Let’s take the discussion over there to keep things clean.

[eobet]

I suppose we could add an option to try that way. Do other users feel this is an important option to have?

For hard surface modeling, it would be an extremely important option to have. This is the way all CAD software packages work.

[radi0n]

Yes! For me is extremely important!

[kromar]

hey i would like to try these improved bevel options since i want to see if it resolves this issue:

can anyone provide me a link to a build that i can try? i was not able to find one:dizzy_face:

when doing mechanical parts modeling a even bevel is in my experience always the desired result and i think the current (official) behavior can be considered a bug and possibly removed?
Or can anyone give me a scenario where you would want such a shift in the bevel?

[Howard_Trickey]

You probably scaled the object non-uniformly along different axes, right?
You should “Apply > Scale” (in the Object menu).
All tools in Blender work on the unscaled object, so you get results like your picture if scaling afterwards is non-uniform.

There is has been a bunch of discussion over the years about whether tools like bevel (and inset, and probably other tools I’m forgetting) should do an “apply the transformation, to the tool, apply the reverse transformation” to fix this problem. But there are some downsides and in the end we have not decided to do that, at least for now. For one thing, it could break existing files. This is mainly a problem for new users – experienced users know to apply Scale after scaling non-uniformly in object mode, and then this problem goes away.

[kromar]

yeah just got that input and its a bad sign if i fail after 10 years of blending with these trivial things.
I dont understand why is there no compensation for that transformation on the operator levels.

I know this has nothing to do with the bevel directly but this is really something that tripps a lot of users and i also implement corrections in addons for the transforations since its something a user should not have to care for and can cost hours to figure out.
And i think it should be taken care of in all the different regions of blender, wehter its exporters, modifiers, or any other area where transformation messes up the expected result.

[Sunbeam]

I dont understand why is there no compensation for that transformation on the operator levels.

probably because object scale can be called modifier of it own that applies after everything, and if user willing to use tools with “compensation” he might as well apply scale it self. What can be done is added warning/hint about non uniform scaling at the bottom when entering edit mode.

[lsscpp]

So recapping, an alert and a apply scale [rot position] modifier

[Fux]

What can be done is added warning/hint about non uniform scaling at the bottom when entering edit mode.

That would actually be a very nice solution to this problem. Or maybe add hints only if you try to apply certain modifiers (eg bevels) that function differently (or maybe unexpected behaviour as in the example above) when there is a no uniform scale

[Wazou]

On my addon, I added a message for that.

[megalomaniak]

I’d modify it to say WARNING! Non-uniform scale will give potentially unexpected results since in some cases you might actually want such results, in which case it’s not exactly bad.

[addddd]

Hi I did this and at a moment I’m showing the effect of setting by interval (not coded again). but do I do something wrong because this is really hard to have width of bevel with bevel weight. https://www.youtube.com/watch?v=5MaYcyk7Bpw
and I was sure that I could find bevel weight in edit mode in the list. but no?
ok I have to add apply scale to my script anyway

[Veezen]

Lately I working a lot to learn 3d design in home. That means, I trying to work non-destructive as much I can but sadly I miss some features.

Let say that I cut a lot of things using booleans. Below is good, non-destructive example.
From this

to this

As you can see, I added 1 segment bevel on top of it but there are some issues with shading. Giving specific angle for bevel or auto-smooth doesn’t work good in every case, especially when you have wide planar changes on mesh.

Chamfer let me define the structure of piece that I currently working on, whether it is metalic piece (small, thin bevel) or plastic (medium, more thic bevel) so it’s important for me to have it always on top while working without collapsing bevel modifer to fix that kind of issues by hand, because due to that, I lose non-destructive pipeline in stage when I still looking for shape ideas.

I quite sure that this question was asked already, but anyway, is it possible to detect boolean intersection edge line, which could be converted for sharp edge? Below I posting example:

That kind of intersection edgeline opens for us a lot of opportunities to use it in different way, for example we could use that for adding custom bevel width just through boolean modifier.