I see some problems in the mitterd version calc that you use. For example…
Actually the center of the bevel corner have a different position than in normal bevel, when the point must be, inittially, in same position in both bevels, mittered or not.
If you try to make a “classic bevel” with 0 Arc the problem is more clear that the solution is not the expected.
E second this, it would be extremely useful to be able to use the Bevel modifier on Bezier Curve objects as well.
Would it be possible to enable this change?
I’m curious, what kind of addon can display information like that in your screenshot in the top left corner?
Pitiwazou speedflow
Answering some of the questions that have piled up in this thread.
Zuorion: you asked about disabling the inner arc for 2-beveled-edges and another unbeveled edge. I don’t know if we want to do that always. I do disable it if the angle between beveled edges is 180 degrees, which it almost is in your example. Maybe I should make the angle at which it is disabled anything close to 180 degrees.
Your example of bevel messing up when there are 7 segments beveling an in-plane T-pattern is a bug. Not sure if it is easy to fix as it depends on how subdivision is used to make that pattern. Thanks for pointing it out.
mx2: your manual fix to the arc outer miter pattern is interesting but hard for me to figure out how to make a rule to program it.
wevon: I see what you mean, and it is possible to do that “relaxing” of the sharp bevel. But how much to relax? I want to avoid adding so many parameters and options that the interface becomes a nightmare of complexity.
xdanic: You have probably seen that a “quad” chamfer (miter) option is something I’ve been considering on my TODO list; I will probably get to it eventually but trying to figure out where to put it in my priority list. A problem I need to solve is how to choose which boundary vertex to spread (only 1 of 3 gets spread in that pattern). I was trying to think of rules like "the one most aligned with a user-specfied axis – x, y, or z – but your picture gives me another idea: if it is an outer arc, chose the direction that is where the reflex angle is. This is similar to what the new Arc pattern on outer miters would give in this case (I know there is still a problem - as others have reported - in the attachment point of the unbeveled edges).
michaelknubben: in that polycount thread at the point you are linking to, it seems the problem is with profile=1 in some cases. The new topology options may avoid the problem but I should find and fix that problem too. And re your point about the UI for user profiles: I understand and agree that a UI for drawing curves instead of actual geometry would be better.
Alberto: you are pointing out the same problem that I was soliciting ideas for some posts above, where my special code for cube corners doesn’t apply with these new topologies. I am working, however, on better parameters for subdivision which will improve the curvature when the general subdivision method is used to make the vertex corners.
duarte.framos: I have so far avoided paying attention to curve objects and bevel. Interesting that someone was able to have the bevel code work with it with curves; I will try to find time to look into doing that.
Much appreciated, I’m sure lots of people will welcome. With all the recent improvements it will certainly be better than curve objects internal beveling.
Another common issue, is that the bevel ends cause a funny extra face to appear, which creates many N-gons and strange edge-flow:
In most cases you’d rather want this I think:
Yes, doing more things at the termination of single beveled edges was on my list of things to look at.
So far I have resisted the requests for adding extra edges that are not just local to the edges and vertices involved in a bevel, requests that usually arise from wanting to fix up ngons. Bevel produces a lot of ngons, I know. It feels like that could get into quite a long list of possibilities of what to do. But I do know that people ask for this sometimes.
Sure, I don’t think it’s that big of a deal if it doesn’t add the edge to split the N-Gon. I can see that this would only work with a specific number of segments.
The more important thing, is if it would just connect at either end I think that would be more desirable than the current behaviour:
This creates 1 N-gon at the termination, whereas the current system creates 4 N-gons + an extra face you have to remove.
Yeah, I believe other softwares have it this way.
The bevel in blender act different, you can see the right side it connect different from the left side . and suppose to be like the top one.
If you look at them radially rather than symmetrically the two sides are functionally identical, so this shouldn’t be surprising. As for getting the top result, this has already been discussed.
KioWorks,
I am close to pushing a change which will make the two unbeveled edges attached to opposite ends of an arc miter, so looking more like the top picture. Though it won’t look exactly like the top picture since I have chosen different angles to make some of the lines involved in that quad around the vertex.
hi. thx u for hard work on bevel update///
https://developer.blender.org/T61214
u close my task/ but this task not for auto merge, in the end, it’s about the bug when segments be a lot like 200 on the cylinder.Plz see this gif
You can insert your gif in your reply instead of giving a link, so we can see it right away without needing any additional click. Use the 
button , or use the following markdown code:
Hi i was spending some time testing 2.8 and i was curious, is the bevel stable enough to use it? i know that is under heavy development but i fund some weird behaviours that im not sure if they are WIPS bugs or is this the new way that its supposed to work.
(on the right 2.79 - on the left 2.8 hash: a5869c3 )
About the new milter, is it supposed to subdivide the vertical unselected edges?
Ps: I ask this here, but should I post this somewhere else? i wasn’t sure if it was related to Gsoc. .
There has been a regression in the behavior for “adjusting offsets” which I have noticed but not yet fixed. I will investigate and fix as my next task.
In other news, I just pushed the change that makes better attachment points for unbeveled edges when using arc miters, fixing a problem that many have pointed out in this thread.
Great, it’s a nice improvement:
However I noticed an issue if you use an uneven number of segments:
A sharp profile is wrong in this case.
I guess you mean with profile=1. I was noticing in my code the other day that I completely disabled the special case handling of profile=1 for odd segments on non-cube-like corners. I’m not remembering why, exactly. I guess I should go back to the commit where I changed that and see if I can rediscover the reason.
