The file is the document

Press Ctrl-S with a project open and Bonsai writes your IFC file. Not a copy of it, not an export of it, but the file itself - with everything in the same order, no weird extras, no ‘upgrades’ to subtly break, and nothing lost.

Most BIM software keeps your work in a format of its own and treats IFC as something you export at the end, for other people. Bonsai has no such proprietary format of its own: the .ifc file is the document.

The .blend isn’t your project

Bonsai runs inside Blender, whose own document is the .blend file. If you have used Blender before, the .blend is the file you keep and back up. In Bonsai the .blend isn’t the project, and you may never need one at all.

Bonsai doesn’t create a .blend, but if you have saved one yourself, Bonsai will try and keep it up-to-date.

A .blend is useful as a working file: it remembers your viewport layout, cameras, lights, render settings and any scratch objects that aren’t part of the building. Keep one if it earns its keep. If you lost it tomorrow you would lose a little convenience; if you lost the .ifc you would have lost the project.

No import, and no export

Bonsai opens and saves IFC projects directly. Bonsai does offer a geometry-only import, which loads the shapes out of an IFC file and discards everything else. It is there for the times when you genuinely want meshes rather than a model: dropping a building into a city model for rendering, or creating an envelope for wind analysis.

You may have learned to distrust IFC

Many people have bad prior experiences with IFC. Almost everyone meets IFC through the import and export menus of proprietary tools, where the implementations are partial, inconsistent and sometimes plainly wrong. Walls arrive as lumps, property sets go missing, a storey turns up at the wrong height. You judge a format by the implementations you have seen, and most are poor.

But that experience is actually a round trip: conversions from one format to another and back, and no way to tell which step mangled your model. Take the conversions away and you get something else entirely.

The other complaint is that ‘IFC files are enormous’. They can be, when somebody’s exporter has written every wall out as a bag of triangles - but that is a choice about how the geometry is described, not a property of the format. If somebody hands you one of those, the documentation has a guide to dealing with large models.

Telling a good model from a bad one is a subject of its own, and so is putting a bad one right. But the format isn’t what has been failing you.

You can open it up

An IFC file is a text file. It uses a long-standing engineering exchange format called STEP, and while it isn’t exactly bedtime reading, it is plain, line-based and legible: you can open your model in a text editor, search it, and copy a few lines into a message when you are asking somebody for help.

Because the file is text, its history can be kept and compared like any other text document. Because it is legible, a broken file can be inspected and often repaired. And because it is open, nothing about your project is hidden from you.

What the text describes is a graph of standard objects.

What follows

Most of the rest of this guide follows from the model being an ordinary file. Other programs can read and write it, so other people’s models can sit alongside yours; it can be versioned, branched and merged with the same Git that the rest of the world uses for source code; and because it isn’t held in somebody else’s proprietary database, your work stays available to you when a subscription lapses or a software supplier changes its mind.

You are editing the deliverable directly. Everything else is a window onto it.

Last updated 2 October 2026.