FBX2glTF: converting Autodesk FBX assets to glTF 2.0 from the command line

Running a conversion and wiring it into a pipeline

The simplest invocation takes a positional path and does the obvious thing:

> FBX2glTF ~/models/butterfly.fbx

A pipeline wants the explicit form, which the README shows with line continuations, the binary `.glb` container, and Draco mesh compression applied:

> FBX2glTF --binary --draco --verbose \
         --input ~/models/source/butterfly.fbx \
         --output ~/models/target/butterfly.glb

Note that `--output` is documented as where to generate the output without a suffix, so the `.glb` extension in the example is the container the `--binary` switch implies rather than a path you should type. The positional form and the `--input` flag are interchangeable for a single file.

`--help` is the real documentation here. The README reproduces the full option list, and it is a long one: `-v` for verbose, `-e` to embed buffers, `-b` for binary output, `--long-indices`, `--compute-normals`, `--anim-framerate` with a bake24, bake30 or bake60 choice, `--flip-u` and `--flip-v` with their negative forms, `--user-properties` to transcribe FBX user properties into glTF extras, and the two blend shape switches for normals and tangents.

Facebook also hosts a hands-on tutorial for converting to `.glb` for sharing, linked from the README, which is the more useful starting point if you have never run a DCC to real time conversion before.

The V flip is the default and the first thing to check

The single most consequential default in this tool has nothing to do with geometry. `--flip-v` is on by default, and the README explains why in terms of the two formats disagreeing about where the origin of a texture sits. An FBX file is likely authored assuming `(0, 0)` is bottom left, while glTF puts `(0, 0)` at top left, so the converter applies an `x -> (1.0 - x)` mapping to all V texture coordinates to produce spec compliant output.

If your textures already arrive flipped, or your assets were authored in a glTF-centric coordinate system, you want `--no-flip-v`, which disables the transformation. The U equivalent exists but the README notes it is less commonly used, which makes sense: the vertical axis is where the disagreement is.

Two other geometry defaults are worth knowing before you debug a model that looks wrong. `--compute-normals` defaults to replacing empty normals, which glTF forbids; the `missing` value implies `broken` and additionally creates normals for models that lack them entirely. And `--long-indices` defaults to `auto`, choosing 16 or 32 bit indices per mesh size, which you can force with `never` or `always` when you are debugging an importer that disagrees with you about index width.

If you supply any `--keep-attribute` option, you enter a mode where you must repeat the flag for every attribute you want kept, which is a blunt instrument for trimming a file you know carries superfluous attributes. The accepted values are `position`, `normal`, `tangent`, `color`, `uv0` and `uv1`.

Draco compression and what its bit defaults actually cost

Draco mesh compression is a single switch with five tuning parameters underneath it, and the defaults are opinionated in a way worth understanding:

-d,--draco
--draco-compression-level INT in [0 - 10]=7
--draco-bits-for-position INT in [1 - 32]=14
--draco-bits-for-uv INT in [1 - 32]=10
--draco-bits-for-normals INT in [1 - 32]=10
--draco-bits-for-colors INT in [1 - 32]=8
--draco-bits-for-other INT in [1 - 32]=8

The structure of those defaults is the useful part. Positions get 14 bits, which is the highest value and reflects that vertex position error is the first thing anyone sees. Normals and UVs get 10 bits each. Colors and everything else get 8. The compression level default of 7 sits near the top of a 0 to 10 range.

Each of these is a separate quality decision, and they interact. Lowering bits for positions is the fastest way to make a Draco-compressed model look visibly wrong at close range, while bits for normals below what your lighting needs produces shading artefacts that are harder to attribute. If you are converting for a target with a known pixel budget, these five numbers are the knobs to sweep rather than the compression level alone.

One more Draco-related consideration: the output has to be decoded by a runtime that supports the extension, so this is a choice about your renderer as much as your asset pipeline.

Materials, embed mode and the honest works-in-progress note

The material switches are three, and the README does not oversell them. `--pbr-metallic-roughness` tries to glean native glTF 2.0 PBR attributes from the FBX, `--khr-materials-unlit` requests an unlit shader through that extension, and there is a third materials-related option noted as also being a work in progress. The README says all three are works in progress in their own way, then adds the useful distinction that `--pbr-metallic-roughness` is at least compliant with the core spec, unlike the others which depend on unratified extensions. If you supply none of them, it is chosen by default.

