After working with glTF for a while and its various sub-formats, I believe there is only one type of glTF that makes sense.
When sending glTF files around, artists always, without fail, forget to include the associated .bin file. Every single time. I understand that having a separate file for binary data makes it easy to edit the JSON info, but if Khronos would just make a hard decision and say “glTF always uses binary data embedded at the end of the file” plugins would arise for various text editors that were capable of editing the JSON portion of the file without mangling the bin data.
On the other hand, packing textures into the file really serves no purpose other than making it harder to get to the textures.
If it were up to me I would get rid of the four sub-formats (text glTF, glTF + bin, glb, glTF base64) and just lock things into the layout I described here.
My software supports all of these sub-types, but it is an awkward conversation when I have to explain to people, “well, actually no one could make up their mind and glTF is actually four different formats…”. It would also result in better support for importers, since trying to wrangle all these options is one of the major challenges in loading these files.
glTF has more users than those like yourself. Yes, it is very convenient to be able to have a single file that represents everything associated with some asset. But glTF also needs to serve people who don’t need that too, who want binary data to be able to be shared among several assets in a scene.
Yes, this means that those generating/finding the assets need to know how they’re going to be used and need to properly deal with them. But that’s no different than today. The only difference is that you’d force users with different needs to use a completely different format that is functionally 99% identical to glTF but doesn’t have a forced data packet under it.
Why would two glTF files need to share the same binary data?
Because they may share the same binary data? Maybe they use the same textures or even mesh components. Maybe a group of meshes use some shared decal that is replaced with team indicators.
My point is that you’re presuming that a glTF file is supposed to be the 3D equivalent of a 2D image: a single file that represents 100% of all of the information needed to reproduce some asset. And while that is a perfectly valid use of glTF, that’s not the only use case for the format.
My feeling is that both “.gltf + external resources” and “.glb + embedded resources” are essential.
Shared texture data across multiple models is very common, at the least. Some applications prefer .gltf with external resources so that parts of the asset – like animations – can be lazily loaded from separate .bin files as they’re needed. While that could also be implemented on .glb with HTTP Range Requests, there are good reasons an application might prefer the separate external resources.
I agree that “.gltf + base64” should generally be discouraged. Blender 4.0 has removed this from its export options, and optimization tools like glTF Transform and gltfpack have intentionally never supported writing in that layout.
I think “text .gltf” is really just a special case of .gltf, when the model happens not to have any binary resources, so you don’t need to choose between embedding or externalizing the resources.
1 Like