Output

Bonsai keeps your whole building model in one .ifc file, written to IFC, the open standard for building models, and a drawing goes into the same file. It isn’t a file that sits next to the model. It is an object inside it.

Specifically, it is an annotation entity with a scale, a position, a direction to look in, and a note of which kind of view it is - a plan, a reflected plan, a section, an elevation. Add a drawing to your project and your .ifc file has grown by one object. Send the file to somebody and you have sent them the drawings.

A view is a camera and a question

What a drawing contains isn’t decided by what happens to be in shot. It is decided by a query, written in the same selector syntax you use to find things, stored on the drawing and saying which elements are included and which are kept out.

A drawing of the second floor isn’t a picture that somebody framed carefully; it is a saved question, and the day the model changes it asks the question again. A question that names a storey can only find what has been put in that storey: a wall contained nowhere is missed by it, however plainly it stands in the viewport.

The geometry it draws with is already in the model too. A window’s appearance in plan is a stored representation rather than a projection worked out on the fly.

Annotation is data, not draughting

Everything you add on top is also IFC. Dimensions, text, leaders, level markers, revision clouds, hatched fill and symbols are each an annotation object in the file, with a type saying what kind of annotation it is.

There is no separate drawing file to keep in step, and no export of your annotation into somebody else’s format: a consultant who opens your IFC gets your dimensions and notes along with your walls, because they were never anywhere else.

Annotation text can also read the model rather than repeat it. A tag can be told to print any value the element it points at carries - an attribute, such as the door’s own Tag, or a property, such as its fire rating. So a door tag showing a fire rating is showing that door’s actual fire rating, not a number somebody typed next to a door and forgot to update. That is the difference between labelling a model and describing one.

The SVG is the result, not the drawing

When you generate a drawing, Bonsai renders it to .svg. That file is an output and nothing more. The drawing lives in the model; the .svg is what the drawing looked like when you last generated it.

Everything else you send out is made from that .svg rather than from the model. A PDF is the SVG converted, by whichever program you nominate for the job. A .dxf, for the consultant who needs lines in a CAD file rather than a picture, is the same SVG read back and written out again as CAD entities. Both are therefore two steps away from the building.

Here too, when the model changes you regenerate. What that buys you is that the description survives: your drawings aren’t a set of files that gradually stop matching the building.

The line weights, hatches, symbols and titleblocks are .svg and .css files, which you can edit yourself.

Sheets

Drawings get placed on sheets, and a sheet is another object in the file - a document, with an identification and a title, holding the drawings you put on it along with a titleblock. What comes out at the end is a stack of paper or PDFs; what is kept is the thing that produced them.

Schedules and quantities

Schedules work the same way and are stored the same way - a document object in the file, with a query deciding its rows and the same value-reading syntax deciding its columns.

A door schedule is therefore not a table somebody typed. It is a question about doors, and the answer is regenerated from the model. The numbers in it come from the quantities already written into the file, which are stored, not recalculated: a schedule isn’t doing arithmetic on geometry as you watch, it is reporting what the model says.

Schedules come out as spreadsheets, and the same machinery reads them back in, so a schedule can be edited by somebody who has never opened Bonsai and the changes brought back into the model.

And the rest of it

The same graph of objects carries further outputs that this guide isn’t going to cover in any depth. Tasks and work schedules are IFC objects, so a programme can be attached to the model and the model animated against it. Cost items and cost schedules are IFC objects too, so quantities can be priced without leaving the file.

Those are large subjects with their own tools, and you don’t need them to produce drawings. They aren’t separate applications bolted on but more objects in the same model, reached by the same queries and kept in the same file.

Everything the project produces is in the document you are editing, and the document is one file.

Last updated 8 October 2026.