We are sometimes seeing an error when loading GLTF files, in which it appears to be timing out and then failing the GLTF validation step.
The error is from the WASM file:
draco_decoder_gltf.wasm Error: Error: /meshes/51/primitives/0
Our use case is a little unusual in that we’re loading a lot of meshes at once on a PM2 cluster, so we’re maybe pushing the limits here, but is there a way to adjust the retry strategy on SceneLoader.ImportMeshAsync?
When you say it is timing out, does that mean the file is not loaded correctly/completely? And in that case, is the file still being processed by the loader?
It looks like the error could come from a parsing error of a partially loaded file. I would assume the loader handle HTTP errors and would stop without calling the gltf parsing in that case.
Adding @bghgary that may know more about this.
I’m not 100% sure if it’s a timeout issue, but it’s a known set of GLTF files and they load 90% of the time, so I don’t think it’s a problem with the GLTF files. We’re running this on a very beefy server, but we’re using PM2 clustering so there are 8 Chromium instances and each loads 10 GLTF files. My first thought was that maybe Chromium has a limit on the number of threads that a WASM can spin off. Maybe we’re hitting a limit somewhere? But I couldn’t find much information on that. If we stagger the PM2 nodes then the problem doesn’t appear.
We noticed that the GLTF loader uses a retry strategy that defaults to 3 tries, with 500ms exponential backoff. If we could set a different retry strategy we could see if that solves the problem.
You can change the RetryStrategy by setting FileTools.DefaultRetryStrategy. You’ll want to do something like this:
// Change from default of 3 retries to 10 retries using default 500 milliseconds base interval.
FileTools.DefaultRetryStrategy = RetryStrategy.ExponentialBackoff(10);
Or set it to something completely custom if you want.
That said, I don’t know if this will solve the problem. The draco wasm error in OP doesn’t seem like it can be caused by a file not downloading due to retry failing.
I agree, it doesn’t seem likely that there’s a problem downloading the file. But since the files are being served from a highly available and consistent source, we don’t know what else could be causing this. Like I said, one thought was that there’s some limit on WASM that we’re hitting. Aside from that, we want to try just retrying until it succeeds, or at least give it a few more tries.
Note that it is also possible there is a bug in the draco WASM module. We recently hit a bug in the MSCTranscoder WASM module for KTX2 files because someone was doing a heavy usage of such textures (more than 100 in a single gltf file) and so a bug intermittently would show up.
We are using a custom Babylon GLTF (thanks @bghgary!) extension to scrub the images array and later implement a custom image loader, so when this issue is happening, it’s loading a GLTF that has only 1px data:image/png;base64 strings. We load KTX files but not until later and they are not KTX2.
One other item of note is that we’re hosting the WASM files ourselves and it appears from that Draco issue those files have been updated. I’ll try to grab the latest from Babylon’s CDN.