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
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
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
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).
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.
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
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
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: