Bundling threejs project with DRACOLoader (webworker)

TejaSwaroopArukoti · July 18, 2020, 8:53am

I am trying to bundle my threejs project which uses DRACOLoader file. It creates web-worker in runtime with BLOB url. I tried webpack / rollup to give options to worker loader.

https://webpack.js.org/loaders/worker-loader/.

But no use. It worker is in separate file, it becomes easy to give options. Why is it DRACOLoader uses runtime approach to create worker? and How shall i bundle it?

donmccurdy · July 18, 2020, 4:54pm

Is your entire application running in a Web Worker? Or could you explain what you’re trying to do with webpack’s worker-loader?

DRACOLoader creates its own Web Workers so that decoding does not block the main thread. It may start multiple workers, to decode parts of a model in parallel. It’s fully compatible with bundlers, but I don’t know whether DRACOLoader itself can run inside of a Web Worker — it may not have all the Browser APIs it needs, e.g. to start other Web Workers, in that location.

TejaSwaroopArukoti · July 19, 2020, 6:06am

I am not looking to run DRACOLoader in another worker.
I am just looking to bundle DRACOLoader and other js files.
I am able to bundle all other js files and am able to run successfully.

But, When I am bundling DRACOLoader with webpack, I am able to generate minified file but browser is not able to recognize the worker.

For webpack to recognize the worker, I am using the below loader.
https://webpack.js.org/loaders/worker-loader/.

But it requires static .js file. In DRACOLoader, worker gets created runtime with BLOB url. I am not able to figure out how to give this option to webpack.

donmccurdy · July 19, 2020, 6:20am

The decoder path given to DRACOLoader needs to have statically hosted files - they cannot be bundled.

If you’re having trouble getting this to build you will need to share enough code to reproduce the issue you are having and the errors you see.

drcmda · July 19, 2020, 8:42am

like @donmccurdy said, you dont bundle draco. bundlers give you a /public folder, it contains files and folders that you intent to ship statically. draco has to be in that folder. your gltf’s as well, unless you import them from the src folder, in which case the bundler adds them to the dist and gives you a url hash.

here’s a running example, it’s react but just look into /public, you’d do the same in plain three. https://codesandbox.io/s/r3f-ibl-envmap-simple-y541h

personally, instead of fetch requests i would also prefer imports or dynamic imports, including the loaders. then it wouldn’t be browser dependent but cross platform. but that’s just how it is.

Anish_Kumar · February 23, 2024, 6:49am

hey @TejaSwaroopArukoti , did you found any solution for this, I am facing the same issue.

Anish_Kumar · February 23, 2024, 7:05am

@drcmda I bundling my threejs project in the same way that you mentioned above, although I am not using worker loader right now. While making the build I am successfully able to make it but while running the build I am facing some error due to the draco loader, below are the details

Here is my build folder, In which ‘draco’ is in static directory

Here I am setting up the draco loader:

Here Is the error I am facing while running ‘index.html’ file from build file (or dist)

While running the project on webpack dev server it is running perfectly, but while running build file it is giving some “draco loader” issue.

Thanks

drcmda · February 23, 2024, 7:53am

you don’t need workerloader, draco creates a worker by code, this has nothing to do with the bundler.

but, why is /static in your /dist? this is unusual. the bundlers job is to copy the contents of the /public folder into the /dist order, but not the folder itself. please use vite if you’re using anything else. “npx create vite” will create a proper project structure for you with a public folder, copy the draco bins in there.

“./static/draco” is a local path, depending from where you call it it can fail. the absolute path would be “/static/draco”.

but ideally, if the bundler is set up corretcly, “./static/draco” should just be “/draco”. this is how it would be in vite.

alternatively,

const drac = new DRACOLoader()
const gltf = new GLTFLoader()
drac.setDecoderPath("https://www.gstatic.com/draco/versioned/decoders/1.5.5/")
gltf.setDRACOLoader(drac)

