partforge 0.123.0 → 0.125.0

package/README.md

@@ -145,8 +145,9 @@ Restore is best-effort per field, so a state that no longer fits is dropped
 rather than fatal. The cut plane's world pose is restored exactly; its
 on-screen size is re-derived from the new geometry, since that is a property of
 the part rather than of the user's choice. Omit `viewerState` on a first mount
-— the viewer then restores its own persisted camera and projection, as it
-always has.
+— the viewer then restores its own persisted camera, as it always has, in
+perspective (the projection is automatic — orthographic only on a view cube
+face view — so it is not persisted).
 
 **Park the viewer when you hide it.** A host that hides the canvas with
 `display: none` needs nothing — the container collapses and the ResizeObserver

package/docs/AUTHORING-PARTS.md

@@ -309,8 +309,14 @@ parts: {
 meta: { title: "…", units: "mm", environment: "studio" },
 ```
 
-- `material` — a preset id from the table below. Without one the sub-part keeps
-  the default look.
+- `material` — a preset id from the table below. Without one (or with one the
+  library does not know) the sub-part keeps the CAD view's look — its `color`,
+  else the viewer's blue-grey — and **realistic mode shows it as a PLA print**
+  (`pla-print`'s finish and layer lines) in that same colour. So an untouched
+  part looks printed in realistic mode; name a material when it is made some
+  other way. The PLA look is realistic-only: the CAD view, 3MF colours and
+  `declaresMaterials` are unaffected, and a part that names no material is not
+  treated as declaring one.
 - `color` — the base colour (`0xRRGGBB`). With a preset it is the TINT. Presets
   marked tintable are normally coloured this way (anodizing, plastic, paint);
   the others have an intrinsic colour (brass) but still accept one.
@@ -2589,7 +2595,7 @@ stylesheet). `mount` looks up these element IDs:
 | `#part` | view-tab bar — leave the div **empty**; `mount` generates one button per entry in `part.views` and opens the resolved default (see the "Which view the viewer opens on" rule above) |
 | `#download-step` / `#download` / `#download-3mf` | STEP / STL / 3MF export buttons |
 | `#status`, `#busy`, `#phase` | status line + busy overlay |
-| `#viewbar` with `#annotate` / `#measure` / `#cutaway` / `#reframe` / `#realistic` / `#environment` / `#theme` | optional viewer controls (omit any you don't want) |
+| `#viewbar` with `#annotate` / `#measure` / `#cutaway` / `#reframe` / `#theme` | optional viewer controls (omit any you don't want) |
 | `#panel` | the full-height controls rail (`class="pf-rail"`); programmatic hosts pass `elements.rail` instead |
 | `#rail-toggle` | optional — collapses/restores the rail; resolved the same way as `#reframe`/`#theme`. A sibling of `#viewbar`, not a child of it: give it `class="pf-float-rail-toggle"` and it floats at the stage's top right |
 
@@ -2597,16 +2603,27 @@ Copy `demo.html` and change the title, the panel heading, and the `<script src>`
 workers are spawned from your one worker entry (`name` = `"manifold"` for preview/STL/3MF,
 `"occt"` for STEP — handled for you).
 
-**`#realistic` (a `<button>`) / `#environment` (an empty `<select>`) are the
-realistic-mode viewbar controls**, resolved by id or as `elements.chrome.realistic`
-/ `elements.chrome.environment`. Both optional and independent: supply `#realistic`
-alone for a bare toggle, or add `#environment` too and `mount` fills it with the
-part's available environments (see "Materials and appearance" above) and keeps it
-in sync — hidden while the view is in CAD mode, showing the environment in effect
-once realistic lands. Omit either and drive `runtime.renderMode` /
-`runtime.environment` from your own UI instead (see below). Both preferences
-persist across reloads the same way the theme does, and are carried in
-`viewerState` (below), which outranks what is stored.
+**The view style button needs no markup.** `mount` generates it (`#view-style`,
+an eye icon) into the stage's `#viewbar`, just before `#theme` behind a thin
+divider — the bar's "appearance" group — so a page that copies `demo.html` gets
+it in the bottom toolbar and it hides with the bar (Sketch mode). A stage with
+no `#viewbar` gets it over the view cube's bottom-right corner instead, where it
+hides whenever the cube does (Sketch mode, a crowded animation transport bar).
+Either way it replaces the old projection toggle. It opens a popover holding every control that
+changes *how* the part is drawn: the **style** — CAD or one of the realistic
+environments (see "Materials and appearance" above), each shown as a live
+thumbnail of the part, re-rendered on the next open after the part or theme
+changes. There is no projection control: the projection is **automatic** (see
+`runtime.projection` below). Feature
+lines are CAD-only and not a switch: they draw whenever the style is CAD and
+never in a realistic style. The old `#realistic` / `#environment` viewbar
+controls (`elements.chrome.realistic` / `.environment`) and the cube's own
+`#projection` button were retired with it (2026-09-24); a page that still
+carries `#realistic` / `#environment` markup just shows dead elements, so
+delete them. A host can still drive `runtime.renderMode` /
+`runtime.environment` / `runtime.projection` from its own UI (see below). The
+style preferences persist across reloads the same way the theme does, and are
+carried in `viewerState` (below), which outranks what is stored.
 
 **`#reframe` is supported but no longer shipped.** The framework's own pages dropped
 the button on 2026-08-20: clicking a face, edge or corner on the view cube reframes
@@ -2729,7 +2746,10 @@ pane's pixel size:
   target are restored after the render. Measurement-mode dimensions render directly
   in the scene, so a dimensioned capture needs no special handling — enable measure
   mode (`runtime.measure.setEnabled(true)`) and call `captureCurrent()`; the dims are
-  just part of the rendered frame.
+  just part of the rendered frame. With the cutaway on, the capture shows the section
+  the way the user sees it — the part clipped, its cut faces hatched — but never the
+  cutaway's translucent plane or its handles, which are controls, not the part (the
+  same holds for `captureViews` and the view style popover's thumbnails).
   `recenter: true` centres the part: the capture becomes the largest centred
   sub-window of the current framing that still holds every visible vertex (equal
   margins on both axes, rendered at the full `size` resolution through a view
@@ -2747,12 +2767,25 @@ pane's pixel size:
 ### `runtime.projection`
 
 `{ get(), set(mode), onChange(cb) }` where `mode` is `"perspective"` or
-`"orthographic"`. Drives the **live view** and `captureCurrent` only —
+`"orthographic"`. The projection is **automatic**, the way Fusion 360's
+"Perspective with Ortho Faces" and Blender's "Auto Perspective" work: clicking
+one of the view cube's six **face** views (on the cube, or through its hidden
+per-face keyboard buttons) tweens there and settles into orthographic at the
+end of the tween, with no size jump; an edge, corner or iso view is perspective
+(an orthographic view switches back as that tween starts). In a face view,
+**pan and zoom keep it orthographic; the first rotation** (the view direction
+leaving the face axis by more than half a degree) swaps back to perspective,
+keeping the part's apparent size. Animation camera cues never switch into
+orthographic. There is no user control for it. `set("orthographic")` still
+works for a host, and is left the same way — by the first rotation — and
+`onChange` hears every automatic swap. It is **not persisted** across reloads
+(a reload opens in perspective); a remount carries it in `viewerState`, but
+only with a face-view camera — carried with any other camera it restores
+perspective. Drives the **live view** and `captureCurrent` only —
 `captureCanonicalViews`, `renderMeshPayloads`, and the CLI's `partforge render`
-stay perspective unconditionally, so agent-facing output does not depend on a UI
-toggle. The choice persists across reloads under `partforge:projection` and is
-restored before the first framing. The orientation cube and its projection
-button are hidden while Sketch (annotate) mode is active, but that only governs
+stay perspective unconditionally, so agent-facing output does not depend on the
+live view. The orientation cube and the view style
+button (in `#viewbar`, which Sketch hides) are hidden while Sketch (annotate) mode is active, but that only governs
 *user-driven* view changes — the framework does not police programmatic ones.
 The ink is a transparent overlay and the WebGL canvas keeps rendering beneath
 it, so a host that calls `runtime.projection.set()` mid-sketch **visibly
@@ -2765,7 +2798,7 @@ Deliberately unguarded, the same way it's always been free to call
 ### `runtime.renderMode`, `runtime.environment`, `runtime.renderViews`, `runtime.declaresMaterials`
 
 For an embedder driving realistic mode from its own UI instead of (or in
-addition to) the `#realistic` / `#environment` viewbar controls above:
+addition to) the generated view style button above:
 
 - `runtime.renderMode` — `{ get(), set(mode), onChange(cb) }` where `mode` is
   `"cad"` or `"realistic"`. `set()` resolves to the mode actually in effect —
@@ -2791,8 +2824,11 @@ addition to) the `#realistic` / `#environment` viewbar controls above:
   revert too.
 - `runtime.declaresMaterials` — `true` when any sub-part names a
   `display.material`. A part with none still supports realistic mode (every
-  sub-part just renders under the library's `default` look), so use this to
-  decide whether to surface the realistic toggle at all, not whether it works.
+  sub-part renders as a PLA print in its CAD colour), so use this to decide
+  whether to surface your own realistic control at all, not whether it works.
+  Feature lines are not a preference: they draw whenever `runtime.renderMode`
+  reads `"cad"` and never while it reads `"realistic"` — there is no switch
+  to drive independently of it.
 - `await runtime.renderViews(viewNames, { renderMode? })` — the appearance-aware
   sibling of `runtime.captureViews` (canonical angles, framed to the visible
   assembly, grid hidden): `{ renderMode: "cad" }` (the default) is exactly
@@ -2800,19 +2836,18 @@ addition to) the `#realistic` / `#environment` viewbar controls above:
   for the capture — waiting on the chosen environment's assets — **without**
   switching the live view. Rejects if the realistic assets fail to load.
 