That distinction is the practical guide. Core spec compliance means your output loads in any glTF 2.0 runtime; an unratified extension means you are betting on a particular viewer's tolerance.

`--embed` deserves its own warning because the README gives one of the more honest explanations in the project. It inlines binary buffers as `data://` URIs inside non-binary glTF, base64 encoded, producing a single distributable file without the binary container. The README describes this as a very slow and space consuming way to accomplish what the binary format was invented to do simply and efficiently, while noting it can be useful for loaders that do not understand `.glb`. If you have the option, use `--binary` instead.

`--user-properties` is a smaller feature worth flagging for pipeline people: it transcribes FBX user properties into glTF node and material `extras`, which is how you carry custom metadata across the format boundary.

Building it yourself with conan and the FBX SDK

Precompiled binaries for Windows, macOS and Linux are linked from the README as releases, and it separately links continuous build artefacts for Windows, describing Linux and macOS there as forthcoming. So a source build is the realistic path on those two platforms.

The dependency chain is the part to understand first. The converter needs Autodesk's FBX SDK, which is not open source and which `FindFBX.cmake` locates. Around it, the repository carries `conanfile.py`, so the C++ dependencies are handled by Conan rather than by hand. The `Dockerfile` shows the whole sequence in one file, starting from `ubuntu:16.04`, adding `build-essential`, `cmake`, `libxml2-dev` and `zlib1g-dev`, installing Conan through pip, and registering the bincrafters remote:

pip install conan && \
conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan

It then downloads and installs FBX SDK 2019.2 for Linux, and builds with:

conan install . -i docker-build -s build_type=Release -s compiler=gcc -s compiler.version=5 -s compiler.libcxx=libstdc++11
conan build -bf docker-build .

Two things to note if you follow that recipe today. The Dockerfile pins Python 3.6 via a PPA and pins GCC 5, and it points at `api.bintray.com` for Conan packages, and Bintray was shut down, so that remote will not resolve as written. A `docker-compose.yaml` is present with a single `fbx2gltf` service that builds from the local context, which gives you a container shape to rework rather than a working image. The `src/` and `third_party/` directories are where the converter and its vendored code live, and there is an `npm/` directory at the top level for the JavaScript wrapper.

A 2019 release line in a 2026 repository

The repository is not archived, but the release history explains a lot about where this project sits. There are three tags: v0.9.5 in March 2018, v0.9.6 in July 2019, and v0.9.7 in August 2019. The last push to the default branch was on 2026-03-27.

The v0.9.7 notes are specific and useful for understanding what kind of project this is. That patch fixed a struct initialisation issue that could damage vertex deduplication in the presence of blend shapes, producing redundant and bloated output files, and the notes observe that the problem seemed to be constrained to Windows. A fix like that is a good example of the failure modes unique to a converter: the file still opens, it just gets bigger, and the cause is a memory layout bug rather than a logic error in the format mapping.

That gap between the newest release and the last commit is the main thing to weigh before adopting this. The code is being touched, but there is no tagged release after 2019 to point at, so a deployment that wants a versioned artefact rather than a moving branch is pinned to a converter that predates current glTF extension work by several years.

The licence is BSD 3-Clause, shown by the badge at the top of the README. The vendor terms that matter more for this particular tool are Autodesk's, since the FBX SDK is what you are building against.

Editorial conclusion

FBX2glTF is the tool to reach for when you have FBX assets from a DCC pipeline and need them as glTF for a real time renderer, and its value is that it makes every conversion compromise explicit instead of silently picking one. The texture V flip default, the Draco quantization defaults, and the per-mesh index width choice are the three decisions worth checking against your assets first. Where it stops is release cadence: the newest tag is v0.9.7 from August 2019 and the last push was on 2026-03-27, so pin the version, keep the FBX SDK build reproducible with `conanfile.py` and `FindFBX.cmake`, and read the material switches section of the README, since those are the ones the documentation calls works in progress.

Frequently asked questions

Official sources

1. facebookincubator/FBX2glTF on GitHub
2. Issues
3. README
4. Releases