Bevel operator calculates wrong offsets #78472

New Issue

Thor Ekle · 2020-06-30T21:42:23+02:00

Thor Ekle commented

2020-06-30 21:42:23 +02:00

System Information
Operating system: Win 10 Pro
Graphics card: nVidia GTX 2070 Super

Blender Version
Broken: 2.83.1
Worked: unknown; was broken in 2.79

Short description of error
The bevel operator calculates incorrect offsets for the new edges in some cases. In Offset mode, the distance from the original edge to the new edges is supposed to be "the distance of a new edge from the original." This is not true in many (most?) cases.

Exact steps for others to reproduce the error

Starting point is the default startup file.
Hit Tab to enter edit mode.
Hit Ctrl R to add an edge loop parallel to the Y axis, then Enter twice to confirm.
Hit Ctrl B, then enter 0.1 to specify the bevel offset.
Verify that the amount mode is Offset and the Segments is set to 1.
Observe that the X positions of the two new edges are 0.1 and -0.1, respectively -- this is expected behavior.
Undo all steps.
Enter face select mode, then select the face that is parallel with the Y axis and with an X position of -1.0.
Type S Y 0.5 and hit Enter to scale the face along the Y axis.
Hit Ctrl R to add an edge loop parallel to the Y axis, then Enter twice to confirm.
Hit Ctrl B, then enter 0.1 to specify the bevel offset.
Verify that the bevel settings are as above.
Observe that the X positions of the two new edges are 0.098462 and -0.098462, respectively -- this is NOT expected behavior.

The distances from the new edges to the original should be 0.1 in both cases.

