If you end up with extra time in your GSoC project, you might provide a bunch of preset curves that users could choose from, to save them from drawing them. And providing one like this would likely be very popular. Though of course another way would be to have a checkbox for “support edges” that behind the scenes generated a curve like this for the user, rather than making it seem like a custom profile.
It might be fun to solicit profiles that people would like as presets on your GSoC 2019 thread (without promising anything). We should try to get what people really would use rather than just “here are the presets that application X has”, for several reasons.
I agree, it would be great to collect profiles for presets. And I think presets would really make the feature so much more useful! Ideally we could do this after the drawing widget is working better, because it’s a little frustrating to edit curves right now.
I’m getting back to basics here. Could anyone give me a reason why there has always been this issue with beveling sharp corners (oblique angles) in blender? The only workaround to the non-round looking bevels that occur with sharp corners is to change the profile amount to something between 0.35 and 0.45 but is a bit annoying because it means I have to bevel the sharp corners separately.
This is a choice I made at the beginning about how to handle bevels between faces that do not meet at 90 degrees. The way Blender does this is to always make a profile that is a quarter of a circle (or quarter of a superellipse, if the profile parameter is not 0.5). Then if the faces don’t meet at a 90 degree angle, a transformation is applied that takes the 90 degree angle into the actual angle. This gives the effect you note in your diagram.
The alternative you show looks easy but is actually not so easy. What you are doing is inscribing a circle in the angle and noting where the circle is tangent to the two enclosing edges, and then using an arc that is that percentage of a circle rather than a quarter circle. The problem is: what if the tangent points don’t match where the bevel wdith parameter says they should be? With circular profile and a non-percentage width type, it will work out ok. Admittedly this is a very common case, but what to do in other cases?
I suppose we could add an option to try that way. Do other users feel this is an important option to have?
Thanks for the reply. I’m gonna have to read it multiple times to fully understand, but I think I vaguely follow and see there’s a complication. What if there could be just an automatic adjustment of the Profile value that we already have? The automatic adjustment would work based on the angle of each corner and would try to simulate the perfect circle-based fillet. For example, with a 90 degree corner the Bevel profile would be 0.5, but if a corner is 45 degrees, a 0.4 profile is applied to that corner, and a 0.35 profile is applied to a 25 degree corner etc. Something like that.
Granted, I am not thinking through all possible cases. I’m actually only thinking through the 2d situation I showed in the diagram.
I wonder if a combination of the super-ellipse function combined with the transformation to the original angle can actually form a perfect circle. After playing with it for a minute it looks close, but I couldn’t get it to match perfectly. There’s also the problem of the profile’s edges being smaller in the middle of the profile.
It would be cool if that worked though! Definitely simpler to implement that way.
I would expect default bevels at 0.5 to always match a circle arc as close as possible at all times, as other users mentioned that is what most real world bevels would look like.
However I understand the technical limitations, and that it may not always be possible.
Yeah, there’s an open bug about material assignment. The problem is, the code has to “break the tie” as to which material should win when there is an odd number of segments. The current method for breaking the tie is not good. A suggestion has been made to break the tie by using material slot #. That seems like a better idea, and I should do that.
I’d honestly might prefer if these weren’t implemented to ‘bevel’
First one is bevel+extrude or inset+transform. Second one is is the same with added profiled loop cut.
If you start adding stuff like this to bevel I think it is easy for tool to become very convoluted.
I guess philosophically speaking it wouldn’t be different from before since all the basic operators already are basically multiple operations in a macro but… somehow I feel like this goes beyond ‘bevel’
Certainly as features these would be nice to have but maybe as compound tools instead. Albeit with Everything Nodes™ it might become redundant sooner than expected if it becomes easy to take operation, procedural select its result and apply more operators.
It’s really hard to draw the line, but I’d tend to agree with you - in the example shown, there’s what we might consider creation of volume, whereas bevel - in its real-world variant at least, which after all is what Blender’s tool is based on, is pretty much only substractive and operates on an already existing ‘protrusion’ or ‘extrusion’ so to speak. Now this is not to enter a philosophical debate but to decide where to draw the line between different operations.