-Both preferences round-trip through `mount()`'s `viewerState`: a
-previous mount's `runtime.getViewerState()` carries `viewerState.renderMode`
-(`"cad"` or `"realistic"`) and, only when the viewer's environment was
-actually CHOSEN rather than merely defaulted from `meta.environment`,
-`viewerState.environment`. `renderMode` reports the mode the user is **headed
-for**, not only the one on screen: a realistic restore or switch that's still
-loading reports `"realistic"`, so a host that remounts on every edit (as an
-embedder applying edits by remounting typically does) doesn't drop the
-in-flight choice — a load that ultimately fails still settles back to
-`"cad"`. Pass `viewerState` back into the next `mount()` call to resume both
-where the previous mount left them; omit it on a first mount and the viewer
-restores its own persisted choice instead, the same way it does for the
-camera and projection.
+Both preferences round-trip through `mount()`'s `viewerState`: a previous
+mount's `runtime.getViewerState()` carries `viewerState.renderMode` (`"cad"`
+or `"realistic"`) and, only when the viewer's environment was actually CHOSEN
+rather than merely defaulted from `meta.environment`, `viewerState.environment`.
+`renderMode` reports the mode the user is **headed for**, not only the one on
+screen: a realistic restore or switch that's still loading reports
+`"realistic"`, so a host that remounts on every edit (as an embedder applying
+edits by remounting typically does) doesn't drop the in-flight choice — a
+load that ultimately fails still settles back to `"cad"`. Pass `viewerState`
+back into the next `mount()` call to resume both where the previous mount
+left them; omit it on a first mount and the viewer restores its own persisted
+choice instead, the same way it does for the camera.
 
 ### The annotation payload's camera block
 
