Rename snaporca/SnapOrca to orca_cad so the OrcaSlicer PR carries no Snapmaker naming

2026-09-27 10:51:22 +00:00 · 2026-09-10 10:58:46 +02:00
parent 498e92ee35
commit 31a15cc5e5
44 changed files with 229 additions and 229 deletions
@@ -1,6 +1,6 @@
 # Mate connectors: aligning with the mainstream CAD systems

-Research date: 2026-08-05. Written against `orca_cad` / `snaporca` at the M8 state
+Research date: 2026-08-05. Written against `orca_cad` / `Snapmaker` at the M8 state
 (`CadDocument.{hpp,cpp}`, `apply_mate`, `datum_frame`, the `Mate` card in `DesignPanel.cpp`).

 **Brief:** align with the mate-connector concept as the main CAD programs actually implement it,
@@ -300,7 +300,7 @@ times.

 **C2 — The roll is unspecified.** Aligning Z leaves one rotation about Z undetermined. Something must
 pin it, and if that something is world-derived, the frame does not rotate with its part. **This
-codebase shipped exactly this bug** (`snaporca-en4`): a face-only connector took Z from the face
+codebase shipped exactly this bug** (`en4`): a face-only connector took Z from the face
 normal but X from `coordsys_x_hint`, a world constant, so Fastened and Slider claimed to lock an
 orientation the frame could not see. Fixed 2026-07-26 by deriving X from the face's own first usable
 edge — but note the fix's own caveat: *"replaying an older document whose face-only connector fed a
