How to use DRACOLoader with GLTFLoader with bare module imports?

Questions
21

Developers can pass whatever they want into the gltfLoader.setDRACOLoader( ... ) method. You don’t have to use the decoder provided in the three.js repo. But as the three.js repo already has four (!) draco decoders (vanilla JS, vanilla WASM, glTF JS, glTF WASM) I’m not excited about adding a 5th that is the same, 50kb bigger, and with a different installation process. I think it muddies the water further.

22

@donmccurdy

Makes sense – I didn’t realize different loaders were needed for GLTF and regular Draco. Well hopefully WASM gets less complicated to deal with in the not so distant future.

Thanks for your time!

1 Like
23

@donmccurdy

A bit tangential to the conversation about WASM now but my PR (admittedly they changed it a lot to get it in shape :slight_smile: ) into WebPack for proper dynamic import resolution was merged. It won’t work in IE but should work in modern browsers so dynamic imports will “just work” there, as well. Progress!

1 Like
24

Hi!

We use the Parcel bundler a ton and it’s a challenge to tell Parcel about the necessary js and wasm dependencies for the DRACOLoader. Parcel will typcially rename dependencies is knows about for caching reasons, so even if it knows which assets are necessary during build the actual runtime URL for them may be different to original filenames. For this reason, an optional callback function on the DRACOLoader that is called, at runtime, with a given dependency’s filename and expects the resolved URL to be returned would be ideal. This pattern is used in some other projects, such as Emscripten itself.

An example of how this could work is as follows:

const loader = new DRACOLoader();
loader.resolveDependency = (filename: string) => {
    switch(filename) {
        case 'draco_decoder.wasm': return new URL('./node_modules/three/examples/jsm/lib/draco/draco_decoder.wasm', import.meta.url).toString();
        // etc
    }
};

In this case the new URL(..., import.meta.url) construction is automatically detected by Parcel, ensuring the asset is included in the final bundle and that the return from the function is the correct final URL for the asset (the Parcel docs for this feature are here). The same mechanism is also supported by Webpack.

This would be super useful for us - and we’d love to contribute a pull request that would add this option if it would be welcome :slight_smile:. Note that we’d maintain the existing behavior if the user doesn’t set a function to resolveDependency.

Thank you!

25

that’s exactly how tensorflow people distribute their stuff, sometimes you dont even have an option to change those urls short of editing their code :sob: