Split Boolean curves where they cross a curve of the other shell. Fixes the cube_cut_2 case from #1743

[BoykoNeov]

Written by Claude Opus 5 — both this text and the code it describes; posted by @BoykoNeov.

Fixes the cube_cut_2 case from solvespace#1743. Two commits on top of master 790bf74c.

Root cause

@phkahler's hypothesis in solvespace#1743 is right, and this is the trace that proves it.

Where the two shells touch rather than pass through each other, a curve of one shell can cross a curve of the other at a point that is a vertex of neither input shell, and that lies on no surface which either curve crosses transversally. SCurve::MakeCopySplitAgainst() splits curves against surfaces, so at such a point it splits only whichever of the two curves does meet a transversal surface there, and leaves the other one whole.

The unsplit curve then contributes a single trim edge whose two halves classify differently. That cannot be represented: MakeCopyTrimAgainst() assembles the trim polygon from chains that FindChainAvoiding() builds, classifies each chain from one representative edge, and keeps or discards it whole. So the edge is lost along with the rest of its chain, AssemblePolygon() fails, and the face goes missing.

@ruevs' simplified model is the clearest example. A 2×2×2 triangular prism, minus a tool swept along a bezier profile from (1,0) to (0,1), z ∈ [−0.5, 0.5]. The tool's flat base face lies in the plane y=0, coincident with the prism's y=0 face, and the profile is tangent to y=0 at its (1,0) end. So the tool's corner edge x=1, y=0 runs within the prism's y=0 face, and crosses the prism's own bottom-front edge y=0, z=0 at (1,0,0).

The tool's edge does get split there — it crosses the prism's z=0 face transversally. The prism's edge does not: the only tool surfaces it meets at x=1 are the coplanar base face and the tangent swept face, neither of which it crosses. An instrumented run then shows the whole 5-edge boundary of the prism's y=0 face arriving as one chain:

ORIGCHAIN A3 n=5 (0,0,0.5)->(2,0,2) ins=CSAME outs=CSAME KEEP=0
...
final: 2 edges
failed: I=3, avoid=3

CSAME is correct for the half of that boundary inside the coincident patch (x ≤ 1) and wrong for the half outside it — which is exactly the situation the missing split creates.

The asymmetry within the same model is worth noting, because it shows the rule at work: at the profile's other end the tool's third face crosses the prism's x=0 face transversally, so that prism edge did get split, at y=1. Only the touching end fails.

The fix

SShell::SplitCurvesAtCrossings(), called from MakeFromBoolean() immediately after the two CopyCurvesSplitAgainst() calls: collect the interior vertex == true points of every source-A curve and every source-B curve, and insert each into the other operand's curves wherever it lies within one of their piecewise linear segments (axis-aligned bounding box prefilter, strict 0 < t < 1, within LENGTH_EPS of the chord) and — for exact curves — within LENGTH_EPS of the exact curve, since the chord of a curved segment is not the curve.

Interior points only, deliberately. A curve's endpoints are its own shell's vertices, which FindVertsOnCurve() already propagates from the trims, and an exact intersection curve's endpoints may lie outside the real geometry entirely — which is what solvespace#1452 was about. test/group/boolean_coplanar_union stays green.

It runs before MakeIntersectionCurvesAgainst(), and RemoveShortSegments() runs after it, so a point landing very close to an existing one cannot leave a degenerate segment behind (the Equals check already rejects anything within LENGTH_EPS of an existing point, so the shortest new segment is longer than that).

Regression test

test/group/boolean_cross_vertex/ — @phkahler's cube_cut_2 from the issue, unmodified. Watertight, not self-intersecting, and a volume check.

The expected volume is the value the same model gives when built as a mesh Boolean instead of a NURBS one (Group.forceToMesh): 203485.224213202 against the NURBS result's 203485.224213201, which is agreement to 2.9e-15 relative. That is the real validation — the constant is not just "whatever this build printed".

No CHECK_SAVE/CHECK_RENDER, following the other Boolean cases here: the surface cache holds last-ulp floats that PrepareSavefile does not normalize.

The committed test against unmodified boolean.cpp fails (inters) = true with two failed to assemble polygon to trim nurbs surface in uv space messages.

Verification

model	master	this branch	mesh-Boolean truth
cube_cut_2	28 tris / 171862.60 / 17 naked	38 / 202243.1316 / 0 naked	56 / 202243.1315 / 0
ruevs' simplified	22 / 10 naked	24 / 6 naked	48 / 0 naked

• Full suite 263 cases / 931 checks, Debug and Release (master baseline 262 / 925).
• The 12 repro models from NURBS failure when ClassifyEdge fails (was: Difference fail depending on compilation options (was: Difference fail with OpenMP)) solvespace/solvespace#1619 / NURBS failure with countersunk holes solvespace/solvespace#1091 / Rounded corner cut (fillet) issue solvespace/solvespace#1291 all still exact, every documented volume unchanged to the last digit, Debug and Release identical.
• 5 repeated runs with OpenMP on give a single sorted triangle set for both models.
• Vector::WithMagnitude(1) of zero vector! appears three times while this test runs. It is the pre-existing triangulator diagnostic on tangent geometry, not something this patch introduces: on unmodified master boolean_knife_edge prints it 18 times, boolean_tangent_spline 6, boolean_tangent_fillet 3.

What this does not fix

ruevs' simplified model still has 6 naked edges on this branch alone. It needs a second, independent fix — the tangent-crossing classification in ClassifyEdge() — and with that stacked on top it comes out clean at 28 triangles, 0 naked. The two defects are genuinely separate: cube_cut_2 is fixed by this change alone, and the classification change alone leaves cube_cut_2 at 17 naked edges.

curve_curve.slvs is a third, different defect, and this does not touch it. It is not the original-curve split at all. The failing curves are the two intersection curves on the plane y = 21.873392, which should each be split where they cross the box's x=0 face at z = ∓13.164015. One of them is, by AllPointsIntersecting() inside surfinter.cpp's own MakeCopySplitAgainst() call — leaving a spurious segment 1.9e-5 long. Its mirror image is not: its nearest piecewise linear point sits 2.5e-5 away from the point it needs. FindVertsOnCurve() is not involved anywhere on this model; instrumented, it yields zero candidates. So the gap is about 1e-5 wide and LENGTH_EPS is 1e-6 — propagating vertices cannot bridge it, and closing it means changing a tolerance, which I did not want to do speculatively.

So the two models @phkahler attached are not two instances of one cause. cube_cut_2's two missing faces are (that is the "two of them for the same reason"); curve_curve is a separate accuracy problem in the intersection-curve split.

One more thing worth knowing about curve_curve: it is OpenMP-nondeterministic on master and on every branch here, cycling through four outcomes (88 tris/4 naked, 75/13, 71/15, 63/17) and deterministic only with OMP_NUM_THREADS=1. Single-run comparisons on that model will mislead whoever picks it up.

---

If this looks right, please fetch and fast-forward rather than using the merge button, so the history stays linear for upstream.

[ruevs]

ruevs' simplified model still has 6 naked edges on this branch alone. It needs a second, independent fix — the tangent-crossing classification in ClassifyEdge() — and with that stacked on top it comes out clean at 28 triangles, 0 naked. The two defects are genuinely separate: cube_cut_2 is fixed by this change alone, and the classification change alone leaves cube_cut_2 at 17 naked edges.

I can confirm. This alone fixes the "left side":

Combined with #5 fix-1291-tangent-crossing both sides are fixed:

The model: solvespace#1743 (comment)