This is a command line tool for converting 3D model assets on Autodesk's venerable FBX format to glTF 2.0, a modern runtime asset delivery format.
This tool has been tested on Linux, Mac OS X and Windows. It requires CMake 3.5+ and a reasonably C++11 compliant toolchain.
We currently depend on the open source projects Draco, MathFu, Json, cppcodec, cxxopts, and fmt; all of which are automatically downloaded, configured and built.
You must manually download and install the Autodesk FBX SDK 2018.1.1 and accept its license agreement. Once installed, the build system will attempt to find the SDK in its default location for each system.
Once that's all done...
Compilation on Unix machines should be as simple as:
> cd <FBX2glTF directory>
> cmake -H. -Bbuild
> make -Cbuild
If all goes well, you will end up with a statically linked executable that can be invoked like so:
> ./build/FBX2glTF ~/models/butterfly.fbx
Or perhaps, as part of a more complex pipeline:
> ./build/FBX2glTF --binary --draco --flip-v \
--khr-materials-common \
--input ~/models/source/butterfly.fbx \
--output ~/models/target/butterfly.glb
Windows users may download CMake for Windows, install it and run it on the FBX2glTF checkout (choose a build directory distinct from the source). As part of this process, you will be asked to choose which generator to use; it should be fine to pick any recent Visual Studio option relevant to your system.
Note that the CMAKE_BUILD_TYPE variable from the Unix Makefile system is entirely ignored here; the Visual Studio solution that's generated handles all the canonical build types -- Debug, Release, MinSizeRel, and so on. You will choose which one to build in the Visual Studio IDE.
The actual translation begins with the FBX SDK parsing the input file, and ends
with the generation of the core JSON description that forms the core of glTF,
along with binary buffers that hold geometry and animations (and optionally also
emedded resources such as textures.)
In the process, each node and mesh in the FBX is ripped apart into a long list of surfaces and associated triangles, with a material assigned to each one. A similar process happens in reverse when we construct meshes and materials that conform to the expectations of the glTF format.
Every animation in the FBX file becomes an animation in the glTF file. The method used is one of "baking": we step through the interval of time spanned by the animation, keyframe by keyframe, calculate the local transform of each node, and whenever we find any node that's rotated, translated or scaled, we record that fact in the output.
This method has the benefit of being simple and precise. It has the drawback of creating potentially very large files. The more complex the animation rig, the less avoidable this situation is.
There are two future enhancements we hope to see for animations:
- Version 2.0 of glTF brought us support for expressing quadratic animation curves, where previously we had only had linear. Not coincidentally, quadratic splines are one of the key ways animations are expressed inside the FBX. When we find such a curve, it would be more efficient to output it without baking it into a long sequence of linear approximations.
- Perhaps more useful in practice is the idea of compressing animation curves the same way we use Draco to compress meshes (see below). Like geometry, animations are highly redundant -- each new value is highly predictable from preceding values. If Draco extends its support for animations (it's on their roadmap), or if someone else develops a glTF extension for animation compression, we will likely add support in this tool.
With glTF 2.0, we leaped headlong into physically-based rendering (BPR), where canonical way of expressing what a mesh looks like is by describing its visible material in fundamental attributes like "how rough is this surface".
By contrast, FBX's material support remains in the older world of Lambert and Phong, with much simpler illumination and shading models. These are modes are largely incompatible (for example, textures in the old workflow often contain baked lighting that would arise naturally in a PBR environment).
Some material settings remain well supported and transfer automatically:
- Emissive constants and textures
- Occlusion maps
- Normal maps
This leaves the other traditional settings of Lambert:
- Ambient -- this is anathema in the PBR world, where such effects should emerge naturally from the fundamental colour of the material and any ambient lighting present.
- Diffuse -- the material's direction-agnostic, non-specular reflection, and additionally, with Blinn/Phong:
- Specular -- a more polished material's direction-sensitive reflection,
- Shininess -- just how polished the material is,
(All these can be either constants or textures.)
Increasingly with PBR materials, those properties are just left at sensible zero
or default values in the FBX. But when they're there, and they're how you want
to define your materials, one option is to use the --khr-materials-common
command line switch, which incurs a required dependency on the glTF extension
KHR_materials_common. Note that at the time of writing, this glTF extension
is still undergoing the ratification process, and is furthermore likely to
change names.
Given the command line flag --pbr-metallic-roughness, we accept glTF 2.0's PBR
mode, but we do so very partially, filling in a couple of reasonable constants
for metalness and roughness and using the diffuse texture, if it exists, as the
base colour texture.
More work is needed to harness the power of glTF's 2.0's materials. The biggest
issue here is the lack of any obviously emerging standards to complement FBX
itself. It's not clear what format an artist can export their PBR materials on,
and when they can, how to communicate this information well to FBX2glTF.
The tool will optionally apply Draco compression to the geometric data of each mesh (vertex indices, positions, normals, per-vertex color, and so on). This can be dramatically effective in reducing the size of the output file, especially for static models.
Enabling this feature adds an expressed required dependency in the glTF on the
KHR_draco_geometry_compression extension, and can thus only be loaded by a
viewer that is willing and able to decompress the data.
Note that at the time of writing, this glTF extension is still undergoing the ratification process.
This tool is under continuous development. We do not have a development roadmap per se, but some aspirations have been noted above.
- Pär Winzell
- J.M.P. van Waveren
- Amanda Watson
FBX2glTF is BSD-licensed. We also provide an additional patent grant.