About Optimizing Using Cached Resources

Questions
1

It should be named NameOfYourScene.babylon.manifest
I really did not understand this sentence in the document, it is not friendly at all!!!
such as how to name the manifest file? If I load this scene in app.vue, it should be called app.babylon.manifest?
And where in the project should the file go? Same directory as app.vue file?

Through the documentation, I don’t know how to do this！！！

I’ve already set these properties to true

   BABYLON.Database.IDBStorageEnabled = true;
   engine.enableOfflineSupport = true

Please help me, how should I use IndexedDB automatically ！！！ :sob:

2

Manifest is required if you want to control the version of the resources you are downloading. The manifest file should be in the same base directory oft he asset you are downloading. Note that the assets is a scene file - either a .babylon file or a downloadable asset. And it shoudl be called the-asset-that-you-load.[extension].manifest

You can disable the manifest check to simplify the process. adding engine.disableManifestCheck = true; will get it to work without manifest files. You will then have an indexeddb DB called babylonjs with the scene, textures, etc’.

3 Likes
3

Thank you. It worked. I tested several scenarios:

  1. The .babylon model file works with the.manifest file
  2. The .babylon model file and engine.disableManifestCheck = true without the.manifest file can also works
  3. The .glb model file and the.manifest file without engine.disableManifestCheck = true do not work together
  4. The .glb model file and engine.disableManifestCheck = true without the.manifest file can also works

Am I right in this conclusion?

4

Yes, that seems about right. The manifest file was created for the .babylon format. It was meant as a global manifest for the entire scene, and not for individual assets, though i think there shouldn’t be a reason not to support our with other formats.
Just don’t forget, that when you don’t have a manifest you will need to take care of clearing the assets from the local db if they changed online.

1 Like
5

Could you please explain about pros and cons of offline indexedDB vs browser’s cache vs service worker?

Seems like service worker works best for offline support, but maybe I missed something

6

Service workers are a great way to support offline users, for sure. All of those work a little differently TBH. You can read about the different technologies on your favorite free source of information :slight_smile:

Babylon’s offline support was implemented way before service workers were a thing, so we used indexedDB. Is it the best? maybe not. Does it work? it sure does! Cross platform as well. It all depends on your usecase and how you want to manage your offline data.

2 Likes
7

IMO, IndexedDB is best for storing app-level data. Things like configuration, profile data, etc. things that your app will mutate and persist across sessions.

Service Workers are great for offloading work from the main UI thread and for prefetching assets and such and work in conjunction with various browser storage schemes (including indexedDB if you want!).

Browser caches are simple, effective, and largely transparent to the app, but due to the vagaries of different browser, machines, and users, can be unpredictable and tough to preserve offline

As Raanan said in his reply, the various technologies have more details on each. As well, if you happen to have a copy of my book available (search Going the Distance Babylon.js for more) the chapter on PWA’s and IndexedDb cover these topics in good detail

HTH!

2 Likes