Bevel Improvements #48583

New Issue

Howard Trickey · 2016-06-03T16:42:12+02:00

Howard Trickey commented

2016-06-03 16:42:12 +02:00

Blender users have many desires for improvements to the Bevel tool and Modifier. This task is for exploring priorities for implementing those, as well as designs for doing so.

Some current TODOs and feature requests

generalize to handle several manifold sheets touching at a point (see #34678).
improve clamping code (see #38871).
more options, e.g., spline spec for profile shape (see #40722) and vertex blends with setbacks.
treat more cases like "pipe" to avoid bulges (see #40258)
option to have bevel not create n-gons (see bf-funboard thread)
sometimes leaves degenerate geometry (#48174)
tapered bevel influence by vertex weight - see https://rightclickselect.com/p/modeling/Wkbbbc/bevel-modifier-influenced-by-vertex-weight. Also #62739 where method isn't suggested -- could also let user set different widths at the two ends of a bevel.
merging of vertices that coincide after beveling (#61214)
better way of specifying vertices in modifier, and even better, a way of specifying edges (#62649) (edge group?)
bevel-after-booleans
option to make vertex group out of all vertices created in bevel
method to have bevel modifier affect curve objects
have angle limit method available in tool (as is already in modifier)
have clamp be local rather than global (or in addition to global?)
"support loop" option - extra loop of edges flat on adjacent faces
use bevel-like code to add new option to extrude (edge, vertex) that keeps geometry manifold (billrey idea in GSoC 2018 thread)
vertex mesh that has the effect of booleaning the edge profiles to have the effect of real-world material removal
profile superellipse arc should not use quarter-ellipse arc always, but rather rather the segment that hits adjacent faces tangentwise
beveling a face as an option in addition to beveling edges and vertices (starts to look like inset)
width method like Percent but where absolute distance along adjacent edges is equal to spec instead of percentage
option to round the terminal edge triangle
special case segments=2, profile=1 case to avoid diagonal edges on cube corners when smaller and large widths mixed

Following comments will have some initial explorations of the problems and designs for solving each of these.

Blender users have many desires for improvements to the Bevel tool and Modifier. This task is for exploring priorities for implementing those, as well as designs for doing so. **Some current TODOs and feature requests** * generalize to handle several manifold sheets touching at a point (see #34678). * improve clamping code (see #38871). * more options, e.g., spline spec for profile shape (see #40722) and vertex blends with setbacks. * treat more cases like "pipe" to avoid bulges (see #40258) * option to have bevel not create n-gons (see bf-funboard thread) * sometimes leaves degenerate geometry (#48174) * tapered bevel influence by vertex weight - see https://rightclickselect.com/p/modeling/Wkbbbc/bevel-modifier-influenced-by-vertex-weight. Also #62739 where method isn't suggested -- could also let user set different widths at the two ends of a bevel. * merging of vertices that coincide after beveling (#61214) * better way of specifying vertices in modifier, and even better, a way of specifying edges (#62649) (edge group?) * bevel-after-booleans * option to make vertex group out of all vertices created in bevel * method to have bevel modifier affect curve objects * have angle limit method available in tool (as is already in modifier) * have clamp be local rather than global (or in addition to global?) * "support loop" option - extra loop of edges flat on adjacent faces * use bevel-like code to add new option to extrude (edge, vertex) that keeps geometry manifold (billrey idea in GSoC 2018 thread) * vertex mesh that has the effect of booleaning the edge profiles to have the effect of real-world material removal * profile superellipse arc should not use quarter-ellipse arc always, but rather rather the segment that hits adjacent faces tangentwise * beveling a face as an option in addition to beveling edges and vertices (starts to look like inset) * width method like Percent but where absolute distance along adjacent edges is equal to spec instead of percentage * option to round the terminal edge triangle * special case segments=2, profile=1 case to avoid diagonal edges on cube corners when smaller and large widths mixed Following comments will have some initial explorations of the problems and designs for solving each of these.

Howard Trickey commented

2016-06-03 16:42:12 +02:00

Changed status to: 'Open'

Howard Trickey commented

2016-06-03 16:42:12 +02:00

Added subscriber: @howardt

Howard Trickey self-assigned this 2016-06-03 16:43:28 +02:00

Howard Trickey commented

2016-06-03 16:43:28 +02:00

Removed subscriber: @howardt

Howard Trickey commented

2016-06-03 17:47:00 +02:00

Better handling of profile = 1, profile = 0.25, and implement profile = 0 cases

The current code for the "vmesh" (vertex mesh) at the corners of edge bevels is approximately this:

Build "profile triangles" across the ends of beveled edges, near the beveled vertex.
Build "boundaries" by putting multi-segment lines in the profile triangles. The "profile" parameter controls the shape that the multisegment lines are trying to approximate. If the triangle is a right triangle, the profile parameter has these special cases:
0.5 : a quarter circular arc 0.25 : follows the flat hypotenuse
1.0 : follows the straight lines that complete a square on the other side of the hypotenuse 0.0 : follows the two non-hypotenuse sides of the triangle
** (in general, the profile is a scaled version of the "super-ellipse" parameter)
If the profile triangle is not a right triangle, the above profiles are scaled / stretched / rotated into the position of the actual profile triangle.
Add a center vertex at the vertex where the beveled edges meet, or somewhere else along the vertex normal of that vertex.
Use a modified cubic subdivision scheme (that keeps boundaries intact) to form the vmesh.

This works OK in the general case, but people have more expectations for the special case profile parameters.

Profile = 1
I think there needs to be special case code, totally different from the above algorithm. What I imagine is:

For each triangle formed by a two successive boundary vertices and the original vertex:
Complete the parallelogram by adding a 4th vertex in the shared face. Rule the parallelogram with parallel rule lines, as per the number of segments. The intersections of those rule lines are the internal vertices of the vmesh.
**When the number of segments is odd, you have to have "straddling" faces across the beveled edges, unfortunately.Profile = 0This case isn't even implemented at all yet, because the current code would build a vmesh that collapses to lines, and we don't want to build all of those 0-area faces and overlapping vertices. So this also needs special case code, pretty analogous to the profile=1 case.Profile = 0.25
Here the users expect the vmesh to all lie on a perfectly flat plane. The general algorithm doesn't guarantee that. Now it won't even be possible to get them all on a flat plane -- the boundary vertices may not all be coplanar. But if they are, one approach to making this case better would be to project the generated vmesh onto the shared plane of the boundary vertices, as a postprocessing step.

**Better handling of profile = 1, profile = 0.25, and implement profile = 0 cases** The current code for the "vmesh" (vertex mesh) at the corners of edge bevels is approximately this: * Build "profile triangles" across the ends of beveled edges, near the beveled vertex. * Build "boundaries" by putting multi-segment lines in the profile triangles. The "profile" parameter controls the shape that the multisegment lines are trying to approximate. If the triangle is a right triangle, the profile parameter has these special cases: **0.5 : a quarter circular arc** 0.25 : follows the flat hypotenuse **1.0 : follows the straight lines that complete a square on the other side of the hypotenuse** 0.0 : follows the two non-hypotenuse sides of the triangle ** (in general, the profile is a scaled version of the "super-ellipse" parameter) * If the profile triangle is not a right triangle, the above profiles are scaled / stretched / rotated into the position of the actual profile triangle. * Add a center vertex at the vertex where the beveled edges meet, or somewhere else along the vertex normal of that vertex. * Use a modified cubic subdivision scheme (that keeps boundaries intact) to form the vmesh. This works OK in the general case, but people have more expectations for the special case profile parameters. **Profile = 1** I think there needs to be special case code, totally different from the above algorithm. What I imagine is: * For each triangle formed by a two successive boundary vertices and the original vertex: **Complete the parallelogram by adding a 4th vertex in the shared face.** Rule the parallelogram with parallel rule lines, as per the number of segments. The intersections of those rule lines are the internal vertices of the vmesh. **When the number of segments is odd, you have to have "straddling" faces across the beveled edges, unfortunately.**Profile = 0**This case isn't even implemented at all yet, because the current code would build a vmesh that collapses to lines, and we don't want to build all of those 0-area faces and overlapping vertices. So this also needs special case code, pretty analogous to the profile=1 case.**Profile = 0.25** Here the users expect the vmesh to all lie on a perfectly flat plane. The general algorithm doesn't guarantee that. Now it won't even be possible to get them all on a flat plane -- the boundary vertices may not all be coplanar. But if they are, one approach to making this case better would be to project the generated vmesh onto the shared plane of the boundary vertices, as a postprocessing step.

cédric lepiller commented

2016-06-03 19:14:57 +02:00

Added subscriber: @cedriclepiller

cédric lepiller commented

2016-06-03 19:14:57 +02:00

Ok, so having pictures could help to see the goals.

Profile = 1, right now we have this.

http://pitiwazou.com/screenshots/blender_2016-06-02_09-42-27.jpg

The goal would be to have a perfect result with the same space between each point for the width.

http://pitiwazou.com/screenshots/blender_2016-06-02_09-46-32.jpg

Profile = 0.5, Much better than before, but still deformed.

http://pitiwazou.com/screenshots/2016-06-03_19-12-09.gif

Ok, so having pictures could help to see the goals. **Profile = 1**, right now we have this. http://pitiwazou.com/screenshots/blender_2016-06-02_09-42-27.jpg The goal would be to have a perfect result with the same space between each point for the width. http://pitiwazou.com/screenshots/blender_2016-06-02_09-46-32.jpg **Profile = 0.5**, Much better than before, but still deformed. http://pitiwazou.com/screenshots/2016-06-03_19-12-09.gif

Piotr Adamowicz commented

2016-06-03 19:17:56 +02:00

Added subscriber: @MadMinstrel

michael knubben commented

2016-06-03 22:18:05 +02:00

Added subscriber: @michaelknubben

Howard Trickey commented

2016-06-05 14:13:35 +02:00

A "Harden Normals" Option

Currently, after a bevel, the way vertex normals are calculated in Blender by default gives tilted vertex normals at the boundaries between the new polygons made along the beveled edges, and the original faces adjacent to those edges (I call those the "reconstructed polygons", because they get reconstructed using some new vertices created as a result of the bevel).

See:

If you use smooth shading on this model, then when hardbody modeling, an artist would usually desire that the original faces of something like a cube would be shaded flat after a bevel - the smooth shading should only affect the beveled edges and corners. Yet in the default case, we get shading artifacts due to the bent vertex normals and the way the faces are triangulated before shading:

Now that Blender has the ability to have split custom normals at vertices, we can adjust the vertex normals if we like. One possible adjustment would be to simply ignore the edge polygons when calculating custom vertex normals at vertices involved in reconstructed polygons. There is an addon, Y.A.V.N.E. (yet another vertex normal editor) -- https://github.com/fedackb/yavne -- which can be used to see what this would look like. With that addon, one can set the "strength" of a face to one of weak, medium, and strong. And then it sets custom vertex normals that only use faces in the maximum strength set found around a given vertex. Using that to set the edge and corner polygons to weak, we get these normals (magenta are the new custom normals; blue are the original ones).

And shaded it looks like:

Notice that this fixes the artifacts on the big flat faces, but the beveled edges don't shade all that well (triangle artifacts still visible). However, if the bevel is smaller and/or has more segments, the result looks pretty good:

Design

I think this should be an option, not something that happens every time, because it requires that the mesh be autosmoothed (a prerequisite for having custom split normals), and it adds a data layer to the object. And the result may not always be better.

A big choice in the design is which of these two things to do:

Do the normal adjustment as a last step of bevel, if some (to-be-added) option flag is set.
Add a new custom data layer in the mesh to keep track of which faces are the bevel's 'edge', 'vertex', and 'reconstructed' faces. Then provide a separate tool and modifier that will "harden bevel normals", reading that custom layer to find out where the reconstructed faces are and which adjacent faces were made by bevel. A variant of 2, call it '2b', would be to just implement the YAVNE code in C as a core part of Blender, and have bevel use YAVNE's existing 'face strength' custom data layer to tag the different kinds of bevel polygons.

The advantage of 1 is ease and discoverability. Artists will naturally see the option and decide whether or not to use it during the course of doing a bevel. And workflow is as easy as ticking a box. Whereas method 2 requires artists to remember to run another tool or apply another modifier after doing a bevel. Another advantage of 1 is that it doesn't require the storage of a new custom data layer in the mesh. For very large meshes, this can be an issue. A final advantage is just that 1 simpler to implement so could be developed more quickly.

The advantage of 2 is that it might survive more topological changes (in the modifier case). That is: the split custom normals, after having been set, may go wrong later if certain topological changes happen around the bevel. Then one might need something like YAVNE to repair. An advantage of 2b would be that the YAVNE tool is generally useful and perhaps deserves to be put into core Blender. A disadvantage of 2 is that it requires more storage, for the additional custom data layer. And if you do this as a modifier, it is hard to make that custom data layer go away if you remove the modifier (because: who knows whether that was the only reason the layer was added?), so the additional storage may linger after one wishes it were gone.

For now I propose doing method 1 -- just doing the adjustment as part of the bevel operation. But let's hear opposing views on this design task.

I propose adding a new option to the bevel tool, "Adjust Normals":

What should it do if activated and the mesh doesn't have autosmoothed enabled? The two choices are (A) enable it for the user; or (B) print an error message telling the user to enable it and do nothing. The YAVNE editor does A, the Normal Editor modifier does B. I think I will emulate the Normal Editor modifier and print an error message, as that is less likely to surprise users with a hidden state change on their model.

**A "Harden Normals" Option** Currently, after a bevel, the way vertex normals are calculated in Blender by default gives tilted vertex normals at the boundaries between the new polygons made along the beveled edges, and the original faces adjacent to those edges (I call those the "reconstructed polygons", because they get reconstructed using some new vertices created as a result of the bevel). See: ![pasted_file](https://archive.blender.org/developer/F316045/pasted_file) If you use smooth shading on this model, then when hardbody modeling, an artist would usually desire that the original faces of something like a cube would be shaded flat after a bevel - the smooth shading should only affect the beveled edges and corners. Yet in the default case, we get shading artifacts due to the bent vertex normals and the way the faces are triangulated before shading: ![pasted_file](https://archive.blender.org/developer/F316047/pasted_file) Now that Blender has the ability to have split custom normals at vertices, we can adjust the vertex normals if we like. One possible adjustment would be to simply ignore the edge polygons when calculating custom vertex normals at vertices involved in reconstructed polygons. There is an addon, Y.A.V.N.E. (yet another vertex normal editor) -- https://github.com/fedackb/yavne -- which can be used to see what this would look like. With that addon, one can set the "strength" of a face to one of weak, medium, and strong. And then it sets custom vertex normals that only use faces in the maximum strength set found around a given vertex. Using that to set the edge and corner polygons to weak, we get these normals (magenta are the new custom normals; blue are the original ones). ![pasted_file](https://archive.blender.org/developer/F316049/pasted_file) And shaded it looks like: ![pasted_file](https://archive.blender.org/developer/F316052/pasted_file) Notice that this fixes the artifacts on the big flat faces, but the beveled edges don't shade all that well (triangle artifacts still visible). However, if the bevel is smaller and/or has more segments, the result looks pretty good: ![pasted_file](https://archive.blender.org/developer/F316054/pasted_file) **Design** I think this should be an option, not something that happens every time, because it requires that the mesh be autosmoothed (a prerequisite for having custom split normals), and it adds a data layer to the object. And the result may not always be better. A big choice in the design is which of these two things to do: 1. Do the normal adjustment as a last step of bevel, if some (to-be-added) option flag is set. 2. Add a new custom data layer in the mesh to keep track of which faces are the bevel's 'edge', 'vertex', and 'reconstructed' faces. Then provide a separate tool and modifier that will "harden bevel normals", reading that custom layer to find out where the reconstructed faces are and which adjacent faces were made by bevel. A variant of 2, call it '2b', would be to just implement the YAVNE code in C as a core part of Blender, and have bevel use YAVNE's existing 'face strength' custom data layer to tag the different kinds of bevel polygons. The advantage of 1 is ease and discoverability. Artists will naturally see the option and decide whether or not to use it during the course of doing a bevel. And workflow is as easy as ticking a box. Whereas method 2 requires artists to remember to run another tool or apply another modifier after doing a bevel. Another advantage of 1 is that it doesn't require the storage of a new custom data layer in the mesh. For very large meshes, this can be an issue. A final advantage is just that 1 simpler to implement so could be developed more quickly. The advantage of 2 is that it might survive more topological changes (in the modifier case). That is: the split custom normals, after having been set, may go wrong later if certain topological changes happen around the bevel. Then one might need something like YAVNE to repair. An advantage of 2b would be that the YAVNE tool is generally useful and perhaps deserves to be put into core Blender. A disadvantage of 2 is that it requires more storage, for the additional custom data layer. And if you do this as a modifier, it is hard to make that custom data layer go away if you remove the modifier (because: who knows whether that was the only reason the layer was added?), so the additional storage may linger after one wishes it were gone. For now I propose doing method 1 -- just doing the adjustment as part of the bevel operation. But let's hear opposing views on this design task. I propose adding a new option to the bevel tool, "Adjust Normals": ![pasted_file](https://archive.blender.org/developer/F316056/pasted_file) What should it do if activated and the mesh doesn't have autosmoothed enabled? The two choices are (A) enable it for the user; or (B) print an error message telling the user to enable it and do nothing. The YAVNE editor does A, the Normal Editor modifier does B. I think I will emulate the Normal Editor modifier and print an error message, as that is less likely to surprise users with a hidden state change on their model.

Vuk Gardašević commented

2016-06-05 16:05:21 +02:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2016-06-05 16:05:21 +02:00

There is a third option :

The option is grayed out until auto smooth is enabled and the info about it could be in the tooltip: Available only if Auto Smooth is enabled for the object.

It can be achieved with a Poll Operator check for auto smooth or activating the checkbox only if it the precondition is met (with .active = condition).

There is a third option : The option is grayed out until auto smooth is enabled and the info about it could be in the tooltip: Available only if Auto Smooth is enabled for the object. It can be achieved with a Poll Operator check for auto smooth or activating the checkbox only if it the precondition is met (with .active = condition).

cédric lepiller commented

2016-06-05 16:33:21 +02:00

Since it's bevel related, could it be possible to add the profile in the modal of the bevel ?
Right now, we can change offset, segments etc but not the profile.

Since it's bevel related, could it be possible to add the profile in the modal of the bevel ? Right now, we can change offset, segments etc but not the profile.

Howard Trickey commented

2016-06-06 05:02:00 +02:00

Cédric: do you have a suggestion for how to control the profile during modal? I guess maybe some hotkey to hold down to make the mouse movement affect the profile rather than the offset? Any suggestion for which key, if so?

cédric lepiller commented

2016-06-06 09:40:58 +02:00

Ctrl or P for profile.

Ctrl is easier to reach fast and we could use Ctrl + Shift to decrease the speed.

Ctrl or P for profile. Ctrl is easier to reach fast and we could use Ctrl + Shift to decrease the speed.

Howard Trickey commented

2016-06-06 19:22:49 +02:00

Cédric: OK, I commited (with commit c8e9e6dda0) a change to have the P key toggle in and out of 'adjust profile' mode. I decided to use P rather the Ctrl since Ctrl-B enters bevel and maybe people could continue to hold Ctrl. (Maybe not. At any rate, the P key works and has a good mnemonic meaning.) The Shift key decreases the speed, as suggested (and as it does for decreasing speed of offset adjustment, in normal modal use).

Cédric: OK, I commited (with commit c8e9e6dda0) a change to have the P key toggle in and out of 'adjust profile' mode. I decided to use P rather the Ctrl since Ctrl-B enters bevel and maybe people could continue to hold Ctrl. (Maybe not. At any rate, the P key works and has a good mnemonic meaning.) The Shift key decreases the speed, as suggested (and as it does for decreasing speed of offset adjustment, in normal modal use).

cédric lepiller commented

2016-06-06 19:26:00 +02:00

Ok good !

Thank you ;)

Ok good ! Thank you ;)

Piotr Adamowicz commented

2016-06-08 12:50:31 +02:00

Regarding the design, we'd optimally want to have both solutions - to have the checkbox method, but also have a button next to it that creates the custom data layer. I realize this is the most work of course. YAVNE's functionality is generally very useful and shouldn't IMO be relegated to an obscure addon.

cédric lepiller commented

2016-06-08 13:03:57 +02:00

Do you think it's possible to make this kind of result for the bevel ?

http://pitiwazou.com/screenshots/blender_2016-06-08_13-03-49.jpg

http://pitiwazou.com/screenshots/2016-06-08_12-59-13.mp4

Do you think it's possible to make this kind of result for the bevel ? http://pitiwazou.com/screenshots/blender_2016-06-08_13-03-49.jpg http://pitiwazou.com/screenshots/2016-06-08_12-59-13.mp4

Howard Trickey commented

2016-06-08 13:30:16 +02:00

Cédric: yes, it is possible. The 4th bullet point of this design task "more options ..." is intended to explore this. In particular, the "with setbacks" part of that statement would address what you want here, I think.

Right now I am working on the harden normals task, which is likely to take a week or so. But will start designing the "with setbacks" task after harden normals, I think.

Cédric: yes, it is possible. The 4th bullet point of this design task "more options ..." is intended to explore this. In particular, the "with setbacks" part of that statement would address what you want here, I think. Right now I am working on the harden normals task, which is likely to take a week or so. But will start designing the "with setbacks" task after harden normals, I think.

cédric lepiller commented

2016-06-08 13:36:03 +02:00

Ok Great !

cédric lepiller commented

2016-06-08 16:54:26 +02:00

Ok, just tested the new build, this is nice, thx a lot ;)

After changing the profile, we press P to change the width, can you restore the previous width value to not have to reduce a lot the actual width.

An example :

http://pitiwazou.com/screenshots/2016-06-08_16-50-28.mp4

On speedflow we keep the width, like that we can change other settings and comeback easilly with the previous width.

Ok, just tested the new build, this is nice, thx a lot ;) After changing the profile, we press P to change the width, can you restore the previous width value to not have to reduce a lot the actual width. An example : http://pitiwazou.com/screenshots/2016-06-08_16-50-28.mp4 On speedflow we keep the width, like that we can change other settings and comeback easilly with the previous width.

Howard Trickey commented

2016-06-08 16:58:42 +02:00

Ah, good point about maintaining the existing width even if the mouse moves to a different place during profile adjustment. I will fix this.

cédric lepiller commented

2016-06-08 20:13:33 +02:00

Cool thx !

Could it be possible to do the same for segments with S ?

Right now, we can only use the mouse or + and -, if we press S we could change the segments with the mouse deplacement or a number.
S exit this mode and we are in width mode.

Like that we could easilly change the settings for pen and mouse.

Cool thx ! Could it be possible to do the same for segments with S ? Right now, we can only use the mouse or + and -, if we press S we could change the segments with the mouse deplacement or a number. S exit this mode and we are in width mode. Like that we could easilly change the settings for pen and mouse.

Howard Trickey commented

2016-06-08 21:11:11 +02:00

Good idea. I will do that too, I think.

Howard Trickey commented

2016-06-13 15:24:28 +02:00

With commit 520691e591 you can now control segments with mouse after S toggle. And I fixed the problem with resuming changing offset at the last point you left off, after changing segments or profile with the mouse. And I added the ability to set the segments or profile with numeric input when you are in the P or S mode, respectively.

With commit 520691e591 you can now control segments with mouse after S toggle. And I fixed the problem with resuming changing offset at the last point you left off, after changing segments or profile with the mouse. And I added the ability to set the segments or profile with numeric input when you are in the P or S mode, respectively.

cédric lepiller commented

2016-06-13 15:30:59 +02:00

Yeah ! Well done, that will be really easy to use, thx ;)

rafael nolasco commented

2016-06-25 03:00:44 +02:00

Added subscriber: @kakachiex2

Bartosz Moniewski commented

2016-07-21 00:25:12 +02:00

Added subscriber: @BartekMoniewski

Howard Trickey commented

2016-08-29 15:07:46 +02:00

Another feature request: see #49173. The desire is to get inward curving profiles for vertex bevels on convex corners. E.g.

Another feature request: see #49173. The desire is to get inward curving profiles for vertex bevels on convex corners. E.g. ![Multisegment_Bevel.png](https://archive.blender.org/developer/F347082/Multisegment_Bevel.png)

Howard Trickey commented

2016-09-07 13:45:03 +02:00

Another feature request (from bf-funboard mailing list): a different number of segments for preview vs render.

marc dion commented

2017-03-06 02:19:58 +01:00

Added subscriber: @MarcClintDion

marc dion commented

2017-03-06 02:19:58 +01:00

To start, I love the new shortcuts added,(p and s)

One of the features I'd like to see added is the ability to quickly locate the vertices that are triggering the clamp overlap response for the modifier.
I usually join models together for texture baking and often once they are joined, the bevel radius for every component is reduced because somewhere there are two or more vertices that are too close together. Finding them can be difficult and time consuming.
It would be nice if those vertices could be added to the edit mode selection so they can be zoomed in on without having to search.

Currently(at least for default) there is a corner-cap triangle created for three edges that come together at 90 degree corners. A real-world machinist carving 3 beveled edges would end up something more like the following image, I think that would be a nice option to have. (a cube with multiple boolean operations and a picture from a counter-top manufacturer)

Here is a link to the counter-top website because it brings me to my next thought. :) Custom profile edges for the bevel modifier, they could be made using curves similar to how curves are used to create profiles for curves. http://granite.filesmonster.co/1239/granite-countertop-edges-pictures

The ability to easily taper bevels using Vertices Data->Mean Bevel Weights should eliminate the jagged pattern created by Edges Data->Mean Bevel Weights in conjunction with the Modifier set to Weight (I don't think we have that option unless I'm missing something...)

The End, and thanks Howard for being thoughtful and friendly :)

To start, I love the new shortcuts added,(p and s) One of the features I'd like to see added is the ability to quickly locate the vertices that are triggering the clamp overlap response for the modifier. I usually join models together for texture baking and often once they are joined, the bevel radius for every component is reduced because somewhere there are two or more vertices that are too close together. Finding them can be difficult and time consuming. It would be nice if those vertices could be added to the edit mode selection so they can be zoomed in on without having to search. ------------------------- Currently(at least for default) there is a corner-cap triangle created for three edges that come together at 90 degree corners. A real-world machinist carving 3 beveled edges would end up something more like the following image, I think that would be a nice option to have. (a cube with multiple boolean operations and a picture from a counter-top manufacturer) ![Screenshot (248).png](https://archive.blender.org/developer/F503710/Screenshot__248_.png) Here is a link to the counter-top website because it brings me to my next thought. :) Custom profile edges for the bevel modifier, they could be made using curves similar to how curves are used to create profiles for curves. http://granite.filesmonster.co/1239/granite-countertop-edges-pictures ------------------------ The ability to easily taper bevels using Vertices Data->Mean Bevel Weights should eliminate the jagged pattern created by Edges Data->Mean Bevel Weights in conjunction with the Modifier set to Weight (I don't think we have that option unless I'm missing something...) ------------------------ The End, and thanks Howard for being thoughtful and friendly :)

Howard Trickey commented

2017-03-06 15:07:57 +01:00

Thanks for the thoughtful suggestions.

I'm afraid I don't understand what you are getting at with the "taper bevels using Vertices Data->Mean Bevel Weights". Could you expand on this and/or provide a picture of what you mean?

Thanks for the thoughtful suggestions. I'm afraid I don't understand what you are getting at with the "taper bevels using Vertices Data->Mean Bevel Weights". Could you expand on this and/or provide a picture of what you mean?

Cirno commented

2017-03-07 01:49:18 +01:00

Added subscriber: @Lambdadelta

marc dion commented

2017-03-07 20:23:36 +01:00

Howdy Howard :)

Sorry, that last idea was confusing. ;)

See image below:

(Vertices Data->Mean Bevel Weights) is highlighted with red.

(Edges Data->Mean Bevel Weights) is highlighted with green.

For the bottom object, I wrote "Truncated when per/edge" what I mean by that is that when an edge is set to 0.0, then the bevel stops there at the beginning of that edge, instead of transitioning to zero near the very end of the object as it could with per-vertex weights.

Howdy Howard :) Sorry, that last idea was confusing. ;) See image below: (Vertices Data->Mean Bevel Weights) is highlighted with red. (Edges Data->Mean Bevel Weights) is highlighted with green. For the bottom object, I wrote "Truncated when per/edge" what I mean by that is that when an edge is set to 0.0, then the bevel stops there at the beginning of that edge, instead of transitioning to zero near the very end of the object as it could with per-vertex weights. ![BevelEditMode.jpg](https://archive.blender.org/developer/F505044/BevelEditMode.jpg)

Howard Trickey commented

2017-05-29 21:06:39 +02:00

Another requested bevel clamping change. See #50994. Requester would like clamp to apply to edges individually rather than globally. Could be consider as breaking backward compatibility for 2.8. Or an option (but we dislike adding too many options).

marc dion commented

2017-05-29 23:47:33 +02:00

I think what I'd like to see is a threshold that prevents close vertices from overlapping without blocking the movement of vertices that are far from each other. I suppose something like a weighting that diminishes the bevel effect for close vertices.
Something like in the following which shows how Edge-Slide has less impact on close vertices but a large influence on vertices with larger distances. I think this would have to be an option though since it would best suit organic or choppy shapes like rocks. It would likely be inappropriate for machined surfaces.

I think I once requested something before about tagging vertices that overlap so they can be easily found and adjusted. Sometimes finding the problem overlaps can be difficult and time-consuming. Maybe they can be automatically added to a specially created and specifically named vertex group.

I think what I'd like to see is a threshold that prevents close vertices from overlapping without blocking the movement of vertices that are far from each other. I suppose something like a weighting that diminishes the bevel effect for close vertices. Something like in the following which shows how Edge-Slide has less impact on close vertices but a large influence on vertices with larger distances. I think this would have to be an option though since it would best suit organic or choppy shapes like rocks. It would likely be inappropriate for machined surfaces. I think I once requested something before about tagging vertices that overlap so they can be easily found and adjusted. Sometimes finding the problem overlaps can be difficult and time-consuming. Maybe they can be automatically added to a specially created and specifically named vertex group. ![slide.gif](https://archive.blender.org/developer/F612336/slide.gif)

Howard Trickey commented

2017-05-31 15:28:16 +02:00

Someone else requested something similar to what you suggest -- just that when some vertices get blocked, they stay there and the unblocked ones continue to move. Maybe this should be the default, but I'd like to get some kind of consensus from artists before changing. As you say, it could be an option, but there is a lot of pushback on Blender devs from Ton not to add too many options to tools, but rather make them smart enough to "do the right thing" without options.

The idea of somehow identifying overlapping vertices to the user is a possibility, but I'd prefer another solution that I'm working on (albeit slowly): putting in the capability to automatically merge and continue beveling (similarly, insetting, for that command) when overlaps/collisions happen. The reason not to do your "identify the overlapping vertices" solution before then is that getting that precisely right is harder to code than one might think.

Someone else requested something similar to what you suggest -- just that when some vertices get blocked, they stay there and the unblocked ones continue to move. Maybe this should be the default, but I'd like to get some kind of consensus from artists before changing. As you say, it could be an option, but there is a lot of pushback on Blender devs from Ton not to add too many options to tools, but rather make them smart enough to "do the right thing" without options. The idea of somehow identifying overlapping vertices to the user is a possibility, but I'd prefer another solution that I'm working on (albeit slowly): putting in the capability to automatically merge and continue beveling (similarly, insetting, for that command) when overlaps/collisions happen. The reason not to do your "identify the overlapping vertices" solution before then is that getting that precisely right is harder to code than one might think.

cédric lepiller commented

2017-05-31 19:22:32 +02:00

Edge group for bevel could be better than vertex group

Example.

http://imgur.com/131ZTN9

Edge group for bevel could be better than vertex group Example. http://imgur.com/131ZTN9

Jac Rossiter commented

2017-09-13 12:25:41 +02:00

Added subscriber: @JacRossiter

Jac Rossiter commented

2017-09-13 12:25:41 +02:00

@howardt Hi Howard, I've been running into some trouble with the bevel modifier over the last week as I move more towards VFX. I am using the Bevel modifier to produce my control loops for Subd modelling and UV as I go, ensuring that the bevel modifier has an even number of segments so that any seams I have defined will remain. But the seams don't remain when the modifier is applied. I have written up a post about this on rightclickselect to argue for a change in behaviour but have since realised I would be much better off voicing my thoughts here.
Regardless here is the post: https://rightclickselect.com/p/general/Xvbbbc/preserve-uv-seams-when-applying-a-bevel-modifier-with-an-even-number-of-segments

Essentially when you UV a model and then apply a bevel modifier the bevel modifier will split edges in the UVs causing unwanted tears and artefacts. In addition the edges marks as seams will split and change the seam location in a way that could never be useful to the user. Be sure to check out the link I posted as it shows some examples of the issue in more detail.

@howardt Hi Howard, I've been running into some trouble with the bevel modifier over the last week as I move more towards VFX. I am using the Bevel modifier to produce my control loops for Subd modelling and UV as I go, ensuring that the bevel modifier has an even number of segments so that any seams I have defined will remain. But the seams don't remain when the modifier is applied. I have written up a post about this on rightclickselect to argue for a change in behaviour but have since realised I would be much better off voicing my thoughts here. Regardless here is the post: https://rightclickselect.com/p/general/Xvbbbc/preserve-uv-seams-when-applying-a-bevel-modifier-with-an-even-number-of-segments Essentially when you UV a model and then apply a bevel modifier the bevel modifier will split edges in the UVs causing unwanted tears and artefacts. In addition the edges marks as seams will split and change the seam location in a way that could never be useful to the user. Be sure to check out the link I posted as it shows some examples of the issue in more detail.

Howard Trickey commented

2017-09-13 12:59:26 +02:00

Thanks for your suggestion, Jac. And thanks for the clear examples in your rightclickselect post. While it seems strange to me to have a different treatment of seams for odd and even numbers of segments, I can understand your argument. What about other edge attributes (e.g., smoothness; bevel weight; ...). In your opinion, which edge attributes should go exclusively to the middle edge, which should go to all of the edges, and which should go to the outer edges of a beveled edge?

As for the 'tears': I've spent a lot of time (much more than I ever expected to have to) on trying to make the UV maps behave well after bevel; it seems a hard problem to get perfect. But I'll look at your examples and see if I can figure out if/how they could be improved.

Thanks for your suggestion, Jac. And thanks for the clear examples in your rightclickselect post. While it seems strange to me to have a different treatment of seams for odd and even numbers of segments, I can understand your argument. What about other edge attributes (e.g., smoothness; bevel weight; ...). In your opinion, which edge attributes should go exclusively to the middle edge, which should go to all of the edges, and which should go to the outer edges of a beveled edge? As for the 'tears': I've spent a lot of time (much more than I ever expected to have to) on trying to make the UV maps behave well after bevel; it seems a hard problem to get perfect. But I'll look at your examples and see if I can figure out if/how they could be improved.

michael knubben commented

2017-09-13 13:51:12 +02:00

Glad to see this being discussed here. I agree with @JacRossiter that you'd want UV seams in the middle of the bevel whenever possible. Now ofcourse that's not the case with an odd number of edges, but it's still an ideal to strive for in my opinion.
As for other edge attributes, it seems to me that hard edges & bevel weight make sense being on the outside of the bevel, so as to avoid compromising the bevel's curvature (either by bevel the middle of it, or by having a sudden gap in normal continuity there).

Glad to see this being discussed here. I agree with @JacRossiter that you'd want UV seams in the middle of the bevel *whenever possible*. Now ofcourse that's not the case with an odd number of edges, but it's still an ideal to strive for in my opinion. As for other edge attributes, it seems to me that hard edges & bevel weight make sense being on the outside of the bevel, so as to avoid compromising the bevel's curvature (either by bevel the middle of it, or by having a sudden gap in normal continuity there).

cédric lepiller commented

2017-09-13 13:57:31 +02:00

Maybe it could be usefull to clean bevel weight when applying the bevel modifier to avoid this kind of result ?

And I agree, the seam should stay at the center if possible to avoid this kind of result.

Of course having the right number of segments is better.

Maybe it could be usefull to clean bevel weight when applying the bevel modifier to avoid this kind of result ? ![blender_2017-09-13_13-53-29.jpg](https://archive.blender.org/developer/F794330/blender_2017-09-13_13-53-29.jpg) And I agree, the seam should stay at the center if possible to avoid this kind of result. ![blender_2017-09-13_13-55-26.jpg](https://archive.blender.org/developer/F794339/blender_2017-09-13_13-55-26.jpg) Of course having the right number of segments is better.

Jac Rossiter commented

2017-09-13 14:02:58 +02:00

@howardt Thanks for such a quick reply! I agree with @michaelknubben. The only thing that really needs to be as much centre as possible is the edge seam, as that way it would be really easy to just reunwrap the mesh and avoid any issues with those unwanted tears. The ideal would be that the UVs wouldn't tear in the first place but it's not a big deal to just reunwrap the mesh with the new seams at the centre of the bevels. I wonder if it would at all be possible to have an option within the modifier on how it would handle edge data. That would be perfect act avoid any worries about being consistent with how edge data is treated. Just let the user decide whether edge seam is split or center. Perhaps add an offset option so that if the bevel has a segment of 1 the user could offset which side the seam would move to. Just an idea, in reality I would just be very happy with just a change that put seams in the centre.

Yury Ziankouski commented

2017-09-19 15:20:24 +02:00

Added subscriber: @YuryZiankouvki

Yury Ziankouski commented

2017-09-19 15:20:24 +02:00

I want to drop a few cents here about the related proposal I don't see mentioned here.
I remember cédric's proposal in rightclickselect for adding Bevel Segments value for Edges Data. It could be s great feature for non-destructive modeling with a better bevel modifier.
https://rightclickselect.com/p/modeling/hqbbbc/add-a-value-for-segments-in-bevel-modifier

I want to drop a few cents here about the related proposal I don't see mentioned here. I remember cédric's proposal in rightclickselect for adding *Bevel Segments* value for *Edges Data*. It could be s great feature for non-destructive modeling with a better bevel modifier. https://rightclickselect.com/p/modeling/hqbbbc/add-a-value-for-segments-in-bevel-modifier ![W0DYcf2h.jpg](https://archive.blender.org/developer/F828602/W0DYcf2h.jpg)

marc dion commented

2017-09-20 00:21:13 +02:00

This comment was removed by @MarcClintDion

*This comment was removed by @MarcClintDion*

Yuriy Sivalniev commented

2018-01-07 11:39:28 +01:00

Added subscriber: @yursiv

Yuriy Sivalniev commented

2018-01-07 11:39:28 +01:00

Here is proposal for bevel options for corners:
Bevel proposal

Here is proposal for bevel options for corners: [Bevel proposal ](https://blender.community/c/rightclickselect/10bbbc/bevel-edges-options)

Howard Trickey commented

2018-01-18 19:25:49 +01:00

Several more bugs reports have also been about the behavior with profile=1.0. As mentioned above, this is difficult to fix in general but likely I should work on some more special cases. I'm going to close the bugs #51010 and #53783 as they are grouped under this general TODO.

Howard Trickey commented

2018-02-05 20:27:13 +01:00

Finally fixed the profile=1.0 case with commit bd9ed0228b, removing a bunch of the most requested tasks in this design task.

Finally fixed the profile=1.0 case with commit bd9ed0228b, removing a bunch of the most requested tasks in this design task.

Duarte Farrajota Ramos commented

2019-02-06 00:46:05 +01:00

Added subscriber: @DuarteRamos

Frederico Martins commented

2019-03-19 15:10:11 +01:00

Added subscriber: @FredericoMartins

Frederico Martins commented

2019-03-19 15:10:11 +01:00

Hi, It would be very useful for me to have the vertex group or any other way, to affect bevel size per vertice, something like this:

I added the image to the right click select post too, please let me know if it is not ok here, thanks!

Hi, It would be very useful for me to have the vertex group or any other way, to affect bevel size per vertice, something like this: ![bevelWeightEffect.jpg](https://archive.blender.org/developer/F6849877/bevelWeightEffect.jpg) I added the image to the right click select post too, please let me know if it is not ok here, thanks!

Dspazio commented

2019-03-24 19:47:59 +01:00

Added subscriber: @Dspazio

Chingiz Jumagulov commented

2019-05-26 21:07:28 +02:00

Added subscriber: @MeshVoid

dark999 commented

2019-07-28 16:02:32 +02:00

Added subscriber: @dark999

Janne Aliu commented

2019-08-06 14:29:35 +02:00

Added subscriber: @Jaydead

M commented

2019-08-24 19:32:36 +02:00

Added subscriber: @justastatue

Lino Thomas commented

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

Added subscriber: @LinoThomas

reza sanjaya commented

2019-09-29 14:44:53 +02:00

Added subscriber: @ReguzaEi

Jac Rossiter commented

2019-11-06 14:56:38 +01:00

@howardt What happened with the changes to the ways seams work when bevelling? It's still breaking seams when you bevel. This was the original post we went over about a year ago https://blender.community/c/rightclickselect/Xvbbbc/

item412 commented

2020-05-04 20:21:13 +02:00

Added subscriber: @item412

Min commented

2020-07-05 21:44:27 +02:00

Added subscriber: @Nominous

hujin commented

2021-12-21 05:12:24 +01:00

Added subscriber: @2046411367

Yacine Teach commented

2022-06-30 09:53:50 +02:00

Added subscriber: @Yacine-Teach

Chingiz Jumagulov commented

2022-08-13 10:59:02 +02:00

Hello! Can we add simple stuff like Loop slide toggle to Bevel Modal Map, it doesn't have to be keymapped by default, but it is really annoying not to have the ability to toggle it with a hotkey and having to always click in the bottom left corner to toggle it off and on, and when modeling hardsurface stuff you switch these modes quite often, please add it to modal map.

P.S. It is also weird that it is not in the Bevel modal map, as it has Toggle Clamp overlap, it makes sense that Toggle loop slide should be present there too.

Hello! Can we add simple stuff like **Loop slide** toggle to **Bevel Modal Map**, it doesn't have to be keymapped by default, but it is really annoying not to have the ability to toggle it with a hotkey and having to always click in the bottom left corner to toggle it off and on, and when modeling hardsurface stuff you switch these modes quite often, please add it to modal map. P.S. It is also weird that it is not in the Bevel modal map, as it has Toggle Clamp overlap, it makes sense that Toggle loop slide should be present there too.

item412 commented

2022-08-13 12:31:52 +02:00

Removed subscriber: @item412