Three.js: DRACOLoader: Decoding should happen in a Web Worker.

Created on 21 Mar 2018 · 12Comments · Source: mrdoob/three.js

Decoding Draco geometries is a long, blocking task, and shouldn't be happening on the main thread. I'm hoping that with some of the LoaderSupport APIs we should be able to configure it to run just as easily in a web worker as not. Proposed API:

THREE.DRACOLoader.setDecoderPath('path/to/decoders/');

// Main thread
var loader1 = new THREE.DRACOLoader()
  // .setParser(new THREE.DRACOLoader.Parser()) // OPTIONAL
  .load('foo.drc',  () => {...});

// Web worker
var loader2 = new THREE.DRACOLoader()
  .setParser(new THREE.DRACOLoader.WWParser())
  .load('foo.drc', () => {...});

// GLTFLoader + WW
var dracoLoader = new THREE.DRACOLoader()
  .setParser(new THREE.DRACOLoader.WWParser());
var gltfLoader = new THREE.GLTFLoader()
  .setDRACOLoader(dracoLoader)
  .load('foo.gltf', () => {...});

The distinction between Loader and Parser exists because the Parser cannot know about any THREE.* types, to minimize dependencies in the WW.

/cc @takahirox @kaisalmen

Aside — In a perfect world the WASM Draco decoder would use threading, but WASM doesn't support that yet, and the decoder would need changes if it did, so using a web worker seems like the place to start.

Loaders Suggestion

Source

donmccurdy

👍2

Most helpful comment

Perhaps the author (Matt Greenhalgh, Stink Studios - ping @mattg73) is able to share their implementation with the community as mentioned in their new technical case study: https://medium.com/@stinkstudios/creating-qalam-d016a0a52d56

Our solution was to move the decompression task off the main thread using Web Workers. We had to modify the THREE.js Draco decoder to support this bespoke functionality. Our change stopped the main thread from being blocked during decompression but we instantly hit against another problem: the decompressed buffer sat in a different thread from the main thread that required it. Copying this data between threads created an even bigger lock-up while the large amount of data was transferred. We solved this problem by implementing a Transferable Objects solution that changes the buffer owner by pointer reference rather than moving the data between threads.

TimvanScherpenzeel on 25 Jun 2018

👍3

All 12 comments

Decoding Draco geometries is a long, blocking task, and shouldn't be happening on the main thread.

Agreed.

About the proposed API, what's the purpose of exporting .setParser()? new THREE.DRACOLoader( { worker: true } ) isn't good? (I'm not familiar with neither DRACOLoader nor LoaderSupport yet.)

takahirox on 21 Mar 2018

That would be fine, too. There may be need for a Parser subclass to isolate code for three.js-independent tasks, but it doesn't need to be exposed to the user necessarily.

donmccurdy on 21 Mar 2018

Content has been moved to own issue: https://github.com/mrdoob/three.js/issues/13664

Ideas are similar to yours. Let me know what you think.

kaisalmen on 21 Mar 2018

@takahirox and @donmccurdy I have moved the ideas related to WorkerLoader to an isolated issue (see above). Sorry for hijacking this issue.

Do you need volunteers for a DRACOLoader utilizing Workers and if when do you need it?

kaisalmen on 22 Mar 2018

No concern about hijacking it's all very related. 😅

I've been wanting to try DRACOLoader + workers for a while still haven't gotten started... if you're interested and find time please do! No time constraint.

donmccurdy on 22 Mar 2018

👍3

Need to work on WorkerLoader/OBJLoader2 first, but having a real use-case apart from PCDLoader for proving the overall concept seems tempting, but it will not happen next week 😉

kaisalmen on 22 Mar 2018

Our solution was to move the decompression task off the main thread using Web Workers. We had to modify the THREE.js Draco decoder to support this bespoke functionality. Our change stopped the main thread from being blocked during decompression but we instantly hit against another problem: the decompressed buffer sat in a different thread from the main thread that required it. Copying this data between threads created an even bigger lock-up while the large amount of data was transferred. We solved this problem by implementing a Transferable Objects solution that changes the buffer owner by pointer reference rather than moving the data between threads.

TimvanScherpenzeel on 25 Jun 2018

👍3

@mattg73 There was some discussion about using workers in loaders in the past and it would be very helpful to understand how you solve this problem. Any chances you make a PR so we can evaluate your approach?

Mugen87 on 27 Jun 2018

FYI: https://github.com/mrdoob/three.js/pull/15249

donmccurdy on 15 Nov 2018

Fixed at https://github.com/mrdoob/three.js/pull/15249. :)

donmccurdy on 26 Aug 2019

🎉1

very nice! Thank you!

On Mon, Aug 26, 2019, 13:10 Don McCurdy notifications@github.com wrote:

Closed #13648 https://github.com/mrdoob/three.js/issues/13648.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mrdoob/three.js/issues/13648?email_source=notifications&email_token=AAKFINUVAGR7MF7KWAKFP5TQGQ2DPA5CNFSM4EWL7OWKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTII3IHA#event-2584851484,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKFINRIR3EVUZKYF6QDPBDQGQ2DPANCNFSM4EWL7OWA
.

ncoder on 27 Aug 2019

I'm really sorry I came across this issue a bit late, I did write the webworker decoder for the qalam project for @mattg73 you guys were talking about earlier. I had issues without older browsers ( ie ) in which some math functions used in the draco decoder were not defined.
I had to re-inject them all at the beginning of the decoder.

I can have a look back at this very soon