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.
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`
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
i expect you would not be able to build/run the project locally since you don’t have the 3d assets which we keep separately outside the git repo (not really setup for outside collabs at this time)
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!
Hey bro, I have the same problem. I had no problem setting up the offline decoder in 4.x-6.x. I ran into this problem today after upgrading to 7.40.0+. The code I had set up previously does not work. Is this a 7.0 issue that the project that worked well before fails after the upgrade?
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
Sorry, I just saw your reply due to time zone issues. This is my playground. Apparently, I see that setting BABYLON.DracoCompression.Configuration has no corresponding effect, and the URL does not change. Can you check if I wrote it wrong? Thanks playground
I can use the DracoDecoder class to change it first, and it will take effect, but I have a suggestion: Should the official documentation be updated or backward compatible? Otherwise, it is easy to make mistakes after upgrading the low-version project.@sebavan@Deltakosh
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
it now works when i alter 
it did not work when i altered 
please let me know if i should file a bug about this, or if this is the intended way.
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!
