I tested both solutions, but I have a problem in both cases.
In the .glb solution, my file weighs 700MB while the same in Babylon version only weighs 10MB.
Here is the .babylon concerned. To reproduce, simply open it in the sandbox and re-export it in GLB.
In the solution to include the textures in the .babylon, I have an error message that I don’t quite understand.
How big are your textures?
and how many are there?
So, the babylon file’s 10MB is probably without textures since they errored out…?
Storing textures in a .babylon file (json) is done as a base64 string, which should result in a larger total size than the GLB. AFAIK.
It purely exists for convenience, and is not suited for a production environment, unless using very small models/textures where the loading difference would only be a few ms.
I don’t think it comes from the textures, because the test carried out with the .babylon provided allows us to account for the problem without even adding a texture.
Just, by loading the .babylon into the sandbox (without textures, 10MB) and exporting it to GLB without any modification, the output file reaches 700MB.
I seem to remember that we recently had a problem with a small source file being exported to a very large file, but I don’t remember the details or the cause of this behavior (and even if it was in the context of a .glb export)…
I haven’t verified this, but most likely what is happening is that there are vertex buffers being shared. The glTF exporter probably will duplicate the shared buffers and cause an explosion in size.
Lol, so it’s not what I said at all. The reason why the export is so big is because there are a bunch of animations in the scene that are animating the rotation via rotation.x which causes the glTF exporter to bake the animation because glTF can’t animate x by itself. This animation is repeated many times in the scene: