Repro: https://codesandbox.io/s/elegant-villani-9d3hr?file=/src/index.js
import { TiltLoader } from "three/examples/jsm/loaders/TiltLoader"
new TiltLoader().load("/model.tilt", (scene) => console.log(scene))
This is the error message in a local env (Parcel):
TiltLoader.js:42 TypeError: _jszipModuleMin.JSZip is not a constructor
at TiltLoader.parse (TiltLoader.js:59)
at Object.onLoad (TiltLoader.js:32)
at XMLHttpRequest.<anonymous> (three.module.js:36749)
Hi, author of fflate here! The reason the async version exists in JSZip is beyond me, since it doesn’t actually offload the processing to other threads. On the other hand, if the assets in the ZIP are reasonably large (around 500kB), fflate will use worker threads to compress/decompress them faster.
However, I looked at some of the demos using JSZip and they don’t seem to load that much data, so using the synchronous unzipping algorithm would be no different to the async version. You could even replace
gunzip.js
, which is used by the NRRD loader, withfflate
because gunzip and unzip use the same core algorithm.Since it seems the ThreeJS team wants minified ES6 module scripts, I’ve hand-tuned a minified version of the library and pasted it below. It’s 4.4kB (2.2kB gzipped) and supports synchronous ZIP decompression (through the exported
unzipSync
method) and GZIP decompression (throughgunzipSync
).Usage:
Minified code (to put in
fflate.module.min.js
):You have the spec, and you have reality. V8 and Gecko use a 64 bit unsigned integer to store the size of typed arrays, which means a theoretical max of a lot, but they both cap the actual size at 231 on all devices I’ve tested. Node caps it at 232. No Zip64 data is strictly necessary while still being possible in JavaScript.
I understand that Zip64 is important, so I’ll add support for it. However, this might be a few days of work since it’s a much more messy specification.
My bad, updated the code in my most recent comment. I had forgotten to switch the CommonJS exports to ESM. UMD build should already be live on jsDelivr, I believe, but you could probably wrap the minified code to make the UMD build smaller too.
On looking again at the source code here, it seems that a lot of compression libraries could be replaced by a single one, which is probably better to avoid fragmentation…Will create a more complete minified copy soon and create a PR.
EDIT: Here are my (semi) final revisions for the versions:
fflate.min.js
(replacesgunzip.js
,inflate.js
,jszip.js
):Great! I’ve completed my first PR to migrate loaders from JSZip.js and gunzip.js to fflate.
I change inflate to fflate in a separate PR when the first one was merged.
I’m not exactly sure what the
resize
option does, but it seems like an optimization more than anything. I checked its usage in the source code and it seems to change basically nothing; the only difference is allocating a new array of length LEN and copying bytes 0 to LEN into the new array vs. taking the subarray from 0 to LEN directly. If anything, the O(n) allocation + copy would be slower…I actually took a closer look and found this comment that indicates that it’s a memory optimization. This is applied by default in
fflate
because if it weren’t, memory would be about 2x worse.I added the ZIP function into
fflateDeflate
.fflate-deflate.min.js
:yep, still plan on finalizing the exporter. I had already taken a note to update current deflate to fflate’s deflate, but thanks for the heads up👍