This PR combines BoykoNeov#5 with BoykoNeov#6 rebased on top of it. In addition I added an extra commit that adds 1291_1743_cube_cut_tangent_outside_still_fails_simplified.zip as a test case that covers both #1291 and #1743.

The original comments form Claude Opus 5:

BoykoNeov#5

Fixes the tangent-outside case from #1291 — @ruevs' 1291_cube_cut_tangent_outside_still_fails.slvs, which still failed after the nine commits of #1731 that are now in master.

This continues that work and sits directly on current master. It does not include the two commits from #1731 that you decided against (the SKdNode::FindEdgeOn relaxation and its tests) — this fix is independent of them, and I rebased it off them so there is nothing to re-litigate here.

Both of the obvious explanations are wrong

I had two candidates going in, and I want to record that they're dead so nobody spends time on them:

1. "The tangent intersection curve is never generated" — the interior-profile-tangency limitation I documented in Classify Boolean edges where a tangent fillet surface folds onto the shell. Fixes #1291. #1731. It does not apply. The profile cubic has ctrl[2] = (30, −12.2621) and ctrl[3] = (30, 18.7884), both at x = 30, so the tangency is at the bezier's endpoint, and the exact-in-plane path from that PR fires correctly: EXACT-IN-PLANE (30, 18.7884, 30) → (30, 18.7884, 0).
2. "906cf739 discards it" (Don't keep Boolean intersection edges that lie along the trim boundary) — ablating that commit gives byte-identical output. Not the culprit.

The curve is generated correctly and then thrown away by misclassification. It reaches MakeCopyTrimAgainst as three chains, all with KEEP = 0 (ins = COINC_OPP, outs = OUTSIDE in one direction, reversed in the other). The cube's x = +30 face is left with five edges, AssemblePolygon fails with failed: I=5, avoid=4, and the face disappears from the output.

Root cause

In SShell::ClassifyEdge()'s edge-on-edge case (src/srf/raycast.cpp), the edge_inters == 2 mixed branches — where one face's direction cosine is ~0 and the other's is not — assume that a face whose normal is parallel to ours is coincident with our surface. It may instead be merely tangent at the shell's edge and curving away immediately. First-order data at the point of contact cannot tell those apart.

This is the same class of defect as the both-tangent branch fixed in #1731, in the branches that PR left alone. I flagged it there as out of scope for lack of a model that reached it; @ruevs' file is that model.

The fix

Extract the both-tangent branch's existing geometry probe as ProbeTangentFace() and apply it to the mixed branches too: probe the parallel-normal face a short distance into itself (scaled by that face's own control-net size) and see whether it stays in the tangent plane or leaves it. If it curves away, that side is classified SURF_INSIDE / SURF_OUTSIDE by the sign of dev * surf_n·inter_surf_n rather than being called coincident.

Faces that really are flat take the old path unchanged, so nothing that worked before changes answer.

Regression test

test/group/boolean_tangent_crossing/ — @ruevs' file verbatim, checking that the display mesh is watertight (no naked or self-intersecting edges) and that the volume matches. Fails with (leaks) = true without the fix. Volume rather than image checks, consistent with the other Boolean cases.

Verification

• Full suite passes in Debug and Release: 263 cases / 931 checks (master is 262 / 925).
• The NURBS result matches the mesh-Boolean ground truth of the same model (forceToMesh = 1) to the last digit: 38 triangles / volume 204432.7149 / 0 naked edges, against 54 triangles / 204432.7149 / 0 naked edges.
• The 12-model sweep of every repro from Rounded corner cut (fillet) issue #1291, NURBS failure when ClassifyEdge fails (was: Difference fail depending on compilation options (was: Difference fail with OpenMP)) #1619 and NURBS failure with countersunk holes #1091 is unchanged, with every previously documented volume still exact.
• Since this branch does not carry the naked-edge checker change from Classify Boolean edges where a tangent fillet surface folds onto the shell. Fixes #1291. #1731, the "0 naked edges" above was re-established with the unpatched checker.

Not addressed

@phkahler's two-sided-extrusion case. There is no model attached to the issue for it yet. Flipping a working model's group subtype 7000 → 7001 does produce failures, but that is not his geometry — it doubles the tool length so it pokes out of the top of the cube, and the tangency still involves one tangent and one crossing face rather than being tangent to both fillet faces. Those failures are pre-existing and unchanged by this PR. I'd rather wait for the real model than claim a fix I can't demonstrate.

Please fetch and fast-forward this branch rather than using the merge button on my fork — that keeps it a clean fast-forward for upstream.

🤖 Generated with Claude Code

BoykoNeov#6

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

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

Root cause

@phkahler's hypothesis in #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 #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

• 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)) #1619 / NURBS failure with countersunk holes #1091 / Rounded corner cut (fillet) issue #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.