3D model exported from sandbox is 200Mb in size as a .glb but is 800Mb as a .babylon?

Hello everyone,

I have a 3D model (415Mb) that I import in the sandbox to add lighting and shadows. When exporting it to a .glb, the file size is 200Mb, but when I do the same as a .babylon file, its size is 800Mb? As far as I know, the sandbox doesn’t provide any export setting for babylon files. Is there something I missed?

Hello :slight_smile:

  • Short answer : .glb is binary, .babylon is text file
  • Plus, it’s JSON based

The 2 reasons above makes so that .babylon being 4 times heavier is not surprising.
Just an example : take a floating number : -768.7770161930185

  • binary : 32 bits (4 bytes)
  • text files : at least (considering ASCII which is the lightest possible) as many bytes as chars, which in that case is 18, +1 considering the coma (list), total 19 bytes (versus 4 bytes).
1 Like

Hi, thank you, this explains a lot. I guess optimizing the file is the only option left on the table, then.

You may try this optimizer - https://glb.babylonpress.org/

2 Likes

The glTF exporter currently also has a number of issues like duplicating buffers and meshes when it shouldn’t. This will be addressed eventually but keep that in mind.

2 Likes

Hi, thank you for the tool. I’ll give it a try.

I am looking forward to it

I have wondered if it would be worth implementing size-optimized import/export for a few data structures used in babylon objects. Are there hooks in getVertexBuffers() or ImportVertexData() to allow customization?

Option 1: BSON
Option 2: reduced-precision ASCII (for floating point arrays)
Option 3: BASE64-encoding for numeric arrays
Option 4: BASE92-encoding for numeric arrays

BASE92 seems the most generically useful and only 20% overhead from raw arrays (not counting the metadata of type and length). Objects/arrays in BASE92 would fit well into JSON structure.

Optimizing Float32Array seems most useful. Then the arrays within a VertexBuffer including arrays of BYTE, INT, UNSIGNED_INT, FLOAT, SHORT, UNSIGNED_BYTE, and UNSIGNED_SHORT.

Edit: maybe Babylon already implements something like this already? I did some internet reading and given that base64 encoding/decoding is built into javascript, that may be a better place to start than base92. However, there are also very lightweight implementations of JSON support of TypedArray objects as well as lightweight Uint8Array to/from Base64. I expect further complexity in memory management and in Endianness (see ArrayBuffer vs. TypedArray vs. DataView).

Simple base64 to/from Uint8Array:

Very simple JSON typed array support without base64:

JSON support of typed arrays (no base64 encode):

Full typed JSON: