recipe 01 (mounting-bracket) volume drifts 2.27% from committed reference under OCCTSwift 1.17.0

[gsdali]

Summary

recipes/01-mounting-bracket's committed output.brep reference no longer matches what
the recipe currently emits: volume drifts by 2.27%, well outside Scripts/recipe-check.sh's
default 1e-3 relative tolerance.

reference: 18654.517 mm^3
current:   18230.310 mm^3

Reproduction

swift run occtkit run recipes/01-mounting-bracket/main.swift --format brep --output /tmp/out
swift run occtkit metrics /tmp/out/body-0.brep --metrics volume
swift run occtkit metrics recipes/01-mounting-bracket/output.brep --metrics volume

Deterministic across repeated runs (not flaky). solidCount is still 1 in both cases,
so this is not a topology regression like #100, it is a numeric drift, most likely in the
Shape.filleted(edges:radius:) result on the bracket's concave inside corner
(prism.filleted(edges: prism.concaveEdges(), radius: filletRadius)), the only non-trivial
geometric operation in this recipe beyond extrude and drilling.

Suspected cause

Bisected to the OCCTSwift dependency version. The committed reference was generated
against OCCTSwift 1.15.0. Re-running the recipe against 1.15.0 was not re-verified here,
but a worktree pinned to OCCTSwift 1.17.0 (Package.resolved, no other change) reproduces
the drift, and no other recipe in the cookbook shows any drift at all on the same 1.17.0
pin (04-spur-gear, 05-lattice-cube, 06-fan-blade, 07-sheet-metal-channel all match
their references to Δvol 0.00e+00). That narrows it to something in 1.15.0 to 1.17.0
that specifically affects fillet results on concave edges, not a general geometry kernel
change.

How this surfaced

