This is similar to the problem of UV maps with bevels of odd numbers of vertices. It is indeed arbitrary what happens at in such cases. I have some ideas on how to make it feel at least a little more consistent for the UV case, and it is good to have this report to remind me that the same solution should be used for vertex properties, including color, also.

Thanks for doing this. Looks great.

The "Circle" object in this file is not a watertight single volume. This is not supported by the current code.

The problem is provoked because the input mesh has some edges that form a zero-degree angle, causing clamp overlap to set the offsets to approximately zero (hence, even with bug fix, this mesh will not bevel noticeably with clamp overlap turned on). Information for bug reporter: an example of the problem are the vertices with indices 44, 17, 73, 10, which form a chain in that order, while it looks like what was intended was that vertex 17 would be in the center of edges going to 10, 73, and 44. You can see vertex indices by selecting Developer Extras in Preferences, then clicking "Indices" in the Display Overlap options, then selecting all the vertices.

I looked into it some. The problem is that the start and end of some profiles (e.g., for edge 33 between vertices 16 and 93) are the same point. This seems to be because when offset_meet is called during build_boundary, the left and right offsets of beveled edges 33, 35, and 37 are zero. They got set properly in bevel_vert_construct, so not sure where they got reset.

This was fixed with commit rB2867c35d4e72

A typo in a commit mistakenly changed the status of this from Invalid to Resolved. I'm changing it back.

Looks good.

If, as you say, this needs further testing and refinement, should I wait until you think it is ready? Or would you like to get this into the 2.83 beta to get users to try it out now? As far as I can tell, this should not affect existing uses of bevel (right?), so there is low risk. But we do want to make sure that this doesn't turn into a source of a large number of immediate bug reports.

Fine with me to submit this. If you also want to remove those 2016 defines for enabling old behavior, and the code they guard, that would be good too. Thanks.

I will add that, at user request, the tools that require autosmooth to be on now enable it for the user if it is not already enabled. But it wasn't possible to do with modifiers because there was no way that I could see, with current code to have a modifier affect the Mesh's autosmooth flag. It would be possible to change the BMesh <-> Mesh interconversion code to make that possible, but that was not something I felt like doing at the time. Since the whole autosmooth usability right now is confusing, there is a modeling task T68893 to improve this, and hence it is probably not the right thing to do to make the change I just mentioned until that task has been resolved.

I think I'm responsible for starting this, about 6 years ago, with bmesh_core_test.cc. I was ambitious to start unit testing all of the primitives used inside BMesh. Many of those functions are not exposed in the Python API, and probably shouldn't be. The tendrils of those primitives extend so far into other parts of Blender that it seemed very hard to isolate small libraries to link against that would let those bmesh files compile & link.

