libfive solid modeling with functional representations

libfive targets programmable solid-model infrastructure

libfive addresses a specific part of CAD development: representing and manipulating solid geometry through functional representations rather than relying exclusively on a conventional mesh as the source model. A function-representation model describes geometry as a mathematical function that applications can evaluate, transform, combine, and ultimately mesh. The README positions libfive as infrastructure rather than a finished vertical modeling product. Its intended users are C++ developers embedding geometry capabilities into applications, programmers working through its C API, and teams that want scripting access through Python or Guile.

The project also reaches interactive users through Studio, a GUI in the style of OpenSCAD. Studio supports live-coded solid models and direct surface manipulation, where pushing or pulling on the surface changes variables in the script. That makes libfive relevant to programmers who want a scriptable modeling workflow, but it is not limited to the GUI. The repository is organized into `libfive/`, `studio/`, and supporting directories, with the core library, standard library, language bindings, and application forming distinct layers.

This separation matters when choosing a project. A developer embedding geometry does not have to use Studio, while a modeling user can start from the application while the underlying implementation remains available as a shared library. The README also identifies related bindings and viewers for Common Lisp, Python, Unity, Rust, Guile, and other environments. Those links indicate possible integration paths, although the README labels some of them as work in progress or unpublished.

C++, C, and generated Python and Guile interfaces

The core `libfive` shared library is written in C++ and exposes a C interface through `libfive.h`. According to the README, its functions cover building, manipulating, and rendering f-reps. The associated `libfive-stdlib` supplies common shapes, transforms, and constructive solid geometry operations. It is also implemented in C++ and exposed through `libfive/stdlib/stdlib.h`.

The data path described by the project begins with a functional solid representation. Higher-level shape, transform, and CSG operations produce or modify that representation. The meshing algorithm then converts it into a triangle mesh. The README characterizes the output as watertight, manifold, hierarchical, and feature-preserving. It also describes generated bindings for Guile Scheme and Python, which expose the standard library for use in a REPL or inside a larger application.

This is a meaningful choice for teams that want scripted geometry with a native core. It does not, according to the README, imply that the same binding depth or build options exist on every platform. Guile bindings are optional and documented as available only on macOS and Linux. Python bindings require Python 3.7 or later. Studio requires Qt 5.12 or later and either the Guile or Python bindings. The README does not provide a complete API walkthrough or binding comparison, so adopters would still need to inspect the headers, examples, and generated interfaces for a specific integration.

Ubuntu source build and Studio first launch

The README documents source compilation rather than a package-manager installation or GitHub release. It says libfive and Studio support macOS, Linux, and Windows. The Ubuntu instructions target the latest Ubuntu LTS described in the README as 20.04, with support before that release no longer official. The following command installs the documented compiler, build tools, native libraries, Guile package, Qt package, and Python package:

sudo apt-get install g++ cmake pkg-config libeigen3-dev libpng-dev libboost-all-dev guile-3.0-dev qtbase5-dev python3

A user who does not need Guile or Studio may omit `guile-3.0-dev` and `qtbase5-dev`, as the README explains. After obtaining the repository, create a separate build directory, configure the project, and build it with parallel make:

mkdir build
cd build
cmake ..
make -j4

The first `cmake ..` run checks dependencies and prints which components will be built. The README gives sample output for `libfive`, Guile bindings, Python bindings, and Studio, with Studio requiring Python and Guile. After the build completes, launch the application from the build tree with this command:

./studio/Studio

This is a real first use because Studio is the repository's interactive application and supports live-coded models plus direct surface editing. The README does not document a minimal model script, GUI startup sequence, sample file path, or automated test command, so this article does not invent one. Users who need evidence about initial rendering, scripting behavior, or direct manipulation should first run the locally built executable and confirm that its dependency report includes the intended layers.

Optional components change build and installation cost

The build system offers meaningful configuration choices, but those choices also make installation more involved than installing one application package. The documented core dependencies are CMake 1.65 or later, `pkg-config`, Eigen 3.3.x, `libpng`, and Boost 1.65 or later. Guile 2.2.1 or later enables the optional Guile bindings. Python 3.7 or later enables Python bindings. Qt 5.12 or later is needed for Studio.