Found while working #100 (recipe-check.sh hardening to assert solidCount >= 1). Not
in scope there: recipe 01 already has solidCount == 1 and was explicitly out of scope
for that fix. Separately, Scripts/recipe-check.sh had a bug (fixed in the #100 PR) where
a Python validation failure inside check_one() was not propagated to the function's
return status, so this drift was failing recipe-check.sh's own assertion but still
printing "OK" and exiting 0. make recipes-test will start failing on 01-mounting-bracket
once that PR lands, for this reason, not a regression introduced by that PR.

Next steps

• Confirm on a clean OCCTSwift 1.15.0 vs 1.17.0 bisect (not just resolved-version
  comparison) whether filleted(edges:radius:) on a concave edge changed behaviour.
• If the new result is geometrically correct, regenerate recipes/01-mounting-bracket/output.brep
  and note the fix in recipes/01-mounting-bracket/README.md.
• If not, file upstream against OCCTSwift.

[gsdali]

Strong lead on the cause: concaveEdges() appears to select an extra edge

Found while reviewing #103, which turned up an independent edge-classification oddity on a
completely different shape. This is a hypothesis with supporting arithmetic, not a confirmed
diagnosis; the decisive test is noted at the end and I have not run it.

The mechanism

recipes/01-mounting-bracket/main.swift:40:

var bracket = prism.filleted(edges: prism.concaveEdges(), radius: filletRadius) ?? prism

The L-profile has exactly one reentrant corner, at (thickness, thickness), so the extruded
prism should have exactly one concave edge. Measured under OCCTSwift 1.17.0:

prism vol      = 35840.00
concaveEdges() = 2 edge(s)      <- expected 1
convexEdges()  = 16 edge(s)
filleted vol   = 35015.82
removed        = 824.18 mm3

An analytic fillet of radius 6 along the 40 mm width removes r^2 * (1 - pi/4) * L = 309 mm3,
so 824 is far more than one fillet accounts for.

The arithmetic lines up with "one extra fillet"

#101 drift (reference - current) = 424.21 mm3
fillet removal now               = 824.18 mm3   (concaveEdges() = 2)
implied removal before           = 399.97 mm3
ratio                            = 2.06x

A ratio of essentially 2.0 is what you would expect if the same operation is now filleting two
edges where it previously filleted one, and the extra edge accounts for the drift almost exactly.

Independent corroboration from a different shape

#103 hit the same class of problem on the pipe flange, where concaveEdges() returns empty
despite a clearly reentrant corner (confirmed reentrant by volume: chamfering that edge alone
increases volume by about 158 mm3, because it fills the corner rather than breaking it), while
convexEdges() includes that reentrant edge and excludes a genuinely convex one.

So two unrelated shapes both show convex/concave classification disagreeing with what the
geometry actually does. That points at the classifier rather than at either recipe.

What this would mean

If confirmed, the 2.27% drift is not a benign tolerance change to be absorbed by regenerating
the reference. It would mean recipe 01 is now rounding an edge it should not, so the committed
reference is right and the current output is wrong. Regenerating the reference would bake in the
defect and silence the signal.

That distinction matters for #102, which is currently blocked on the question of whether to
regenerate.

The decisive test, not yet run

Resolve the package against OCCTSwift 1.15.0 and re-measure prism.concaveEdges().count on the
same prism. If it returns 1 there and 2 at 1.17.0, this is confirmed and belongs upstream as an
OCCTSwift regression in concaveEdges() / convexEdges() classification, with #101 downgraded to
"pin or wait for the upstream fix" rather than "regenerate the reference".

Worth doing before deciding what to do with the reference.

Note on the fallback

?? prism here is the same silent-degradation pattern as #103. It is not firing today, since the
fillet succeeds, but if the classifier ever returns an unfilletable set this recipe would quietly
ship an unfilleted bracket.

[gsdali]

Correction: my previous comment's hypothesis was wrong. Here is the actual cause.

I ran the comparison. concaveEdges() has not changed, so the theory in my previous comment
is refuted and should not be acted on. Correcting it in full below, with the real mechanism.

The concaveEdges() theory is dead

A minimal standalone probe depending only on OCCTSwift, run at three versions:

1.3.1  -> prism=35840.00 concave=2 convex=16 filletOK=true removed=824.18
1.15.0 -> prism=35840.00 concave=2 convex=16 filletOK=true removed=824.18
1.17.0 -> prism=35840.00 concave=2 convex=16 filletOK=true removed=824.18

Byte-identical. The 2.06x ratio I reported was a coincidence, and my scratch test compounded it by
using filletRadius = 6 when the recipe actually uses 8. concaveEdges() still returns 2 on a
shape with one reentrant corner, which remains odd, but it is not the cause here and it is
stable across versions.

What the reference was actually built against

Not 1.15.0. recipes/01-mounting-bracket/output.brep was last written by 99b1f09 on 2026-06-07,
whose message says "on OCCTSwift 1.3.1". So the span is 1.3.1 to 1.17.0, much wider than I
assumed.

The real cause: drilled was under-cutting at 1.3.1

Reproducing the recipe exactly (legLength 50, thickness 5, width 40, holeRadius 3.5):

1.3.1   prism=19000.00  fillet=19000.00  d1=18913.63 d2=18827.26 d3=18740.89 d4=18654.52
1.17.0  prism=19000.00  fillet=19000.00  d1=18807.58 d2=18615.15 d3=18422.73 d4=18230.31

Both final figures reproduce the real artifacts exactly: 18654.52 is the committed reference,
18230.31 is current output. So this probe is the recipe.

Per hole:

version	removed per hole	expected pi * r^2 * t
1.3.1	86.37 mm3	192.42 mm3
1.17.0	192.42 mm3	192.42 mm3

pi * 3.5^2 * 5 = 192.42. 1.17.0 matches to the penny. 1.3.1 removed 44.9% of the correct
material, so the holes were not going all the way through.

Conclusion: the drift is a fix, not a regression

The committed reference is wrong. Current output is right.

This reverses the recommendation in my previous comment. The correct resolution for #101 is to
regenerate recipes/01-mounting-bracket/output.brep, and the 2.27% is the recipe finally
drilling its four holes properly.

Nothing needs to go upstream. This is a kernel fix landing somewhere between 1.3.1 and 1.17.0
being noticed two months late, because the reference was never regenerated and, per #102, the
check that would have flagged it was reporting passes regardless.

Separate defect found while doing this: the fillet has never applied

r=8.0 (the recipe's configured value) -> nil (FALLBACK FIRES) removed=0.00
r=5.0                                 -> nil (FALLBACK FIRES) removed=0.00
r=4.9                                 -> ok  removed=475.01

filletRadius = 8 on a thickness = 5 leg is geometrically impossible: the radius exceeds the
material. filleted(...) returns nil, ?? prism swallows it, and the bracket ships with a sharp
inside corner while its header, README and API list all advertise a filleted one. Note
fillet=19000.00 equals prism=19000.00 at both versions in the runs above.

That is the third instance of this exact pattern, after #100 (shell shipped as solid) and #103
(chamfer never applied). Filed separately so #101 stays about the drift.

[gsdali]

Confirmed upstream, and already fixed. The current value is the correct one.

Checked before acting on the regenerate recommendation. It holds up.

The upstream bug

OCCTSwift#272, closed 2026-07-18:
"Shape.drilled(at:direction:radius:depth:) ignores direction, bridge hardcodes the cylinder to
+Z". The bridge computed the bore's bottom point correctly along direction, then built the
cutting cylinder with OCCTShapeCreateCylinderAt, which always used gp_Dir(0, 0, 1).

Recipe 01 drills along Y and X, so all four of its holes were affected.

Proven arithmetically, not just by correlation

If the cylinder is forced to +Z, the first hole's axis sits at y = -1.0 while material occupies
y >= 0, so only the circular segment above the face cuts:

segment area = r^2*acos(d/r) - d*sqrt(r^2 - d^2),  r = 3.5, d = 1.0  = 12.3387 mm2
x drill length 7.0                                                    = 86.37 mm3

measured removal at OCCTSwift 1.3.1                                   = 86.37 mm3

An exact match, which rules out coincidence. The old reference was not drilling holes at all; it
was shaving a lens off the face.

Bisected

1.12.0  -> perHole = 86.37   (broken)
1.12.9  -> perHole = 192.42  (fixed)

Consistent with #272 closing on 2026-07-18 and v1.12.9 publishing on 2026-07-19.

The current value is correct and stable

pi * r^2 * t = pi * 3.5^2 * 5 = 192.42 mm3

1.17.0          -> perHole = 192.42   final = 18230.31
2.0.0-kernel.1  -> perHole = 192.42   final = 18230.31

Exactly pi*r^2*t, and unchanged into the 2.0 kernel prerelease, so this is not a transient that
will move again next release.

The two later drilling issues do not affect this

Both closed after v1.17.0 shipped, so their fixes are not in our pin:

• #496, closed 2026-07-30, OCCTShapeDrillHole duplicating BRepFeat_MakeCylindricalHole with a cruder boolean algorithm.
• #532, closed 2026-08-01, BRepFeat_MakeCylindricalHole removing no material across a multi-body stack.

Neither changes the single-solid through-hole result, which is already exact at 1.17.0 and holds
at 2.0.0-kernel.1. Worth knowing they exist if drilling behaviour is ever questioned again, but
they are not in play here.

Conclusion, unchanged

Regenerate recipes/01-mounting-bracket/output.brep. The committed reference bakes in
OCCTSwift#272, and the 2.27% is the recipe finally drilling its four holes properly.

Nothing to raise upstream. This is a fixed upstream bug surfacing two months late because the
reference was never regenerated and, per #102, the check that should have caught it was reporting
passes regardless.

[gsdali]

Resolved in #102 (merged as 5812e17), which regenerated recipes/01-mounting-bracket/output.brep from 18654.52 to 18230.31.

The drift was OCCTSwift#272, Shape.drilled ignoring direction and hardcoding +Z, fixed between 1.12.0 and 1.12.9. The old reference was built at 1.3.1 and baked that in: it removed 86.37 mm3 per hole, exactly the circular-segment volume a +Z-forced bore entering at y = -1 would cut, rather than the pi*r^2*t = 192.42 of an actual through-hole.

So the reference was wrong and the current output is right. Nothing to raise upstream.

Note the bracket is still un-filleted in the new reference. That is a separate defect, #105: filletRadius = 8 exceeds the 5mm leg thickness so filleted(...) returns nil at every version, and ?? prism hides it. Fixing that will regenerate this reference once more.