Well, it is expected, from the way the algorithm works. (It tries to remove unneeded triangulation edges, but whether it is completely successful or not is a bit up to chance. All is made harder by the fact that two of those extra edges (the ones leading from the inner to the outer circles) are necessary because Blender doesn't allow holes in faces. So the code is trying to remove as many as it can without creating that problem. Clearly there are more that could have been removed here. I can look at the code again and see if can be improved for cases like this.

I will remove this quadratic behavior.

The Exact Boolean is operating as expected here, so there is no bug here, except that the Fast boolean is not really doing the right thing.

Working on this now.

I originally thought I would use the opportunity of this new exporter to fix those bugs. But then figured it would be better to first have a release that matched as close as possible the old behavior, so that users wouldn't complain, and then follow up with functionality altering bug fixes. I'm interested in Sybren's thoughts. I don't have a super strong opinion.

This looks good to me. Do you have commit rights? If not, I will commit in your name.

I'm going to call this a known issue. The Exact Boolean algorithm that I implemented only works if all intersections are found -- the method for partitioning space depends on that. So it is supposed to always take self-intersections into account. But intersection finding can be a lot faster if it doesn't have to look for self intersections, so I let the user turn that off if they know there are no self intersections in either half of the boolean operation.

OK, I can get it to happen on Linux, about once out of every 4 times.

Hmm, I tried this with the latest build and could not get it to do this. I did this on my Mac. What platform are you using (I'm hoping this isn't platform specific, but grasping at straws here).

I've made an initial try at this, in D10951.

There is an angle below which it won't slide along the edge. It is 0.25 radians = 14.3 degrees. The reason for this was, I think, that at that angle, you have to go about 4 times as much along the sliding edge as the width desired (for offset mode), and people complained about "spikes". This seems like a very technical thing to expose in the UI (control over that angle). But since one can turn loop slide off, maybe I should just use a much tinier angle instead of .25 radians. I will investigate whatever bugs caused me to put 0.25 in in the first place and then decide what to do.

After talking with Hans about this some, I think I will generalize this node to have both an input attribute and result attribute. For now, both should be on the Point domain, though I can think of ways to generalize to other domains. On the point domain, the semantics are: the nominal smoothed result attribute value is gotten by taking, for each edge attached to the point, the average attribute value at each end of the edge, and averaging all those together. (This is what the Smooth modifier does for "position".) Then the Factor, which can be per-Point if the Factor input is also on the Point domain, is used as the interpolation factor between the original attribute value and the nominal smoothed result.

Yes, a NULL check was all that was needed (and also in the similar Collection case). Thanks for the report. Fixed.

Generally looks fine to me. But please find and fix the reason that it doesn't work for a Union operation.

I think this is about gathering together the transformational operations that work directly on the kernel-level (DNA-defined) object data. Kind of like what is in bmesh/tools (mostly) for transformation operations on mesh data in bmesh form.

i am looking at this now. There are lots of zero or near-zero area faces because the ring inside the face on the top of the arm pin (Cylinder.009) has what appear to be doubled vertices with zero-length edges connecting them. I advise selecting all vertices and then doing Mesh > Clean Up > Degenerate Dissolve on that mesh. Then the animation runs without crashing.

I was trying to reproduce the behavior of Fast, but it seems I misunderstood that behavior. Some experiments seemed to show that Fast just used the same slot # in the final result that was used for the material of the faces on the source (cutter) object, so that's what I did (if you add two more slots of materials to the icosphere and put the magenta material in the 3rd slot, which corresponds to where that material is in the cube, then it works). Also, if the target doesn't already have the source material somewhere in one of its slots, Fast doesn't copy the material over to the target. This seems kind of broken too, but I guess should, for now, just try to emulate exactly what the Fast mode does, which seems to be: look up the source material in the targets material slots: if found, use that slot #; if not found, just use the same slot #.

Sorry, discussing now with developers whether to revert this or wait for a compiler flag fix.

I tweaked the threshold used to decide "insideness" when meshes are non-manifold and the operation is Intersect. It now works in the Suzanne case.

I am looking at this. I think the new method I am using to decide inside/outside could use some tweaking. There are cases where the Fast's inside/outside test will fail on a boolean like Cell Fracture, though clearly this isn't one of them.

This was the same problem as T86308 and was fixed with rBcfd766cebdf6

Thanks for the bug report.

Looks good. Thanks! Please go ahead and commit this.

I will second the idea that it should be OK to put a script in the .blend file to aid the developer. E.g., when I have to debug why a particular bevel test is now failing, I find it easier to do from a script in the file. Not a script to replace the actual test, which remains the authoritative text to specify and execute the test, but as a debugging aid.

Working on it.

The change I made fixed the crash. But I do see that your example takes an awful long time to Boolean. Sorry!. This will be a good example for future performance tuning.

I have discovered the cause of the crash. The new code does its own triangulation using constrained delaunay triangulation, instead of the polyfill code that the old codepath used. I should probably just switch to using that old code path, which will be faster anyway (I was, probably out of an exceeding amount of caution, using the mulitprecision version of the CDT code). This might take a few days to fix. Meanwhile, you (bug reporter) might want to look for faces that look like this:

I made all the changes suggested by Campbell (except the ++i ==> i++ changes, after consulting with other C++ coders in blender.chat). I also made the change suggested earlier by Hans to change the interface so that it passes transform matrices instead of objects to the api I made. I am going to submit this to master now, hope that's OK.

As Philip said, these cases work fine, I believe, if you flip the normals of the bottoms of the cylinders with the spread-out bottoms.

I'll look at this.

Thanks Ankit. I forgot a bvhtree free. Fixed with commit rB0376b2f56617

While still no guarantees, the commit just mentioned makes this case work in exact boolean. Unfortunately, it is very slow. Much better results would happen if both operands were closed volumes.

While still no guarantees, the commit just mentioned makes this case work in exact boolean.

The commit just mentioned makes this case work properly in the exact mode.

That latest commit make new boolean work in this case (though it is still the case that there are no guarantees when all operands are not volume-enclosing.

@Brecht Van Lommel (brecht) Did you hand test a boolean with Exact solver picked? I think the current regression tests for Boolean and Modifiers only check the Fast mode (though I could be wrong). In any case, good news if it works as is. If you didn't update the library, I the library is properly adapting to using portable C code only rather than SIMD instructions.

If both operands are not volumes, trimming can be kind of ambiguous. You could say a difference A - B, where A, and B are both non-closed surfaces means: discard everything on the positive normal side of B from A, but I could draw lots of pictures where it is not clear what is on "the positive normal side of B", if B doesn't extend to effectively infinity. I'm sure you can image this.

This is indeed the same general issue: Boolean is not guaranteed to work when both operands are not volume enclosing. The old boolean will have issues too in certain orientations of the mesh. The code I have been playing around with seems to do better in this case. I just need to test it more before committing.