Serialization relies on id strings being unique?

It appears that the serialization format uses the id of objects to establish parent-child or material associations. This means for example that if two different transform nodes have the same name and therefore the same default id, after serialization parent-child relationships get lost for any mesh that uses the second transform node as a parent.

Is that a correct understanding ? It took me a while to figure this out since I did not expect the name to have a critical function. Perhaps there is documentation ? The loader code appears to look for ids. It is somewhat surprising since there is also the .uniqueId property which could be used for serialization purposes to avoid loss of such information (probably with the understanding that it would not be preserved after loading).

yup unfortunately it is mostly related to historical reasons :slight_smile:

The unique ids are unique upon creation of objects but we can not ensure they would not conflict with what is already in your scene so ids where used during some deserialization in the babylon format.

@Deltakosh may have more precision in this regard :slight_smile:

4 Likes

Thanks for the confirmation, very helpful. I kind of suspected that there may be historical reasons.

I suppose, the loader could still use the old, serialized uniqueIds just for the mapping, while assigning new uniqueIds, as a fallback when ids are duplicated. But perhaps there are other reasons than serialization to encourage proper names and ids.

So if I use SceneLoader.ImportMesh, it will lost the parent relationships.
And I try SceneLoader.Append, it’s all fine.
Is there any way to ImportMesh with correct parent relationships?
@sebavan

importMesh won t lose it inside the hierarchy of the imported mesh. if you need to maintain hierarchy accross meshes, you could probably use tags to know what goes where.