Triage: still an issue after baf9dc0, although I get many fewer problematic edges (different chord tolerance?).

Triage: per discussion in Evil-Spirit@51616bc#commitcomment-21277921, switching from ear-triangulation to Delaunay will help here.

@whitequark
What about using https://www.geometrictools.com/Samples/Geometrics.html?
Occasionally, my friend @bazhenovc made cmake building for this https://github.com/bazhenovc/WildMagic/commits/master

@bazhenovc
What do you know about this library? Is this the best choice?

Oh hello there.

I can say that this library does the job and the code is of high quality - so yes, I'd recommend it. I'd suggest to extract the needed classes rather then using the whole WM5/GTE - it's quite huge and you'll probably never need the whole package.

@bazhenovc Thanks for chiming in!

@Evil-Spirit This uses the Boost license, so it's compatible. It will remove a massive chunk of code from SolveSpace, if I understand correctly (exactly which?). Seems easy to integrate, though I think using a submodule is preferable to copying files (history is lost, upgrades are painful, etc).

History will be lost no matter what you'll do - their source code is distributed in zip archives.

In these cases I normally import releases into git version by version (which is quite easy with a script), so we can still easily bisect, and also easily track/rebase our changes on top of their classes.

@bazhenovc
Thanks for information!

@whitequark
At least we can use Delaunay triangulation.

Anything else?

there is CORK, some library for booleans.
Not sure this is production ready
http://arc-team-open-research.blogspot.ru/2014/10/boolean-operations-powerful-cork.html

There's this issue with it:

WARNING: Unfortunately, there are a number of known problems with Cork. I have zero time to work on the library since I'm currently busy working on a thesis. (March 2016) If you would like to pay me large sums of money to improve this library, maybe we should talk. Otherwise, I'm really quite sorry to say I don't have time.

It might still be better than our current booleans, but I'm not sure of a good way to compare them.

It also uses LGPL so this creates obvious distribution issues for us, but that's comparatively minor.

Using current master (dbf5a8d) with default setting this gives me 8 bad edges. Switching it back to NURBS produces zero bad edges even if I increase max_segments to 100 and lower chord tolerance to 0.01 percent. It is always best not to use triangle mesh unless something goes wrong with a NURBS boolean operation. Maybe at the time this issue was opened that was necessary.

This is still an issue and a fairly simple test sketch.

I just revisited this model with commit 61cc28f (late in 3.0 prior to 3.1) and the problem is still there. I noticed that switching to NURBS and then back to triangle mesh often changes the number of bad edges. Anywhere from zero up to 126 but typically about 30. There seem to be some randomness in the boolean operations on triangle meshes.