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: