re: meshopt. I guess we can include if it doesn't have any overhead like the draco decoder

I see some tests failing

the test failing doesn't seem to be related to committed code, instead firefox not launching. I'll try closing / reopening to retrigger the test

If no overhead we can also include meshoptDecoderPath

Yes, looks like https://unpkg.com/meshoptimizer@0.18.0/meshopt_decoder.js is the latest version and best URL? Will use that unless you or Don have other suggestions.

When including meshoptDecoderPath in gltf-model system there are a few failed tests. I doubt these tests had any meshopt models, so I'm guessing meshopt does not lazy load in order to affect tests?

I'm not sure how to fix. I would suggest to revert this to include default path for draco only unless @dmarcos or @donmccurdy you have any additional insight.

FAILED TESTS:
✖ "after each" hook for "does not emit trackpadmove on axismove with no changes"
Chrome 107.0.0.0 (Mac OS 10.15.7)
RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance

gltf-model
✖ attaches animation clips to model
Firefox 107.0 (Mac OS 10.15)
Timeout of 3000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

✖ "after each" hook for "attaches animation clips to model"
Firefox 107.0 (Mac OS 10.15)
self.loader.setMeshoptDecoder is not a function
./src/components/gltf-model.js/init/this.ready<@build/commons.js:13907:21

I have reverted these changes. It looks like loading meshopt has side effects. Unlike draco loader, meshopt is loaded upon system init by injecting a script element in the document.

including meshopt as default should probably be tackled as a separate issue

I have reverted these changes. It looks like loading meshopt has side effects. Unlike draco loader, meshopt is loaded upon system init by injecting a script element in the document.

including meshopt as default should probably be tackled as a separate issue

Yeah. I agree thanks so much!