@@ -3276,7 +3311,8 @@ nothing either way and stays silent, matching `animation-track-rebuilds`'s own
 trust handling.
 
 **Appearance** (all warnings) — `unknown-material` (a `display.material` the
-library does not know; the viewer shows the default look), `unknown-environment`
+library does not know; the viewer draws it as if it named none — a PLA print
+in realistic mode), `unknown-environment`
 (`meta.environment` not known; realistic mode uses `studio`),
 `material-key-unknown` (a `display` key that is not colour, opacity, material
 or one of the six overrides; ignored), `material-override-clamped` (an override

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "partforge",
-  "version": "0.123.0",
+  "version": "0.125.0",
   "description": "Turn a declarative part definition into a parametric-CAD web app (three.js + Manifold/Replicad). Requires a Vite-based consumer.",
   "type": "module",
   "license": "MIT",

package/src/framework/annotate/annotate-mode.js

@@ -515,8 +515,13 @@ export function createAnnotateMode(viewer, { stage, getContext, onSend, createCa
   }
 
   function cameraBlock(inv) {
-    const { pos, target } = viewer.getCameraState();
+    // The target from getCameraState, the position from the LIVE camera: under
+    // ortho getCameraState reports a perspective-equivalent position (for
+    // restoring a framing), while this block describes the camera that
+    // actually drew the frame.
+    const { target } = viewer.getCameraState();
     const cam = viewer.camera;
+    const pos = cam.position.toArray();
     const ortho = !!cam.isOrthographicCamera;
     // 4 decimals ≈ 0.1 µm at mm scale — far below anything a sketch encodes,
     // and it keeps float dust (1e-16 up-vector components) out of what an LLM

package/src/framework/app.css

@@ -476,8 +476,8 @@ button.action:disabled { opacity: .5; cursor: default; }
 /* keyboard focus ring shared across the panel's interactive controls */
 .seg button:focus-visible, select.preset:focus-visible, .dl-row button:focus-visible,
 button.action:focus-visible, .adv-toggle:focus-visible, .sec-title:focus-visible, #viewbar button:focus-visible,
-#viewbar select:focus-visible, .pf-view-select:focus-visible,
-.pf-viewcube-toggle:focus-visible, .pf-float-rail-toggle:focus-visible, .pf-sketch-toolbar button:focus-visible {
+.pf-view-select:focus-visible,
+.pf-float-rail-toggle:focus-visible, .pf-sketch-toolbar button:focus-visible {
   outline: none;
   box-shadow: 0 0 0 3px color-mix(in oklab, var(--pf-accent) 35%, transparent);
 }
@@ -595,21 +595,6 @@ button.action:focus-visible, .adv-toggle:focus-visible, .sec-title:focus-visible
 #viewbar button:disabled:hover { color: var(--pf-muted-2); background: transparent; }
 #viewbar button:hover { color: var(--pf-text); background: var(--pf-surface-2); }
 #viewbar button.on { background: var(--pf-accent); color: var(--pf-on-accent); }
-/* Realistic view (realistic-controls.js). The toggle is an ordinary viewbar
-   button that pulses while its environment loads; the environment picker is a
-   native <select> — the accessible choice on a phone — dressed as a viewbar
-   button, shown only while realistic. Keyed on `#viewbar select` rather than
-   an id so a host's own element in the pill gets the same look. */
-#viewbar button[data-busy] { animation: pf-busy-pulse .8s ease-in-out infinite alternate; }
-@keyframes pf-busy-pulse { from { opacity: 1; } to { opacity: .45; } }
-@media (prefers-reduced-motion: reduce) { #viewbar button[data-busy] { animation: none; opacity: .6; } }
-#viewbar select {
-  height: 34px; padding: 0 8px; border: 0; border-radius: var(--pf-radius-control);
-  background: transparent; color: var(--pf-muted-2); cursor: pointer;
-  font: inherit; font-size: 13px;
-}
-#viewbar select:hover { color: var(--pf-text); background: var(--pf-surface-2); }
-#viewbar select[hidden] { display: none; }
 
 /* Sketch-mode toolbar: the #viewbar pill idiom, top-centre, owning the mode
    while the viewbar itself is hidden (mount toggles both).
@@ -733,57 +718,84 @@ button.action:focus-visible, .adv-toggle:focus-visible, .sec-title:focus-visible
    APPEARANCE only (placement lives in chrome.css, per the split at the top of
    this file).
 
+   The VIEW STYLE button replaced the cube's projection toggle
+   (view-style-controls.js, 2026-09-24); it now lives in #viewbar, and only a
+   host without one gets it over the cube's corner (its appearance is in the
+   next section, its placement in chrome.css). The toggle's history there ran:
+
    Through 2026-08-19 the projection toggle sat in its own `.pf-viewcube-pill`
    card below the cube, deliberately borrowing #viewbar's chrome so it read as
    one of the viewer controls. The 2026-08-20 revision moved it beside the
    cube instead, at a size and a bottom-aligned baseline that a #viewbar-style
-   card could not shrink to — so it is now a small bare circle in its own
-   right (`.pf-viewcube-toggle`), no card, no border, no shadow.
-
-   A same-day follow-up moved it again, from beside the cube to OVER its
-   bottom-right corner (placement in chrome.css, as ever). Nothing here
-   changed: a bare transparent circle was already what made that legal — it
-   has no card edge to cut across the drawing underneath it, so overlapping
-   costs the cube nothing but the 24px it covers.
-
-   A later revision that same day took the resting fill away entirely: now
-   that the button sits ON the cube's drawing, a persistent accent-tinted
-   disc in orthographic mode read as a blob over the geometry rather than as
-   a control. A background appears on HOVER only, in both states.
-
-   The last revision of the day took the accent COLOUR away too, so the
-   orthographic state now carries exactly ONE visual signal: the icon GLYPH (a
-   perspective frustum becomes an axonometric box). The button is grey in both
-   projections, resting and hovered, and there is deliberately no `.on` rule
-   below — viewcube-controls.js still adds the class, and `aria-pressed` still
-   carries the state for assistive tech. That is a choice, not an oversight: a
-   blue icon sitting on the cube's own drawing read as a stray tint rather than
-   as a mode, and the glyph is the tell that survives any colour scheme anyway.
-   Do not reintroduce a tint without asking. */
+   card could not shrink to — so it became a small bare 24px circle in its own
+   right (`.pf-viewcube-toggle`), no card, no border, no shadow. A same-day
+   follow-up moved it OVER the cube's bottom-right corner, took its resting
+   fill away (a tinted disc on the drawing read as a blob, not a control) and
+   then its accent colour, leaving the glyph as the one signal of the
+   projection. The view style button went the other way on purpose: the
+   request was for a control that is clearly SEEN — first #viewbar's card
+   chrome over the corner, now a button IN #viewbar. The projection itself has
+   no control at all since 2026-09-24: it is automatic (orthographic on a view
+   cube face view, perspective otherwise — viewer.js's tweenCameraTo). */
 .pf-viewcube-canvas {
   display: block;
   touch-action: none;
 }
-.pf-viewcube-toggle {
-  /* 24px: the low end of "small" so the bare circle reads as understated next
-     to the cube rather than as a second focal point competing with it — a
-     card's border/background used to do that visual quieting; a transparent
-     shape has nothing else to lean on but size. */
-  width: 24px; height: 24px;
-  border: 0; border-radius: 50%;
-  background: transparent; box-shadow: none;
+
+/* ---- view style button + popover (view-style-controls.js) -------------------
+   In #viewbar the button is a plain `#viewbar button` (34px, transparent,
+   the bar's hover / `.on` / focus) and needs nothing here beyond the
+   divider that opens the appearance group. The card chrome below is the
+   FALLBACK's alone — the button over the cube's corner, for a host with no
+   #viewbar — where it has to read as a control on top of the drawing: 30px,
+   the viewbar's own compact button size (at 34px it covered a third of the
+   101px narrow cube). Scoped to the stack so none of it (the float shadow in
+   particular, which `#viewbar button` does not reset) leaks into the bar. */
+.pf-viewbar-divider {
+  width: 1px; align-self: stretch; margin: 6px 2px; flex: none;
+  background: var(--pf-border);
+}
+.pf-viewbar-divider[hidden] { display: none; }
+.pf-viewcube-stack > .pf-view-style-button {
+  width: 30px; height: 30px; border: 1px solid var(--pf-border); border-radius: var(--pf-radius-control);
+  background: var(--pf-surface); box-shadow: var(--pf-shadow-float);
   color: var(--pf-muted-2); cursor: pointer;
-  font-size: 14px; line-height: 1;
   display: flex; align-items: center; justify-content: center;
 }
-.pf-viewcube-toggle:hover { color: var(--pf-text); background: var(--pf-surface-2); }
-/* The focus ring is NOT restated here: the toggle joins the shared
-   :focus-visible selector list above, beside #viewbar's own.
-
-   No narrow-width shrink rule here: unlike the old pill (which borrowed
-   #viewbar's chrome and had to shrink in lockstep with it, below), a bare
-   24px circle has no card to keep in step with a smaller viewbar — it stays
-   its one fixed size at every width. */
+.pf-view-style-button[hidden] { display: none; }
+.pf-viewcube-stack > .pf-view-style-button:hover, .pf-viewcube-stack > .pf-view-style-button.on { color: var(--pf-text); background: var(--pf-surface-2); }
+.pf-view-style-popover {
+  position: absolute; z-index: 30;
+  width: min(300px, calc(100% - 24px)); overflow: auto;
+  padding: 12px; display: flex; flex-direction: column; gap: 12px;
+  background: var(--pf-surface); border: 1px solid var(--pf-border);
+  border-radius: 12px; box-shadow: var(--pf-shadow-float);
+  color: var(--pf-text); font-size: 12px;
+}
+.pf-view-style-popover[hidden] { display: none; }
+.pf-view-style-heading { margin: 0; font-size: 11px; letter-spacing: 0.06em; text-transform: uppercase; color: var(--pf-muted-2); }
+.pf-view-style-grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 8px; }
+.pf-view-style-tile {
+  display: flex; flex-direction: column; gap: 4px; padding: 0; border: 0;
+  background: none; color: var(--pf-muted-2); cursor: pointer; font: inherit; text-align: center;
+}
+.pf-view-style-thumb {
+  display: block; aspect-ratio: 1; border-radius: 8px; overflow: hidden;
+  background: var(--pf-surface-2); border: 1px solid var(--pf-border);
+}
+.pf-view-style-thumb img { display: block; width: 100%; height: 100%; object-fit: cover; }
+.pf-view-style-thumb img[hidden] { display: none; }
+.pf-view-style-tile[aria-pressed="true"] { color: var(--pf-text); }
+.pf-view-style-tile[aria-pressed="true"] .pf-view-style-thumb { border-color: var(--pf-accent); box-shadow: 0 0 0 1px var(--pf-accent); }
+.pf-view-style-tile[data-busy] .pf-view-style-thumb { opacity: 0.6; }
+/* A tile whose environment is still loading pulses (the retired viewbar ✦
+   toggle's signal, moved onto the thing that was clicked). */
+.pf-view-style-tile[data-busy] .pf-view-style-thumb { animation: pf-busy-pulse .8s ease-in-out infinite alternate; }
+@keyframes pf-busy-pulse { from { opacity: 1; } to { opacity: .45; } }
+@media (prefers-reduced-motion: reduce) { .pf-view-style-tile[data-busy] .pf-view-style-thumb { animation: none; } }
+.pf-view-style-button:focus-visible, .pf-view-style-tile:focus-visible {
+  outline: none; box-shadow: 0 0 0 3px color-mix(in oklab, var(--pf-accent) 35%, transparent);
+}
 
 /* At very narrow widths the full-size viewbar (5 icon buttons + cutaway's
    Flip/Reset, ~314px) is wider than a small phone's viewport minus the

package/src/framework/chrome.css

@@ -249,24 +249,36 @@
    56px fallback is the standard viewbar's 12px bottom + 44px height, so the
    stack still sits right if the observer never fires.
 
-   The projection toggle has moved twice. Through 2026-08-19 it sat in its own
-   `.pf-viewcube-pill` card BELOW the cube, making the stack a column. Earlier
-   on 2026-08-20 it became a bare circle BESIDE the cube, making the stack a
-   `row-reverse` flex row (`canvas + gap + button`, 167px wide at the full
-   135px cube). It now sits OVER the cube's bottom-right corner instead:
-   absolutely positioned within the stack, right edge on the stack's right edge
-   and bottom edge on its bottom baseline, so the stack's width collapses back
-   to the canvas alone (135px, or 101 below the narrow breakpoint).
-
-   That is also what satisfies "aligned with the right of the toolbar" without a
-   second offset: `.pf-float-viewbar` above is `right: 12px` too, so making the
-   button's right edge the STACK's right edge lines it up with the viewbar's by
-   construction — and it keeps doing so if that margin is ever retuned.
-
-   The button is a later sibling than the cube's wrapper, so it paints over the
-   canvas with no z-index of its own; 24px over the corner cell — the least
-   informative part of the drawing — is small enough not to hide anything worth
-   clicking, and the canvas keeps receiving pointer events everywhere else.
+   The VIEW STYLE button (view-style-controls.js) now lives in #viewbar, the
+   bottom toolbar, in its APPEARANCE group beside #theme (2026-09-24, at the
+   user's request after a live mock, following Fusion 360's
+   display-settings-in-the-nav-bar convention) — the cube's corner is clear
+   again. Only a host with NO #viewbar still gets it here, over the cube's
+   bottom-right corner (the `.pf-viewcube-stack > .pf-view-style-button`
+   rule below is scoped to exactly that fallback). Its history: the
+   PROJECTION TOGGLE it replaced had moved three times (through 2026-08-19 in
+   its own `.pf-viewcube-pill` card BELOW the cube, the stack a column;
+   earlier on 2026-08-20 a bare circle BESIDE the cube, the stack a
+   `row-reverse` flex row 167px wide at the full cube; later that day OVER
+   the cube's bottom-right corner). The view style button took that corner;
+   for a few hours on 2026-09-24 it moved out beside the cube, to its left
+   (at 34px and card-chromed it covered a third of the 101px narrow cube, and
+   beside the cube it had to dodge the animation transport bar); later that
+   day it came back over the corner ("to the bottom right of the direction
+   widget"), at 30px; and later still it moved into the bottom toolbar.
+
+   In the fallback it sits inside the stack's box, so it cannot change the
+   stack's measured size — the size viewcube-controls.js publishes as
+   data-pf-w/h and the transport bar's crowding rule reads is still the
+   canvas alone (135px, or 101 below the narrow breakpoint). It is a later
+   sibling than the cube's wrapper, so it paints over the canvas with no
+   z-index of its own.
+
+   The stack keeps its right edge on the viewbar's (`.pf-float-viewbar` above
+   is `right: 12px` too), so the cube still lines up with the toolbar by
+   construction. The popover is NOT in the stack: it is appended to the stage
+   and placed at open time (above the toolbar pill, or above the fallback
+   button).
 
    The 8px that used to sit between the stack and the viewbar is now 3px
    (2026-08-20: "lower the whole box so it's closer to the bottom bar"). 3
@@ -283,9 +295,9 @@
    this pair (3 + 5) is the whole slack that exists without either overlapping
    the viewbar or shrinking the cube.
 
-   The stack itself is pointer-transparent. With the button back inside the
-   canvas's footprint there is no dead gap left at all: the stack's box IS the
-   canvas's box, and both the canvas and the button opt back in below. The
+   The stack itself is pointer-transparent. Its box IS the canvas's box, so
+   there is no dead gap in it; the canvas (and a fallback view style
+   button) opt back in below. The
    declaration stays because the stack's own box is still an element over the
    viewer, and a stray hit on it (its padding-free edges, or a future child
    before it opts in) should reach the model behind rather than be swallowed. */
@@ -298,10 +310,11 @@
   pointer-events: none;
 }
 .pf-viewcube-stack[hidden] { display: none; }
-.pf-viewcube-canvas, .pf-viewcube-toggle { pointer-events: auto; }
-/* Over the cube's bottom-right corner. Absolute against the stack, which is
-   itself absolute and so already the containing block. */
-.pf-viewcube-toggle { position: absolute; right: 0; bottom: 0; }
+.pf-viewcube-canvas, .pf-viewcube-stack > .pf-view-style-button { pointer-events: auto; }
+/* The fallback only (no #viewbar): over the cube's bottom-right corner.
+   Absolute against the stack, which is itself absolute and so already the
+   containing block. In #viewbar the button is an ordinary flex item. */
+.pf-viewcube-stack > .pf-view-style-button { position: absolute; right: 0; bottom: 0; }
 
 /* The keyboard surface: six per-view buttons standing in for the DOM focus a
    canvas cannot give us. Visually hidden rather than display:none — the latter

package/src/framework/cutaway-gizmo.js

@@ -53,7 +53,8 @@ export function createCutawayGizmo({
   onDragChange = () => {},
   pickHandle,
 }) {
-  // Reassignable: the viewer swaps cameras when the projection toggle flips,
+  // Reassignable: the viewer swaps cameras when the projection changes (a view
+  // cube face view settling into ortho, a rotation leaving it),
   // and this module holds fifteen references to it. One binding to move beats
   // threading a getter through all of them.
   let camera = initialCamera;

package/src/framework/cutaway.js

@@ -144,6 +144,29 @@ export function createCutaway({
     handleHoverSubscribers.clear();
   }
 
+  // "What the section looks like changed": the mode went on or off, or the
+  // plane moved (a drag, flip, reset or restore). For anything that caches a
+  // picture of the part — the view style popover's thumbnails — which would
+  // otherwise keep showing a section the user has since moved or closed.
+  // Fires often during a drag, so a listener must be cheap; no argument, since
+  // every caller only needs to know that it happened. A throwing listener is
+  // reported, never allowed to interrupt the controller work that fired it.
+  const changeListeners = new Set();
+  function notifyChange() {
+    for (const listener of [...changeListeners]) {
+      try {
+        listener();
+      } catch (error) {
+        try { console.error("Cutaway change listener failed", error); } catch { /* reporting only */ }
+      }
+    }
+  }
+  function onChange(listener) {
+    if (disposed || typeof listener !== "function") return () => {};
+    changeListeners.add(listener);
+    return () => changeListeners.delete(listener);
+  }
+
   function selected(name) {
     return selectedNames == null || selectedNames.has(name);
   }
