https://visom-gis.oss-cn-beijing.aliyuncs.com/temp/scene%20(1).glb
https://visom-gis.oss-cn-beijing.aliyuncs.com/temp/1679967479351%20-%20副本.babylon
- I serialize the scene to a babylon file. The babylon file is 420MB
- By using “GLTF2Export” of the sandbox ,I get a glb file from the babylon file.The glb file is 17MB.
- I tried to save the scene (which was loaded by the babylon file) in a babylon by serialize again without any others, it failed.
- I tried to save the scene (which was loaded by the glb file) in a babylon by serialize again.
I noticed that the serialized scene’s materials is 4700+ of step 3 and the step 4 is 31
So, what happened? Why the babylon file is much bigger than the glb? And why it failed when serializing again?
Hello,
Just to clarify the scenario, your original scene is the one in .glb format, and then you saved it as a .babylon? Because there’s a difference between the two scenes, the .babylon one has this extra plane:
that the .glb doesn’t seem to have:
The original file is the babylon! The glb is from the babylon by GLTF2Export method.
The step 3 and 4 are serialized the scene by loading babylon and glb file differently.
The babylon file is so much bigger, because it is a text file, and there is no precision restriction on floats (the entire file) when this is being done.
Also worth noting is those 4700+ materials in the original file:
The .babylon save will attempt to save all those materials as they are, while the .gltf/.glb only saves one copy of those repeated materials. As why the original file has this many materials, we’d have to see the original scene to know.
It probably failed when serializing again because the original file was at the limit of serialization size, and when loading again in the sandbox, it creates a few extra materials for the environment, which are serialized along with the already existing ones. And these extra materials made it go over the string length limit. I’d recommend cleaning up your original scene.
2 Likes
Does it mean the babylon file could not be smaller or just like the size of the glb file without any other problems like repeated materials?
I found the reason of those repeated materials. The node was disposed but the materials of that node were not.The babylon file was 107MB after I cleaned up those repeated materials,aslo much bigger than the glb (17MB).
Like the reason @JCPalmer mentioned, can the babylon file be saved smaller?
As Palmer mentioned, the .babylon file is a text file, so it will inevitably be bigger than the .glb.
If you have the possibility to do so, you can try to zip the file, which could reduce its size significantly.
Sorry, this parts needs further clarification. @bghgary pointed out correctly that the GLTF export won’t care if the materials are repeated or not, and that’s true. What is happening is that, of those 4700+ materials, only ONE of them is being used, so it is the only one saved. To be more specific, this PG shows there are 4711 repeated materials: Babylon.js Playground (babylonjs.com)
1 Like
