Stranges with Containers


I found strange behaviour with containers. Could someone explain that?

When we call addAllToScene and have some mesh in KeepAssets, we had strange duplications.
In scene.meshes we had 2 instances of object with same uniqueId.

Could you explain that please? What it happens?

This is per design. The “duplicated” mesh is actually the same mesh. this is why it has the same uniqueId.

The list of meshes (or nodes) in the assets container is meant as a way for you to find what meshes are in the container, and not meant as a way to add new meshes to the assets container. This is somehow a downside of js/ts - there are complex ways to achieve that, but there is no simple way of defining this array as read-only (in a sense of - immutable).

If you want to move assets to the container, you will need to use the assets container functions, as described here - Asset Containers | Babylon.js Documentation

Also note that when you register events in the playground, you need to remove the event listener otherwise it will register again every time you run the playground again, ending in a crazy number of events that reference the wrong objects.

1 Like


Thank you fo exlplain!
But while i cant get all from explain and documentation.
How i can fill AssetContainer explicitly?
About what methods you told?
Only with help KeepAsset? With container.moveAllFromScene(keepAssets); ?

I understood advice about listener, thank for that too!
I noticed stranges with console, but not connected that with many similar listners ))

This would be the function you need to use, yes.

Can I ask what your goal is? Are you sure the assets container is the tool you require?

1 Like

No, im not sure ))

In all i trying to make controller for app parts.

Controller can have Parts of App.
And make switches between parts, initiate resources of parts, free memory, create new parts on demand and so on.

One Part can use Scene (as real scene) or scene with virtual scenes.
Virtual scene not real scene, only set of materials, objects, etc associated with virtual scene.

As example:
Part contain part of logic of simulator, scene contain common elements for fast use and set of virtual scenes, assotiated with scene.

As example virtual scene can be room View in sets of few rooms.

When we switch between rooms (virtual scenes) we remove or get elements (to and from containers) elements and can make few useful things:

  • make lazy loading resources if need
  • less load GPU because of elements realy remove to assets
  • flex use events like as piking

Somthing like that )

i was able to do build that with Parts, Scenes, Resources, but not virtual scenes. (Work with asset containers required understanding how it work).
Could you tell more about AssetContainers and KeepAsset? Perhaps we need use other mechanic?

Well, that seems to partly fit the use case for asset container :slight_smile:

It requires a bit of explanation thou - the assets in the asset container are still using memory, and are still bound to the scene. They are not rendered and don’t play a role in the scene rendering process, but they are definitely there.

Asset container can be used if, for example, you have a scene with a room that you want to reset every time the game starts. You load the assets, move them to an asset container, and instantiate them every time the player wants to start the scene from the beginning (after clearing the scene when the experience is over). You can technically do that they way you have been using the asset container in your initial playground, but you will have to take care of removing the assets from the scene yourself. The assets in the container will maintain their state and will not be altered by the user.

The KeepAssets mechanism lets you define what element get to stay in the scene when calling moveAllFromScene

Think about it this way - you first load the entire scene with everything in it (while showing the users a loading screen). You then create containers with different parts of your scene, while move them away from the scene - now the scene is empty, and you are ready to instantiate the right container. Which seems to fit your description correctly.
That depends on the current state. This is one way of achieving this. You can also manage your own state or customize the loading mechanism.


Something like this I did (load, then hide, then switching), but obviously did not understand the way of adding, because I was trying to add elements next time, just placing them in the container arrays.

Thanks a lot for the tips!

1 Like