@@ -213,6 +236,7 @@ export function createCutaway({
     gizmo.setFlipped(flipped);
     gizmo.setPose(pose);
     if (activeAppearance) showActive();
+    notifyChange();
   }
 
   function onPoseChange(nextPose) {
@@ -314,6 +338,7 @@ export function createCutaway({
     } finally {
       disabling = false;
     }
+    if (wasEnabled) notifyChange();
     if (firstError) throw firstError;
     return true;
   }
@@ -340,6 +365,7 @@ export function createCutaway({
     gizmo.setVisible(true);
     gizmo.updateForCamera();
     showActive();
+    notifyChange(); // applyPose above fired too, but before `enabled` meant on
     return true;
   }
 
@@ -360,6 +386,7 @@ export function createCutaway({
     planeFromPose(plane, planeNormal, pose.position, pose.quaternion, flipped);
     gizmo.setFlipped(flipped);
     showActive();
+    notifyChange();
     return true;
   }
 
@@ -579,6 +606,7 @@ export function createCutaway({
     publishHandleHover(null);
     drainHandleHoverPublications();
     clearHandleHoverSubscribers();
+    changeListeners.clear();
     attempt(() => overlayScene.clear());
     attempt(() => capGeometry.dispose());
     if (firstError) throw firstError;
@@ -605,6 +633,11 @@ export function createCutaway({
     updateForCamera,
     renderOverlay,
     onHandleHoverChange,
+    onChange,
+    // The gizmo's in-scene half (the ghost plane and its border). It is
+    // interactive UI drawn in the part's own scene, so the viewer keeps it out
+    // of every offscreen render (viewer.js's captureHidden).
+    captureExcluded: [gizmo.group],
     setCamera(next) {
       if (!next) return;
       camera = next;

package/src/framework/geometry/threemf.js

@@ -69,8 +69,9 @@ function weld(positions, indices) {
 }
 
 // Default for an uncoloured object in an export where some other object IS
-// coloured: the viewer's own default look (presets.js "default"). Written as a
-// literal so this module keeps its fflate-only import closure.
+// coloured: the viewer's own no-material colour (resolve.js
+// NO_MATERIAL_COLOR). Written as a literal so this module keeps its
+// fflate-only import closure; viewer-materials.test.js pins the copies equal.
 const DEFAULT_DISPLAY_COLOR = 0x9fb4cc;
 // Base-material group id: outside the object id range (objects are 1..n).
 const BASE_MATERIALS_ID = 1000;

package/src/framework/lint/rules-materials.js

@@ -3,12 +3,12 @@
 // block geometry, and the viewer already falls back (resolve.js). Pure — imports
 // only the three-free materials data (test/lint-purity.test.js).
 import { warn } from "./finding.js";
-import { PRESETS, DEFAULT_PRESET_ID } from "../materials/presets.js";
+import { PRESETS } from "../materials/presets.js";
 import { ENVIRONMENTS } from "../materials/environments.js";
 import { resolveMaterial, resolveEnvironmentId, OVERRIDE_RANGES } from "../materials/resolve.js";
 import { suggest } from "../geometry/op-options.js";
 
-const listedPresets = () => Object.keys(PRESETS).filter((id) => id !== DEFAULT_PRESET_ID);
+const listedPresets = () => Object.keys(PRESETS);
 const subParts = (part) => Object.entries(part?.parts ?? {}).filter(([, sp]) => sp && typeof sp === "object");
 const issuesOf = (part, kind) => subParts(part).flatMap(([name, sp]) =>
   resolveMaterial(sp.display).issues.filter((i) => i.kind === kind).map((i) => ({ name, ...i })));
@@ -20,7 +20,7 @@ export const MATERIAL_RULES = [
       const near = typeof value === "string" ? suggest(value, listedPresets()) : null;
       return warn("unknown-material",
         `sub-part "${name}" names material ${JSON.stringify(value)}, which is not in the library`,
-        `${near ? `Did you mean "${near}"? ` : ""}The viewer shows the default look instead. Known materials: ${listedPresets().join(", ")}.`,
+        `${near ? `Did you mean "${near}"? ` : ""}The viewer draws it as if it named no material instead (a PLA print in realistic mode). Known materials: ${listedPresets().join(", ")}.`,
         `parts.${name}.display.material`);
     }),
   },

package/src/framework/materials/assets/SOURCES.md

@@ -68,7 +68,7 @@ the sliced primary and gain-map buffers now start with SOI (`FF D8`) and end wit
 | `pattern-walnut-rough.jpg` | Poly Haven "Dark Wood" (roughness; API key `Rough`) | https://polyhaven.com/a/dark_wood — file https://dl.polyhaven.org/file/ph-assets/Textures/jpg/1k/dark_wood/dark_wood_rough_1k.jpg | 2026-09-24 | 1K JPG, grayscale data -> `node scripts/bake-environments.mjs --texture dark_wood_rough_1k.jpg pattern-walnut-rough.jpg --gray` (source is neutral grey; channel means unchanged). |
 | `ground-maple-color.jpg` | Poly Haven "Oak Veneer 01" (colour; API key `Diffuse`) | https://polyhaven.com/a/oak_veneer_01 — file https://dl.polyhaven.org/file/ph-assets/Textures/jpg/1k/oak_veneer_01/oak_veneer_01_diff_1k.jpg | 2026-09-24 | Workshop floor, "unfinished maple": `node scripts/bake-environments.mjs --texture oak_veneer_01_diff_1k.jpg ground-maple-color.jpg --modulate 1.5,0.7 --quality 85` (lightened 1.5x, saturation 0.7). |
 | `ground-maple-normal.jpg` | Poly Haven "Oak Veneer 01" (OpenGL normal map; API key `nor_gl`) | https://polyhaven.com/a/oak_veneer_01 — file https://dl.polyhaven.org/file/ph-assets/Textures/jpg/1k/oak_veneer_01/oak_veneer_01_nor_gl_1k.jpg | 2026-09-24 | Workshop floor relief: `node scripts/bake-environments.mjs --texture oak_veneer_01_nor_gl_1k.jpg ground-maple-normal.jpg --data --quality 92`. A separate file from `pattern-oak-normal.jpg` so the floor and the oak material never share (and dispose) one texture. |
-| `ground-pei.jpg` | None — procedural | n/a | n/a | Gold-brown fine-grain speckle, no external source. First attempt tinted ambientCG "Plastic 010"'s colour map (near-uniform, stdev < 1/channel — visibly flat, no grain, when actually viewed) gold-brown; that colour map carries no usable grain at all (its roughness map does, which is why `ground-pei-rough.jpg` below is still Plastic010's roughness). Checked ambientCG alternatives (Metal049A — also flat; Granite006A — real speckle but reads as rock, not powder-coat) and found nothing closer. Generated in-baker instead, same procedural precedent as `pattern-carbon.jpg`: per-pixel triangular-distributed noise around a `196,154,82` gold-brown base (asymmetric per channel so flecks warm rather than grey), then a 0.5px blur to turn single-pixel noise into soft grains -> `node scripts/bake-environments.mjs --speckle ground-pei.jpg --tint 196,154,82`. |
+| `ground-pei.jpg` | None — procedural | n/a | n/a | Gold-brown fine-grain speckle, no external source. First attempt tinted ambientCG "Plastic 010"'s colour map (near-uniform, stdev < 1/channel — visibly flat, no grain, when actually viewed) gold-brown; that colour map carries no usable grain at all (its roughness map does, which is why `ground-pei-rough.jpg` below is still Plastic010's roughness). Checked ambientCG alternatives (Metal049A — also flat; Granite006A — real speckle but reads as rock, not powder-coat) and found nothing closer. Generated in-baker instead, same procedural precedent as `pattern-carbon.jpg`: per-pixel triangular-distributed noise around a `168,134,82` bronze-gold base (asymmetric per channel so flecks warm rather than grey), then a 0.5px blur to turn single-pixel noise into soft grains -> `node scripts/bake-environments.mjs --speckle ground-pei.jpg --tint 168,134,82`. (Re-baked 2026-09-24 from `196,154,82`: darker and less saturated, closer to a Bambu textured-PEI plate's muted bronze-gold.) |
 | `ground-pei-rough.jpg` | ambientCG "Plastic 010" (Roughness) | https://ambientcg.com/a/Plastic010 | 2026-09-24 | 1K JPG, grayscale -> `node scripts/bake-environments.mjs --texture Plastic010_1K-JPG_Roughness.jpg ground-pei-rough.jpg --gray` |
 | `ground-concrete.jpg` | ambientCG "Concrete 047 A" (Color) | https://ambientcg.com/a/Concrete047A | 2026-09-24 | 2K JPG -> `node scripts/bake-environments.mjs --texture Concrete047A_2K-JPG_Color.jpg ground-concrete.jpg --size 1024 --modulate 1.35,0 --flatten 0.7 --quality 82` (grey, brightened to the old map's mean so the concrete material preset keeps its tone; `--flatten 0.7` is 30% less grain contrast). Replaced ambientCG "Concrete 034", whose colour map was nearly flat (stdev ~5/255) and read as blur up close; 047 A's exposed aggregate keeps fine grain. |
 | `ground-concrete-rough.jpg` | ambientCG "Concrete 047 A" (Roughness) | https://ambientcg.com/a/Concrete047A | 2026-09-24 | 2K JPG, grayscale -> `node scripts/bake-environments.mjs --texture Concrete047A_2K-JPG_Roughness.jpg ground-concrete-rough.jpg --gray --size 1024` |