Draco decompression broken?

Has something just happened to break Draco decompression of glb files?
Suddenly my models are not loading and giving an error like
Uncaught (in promise) abort({}). Build with -s ASSERTIONS=1 for more info.

And also trying to drag-drop them in sandbox just gives inifinte spinning icon. They all used to work.

It was working up until about an hour ago.

Is it possible something has happened on my machine?

I just checked in the console of sandbox when I try to drop a draco compressed glb model and I get the same errors. These are models that I have previously viewed in sandox, they have not changed.
I am using scripts from here https://cdn.babylonjs.com/loaders/babylonjs.loaders.min.js

I am a bit anxious if things can suddenly break. Should I be downloading a particular version of babylon scripts into my project and using them rather than the cdn if it can change and break?

@bghgary will have an answer very soon

AFAIK nothing has changed on the production cdn, changes have been made to the preview cdn only.

I have just checked, the file https://cdn.babylonjs.com/loaders/babylonjs.loaders.min.js is the same one than Babylon.js/babylonjs.loaders.min.js at master · BabylonJS/Babylon.js · GitHub which is the 4.1.0 version, so it did not change since 4.1.0 has been released.

Thanks for the replies I really appreciate it.

Any ideas why it would be broken for me? Given it no longer works in sandbox either. Does loading a model in sandbox use local cache versions maybe? Is there anything on my local machine that would affect this?..Hold the press…
Just before posting this I tried again and it is now working. Both sandbox and my app is now loading fine. While all is good now it would be good to know what the cause was, if possible. I suspect it must be something local.

Maybe a problem with the cache of your browser?

Yeah probably. I just had a power outage (I am on solar and my battery bank has degraded so I often suddenly loose power and it took a while to get back on) so that and a delay may have triggered a cache clean. Next time I have an issue like this I will clean cache first. I did try a clean reboot but presumably the cache persisted.

1 Like


I’m also experiencing a similar issue with one of my builds. If we do a hard reload it seems to fix the issue, but in trying to diagnose the problem I’ve noticed that my project seems to pull from the preview branch of babylon, as in preview.babylonjs.com/draco_decoder_gltf.wasm

I’m using npm so I have: “babylonjs-loaders”: “^4.1.0”

and in my code I’m doing: import “babylonjs-loaders” with SceneLoader.LoadAssetContainer

Is there a way I can not use the preview branch for draco compressed GLBs?


The external wasm files are always loaded from the preview CDN, I don’t think you can change that (@Deltakosh?)

Actually you can change it with BABYLON.DracoCompression.Configuration:


Thanks for the reply.

I felt like the issue we’re experiencing where some of our users are getting black screens with errors logged to the console

Uncaught (in promise) abort({}). Build with -s ASSERTIONS=1 for more info.

could have been related to the fact that some of the scripts were coming from the preview branch. Do you think this likely isn’t the case?

Since I’ve cleared my cache I haven’t experienced the issue, but someone did screenshot the console for me, and I’ve attached it.

I’m just not sure what to do to potentially try to prevent something like this from happening in the future.

Thank you for your help, it’s much appreciated.


Maybe @bghgary will know more

I’m not sure what’s going on with the error (sounds like there is a mismatch between babylonjs and draco files), but I did just update the draco files to a newer version yesterday as well as update the code to use a couple of functions in the newer version. If the code is mismatched from the draco files, it will not work since the functions will not be present. For production environments, it would be good to set the Draco configuration to point to a copy of the Draco files hosted in the production environment. Maybe there is a way we can set it up so that it’s more obvious that this needs to happen? By default, the code is configured to point to the preview files.

Thanks for the reply, so for now you’d recommend that I pull down the draco files from the preview branch, and point BABYLON.DracoCompression.Configuration at them?

I’m wondering though, if I might npm install at some point and they are no longer in sync.

I suppose I’d know that was the case immediately and could manually pull down the updated files from the preview branch?

It depends. Preview files can change and is not good for production. The Draco team wants people to use https://www.gstatic.com/draco/v1/decoders/* (see this), but if you need IE support, then those files won’t work (see this).

Maybe we can tell from the code whether the version is correct or not. I wonder if Draco libraries can tell me what version it is. That said, I doubt that the Draco API will change often.

1 Like

Ok that’s great, thank you again!