Maniphest T69602

Bevel width in edit mode not clamping to surrounding vertices in all cases.
Closed, Archived
Actions

Assigned To
Howard Trickey (howardt)
Authored By
Lino Thomas (linolafett)
Sep 6 2019, 9:15 PM
Tags
  • BF Blender
Subscribers
Germano Cavalcante (mano-wii)
Howard Trickey (howardt)
Lino Thomas (linolafett)
William Reynish (billreynish)

Description

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: rBa94bf0e1349b
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:

  1. Open the attached file:

bevel_not_clamped.blend500 KBDownload

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

Thank you for your time!
-Lino

Related Objects

Event Timeline

Lino Thomas (linolafett) created this task.Sep 6 2019, 9:15 PM
William Reynish (billreynish) added a subscriber: William Reynish (billreynish).Sep 7 2019, 8:50 AM

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

I don’t think this is a bug.

Lino Thomas (linolafett) added a comment.EditedSep 7 2019, 11:04 AM

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 (mano-wii) assigned this task to Howard Trickey (howardt).Sep 24 2019, 3:29 PM
Germano Cavalcante (mano-wii) added subscribers: Howard Trickey (howardt), Germano Cavalcante (mano-wii).

@Howard Trickey (howardt), I suppose the "offset" behavior is working as intended, right?

Lino Thomas (linolafett) added a comment.Sep 24 2019, 7:44 PM

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 (howardt) changed the task status from Unknown Status to Unknown Status.Sep 28 2019, 1:19 AM

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, T48583. So I'm archiving this for now.

Lino Thomas (linolafett) added a comment.Sep 28 2019, 10:35 AM

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.