three-slicer 0.3.2 → 0.3.3

package/CHANGELOG.md

@@ -1,5 +1,79 @@
 # Changelog
 
+## 0.3.3 — 2026-10-01
+
+### Added
+
+- The layer contours can be computed on the GPU. The viewer's slice bar has a GPU select (`gpu_acceleration`:
+  `auto`, `on`, `off`), and the worker's slice message takes `gpu: true`. `auto` uses it on the single-threaded
+  kernel only, where a 3M-facet slice went from 9.8 to 7.6 s; the threaded kernel gains nothing measurable. A GPU
+  slice's G-code differs from the CPU slice's in its vertices (same contour area), and the result's
+  `stats.contour_engine` says which engine ran.
+- On the single-threaded kernel the GPU also cuts the mesh into layers and chains the loops (`stats.contour_front`
+  `'gpu'`; the slice card reads "Contours cut and unioned on the GPU"). The kernel hands its mesh over instead of
+  cutting every layer itself: on a 3M-facet model that part went from 419-442 ms to 34-154 ms plus 64-153 ms on the
+  GPU. A layer the GPU cannot close is cut by the kernel as before.
+- `support_style` `tree_slim`, `tree_strong` and `tree_hybrid` reach the kernel as `tree_style`. They used to slice
+  as organic.
+
+### Changed
+
+- The threaded kernel ships its wasm as a file, `engine/src/slicer_core.mt.wasm`, instead of inlining it in
+  `slicer_core.mt.js` (6.4 MB -> 107 KB). Every pthread worker loads the glue, and the inlined bytes cost each of
+  them about 60 MB of V8 heap; Chrome holds every isolate of a tab in one 4 GB heap region, so slicing several plates
+  at once crashed the tab ("V8 javascript OOM"; 3 workers on a 6-plate project: 4 crashes in 6 runs). With the file,
+  3 to 8 workers ran without a crash and peaked at 1.2-1.9 GB. A bundler emits the file as an asset; see
+  "Multithreaded WASM" in the README for serving it.
+- Tree support (slim, strong, hybrid) runs four of its loops on every thread of the threaded kernel: a 1.13M-facet
+  hybrid plate went from 91 to 21 s, with the same G-code as the single-threaded kernel.
+- Tree support unions each layer's support circles per group of overlapping circles instead of all at once. On the
+  same plate the slice went from 21.2-21.6 to 18.9-19.0 s (threaded) and from 110.3 to 98.0 s (single-threaded).
+  The support area is unchanged; its G-code vertices come out in another order (support extrusion 4113.49 ->
+  4113.50 mm, every model path unchanged).
+- Tree support finds overhangs on every thread of the threaded kernel (it ran on one): on the same plate the slice
+  went from 18.6-18.9 to 17.6-17.7 s, with the same G-code.
+- Tree support no longer recomputes the same offsets while it drops branches and groups overhangs (a dilation per
+  node move, a whole-layer line clip per segment, a region offset per cluster tried): on the same plate the slice
+  went from 17.1-17.3 to 15.5-15.6 s, with the same G-code.
+- Tree support's threads no longer queue on two locks while they move branches (one over the line-cut cache, one
+  around every new node), the branch spanning trees are built in one pass per vertex and per part on threads, and the
+  layer outlines are prepared beside overhang detection instead of after it: on the same plate 15.6 -> 13.9-14.1 s,
+  then 10.2-10.3 -> 9.7-9.8 s, with the same G-code.
+- Tree support unions each group of overlapping circles as a tree of smaller unions, split by position: draw_circles
+  4.6 -> 2.3 s on the same plate (11.6-11.8 s slice). The support area is the same; the intermediate unions round
+  their crossings once more, so the support G-code moves slightly (support extrusion 4113.50 -> 4113.56 mm, the worst
+  layer 0.27 %, every model path unchanged). Clipper2's union measured slower and is not used.
+- Arachne walls are written by the threaded kernel's G-code writers like every other path (they were written on one
+  thread): on the same plate emit 3.2 -> 1.7 s (11.7 -> 10.2 s slice), with the same G-code, toolpaths and widths as
+  the single-threaded kernel.
+
+- The toolpath preview culls back faces and, far from the camera, draws every 2nd or 4th layer that many layers
+  thick (raft and skirt layers and a cut layer range keep full detail). Measured on a 6-plate project with 14.6M
+  segments: 67.8 -> 34.8 ms per frame, the overview 27.6 -> 9.6 ms.
+- Switching plates no longer recolours every plate or builds the focused plate's G-code Blob (332-574 ms -> no task
+  over 50 ms). "Export G-code" builds its plain `.gcode` on click and hands it to the host's `onExport` like the other
+  exports; it used to be a prefilled download link that bypassed `onExport`.
+- A 3mf loads with each part inflated by `DecompressionStream`, read from its bytes and baked (normals, bounds) in
+  the parse worker, with the build items spread over copies of that worker: 1338-1352 -> 367-372 ms on a 52 MB
+  project, with the same meshes. zip64 and encrypted archives keep the previous reader.
+
+### Fixed
+
+- A click on a plate in Preview did nothing; it now selects the plate.
+- Tree support could lose a whole support island's paths on a layer: reordering a layer's paths dropped any group of
+  paths whose first or last member was empty, with every path in it (a 3M-facet tree-slim model lost 64.6 mm of
+  support paths over three layers). Only the empty members are dropped now. Models where it did not happen slice to
+  the same G-code.
+- Tree slim, strong and hybrid crashed the kernel on any model.
+- The same tree slim or strong input could slice to different G-code from run to run (a tie in the minimum spanning
+  tree was broken by memory address).
+- A Bambu Lab X2D or H2D project failed every slice with `CUSTOM_GCODE_ERROR`: the start G-code reads
+  `first_filaments` and `first_non_support_filaments` per physical nozzle, which were missing or not mapped.
+- A plate whose objects are all on one filament other than the first printed with filament 1: the start G-code
+  loaded it (`M620 S0A` on a Bambu Lab printer) and its temperature, flow and retraction were used. The kernel
+  takes `single_tool`, which the viewer sends for such a plate, and prints with that filament's values; the
+  start and end G-code see it as `initial_extruder` / `current_extruder` and the footer reports its use.
+
 ## 0.3.2 — 2026-09-21
 
 ### Added

