The app exported 3MF but only read STL (accept=".stl", STLLoader the only
loader in the tree), so anyone modelling in Fusion, Bambu Studio or
FreeCAD had to re-export first -- backwards, since 3MF states its units.
zip.js gains a reader. We emit STORE but real 3MFs are DEFLATE, so
inflate comes from DecompressionStream, which Deno has too, letting the
tests exercise the browser's path. ZIP64 is handled: writers enable it
regardless of size, and its extra field holds only the fields that
overflowed, so assuming all three mis-parses the offset-only case.
threemf.js gains readThreeMF(). Three things make it work on a real file
rather than only on our own export:
- UNITS: the unit attribute is authoritative and not always millimetre;
everything downstream is mm.
- TRANSFORMS: <build><item> and <component> matrices compose with the
object's own, or the part imports offset from the plate.
- MULTIPLE BODIES: a plate can hold several and this tool fins one, so
they are merged and the status rail says so, along with any unit
conversion and any support body left out.
Parsed with a tag scanner, not DOMParser: the tests run outside a browser,
and a scanner cannot resolve an external entity from a stranger's file.
Objects typed support, surface or other are skipped -- not closed bodies,
and they would poison the overhang analysis.
app.js sniffs the ZIP magic, not the extension, so a renamed file still
parses. The reader returns the same flat array STLLoader does, in mm, so
setPart and the engine are untouched.
tests/threemf.test.js covers the round trip, units, composed transforms,
DEFLATE, both ZIP64 shapes, support exclusion, and malformed packages. A
3MF-sourced part analyses identically to the same part loaded as STL.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
