Yes, and I have just now tried again with the very latest build.
As you can see, there are still disturbances, where the original custom normals are changed or cleared.
You can check out the blend in my original post, or use this one here, which also has a second sphere where I fixed the normals myself, so you have something to compare to.
Thanks!
Thanks for the example. Sorry I didn’t notice the blend in the original post. I will look at this in the next couple of days.
Hello, and thanks for all the hard work!
Would it be possible to implement a support loop option in bevel? It is a standard technique used in subdivision modeling to sharpen edges, but it also works as an elegant way to fix weird normals using only geometry.
This is how they work:
I also posted on rightclickselect, but I don’t know how many developers go there: https://blender.community/c/rightclickselect/y6cbbc/support-loops-in-bevels
xikon,
Yes that is possible. Many people have asked for this. I was kind of hoping that the harden normals option would lessen the demand; but I understand that the flexibility to solve the problem this way would be appreciated. I’ll consider this.
Howard, thanks for all the lovely work you are doing with bevel.
During the Code Quest, we got to talk about ways in which we could improve the Extrude tool. One major missing feature that competing apps have had for ages, is the ability to extrude edges and vertices while keeping the mesh manifold. This could be added as an operator option with the Extrude tool.
Here’s what I mean:
Even though it would be an option within the extrude tool, the underlying operations are more akin to a bevel.
So anyway, it would be amazing to get this in Blender I think - even though it doesn’t manifest itself strictly speaking as a bevel tool thing, it is bevel-rated.
Cheers
W
By using several bevel?
I believe there is no need for that.
Just select Harden normals on the bevel modifier, or add a weighted normals modifier
As discussed #blendercoders, I like this idea a lot, and will probably do it some time.
I continue to be interested to get some kind of consensus on priority from users on the various things on my TODO list.
Well, depending on who you ask you might get different answers. However, I would generally advocate to get the most basic features right first, which apply in many cases, before tackling more advanced or esoteric features, which only apply to edge-cases.
In the case of your list I would say:
#1: This is super important. Currently, UV mapping basically breaks when you have an odd # of bevel segments.
#2: Seems like less of an issue?
#3: You could always continue to keep adding miter types. But given that you’ve already developed many new useful miter types, you could start by just adding in the ones you’ve got, which may be good enough for now. More could always be added later
#4: This would have a huge impact in many common cases that currently fail, when you have too dense geometry before a bevel.
#5: This is massively applicable in many common use-cases. Both for special shapes, but also just because it’s a nice way to accurately visualize your bevel profile vs the ‘Profile’ value, which is not super clear.
So, here’s how I would stack your todo’s in order of importance to most end-users:
1: #1: Tie-breaking rules for materials and UV seams with odd # of segments
2: #4: bevel flow past existing edges
3: #5: Custom profile curves
4: #2 “termination” pattern types
5: #3 The polar miter type
And I would probably add the beveled extrude feature somewhere near the top of that list too, as that is a very basic operation too.
Obviously, all of your todo items seem like nice things to do, but the above order I think reflects roughly on what would have the most useful impact for most users on most projects. 
Howard,
I’d agree with the list that billrey posted above in terms of my own personal priority list, especially the first two. Though I’d probably put #4 (bevel flow) as my #1 but I do my UV mapping in UVLayout so #1 doesn’t apply to me as much.
I see people disagree with xikon’s suggestion but personally that’s something I would really benefit from as well. I work in games and hardening normals isn’t always an option or a workable solution (for various reasons, some being engine related) so being able to force it with extra loops like that would be awesome.
Honestly the more work done with bevels in general the happier I am They’re used a lot by me and my coworkers so everything you’re doing to improve them and normals is much appreciated!
Yes I have to agree with this too, this is something I do manually right now post bevel and is the kind of feature I’d want irregardless of any features to control normals and shading. After all, this is of great benefit to SubD modeling too.
While this is an alternate(and fairly good) way to do it, it is not as convenient and doesn’t guarantee as consistent of a geometric profile. Multiple beveled areas on a more complex model would end up with different edge lengths for the surrounding face/edge ring. In some situations it might be less of an issue, in others more.
Thanks for the nice update with the new miter types. I noticed a new small issue with the Arc type.
The connecting edge goes to the wrong vertex in this case, which causes face overlapping. The blue dotted line represents the path where this edge should be.
Edit: Here’s an example where it’s more clear that this causes overlapping geometry:
billrey - yeah, knew about that and will likely fix. I was thinking the non-beveled edges should attach to the middle (or nearest to middle) vertex of an arc miter. But you suggest an alternative: attach each to the one that makes the shortest new edge. Hmm, have to think about it.
What you are suggesting is this:
But I would think this result would be better in most cases:
I would think that, if you are working on a non-planar surface, the bottom result will work better. It also avoids the pinched pole in the middle of the miter, and ensures that the resulting N-gons don’t have to turn around the corners to create problematic geometry. You also end up with 1 less N-gon
I agree with you in this case. And rather than “shortest” maybe your rule is "one that causes least deviation in angle from what it was before. I need to think about other cases where there are more or less than 2 unbeveled edges attached at the miter vertex, as well as cases where one or more of those edges is not in-plane with the face that would go between beveled edge if no extra edges were there.
Another issue is if you use the Arc inner miter, there’s a funny concave shape that emerges at the poles. It’s unrelated to the Profile, which can’t get rid of it.
For references, this is the same profile, but using Sharp miter:
just played with this a bit, indeed a very nice improvement
often I use bevel modifier as a way to create nicely uniform control loops for subdivision surfacing.
With sharp outer mitter corners often turn out … not so nice.
with arc the vertices look correct, but the edge placment is problematic. maybe this is related to what billrey describes a few posts above.
here i quickly cleaned it up - this is how I would prefer it to be:
Yes, it’s the same issue.
another thing - the bevel width and the mitter spread seem to be linked? the python code points to different rna properties, but these behave as if they are the same? (totally possible that i just dont know how to use it …)
kio - they are not linked. What did you do that made them seemed linked to you. If you do this:
Do you see that the main beveled edges maintain the same width, but get shorter and longer as the spread varies?
billrey: about the funny concave shape: yes, I know about this. It also happens with sharp miters if you have 4 or more beveled edges at one vertex; I use very specific code to correct it for cube-like corners. I am a little stuck on how to fix it when inner arcs are added to the mix. I’ll explain with pictures in a later post and maybe you or others here will have ideas.
