Rows without an analytic volume (the fuzz seeds) get one from the
primitives' definitions, by no kernel: along each vertical line both
operands are exact z intervals, combined exactly, integrated over a grid
whose cell edges include every straight face, with the half-resolution
grid bounding what error is left. Each kernel's volume is graded against
it (within 1e-3 relative or 3x that bound), in the JSON per row and in the
report's summary.
On 64 seeds truck is right on all 192 rows. SMLib's own measure is wrong on
13, all with cylinders or spheres, although truck's measure of the same
exported bodies is right on every one of them; 5 give no closed solid.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When SMLib's volume of a boolean result differs from truck's, the report could
not tell a wrong body from a wrong SMLib measure. The runner now measures the
result it exports back to truck as well, keeps that volume in the JSON, and
shows it in the export column wherever it leaves SMLib's own measure or SMLib
could not measure the body at all.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QWhMwdqJYQKQq8RCLSL1LT
The side-by-side runner now reports how long each boolean takes on truck and
on SMLib (the call alone), and apart from that the SMLib side's conversions:
the operands' truck→SMLib import and the result's SMLib→truck export, which
the app pays while truck still holds the bodies. The report gains a times
summary (median, worst, total), solid counts, the analytic volume of each named
case's union, intersection and cut, and how many results land on it.
It also runs the "each cut gets slower" case from TASK_kernel-smlib-booleans as
a named sequence: a 63.6 × 31.7 × 9.5 block, a Ø20 × 10 boss joined on top, a
slot front to back, a Ø6 cross hole through the boss and a slot that splits
the block, each step on the previous result. SMLib keeps its own results from
step to step (only the tools come from truck), in a child process like the
cases, and every step's volume is checked against its closed form.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QWhMwdqJYQKQq8RCLSL1LT
The smlib_booleans example answered "not supported yet" for every SMLib case.
Now it runs solidcraft_smlib::Brep::boolean on the tagged operands (cut maps
to Subtract, None is an empty result), reads the result's history from the
tags, and measures its volume with mass_properties at MEASURE_ACCURACY, so the
report compares truck and SMLib on real results.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QWhMwdqJYQKQq8RCLSL1LT
Boxes and cylinders go into SMLib as truck's own B-reps, through their
schema 4 records (smlib_body), so both kernels start from the same input
whatever the axis. Spheres and tori are SMLib's primitives about +Z, like
truck's, since the import doesn't take truck's revolved surfaces yet. All
41 cases' operands now build; only the boolean itself waits for its shim.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
examples/smlib_booleans runs truck and SMLib on the same cases (named pairs
whose results are known by hand, then fuzz::boolean_shapes for N seeds),
each as union, intersection and cut, and compares volume, face and edge
counts and the shape of the history (how many faces Kept, Modified, Split,
Merged, Generated; edges from an operand edge, new, or without origin). It
writes a JSON and a Markdown report and never changes the default kernel.
SMLib runs in a child process per case, so a crash inside it is reported as
that case's result. Its primitives and booleans arrive with the operation
shims; until a call exists the case is reported as not run on SMLib.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brennen Herbruck