Yes, please put this on the known issues (it is unfortunate that this bug is really two completely separate bugs; the first one (cylinder) is fixed; the second (cube) is not.

I have been working on this for a while, and had already submitted one change that fixed the first crash, but the other reports showed that a more fundamental rethinking of the code was likely necessary. I am near a solution, but am putting this bug here so that there will be a record of why the rewrite was needed,

This revision looks fine to me. Go ahead and submit it to master. Thanks for the fix.

This revision is accepted, and has been committed by commit 3fdc04d3ee0ae45
.

No, sorry, the new Boolean will not be in 2.82. Probably not even in 2.83. I thought I was close, but the pesky problems related to numerical issues have proven difficult to get right. I've spent the last 3 weeks redoing an underlying triangulation / intersection library that is core to the new code so that it will be extremely robust in the face of nearly-degenerate geometry. Sorry.

The lines are created in the top face are necessary because Blender doesn't allow holes to exist in faces without those holes being connected to the enclosing face by at least two edges. It is not easy to make those "support edges" get added at consistent vertices as you move things around, unfortunately, and the current code does't even try.

I tried this just now and found that test 0 of the modifiers test is now failing. Does it work on your system? If so, it may be that one or more of the modifiers produces results that depends on, say, how pointers on a particular run are hashed and we should for now not do that test.

Brecht, are there any objections remaining to accepting this patch?

I am wondering about the effect you intend for the Cube.003 object in the latest version of your test file. You have a circle aligned showing that you intend the tangent circle to go between the two non-beveled edges between the beveled ones. That makes sense from one point of view -- looking at the curvature of the profile at that corner. But it has several downsides:

It would require a whole new UI to do (to have an entry box for the thing to add or multiply by or set for pasting. We couldn't figure out an good way to do that in the time before 2.80, so went with what we went with. As noted above, probably a real tool should be made with some good UI design. One can still copy a normal from somewhere else (constructed as one sees fit) and paste it. And the functionality is still available via Python.

I am close to having an experimental version of the new boolean for people to try. It alreadt handles the case detailed in this bug properly.

Boolean operations are intended to be interpreted as if they are operating on 3d volumes. So, e.g., difference A-B (for objects A and B) means everything inside the volume of A, but excluding any point that is also in volume B. The currently implemented BMesh Boolean code assumes that the two objects are closed volumes -- that is, there are faces all around that are tightly sealed together and you can clearly figure out what is inside and what is outside the volume implied by those faces connected faces.

This is very hard to fix with the current Boolean, and will be fixed with new Boolean code that I am writing. I'm hoping to have it done for 2.83. Or if things go very well in the next few weeks, 2.82.

I would like to merge this into master now that we are in the early 2.82 stages there. Any objections, Campbell?

Yes, I agree that the crease should be continued across that line. There is the "mark sharp" option that is supposed to fix that, but apparently the code is not handling this case properly.
I will fix this, but probably not until 2.82, because of large pending changes to bevel (GSoC project inclusion) because this is not a regression from previous behavior.

This is not a bug. The Offset mode does not measure width along the edges you are looking at: it measures the perpendicular distance between the offset edge and the original edge. If the edges that it is sliding along happen to make 90 degree angles with the beveled edges, then the perpendicular distance and the distance along the edge will be the same, but not otherwise,

I had put some code in to clamp the sliding amount on "terminal edges" - those where the selection stops at a vertex. That's why you get the clamping result you want when you selected isolated edges. But I really intended one to use the 'clamp overlap' checkbox to cause clamping, and in retrospect I probably shouldn't have done that other clamping even when the box wasn't checked, because it confuses matters about when clamping happens.

In D5516#135587, @Hans Goudey (HooglyBoogly) wrote:

After looking through many of the bevel test results manually, I haven't been able to visually confirm many of the failed operations. The test reports that there is a "Vertex Coordinate Mismatch," but all the vertices I've checked are in the correct locations, and their indexing has been the same as well.
For others the difference doesn't quite make sense. It would be great if someone with more familiar with the automated bevel tests took a look at this; it's not clear to me what the issue is at this point.

Collapsing edges would mostly handle that case, yes. I wasn't sure whether you intended to support that everywhere or just as part of handling merges across boundaries, but thinking about it, you must have meant the former, because the latter wouldn't come up in most cases, if ever.

Pointing out that some of the desire for this comes from the fact that the Bevel modifier can, as a result of clamping, put vertices on top of each other, and users would like them merged. As Campbell points out, the Bevel modifier itself could be changed to detect and merge in such cases. I would have done so if it were easy, but it is not so easy (the current code that merges nearby vertices gets quite complicated), so was delaying -- especially as my eventual goal is to get rid of clamping completely and continue beveling after such collisions cause merges.

I made a first pass at reviewing this. Several minor things to change per my comments.
I think this code is about ready to merge, though we should wait until after the 2.81 stabilizing branch has been made (supposed to be Oct 10).

Thanks for the report.

Eldee, they were pros and cons about the actual-holes-in-faces BMesh solution.

I was about to suggest the same thing eldee said: flagging "support edges" as such, so that the only thing affected is display and selection of edges and perhaps export to file formats that support holes. I too think this is a decent compromise. But it is likely to uncover a number of cases where current code has to be modified to take account of these as hidden, else users will be surprised. E.g., bevel and inset and boolean may all give strange and buggy-looking results if not updated; similarly some select types (e.g., selecting ngons of a given # of sides) will appear buggy unless fixed.

I still can't make this happen. Can someone who can make this happen please upload a simple .blend with a cylinder and cube with boolean modifier set to difference where the result of the boolean is the union rather than the difference?

I can't tell how to reproduce this problem. Does the attached blend file (mastering drivers copo.blend) have anything to do with reproducing the bug? From the screenshots, it looks like you are just doing a boolean of a cube with a smaller cylinder. I don't know what it means to say that you have a "wireframe cube" -- do you just mean that the display is set to wireframe? When I try a cube and a cylinder, in wireframe display mode, it works ok for me.