Anish_Kumar · February 23, 2024, 8:37am

Hey @drcmda thanks for your response,

I am using webpack as a module bunder for my project and and there is a static folder in my root directory which behaves same as public folder in vite, so while making the build, webpack copies the static files from static folder present in root directory and copies it into the build static folder. So it is same like public folder in vite.
And for some personal reasons I don’t want to use vite for this project.

And I have cross checked the paths also, there is no issue with paths for draco.

But let say, there is some issue with file structuring and storing the ‘draco’ in static folder. But these issue should not come if i am using cdn link for draco right ? Like given below

        this.dracoLoader = new DRACOLoader();

		// Setup Draco Loader
        this.dracoLoader.setDecoderPath("https://www.gstatic.com/draco/versioned/decoders/1.5.5/");
		this.gltfLoader.setDRACOLoader( this.dracoLoader );

But while running the build ‘index.html’ file it is giving the same issue as I mentioned above.
I think It is due to some web worker issue for draco loader.

Let me know what you think about this

Thanks

drcmda · February 23, 2024, 10:06am

js opening up a worker is all but common: URL.createObjectURL(new Blob([functionString])). the bundler doesn’t get involved. worker-loader exists so that you can have external workers as js modules which can import packages. this isn’t what DRACOLoader is using.

the crash seems to be here (inside the worker) which indicates that it didn’t insert the draco stuff, which probably means it’s not able to fetch/resolve the correct binaries.

the cdn link has to work, please also make sure you have latest threejs.

And for some personal reasons I don’t want to use vite for this project.

you’re most likely fighting against this bundler and the rules it has regarding static files. i wouldn’t know how to help. you normally have /public, drop /draco in there, address it as “/draco” and that’s it.

donmccurdy · February 23, 2024, 3:18pm

Upvotes and kindly-explained use cases on this feature request would be welcome, I think:

github.com/google/draco

Modernizing Draco package - ES modules and unifying NodeJS/Browser builds.

opened 04:34AM - 16 Feb 23 UTC

bhouston

Hi, I'm a user of the draco3d library for glTF encoding/decoding - I am also …a contributor to the glTF standards. It is quite challenging to use this library in its current form. A few combined issues make it quite challenging: - The npm packages only supports node.js operation and has hard coded dependences on NodeJS-specific fs and path libraries as well as relying on __dirname, which isn't available in ES modules. - The npm packages rely upon CommonJS rather than more modern ES modules, thus you need to use old school bundlers. - The browser version of the library isn't in any npm package, thus you have to copy it manually into projects. - The browser version of the library also doesn't have typings (e.g. @types/draco is only for the node.js-specific npm module.) Together this makes this library super old-school and a pain to use, even though it has awesome functionality. The best way forward would be to: - update the npm package so that the decoder/encoder is not dependent upon either the browser or Node.JS, rather it is independent and just operates on ArrayBuffers. - the npm package should be published in at minimum ES module format, and I guess you can keep the CommonJS. Use the "module" and "main" fields of the "package.json" respectively for this dual publishing method. - There is a function on the main wrapper in which you can pass in the WASM file. So you can load it differently depending on the platform, but once loaded you initialize it into the library the same way. Relying upon primarily the emscripten version would allow one to just package this up so that anyone can use it. Trying to load the WASM module makes things a lot more complex because import support for WASM nor bundler support for WASM is here yet. This would allow something like this in Node.js: ```js import { createDecodeModule } from 'draco3d'; import { fs } from 'node:fs' const wasmBuffer = fs.readFileSync('/path/to/add.wasm'); createDecodeModule( wasm: wasmBuffer ); ``` And this code in the browser: ```js import { createDecodeModule } from 'draco3d'; const wasmBuffer = await fetch( '/path/to/add.wasm'); createDecodeModule( wasm: wasmBuffer ); ``` And both scenarios would share the same typing and the same ES module. I know the is a big ask so it probably won't happen, but I figured I'd share a way forward that seems reasonable. Thanks for your attention.

