Page MenuHome

Bevel Weight not affecting Bevel modifier correctly
Closed, InvalidPublic


System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 418.81

Blender Version
Broken: version: 2.80 (sub 50), branch: master, commit date: 2019-03-18 21:39, hash: rBd47f827019f2
Also broken in other versions a couple of days older at least.
Also broken on 2.79 in (version: 2.79 (sub 7), branch: blender2.7, commit date: 2019-03-14 17:29, hash: 57b5852bc8b8)

Worked: works well on 2.79 stable (version: 2.79 (sub 0), branch: master, commit date: 2018-03-22 14:10, hash: f4dc9f9d68b)

Short description of error
Bevel weight not decreasing bevel smoothly as value decreases when two consecutive edges are being beveled.

Exact steps for others to reproduce the error
Create a look with 2 consecutive edges being affectd by bevel weight, one as a value of 1 and the other change the value with the slider.
if you do that with a bevel modifier, the bevel effect on the mesh will not change smoothly on the geometry.
If you do the same on 2.79 it works very well and smoothly.

I attached a video with a sample of the same function, how it works in 2.79 and in 2.8.

This works almost similarly with percentage method and works well, but I really need it to work with a specific value instead of a percentage, on a specific project.



Event Timeline

William Reynish (billreynish) triaged this task as Confirmed, Medium priority.

I can reproduce the difference in behavior here.

@Howard Trickey (howardt) I guess you can confirm if this is intended or not.

The behavior in 2.79 is not really intended -- it is more an accidental consequence of a choice made to solve conflicting specifications.
What the specifications say is that one edge is supposed to have one particular bevel width all the way along it, and the other edge (with the adjusting weight) is supposed to have another weight all the way along it. Where they meet is a conflict. The conflict used to be solved by taking an average, which gave the smooth tapering effect you saw. But for other cases (especially when there are loops) that is not nearly good enough, so I switched to using a least-squares optimization some time in the 2.79 series (I see that you note that this was working for a while in 2.79 and then stopped working, so maybe that was when I made this switch).

I will see if there is something wrong with the least-squares optimization that can be fixed that would bring the behavior back to what you hoped for.

Sorry, I am closing this as "working as intended" because the code is doing what I intended: that is, it is choosing to keep widths even along their edges as a higher priority than trying to half-way meet an unmeetable set of width constraints.

Others have asked for some kind of "taper" support, though usually on just one edge. I will add that idea to my list of feature requests, T48583.

Thank you,
that is sad for me unfortunately since there is no other way to do this in blender without just working on geometry and loosing editability :( this was a great feature for me, on this project and other stuff ive used it before (RIP).

I will keep using 2.79 on this project since this something vital for it, but I already miss the great new tools i've been using in 2.8.