How to self-host files from assets.babylonjs.com CDN

Bugs
1

When following the guide for replacing the Babylon CDN with your own resources here: Babylon.js docs

We find that resources normally loaded from assets.babylonjs.com will no longer load.

Even just following the simple example for using a fixed version of the CDN has this issue.

BABYLON.Tools.CDNBaseUrl = "https://cdn.babylonjs.com/v8.37.0";

If you load this PG and enter VR, you’ll see these network errors:

webRequest.ts:185  GET https://cdn.babylonjs.com/v8.37.0/HandMeshes/l_hand_rhs.glb 404 (Not Found)
webRequest.ts:185  GET https://cdn.babylonjs.com/v8.37.0/HandMeshes/r_hand_rhs.glb 404 (Not Found)

In our case, we’re hosting a copy of the CDN from the github deploys snapshot and pointing to it via CDNBaseUrl and we have the same problem. Browsing the files from the snapshot, it doesn’t look like the assets are included. So I think our immediate fix will be to assign our self-hosted CDN url to Tools.ScriptBaseUrl instead, but then where do we get a copy of the CDN resources for Tools.AssetBaseUrl?

2

cc @docEdub @amoebachant

1 Like
3

CDN does not host these assets. They are only on assets.babylonjs.com

They are here:
BabylonJS/Assets: A place for public domain digital assets to use.

4

ok confirming this instruction in the docs won’t work as described, since it changes the AssetBaseUrl to the CDN instead of assets.

image
image1982×596 70.5 KB

Could we have some docs on how to build BabylonJS/Assets to get the expected directory structure? Thanks

1 Like
5

cc @alexchuber

1 Like
6

Oops, sorry about the bad example. You’re correct that our CDN would only work for replacing ScriptBaseUrl.

For more context, these are the default values of each:

public static readonly _DefaultCdnUrl = "https://cdn.babylonjs.com";
public static readonly _DefaultAssetsUrl = "https://assets.babylonjs.com/core";

assets.babylonjs.com follows the same directory structure as our Assets repo, so as of right now, the answer is to download the contents of the Asset repo’s core folder, Assets/core at c78b67f767197129baf8ffa01f891e0fcfcc537b · BabylonJS/Assets · GitHub.

This could be better… maybe we should publish these on NPM somewhere, like we do for our scripts (which live in @babylonjs/core/assets).

1 Like
7

Thanks so much @alexchuber!!

1 Like
8

If you could do a versioned github artifact for the core assets like you do for the scripts CDN snapshots, that would be ideal for us

1 Like
9

Yeah, it’d be good to version and publish the Assets CDN somewhere. A GitHub artifact sounds like a good place to start. cc @docEdub

Fortunately, the asset CDN structure doesn’t change often, but files are added and shuffled around (EDIT: with accompanying redirects, of course) every now and then.

1 Like
10

The assets repo can be downloaded as a .zip archive at any commit/version by specifying the Git hash in the URL.

For example: https://github.com/BabylonJS/Assets/archive/df2c35967307b155026c1da6926cadc640334fb7.zip for the version from May 20th.

Since there is no build for the assets repo, the GitHub .zip archive is what would be in any release archive we would generate, so I don’t think it’s needed.

11

Thank you. How do we correlate Assets repo git hash with BabylonJS library version to ensure we get the correct version? I don’t see any releases or tags on the Assets repo.

That zip is probably pretty large - I’m also going to try to do some git magic to checkout only the core folder to save time since we’re doing this in CI workflows

12

Assets are not versioned. They are only gltf files so no dependencies on version
So you are good to go :wink:

13

That doesn’t feel sufficiently safe for production use. As @alexchuber mentioned above, assets may be added or moved. If we have a version of bjs core that references new assets or changed asset locations, but an old copy of the assets repo deployed, then we’ll have failures.

If we always run the current copy of assets, then we run the risk of an older deployed version of BJS referencing urls that no longer exist.

Or let’s say WebXR hand tracking standard is updated someday and the reference hand models are updated with different joint names. How do we ensure we’ve got the matching version in our assets for our BJS version?

Is there a guarantee of never making backwards-incompatible changes to BabylonJS/Assets so we can safely deploy the current version regardless of our library update schedule?

14

Yup.. This is how we deal with it :slight_smile:

2 Likes
15

In your webXR example, we will have the obligation to make it work with old and new assets (assuming we add new feature to the hand model for instance)