**System Information** Operating system: Win 10 Pro Graphics card: nVidia GTX 2070 Super **Blender Version** Broken: 2.83.1 Worked: unknown; was broken in 2.79 **Short description of error** The bevel operator calculates incorrect offsets for the new edges in some cases. In Offset mode, the distance from the original edge to the new edges is supposed to be "the distance of a new edge from the original." This is not true in many (most?) cases. **Exact steps for others to reproduce the error** - Starting point is the default startup file. - Hit Tab to enter edit mode. - Hit Ctrl R to add an edge loop parallel to the Y axis, then Enter twice to confirm. - Hit Ctrl B, then enter 0.1 to specify the bevel offset. - Verify that the amount mode is Offset and the Segments is set to 1. - Observe that the X positions of the two new edges are 0.1 and -0.1, respectively -- this is expected behavior. - Undo all steps. - Enter face select mode, then select the face that is parallel with the Y axis and with an X position of -1.0. - Type S Y 0.5 and hit Enter to scale the face along the Y axis. - Hit Ctrl R to add an edge loop parallel to the Y axis, then Enter twice to confirm. - Hit Ctrl B, then enter 0.1 to specify the bevel offset. - Verify that the bevel settings are as above. - Observe that the X positions of the two new edges are 0.098462 and -0.098462, respectively -- this is NOT expected behavior. The distances from the new edges to the original should be 0.1 in both cases. ![bevel bug.jpg](https://archive.blender.org/developer/F8655750/bevel_bug.jpg)

Thor Ekle commented

2020-06-30 21:42:23 +02:00

Added subscriber: @thorie

Jesse Yurkovich commented

2020-06-30 21:56:41 +02:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2020-06-30 21:56:41 +02:00

In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2

In the meantime, the documentation for "Offset" mode should probably be reworded to better explain the parameters under which it operates.

In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2 In the meantime, the documentation for "Offset" mode should probably be reworded to better explain the parameters under which it operates.

Thor Ekle commented

2020-06-30 22:30:57 +02:00

I may be able to test 2.90 in a day or two -- thanks!

And I agree that the documentation should be reworded; it reads as if the distance is measured perpendicularly to the original edge. Which begs the question... how IS the distance currently measured?

In #78472#970069, @deadpin wrote:
In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2

In the meantime, the documentation for "Offset" mode should probably be reworded to better explain the parameters under which it operates.

I may be able to test 2.90 in a day or two -- thanks! And I agree that the documentation should be reworded; it reads as if the distance is measured perpendicularly to the original edge. Which begs the question... how IS the distance currently measured? > In #78472#970069, @deadpin wrote: > In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2 > > In the meantime, the documentation for "Offset" mode should probably be reworded to better explain the parameters under which it operates.

Richard Antalik commented

2020-07-01 00:25:37 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-07-01 00:25:37 +02:00

In #78472#970069, @deadpin wrote:
In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2

In the meantime, the documentation for "Offset" mode should probably be reworded to better explain the parameters under which it operates.

Does that work for you? It doesn't seem to produce desired result

> In #78472#970069, @deadpin wrote: > In 2.90 a new bevel mode called "Absolute" was added which should give you more expected results in both cases here. If possible can you check this in 2.90 to see if it solves your case? In both cases above the new edge segment generated by the bevel will be exactly 0.2 > > In the meantime, the documentation for "Offset" mode should probably be reworded to better explain the parameters under which it operates. Does that work for you? It doesn't seem to produce desired result

Richard Antalik commented

2020-07-01 00:28:41 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2020-07-01 00:28:41 +02:00

I can confirm this based on documentation, I think it's worded quite precisely

Thor Ekle commented

2020-07-01 00:40:27 +02:00

In #78472#970117, @iss wrote:
I can confirm this based on documentation, I think it's worded quite precisely

Sorry to be so dense... but I'm not sure I understand? Are you saying the documentation is worded precisely or that my bug report is? :)

> In #78472#970117, @iss wrote: > I can confirm this based on documentation, I think it's worded quite precisely Sorry to be so dense... but I'm not sure I understand? Are you saying the documentation is worded precisely or that my bug report is? :)

Richard Antalik commented

2020-07-02 00:21:39 +02:00

I think that documentation is worded quite precisely, and it does not match actual behavior.

Thor Ekle commented

2020-07-02 01:36:02 +02:00

In #78472#970999, @iss wrote:
I think that documentation is worded quite precisely, and it does not match actual behavior.

Right -- we are on the same page.

> In #78472#970999, @iss wrote: > I think that documentation is worded quite precisely, and it does not match actual behavior. Right -- we are on the same page.

Thor Ekle commented

2020-09-02 15:06:00 +02:00

I just tested this in 2.90, and the new Absolute mode does not solve the issue described in the initial post.

While the length of the new edge segment is 0.2 in this mode, the distance between the two loops (obviously) is not -- and this was the original problem. None of the modes create new loops with a distance of 0.1 from the original loop. It seems more important to correctly calculate this distance than the length of the new segment(s).

As an aside, the M shortcut key (to switch between modes before confirming) seems to skip the new Absolute mode. Let me know if you want me to report that separately.

I just tested this in 2.90, and the new Absolute mode does not solve the issue described in the initial post. While the length of the new edge segment is 0.2 in this mode, the distance between the two loops (obviously) is not -- and this was the original problem. None of the modes create new loops with a distance of 0.1 from the original loop. It seems more important to correctly calculate this distance than the length of the new segment(s). As an aside, the M shortcut key (to switch between modes before confirming) seems to skip the new Absolute mode. Let me know if you want me to report that separately.

Howard Trickey commented

2020-09-23 05:21:54 +02:00

Added subscriber: @howardt

Howard Trickey commented

2020-09-23 05:21:54 +02:00

The code is working as intended.
Sometimes it is impossible to get the offset to be the exact amount specified on all edges simultaneously. This is the case in the example you have explained how to construct. When this happens, bevel has to do the best it can in an overconstrained situation, which will mean some (maybe all) of the actual offsets will be slightly off.

Note that if you remove all but the top of the second cube (the one with the scaled face), then do the bevel, you get the x values as you expect -- 0.1 and -0.1, as they should be (measured perpendicularly from the original edge at x = 0).

Now look at the sides of the second cube. because they aren't parallel to the x-axis, the distance measured perpendicularly from the center edge loop is longer than the distance measured perpendicularly from the center edge loop on the top and bottom. It is impossible to have the distance be the offset on all four sides and still have them meet at the same place on the 4 edges going (roughly) in the x-direction. I regard it as more expected that bevel not split the connection point on those 4 edges than that it exactly obey the offset specification.

Should I change the documentation to explicitly say that sometimes it is impossible to satisfy all of the offset requirements simultaneously?

The code is working as intended. Sometimes it is impossible to get the offset to be the exact amount specified on all edges simultaneously. This is the case in the example you have explained how to construct. When this happens, bevel has to do the best it can in an overconstrained situation, which will mean some (maybe all) of the actual offsets will be slightly off. Note that if you remove all but the top of the second cube (the one with the scaled face), then do the bevel, you get the x values as you expect -- 0.1 and -0.1, as they should be (measured perpendicularly from the original edge at x = 0). Now look at the *sides* of the second cube. because they aren't parallel to the x-axis, the distance measured perpendicularly from the center edge loop is *longer* than the distance measured perpendicularly from the center edge loop on the top and bottom. It is impossible to have the distance be the offset on all four sides and still have them meet at the same place on the 4 edges going (roughly) in the x-direction. I regard it as *more* expected that bevel not split the connection point on those 4 edges than that it exactly obey the offset specification. Should I change the documentation to explicitly say that sometimes it is impossible to satisfy all of the offset requirements simultaneously?

Thor Ekle commented

2020-09-23 12:08:17 +02:00

I see your point, and I definitely think the documentation should be changed as you suggest.

However, this does not solve the issue from the user point of view. I think it's safe to say that most users expect the behavior I described in the initial post -- and that should be an important consideration.

One approach would be to give precedence to the current transformation orientation (global, local or custom) when calculating the offset. In my example, the intent clearly is to calculate the offset along the local X-axis; the distance measured along the side is not of interest. And in case the user actually wants to measure the distance along the side, it's a simple matter of adding a custom orientation.

This approach would let the user decide which offset requirements are important and have those calculated according to the user's needs, rather than having potentially all offsets fail to obey the specification.

Given that the UI already has a prominent and easy-to-use transform orientation selector, making this change need not affect the UI at all -- unless you want to give users the option of reverting to the old behavior; that would require a checkbox. Alternatively, this could be implemented as a new mode.

Regardless, I think this would be an important improvement that's also in line with the basic behavior of blender; GS&R all obey the selected transform orientation, for example.

In #78472#1021374, @howardt wrote:
The code is working as intended.
Sometimes it is impossible to get the offset to be the exact amount specified on all edges simultaneously.

I see your point, and I definitely think the documentation should be changed as you suggest. However, this does not solve the issue from the user point of view. I think it's safe to say that most users expect the behavior I described in the initial post -- and that should be an important consideration. One approach would be to give precedence to the current transformation orientation (global, local or custom) when calculating the offset. In my example, the intent clearly is to calculate the offset along the local X-axis; the distance measured along the side is not of interest. And in case the user actually wants to measure the distance along the side, it's a simple matter of adding a custom orientation. This approach would let the user decide which offset requirements are important and have those calculated according to the user's needs, rather than having potentially all offsets fail to obey the specification. Given that the UI already has a prominent and easy-to-use transform orientation selector, making this change need not affect the UI at all -- unless you want to give users the option of reverting to the old behavior; that would require a checkbox. Alternatively, this could be implemented as a new mode. Regardless, I think this would be an important improvement that's also in line with the basic behavior of blender; GS&R all obey the selected transform orientation, for example. > In #78472#1021374, @howardt wrote: > The code is working as intended. > Sometimes it is impossible to get the offset to be the exact amount specified on all edges simultaneously.

Howard Trickey commented

2020-09-23 13:15:03 +02:00

Changed status from 'Confirmed' to: 'Archived'

Howard Trickey closed this issue

2020-09-23 13:15:03 +02:00

Howard Trickey self-assigned this 2020-09-23 13:15:03 +02:00

Howard Trickey commented

2020-09-23 13:15:03 +02:00

"most users expect the behavior described in the initial post"

Really? I think there is an equally valid expectation that ALL edges selected to be beveled get the right offset. In your mind, you were trying to get a particular width along the x axis, but others might be trying to get a constant width of the band on the surface of the object that the band is going around (which is impossible, as I've pointed out, but as a user, that would be MY expectation).

I'm not totally opposed to tie-breaking rules but am dubious that a rule like "prefer to get the width right on edges most perpendicular to the x axis of the current transform" is useful enough to go to the effort of programming that in (I'd have to change the structure of the code somewhat to pass that transform in, and it will get kind of ugly because the transform isn't always available or relevant (think: API and modifiers). So I'm not going to implement this tie breaking rule right now. If you think this is wrong, and an essential necessity, try drumming up support for this point of view on BlenderArtists or blender.devtalk and I might change my mind.

For now, I'm going to close this thread and update the blender manual as I proposed above.

"most users expect the behavior described in the initial post" Really? I think there is an equally valid expectation that ALL edges selected to be beveled get the right offset. In your mind, you were trying to get a particular width along the x axis, but others might be trying to get a constant width of the band on the surface of the object that the band is going around (which is impossible, as I've pointed out, but as a user, that would be MY expectation). I'm not totally opposed to tie-breaking rules but am dubious that a rule like "prefer to get the width right on edges most perpendicular to the x axis of the current transform" is useful enough to go to the effort of programming that in (I'd have to change the structure of the code somewhat to pass that transform in, and it will get kind of ugly because the transform isn't always available or relevant (think: API and modifiers). So I'm not going to implement this tie breaking rule right now. If you think this is wrong, and an essential necessity, try drumming up support for this point of view on BlenderArtists or blender.devtalk and I might change my mind. For now, I'm going to close this thread and update the blender manual as I proposed above.

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

Bevel operator calculates wrong offsets #78472