Unsafe to reuse a Decoder instance

[donmccurdy]

My code was throwing this error on glTF models containing multiple mesh primitives compressed with Draco:

RuntimeError: memory access out of bounds
    at wasm-function[79]:226
    at wasm-function[76]:207
    at wasm-function[314]:48
    at wasm-function[313]:439
    at wasm-function[312]:893
    at wasm-function[186]:303
    at wasm-function[346]:20
    at wasm-function[460]:7
    at k.DecodeBufferToMesh.k.DecodeBufferToMesh (/Users/donmccurdy/Projects/glTF-Transform/node_modules/draco3dgltf/draco_decoder_gltf_nodejs.js:128:54)
    at T (/Users/donmccurdy/Projects/glTF-Transform/packages/extensions/dist/extensions.js:1:2157

After changing my code to create a new Decoder instance for each mesh, the error was resolved. I didn't pick up on that from the JS API docs; I'd assumed that DecoderBuffer instances had to be created for each mesh, given the different Init() data, but didn't make the same assumption for Decoders.

It took me a while to discover the error, since it only affected some models, and the solution wasn't obvious once I found it. Might be worth more specific error or documentation here, if possible, but either way I thought I'd write this up in case someone else hits the same issue.

[duncan-vrify]

@donmccurdy I'm running into a similar issue using threejs and trying to load models on mobile browsers, do you think you could elaborate on how you created a new Decoder instance per mesh? I seem to run into this error and my application hard crashes during the .load call on my model so I'm not sure where I would go about creating a new instance for each mesh

Also from the threejs docs, it states

When using Draco with glTF, an instance of DRACOLoader will be used internally by GLTFLoader.

It is recommended to create one DRACOLoader instance and reuse it to avoid loading and creating multiple decoder instances.

Is that to be ignored in this case?

[donmccurdy]

If you're using three.js, you shouldn't have to worry about this — one THREE.DRACOLoader instance will automatically create however many Draco WASM decoder instances it needs to decode the model.

Are you only getting these hard crashes on mobile browsers? I'm not sure what to make of that, but the three.js forums would probably be the best place to start debugging: https://discourse.threejs.org/

[duncan-vrify]

Yeah, strictly on mobile browsers. The exact same models that fail on mobile browsers seem to render fine on my computer and it seems to only happen with some models.

But yeah, I'll head over there and make a post. Thanks!

[looeee]

Hitting this issue as well - or at least, I'm getting the same error message intermittently on mobile.

@duncan-vrify is this your post on Discourse?

https://discourse.threejs.org/t/wasm-memory-access-out-of-bounds-using-dracoloader-on-mobile-browsers/22930

[duncant3]

Hitting this issue as well - or at least, I'm getting the same error message intermittently on mobile.

@duncan-vrify is this your post on Discourse?

https://discourse.threejs.org/t/wasm-memory-access-out-of-bounds-using-dracoloader-on-mobile-browsers/22930

Yeah @looeee, that was my post.

We ended up having to alter the model itself because a particular node had like thousands of geometries associated with it so I'd say maybe double check the model?

edit: Sorry just realized I responded from a different GitHub account but both are me, haha

[looeee]

We ended up having to alter the model itself because a particular node had like thousands of geometries associated with it so I'd say maybe double check the model?

In this case the model has just 4 geometries, ~300k tris total, and it's 7mb uncompressed. I did some more testing and found out that it's only when I use gltf-transform draco to compress that I get this error - see the discourse post for more info.

In the end I went with gltfpack -cc which quantizes the model. This gave me a final file size of 2.1mb vs 1.1mb draco, which is good enough.

[donmccurdy]

@looeee one other idea that might be worth a try – if you have a script using glTF-Transform for the compressor here, try replacing the draco3d package with draco3dgltf? The CLI is using the latter, but some of my examples might have used the former; I'm not really sure what the differences are (https://github.com/google/draco/issues/717).

[looeee]

Thanks. In this case I was just using the CLI but if I come across this again I'll try that out.