recipe 01 fillet never applies: radius 8 exceeds the 5mm leg thickness, hidden by ?? fallback

[gsdali]

Found while running the version comparison for #101.

The defect

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

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

With the recipe's own parameters, filletRadius = 8 and thickness = 5, this always returns
nil and the ?? prism fallback fires. The bracket ships with a sharp inside corner.

A fillet radius of 8 mm cannot be placed on a 5 mm thick leg: the radius exceeds the material.
Measured directly on the recipe's prism:

r=8.0 (configured) -> nil (FALLBACK FIRES) removed=0.00
r=5.0              -> nil (FALLBACK FIRES) removed=0.00
r=4.9              -> ok  removed=475.01
r=3.0              -> ok  removed=176.42

Corroborated end to end: reproducing the full recipe shows prism = 19000.00 and
afterFillet = 19000.00, identical, at OCCTSwift 1.3.1, 1.15.0 and 1.17.0 alike. This has never
worked, at any version.

Why it matters

The fillet is advertised in three places:

• main.swift:4, "an L-bracket with a filleted inside corner"
• main.swift:7-8, which explains selecting it "geometrically with Shape.concaveEdges()
  (OCCTSwift v1.3.1, #171) rather than by a fragile edge index"
• the README's description and its "OCCTSwift APIs used" list

The recipe is a reference example whose stated purpose is demonstrating concaveEdges()-driven
filleting, and that is the one thing it does not do.

Suggested fix

1. Pick a radius that fits. Anything below the 5 mm leg thickness works; 3 mm removes
   176.42 mm3 and leaves a sensible bracket. 4 mm is probably the largest sane choice.
2. Remove the silent fallback. ?? prism should not be how an advertised feature degrades.
   Force-unwrap or fail loudly, as recipe 03 chamfer never applies: chamfered() returns nil and the ?? fallback hides it #103 did for the flange chamfer.
3. Regenerate output.brep, which is needed for recipe 01 (mounting-bracket) volume drifts 2.27% from committed reference under OCCTSwift 1.17.0 #101 anyway.

Related

This is the third instance of the same pattern:

• recipe 03 revolves a wire, so the flange is a shell rather than a solid #100, recipes emitting shells while documenting solids
• recipe 03 chamfer never applies: chamfered() returns nil and the ?? fallback hides it #103, flange chamfer returning nil behind ?? flange
• this one

Common shape: an optional-returning geometry op degrades silently via ??, the output still looks
plausible by every metric measured, and the docs keep describing the intended behaviour. Worth
considering a sweep for ?? fallbacks on geometry operations across the recipes, and a policy
line about it, rather than fixing them one at a time as they are discovered.

[gsdali]

Correction: the radius was never the problem

Resolved by #106 (merged as 60b1bd2), but this issue's title and diagnosis are wrong and should not be read as the record.

I wrote "radius 8 exceeds the 5mm leg thickness". That is true of the edges concaveEdges() returns, but those are not the bracket's inside corner. The real cause is that the classifier returns the wrong edges entirely:

edge[7]  the true reentrant edge   len=40, x:[5,5] y:[5,5] z:[0,40]    -> classified CONVEX
edge[9]  concaveEdges() result #1  len=45, x:[5,50] y:[5,5] z:[40,40]  -> classified CONCAVE
edge[12] concaveEdges() result #2  len=45, x:[5,5] y:[5,50] z:[40,40]  -> classified CONCAVE

The two returned edges are top-cap perimeter segments bounded by the 5 mm leg thickness, which is why an 8 mm radius failed against them. The genuine inside corner is bounded by legLength - thickness (45 mm) and fillets cleanly from r=0.1 to r=44.9.

So filletRadius = 8 was correct all along and #106 left it unchanged. My suggested fix ("pick a radius that fits; 3 mm is sensible") would have produced a working-looking bracket with the wrong edge rounded and the real corner still sharp, and the volume would have looked plausible.

Two further corrections to what this issue says:

• A fillet on a reentrant corner adds material, it does not remove it. The measured +549.38 mm3 matches 8^2 * (1 - pi/4) * 40 exactly. The "removed=" figures quoted above were from filleting the wrong edges.
• "This has never worked, at any version" is right, but not for the reason given. The classifier defect is OCCTSwift 1.x only and is fixed in the 2.0.0 line, verified on v2.0.0-kernel.1 and raised upstream as OCCTSwift#695.

The durable version of all this is okf/decisions/concave-edge-classifier-can-select-wrong-edges.md, which carries the repro and scopes the workaround to 1.x. Prefer that over this issue body.