# What is the advantage of binary FBX files over ASCII ones?

I know that the size does matter but except for this advantage, are their any other advantages to using binary files instead of the ASCII format in real production workflows?

ASCII files have a lot of advantages: human-readable, easier to integrate and debug, VCS, etc.

In general you don't use any such format directly as an asset in production. It's fine to add code for loading them, and to use them as an intermediate format for development, but for production you don't really go down that route. Instead, for production you want to use e.g. a model format that you can load fast and directly; e.g. and in OpenGL, you'd want to be able to do something like this:

void *data = glMapBuffer (GL_ARRAY_BUFFER);


The same would apply to any other asset type.

This approach requires no parsing whatsoever, it loads directly into the final buffer (or other container) from which it's going to be used, it's friendlier for content streaming approaches, and all the hard work of debugging/etc will (hopefully!) already have been done using the intermediate format, so those advantages don't apply.

• "you don't use any such format directly" - Can you precise which format you are talking about please? Nov 26 '13 at 5:15
• He was precise, "any", you create a custom format that holds only and exactly what your game needs, in the order it needs it in. Nov 26 '13 at 11:36
• @Korchkidu - what MickLH says: "any" means "any". Nov 26 '13 at 16:28
• Well, you have to use some of these formats at least to get some assets in your pipeline. Not even mentioning unity 3D. Simply put, you have a pipeline like Maya -> FBX -> (Custom Format) -> Game Engine. With unity 3D, you do not even need a custom format. Nov 26 '13 at 16:39
• NOTE: i am talking about workflows so during development. Maybe my term "production" adds some confusion. Nov 26 '13 at 16:46

The advantages of binary FBX over ASCII FBX are most immediately; speed of reading and the size of the file.

Another significant advantage would be that it is possible to build your own parser and asset importer for the ASCII flavour. The binary format has never been (officially) publically documented.

I would also challenge the degree of advantage ASCII FBX has over binary FBX in a few areas.

While ASCII is considerably more readable than binary, it may not be practically relevant. Many exported models are large and complex to read even as ASCII text. You're unlikely to venture into the file except for debugging. This is more likely if you're building your own parser but otherwise considering how mature the format is, I don't see there is much call to poke around in it. Likewise you're only going to be fixing the reading side, since the exporter is proprietary.

### VCS

Because of the way the text is organised in an ASCII FBX, anything but the smallest changes cause merge conflicts to rival the problems you face in using the binary form.

As for production workflows my answer would only echo MFAHs response above. Ideally use FBX as an intermediate format only. Process them into a binary format well suited to your title, which may include raw buffers and the like.

Binary files load much faster than ASCII files --

// open it
FILE *fin = fopen( "binary.fbx", "r" ) ;
// get size in bytes
fseek( fin, 0, SEEK_END ) ;
size_t size = ftell( fin );
rewind( fin ) ;
unsigned char* bytes = (unsigned char*)malloc( size ) ;
fread( bytes, size, 1, fin ) ;
// THAT'S ALL FOLKS!


Meanwhile, an ascii fbx parser is pretty significant code size. Not that it'll take too long for a small model, but there is a speed advantage there.