nem0/OpenFBX: a lightweight FBX importer for C

What OpenFBX loads from an FBX scene

OpenFBX addresses the problem of bringing FBX scene content into a C application without requiring a complete engine around the importer. The README identifies geometry as a supported area, along with UVs, normals, tangents, and colors. It also lists skeletons, animations, blend shapes, materials, textures, cameras, and lights. This makes the library relevant to importers, asset pipelines, editors, engines, and tools that need to convert an FBX file into application-specific runtime data.

The project describes itself as an "almost" full-featured importer. That wording matters because the README presents broad scene coverage without promising every part of the FBX format. It does not document unsupported object types, version handling, conversion guarantees, or behavior for malformed files. A potential adopter should therefore treat the feature list as a scope statement, not as a complete compatibility specification.

The intended reader is a developer who is already familiar with FBX. The README recommends learning about the format before using the library and links Autodesk documentation. This points to a low-level integration model. OpenFBX loads scene information, but the README does not say that it supplies a scene graph abstraction suitable for every engine, a complete export pipeline, or automatic conversion from FBX materials to the conventions of a particular renderer. Applications still need to decide how imported data maps to their own buffers, objects, and rendering APIs.

OpenFBX source integration and decompression

The documented library integration method is source based. The README tells users to add the files from the repository's `src` directory to their own project. The repository also contains `runtime`, `demo`, `projects`, `CMakeLists.txt`, and `openfbxConfig.cmake.in`, but the README presents CMake support as community maintained rather than supported by the project author.

The importer is written in C, and the README names libdeflate as the decompression library. This confirms that decompression support is part of the import path rather than something the README says applications must provide. The documentation does not explain the internal loader sequence, public data structures, memory ownership rules, threading guarantees, or error-reporting contract. Those details need to be established from the source code and the linked examples before the library becomes part of a production pipeline.

The source layout also suits embedding the importer in a native application. The README does not describe a separate runtime service or installable package. `demo/main.cpp` serves as the basic example, while the Lumix Engine importer is cited as a more advanced use case. That difference is useful when judging integration effort. The demo indicates a direct use path, while the engine importer suggests production consumers may need substantial conversion after OpenFBX has loaded the file.

Building the Windows demo and loading a first file

The repository documents a Windows-only demo build. The steps are to download the source code, execute `projects/genie_vs19.bat`, open `projects/tmp/vs2019/OpenFBX.sln` in Visual Studio 2019, and compile and run the project. This is a specific first check for Windows developers because it tests the documented setup rather than requiring an assumed command-line workflow.

The demo is Windows only, while the README describes the library as multiplatform. The repository does not document equivalent demo commands for Linux or macOS, so those platforms require application-side integration based on the source and examples. The visual screenshot in the README indicates that the demo presents an interactive viewer, but the README does not specify which FBX assets it loads by default.

For direct use in another project, the README gives a shorter path:

add the files from src to your project

That instruction is a repository operation rather than a shell command. The next step is to follow the API initialization shown in `demo/main.cpp`. The README does not provide a complete include list, public function signature, sample filename, or standalone command for loading an FBX file. Those details should not be guessed. The linked demo is the documented source for the exact C API and initialization sequence, while Lumix Engine's `fbx_importer.cpp` provides the more advanced example.

FBX coverage leaves conversion work to the application

OpenFBX covers several asset categories, but its documentation leaves the boundary between file loading and application processing unclear. Geometry with UVs, normals, tangents, and colors may still require conversion into the conventions of a particular renderer. Skeletons and animations may need mapping to an engine's bone hierarchy, timeline representation, and sampling rules. Materials and textures may require application-specific interpretation. The README confirms support for those categories, but it does not claim that every engine can consume them directly.

Blend shapes, cameras, and lights are named explicitly. That is useful when comparing the library with a general-purpose FBX SDK, but it does not establish identical behavior for constraints, instances, keying, animation layers, embedded media, or other FBX features. The repository description does not document those subjects, so the supported conclusion is limited to the listed categories. Anything outside that list requires inspection or testing against actual assets.

