Potential Issues with using .ids in Serialization

Bugs
1

Hi BJS team

Noticed that we are using .id in some serialization code. However, in BJS .id isn’t guaranteed to be unique. This could lead to issues when deserializing objects with .id conflicts?
What would be the recommended ways to work around this?

2

I think the recommended way is to have unique names for ids… Ids are given by the user, so it’s possible to make sure there are no two ids that are the same.

Using uniqueId in the code above will make sure ids are unique, but that would be a breaking change. Also, I’m not sure it exists a uniqueId property for all the entities that are serialized…

2 Likes
3

From my experience, the most common method is to use node.name property too.

Id’s in babylon have always been a bit weird,
often it’s just a copy of the name property (set on node creation).
but it’s there if you want to use it or if you’re importing meshes/nodes that use it.

node.name property should also be unique, babylon doesn’t check this either :slight_smile:
it’s up to the developer.

One option to ensure ids are unique is to use

BABYLON.Tools.RandomId();

resulting in random string such as

fb6b6704-8a8a-4018-9f05-c932aa2bf2ac

1 Like
4

Thanks for the replies! One issue with using .ids is that it gets arbitrarily set in various different functions all over the source code i.e. cloning functions, and usually these are just copies of the name like @aWeirdo mentioned. So it’s usually not something that the user provides all the time, and this could lead to weird behavior