I’m currently running into an issue where I’m trying to load a Draco compressed model using the Draco Loader on mobile browsers and it seems to hard crash during the call to the .load method. iOS Safari not and Chrome version 88.0.4324.93 on an Android - Pixel 2 XL are the ones I’ve tested so far. The exact same models seem to render completely fine on web browsers with no issues.
This the error I’m receiving
RuntimeError: memory access out of bounds
at <anonymous>:wasm-function[377]:0x18a28
at <anonymous>:wasm-function[358]:0x170b9
at <anonymous>:wasm-function[354]:0x16f17
at <anonymous>:wasm-function[446]:0x21f40
at <anonymous>:wasm-function[323]:0x1371f
at <anonymous>:wasm-function[23]:0x2cb1
at emscripten_bind_Decoder_DecodeBufferToMesh_2 (<anonymous>:wasm-function[119]:0x934e)
at a._emscripten_bind_Decoder_DecodeBufferToMesh_2 (blob:https://bdd35c37d00a.ngrok.io/95a82b20-81cc-451e-a630-f47694de7a0f:51:560)
at g.DecodeBufferToMesh.g.DecodeBufferToMesh (blob:https://bdd35c37d00a.ngrok.io/95a82b20-81cc-451e-a630-f47694de7a0f:92:54)
at decodeGeometry (blob:https://bdd35c37d00a.ngrok.io/95a82b20-81cc-451e-a630-f47694de7a0f:189:29)
I’ve tried adding console logs to the onProgress, onLoad, and onError callbacks. The onProgress seems to fully complete but after that, before the onLoad callback can run, it crashes and the onError callback isn’t called either.
Anyone have any ideas on how to go about solving this? Any help would be much appreciated.
I thought this might be an issue as well but the model itself is only about 100 mb. The JS heap snapshot is ~363 mb after loading on web and the snapshot on my mobile device using the chrome debugger is 193 mb (but probably lower because the model doesn’t fully load is my guess)
Sorry, I was actually misinformed. The draco size after compression is 50.9MB. And yes I can share the model. Did you want a link to the implementation or the model itself?
The models seem to work completely fine in those examples.
Draco compression rates can be as good as 95%… if the 50MB is expanding to 50 / .05 = 1000MB during decompression then you may just be running out of memory on these devices. If that’s the issue then you may need to simplify the models before compressing them, or there are other types of compression you could try.
This is the implementation [redacted] and this is the model itself [redacted]
Ohhhh, that’s really interesting. This is probably going to be a stupid question but in terms of the file size, when I take the heap snapshot in the Memory tab of the Chrome DevTools, does the size of the uncompressed model not get reflected there? Like for example, in the first link, after the model loads, and I take the heap snapshot, the size is 363 mb so would that be enough to cause the device to run out of memory?
Note that both Draco geometry and PNG/JPG textures have to be decompressed when rendering to the GPU. The full size of the textures and geometry, after decompression, in this scene is about 930 MB. That’s roughly 190 MB of geometry and 740 MB of textures. Some of the textures have dimensions like 5819 x 4480px, which is too large for many mobile devices. I would not expect mobile devices to support anything larger than 4096px, and ideally avoid using more than 2048px.
I can’t tell you exactly which of these things is causing the crash you’re seeing, but generally it does seem like this model will need to be simplified, by an artist or with software like Blender or RapidCompact.
Here are the textures’ stats, produced with gltf-transform inspect model.glb:
That is unbelievably helpful. Thank you so much, I’m definitely going to take a look at reducing the size of some of these models and will look into implementing gltf-transform to be able to get a breakdown like this for future issues.
However, I seemed to briefly get this error instead of the old one
blob:https://dev.vrify.com/d96ae97a-72fb-422a-8201-5b2dff8ee537:124 Error: THREE.DRACOLoader: Decoding failed:
at blob:https://dev.vrify.com/d96ae97a-72fb-422a-8201-5b2dff8ee537:124
at blob:https://dev.vrify.com/d96ae97a-72fb-422a-8201-5b2dff8ee537:124
(anonymous) @ blob:https://dev.vrify.com/d96ae97a-72fb-422a-8201-5b2dff8ee537:124
9544:1 Uncaught (in promise) Object
But since then, I’ve continued to receive the old error about the memory access being out of bounds. Does this mean that the model’s textures are still too big or does the new error indicate something could be going wrong during the creation of the model/draco compression of the model? (I’m in the process of going about implementing the gltf-transform but just a bit slow)
Thanks again for any help/input you can provide.
edit:
I think I figured out the issue. One of the geometry’s in the model was gigantic and was causing problems when it was being uncompressed. I created a version of the model with only that material + another, leaving the draco model at 21MB and it still failed and upon further investigation, it was just way too detailed so we’ll look to reducing the complexity/size of it. Thanks for the help everyone!
Could you please explain why you divide by 4?
Doc says:
- maxTextureSize: The value of **gl.MAX_TEXTURE_SIZE** . Maximum height * width of a texture that a shader use.
This leads me to think you need a square root. So for example my pc gives me renderer.capabilities.maxTextureSize = 16384. Does that mean the texture should be smaller than 128x128?
I seem to be hitting this issue as well on mobile. The scene loads about 80% of the time, but 20% I get this error message. I’m loading three small glb files. After compression they are about 2mb total, before compression about 25mb.
That comment was referring to the Draco decoder implementation in glTF-Transform, which can be found here:
I haven’t modified THREE.DRACOLoader recently, but it seems to do the same:
… so I don’t think the error you’re seeing is likely to be exactly the same thing. I’d be curious if the error becomes more common with higher or lower parallelism? For example, calling dracoLoader.setWorkerLimit(1) or dracoLoader.setWorkerLimit(1000). That might indicate something or other. It’s also possible to compile debug builds of Draco which may have better error messages.
I’ve tracked this down to one of the four files I’m loading. The error only occurs when I load the draco version of the file, even when I’m loading other draco compressed files.
The file is called buildings.glb. It’s 7.8mb uncompressed, 1.07mb compressed. It’s originally an FBX file that I exported from Max then converted with FBX2GLTF.
It only causes this error when I used gltf-transform to compress the file. If I use FBX2GLTF to directly output draco compressed .glb, it’s fine, and if I use gltf-pipeline to compress it, it’s also fine:
EDIT: just realised gltf-pipeline messes up the UVs so that’s not an option either.
When I set worker limit to 1, I get the same error. When I set it to 1000, I get Uncaught (in promise) RangeError: WebAssembly.Memory(): could not allocate memory repeated many times.
If you like, I can share the file privately with you.
Hm, I’m not sure why glTF-Transform output would produce files that inconsistently cause OOB errors in Draco… is that a glTF-Transform bug or a bug in a Draco decoder? But I’d be happy to look into it more if you can share the file privately.
Once I had pinned down the file causing the error, it was consistent. I was testing out compression on several models and it was only happening on mobile so I mistakenly thought it was only happening occasionally.
Sorry for the delay in getting back to you. I reached out to the client and they don’t want me to share the model with anyone, even in private
In any case, I went with gltfpack with the -cc option which gives pretty good compression (1.7mb vs 1.07mb with draco).
Ah ok, understood! If someone does find a model they can share reproducing the issue I’m happy to look into it.
One quick tip – gltfpack compression benefits disproportionately (by design) from Gzip, so it’s helpful to compare against Draco with Gzip applied to both files.
@donmccurdy I encounter the same problem in Android chrome browser. I am using GLTF-pipeline to compress the file. It loads fine in desktop and even in Android mobile native browser, Firefox mobile and add all the browsers in Iphone. It doesn’t work only on Android Chrome browser.
I am attaching the GLB file which runs in to a problem.
