hey folks, i’ve been using babylon for years, and me and a buddy are now making a really cool roguelike game we can’t wait to show you soon!
anyways, i’m trying to load the draco wasm decoder locally (instead of using the babylon cdn), but i can’t get it working – following various online advice, i made fix-babylon-draco-urls.ts:
import {DracoCompression} from "@babylonjs/core/Meshes/Compression/dracoCompression.js"
const dir = "/node_modules/@babylonjs/core/assets/Draco"
DracoCompression.Configuration.decoder.wasmUrl = `${dir}/draco_wasm_wrapper_gltf.js`
DracoCompression.Configuration.decoder.wasmBinaryUrl = `${dir}/draco_decoder_gltf.wasm`
DracoCompression.Configuration.decoder.fallbackUrl = `${dir}/draco_decoder_gltf.js`
and then i import "./utils/fix-babylon-draco-urls.js" before loading anything else, but for some reason, babylon seems to be ignoring these url configurations.
- babylon is still loading from the cdn, eg:
https://cdn.babylonjs.com/draco_decoder_gltf.wasmhttps://cdn.babylonjs.com/draco_wasm_wrapper_gltf.js
- i’ve used some console logging to verify
fix-babylon-draco-urls.js is indeed executing before anything else
- i’m using
"@babylonjs/core": "^7.42.0"
- it fails the same way whether i’m loading the es modules directly/individually (with an importmap), or am using my rollup bundle
- i thought maybe it’s some funkiness about where i’m importing DracoCompression from, but it fails either way here:
import {DracoCompression} from "@babylonjs/core/Meshes/Compression/dracoCompression.js"import {DracoCompression} from "@babylonjs/core"
- i guess a playground repro would not help, since it’s surely something to do with the way/order that modules are loading
i was hoping somebody might have a hunch about what’s wrong 
later today i’ll try doing some more experiments and troubleshooting and keep you posted.
thanks in advanced
1 Like
hey, i found a solution that seems to work, although i’m not sure if it might be a hacky workaround:
fix-babylon-draco-urls.ts
import {DracoDecoder} from "@babylonjs/core/Meshes/Compression/dracoDecoder.js"
const dir = "/node_modules/@babylonjs/core/assets/Draco"
DracoDecoder.DefaultConfiguration.wasmUrl = `${dir}/draco_wasm_wrapper_gltf.js`
DracoDecoder.DefaultConfiguration.wasmBinaryUrl = `${dir}/draco_decoder_gltf.wasm`
DracoDecoder.DefaultConfiguration.fallbackUrl = `${dir}/draco_decoder_gltf.js`
it now works when i alter DracoDecoder.DefaultConfiguration
it did not work when i altered DracoCompression.Configuration.decoder
i discovered the existence of DracoDecoder.DefaultConfiguration, by blocking the network requests to the CDN and then pausing the chrome debugger on the failed request, and crawling up the call stack to find which configuration was being used.
in all the advice and examples i found online, everybody else was manipulating DracoCompression.Configuration – i suspect that something about the way i’m loading babylonjs via es modules, is executing a different startup branch for DracoDecoder, which for whatever reason is not using DracoCompression.Configuration.decoder and is instead falling back on DracoDecoder.DefaultConfiguration – i suspect that manipulating this DefaultConfiguration fallback is kinda hacky, and not the ergonomically intended way of setting these configurations.
please let me know if i should file a bug about this, or if this is the intended way.
if this is intentionally a valid usage pattern, then perhaps me or somebody else might leave a note about the new usage pattern on some of these older threads for posterity:
This should work, I guess a repro on github could help here ? (the simplest as possible please)
Wondering if your code is hitting a different code path, for instance if you use GLTF, DracoDecoder.Default is being used creating a new DracoDecoder() relying on the DracoDecoder.DefaultConfiguration
I would say you could change your code to:
import {DracoDecoder} from "@babylonjs/core/Meshes/Compression/dracoDecoder.js"
const dir = "/node_modules/@babylonjs/core/assets/Draco"
DracoDecoder.DefaultConfiguration.wasmUrl = `${dir}/draco_wasm_wrapper_gltf.js`
DracoDecoder.DefaultConfiguration.wasmBinaryUrl = `${dir}/draco_decoder_gltf.wasm`
DracoDecoder.DefaultConfiguration.fallbackUrl = `${dir}/draco_decoder_gltf.js`
2 Likes
great, well the DracoDecoder.DefaultConfiguration works 
I guess a repro on github could help here ?
now that it’s working, i’m gonna be lazy and neglect to make a proper minimal repro – but here you can see the source code for my project, at the commit/file with the fix, just in case it might help you diagnose anything
Wondering if your code is hitting a different code path, for instance if you use GLTF
yes, we are loading .glb files which are draco-compressed via gltf-transform.
i love that you guys are so prompt and helpful, it gives me and my cofounder a great deal of confidence in babylonjs knowing we are just a forum post away from getting real support – thank you!
1 Like
cc @alexchuber as she is deep into Draco already
Thanks for the report! I don’t repro with a PG, which is worrying.
If you’re using DracoCompression.Default, then just once, call DracoCompression.ResetDefault() right before setting the configuration. Does this make any difference for you? If so, it means that Default is being instantiated (lazily) somewhere using the Babylon default configuration before you get the chance to set your own. We can try to figure out why from there.
(For additional context, the internals of DracoCompression have indeed changed recently. We’re considering deprecating it in favor of using the new DracoDecoder class, which DracoCompression now composes.)
Unless you are setting the configuration to affect how glTF assets are loaded with the Babylon loader… in which case, the only way to do that now is via DracoDecoder.DefaultConfiguration like Seb said.
I didn’t think of this possible use case when replacing the DracoCompression with DracoDecoder in the glTF loader. Is it worth putting it back to DracoCompression? @bghgary
No worries! This PR should fix the issue. Then you can use either the DracoCompression.Configuration or DracoDecoder.DefaultConfiguration to affect the glTF loader’s draco configuration.
The documentation will be getting an update soon to better explain the new DracoDecoder API, but for now, it’s safe to continue using DracoCompression
3 Likes