New TriangleSplitter

[gkjohnson]

Related to #51, #97

TODO

• Add "verbose" flag & update docs
• Implement the proper algorithm for inserting segments. From the paper:
  • required segments can intersect - need a point inserted
  • insert points first
  • remove triangles that conflict
  • triangulate using earcut
  • https://github.com/gcherchi/FastAndRobustMeshArrangements
  • https://dl.acm.org/doi/10.1145/3414685.3417818

Follow On

• Potentially able to determine coplanar triangles much more easily (triangles within a coplanar triangle)
• We have half-edge connectivity and "required" edges
  • These can be used to more quickly determine connected triangle sets to add together and reduce raycasts
  • Because it will be easier to track the original half edge sibling we can even use the sibling edges raycast result
  • We can use these to update the half edge structure instead of rebuilding it from scratch
• Potentially enables easier water-tight detection
• Potentially able to choose edge direction that keep triangles fairly large

[ToyboxZach]

I have been trying to get this to work for us locally and I believe this will fail if the triangles only intersect at a single point:

__
|  /
| /*----
|/ |
   |

Since they are intersecting at that point you still need to insert it into your graph, otherwise the graph will not know about that point

This logic then needs to be moved to the two places you call getTriangleLineIntersection and choose to add a point if it is a single point edge.

[ToyboxZach]

Causes the issue in the fiddle here:
#210

[ToyboxZach]

Another issue we ran into.

Swapping this edge can lead to one of the triangles to be a 0 area triangle, which then makes it not able to clean up.

I'm not sure if there is a downstream place to fix it, but we discovered this would lead to some invalid geometry.

If I check if the resulting triangles are not 0 area this ends up not being a problem

[ToyboxZach]

Actually I looked into this more and the problem is a bit more generic.

This function swaps edges, which can lead to an invalid triangle or a flipped triangle.

So we need to detect if the swapped edge will interect or flip over the none change edge for both of the attached triangles:

I can improve this by adding this to swapEdge

const otherEdgeIndex = ( t0SwapIndex + 1 ) % 3;
		const otherEdgeIndexReverse = ( t1SwapIndex + 1 ) % 3;
		const otherEdge = triangle.edges[ otherEdgeIndex ].edge;
		const otherEdgeReverse = reverseTriangle.edges[ otherEdgeIndexReverse ].edge;
		const travlingEdge = { start: triangle.points[ t0SwapIndex ], end: reverseTriangle.points[ t1SwapIndex ] };
		const res = { x: NaN, y: NaN };
		const resReverse = { x: NaN, y: NaN };
		 closestPointLineToLine( otherEdge, travlingEdge, res );
		 if ( res.x <= 0 || res.x >= 1 ) {

			edge.required = true;

			return false;

		}

		 closestPointLineToLine( otherEdgeReverse, travlingEdge, resReverse );
		 if ( resReverse.x <= EPSILON || resReverse.x >= 1 - EPSILON ) {

			edge.required = true;

			return false;

		}
		
		```

[ToyboxZach]

I have started using this branch and overall its a huge improvement over the old triangle splitter. I was able to find a couple small issues.
https://github.com/ToyboxZach/three-bvh-csg/tree/FixTriangleSplit

I made three fixes:

1. In the triangle splitter, if a triangle splits a triangle and ends directly on another edge the package used to ignore that point, we now correctly handle that.
2. In edge sape, it was possible for those faces to be invalid this change fixes it so its much more unlikely to generate an invalid face.
3. If there is a 0 area triangle we just don't add it to the final mesh, this was creating a few cases of extra edges/bounding box weirdness that was not necessary. I think the real fix is probably to not generate these 0 area triangles, but I need to move on to something else so I didn't dive too deeply into the issues.

I ended up finding most of these issues using various orientations of coplanar Boxes and TextGeomtery which gives a whole bunch of orientations

This is what was happening with this PR:

This is after my small fixes:

[ToyboxZach]

This should probably check > EPSILON

[ToyboxZach]

Could you explain why 3 was chosen? I ended up with a case where I needed a few more iterations, and _edgesToSwapLength ended up being enough

[gkjohnson]

I think 3 is just the number I was using for my testing at the time.

[gkjohnson]

Thanks for taking a deeper look @ToyboxZach. As mentioned in #210 - there are still some issues with this approach. Specifically just "swapping edges" isn't good enough to generate a good topology. The paper referenced in the original comment instead requires that something like earcut triangulation be performed when we find that edges need to be swapped. Unfortunately the defacto javascript earch implementation (from MapboxGL) isn't robust to some scenarios and will produce bad triangulation. I think a CDL implementation (referenced in #210) would be easier to work with.