The README explains that `sudo make install` writes components to system-wide destinations, including `/usr/local/bin/Studio`. That permits invocation outside the build directory, but it also means the installed Studio and libraries are separate from the checkout. The README specifically says this installation must be repeated after source changes when using that workflow. This is an operational cost worth considering for developers who edit and rebuild frequently.

Python bindings are normally installed under `/usr/lib` unless `PYTHON_SITE_PACKAGES_DIR` is set. The documented configuration command uses an example destination:

cmake -DPYTHON_SITE_PACKAGES_DIR=/usr/local/lib/python3.9/dist-packages .

The repository has no GitHub releases, and the README points users to a downloads page without documenting release artifacts or versioned packages in the available instructions. macOS instructions also depend on a Homebrew installation and may require a Qt-specific `CMAKE_PREFIX_PATH`. On Windows, the README specifies VS2022 with Desktop development with C++, MSVC, the Windows 10 SDK, and C++ CMake tools. These details indicate that maintenance includes managing native toolchains and optional runtimes, although the last push was on 2026-10-13, so it should not be characterized as abandoned.

Mixed licensing separates core reuse from Studio and Guile terms

libfive does not use one license across every layer. The README identifies the core `libfive` library, `libfive-stdlib`, and Python bindings as released under the Mozilla Public License, version 2. Studio and `libfive-guile` are released under the GNU General Public License, version 2 or later. This split can affect integration decisions, especially for applications that combine the Python-facing core with Studio or Guile components.

The README does not provide legal interpretation or a compatibility analysis. It also states a copyright notice for Matthew Keeter and links to the applicable license texts. Organizations should therefore review the license of each component they compile, link, distribute, or modify. The distinction is more concrete than a general license warning: choosing Studio brings GPL terms into the decision, while using the core library, standard library, and Python bindings points to MPL 2.0 as documented.

The project also offers a contact address for custom development, integration, and commercial support. That is a documented path for project-specific assistance, but the README does not state response times, service levels, pricing, or the scope of support. There are no GitHub releases to compare for upgrade compatibility, so an adopter should inspect `CHANGELOG.md` and the repository history for migration notes before planning an upgrade. The README does not document a rollback procedure.

Function representation differs from direct surface editing

The central trade-off is visible in the architecture. libfive is organized around functional representations, and the README presents model construction, transformation, CSG operations, and meshing as operations on that mathematical representation. This is a different approach from treating a triangle surface as the primary editable object. The documented result is a generated triangle mesh with watertight, manifold, hierarchical, and feature-preserving properties.

That design is appropriate for scripted geometry, parametric models, and applications that need to evaluate or combine model functions. It is also a poor fit for a team whose core requirement is a conventional surface editing workflow centered on vertices, edges, and faces. Studio provides direct manipulation, but the README describes it as changing variables in the script. It does not present Studio as a general B-rep editor with topology selection and constraint-based surface construction.

A real alternative approach is to use a mesh-first CAD workflow, where geometry is represented and edited directly as a surface. The difference is not simply a language preference. Function representation changes where operations occur: shapes and transformations are expressed as functions, then passed to the meshing algorithm. A mesh-first workflow instead begins with surface data and applies geometric edits to that data. Teams should choose based on whether script composition and programmatic evaluation are central requirements or whether direct surface topology is the primary requirement.

libfive also has boundaries around platform and optional-component coverage. Guile bindings are unavailable on Windows according to the README, and Studio depends on a supported Qt setup. The repository documentation is strongest around building and architecture. It does not state production performance limits, supported model sizes, memory requirements, numerical tolerances, or compatibility guarantees for third-party bindings. Those omissions should be checked against representative models before adopting it as a critical CAD backend.

Editorial conclusion

Engineers building CAD tools, scripted geometry pipelines, or reusable implicit-model infrastructure should evaluate libfive when its function representation and language bindings fit the application. Projects expecting packaged releases, a single license across every layer, or an effortless visual modeling setup should look elsewhere. Before adoption, verify the required CMake, Eigen, Boost, libpng, language-runtime, and Qt dependencies on the target platform, then review the separate MPL 2.0 and GPL terms for the components intended for use.

Frequently asked questions

Official sources

1. Issues
2. libfive/libfive on GitHub
3. Project website
4. README