I am currently searching for a way to store objects even when my babylon engine and scene are disposed. Since every babylon asset is connected to a scene, this is difficult. Think of a web app, where I am switching pages, one has a canvas the other not. If I switch back, I would like to reload the canvas with the engine as fast as possible. Currently I would have to keep a canvas and the engine active on both pages.
ThreeJS seems to have a different approach, their geometries can exist in memory without having a scene - I guess BabylonJS is not taking this path, to take care of garbage collection?
Now I saw AssetContainer, which should be able to take assets from one scene to another, but since it needs a scene itself and therefore an engine, it runs into the same issue. It would be nice to have an option to give the AssetContainer a “hollow” scene/engine that is not running at all, so I can move it around without having any active engine. Thinking about this, the engine would need to be able to exist without a canvas. I thought about using NullEngine for this, but I realized AssetContainer seems to be fixed to one scene. It would be great, if I could just use addAllToScene(anotherScene), but this is not how the function works.
Here is a simple playground, where I create a nullengine with a sphere in a scene that is passed to a container. But the container cannot throw it into the normal scene:
not entirely. Reloading the original assets might require some HTTP requests to trigger (for example).
You might want to check Babylon’s offline-support as well - Optimizing Using Cached Resources | Babylon.js Documentation , which will be very helpful to prevent unneeded (and repeated) asset requests
The assets in the assets container are scene dependent per design. It was not meant to be used as a multi-scene asset management.
In general, basic elements (camera, light, meshes) in Babylon are scene-dependent. The data containers (like the vertexData class) are not, and can be reused. Textures can also be initialized with an engine and not a scene, so that they are not scene dependent as well. You will need to handle disposal of unused data yourself.
Maybe my initial question should have been - what exactly are you trying to achieve? to have a mesh.setScene function? is it a performance issue?
For example, I have a tree that is build up in runtime, since I apply node material and LOD in a specific way, which is not achievable with plain gltf. Instead of setting up the tree asset every time I create a scene I would like to keep it outside of it.
I could also wrap an engine/scene around all my pages, but it does not seem straight forward.
Another use case is for people loading assets and models using an external framework or SPA, so where the scenes and engines are dynamically (re)created and re-use loaded models/images. Would be useful for AssetManager and SceneLoader to have an opt-in mechanism for caching without scene instance reliance (and these intermediate structures could be handed off to the loaders in the future). Besides vertex data there is also skeletons/animations and textures that would need to be considered. What I did to solve was clear cache when the scene changes, but that causes everything to reload. In other words, the results from babylon loaders are already attached to a scene - in the case of three gltfloader the response can be cached and applied to new scenes. Take for example a website that loads a model for a configurator type of website, when navigating away from the page upon returning would always require the scene and hence models to be reloaded (by default). I think offline support may be the right solution and has nice configuration options for filtering, but haven’t investigated it fully. The browser cache would probably also mitigate reload times, but have not investigated that in practice either. Anyway, those are just some thoughts out loud.