Blender 2.79b bevel in holes a bit odd #62649

New Issue

Cyp · 2019-03-16T12:30:58+01:00

Cyp commented

2019-03-16 12:30:58 +01:00

System Information
Operating system: Gentoo Linux

Blender Version
Broken: 2.79b

Short description of error
From left to right:

Bevel disabled
Bevel width 0.5
Bevel width 0.4999

The one with bevel width 0.5 looks a bit odd. The one with bevel width 0.4999 looks as expected.

Exact steps for others to reproduce the error
Make a hole somewhere and bevel it so the vertices should touch. For fun and surprising results, the first bevel should be ≥ 50% of the width, and the second bevel can be anything. Also, try changing the first bevel to 1 segment for a more symmetric and unconventional result. Endless possibilities!

bevelbug.blend

**System Information** Operating system: Gentoo Linux **Blender Version** Broken: 2.79b **Short description of error** From left to right: * Bevel disabled * Bevel width 0.5 * Bevel width 0.4999 ![bevelbug.png](https://archive.blender.org/developer/F6834076/bevelbug.png) The one with bevel width 0.5 looks a bit odd. The one with bevel width 0.4999 looks as expected. **Exact steps for others to reproduce the error** Make a hole somewhere and bevel it so the vertices should touch. For fun and surprising results, the first bevel should be ≥ 50% of the width, and the second bevel can be anything. Also, try changing the first bevel to 1 segment for a more symmetric and unconventional result. Endless possibilities! [bevelbug.blend](https://archive.blender.org/developer/F6834079/bevelbug.blend)

Cyp commented

2019-03-16 12:30:58 +01:00

Added subscriber: @cyp-2

Howard Trickey was assigned by Brecht Van Lommel

2019-03-16 18:02:12 +01:00

Bastien Montagne commented

2019-03-16 22:28:26 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2019-03-16 22:28:26 +01:00

Please try with latest blender 2.8 build, 2.79 is not maintained anymore (besides critical issues), and code has evolved since that release…

Bastien Montagne commented

2019-03-16 22:30:26 +01:00

Hrrm, actually, can confirm the issue with blender 2.8 here…

Howard Trickey commented

2019-03-17 00:17:31 +01:00

I confirm too for 2.8. Oddly, it only happens for the modifier, not the tool (oddly because the code for the core bevel is the same). And the second bevel doesn't have to have 0.5 width -- any width will show the problem as long as the first one had width 0.5. I will investigate further.

Howard Trickey commented

2019-03-17 17:13:46 +01:00

OK, this was mysterious, but I understand the problem now. It is that vertex groups are getting mixed up in a way that is likely unexpected to users: there are weights associated with each vertex in a group and the bevel modifier considers each vertex to be part of the bevel if the weight is >= 0.5.

The problem is that when new vertices are made, their custom data is interpolated between the custom data of all of the vertices in the face that they are created in. What is happening in the example blend is that when you do a bevel on vertex group Bevel1 with width 0.5 then the interpolation causes the new end vertices to have 0.5 for weight in Bevel1 group and also 0.5 for weight in Bevel2 group (which wasn't involved in the first bevel, but is adjacent so the interpolation causes Bevel2 group to "leak over" onto new adjacent vertices. This means that the second bevel modifier, on group Bevel2, now operates on more vertices than the user intended when setting up the groups Bevel1 and Bevel2. When you use width 0.4999 the interpolated weight for Bevel2 group on the new vertices is just shy of the magic 0.5 value I use to decide whether or not to have those vertices participate in the bevel.

The root problem is that we are using vertex group weights to indicate membership in a set instead of boolean values. If they were boolean values, we wouldn't even be trying to interpolate the values in the face, but rather they would be set from the example vertex (the one that the bevel verts are being created around) and all would be well. I wonder if this problem shows up elsewhere in Blender where vertex groups are using for membership semantics?

I am not sure how to fix this and would appreciate comments from users and other devs. Here are some possibilities:

Have bevel go back and "fix" the interpolated values for the newly created vertices so that the entire weight comes just from the vertex that the new vertices are created around. This is a bit messy, needing more code, and might not be the right solution if we want to fix the general problem of "weights shouldn't be interpolated if they are being used for membership semantics". Also, what if the weights are being meaningfully used for something other than group membership, so that interpolation semantics are what is needed? Right now, there is no way for bevel to know which groups should be "fixed" and which should be left interpolated.
Make a separate kind of vertex group that is only used for membership, so has boolean values, and doesn't get interpolated. This could/should also be done for edge and face selection groups, something that has long been asked for by users. The problem here is mainly that this is a significant amount of work, probably not possible before the 2.80 release, At least, if done properly, with good UI support, documentation, tests, etc.
Have a bevel modifier option to be the threshold to use for deciding membership (instead of hard-coded 0.5). I doubt this really solves the problem, because if you bevel beyond 0.5 in our example case, the interpolation will actually move membership more towards adjacent vertex bevel groups and there probably won't be ways of manipulating the threshold properly to get the intended effects.

In my opinion, option 2 is the only workable one, but as I said there, kind of difficult to implement on short term.

A workaround for the particular case in the bug report would be: use Bevel1 vgroup for the first bevel limit, but instead of Bevel2 for the second, specify that group using Bevel Edge Weights = 1.0 and the weight limit method. I realize there are many similar cases for which such a workaround won't be possible, sorry. I hope we can fix the bigger problem eventually.

OK, this was mysterious, but I understand the problem now. It is that vertex groups are getting mixed up in a way that is likely unexpected to users: there are weights associated with each vertex in a group and the bevel modifier considers each vertex to be part of the bevel if the weight is >= 0.5. The problem is that when new vertices are made, their custom data is interpolated between the custom data of all of the vertices in the face that they are created in. What is happening in the example blend is that when you do a bevel on vertex group Bevel1 with width 0.5 then the interpolation causes the new end vertices to have 0.5 for weight in Bevel1 group and also 0.5 for weight in Bevel2 group (which wasn't involved in the first bevel, but is adjacent so the interpolation causes Bevel2 group to "leak over" onto new adjacent vertices. This means that the second bevel modifier, on group Bevel2, now operates on more vertices than the user intended when setting up the groups Bevel1 and Bevel2. When you use width 0.4999 the interpolated weight for Bevel2 group on the new vertices is just shy of the magic 0.5 value I use to decide whether or not to have those vertices participate in the bevel. The root problem is that we are using vertex group weights to indicate membership in a set instead of boolean values. If they were boolean values, we wouldn't even be trying to interpolate the values in the face, but rather they would be set from the example vertex (the one that the bevel verts are being created around) and all would be well. I wonder if this problem shows up elsewhere in Blender where vertex groups are using for membership semantics? I am not sure how to fix this and would appreciate comments from users and other devs. Here are some possibilities: 1) Have bevel go back and "fix" the interpolated values for the newly created vertices so that the entire weight comes just from the vertex that the new vertices are created around. This is a bit messy, needing more code, and might not be the right solution if we want to fix the general problem of "weights shouldn't be interpolated if they are being used for membership semantics". Also, what if the weights are being meaningfully used for something other than group membership, so that interpolation semantics are what is needed? Right now, there is no way for bevel to know which groups should be "fixed" and which should be left interpolated. 2) Make a separate kind of vertex group that is only used for membership, so has boolean values, and doesn't get interpolated. This could/should also be done for edge and face selection groups, something that has long been asked for by users. The problem here is mainly that this is a significant amount of work, probably not possible before the 2.80 release, At least, if done properly, with good UI support, documentation, tests, etc. 3) Have a bevel modifier option to be the threshold to use for deciding membership (instead of hard-coded 0.5). I doubt this really solves the problem, because if you bevel beyond 0.5 in our example case, the interpolation will actually move membership more towards adjacent vertex bevel groups and there probably won't be ways of manipulating the threshold properly to get the intended effects. In my opinion, option 2 is the only workable one, but as I said there, kind of difficult to implement on short term. A workaround for the particular case in the bug report would be: use Bevel1 vgroup for the first bevel limit, but instead of Bevel2 for the second, specify that group using Bevel Edge Weights = 1.0 and the weight limit method. I realize there are many similar cases for which such a workaround won't be possible, sorry. I hope we can fix the bigger problem eventually.

Howard Trickey commented

2019-03-17 17:18:10 +01:00

Added subscriber: @ideasman42

Howard Trickey commented

2019-03-17 17:19:57 +01:00

Added Campbell to get his opinion too on how to solve this problem with vertex groups being used for membership and interpolation.

I thought of another possible fix for bevel:
4) add an option for user to say whether or not vertex groups should ALL be treated as membership groups and therefore not interpolated. This would solve the problem that I can't tell the purpose of a group. But yucch.

Added Campbell to get his opinion too on how to solve this problem with vertex groups being used for membership and interpolation. I thought of another possible fix for bevel: 4) add an option for user to say whether or not vertex groups should ALL be treated as membership groups and therefore not interpolated. This would solve the problem that I can't tell the purpose of a group. But yucch.

Howard Trickey commented

2019-03-18 12:29:33 +01:00

Changed status from 'Open' to: 'Archived'

Howard Trickey closed this issue

2019-03-18 12:29:33 +01:00

Howard Trickey commented

2019-03-18 12:29:33 +01:00

Even though the behavior is surprising, even to me, I am closing this bug for now as "working as intended", since the semantics of vertex groups and weights being interpolated is indeed as intended. I will add a point in my general bevel improvements request bug, #48583, to eventually fix this.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender 2.79b bevel in holes a bit odd #62649