Metadata lost when instantiating container models?

Before I delve too deeply, I ran across some behavior that may (or may not) be intended. It’s entirely possible I’m doing it wrong :slight_smile:

After I fetch a scene via SceneLoader.LoadAssetContainer(), I iterate through the asset container’s meshes and make some adjustments to isPickable, checkCollisions and isVisible based on their metadata (exported from Blender). I then stash that container away in a cache. When I later instantiate that container, the instantiated mesh’s metadata has been removed and the previous changes I made to the meshes have been reset. Is that intended? Is there a better way to persist those states so future instantiations will have them?

Thanks!

cc @RaananW

Would you be able to reproduce this on the playground? a simple example would suffice, so I will understand exactly what you are doing and what doesn’t work correctly.

I think I’ve also noticed that mesh.clone() also does not retain metadata. I would guess that these are related, though neither really get at whether metadata retention during clone() or serialize() is intended by the babylon framework.

I could totally understand if the intent is to NOT copy metadata since, in some cases, metadata copying might be imprudent. Deep copying, references to other meshes and circular references all would complicate copying or serializing.

Yup! https://playground.babylonjs.com/#MF6GAX#8

The cube has been marked in the .glb metadata as invisible. If the cube IS visible in the playground, then it’s not working and console.asserts() should be complaining.

As I mentioned, this might be expected behavior. When cloning the container models {doNotInstantiate: true}, it works fine. It seems that the information is lost if the models are instanced {doNotInstatiate: false}.

@HiGreg Hmm… I’m actually seeing the opposite behavior, although I’m not cloning directly (instantiating via AssetContainer). If I force cloning, it appears to work.

I must have been mistaken. A simple test in playground proves you’re right: