Babylon CDN Traffic Increase

Hey Everyone,

Over the past week we’ve seen a large increase in traffic using the Babylon CDN. First we’re overjoyed that more applications are being deployed that are leveraging Babylon to bring great experiences to the world!

While this is super exciting, at the same time we want to remind everyone that the Babylon CDN is not recommended to be used in production applications. The purpose of our CDN is to serve Babylon packages to users learning how to use the platform or running small experiments. Once you’ve built an application and are ready to share it with the world at large, you should serve all packages from your own CDN.

You can read more about our CDN and how/when to use it here: CDN Babylon.js Packages | Babylon.js Documentation

Thanks everyone!

8 Likes

That’s a pretty funny but good problem to have…

I noticed these requests being made from my locally built project using bjs npm packages-

  tools.js:
  1. https://preview.babylonjs.com/glslang/glslang.js
    glslang.js:
  2. https://preview.babylonjs.com/glslang/glslang.wasm
    tools.js:
  3. https://preview.babylonjs.com/twgsl/twgsl.js
    twgsl.js
  4. https://preview.babylonjs.com/twgsl/twgsl.wasm

It’s code like this:

        function instantiateAsync() {
            if (!wasmBinary && typeof WebAssembly.instantiateStreaming == "function" && !isDataURI(wasmBinaryFile) && !isFileURI(wasmBinaryFile) && !ENVIRONMENT_IS_NODE && typeof fetch == "function") {
                return fetch(wasmBinaryFile, {
                    credentials: "same-origin"
                }).then(function(response) {
                    var result = WebAssembly.instantiateStreaming(response, info);
                    return result.then(receiveInstantiationResult, function(reason) {
                        err("wasm streaming compile failed: " + reason);
                        err("falling back to ArrayBuffer instantiation");
                        return instantiateArrayBuffer(receiveInstantiationResult)
                    })
                })
            } else {
                return instantiateArrayBuffer(receiveInstantiationResult)
            }
        }

Idk how to get around these network calls, as I myself would prefer that everything worked offline; on the plane I cant do development sometimes :confused:

Do you have a workaround?

It would be nice to have a write-up about properly rehosting Babylon bits - and have a build that contains all of those. Unless I missed it somewhere?

That is, all wasm files, plugins, etc - pretty sure that’s not the complete list:

KhronosTextureContainer2.URLConfig.jsDecoderModule = '.../babylon.ktx2Decoder.js';
KhronosTextureContainer2.URLConfig.wasmZSTDDecoder = '.../zstddec.wasm';

KhronosTextureContainer2.URLConfig.wasmUASTCToASTC = '.../ktx2Transcoders/1/uastc_astc.wasm';
KhronosTextureContainer2.URLConfig.wasmUASTCToBC7 = '.../ktx2Transcoders/1/uastc_bc7.wasm';
KhronosTextureContainer2.URLConfig.wasmUASTCToRGBA_UNORM = '.../ktx2Transcoders/1/uastc_rgba8_unorm_v2.wasm';
KhronosTextureContainer2.URLConfig.wasmUASTCToRGBA_SRGB = '.../ktx2Transcoders/1/uastc_rgba8_srgb_v2.wasm';
KhronosTextureContainer2.URLConfig.jsMSCTranscoder = '.../ktx2Transcoders/1/msc_basis_transcoder.js';
KhronosTextureContainer2.URLConfig.wasmMSCTranscoder = '.../ktx2Transcoders/1/msc_basis_transcoder.wasm';

MeshoptCompression.Configuration.decoder.url = '.../meshopt_decoder.js';

DracoCompression.Configuration.decoder.wasmUrl = '.../draco_wasm_wrapper_gltf.js';
DracoCompression.Configuration.decoder.wasmBinaryUrl = '.../draco_decoder_gltf.wasm';
DracoCompression.Configuration.decoder.fallbackUrl = '.../draco_decoder_gltf.js';
1 Like

I totally agree this should be all over our doc referencing all the possibly download external files.

cc @PatrickRyan if you can help with this part ?

@arcman7 those are part of the options when you initAsync the webgpuEngine

2 Likes

I see that now, thanks for the pointer :+1:

Babylon is a victim of its success it seems. :slight_smile:
For my part, I fetch the CDN files once with PHP and I rewrite the files locally. I find this loads scripts faster than with CDN.

I do it like this:

<?php
function updateBabylon($urlDist, $localFile)
{	
	//GET
	$babylonFile = file_get_contents($urlDist, false, stream_context_create(array("ssl" => array("verify_peer"=>false, "verify_peer_name"=>false))));	
	$babylonFile = preg_replace('!^[ \t]*/\*.*?\*/[ \t]*[\r\n]!s', '', $babylonFile);
	$babylonFile = preg_replace('~//[#@]\s(source(?:Mapping)?URL)=\s*(\S+)~', '', $babylonFile);
	
	//SET
	$pathProject = "../myProject/";
	file_put_contents($pathProject.$localFile, "".$babylonFile."");
}

updateBabylon("https://preview.babylonjs.com/babylon.js", "babylon.js");
updateBabylon("https://preview.babylonjs.com/gui/babylon.gui.min.js", "babylon.gui.min.js");
updateBabylon("https://preview.babylonjs.com/materialsLibrary/babylonjs.materials.min.js", "babylonjs.materials.min.js");
updateBabylon("https://preview.babylonjs.com/inspector/babylon.inspector.bundle.js", "babylon.inspector.bundle.js");
updateBabylon("https://preview.babylonjs.com/loaders/babylonjs.loaders.min.js", "babylonjs.loaders.min.js");
updateBabylon("https://preview.babylonjs.com/serializers/babylonjs.serializers.min.js", "babylonjs.serializers.min.js");
?>

With this PHP script, I call the CDN once, I copy the files locally and the CDN is no longer used on my application. It’s faster than downloading the zip

Afterwards, I find that the CDN is perhaps highlighted too much in the repository and in the docs. I mean it takes longer to download the zip (a few minutes each time) to fetch the files one by one to use them locally. Most people will only use the CDN for simplicity and speed.

1 Like

that is a bit concerning to hear…

what are you saying here @sebavan , that npm packages do not ever fetch remote files unless you are doing some or other runtime initialization on packages not included in the build ?

Is it alright if I download the builds (babylon.js, babylon.materials.js, Havok, Recast, etc.) once in a while (idk, every 2 weeks maybe; or after an important hotfix)?

@shaderbytes, yes, for convenience some of the dependencies are external and pointing at our cdn: like some of our wasm dependencies to workaround the need of extra setup on client builds.

This is the part we need to be extra cleat about in the doc.