This is Part 3 in our series, "Ben Houston's Ultimate Guide to 3D File Formats".
What is the FBX file format? The Autodesk FBX file format is a popular 3D data interchange format utilized between 3D editors and game engines. It was originally created as the native file format for Kaydara’s Filmbox motion capture tool. The FBX format name and extension is derived from that application name FilmBox. In 2005 Kaydara released a public SDK for the otherwise closed and proprietary FBX file format and engaged in a concerted PR campaign to encourage the adoption of the FBX file format for high quality 3D data interchange between different tools. Filmbox was eventually renamed MotionBuilder and later acquired by Autodesk.
Should you use the FBX 3D file format? It depends on what you are using it for.
Here are the pros and cons:
Wide Feature Support
The FBX format is the goal standard in its support for the variety of data in its format. FBX supports 3D models, scene hierarchy, materials lighting, animations, bones, skinning as well as blend shapes. FBX, as it is older format, also supports data that isn’t widely used today such as NURBS surfaces and curves. When you choose FBX as your interchange format you know that on the geometry side of things it can likely represent the data you need.
Separate Position, UV and Normal Topologies
A strength of the FBX file format, one that is also shared by the OBJ 3D model format, is that it enables the storage of both position, UV and normal data that has different topology. This is great for high quality modeling tools, and enables complex features like accurate subdivision surfaces. This makes it a bit harder to load these models into game engines as that data needs to be preprocessed in order to unify all of the topologies.
Fast and Efficient
The FBX file format, because it utilizes a binary format, is both fast and efficient. This is because when one stores data as binary it is faster to write and read it as opposed to a text-based format that must convert binary data to and from human readable numbers. It is also efficient in terms of space because binary representations of numbers take up less space than human-readable numbers. Binary formats can often be complex if you need to read and write to them directly but the FBX SDK hides this completely completely form the user of the FBX SDK.
If you are a developer using a language supported by the SDK, it is very powerful and convenient to integrate the FBX file format into your application. The process of adding FBX import and export is a relatively simple and straightforward process of linking the SDK and then using its API to stream data in and out. All the complexity of the file format is hidden from the software developer integrating the SDK. And one does not need to worry if the SDK supports all of the FBX features because it is the official and one-and-only FBX SDK.
In part, because the SDK ensures that it can read all previous versions of the FBX file format, ensures that most modern versions of tools can correctly read the FBX files produced by other tools. Even if the FBX file format changes, the SDK can ensure that it can read both the old format and the new format via different code paths that are transparent to the user of the SDK. As such FBX is not riddled with compatibility problems that have plagued similar complex formats such as COLLADA. If FBX properly supports a feature, then it can transfer that data between applications without much concern.
As such, FBXs can be used to transfer complex 3D scene data easily between Clara.io, 3DS Max, Maya, Unity 3D and Unreal Engine.
The biggest downside of the FBX format is that it is a closed format. The only official way to access the data in FBX files is to use the official SDKs. If you want to load an FBX on a system that is not officially supported by the FBX SDK (such as in a web browser or an open source application) you can not do so. (Although recently, after a couple years of effort, Blender has successfully reverse engineered most of the current version of the FBX format.)
Because it is a closed format, it is also not possible for anyone to evolve the format except for its owners Autodesk. Its’ owners have recently not made many changes to the FBX file format and as such it has somewhat stagnated.
Wide Feature Support
This was listed in the pros but it is also a con. The issue with FBX’s wide data support is that many of its support data types are legacy and not regularly used any more. Besides its dated material and lighting models (which are covered below), FBX also supports NURBS surfaces and curves. These are significantly complex to support as they require a full CAD kernel to be part of the FBX SDK, but they are rarely used in today’s games and 3D editors for media and entertainment. Legacy features like NURBS support adds significant complexity to the FBX file format that make it hard and costly to maintain and its SDK is very large and difficult to integrate into mobile games or other size restricted applications.
The FBX file format uses a 1990s era lighting model premised on the Blinn-Phong spec-glossy model, along with a single color or texture per material property. While this was sufficient for a minimalist material representation, it does not reflect the capabilities of modern 3D editors or game engines that utilize complex shader networks in concert with the Physically-Based Rendering material model centered around roughness-metalness. Nor does the simplistic FBX materials support sub-surface scattering, proper layered materials nor anisotropic effects. Because of the severe limits of FBX’s material model, most materials on 3D models have to be redone after they have been transferred between tools via the FBX format.
The lighting model in FBX again uses 1990s era conventions. Modern games and tools like ThreeKit use a physically based lighting model where all lighting parameters are grounded in physical quantities such as lumens, luminosity and physically based falloff. Modern game engines want to transfer global illumination information such as light probes and image-based lighting but FBX does not support this.. FBX uses a more historic and arbitrary lighting model which makes it difficult to communicate between tools that use the more modern and physically-based approaches. Like with materials, most lighting information transferred using the FBX file format has to be fixed or simply redone once it is imported into its target application.
You should use the FBX file format is you want to transfer data between the current popular 3D editors, like Maya, Clara.io, and 3DS Max, and 3D experience engines like Unity, Unreal Engine. This is really what the file format was designed for.
If your destination platform supports a more modern format like glTF, using glTF instead of FBX will save you time because it better transfers material properties.
If you want to use a format for fast real-time transfer to a client application, especially for AR applications, FBX can be slower than a transmission optimized format like glTF.
Clara.io supports importing and exporting both FBX, glTF and OBJ files with ease.