Bevel width in edit mode not clamping to surrounding vertices in all cases. #69602

New Issue

Lino Thomas · 2019-09-06T21:15:04+02:00

Lino Thomas commented

2019-09-06 21:15:04 +02:00

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.60

Blender Version
Broken: version: 2.81 (sub 8), branch: master, commit date: 2019-09-06 13:07, hash: a94bf0e134
Worked: (optional)

Short description of error
Hi,

the bevel operator is not being affected by surrounding edge loops(or vertices?) in all situations.
The results of the operation depend on the amount of selected edges to be beveled.

First the example, where the bevel results are as expected:

I have only two edges selected and increase the bevel width as much as i can.
The bevel will clamp to the "start/end" vertices of the selections.
As the selections are only single edges, the resulting bevel is clean, all edges are parallel (i am ignoring the intersecting vertices in the middle for now).

Where the bevel fails:

The same starting geometry, but with simply the middle edge also selected.
As we can see, increasing the bevel width will result in an uneven result. The edges are not parallel anymore.
Only at the "start/end" point of the selection, in this case the outer two vertices, the bevel is stopped correctly.

The expected result is, that the with of the bevel is clamped at the surrounding edge loops.
This is how the bevel in 3dsMax for example operates.

Exact steps for others to reproduce the error

Steps to reproduce:

Open the attached file:
bevel_not_clamped.blend
hit ctrl+b to bevel
Increase the bevel width as much a you can, the issue should be become apparent.
Optional: use the scroll wheel to add more subdivisions to the bevel to see the non parallel edges.

Thank you for your time!

Lino

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.60 **Blender Version** Broken: version: 2.81 (sub 8), branch: master, commit date: 2019-09-06 13:07, hash: `a94bf0e134` Worked: (optional) **Short description of error** Hi, the bevel operator is not being affected by surrounding edge loops(or vertices?) in all situations. The results of the operation depend on the amount of selected edges to be beveled. First the example, where the bevel results are as expected: ![Bevel_02.png](https://archive.blender.org/developer/F7720085/Bevel_02.png) I have only two edges selected and increase the bevel width as much as i can. The bevel will clamp to the "start/end" vertices of the selections. As the selections are only single edges, the resulting bevel is clean, all edges are parallel (i am ignoring the intersecting vertices in the middle for now). Where the bevel fails: ![Bevel_01.png](https://archive.blender.org/developer/F7720095/Bevel_01.png) The same starting geometry, but with simply the middle edge also selected. As we can see, increasing the bevel width will result in an uneven result. The edges are not parallel anymore. Only at the "start/end" point of the selection, in this case the outer two vertices, the bevel is stopped correctly. The expected result is, that the with of the bevel is clamped at the surrounding edge loops. This is how the bevel in 3dsMax for example operates. **Exact steps for others to reproduce the error** Steps to reproduce: 1) Open the attached file: [bevel_not_clamped.blend](https://archive.blender.org/developer/F7720103/bevel_not_clamped.blend) 2) hit ctrl+b to bevel 3) Increase the bevel width as much a you can, the issue should be become apparent. 4) Optional: use the scroll wheel to add more subdivisions to the bevel to see the non parallel edges. Thank you for your time! - Lino

Lino Thomas commented

2019-09-06 21:15:04 +02:00

Added subscriber: @LinoThomas

William Reynish commented

2019-09-07 08:50:34 +02:00

Added subscriber: @WilliamReynish

William Reynish commented

2019-09-07 08:50:34 +02:00

To get the desired result in this case, use Percentage.

I don’t think this is a bug.

To get the desired result in this case, use Percentage. I don’t think this is a bug.

Lino Thomas commented

2019-09-07 11:04:12 +02:00

Can confirm, that with percentage it does work.
Thank you for the quick reply.

Is then the default "offset" behaving like and end user would expect it?
It was sadly not clear to me and i thought i tried all the options in the operator (obviously i missed the percentage).

Can confirm, that with percentage it does work. Thank you for the quick reply. **Is then the default "offset" behaving like and end user would expect it?** It was sadly not clear to me and i thought i tried all the options in the operator (obviously i missed the percentage).

Germano Cavalcante commented

2019-09-24 15:29:27 +02:00

Added subscribers: @howardt, @mano-wii

Howard Trickey was assigned by Germano Cavalcante

2019-09-24 15:29:27 +02:00

Germano Cavalcante commented

2019-09-24 15:29:27 +02:00

@howardt, I suppose the "offset" behavior is working as intended, right?

Lino Thomas commented

2019-09-24 19:44:44 +02:00

If it is working as intended/designed, then i would reconsider the design.
Because right now when changing the "width type", it resets the "width" value, as percentage and the offset values are not compatible.
One is done in a 0-100% range the other uses a integer from 0-1.
The usual offset bevel is the preferred one as the percentage will not create even bevels you need most of the time.

I suggest changing the offset to have a setting to clamp to the nearby ede loops as shown in the images.
If this should be the default, is a different question i dont want to ask here.

If it is working as intended/designed, then i would reconsider the design. Because right now when changing the "width type", it resets the "width" value, as percentage and the offset values are not compatible. One is done in a 0-100% range the other uses a integer from 0-1. The usual offset bevel is the preferred one as the percentage will not create even bevels you need most of the time. I suggest changing the offset to have a setting to clamp to the nearby ede loops as shown in the images. If this should be the default, is a different question i dont want to ask here.

Howard Trickey commented

2019-09-28 01:19:54 +02:00

Changed status from 'Open' to: 'Archived'

Howard Trickey closed this issue

2019-09-28 01:19:54 +02:00

Howard Trickey commented

2019-09-28 01:19:54 +02:00

I had put some code in to clamp the sliding amount on "terminal edges" - those where the selection stops at a vertex. That's why you get the clamping result you want when you selected isolated edges. But I really intended one to use the 'clamp overlap' checkbox to cause clamping, and in retrospect I probably shouldn't have done that other clamping even when the box wasn't checked, because it confuses matters about when clamping happens.

Now, if you use 'clamp overlap', the clamping happens but it is a global clamping, so we don't get the result that it seems you want here -- for all of the bevels to continue until they clamp, even though that means a different clamp amount for each edge, or even each end of each edge (as you seem to want here). There are all sorts of arguments for all kinds of clamping, and I will likely add more eventually. It is a current ask that I have registered in my TODO task, #48583. So I'm archiving this for now.

I had put some code in to clamp the sliding amount on "terminal edges" - those where the selection stops at a vertex. That's why you get the clamping result you want when you selected isolated edges. But I really intended one to use the 'clamp overlap' checkbox to cause clamping, and in retrospect I probably shouldn't have done that other clamping even when the box wasn't checked, because it confuses matters about when clamping happens. Now, if you use 'clamp overlap', the clamping happens but it is a global clamping, so we don't get the result that it seems you want here -- for all of the bevels to continue until they clamp, even though that means a different clamp amount for each edge, or even each end of each edge (as you seem to want here). There are all sorts of arguments for all kinds of clamping, and I will likely add more eventually. It is a current ask that I have registered in my TODO task, #48583. So I'm archiving this for now.

Lino Thomas commented

2019-09-28 10:35:36 +02:00

Hey Howard,

thanks for your answer and work on the matter!
Yes a non global clamping would be appreciated, if i understand you correctly. Looking forward to your solution.

Hey Howard, thanks for your answer and work on the matter! Yes a non global clamping would be appreciated, if i understand you correctly. Looking forward to your solution.

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 width in edit mode not clamping to surrounding vertices in all cases. #69602