Commit Graph

3635 Commits

Author SHA1 Message Date
jyviko 2c19013710 kernel: the record test takes the one wall a circle of arcs extrudes to
Since tangency-labs/smlib#67 an extruded profile's arcs on one circle sweep one
full-turn wall face, made from all of them (Profile 4, 5 and 6 here), where it
was a face per arc. The geometric check of the record finds a face over several
segments by its triangles' centres and vertices on them; the revolved arcs keep
a face each.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 17:09:44 -04:00
jyviko 26b42048c0 Preferences: the Body check note says each option in one short line
"After every step: checks each sweep, boolean and blend." / "Once per
feature: checks each feature's result once." / "Off (experimental): no
check.", in the order the options are shown, in en, ar, he, ja, zh, de
and ko.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 16:19:33 -04:00
jyviko a71450aebd Preferences: symmetric surface extrudes read only the total distance
The Design preference surface_extrude_symmetric_per_side, which gave new
symmetric surface extrudes their distance on each side, is removed with
its Surfaces section, its session field and its labels. A symmetric
surface.extrude given no convention splits the total around the start
plane, as solid.extrude does; timeline.edit and timeline.redefine give a
one-sided extrude made symmetric the same. default_extrude_convention,
which only existed to read the preference, goes too.

An explicit `convention: legacy_per_side` and the marker saved designs
carry are unchanged. A saved preferences file that carries the key loads
as before (the prefs test now covers both removed keys).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 16:19:33 -04:00
jyviko 2ae53d387f Preferences: metric tapped holes drill only the tap maker's drill
The Design preference metric_tap_drill_major_less_pitch, which gave new
metric tapped holes the major diameter less the pitch (M8: 6.75 mm), is
removed with its Holes section, its session field and its labels. A new
tapped hole given no diameter drills the tap maker's drill (M8: 6.8 mm);
a custom metric size the table lacks still takes the major less the pitch.
A saved preferences file that carries the key loads as before: serde
ignores keys Prefs doesn't have, and the key is not written back.

The preference's UI test becomes an engine test of the default drill
(M8, 1/4-20 UNC, a given diameter) and a prefs test that a saved file
with the removed key still loads.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 16:19:33 -04:00
jyviko 222211de43 Model cache: a thinned model keeps the check mode only as the model records it
SavedModel::thinned wrote `"validation": null` into the records of a model
that records no check mode, so a thinned model was never the model it came
from, even with room for every state, and its manifest grew by that key
(design::tests::a_thinned_model_keeps_the_final_state_then_the_slowest_that_fit,
a_model_cache_too_big_for_the_file_keeps_fewer_states). It copies the mode
when there is one and adds nothing otherwise; the tests' timeline model records
one, as every saved model does now, and a thinned model is asserted to keep it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 16:19:28 -04:00
jyviko 6700e6ef1f kernel: a body SMLib keeps in the record's order is mapped, whatever order its export lists
An imported solid's faces were mapped to the file's only when SMLib's export numbered them as the
record did (native.rs, numbering). The export is in canonical order, which can list edges
otherwise: the two periodic-knot tubes of #1374 came back with their seam and rim edges listed
[2, 0, 1, 5, 3, 4], so the sheet, a valid B-rep, was refused as "SMLib renumbered the solid's
faces". The export's order says where SMLib's own face and edge i went; put back in SMLib's
order it numbers them as the record does, and SMLib's i is the record's i (an import lists them in
the record's order). numbering now takes that too, checked the same way; an edge split into
pieces is no renumbering and stays unmapped.

The tube test asserts what it should: one surface body, not a mesh, its faces the file's two
faces in order, every face meshed, in under a minute, and the area exact: each face is the file's
quadratic circle (corner weights sqrt(2)/2 to 12 digits) moved straight along its axis, a
cylinder's side, so 2 * 2 pi r h, which SMLib's measure meets to 1e-6.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 15:19:38 -04:00
jyviko 393c83c2a3 STEP import: a solid the kernel refuses, its faces too, is refused with the reason, never a mesh
A solid SMLib refused came in as a surface body of its faces; where SMLib could not stitch those
either, the importer meshed them with SolidCraft's planner and kept the triangles as a mesh body
(step_in/parallel.rs, mesh_part). A build without SMLib showed it: every STEP part of the import
rig came in as a mesh of its faces. That fallback is gone: the solid is not imported, and its
warning names it and gives the kernel's reason ("solid 'Cube': not imported: ..."); a file whose
every solid is refused fails with the same words.

The import report tells a part the kernel refuses (Refused) from one the reader cannot read
(NotImported), and its summary says "N parts couldn't be made into solids and were not
imported" in place of the mesh sentence (en, ar, de, he, ja, ko, zh). STL, 3MF, OBJ and glTF
still come in as mesh bodies: that is what those files are.

The two-tube sheet of #1374 had come in only through that fallback: SMLib's export lists its
edges in another order, which the next commit maps. Until then its test asserts the refusal and
meshes the faces as read at the body's coarse display tolerance, the regression it guards.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 15:19:38 -04:00
jyviko 709765fcae Model cache: a saved model records its body check mode and is adopted under it
Since the body check mode became part of the evaluation context (9acbcf924),
evaluate digests the context with the mode, but Model::adopt still took the
context without it and the default mode: the first evaluation after opening a
design from its saved model saw another context and recomputed every feature
(undoing_an_edit_after_opening_reuses_the_saved_results,
rolling_the_marker_back_keeps_results_after_cache_eviction). The saved model
now records the mode it was evaluated under (thinned ones too), adopt takes
it and digests the context as evaluate does, and a session opening a design
under another mode evaluates it again rather than showing that mode's results.
Model cache format 6.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 15:19:33 -04:00
jyviko 45823002c0 SMLib: pin 68fb916 (tangency-labs/smlib#67)
The owner's bar running tangent into a cylinder rounds its concave arc and
its top edge both together and one after the other in either order, at
r 1 to 7. Two more peg cases come off the fillets known-failing list.

The ladder's shelled dome ring now has 9 edges, not 7: each of its two
cylinder walls is one full-turn face with its seam edge (one wall face per
extruded circle), where it was two halves. Faces, vertices, area and volume
are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvoxKQ2rEZvcXNQnhE3Sgs
2026-10-30 15:19:29 -04:00
jyviko d3766865a0 Tests: old designs open and evaluate; what they rebuild to is today's
Tests that asserted an older design rebuilds as the build that saved it made it
now assert what still holds: it opens, is upgraded, evaluates, round trips and
names alike every time, and a feature that lost a reference asks for it again.

- naming corpus: two builds still name every face and edge alike and find the
  same faces with their stored names; a stored name that finds nothing must
  leave its feature failed (it asks to reselect), never a feature that builds.
  A sketch's face is found by its name as the sketch finds it.
- design corpus: the volumes, areas and bounds the saving builds recorded are
  no longer compared; a corpus design may fail only by a request to reselect,
  and undo leaves the features that failed on opening failed.
- fixed robustness seeds: no panic, valid bodies and volumes moving the right
  way; a step the kernel refuses is not a bug.
- a format 28 design's pieces and a format 13 design's extra bodies: marked as
  they open and named alike, without promising the numbers or names saved.
- action matrix baseline: the two corpus designs whose fillets, chamfer and
  offset face held names saved before format 14 re-recorded.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko ef37bd4459 doc: names saved before format 14 find nothing; their features ask to reselect
Face and edge names stored before format 14 were worked out from geometry and
open marked `?`. They were found among the names geometry gives today, as the
builds that saved them found them, pieces by the one nearest the pick. They
find nothing now: the feature holding one fails, asking for its reference to be
picked again, which stores its exact name. The legacy face and edge names a
body worked out for them are gone.

The tests that found such names as saved now assert the request to reselect:
a saved strip projection, a version 9 emboss on an annulus, a format 10 face
sketch and the corpus design named with numbered pieces.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko cfa6f38d6e doc, engine: a stored name finds its very face or edge, or its feature asks to reselect it
A face or edge name a feature stored finds only the face or edge it names: the
very name (or a synonym of that face), or the named piece told apart by the
faces around it. A face split into several pieces, merged into another face,
or left only as a face of the same stem is not the face that was picked, and a
name found on several bodies is told apart only by the body the reference's
point lies on. The fallbacks are gone: no piece nearest the pick, no merged
face, no edge at the picked point, no lost link that keeps its last geometry.
A feature whose stored reference finds nothing fails with DocError::Reselect:
blends, face points, sketch planes, sketch projection links, construction
references, hole reference edges, sheet bend edges and cylinder emboss.

The tests that asserted a fallback now assert the request to reselect: split
and removed fillet edges, a merged or rejoined face, a projected edge that was
split or is gone, a projection whose body went, saved strip projections after
wall coalescence, a fillet saved on a piece of a tapered side that is whole
now, a cut that starts from a piece that is no longer that piece, and a fillet
named on the lower of two stacked boxes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko 4a652ba4a1 doc: a face its feature made from several roles has each as a name
A side drawn in collinear sketch pieces is one face the extrude made from each
piece (#1788): its first role is its name, and the others were kept as aliases,
like the names of faces merged into it by a later join. They are names of that
very face, not of faces merged into it: the face keeps them as synonyms, which
a stored name matches as exactly as the face's name (a piece of it, once it is
split), through copies and later features, and the face whose name a merge
keeps keeps its synonyms too. An extrude-side certificate made on one of the
pieces finds the joined face the same way, and the saved model records the
synonyms (model cache format 5).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko 1b08d4b8b5 doc: a feature's face points are named on its own component's bodies first
Each component's bodies lie in its own coordinates in the state a feature's
points are named in, so a part inserted twice has a face at the same point in
each copy: a thread on the second copy was named after the first copy's face.
The points are named on the feature's own component's bodies first, then on
every body for a point that lies on none of them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko d62d248b76 doc: Untrim's face points pick faces of the body it untrims
FeatureKind::face_body did not name Untrim's body, so its face was looked up by
name on every body and could be taken from another one (a copy has the same
face names).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko b24d902692 doc, ui: a feature that lost a reference asks for it to be picked again
DocError::Reselect names the feature and the stored reference (a face or edge
name) that no longer finds what was picked: "<feature>: the reference `<name>`
no longer exists as it was picked; reselect it". Evaluation fills in the
feature's name; reselect_parts reads both back from a feature's error text, and
the UI shows the message translated (ar, de, en, he, ja, ko, zh in
assets/locales/pending/reference-reselect.json).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 14:31:23 -04:00
jyviko e43fe1ab04 Kernel rig: diagnostics.validation is a setting, exempt from cases
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvoxKQ2rEZvcXNQnhE3Sgs
2026-10-30 13:52:54 -04:00
jyviko 6a133042cb Preferences: the body check is the kernel's, not named after SMLib
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:52:54 -04:00
jyviko 50501fe14a Preferences: Body check, once per feature by default
The Design page's Body check section sets the validation preference
(each_feature; each_step keeps the old checks after every step; off is
experimental), applied to the session like the hole and surface extrude
preferences, to the sessions a design is opened in off the window thread,
and kept in step with diagnostics.validation. ui.prefs refuses an unknown
mode; a saved unknown one reads as the default.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:52:54 -04:00
jyviko 1a93a39770 CLI: run and kernel-cases take the validation mode
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

solidcraft-cli run --validation MODE, kernel-cases --validation=MODE and
cargo xtask kernel-cases --validation MODE (with --ladder too), so the rig
runs under each mode.
2026-10-30 13:52:54 -04:00
jyviko 5d80fc5711 Engine: diagnostics.validation reads and sets the mode
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

With input and output schemas. The mode is the session's user setting:
kept when another design is opened, started, recovered or imported (each
evaluated under it), and by timeline.compute_all. Linked and extracted
designs are evaluated under it too.
2026-10-30 13:52:54 -04:00
jyviko 9acbcf924b Evaluation: under each_feature a feature's kept bodies are checked once
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The model carries the mode (Model::set_validation) and runs each feature
under it. When a step left its check, every body the feature made or
changed is checked by SMLib before the state is kept: a body the check
refuses fails the feature with the check's reason and the body's name.
The mode is part of the cache context, except each_step, whose results
are develop's.
2026-10-30 13:52:54 -04:00
jyviko 4030b795c4 Kernel: a validation mode decides when sweeps, booleans and blends are checked
Validation::EachStep checks every solid sweep, boolean and blend result
in SMLib as before; EachFeature leaves those checks to the end of the
feature and says a check was left; Off skips them. The evaluation installs
the mode around a feature (validating), as watch installs a watch; outside
it every step is checked as always, and the kernel's worker threads run
under the caller's mode.

Under EachFeature a body decoded from a step keeps that step's SMLib
result (for its own record only), and check_kept checks it as the step's
own check would have, then lets it go; any other kept body is checked as
SMLib imports its record. The record can pass where the result fails: a
fillet's surface of revolution whose polar curve SMLib's check refuses
(fillets/1080-fillet-sloped-basin-1-mm-rim-r0-5-4-edges) is rebuilt on
import, and its round meets a wall at 72 degrees; checking the record
alone kept that round.

The largest-size search of a blend checks every candidate as it is built,
whatever the mode: a candidate fits only as a body the check accepts.
Surface operations and stitching keep their checks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:52:54 -04:00
jyviko 051a7b714c Kernel tests: rustfmt
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvoxKQ2rEZvcXNQnhE3Sgs
2026-10-30 13:52:26 -04:00
jyviko 292ec65c8e Fillet rig: the chamfer running into the openings is named for what it does
fillets/1080-chamfer-runs-into-openings-refused already expects the
9 mm chamfer built and cut by the openings (V = 3350); its id said it is
refused. It becomes 1080-chamfer-runs-into-openings-cut-by-them, and
blend_fit's chamfer_through_the_openings_is_cut_by_them names it so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:52:26 -04:00
jyviko 1878274cb7 Kernel tests, fillet rig: a chamfer past its rim builds, cut by what lies past it
The owner's ruling of 2026-10-30 (d7): a chamfer that reaches or runs
past a rim builds, everywhere, as SMLib's cliff overflow builds a convex
blend: on its faces' continuations, then cut by what the cliff cuts
away. The earlier rule refused a chamfer whose leg runs off its face.
SolidCraft has no such refusal of its own; SMLib refuses these, so the
cases fail on SMLib 985faaee and are listed with its reasons (traced in
gdb at SmFilletErrorInfo::NoteError):

- the sloped basin's single front edge past its rim (1 mm rim 2 and 3,
  0.5 mm rim 4): CloseRemovalRegion, "a cliff overflow's fillet boundary
  lies on the surfaces of two faces": the sheet's boundary along the end
  wall's top edge line from the edge's vertex to the top's contact
  (x = 20, y from -1 to 1, z = 30) lies on the top's plane and the end
  wall's both.
- the equal-slope basin's rim loop 2 and the 5 mm pocket's rim 5.5:
  CloseRemovalRegion, "a cliff overflow's fillet boundary closes on one
  face" (every edge of the loop blended).
- the sloped basin's front and right edges 2: status 1001,
  SmFilletNx2Corner, CalcFilletIntSideFace.
- the cylinder's rim 2 across the top and 25 down its 20 mm wall: status
  1001, SmFilletNx1ClosedCorner cannot compute its geometry.

Expectations, each from a closed form or an exact quadrature:

- chamfer_wider_than_sloped_basin_rim_is_refused becomes
  chamfer_wider_than_sloped_basin_rim_builds, ignored until SMLib builds
  it: the triangle clipped to y >= 0, times 30 + z (shoelace):
  73.450475, 142.112912, 184.526613; the rig's 1080-chamfer-sloped-
  basin-*-past-the-rim cases: V = 144459.882858, 144391.220421,
  144082.140054.
- blend_corner's a_rim_loop_chamfer_running_off_its_rim_is_refused
  becomes ..._builds, ignored likewise: sliced at depth t the mitred loop
  takes the pocket's rectangle grown by w(t) = d (1 - t / delta) on each
  side, clipped to y >= 0, less the rectangle, Simpson exact on each
  quadratic piece: 375.673069, V = 139957.660264 (the rig's
  1080-chamfer-equal-slope-basin-1-mm-rim-loop-2 too).
- 5835-chamfer-sloped-basin-1-mm-rim-2-two-edges: the same slicing with
  the front and right sides grown, 161.279149, V = 144372.054184.
- every-chamfer-pocket-rim-5-5-past-the-floor: 50 d^2 + (4/3) d^3 at
  5.5, the groove 0.5 deep round the floor included, V = 19265.666667,
  15 faces.
- 2893-chamfer-two-distances-past-the-bottom: the frustum r 8 to 9.6
  over 20, pi 20 (64 + 76.8 + 92.16) / 3 = 4879.102831, 3 faces.

Each drops "-refused" from its id (the 5.5 pocket's says past the floor).
The same slicing reproduces the existing 5835-...-4-mm-rim-2-2-edges
(176.006388), equal-slope loop 0.5 (24.455545) and half-width
(5.426545) values.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:52:26 -04:00
jyviko 3a2fac31a1 Kernel tests, fillet rig: a chamfer as wide as its rim builds
The owner's ruling of 2026-10-30 (d7): a chamfer that reaches or runs
past a rim builds, everywhere. The earlier rule refused a full-width
chamfer, naming the largest size that fits. SolidCraft has no such
refusal of its own (a blend's TooLarge is SMLib's SMLIB_ERR_NO_ROOM,
and the doc layer only names the largest fit), and SMLib already builds
these, so only the expectations change, each from a closed form or an
exact quadrature:

- chamfer_wider_than_sloped_basin_rim_is_refused's full widths become
  chamfer_as_wide_as_sloped_basin_rim_builds: the whole triangle,
  d drop / 2 (60 - drop / 3), drop = 20 d / sqrt((20 - margin)^2 + 400)
  (shoelace over the section, its length 30 + z between the sloped end
  walls): 21.662379 (1 on 1 mm), 5.359321 (0.5 on 0.5 mm). The basin and
  the removal move into sloped_basin and sloped_basin_rim_chamfer_removed.
- fillets/1080-chamfer-sloped-basin-{1,0-5}-mm-rim-as-wide-as-the-rim:
  V = 144511.670954, 144261.307346.
- fillets/every-chamfer-pocket-rim-5-full-depth: 50 d^2 + (4/3) d^3 at
  d = 5, V = 19583.333333, 11 faces (the walls used up).
- fillets/every-hole-top-rim-chamfer-10-full-depth: the triangle 10^2/2
  revolved at rho = 5 + 10/3 (Pappus), V = 16000 - 3250 pi / 3 =
  12596.607959, 7 faces.
- fillets/1113-chamfer-arc-top-edge-full-wall-height: the 9.5 case's
  Int rho asin(21/rho) h(rho) drho at s = 10, by Gauss-Legendre in
  u = asin(21/rho), 1303.400331, V = 8287.993768.

Each drops "-refused" from its id and its KNOWN_FAILING line goes: all
five pass on SMLib 985faaee.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:52:26 -04:00
jyviko f1199f89bc Joint drive: contact is decided on the exact bodies, not their display meshes
A joint drive with contact on tested each sample and each of 14 bisection
steps with a brute-force mesh-against-mesh overlap check, its cost the product
of the two display meshes' triangle counts under a fixed budget. Since the
display mesh puts nodes inside planar faces, a cam and its tappet or a block and
a sphere exceed that budget ("motion exceeds contact sweep collision budget"),
and whether a motion may run depended on display tessellation.

Now, at each sample, bodies whose exact boxes meet are intersected exactly
(SMLib boolean, exact volume); a shared volume is a contact, a touch (a cam and
its follower) is none. Between the last clear sample and the first overlapping
one the drive closes in by conservative advancement: from a clear placement it
moves no point of the pair further than the pair's exact gap (body_distance),
until the gap is within 1e-9 of the bodies' size. Only clear placements are
measured, so no intersection is asked to tell touching from overlapping within
its tolerance (SMLib's boolean fails there, status 1001, on two cubes 1e-4
into each other). The budget is 2048 intersections per drive.

Fixes cmd::joints::tests::cam::a_cam_drives_a_closed_loop_and_stops_at_a_contact
and contact_sweep ordinary_curved_bodies_stop_at_their_contact_within_the_sampling_budget,
and the other contact, cam, motion, interference and clearance tests pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 13:11:11 -04:00
jyviko b4af45dd07 Kernel rig: the horn torus and the circle revolved touching its axis build
SMLib's revolve now splits a curve where it touches the axis inside itself
(tangency-labs/smlib#66), so both cases come off their known-failing lists.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvoxKQ2rEZvcXNQnhE3Sgs
2026-10-30 12:14:18 -04:00
jyviko 7fe880a7bf SMLib: pin f8fd83e (tangency-labs/smlib#66)
The batch brings history Kept for a face only cut by a vertex, revolve of a
curve touching its axis, loops touching at a vertex, a torus rail on its axis,
and the fillet causes behind the owner's bar running into a cylinder: a
tangent edge past a tangent side edge is the corner's edge, the rails of a
round collapsing at its end end at one point, and a trace from a tangent point
starts along the curve.

The two peg cases with the sketch's solver residues come off the fillets
known-failing list: both build.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvoxKQ2rEZvcXNQnhE3Sgs
2026-10-30 12:14:18 -04:00
jyviko 12496c2c1d Tests: a round flange stays an exact circle through unfold, refold and DXF, with a cut near its rim
The test it replaces probed for a polyline by placing a 0.2 um square in the
gap between the rim and a 1 um polyline: a micro feature in a millimetre part.
This one asserts the property itself, in millimetres: every rim segment of the
flat pattern is an arc of radius 10, the DXF draws one circle of radius 10, and
a 1 mm cut 0.5 mm inside the rim stays one hole.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 12:05:28 -04:00
jyviko 7c9e5ec696 kernel: a seam held as two edges is one join, drawn whole in the shaded view
A G2 corner patch's side is G2 to its round except near the face it ends
on, and SMLib holds each side as two edges. The smooth-join test judged
each edge alone, so the G2 half was hidden and the line stopped at the
vertex in the middle of the seam. Edges between the same faces that
continue each other at a shared vertex now share one verdict: smooth only
where every one of them is.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 10:37:53 -04:00
jyviko e46359ff04 Kernel rig: the patch cases the fill now builds come off the known-failing lists
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 25e275722d Tests: a patch's continuity g3 is valid, g5 is the hostile word
patch_continuity_and_points_cap_a_tube listed "g3" among the values surface.patch must refuse,
from #1521 when a patch built G0 to G2. Since cb8712aa0 Construction::Patch builds G0 to G4
(continuity_order.rs: `Construction::Patch => (G0, G4)`), so g3 is accepted, as it must be;
the order above what a patch builds is g5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko c088cf43ed geom: the patches about a centre are solved the same to the last bit on every run
The block solve kept its sparse entries in hashed maps and summed the coupling of each patch's
interior onto the shared unknowns in the map's order, which a hashed map draws afresh each
time: the same loop filled to surfaces differing in their last bits, so a design read back
rebuilt another cap (engine patch_continuity_and_points_cap_a_tube, "the same surface read
back"). The entries are now in ordered maps; a fill twice of the tube's ring and of a hexagon
about a centre are bit for bit the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko f7409dd59f geom, kernel: a loop with fewer than three corners is filled by a ring of patches
A tube's end has no corner at all; the kernel gives its circle in four quarters, and one patch
on them has a corner on each quarter joint where the loop runs straight on: flat, its two
derivatives parallel, which SMLib's check refuses (Bad Surf FlatCorner within 0.5°). Any
layout with a patch corner on such a loop has one.

Such a loop is now the ring of structured meshing (an O-grid): four patches each on one side of
the loop, two meeting at every point of it, about one inner patch (Quilt::ring). The spokes are
now any curve two patches share (Seam), each glued G1 with linear gluing functions: at an inner
vertex of valence m the characteristic value ±2cos(2π/m) (the centre's spokes as before, the
ring's inner corners with m = 3), at the loop what its two sides' derivatives there ask
(foot_gluing; 0 and their speeds' ratio where the loop runs straight on). IsoFill says where each
spoke starts and ends (SpokeEnd) and holds the inner vertices; the kernel builds them so.

The tube end caps G1 (normal within 0.0157° of the wall, sealed 10458.232 against the tube and
dome's 10458.232) and G2 (curvature across 4.6e-5 /mm against G1's 0.30), five faces with no flat
corner. A crown on the ring lifts the inner patch whole (the ring rises as v(2 − v)).

Saved designs: a general patch on a smooth closed loop (a tube's end) rebuilds as five faces
where it was one (which SMLib refused).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko d5941c0d06 geom: a general fill's crown fills out to the side its neighbours' normals face
The crown moved the free points along the patch's own normal, whose sign is only the way the
patch happens to be parameterised: the pentagonal window's crown 0.1 sank 1.56 mm into the
cylinder (the middle 9.959 from the axis plain, 8.395 crowned) where the kernel documents it
filling out to the side the G1/G2 neighbours' normals face. The crown now takes that side: the
sum of the patch's normals against the neighbours' over the stations sets one sign for the fill.
The pentagon's middle goes out to 11.526.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 30b12cea8c geom: a crowned height field rises by the whole crown at its box's middle
The crown's bump went onto the first net with any control point clear of the loop; a coarse
net could leave points supporting the box's middle without it, so the middle rose by only a
share of crown · size (the pentagonal cup: 7.6558 of 13.3877). The net is now refined (knot
insertion, the surface unchanged) until every point whose basis is not zero at the middle takes
the bump, where the middle is inside the loop: the bubble is then exactly 1 there, as fill_loop
documents.

The kernel test measured against the face's domain, which SMLib holds as the loop's extent; the
documented box is the height field's whole domain, the loop's box and 1% more each way (as the
engine's crown test says, 28 × 28 + 1%). Its diagonal is 1.02 times the face's, so the
documented rise is 0.25 × 53.5506 = 13.387661 = 1.02 × 13.125158, which the patch now meets to
1e-6 for crowns ±0.25.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 62d41a0cfa Tests: the fill tests evaluate a face's (u, v) on its NURBS form
A face's domain and pcurves are on Face::parameters() (its NURBS form when it has one, the
record's documented contract); the general fill tests' quadrature and the pick-order and crown
comparisons evaluated Face::surface instead. A fill SMLib recognises as an analytic surface (the
240° window's G0 patch is the cylinder itself) then read its arc-length domain as angles: the
quadrature came out 4188.79 for the window's 418.879 (10 × 41.888 of angle against 4.189).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 55cb6b32b0 geom, kernel: the patch fill's sides run from corner to corner, not edge to edge
A vertex where the loop runs straight on (SMLib's seams: a cylinder's at 35.12° splits a half
circle into two arcs) was a corner of the fill's region, so a patch had a 180° corner there:
flat (its two derivatives parallel), degenerate, and refused by SMLib's check (Bad Surf
FlatCorner, within 0.5°). Half a post's side, six edges on four corners, was six patches about
a centre and folded.

The region's corners are now the vertices where the loop turns by more than the kernel's corner
test (1°, IsoSpec::corner_turn); a side is the chain of edges between two corners, held as one
exact B-spline (each edge carried exactly to the side's degree on its stretch, joined at a knot
of full multiplicity, which the knot-line rows keep tangent across). Each edge's pcurve is still
a straight line, now on its stretch of a patch's side; a spoke says where on the loop it starts
(IsoFill::feet). A loop with fewer than three corners keeps its edges as sides.

The half post is one face again (a_loop_that_does_not_bound_a_height_field_fills_with_one_face),
the 240° window is one patch, the exact cylinder (area 418.879), and the torus window fills G0
and G1.

Saved designs: a general patch on a loop with seam vertices rebuilds with fewer faces (the half
post's 6 become 1), its corners where the loop's are.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 49377d318c geom: patches about a fill's centre join G1 there, with the linear gluing function
Across each spoke the two patches' derivatives away from it were held opposed (parametric C1).
At the centre that asks the spokes' tangents d_{k-1} + d_{k+1} = 0, which for N other than a
multiple of four only d = 0 meets: every patch got a flat, singular corner at the centre (a
pentagon on a wavy rim: derivatives of 3.3e-5 there; the hexagonal rim's control net doubled
back and SMLib's check refused it as NonMonotonic).

The join is now G1 with the linear gluing function of Loop, Peters and Hahn:
d/du S_k + d/dv S_{k+1} = alpha(t) d/dt S along the spoke, alpha(t) = 2 cos(2 pi / N) t. At the
midpoint alpha is 0 (the edge's two halves leave it at the same speed, opposed); at the centre
it is the value any affine image of the regular N-star meets, d_{k-1} + d_{k+1} = 2 cos(2 pi/N)
d_k. N = 4 is the old row. The pentagon's centre corners now open 72° with derivatives of 16.2
(N = 5 to 8: 360°/N each).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 013978724e geom: the patch fill's cross-boundary targets agree with its corners
A tensor patch's cross derivative along a side is, at a corner, the tangent of the side it
meets there (the two share the corner's next control point): the compatibility condition of
Coons and Gregory interpolation. The weak rows asked t·c′ = 0 and w·c′ = s right up to every
corner, which no patch can meet where the next side is not square to the edge; at a smooth
vertex (a tube's end in four quarter arcs) the next side runs along the edge itself. The least
squares spread the contradiction into the first spans and folded them: the tube end's worst
normal went 13.8°, 17.9°, 89.8° (folded), 85.6°, ... 25.1° (folded) with refinement, and the
symmetric loop came back asymmetric.

The target is now the Coons start's own cross derivative, compatible at every corner by
construction, turned about the edge into the neighbour's tangent plane (its part along the
edge kept, the rest laid along the leave direction at its length). The tube end converges
21°, 3.8°, 0.76°, 0.18°, 0.045°, symmetric, and does not fold.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:17:35 -04:00
jyviko 9243b6550d SMLib history: a split line between two pieces of one face comes from nothing
An edge SMLib reports as new was given the origin "where its two faces meet", each side what
that face came from. A split line lies between two pieces of one face, so both sides are that
face and the edge read EdgeOrigin::Meet { top, top }: a face meeting itself, which no two faces
did. Such an edge now has no origin, as the history's EdgeProv documents for a new edge between
faces new to the operation (the doc now names the split line too).

New test: a_split_line_comes_from_nothing (one face split in two, its new edge has no origin).
modify_history_tests::split_a_face checks this at its last line; it still fails earlier, on its
counts ([3, 2, 2, 0, 0] for [5, 0, 2, 0, 0]) on develop's SMLib pin, until SMLib batch 3's
history fix (03bbc88) is pinned.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:14:44 -04:00
jyviko 738f336e12 Raytrace: a closed box dielectric is certified from its mesh's geometry, in any tiling
The closed-box certificate took exactly twelve triangles, two a face. The one mesher puts
interior points on planar faces (a 20 x 20 x 2 box comes in more than twelve), so
render.preflight refused a box as "unsupported dielectric boundary tessellation"; a box is a
box however its faces are triangulated.

The certificate now reads the mesh's geometry exactly: every triangle in the plane of one of
the faces of the box its points span (corners on it, normal exactly that axis) facing out,
and the triangles a closed, consistently oriented surface (each edge, by its ends' exact
coordinates, run once each way). Such a surface is a 2-cycle on the box's boundary, a sphere,
so it covers every point of it the same k >= 1 times, and its area is k times the boundary's:
k = 1 is decided by the area being under 1.5 times the boundary's. Up to 65536 triangles. A
thin sheet is still one or two triangles; a general closed mesh is still refused.

New test: a box with its top fanned from a point in it is certified, with the same bounds;
the point 1e-9 off the plane, or the top covered twice, is refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:14:44 -04:00
jyviko 5732b62ec3 Tapered extrude: the end check of a profile with holes takes the section a swallowed line leaves
A tapered extrusion of a region with holes checks, at its two ends, that each hole's section
stays inside the outer loop's and clear of the others. Those sections were made with the
start section's rule, which refuses a line the offset swallows ("draft extrusion that starts
before its profile where the taper closes a side"). At the far end such a line is ordinary: a
short line between two concave corners whose wall closes on the way up. The letter g of
"tres long" (8 mm, joined 2 mm with a 3 degree taper) has one, and the whole text was refused
with a message about the start that does not apply.

The end check now takes the section as it is there (offset_loop's swallowed lines left out, their
neighbours meeting where they were); whether the closing wall is built stays the draft's to
say. The g builds at 3 and 15 degrees.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:14:44 -04:00
jyviko cf40a3e6c6 Boolean regression test: the raked wedge's R4 rounds the four edges the issue picked
raked_wedge (#1617, test from 7f2ae11a0 on 2026-10-17) rounds four end edges R4. Since
84bd2daad (2026-10-22) solid.fillet carries each picked edge round its tangent chain by
default, so the R4 now ran on round the end outline onto the R1.2 round's end arc, where the
round's rail on the end face would be an arc of radius 1.2 - 4 < 0, and it is refused as too
large. The issue's R4 rounds those four edges alone: the step says tangent_chain: false.

The test still fails, one step later, on SMLib: the issue's R0.854 round of both ends' outline
is refused by SMLib's own check (SmBSplineSurface Test #5, "close to singular at boundary"),
reported for the SMLib batch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:14:44 -04:00
jyviko f2982b47a0 Sheet tests: the tiny cut inside the exact circle is above SMLib's modelling tolerance
tiny_cut_inside_exact_circle_survives_unfold_refold_and_dxf cut a 50 nm square 0.2 um inside
the disc's rim. SMLib models at a zone tolerance of 1e-4 mm: its check refuses the cut's 50 nm
walls as planes "degenerated to a point (tolerance=0.0001)", so the extrude was refused. A
feature below the kernel's resolution is not one it can keep, on any path.

The test's point is that the exact circle, not its display polyline, bounds the flat pattern:
a cut between the two must survive unfold, refold and the DXF. The polyline at 1e-3 has 224
chords (sagitta 10 (1 - cos(pi/224)) = 0.98 um), so the square is now 0.2 um across, centred
0.4 um inside the circle on the first chord's bisector: outside the polyline, inside the
circle, its walls and its 0.3 um gap to the rim above 0.1 um. Its hole's area is
(2e-4)^2 = 4e-8 (was 2.5e-9 for the 50 nm square).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:14:44 -04:00
jyviko 17a466e6b8 Ruled surface: a free strip on a straight edge gets a far curve that can bend
A strip's far curve, where its rulings turn along the edge, is a B-spline in the edge's own
spline space. A straight edge's space is one linear span, which holds only the chord between the
strip's corners: the rulings' ends (the closeness term) had no say, and the strip had no handles.
Off the patch over the cup's rim in a_strip_off_a_curved_face_is_ruled_to_its_far_curve the
normal along the straight rim at x = 14 turns by 5 degrees (x component -0.350 at the ends,
-0.262 at the middle; the patch's middle is at z 10.296, not the cylinder's 10), so the strip is
free and its rulings' ends lie up to 0.26 mm off that chord.

Such an edge is now taken as the cubic Bezier it also is (exact degree elevation: control points
at thirds, the same points at the same parameters) before the far curve is solved, so the far
curve has two interior control points: its handles. Exact strips on straight edges keep the line.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:14:44 -04:00
jyviko fb5ae6cdd2 SMLib import: an extruded circle's circle comes from its widest span, not the face's range
Since 6cc759750 an extruded circle is a cylinder over the face's trimmed range, and the circle was
fitted through three points of that range. On the shallow strip of the extruded-ellipse test
(radius 3000, 6 mm wide: 0.002 rad round) the three points are 2 mm apart and the fit is
ill-conditioned: the centre came 2.5e-10 mm off the circle's plane (the frame's x axis tilted
8.3e-14 out of it) and the radius 8.1e-9 mm short. SMLib took that cylinder, but on the way back
(the import's SMLib round trip, then Body::smlib) SmCylinder::IsNurbSurfaceCylinder did not find
a cylinder in SMLib's own NURBS of it, and the strip was refused as needing repair
(SM_ERR_INVALID_INPUT, AnalyticOfNurbs). Before 6cc759750 the fit ran over the record's domain,
1.4e-6 rad wider on each side, and happened to come out level.

The patch's trims were right all along: they straddle the profile's seam (u = 4, the knot
between the spline's two quarter spans) without wrapping, [3.9992930395761980, 4.0007069604238020],
which is the exact 0.001 rad either side of it.

The circle is now fixed by three points on the arc's widest knot span (a quarter turn here),
where it is determined to rounding, and checked as before at 65 points over the face's range.
A revolution's profile circle is fitted as before.

Regression test (smlib import tests): a 0.002 rad patch of an extruded circle of radius 3000
across that knot is the cylinder of radius 3000 to 1e-10 (it was 2.8e-10 short), its axis
along z to 1e-15, over exactly the patch's range.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:06:14 -04:00
jyviko 8d590c1982 Kernel tests: the long-setback G2 patch's reach past the box from its exact surface
a_long_setback_keeps_the_g2_patch_inside_the_box measured the patch's reach past the box on
the vertices of a display mesh at chord 1e-3, so where the tessellation's nodes fell decided
the result (#9307 moved them). It now brackets the highest max(x - 60, y - 40, z - 20) on the
patch within its trim from the exact B-spline: the surface cut into its Bezier patches, split
by de Casteljau while a patch's control hull can still beat the best surface point found
inside the trim (the pcurves), so the hull bounds it from above and the patch corners from
below.

Body::exact_bounds (SMLib's SmFace::CalculateTightBoundingBox) is not used: it gives the
patch 40 + 1.4e-14 in y at set back 12, while the surface at (u, v) (-1.509, 8.041), inside
the trim, is at y = 40.00133 (a mesh node there agrees).

The bound is 1e-9 mm: the body is convex, a convex face lies inside each tangent plane, and
the patch meets each box plane tangentially along its seam, so it reaches past none of them
but by rounding. The exact extent shows the patch does reach past the box at every setback,
each time 0.4 to 0.65 mm from a hole corner (where a round's section ends on a plane, inside
the fill's fade zone): 7.0776e-4 (s 11, z), 1.3298e-3 (s 12, y), 2.6338e-6 (s 13, y),
5.1293e-5 (s 14, x), 4.7891e-4 (s 15, x). The test fails with these numbers until the patch
construction keeps the fill convex there.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 09:02:50 -04:00