Scripting

Everything Bonsai does through a panel, it will also do from a script - and mostly by running the very same code.

Start with what you already have, because it is more than people expect. Bonsai, which turns Blender into an editor for IFC files, is built out of modules, among them searching and filtering, drawings and sheets, schedules and quantity take-off, clash detection, IDS checking, BCF, Git support, cost items and work programmes, patching, facility management handover. Each is part of the add-on you installed rather than a separate program you have to acquire, so there is no toolchain to assemble before you can begin.

Most modules have a command-line twin

Underneath, most of those modules are a front end onto a standalone tool that also runs by itself, without Blender, working straight on your .ifc file. IFC is an open standard, so nothing about the file requires Bonsai in order to read it.

Clash detection is ifcclash. IDS checking is ifctester. Schedules are ifccsv. Comparing two files is ifcdiff. Merging two lines of work on one model is ifcmerge. Transforming a file is ifcpatch. Validating a file against the standard is part of IfcOpenShell itself. It is the same code doing the same work, and the only difference is whether you are driving it through a panel or from a command line.

When the command line earns its keep

Not often, at first. But there are four situations where it stops being an eccentricity and becomes the obvious thing:

• Many files at once. Doing something to one model is a job for the panel. Doing it to two hundred consultants’ models is a loop.
• The same job every time. Anything you find yourself doing weekly, in the same way, is a candidate - not because clicking is slow, but because clicking is where the mistakes come from.
• Unattended. A check that runs when a file lands in a folder, or overnight, or when somebody pushes a revision.
• As one step among others. A model check wired into whatever your office already uses to move files about.

ifcpatch is the clearest illustration. A recipe is a named transformation, invoked like this:

python -m ifcpatch -i input.ifc -o output.ifc -r ConvertLengthUnit

There are many of them. Some fix other people’s exports, written by people who met the problem on a real job. Others are ordinary utilities - convert a file’s units, pull a subset of elements out into a new file, merge several projects into one. Any of them can be run over a folder of files by anybody who can write a loop, and none of them require you to open Blender.

The library underneath

Below all of them is ifcopenshell, a Python library like any other. Everything in this guide - containment, types, attributes and properties, representations, queries - is reachable from it in a few lines, and the tools above are themselves written against it.

import ifcopenshell
model = ifcopenshell.open("model.ifc")
for wall in model.by_type("IfcWall"):
    print(wall.Name)

That prints the name of every wall in a file, and the IfcOpenShell documentation carries on from there.

You don’t need to install it separately to experiment, because it is already inside Blender, along with a text editor and a console.

One toolkit, not an assortment

The selector syntax chooses what a drawing contains, picks a schedule’s rows, fills in the text on an annotation, decides how much of somebody else’s model to load when you link it, and names which elements clash detection should compare. Several jobs in different modules, and one sentence you learned once.

The modules are one set of ideas - the schema, the graph of objects, the selector syntax - with different jobs attached, which is why learning one of them makes the next one easier rather than being a fresh start.

And you can ignore nearly all of it

You don’t need any of this yet, and possibly ever.

Model, draw, schedule, check. If a day comes when you are doing the same thing to the fortieth file in a row, you will know, and this page will still be here. The tool already exists, and you already own it.

Last updated 8 October 2026.