Not their fault that packaging WASM is quite difficult today, but I think they’re leaning on the CDN distribution method a bit too much.

Anish_Kumar · February 25, 2024, 10:59am

Hey Hii @drcmda

I am not able to figure out what is the issue, I don’t know what I am missing.

Also its difficult to understand the issue for you also without any reference, therefore I have created a git repository which can help you to reproduce the error.
Here’s the Repository Link to reproduce the error, I also added error description and steps to reproduce the error in the readme. Let me know If am missed something.

Try it, and let me know where I am lacking.

Thanks!

drcmda · February 25, 2024, 12:50pm

this.loadGltfByUrl('../static/Fox-draco.gltf')

this is imo not a valid url. requests should be absolute, relative urls are for imports. in any normal setup it’s just “Fox-draco.gltf”, if you have configured webpack to handle this differently it brings us to another thing …

*.gltf refers to external files whose paths must be obvious to the loader. in your case the gltf for instance refers to “Fox-draco.bin”, so again, it will url-fetch “Fox-draco.bin”, not “/static/Fox-draco.bin” and surely not “…/static/Fox-draco.bin”. if your project is set up weird these fetches will fail, it has likely nothing to do with web workers it just can’t find the buffers and textures.

there is a method on the loader where you can set the root path, but i would suggest webpack is fixed instead. it is not normal that you address /static, the contents of /static should be copied into /dist
if you use a *.glb instead of a *.gltf, then it contains everything in one, with or without draco. less room for errors.

Anish_Kumar · February 26, 2024, 6:48pm

@drcmda
I am looking into the project structure I have setup with webpack, I will correct it the things If wrong.

But the issue is not coming only for the gltf (having bin file) but also for glb and single gltf (without bin file) also. The problem is only occurring for the models which are compressed with draco (inside blender) weather it is gltf(embedded texture), gltf (with bin) or glb.
Also I am fetching the draco from cdn link and in the devtools network panel I am able to see that draco and their wasm files are getting fetched.

One more thing I wanna mention that, I am uisng webpack obfuscator in the webpack, so today I was testing and I found that when I disable the webpack obfuscator and make build without any obfuscation it is running correctly without any draco issue, but when I make build with webpack obfuscation enabled then it is giving error.

It will be better If you will run and reproduce the error inside your machine from the repo (link) I have provided and try to experiment the things.

Thanks!

Hudson_Spangler · May 19, 2024, 8:22am

Hey @Anish_Kumar I am experiencing the same error, only when obfuscated.

Additional details I have found are:
I have had this working before. It seems with a previous version of dracodecoder which is not created from blob, like this:

At this point, I’m considering incrementally rolling back my “@react-three/drei” until something works.

Any luck further debugging this on your end?

*Edit
I got it to work by obfuscating only my src files. To do this, I used react-app-rewire to expose React’s webpack config, then using the JavaScript-Obfuscator web pack loader (not the plugin) and including only my src directory.

I’m still trying to figure out how to get source maps to point back to unobfuscated typescript, but this resolved the error in the service worker.

Incidentally, by not including the node_modules imports in the obfuscation, my bundle size shrank from 2700kb to 400kb.

Topic		Replies	Views
Draco decoder visible name in WORKER Discussion draco_decoder , draco-loader	0	22	November 1, 2024
How to use DRACOLoader with GLTFLoader with bare module imports? Questions modules	24	6142	July 7, 2023
DRACOLoader object URL not disposed Discussion memory-leak , draco-loader	6	598	April 26, 2023
Draco loader configuration options Questions loaders	16	2373	October 27, 2021
Any way to use DracoLoader without going back to HTML import tags? Questions draco	3	953	June 15, 2019

Bundling threejs project with DRACOLoader (webworker)

Related topics