@@ -512,7 +512,7 @@ Source of record: `CadDocument.hpp:26,247-252,298-310`; `CadDocument.cpp:1669` (
 **Already aligned — do not "fix" these:** the five types and their DOF; the frame definition (A1);
 Z as the joint axis (A2); superimpose-then-relax (A3); the fixed/moving asymmetry in the data model
 (A5); DOF wording in the type list (A7); free-DOF preservation (A8); right-handed frames under mirror
-(R14); and `snaporca-en4`'s fix, which put roll derivation on the body where it belongs (C2).
+(R14); and `en4`'s fix, which put roll derivation on the body where it belongs (C2).

 **The pattern worth naming: the kernel is in good shape and the concept is under-explained.** Half the
 requirements here are wording and drawing, not geometry. The two real engineering items are R9 (origin
@@ -668,7 +668,7 @@ is a symbol, not a part — it must not shrink with the model. Nothing about tha
 The glyph was therefore implemented and driven on the rig. Screenshots: `g-0*.png`, left in the workspace `artifacts/shots/` and not moved into the repo.
 Five findings, none of which a mock could have produced:

-**F1 — Three axis arms lose to one.** Rendered side by side (`SNAPORCA_GLYPH=A` vs default), the
+**F1 — Three axis arms lose to one.** Rendered side by side (`ORCA_CAD_GLYPH=A` vs default), the
 Onshape-style RGB trio crowds a 22 px disc: the arrowheads are as large as the disc, they bury the
 gold quadrant, and at an oblique angle the three heads pile into a coloured smudge. Worse, **it is
 indistinguishable from the move gizmo and the bed triad**, which are already RGB arrow trios in this
@@ -827,7 +827,7 @@ conversation it arrived in points at "glyph".
 It changes the meaning of every stored document containing a mate. Options: (a) invert and migrate,
 writing `direction=Aligned` where `mate_flip` was false; (b) invert only for new mates and store
 `direction` explicitly from now on. (b) is safer and costs one field. Note this project has taken one
-such semantic hit knowingly before — the `snaporca-en4` fix — and the golden fixture survived, so the
+such semantic hit knowingly before — the `en4` fix — and the golden fixture survived, so the
 migration path is a known quantity. **If G3 (live preview) lands first, this matters much less.**

 **D2 — How far to take origin candidates?** [R9]
@@ -911,7 +911,7 @@ R18's loud refusals carrying the honesty.
 [Joint kinematics — the six lower pairs and their DOF](https://erc-bpgc.github.io/handbook/mechanical/Joint%20Kinematics/) ·
 [ISO 10303-105 — Kinematics (STEP integrated resource)](https://www.iso.org/standard/78589.html)

-**Internal** — `snaporca-en4` (closed 2026-07-26, fixes C2 here) · `CadDocument.cpp:1669`
+**Internal** — `en4` (closed 2026-07-26, fixes C2 here) · `CadDocument.cpp:1669`
 `datum_frame` · `CadDocument.cpp:2961` `apply_mate` · `CadDocument.cpp:1302` `add_mate`

 **Second opinion** — an independent review by Kimi Code (2026-08-05) contributed the
@@ -9,7 +9,7 @@ static const Vec2d kBearOutline[] = {        // 12 verts, RDP eps 0.030, CCW
 static const Vec2d kBearChin[] = {            // the CHIN BAR, flat. The muzzle is relief — see kBearCrest.
    {-0.2682, -0.3578}, {+0.2628, -0.3578}, {+0.2237, -0.1786},
 };
-// {cx, cy, r}: two eyes, then the cheek dot that carries handedness (snaporca-wi3z).
+// {cx, cy, r}: two eyes, then the cheek dot that carries handedness (wi3z).
 static const Vec3d kBearMarks[] = {
    {-0.1997, +0.1760, +0.0590},
    {+0.1947, +0.1760, +0.0590},
@@ -96,7 +96,7 @@
 <div class="wrap">

  <header>
-    <div class="eyebrow">SnapOrca Design · assembly</div>
+    <div class="eyebrow">Orca Design · assembly</div>
    <h1>Mate connector glyph — polarity and verse</h1>
    <p class="sub">
      Onshape's core (disc + roll quadrant + Z arrow) is adopted unchanged because it is proven and
@@ -1,4 +1,4 @@
-"""Emit the simplified bear as a C++ table for the viewport glyph — snaporca-wi3z.
+"""Emit the simplified bear as a C++ table for the viewport glyph — wi3z.

 Everything is normalised to the part's own bounding span and centred, so the renderer scales by
 one radius R in screen pixels and nothing here carries millimetres. Emitting rather than
@@ -79,7 +79,7 @@ L.append("};")
 L.append(f"static const Vec2d kBearChin[] = {{            // the CHIN BAR, flat. The muzzle is relief — see kBearCrest.")
 L.append("    "+", ".join(f"{{{fmt(x)}, {fmt(y)}}}" for x,y in TRI)+",")
 L.append("};")
-L.append("// {cx, cy, r}: two eyes, then the cheek dot that carries handedness (snaporca-wi3z).")
+L.append("// {cx, cy, r}: two eyes, then the cheek dot that carries handedness (wi3z).")
 L.append("static const Vec3d kBearMarks[] = {")
 for cx,cy,r in E: L.append(f"    {{{fmt(cx)}, {fmt(cy)}, {fmt(r)}}},")
 L.append(f"    {{{fmt(DOT[0])}, {fmt(DOT[1])}, {fmt(DOT[2])}}},")
@@ -1,4 +1,4 @@
-"""Render the SIMPLIFIED glyph exactly as render_mate_face() draws it — snaporca-x0kd.
+"""Render the SIMPLIFIED glyph exactly as render_mate_face() draws it — x0kd.

 This is the panel the study was missing. simplify_study.py measured a FLAT outline and
 relief_sheet.py measured the FULL 1508-facet part; neither showed the simplified glyph WITH its
@@ -1,4 +1,4 @@
-"""Give the bear a handedness mark that survives rasterisation — snaporca-wi3z, Tommaso's call 2.
+"""Give the bear a handedness mark that survives rasterisation — wi3z, Tommaso's call 2.

 The study showed the left/right cue lives in sub-millimetre corner radii and is therefore invisible
 at glyph size: one pixel is 2.6 mm at 32 px. Roll and verse are safe; handedness is not.
@@ -1,4 +1,4 @@
-"""The muzzle has to READ, not just be present — snaporca-wi3z.
+"""The muzzle has to READ, not just be present — wi3z.

 Faithfully scaled, the part's ridge is 11.3 mm on an 83 mm face: 13.6 % of the width. At glyph
 size that is a scratch. A glyph is a symbol, not a scale model, so the question is how much
@@ -1,4 +1,4 @@
-"""Flat glyph vs 3D relief, at the elevations that killed the disc — snaporca-wi3z.
+"""Flat glyph vs 3D relief, at the elevations that killed the disc — wi3z.

 The flat study collapsed at 16 deg because anything drawn IN the connector's plane foreshortens by
 sin(elevation). This renders the SAME bear as its real relief (1508 facets off the supplied male)
@@ -1,4 +1,4 @@
-"""Reduce the bear face to the fewest marks that still read at glyph size — snaporca-wi3z.
+"""Reduce the bear face to the fewest marks that still read at glyph size — wi3z.

 Geometry comes from bear_outline.json, which extract_outline.py pulled off the supplied male
 B-rep's back plate: the outer wire IS the silhouette, the inner wires are the two eyes and the