Material id not being unique breaks deserialization

Bugs
1

The id property of materials are not unique. This breaks serialization/deserialization. Please refer to below PG for example of GLB which has multiple different materials but share the same id property. I have encountered many other glbs where multiple materials have same id.

PG

This becomes a problem when deserializing meshes and associating the corresponding material. BJS uses the first material with matching material id.

This seems arbitrary. It means upon deserialization, the associated material can be completely wrong. For example, with the GLB in my case, deserialized meshes are associated with the wrong material and is missing their albeto textures.

I suggest BJS makes sure the material id after loading a GLB is always unique.

2

I can not understand how this is breaking glbs as they are not relying on this deserialization ?

https://playground.babylonjs.com/#G5NEF0#5

1 Like
3

I think he means when you serialize as a .babylon file and deserialize the .babylon back into the scene

4

@Evgeni_Popov Remember we had this chat in the past but can not remember what the conclusion was ?

5

Can confirm i mean when I import a GLB, allow user to make changes, and serialize the scene as .babylon file. Upon loading the existing project, user should be able to deserialize the .babylon file and see the scene as it was.

Due to constraints on our app, we cannot change the material id property ourselves to make it unique. In any case, I don’t think developers should have to themselves in order for import/serialization/deserialization to be stable within the BJS library.

6

There was this PR:

But it had been reverted because of perf problems:

In any case it would not have fixed the problem here where the ids of the materials are a given.

Maybe the babylon serializer should use the uniqueId field instead of id, but that would be a breaking change…

Another solution would be to have a flag in the glTF loader that would “uniquify” the material id at loading time? I don’t know if changing the material ids could break something on the glTF side, adding @bghgary who will know.

2 Likes
7

Hmm, I’m not sure. The code currently puts the names from the glTF as is. I’m not sure if anyone is relying on this fact. Maybe it’s okay to set the name as the name from glTF but make the id unique? Similar problems will happen if two glTFs are loaded and there are duplicate names, so I’m not sure this will solve the problem completely.