three-slicer-viewer 0.3.2 → 0.3.4

package/TOOLPATH_SPEC.md

@@ -53,7 +53,7 @@ being rewritten (`core/toolpath_views.js`, `use_move_scrub.js`). Everything else
 | `nTrav` | number | travel segments |
 | `nV` | number | vertices in the extrusion stream |
 | `position` | Float32Array | per-vertex geometry input |
-| `hwa` | Float32Array | per-vertex height / width / orientation |
+| `hwa` | Float32Array | per-vertex height / width / joined heading / packed colour |
 | `segIndex` | Uint32Array | per-vertex segment identity |
 | `layerSegPrefix` | Uint32Array, length `layerCount + 1` | non-decreasing; `[0] === 0`, `[layerCount] === nSeg` |
 | `travelPos`, `travelPrefix`, `nTrav` | — | the same, for travels |
@@ -94,6 +94,10 @@ Requirements:
   0.2 mm layer: the bead spans half a layer height either side.
 - Orientation follows the segment direction in the XY plane.
 - Width and height come from `meta`, per vertex, so two segments in one draw call can differ.
+- Consecutive beads meet. An endpoint shared with the next extrusion of the same layer (or, closing a loop, with
+  the first of its run) carries that neighbour's heading in `hwa[+2]`, and the side corners there sit on the
+  bisector of the two headings. Square ends left a wedge on the outside of every turn and a corner of every short
+  segment sticking out of a curved wall. Turns sharper than 140 degrees keep the square end.
 
 `makeToolpath(THREE, data) -> ToolpathHandle` builds the scene objects. The `THREE` namespace is **passed
 in, never imported** — that is what guarantees the consumer's own three.js instance is used, and it is why
@@ -106,7 +110,10 @@ setLayerRange(lo, hi)   show only layers lo..hi inclusive
 setVisibleLayers(n)     === setLayerRange(0, n - 1)
 setTravelVisible(bool)  travels start hidden
 setColors(Float32Array) swap the per-vertex colours in place, without rebuilding geometry
+setMoveRange(at)        draw the top shown layer up to its move `at` (null = whole range again); returns
+                        moveCursor's answer plus the `layer` it walked — the move scrub (use_move_scrub.js)
 dispose()               release GPU resources
+data                    the SegmentData it was built from — the move scrub counts moves in it
 nSeg, layerCount        mirrored from the data
 ```
 

package/VIEWER.md

@@ -256,6 +256,7 @@ opt-out only, everything on unless you say `false`, an unknown key stays on.
 | `filePicker` | The file dialog never opens, from any of the buttons that open it. |
 | `contextMenu` | No right-click menu. The browser's own menu stays suppressed over the canvas either way — OrbitControls preventDefaults `contextmenu` itself. |
 | `logs` | No console output, from the component or from the slice worker. |
+| `versionBadge` | The build number at the right end of the status bar is not drawn. It is there so a bug report can name a build; turn it off when the viewer is embedded as part of your own product. `panels.status: false` hides it too, since it rides that bar. |
 
 ### Read-only panels
 
@@ -395,6 +396,29 @@ for 143MB) against a 4GB pool budget, which gives 2 for that model and does not
 manual count is capped the same way. What the browser has NOT measured yet is
 the arachne + tree-support preset, where the harness gains were largest.
 
+### The contour union on the GPU
+
+The slice bar's **GPU** select (`gpu_acceleration` in the settings map: `auto`, `on`, `off`; absent is `auto`; a viewer
+knob like `slice_workers`, not a kernel parameter) lets the slicer worker compute every layer's contour union with
+WebGPU instead of Clipper. `auto` asks for it only when the single-threaded kernel loaded, `on` on either kernel,
+`off` never. It applies to the selected plate's filament slice; pool workers, multi-material and resin slices compute
+their contours themselves.
+
+Measured in node (Dawn, Metal, 15 cores) with the kernel consuming the GPU's contours:
+
+| model | kernel | CPU | GPU |
+|---|---|---|---|
+| 3M-facet scan, tree slim support, 420 layers | st | 9.6-9.8 s | 7.6-7.7 s |
+| 1.13M-facet plate, tree hybrid support, 849 layers | st | 105 s | 102-104 s |
+| either | mt | | within run-to-run spread of the CPU slice |
+
+The union is about 2.5 s of the single-threaded slice and 50-100 ms on the GPU; on the threaded kernel the same union is
+already spread over the threads, which is why `auto` leaves it alone. What it costs: the GPU's contours have the CPU
+union's area (within 2e-10 relative) and other vertices, so the G-code is not the CPU slice's byte for byte (filament
+within 0.3 % in those two models). The slice never depends on the GPU: without a device, or when the GPU refuses an
+input, the kernel slices by itself, a layer whose loops the GPU leaves open gets the kernel's own union, and the stats
+card says which happened (`Contours on the GPU`, with the count of layers that went back to the CPU).
+
 ## Theming
 
 Both shadow roots (the viewer and `<SettingsPanel/>`) paint their chrome from one palette, `UI_TOKENS` in