Why updating to 5.0 on the CDN without warning?

Questions
1

Hi,

Just a quick question : why did you update the babylonJS version on your CDN like this, shouldn’t the logic be to have a new different link on the CDN when updating to a new major version ?

The 5.0 update broke the website I made with 4.2, without even triggering any error in the JS console, so no automatic error detection system saw the problem…
Our client wasn’t very happy with it.

I downloaded the 4.2 .zip and got the files I needed and now load it locally.
But I’d really advise to have a different CDN link for each major version, like most libs out there :

Any reason to not do that ?

2

While this has been a hindsight from Babylon, I’d recommend people using their own CDN (and this recommendation extends to all libraries, except jquery - which is popular enough so you will get real cashing benefits from a shared cdn.)

ps. the recommended hypothetical pattern for versioning should be like this:

https://cdn.babylonjs.com/babylon/core?v=5.0.0 // use 5
https://cdn.babylonjs.com/babylon/core // use latest
1 Like
3

Yes, well I don’t know if I should like or dislike this comment. But I sort of do agree (that major versions should remain available as long as they are ‘supported’).

1 Like
4

Sorry if my comment sounded like I’m here to rant about it (I guess that’s why you wasn’t sure about my comment ?), I’ve been kinda stressed by this babylonjs website being broken without anyone touching anything on it, but I know this is my fault in the end : as @ecoin stated, I should have hosted the scripts on our own CDN, it was clear in the CDN link I used that it wasn’t gonna stay on 4.2 forever but would evolve with versions…

My point isn’t to complain, but to maybe avoid that kind of problem to others if versionned CDN links would be a thing :wink:

5

Uh… no, your comment was fine and fair. I said I wasn’t sure just because the rather small community of BJS is used to these manners and visits the forum whenever there’s an issue of this kind. On the other hand the community and users is growing (and I hope it will grow a lot) and it might just be a good time to think about implementing some good practices that will be appreciated by the larger community.
And complaining is ok, I also do it when I feel like it :wink:

2 Likes
6

The cdn always hosts the latest version at the root level. This has been true since 1.0

As 5.0 hits its release we moved the new bits to the root of the cdn (and I believe @RaananW is working on having other versions available as well in sub folders)

7

On a different note @Clement could you let me know what broke during the change ?

I want to try to be as backward compatible as possible and it looks like you are not the only one who had issues :frowning: I wonder if it is smthg we could easily address

2 Likes
8

I don’t really know what was the problem sorry. It was on this website : https://larouget.com/

The bottle was displaying fine, but the moving stickers disappeared, with no error in the console, so I don’t know why they didn’t load anymore. (The stickers are a different .glb file than the bottle).

9

Maybe babylonjs.loaders.js was still in v4.2?

10

Well, I was loading both files from the CDN, so I think the 2 files have been updated at the same time ?

Here’s the scripts I was loading before changing it to local 4.2 scripts :
src=“https://cdn.babylonjs.com/babylon.js”
src="https://cdn.babylonjs.com/loaders/babylonjs.loaders.min.js

11

first, what an AWESOME website!!!

Second - would be really great knowing what went wrong. Do you have a stacktrace? Something we might be able to work with? There is no reason for that to happen, and we work hard to maintain back-compat (in almost all cases).

About previous versions - I have a github issue already open to support older versions and we will soon have the option to load previous versions on our cdn.

1 Like
12

Thank you :slight_smile: first project with BabylonJS :slight_smile:

No, sorry, unfortunately it didn’t trigger any error anywhere, I don’t have any information to give to you… No JS error in the console, no error in apache logs, nothing.

If it can be of any help, it’s kinda similar to a bug I already had in 4.2 : if I zoomed the camera too much, the stickers disappeared. I thought it was camera clipping, but even by setting the clipping very small, they disappeared all the same. Making all the objects bigger instead of zooming the camera triggered the same problem when going higher than a given size. And the same thing happened when changing the canvas width : when the width became too small, the stickers disappeared too. I’ve got to set the canvas to a fixed (pretty big) width, and let it go out of the viewport on the left and right, to be able to keep the stickers visible at any width.

I don’t know if this has anything to do with the bug I got in 5.0, but the problems I discribed made the stickers disappear without triggerring any error too.

Sorry to not be able to help futher, let me know if I can do more, maybe there’s some debug mode I can enable or something to try to get errors ?

Nice to know we’ll be able to load previous versions from your CDN in the future :slight_smile:

13

Interesting! Those kind of issues keep us up at night, because we want everything to always work the same, especially if you are only using our public APIs.

I’ll DM you

Thank you so much for your patience :slight_smile:

14

Being FR-CH with a view on the Jura and also a beer lover :wink: I can only endorse this website. Trendy, shiny and beautifully crafted. ‘Un super job, j’adhère à fond’ :smiley:

1 Like
15

Thanks to @Clement for sharing the broken version with us, we found the culprit:

This is related to one of the bug fix that has been done in 5.0 : Animation Group Recent Changes - #2 by sebavan Basically before the FPS in the loader was considered 1 meaning the animation worked on a frame basis instead of time :frowning:

This is part of the breaking change list in 5.0 but I agree adding a meaning full workaround in the entry would be great. @carolhmj will update the whats new with the workaround:

BABYLON.SceneLoader.OnPluginActivatedObservable.add(function(plugin) {
         if (plugin.name === "gltf") {
             plugin.targetFps = 1;
         }
});
4 Likes