F3D: A Command-Line 3D Viewer for glTF, STL, STEP and USD Files

What F3D solves, and who ends up using it

Opening a 3D file usually means launching a heavy modelling application, waiting for it to start, and then fighting a UI built for editing when all you wanted was to look. F3D takes the opposite position. The README describes it as a "fast and minimalist 3D viewer desktop application" that is "fully controllable from the command line and supports configuration files." One command opens a file. Appending --output writes the render to an image instead of opening a window.

The stated vision is explicit about scope: support as many 3D formats as possible, show meshes, volumes and point sprites, be usable non-interactively, and stay buildable with a small dependency set. The same list says there is no plan to provide a classic mouse-based UI with menus and buttons, no data processing tools, and no export feature. That last point matters more than it looks. F3D displays geometry. It does not convert it.

The people who benefit are engineers with a directory of CAD or simulation output, pipeline authors who need a render step inside a script, and developers embedding a viewer in their own application through libf3d. Anyone who needs to edit a mesh, repair a solid or save a different format should look elsewhere. The project says so itself.

How the viewer is put together, from the CMake tree to libf3d

The repository layout shows the split clearly. There is application/ for the f3d executable, library/ for libf3d, and separate top-level directories for c/, java/, python/ and webassembly/ bindings. The README describes libf3d as "a simple library to render meshes, with a C++17 API and C, Python, Java, and JavaScript bindings." The same renderer therefore sits behind the desktop tool and behind every binding, which is why a scripted render and an interactive render look the same.

Format support is not written from scratch. The acknowledgments list VTK, OCCT, Assimp, Alembic, Draco, web-ifc, OpenUSD, OpenVDB, PDAL, OSPRay and ImGui as the projects F3D relies on. Each one covers a family of formats or a rendering path, and the vision statement's goal of modularity exists so that a build can drop dependencies it does not need. In practice this means the formats you can open depend on how your particular package was built, not only on the version number.

Rendering options include real-time physically based rendering and raytracing, plus texturing and edge display. The README also shows a direct scalars render, which is the path for scientific datasets where a scalar field is mapped to colour rather than a surface being shaded. Interactive hotkeys, drag and drop and file manager integration round out the desktop side.

Installing F3D and rendering a file from the terminal

The README does not give package manager commands. It points to the download page, which "lists the latest release packages and installation options for supported platforms." Install from there, then confirm the binary is on your PATH. The README states that once installed, the f3d command should be available from your terminal.

Opening a file is a single command. The path is the only required argument:

f3d /path/to/file.ext

A window opens with the model loaded. The same command works for any supported format, so you do not pass a format flag for a normal glTF, STL, STEP, PLY, OBJ, FBX or Alembic file.

To render without a window, append the output option. The README gives this exact form:

f3d /path/to/file.ext --output=/path/to/img.png

The render is written to the PNG path and no interactive window is needed, which is what makes the tool usable in a batch script or CI job. The README points to doc/user/01-QUICKSTART.md for the rest of the options, and to doc/libf3d/01-OVERVIEW.md if you intend to call the library rather than the executable.

Python users have a second route. The pyproject.toml declares a project named f3d requiring Python 3.10 or newer, built with scikit-build-core and pybind11, and the wheel installs into a f3d directory. The package metadata lists Windows, POSIX and macOS as supported operating systems.

Where F3D is the wrong tool

The missing export feature is the sharpest limitation, and it is a deliberate design decision rather than a gap waiting to be filled. The vision list states plainly that F3D will not provide export. If your task is to read a STEP file and write an STL, F3D will display the STEP file and stop there. Searches for converting between those two formats land on F3D because it opens both, not because it converts between them.

There is also no data processing. No mesh repair, no boolean operations, no decimation, no measurement tools. The vision list rules out data processing tools in the same breath as the mouse-driven UI.