package/README.md

@@ -679,6 +679,11 @@ Cross-Origin-Embedder-Policy: require-corp
 
 Without those headers, the engine falls back to the single-threaded kernel.
 
+The multithreaded kernel's wasm is a file beside its glue, `engine/src/slicer_core.mt.wasm`, reached through
+`new URL('slicer_core.mt.wasm', import.meta.url)`; Vite and webpack emit it as an asset. Serve it as
+`application/wasm`, and from another origin (a CDN) with `Cross-Origin-Resource-Policy: cross-origin`, or the
+cross-origin isolated page cannot load it. The single-threaded kernel still inlines its wasm.
+
 ## Data Files
 
 The package includes extracted OrcaSlicer metadata for custom interfaces:
@@ -737,6 +742,7 @@ the layout by hand.
 | `printerSettings(name)` | Settings a vendor machine profile applies |
 | `printerKeys` | Every key a printer profile can set — clear these before applying another |
 | `printerDefaultPreset(name)` | The vendor's recommended process preset for that printer |
+| `printerDefaultBedType(name)` | The bed type the printer's model defaults to — the viewer writes it to `curr_bed_type` on a pick |
 | `machineLimitKeys` | The schema keys the kernel's machine limits are read from |
 | `processPresets()` | Lazy facade over the print (process) preset catalog |
 | `filamentPresets()` | Lazy facade over the material preset catalog |