Glb vs glTF, size/performance advantages?

Questions
4

There isn’t a right answer which one is better. It depends on the situation.

Ways to store glTF on a server

  1. Loose glTF files contains:
    • The glTF JSON file
    • Zero or more .bin files (for geometry / animations)
    • Zero or more image files (for textures)
  2. Self-contained GLB:
    • The GLB includes everything from the loose glTF files in one file without compression.
  3. GLB with external references:
    • There are multiple ways to configure this, but one possible usage is to put the geometry with the GLB but not the image files.
  4. glTF with Base64 embedded binary.
    • Avoid this since it is both bigger and slower to encode/decode. Sorry @JCPalmer :slight_smile:

Servers can be configured to compress files that are being served. Compressing files that are already compressed (e.g., .png or .jpg) is typically not a good idea because compressing these files do little to reduce the payload and decompressing these files cost time. It’s a lose-lose.

Depending on network conditions, downloading multiple streams in parallel may have faster overall throughput than a single serialized stream. Each network request has overhead. Doing a lot of small requests is usually bad if the payloads are small.

The reason why GLB was originally created is to make it such that the geometry/animation data and the glTF JSON can be combined into one file and thus one request. This payload can also be compressed which saves bandwidth. The image files are often bigger and thus should be uncompressed and downloaded in parallel. This is my general recommendation given no information about the assets.

Nowadays, people use GLB as a self-contained single asset for convenience when working with them, but it is probably not the best layout on a server.

At the end of the day, the only way to know for sure is to measure and see which one works best for your scenario.

3 Likes