Format coverage is the third constraint, and it is the one most likely to surprise people. Because support comes from bundled third-party libraries, a given build may not include a given plugin. The README does not document which plugins ship with which package, so the download page and the package contents are the places to check. A file that opens on one machine may fail on another with a different install. The README does not describe the error behaviour when a format is unsupported.

Finally, the interaction model is keyboard and command line. There is no menu bar, no property panel, no scene tree. Users who expect a conventional desktop application will find the interface minimal to the point of feeling absent.

F3D against a general-purpose mesh tool

The obvious alternative is MeshLab, which also opens a wide range of 3D formats and is free and open source. The difference in approach is the axis each one optimises. MeshLab is an interactive processing application: you load a mesh, then clean, filter, simplify, align and export it through a graphical interface. Its value is in the operations it performs on geometry.

F3D performs no operations on geometry. Its value is in how little stands between a command and a rendered image. That makes it scriptable in a way an interactive editor is not, and it makes the same renderer available as a library with bindings in four languages. If your problem is "show me this file" or "render this directory overnight," F3D is the shorter path. If your problem is "this mesh has holes and I need to fix them," MeshLab is the tool and F3D is not, by the maintainers' own stated design.

The same comparison holds against a full CAD package. Those give you a modelling kernel and a document model. F3D gives you a viewport and a command line.

Licence, releases and what maintenance costs you

F3D is distributed under the 3-Clause BSD License. The README states that F3D integrates sources of other libraries and tools, all under permissive licenses, listed in THIRD_PARTY_LICENSES.md, and that the packages rely on other libraries and tools, also permissive, listed in the respective package. The pyproject.toml classifier records the licence as BSD. Permissive licensing at both layers removes the copyleft question that usually blocks embedding a viewer inside a commercial product, but the third-party list is the document to read before shipping, and this is a factual observation rather than legal advice.

The release history shows v3.5.0 on 2026-04-05, preceded by v3.5.0-RC3 on 2026-04-04, and an older nightly tag from 2022. The package.json version field matches 3.5.0. The repository is not archived, and the last push was on 2026-09-22, so work is ongoing. Note that the version in package.json describes the WebAssembly npm package, not the desktop release, and the two can move independently.

The maintenance cost on your side depends on which surface you adopt. The f3d executable is a binary you upgrade when you want new format support. libf3d is a C++17 API, so binding it into an application couples you to its interface. The Python package carries its own constraint: requires-python is >=3.10. Building from source means CMake 3.21 or newer and Ninja 1.10 or newer, per the scikit-build settings, and the dependency set is large enough that the project's own packaging lives in a separate repository.

Which surface to adopt: CLI, library, or browser

F3D ships in more than one shape and they are not interchangeable. The desktop executable is the right choice for manual inspection, file manager integration and shell scripts that call f3d with a path and an --output target. The library is the right choice when rendering has to happen inside a longer-lived process, and it is the only option if you are writing C++, C, Java or JavaScript against the API rather than shelling out.

The Python package sits between the two. It requires Python 3.10 or newer and installs a wheel built from the same CMake project. The README also mentions using F3D directly in a browser, and the repository contains a webassembly/ directory plus an npm package named f3d that exports dist/f3d.js. That npm package builds through a Docker image, ghcr.io/f3d-app/f3d-wasm, invoked by the build script in package.json. If you only need to look at a model once, the browser viewer on the project site avoids an install entirely.

The distinction matters because the plugins bundled with a WebAssembly build and those bundled with a desktop package are not guaranteed to be the same set. Decide which surface you need before you evaluate whether a specific format opens.

Editorial conclusion

Adopt F3D if you need to open or render 3D files from a shell, a batch job or another program, and you can live without editing or export. Skip it if your workflow depends on a menu-driven CAD interface or on converting geometry between formats. Before committing, verify that your specific format loads with the plugins your package ships, and confirm whether you need the f3d executable, the libf3d bindings, or both.

Frequently asked questions

Official sources

1. f3d-app/f3d on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases