IfcOpenShell: the geometry engine under open source BIM tooling

One API across four generations of the IFC schema

IfcOpenShell describes itself as an open source library for working with Industry Foundation Classes, and the schema coverage it claims is specific enough to be worth repeating: complete parsing support for IFC2x3 TC1, IFC4 Add2 TC1, IFC4x1, IFC4x2 and IFC4x3 Add2, with extensive geometric support implemented for IFC2x3 TC1 and IFC4 Add2 TC1. That gap between the two sentences is the interesting part. Reading entities and attributes is a schema job, and turning those entities into solids, surfaces and tessellations is a geometry engine job. The Dockerfile is a fair hint at where the second half lives, since the image installs libocct-foundation-dev alongside libocct-modeling-algorithms-dev, libocct-data-exchange-dev and the OCAF document framework, all of them OpenCASCADE development packages, on top of a base of ubuntu:22.04.

Both a C++ and a Python API sit on top of that, and the default branch is named v0.9.0, so the versioning tracks the IFC schema generations rather than following a plain semantic release line. Extending support to an arbitrary IFC schema is possible at compile time from C++ and at run time from Python, which is the difference that matters if you are working with a national or vendor-specific schema rather than a released one. A vendor extension that does not exist yet when you build is exactly the case where the Python route is the one that saves you a rebuild.

Bonsai and IfcConvert are the two doors most people walk through

The repository is not a single tool, and the two entry points named first in the project description are the ones a new user meets. Bonsai is an add-on to Blender that turns the open source 3D application into a graphical IFC authoring platform, with its own site at bonsaibim.org and its own documentation tree, including pages for installation and for exploring an IFC model. It is the piece people see in screenshots, and it is the only component in the table licensed under GPL-3.0-or-later while everything else stays LGPL.

IfcConvert is the other one, a command line application for converting IFC models to other formats, and it carries a marker in its license column that the other rows do not. Several rows in that table carry a trailing asterisk, including ifcblender and ifcmax, both of which are described in the table as historic: ifcblender was the older Blender import add-on and ifcmax was an extension for 3DS Max. The conversion pipeline that replaced the Blender add-on is still documented, which is worth knowing if you are maintaining a pipeline written against the older import path.

Alongside those two sit auxiliary standard support for BCF and IDS, the issue coordination and information delivery formats that the wider construction industry uses around the IFC file itself. If a request arrives as a BCF issue rather than a model, the `bcf` package is the entry point.

Fourteen PyPI packages that cover the boring half of a BIM pipeline

The part of this repository that saves the most engineering time is the table of packages underneath the two headline tools, because the operations listed there are exactly the ones that get hand-rolled badly in every pipeline. `ifcclash` is clash detection as a library and a command line app. `ifccsv` exports and imports schedules from IFC, which is the bridge to the spreadsheet-shaped world most quantity surveyors still live in. `ifcdiff` compares changes between two models, so version control over a building becomes a review rather than a guess. `ifc5d` reports and optimises cost information from IFC, `ifc4d` converts to and from project management software, and `ifcfm` extracts the data facilities management teams need at handover.

The rest of the list is narrower but just as real. `ifccityjson` converts CityJSON to IFC, `ifcedit` is a command line wrapper around the `ifcopenshell.api` model mutation functions, `bsdd` queries the buildingSMART Data Dictionary API, and `ifc2ca` converts IFC structural analysis models to Code_Aster. `ifcmcp` is an MCP server for querying models, which is the newest direction in the table and the one most likely to be moving.

The mutating half is reached through `ifcopenshell.api`, and `ifcedit` exists so you can drive it without writing Python. That split is the design decision that makes the rest of the package list possible: a model can be loaded, inspected, changed and saved through the same object graph regardless of which operation you are performing.

What the build directory layout says about shipping this

The repository tree is a useful map of how a project with this many deliverables gets built and published. `src/` holds the code, `cmake/` the build definitions, and then there is a separate directory per distribution channel: `conda/`, `nix/`, `choco/`, `win/`, `docker/`, `aws/` and a top-level `Dockerfile`. `pixi.toml` and `pixi.lock` sit next to `pyproject.toml`, which suggests the maintainers run several toolchains at once rather than betting on one. `pyodide/` is the interesting entry, since it is the path that lets the Python API run inside a browser.

The linting configuration in `pyproject.toml` is unusually explicit about its own limits. Ruff runs at a line length of 120 with a selected rule list that starts from error detection, unused imports, future annotations and pyupgrade, then adds import sorting. Several paths are excluded, and the comments say why: generated sources such as `express_parser.py`, submodule directories like `mvd` and `simple_spf`, and templates under `ifc2ca` that do not fit the linter. A separate Pyright section disables invalid type reporting and missing module source warnings, with a comment noting that Pylance ignores gitignore and therefore needs manual excludes to keep the editor fast.

Testing lives in `test/`, and development tooling requirements are pinned separately in `requirements-tools.txt`. The theme carries both `AGENTS.md` and a `CLAUDE.md` at the root, so instructions for coding agents are part of the repository rather than something contributors improvise.

Reading the release feed and the version branch together

The release list is dominated by Bonsai nightly builds rather than tagged library versions. The three most recent entries are all named `bonsai-0.9.0-alpha` followed by a timestamp, all marked unstable, all published on the same day in September 2026, and each one points readers to a separate repository for how to set up automatic updates to daily Bonsai builds. That tells you the alpha channel is automated and frequent, and it tells you the tagged library releases do not live in this view.

The default branch name, v0.9.0, is where the version story actually is. It also lines up with the Bonsai alpha tags, so a 0.9.0 generation is what is currently in flight on both the library and the Blender add-on. The repository is not archived, the last push was 2026-09-24, and the open issue count sits at 2028 against roughly 2800 stars and 971 forks. That ratio is worth reading carefully rather than skipping past: a large open issue count on a project of this size is normal for a schema library where every report is a specific exporter or a specific national variant, but it does mean triaging matters more here than in a typical library.

Funding runs through Open Collective under the opensourcebim account, which is the arrangement that keeps a multi-package project with this many maintainers and contributor paths viable.

The boundary between what the README settles and what the docs do

The README is a directory with a short introduction, and it is honest about being that. It states schema coverage, names the two headline tools, prints the package table, and then points at five separate documentation sites: the IfcOpenShell website, the C++ installation page, the Python installation page, a Python hello world tutorial, and the Bonsai documentation with its own installation and model exploration pages. Every packaging decision a reader needs is one hop away rather than on the page.

That structure has a practical consequence for evaluating the project. Questions such as which geometry operations are implemented for IFC4 as opposed to IFC2x3, how performance behaves on a very large model, and how the runtime schema extension works in Python are documentation questions, not README questions. So are the per-package details, since each row in the table links to its own page.

What the README does settle, and settles well, is scope. This is a library first, with applications and packages arranged around it, not a monolith. The pyproject comment explaining that requires-python is deliberately omitted so that individual projects can set their own is a small but telling detail: bonsai and the general IfcOpenShell distribution deliberately do not share one Python version constraint, and the packaging was designed around that.

Editorial conclusion

IfcOpenShell is worth reaching for when a task starts with an IFC file and ends somewhere other than a viewer: clash detection, schedule export, model diffing, cost reporting or converting a model into a city JSON file. The library layer handles four schema generations, and the package layer covers the operations that every BIM pipeline ends up writing badly. The parts to read before committing are the ones the README leaves open, namely how geometry support differs between IFC2x3 and IFC4, which of the fourteen packages you actually need, and the licensing split where Bonsai is GPL while the libraries stay LGPL. Start with the Python installation page and the hello world tutorial, then read the release notes for the package you need rather than the whole table.

Frequently asked questions

Official sources

1. IfcOpenShell/IfcOpenShell on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases