An edge whose curve runs a few um past its vertex and its spline face's
patch was trimmed back by SMLib when it made the trim, and the face was
refused ("SMLib moved an edge's interval"). Our own measure never saw the
gap: STEP measures an edge against its surface only where the nearest point
is in closed form, and a spline face's gaps only on the pcurves the kernel
returns, after SMLib has trimmed the edge. Each bare use's edge is now
measured by SMLib (smlib_brep_edge_face_distance, over the patch) after the
sheet's import, its tolerance raised to cover the gap with
SURFACE_GAP_MARGIN and the sheet imported again: SMLib keeps the edge whole.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An edge raised to cover its pcurves' gap could get past SMLib's limit
(Congé19: 0.98 mm off, tolerance 1.47 mm) and its whole solid then failed
as "SMLib rejected the input". The tolerance an edge or vertex would get,
not only its gap, is now held to that 1 mm: farther off is refused with
how far. The record mapping refuses a tolerance past it with a message
rather than handing SMLib what it rejects.
The margin over a surface gap moves to solidcraft_geom::brep::pcurve
(SURFACE_GAP_MARGIN) for SMLib's pcurves to use too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Binds smlib_brep_edge_face_distance: how far an edge lies from a face's
surface over the surface's own domain, the gap SMLib sizes an edge's
tolerance by.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tangency-labs/smlib e51c3f2: a drop that comes back in pieces is joined
where they meet, never stretched onto its edge (solidcore#1383), and
smlib_brep_edge_face_distance.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Pins tangency-labs/smlib 56f6e81 (release prebuilt-56f6e811bc84…): smlib_blend_setback_eased
and smlib_blend_setback_open_eased, an ease length before each set-back corner over which a
round's section blends from its circle to the curvature-continuous section (solidcore#1376).
New calls only; existing ones are unchanged (ease 0 is today's body).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SMLib may end an edge at a parameter of its own: a knot its vertex lies at (-1.0 where the
vertex's angle gives -0.99999998, a 2e-8 step on the edge's quarter arc, far under 1e-6 mm).
We refused any change beyond 1e-9 of the parameter, a bound with no geometric meaning:
"SMLib moved an edge's interval" on 8 of Poppy Humanoid's faces. The ends SMLib chose are now
measured on the edge's curve: within the edge's tolerance, its pcurve is mapped onto our
interval by the affine change of parameter (exact for a B-spline: its knots move), and the
record's check measures it as any pcurve; farther is SMLib trimming the edge, refused with
how far.
Poppy: 227 → 232 bodies, 17 → 15 solids not imported, no interval refusals left.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LUXeKMoxpM7Vuv8Rb6E3K2
Pins tangency-labs/smlib 1072d1b (release prebuilt-1072d1b857de…): an N-sided corner
patch now meets each round on the round's own exact section edge instead of its polynomial
approximation, which the stitch kept on a near tie at some corners (solidcore#1377).
SMLIB_PREBUILT rewritten by scripts/fetch-smlib.sh --pin.
The kernel's tess, display_mesh, step, corner and fillet tests fail the same 63 as with the
previous pin, none new.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A revolved circle whose centre is as far from the axis as its radius (a horn torus, its
tube touching the axis) measured its major radius a few ulps above its minor from the
profile's control points, became SMLib's ring torus, and SMLib refused it
(SM_ERR_INVALID_INPUT: no ring torus of that NURBS). A ring torus now needs its tube
clear of the axis by more than rounding (1e-9 of the radius, the slack the same test
already takes for the circle's plane); a horn torus goes as its rational B-spline.
Test: a revolved unit circle 1.5 from the axis is a ring torus; at 1, 1 + 4 ulp and 0.5
it stays a revolution (develop calls the first two ring tori).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LUXeKMoxpM7Vuv8Rb6E3K2
A face on a placed revolution that carries its NURBS form (every STEP surface of
revolution, read since b6a3b31ff) was written as two NURBS blocks: the revolution's own
net, then the form, flagged FACE_NURBS_FORM on a NURBS face. SMLib reads one block per
face, so the flat arrays did not add up and it refused the body (SM_ERR_INVALID_INPUT),
in the main import and in the one-face sheets SMLib makes pcurves on. SMLib has no class
for a revolution: the form is the face, its range and trims already in its parameters,
so it now goes as that NURBS face with no form flag. A revolution the analytic pass
recognises (a plane, cylinder, cone, sphere, ring torus) is unchanged.
Test: surface_of_revolution_sense_follows_iso, which develop fails with the refusal,
passes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LUXeKMoxpM7Vuv8Rb6E3K2
SMLib's out_failed_corner reaches Rust as Error::CornerRefused { corner }, and the
kernel names the corner by its point: a G2 fillet at a corner of mixed convexity
says where it is and that SMLib sets back only corners whose rounds are all
convex or all concave. Engine test checks the message through solid.fillet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LUXeKMoxpM7Vuv8Rb6E3K2
smlib_blend_setback_open's binding: the sheet, and per corner a Hole, its
edges in order (each starting where the one before ends), each with the face
beside it and whether that face runs it forwards. The holes' buffer starts at
64 edges a corner and grows once to the length a first call names. Tested on
the r5 box corner set back 8: 9/30/22, a sheet SMLib's check passes, one hole
of twelve edges chained end to start; an unrounded edge at the corner is
Unsupported.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Session::execute is a command span; Model::evaluate and each feature computed
(by its type) are spans; io's import, export and design read/write too; the
STEP reader's topology, pcurves and solid record.
- diagnostics.profile (contract + output schema): report, start/stop, reset,
Chrome trace file.
- A STEP/IGES import's reply carries its own profile while recording.
- Every app compiles the profiler in by default (feature `profile`);
SOLIDCRAFT_PROFILE=1 starts it.
- solidcraft-cli run/eval/bench-open --profile print the table on stderr,
--profile-out writes the trace; run --profile works on designs and STEP files.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The C API logs each call with its steady_clock time; the log sink records
that as an smlib span (child of whatever runs on the calling thread).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tangency-labs/smlib's prebuilt workflow builds the C API once per commit for every Rust target
SolidCraft builds (Linux x86_64 and aarch64, macOS arm64 and x86_64, Windows x64, x86 and ARM64,
wasm32 with wasi-sdk's C++ runtime) and releases it as prebuilt-<commit>. SMLIB_PREBUILT pins each
archive's SHA-256. scripts/fetch-smlib.sh now downloads the host's archive (or the named
targets'), checks its hash and the commit it was built from, and falls back to the sources for a
target with no archive; --source fetches the sources, --pin writes SMLIB_PREBUILT from the
release. build.rs links a fetched archive whose hash matches the pin, else compiles as before,
now with -ffp-contract=off like the archives: every platform does the same arithmetic. No
network access in build.rs.
SMLIB_REV moves to 8b57e7e: the workflow, and fixes for MSVC (no directive inside a macro
argument, SM_PI for M_PI), the no-fused-multiply-add build and a test that needed a POSIX shell.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HoZgkCdAVrscuw2kjQTWDs
On the web target the smlib build compiles SMLib for wasm32-wasip1 with wasi-sdk's clang
(WASI_SDK_PATH), with wasm exceptions in the exnref encoding that wasi-sdk's libc++ and Rust
use, and links wasi-sdk's libc++, libc++abi, libunwind and libc. The WASI calls libc makes are
defined in ffi.rs: stdout and stderr go to the log, the clocks are the page's (the C API times
every call), and there is no file system or environment. solidcraft-web gets an smlib
feature, off until CI has wasi-sdk.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HoZgkCdAVrscuw2kjQTWDs
Ladder 06/009 had no way to ask for one: "solid.thread has no runout (vanishing thread)
length". With SMLib's smlib_screw_sweep_radial (replay e7acea1):
- smlib: the FFI binding and Brep::screw_sweep_radial, the profile moved off the axis by a
piecewise linear law of the turn; crate test: a tooth moved out 1 mm over three turns has
A 2π (c turns + ∫ offset dt).
- kernel: sweep_helix_radial, sharing sweep_helix's checks (helix_profile).
- doc: `ease_in`, `ease_out` (a length, or ISO 3508's standard 2.5 P or short 1.25 P) fade the
groove over that length, its section moving out of the material as it turns (outward for a
shaft, inward for a nut). ease_in is at the end the thread starts from. The runout lies past
the full-form length: beyond a square stop, before a shoulder up to its clearance; at a free
end inside the face. Runouts longer than the thread are refused. No end gets one by default,
so saved threads keep their geometry.
The cut is the integral over the turn of the clipped section's 2π∫ r dA: engine test (2.5 P
and 1.25 P between two collars) within the sweep's wall tolerance times the runouts' wall area
(0.029 against a 0.036 mm³ bound), ladder 06/009 (004's shaft, a 2 P runout before the
shoulder) graded in closed form (measured 1.7e-6 off).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The record's torus label is a ring torus (major > minor; the validator
refuses any other). SMLib keeps horn and spindle tori: a half disc revolved
about a line through its rim's end is a horn torus, its major radius a
rounding below its minor, and the export wrote it as a torus label the
record then refused (rig sweeps/4007, "ring torus radii"). Such a face is
now its NURBS form, unlabelled, which is its geometry in any case.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rig case shell/4711 (a 60 x 40 x 10 block, an r3 through hole at (22.5, 7), a 10 x 10 notch on
the front edge, shelled 2 open at the bottom) failed with "SMLib shell: operation: SMLib failed
(status 1027)". The hole is 4 = 2 x 2 from the front face: the hole wall's offset (r5) is tangent
to the front's at (22.5, 2), the walls meet along a line and the cavity would pinch to zero
thickness there, which is no solid. Refusing it is right; the refusal did not say why.
SMLib now refuses an offset whose walls would meet with its own status, SMLIB_ERR_WALLS_TOUCH
(-1110). The smlib crate reads it as Error::WallsTouch; the kernel's offset backend turns it into
a sentence with the wall, as blends turn NoRoom into one: "shell: the 2 mm walls would meet along
a line (between a hole and the side, for example), which leaves no solid there; use a thinner or
thicker wall, or move the feature". Thicker builds too (SMLib shells 4711 at 2.5, the walls
crossing and merging between the hole and the front), so the sentence offers both.
4711 expects that refusal and its message ("outcome": "refused", "refusal"), its "what" and
"method" saying why: the wall is 4 = 2 x 2, the walls meet along a line. Tests: the smlib crate
shells 4711 built from primitives (2 refused as WallsTouch, 1.5 and 2.5 valid), the kernel a
plate whose hole is 3 from its side at 1.5 (refused, with "the 1.5 mm walls would meet along a
line").
Results (run-sc.sh against SMLib a759622's code, which differs from the tree run only in
comments and docs; baseline 858f381fc-5448b9a): rig 410/447 (409
before; 4711 fail -> pass as the refusal, nothing else changed), ladder 109/116 (unchanged),
kernel lib 535 passed / 202 failed (one new test; the same failing set), smlib crate 53 / 2
(one new test; the same failing set).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0113gDVmStT5tCGKW9Fxgc5K
SMLib now builds a round or chamfer whose rail runs off its face across a cliff (an opening's
rim, the body's outline): the blend is made as if its faces continued and what it removes is
subtracted, so it never bridges an opening (owner decision for rig 5158/5181; fork commit
"SMLib, capi: a convex blend overflowing a cliff is subtracted from the body"). The tests that
expected a refusal for such blends now expect the body, each answer from the geometry:
- variable_radius_on_a_box_edge: 2 -> 50 on the 10x20x30 box's top edge builds at
3546.18767939 (circular sections in y = const, the r x r square less the quarter disc,
clipped to the box; rel 1e-4).
- variable_radius_from_a_spline: the "big" law builds at 6000 - 726.5334566720 (de Boor law,
split at the knot and where r crosses 10).
- a_chamfer_meets_sloped_end_planes: chamfer 25 removes 11500 - 4625 * slope
(integral of 40 - 2 * slope * y over z >= y - 5).
- g2_fillet_refuses_invalid_geometry: G2 at 25 builds at 6138.1606889 (the quintic section
with control points at thirds, clipped to 20x20, along 20).
- fillet_max_each_reduces_only_where_the_radius_does_not_fit: both edges take 4, 24438.7317761.
- hostile_inputs_are_errors: chamfer 30 on the cube builds at 1000 (y + z <= 10 along 20);
R50 still fails.
- kernel-cases fillets/1080: the 9 mm chamfer into the openings builds at 3350
(method in expected.json).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0113gDVmStT5tCGKW9Fxgc5K
A loft cut from a block's whole outline (flush with its sides) down to a pad cuts the slab
above it loose: the slab and the rest touch along the outline's four edges, round the pocket
the loft leaves. SMLib keeps the pocket as a void region of its own (its check finds the body
valid): its one runtime shell is the slab's underside and the loft's faces, so the slab's
material shell faces two empty runtime shells, the infinite region's and the pocket's, and so
does the rest's. The export made one record shell per pair of empty and material runtime
shells, so each solid's closed boundary came out as two open shells ("an open, wire or vertex
shell lies in one region").
A record shell is now one material runtime shell, whatever empty shells its faces face. Empty
regions one solid's boundary faces together are one record region: the infinite region where
it is among them, else the void whose outer shell bounds it alone. The pocket, which no record
shell bounds once the solids' shared edges are split, is part of the empty space round them.
Fixes rig sweeps/96-loft-cut-box-sections-pad-first and -top-first.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 796920968265c57c59f11dd908ec022d53f5c647)
A degree-1 patch of four control points on a parallelogram (a plane as an IGES
or STEP B-spline writes it) is that plane at every parameter, so its pcurves
take the plane's closed forms instead of going to SMLib (which drew the rim
circle of 3806's base as a 385-point spline).
SMLib may run a one-face sheet's loop against ours. A use's pcurve is the same
either way, so the loop's way round is read from an edge the face uses once and
every use is matched with it (3806 failed with 'a use SMLib did not keep').
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BnQawySUFx57iaJZq7z1Fm
A use with no closed-form pcurve (an approximated intersection curve on a cone,
a spline edge on a spline surface) no longer refuses its solid. Its face goes to
SMLib alone, an open sheet with the trims it has and without the others, and
SMLib makes those as it makes every trim it needs (GetOrCreateUVTrimCurve on
export); they come back on the record's parameters and the face is closed and
checked as before. The STEP reader takes the trim maker from the kernel
(read_solids_with, read_solid_with); read_solids stays exact-only.
Kernel lib tests: 490 pass, 239 fail (were 468 / 261; pushed head 475 / 254),
none newly failing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BnQawySUFx57iaJZq7z1Fm
SMLib holds every ellipse as an exact rational NURBS; the fork now sends ellipse edges with that
form and takes them back with it. The export reads an ellipse with its form as it reads a circle
with one (its frame turned so its angle grows along the form, its trims carried over as they are);
the import writes an ellipse on its form as its conic entry plus the NURBS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BnQawySUFx57iaJZq7z1Fm
No floor of ours on tolerances (1e-6 of the body's size, 30 times SMLib's 1e-5 default): the
record's tolerances go back into SMLib, which approximates to them, so the floor coarsened every
later operation. No recognition of NURBS edges as lines or circles: an edge is a circle where
SMLib holds an SmCircle (with its NURBS form), and a NURBS edge keeps SMLib's trims on its own
parameter. crashes/2992 and sweeps/1853 pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Edge::curve_interval (and brep::curve_interval for assemble's edges) gives the interval on the
edge's curve itself: a form circle's angles of its ends, its frame turned by the SMLib conversion
so the angle grows along the NURBS. lip and the ruled surfaces read arcs by it; the hull, the
blend tangents, the patch pcurves, point paths, IGES output and the prism runs evaluate on
Edge::parameters. assemble carries an edge's form through.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The SMLib conversion reads and writes EDGE_NURBS_FORM: a circle edge's record keeps the circle
as what it is and the NURBS SMLib holds it as as its parameter, so the trims on it carry over
exactly (TrimMap identity).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The edge mirror of a face's NURBS form: Edge::nurbs keeps the NURBS SMLib holds a conic as, and
the edge's interval and its pcurves' parameter are its. Edge::parameters is the curve every
evaluation at a parameter uses; curve says what the edge is. Nothing writes the form yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every SMLib analytic surface is a B-spline surface, and its trims are in that NURBS's
parameters. Face::nurbs keeps that NURBS: the face's domain and pcurves are its (u, v), and
`surface` says what the face is. Face::parameters is the surface every (u, v) evaluation uses.
The SMLib conversion reads and writes it (fork FACE_NURBS_FORM, SMLIB_REV c4483f6); the STEP
writer writes the analytic surface and the face's edges without pcurves.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017itGh5fpMEousnZ91cYcVt
SMLib (fork 68e3086) refuses a blend whose rails leave the faces they roll on with
SMLIB_ERR_NO_ROOM, which the kernel reports as KernelError::TooLarge. The kernel's own
pre-checks go: blend_fit's fit check and the 256-station band check of the variable fillet.
The shim no longer follows tangent chains; the Fillet/Chamfer dialog already expands a pick
to its chain (its Tangent Chain option) and stores every edge in the feature.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017itGh5fpMEousnZ91cYcVt
Pinned at the fork's draft-corners head: a drafted rectangle (or any
line-line corner) has its walls meet at a corner edge under the tangent
rule as well, 6 faces rather than 14. A curvature refusal for a curve
that is neither a line nor an arc names that curve's start.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017itGh5fpMEousnZ91cYcVt
extrude_tapered(_between) take a DraftCorner: PreserveCurvature (each wall
continues as itself, a line's plane or an arc's cone, until it meets its
neighbour; SMLib's SM_OC_CURVE_EXTENSION), Tangent (the offsets continued
along their end tangents) or Round (an arc about the corner). A corner
the rule cannot close is refused with its point and why
(solidcraft_smlib::Error::Corner). draft_corners reports, per sharp
corner of a profile, what each rule gives: how far each offset curve runs
on or is trimmed, whether the corner cuts inside the exact offset, or why
the rule refuses it. SMLib pinned at the fork's draft-corners head.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017itGh5fpMEousnZ91cYcVt
jyvikoandClaude Opus 5.5