The direct-source model also transfers build maintenance to the integrating project. A team chooses which files under `src` to add and must keep them synchronized with its own project configuration. The README does not document versioning, compatibility guarantees, or an upgrade procedure. The repository has no GitHub releases, so there is no published release series that can serve as a documented integration baseline. The last push was on 2026-05-16, and the repository is not archived. This records repository activity, but it does not establish a support commitment or release cadence.

Failure modes when OpenFBX is the wrong fit

The clearest failure mode is an incomplete expectation about API ownership. If an application expects a finished editor import pipeline with automatic mesh construction, renderer-compatible materials, scene ownership, and production error handling, OpenFBX may expose only part of that work. The README lists supported FBX content but does not promise those higher-level conveniences. Teams that do not want to inspect the C data structures or write conversion code should identify that mismatch before vendoring the source.

Another risk comes from direct source integration without a documented release line. Adding the current `src` files makes an application dependent on the repository revision it copied. Later updates can alter source files or interfaces, and the README provides no migration notes. There are also no GitHub releases against which to compare an upgrade. This does not make updates impossible, but it makes source review and revision tracking part of the adoption cost.

Input compatibility remains another open question. The README does not state supported FBX versions, binary and ASCII handling details, behavior for malformed files, or whether every producer exports the listed features in the same way. A failed import cannot be attributed confidently without knowing which of those concerns applies. The linked demo is a starting point for evaluating the public API, but it is not a compatibility matrix.

Comparing OpenFBX with UFBX

The README names UFBX as a similar project written in C. That is the only alternative approach described in the OpenFBX documentation. It identifies another C FBX loader that can be inspected before an application commits to OpenFBX, but the README does not compare API shape, feature coverage, build requirements, file compatibility, or maintenance history. It therefore does not support a claim that either project is smaller, faster, more complete, or easier to adopt.

The documented difference in context is that OpenFBX says it is used in Lumix Engine and Flax Engine, while also linking a Lumix Engine importer as a more advanced example. UFBX is presented only as a similar C project. This may make OpenFBX more directly relevant to an engine integration patterned on Lumix, although the README does not provide enough detail to judge how closely its API matches other engines.

A meaningful comparison would load the same project FBX files in both libraries, map their outputs into the target application's data structures, and inspect build integration. The README does not supply those results. Until that comparison is performed, UFBX remains a documented alternative rather than a demonstrated upgrade path from OpenFBX.

MIT licensing and direct-source upgrade cost

OpenFBX is distributed under the MIT license, as indicated by the repository license metadata and the README badge. That is a permissive open source license, but integrators should read the repository's `LICENSE` file for its exact terms and preserve required notices where applicable. The README does not address whether exported FBX assets, embedded textures, or Autodesk tooling introduce separate terms, so this review is limited to the library's stated license.

Maintenance responsibility extends beyond copying files. A project must decide which files under `src` belong to its build, ensure that libdeflate is available, and track the exact OpenFBX revision used. The README names libdeflate but does not provide dependency configuration instructions in the integration section. It also does not document a compatibility range for that dependency. Direct consumers therefore need to confirm the actual include and linkage expectations from the source rather than assuming package-manager installation.

The repository is not archived, and the last push was on 2026-05-16. However, there are no GitHub releases, no documented semantic-versioning scheme, and no support policy in the README. The practical upgrade cost is source review and regression testing rather than a documented package version bump. Projects that cannot record revisions or validate imported scene changes may find that maintenance model inconvenient.

Editorial conclusion

OpenFBX suits C applications that need a compact FBX loading path and can work directly with FBX-oriented scene data. It is a poor fit for teams that require a documented, supported high-level API or a turnkey asset pipeline without understanding FBX internals. Evaluate it first by checking whether your expected FBX features map to the importer scope, then inspect demo/main.cpp and confirm that adding the src files fits your build system.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nem0/OpenFBX on GitHub
4. README