External file https://cdn.babylonjs.com/draco_wasm_wrapper_gltf.js

Questions
,
1

Hello babylonians!

From build to build, an external link in the application appears and disappears. I discovered this when I accidentally forgot to pay for the internet :grin: and noticed that my application wasn’t working offline. That’s when I saw that the framework was trying to fetch a file externally:

https://cdn.babylonjs.com/draco_wasm_wrapper_gltf.js

I was about to report it, but then, in subsequent builds, the problem disappeared, and the application started working offline again. The framework no longer fetched this file externally. Now, in the DevTools console warnings, I see this message:

“Normalized flag from Draco data (false) does not match normalized flag from glTF accessor (true). Using flag from glTF accessor.”

and once again, attempts to fetch the file from the CDN server. I use BabylonJS 7.28.0 for now.

Is this issue related to the Draco Decoder license or something else? Why can’t we include it in the framework’s build itself? Maybe I’m specifying something incorrectly in the dependencies section of my package.json file. My dependencies block looks something like this:

"dependencies": {
    "@babylonjs/core": "^7.28.0",
    "@babylonjs/havok": "^1.3.10",
    "babylonjs": "^7.28.0",
    "babylonjs-gltf2interface": "^7.28.0",
    "babylonjs-gui": "^7.28.0",
    "babylonjs-loaders": "^7.28.0"
}

Thank you in advance for any advice.

2

You can always download the files and host in your own solution. You just need to configure the new URLs:

https://doc.babylonjs.com/typedoc/classes/BABYLON.DracoCompression

3

Hello Boye.

Thank you for responding to my message. Currently I use this solution:

    DracoCompression.Configuration = {
      decoder: {
        wasmUrl: "/draco/draco_wasm_wrapper_gltf.js",
        wasmBinaryUrl: "/draco/draco_decoder_gltf.wasm",
        fallbackUrl: "/draco/draco_decoder_gltf.js",
      }
    }

:thinking: I don’t like this way of solving the problem, and it seems entirely inelegant to me.

Why do we need to add workarounds like manual configuration and manually placing files into a directory, instead of simply having these files installed via a package.json dependency and placed in node_modules, as it happens with the Havok Physics Engine?

4

Those files are available in the core package. You can use them directly from the package. Documentation can be found here -

https://doc.babylonjs.com/setup/frameworkPackages/es6Support#draco-compression

1 Like
5

Cool. I see that we already have these files locally.
image
But why not use them by default from here? Why is there an external link in the default settings leading to the CDN server? The documentation states that we should use CDN servers only in rare cases, like for the sandbox or dev environments. But now we have a situation where the framework, instead of using the available local files, reaches out externally. Why?

1 Like
6

Oh, that’s a good question :slight_smile:

The short answer is - back-compat and the UMD version.

You are right, we don’t recommend using our CDN in production, mainly because we won’t guaranty uptime. We do, however, try to allow the framework to “just work” without breaking development.
Our UMD version doesn’t include these files - they are only included in the es6 version of the framework. They will also not work the same in UMD as they work in es6. And as we don’t want to provide different configuration to both versions, the decision was done to maintain this behavior and not break it in future versions.

You will see this in different areas of the framework. We try to never break public back-compat, which forces us to make these kinds of decisions.

We do allow you to override this behavior and make sure you serve these files as you see fit, using your favorite bundler. It just takes a bit of configuration/implementation on your end.

2 Likes
7

Hello RaananW,
Thank you for the detailed explanation. It has clarified things for me. :+1:

2 Likes
8

Let’s move this case to the bugs section, because with the default settings, sudden connections to the outside cannot be justified. This is not normal behavior for any system. :face_with_peeking_eye:

1 Like
9

That’s definitely not a bug. One could argue that it is not a recommended way to work in production, but we do offer the way to optimize it. Actually many different ways to optimize it, and they are all documented.
I am pretty sure there are many other devs that don’t think it is a bug and are actually happy it works “out of the box”.
Also - as much as we don’t recommend using our CDN in production, it is a highly available azure frontdoor-based CDN. it is quite reliable :slight_smile:

10

I acknowledge that this is not a bug, but rather a field and opportunities for improvements are limitless. There is always something that can be made more convenient and better.

Perhaps not enough attention was given to this issue in the documentation under the SceneLoader or ImportMesh sections, which led me to a negative experience.

I should have studied the documentation thoroughly before using the framework. I chose a path where I start reading the documentation when something is unclear to me.

I admit that BabylonJS is very intuitive, and often documentation is not even necessary. In moments of weakness, I was a bit discouraged that the product does not work autonomously “out of the box” and requires an internet connection. It may seem that I am nitpicking and looking for flaws in the framework. However, I understand the enormous effort it takes to create such a framework that simultaneously supports all kinds of includes. I have no way to influence the development course of the framework; I can only provide feedback as your user. My Windows never downloads anything from the internet by default without my permission, and if it needs updates, it will ask me. I apologize for comparing Babylon to an operating system that asks for permission for external connections. This does not diminish the greatness of Babylon, but it adds an element of unpredictability.

Please forgive me if my messages come across as outraged. I am a beginner as 3D-developer, so I know what will be convenient for me, but I am not deeply immersed in the challenges you face to provide me with this user-friendly interface for my comfortable work with 3D.

:slight_smile: I’ve shared my pain. The topic can be closed.

2 Likes