I’d be all in support of granularizing these if we had easy to use visual macros we could build out of these more granularized operators. For an example using node trees/flowcharts to build macro operations out of.
But I dont consider nor expect it a trivial task to add something like this.
I’m going to preface this by saying I THINK I’m for the added complexity.
I’m not as big of a power user when it comes to beveling, but I think having the extra options is probably a good idea. As you said, there is something inherent about bevel that brings up many different scenarios. It’s just a complicated tool, period.
That being said, its less the added functionality, and more the increased space that the modifier now takes that is what is a concern I think. One, it’s a bit unwieldy as a modifier, two, we are worried that starting users - intermediate users will feel overwhelmed by bevel, no? I can understand that, but I think this might bleed a bit into a everything nodes discussions.
As a node, not a modifier, all this added functionality will likely feel a bit easier to work with. And when it comes to parametric modelling all the added functionality will absolutely be welcome; you never know what you need when it comes to that.
The only problematic point that I heavily consider is how, in the future, we will decide to display the nodes. Blender has a tendency to expose all the elements in a node for easy access (shading, compositer). While this has its ups and downs, on the whole I like it because blenders nodes aren’t usually too big, and exposing all the parameters doesn’t take up too much space, plus it allows feeding parameters into one another very easily. That’s all great for procedural modelling. But when it comes to bevel, it may infact still be a hilariously large node…
That brings up the discussion of maybe having the nodes be closed, and their parameters be brought up in something like the N panel, which we already can. This way we could probably consider tabs and the likes to clean up all the features.
There is a lot to consider, and I hope that I can chat with Jaques Luckes on the blender today show that Pablo hosts, as you can leave questions that are answered on the show. Hopefully that can give some clarity for the future. But for the mean time, the bevel modifier will maybe just be a bit awkward in size.
To sum up: I think the changes are fine, the modifier might be a bit awkward right now, but it should become easier to work with as a node in the future. Those are my thoughts.
I was thinking something quite similar. I have some ideas relating to other concepts/post that may help and give the user a lot more control. The modifier could end up being used for a lot more than beveling.
Well said both of you, it’s definitely a tricky problem.
In general I’m not against the added complexity, but it’s always better if it can be accompanied by a simplification that also makes it easier or more pleasant to use. It’s too bad we don’t have a tally of how many times Blender users have clicked on each of the width methods. I wonder if it would be possible to do a poll or a survey to see if one of the options is used much less. I also really like that they’re all accessible, not in a drop-down menu, and once there are five that becomes much more unwieldy.
On the bevel, I only use OFFSET since PERCENT isn’t fully supported with a merge threshold like I posted some time ago.
I took the liberty of crating a new thread as Howard requested.
Let’s take the discussion over there to keep things clean.
For hard surface modeling, it would be an extremely important option to have. This is the way all CAD software packages work.
Yes! For me is extremely important!
hey i would like to try these improved bevel options since i want to see if it resolves this issue:
can anyone provide me a link to a build that i can try? i was not able to find one:dizzy_face:
when doing mechanical parts modeling a even bevel is in my experience always the desired result and i think the current (official) behavior can be considered a bug and possibly removed?
Or can anyone give me a scenario where you would want such a shift in the bevel?
You probably scaled the object non-uniformly along different axes, right?
You should “Apply > Scale” (in the Object menu).
All tools in Blender work on the unscaled object, so you get results like your picture if scaling afterwards is non-uniform.
There is has been a bunch of discussion over the years about whether tools like bevel (and inset, and probably other tools I’m forgetting) should do an “apply the transformation, to the tool, apply the reverse transformation” to fix this problem. But there are some downsides and in the end we have not decided to do that, at least for now. For one thing, it could break existing files. This is mainly a problem for new users – experienced users know to apply Scale after scaling non-uniformly in object mode, and then this problem goes away.
yeah just got that input and its a bad sign if i fail after 10 years of blending with these trivial things.
I dont understand why is there no compensation for that transformation on the operator levels.
I know this has nothing to do with the bevel directly but this is really something that tripps a lot of users and i also implement corrections in addons for the transforations since its something a user should not have to care for and can cost hours to figure out.
And i think it should be taken care of in all the different regions of blender, wehter its exporters, modifiers, or any other area where transformation messes up the expected result.
probably because object scale can be called modifier of it own that applies after everything, and if user willing to use tools with “compensation” he might as well apply scale it self. What can be done is added warning/hint about non uniform scaling at the bottom when entering edit mode.
So recapping, an alert and a apply scale [rot position] modifier
That would actually be a very nice solution to this problem. Or maybe add hints only if you try to apply certain modifiers (eg bevels) that function differently (or maybe unexpected behaviour as in the example above) when there is a no uniform scale
I’d modify it to say WARNING! Non-uniform scale will give potentially unexpected results since in some cases you might actually want such results, in which case it’s not exactly bad. 
Hi I did this and at a moment I’m showing the effect of setting by interval (not coded again). but do I do something wrong because this is really hard to have width of bevel with bevel weight. https://www.youtube.com/watch?v=5MaYcyk7Bpw
and I was sure that I could find bevel weight in edit mode in the list. but no?
ok I have to add apply scale to my script anyway
Lately I working a lot to learn 3d design in home. That means, I trying to work non-destructive as much I can but sadly I miss some features.
Let say that I cut a lot of things using booleans. Below is good, non-destructive example.
From this
I quite sure that this question was asked already, but anyway, is it possible to detect boolean intersection edge line, which could be converted for sharp edge? Below I posting example:
That kind of intersection edgeline opens for us a lot of opportunities to use it in different way, for example we could use that for adding custom bevel width just through boolean modifier.
reposted from GSOC thread
hello @Howard_Trickey,
the bevel and it’s relationship with seams on apply has always been “bumpy”. When the bevel is applied the new faces have a notched connection with other islands. This has been a bane of high poly bevel uv workflows forever. It can be mitigated with an additional segment but this also changes the form since the goal is to work with 1 segment or 3. These sort of disconnected notches happen all over the place. It’s not able to easily be exploited on a cube but with something more complex it happens.
This one is another example.
Is there any way to ease the notching with applying bevels on models that are uv’ed as we work? Because since they are so variable it affects the baking and thus the texturing. Love the work so far! 2019 is the year of the bevel!
Yes, it has been on my TODO list to try to improve things here for a while. I’ve lately been trying to sprint on my major fix to Boolean, so the bevel TODO list has languished, sorry.
This particular problem is not easy: when you have an odd number of segments, how do you decide which side to put the middle segments on? The algorithms I thought of were pretty complicated. Someone had the idea: just materials to break the tie. That is, if there are different materials on either side of a beveled edge, put the middle segments on the side with the lower material index number. Do you think such a solution would work for you?
