Model loading · function
prepareZipInflate
The same trick for a zip, which is how a .3mf and a bought archive both arrive.
Explained in Importing models.
function prepareZipInflate(buffer: ArrayBuffer, inflate: AsyncInflate): Promise<Inflate>import { prepareZipInflate } from '@driftengine/assets';Parameters
| Parameter | Type | Description |
|---|---|---|
buffer | ArrayBuffer | |
inflate | AsyncInflate |
In depth
Promoted from a consumer's private copy. Every piece needed to open an archive was already
exported — readZip, readerFor, MODEL_FORMATS, assetCandidates, ModelSource.beside — and
a second consumer still spent about sixty lines assembling them, most of it rediscovering this
function. The engine's own model worker had implemented it privately for .3mf at the same time,
which is two copies of one idea and the point at which it belongs here.
A zip stores raw deflate and FBX stores zlib-wrapped, so this takes its own decompressor and
is deliberately a separate name from prepareFbxInflate. Passing either where the other belongs
fails on the first bytes, which is the good kind of mistake.
Two passes for the same reason: readZip expands each entry as it walks and the only
decompressor a browser has is asynchronous, so entries are recorded first and answered second.
Spans are keyed by byteOffset, which identifies them exactly, since each payload is a subarray
of the one buffer being read.