Finding things

Most of what is in your model cannot be clicked on. Property sets, classifications, materials, tasks, cost items - none of it has a shape in the viewport, and the parts that do have shapes are frequently buried behind other shapes.

So clicking cannot be the main way you reach the model, and if it is the only way you know, you are working with the small visible fraction of your project. This page is the practical answer to The model is a graph of standard objects.

Select by what things are

The way in is to describe what you want rather than to find and click it. Bonsai will select by class, by the storey or space something sits in, by its type, by its material, by a classification code, or by any property in any property set.

That is already a different way of working. “Every external wall” and “everything on Level 2” and “every door of type DT03” are questions about the data, and the answer arrives as a selection regardless of whether the things are visible, hidden behind something, or out of shot.

There is a query language, and it is worth ten minutes

Underneath the filter panel is a small textual query language, and it is the durable interface - it is written down, it can be saved, and it does not move when the buttons do.

IfcWall

Every wall. Narrow it by adding terms separated by commas:

IfcWall, Pset_WallCommon.IsExternal=TRUE

Only the external ones. A comma means and, so each term you add takes things away:

IfcWall, location="Level 2", type=WT01

Walls, on Level 2, of type WT01. The exception is worth knowing because it looks like an inconsistency and is not: two plain class names separated by a comma give you both, since nothing can be a wall and a slab at once.

IfcWall, IfcSlab

Comparisons other than = are available - != for is not, > and < for numbers, and *= for contains:

IfcDoor, Pset_DoorCommon.FireRating!=FD30
IfcSpace, Name*=Store

That second one is the sort of thing that finds you a problem: every door whose fire rating is not what you assumed. Note the negation goes on the comparison. You cannot put a ! in front of a property term - that is a syntax error - though you can put one in front of a class name, to take that class back out of what you have already asked for. On its own, ! IfcWall returns nothing at all, because negation needs a set to subtract from.

A + between groups gives you a union, for when a single narrowing chain will not express it:

IfcWall, location="Level 1" + IfcSlab, location="Level 2"

A search is a thing you keep

Selections are ephemeral and queries are not. You can save a query, name it, and load it again next week. Where it is saved is worth knowing: the query is kept in the model itself, so it travels with the file. Send somebody your model and they get your searches along with it.

This is the habit worth forming early. The first time you work out how to select every fire door on a floor, that is a piece of work; saving it means you did that work once, and that whoever opens the model after you inherits it rather than working it out again.

Colouring by property, which is how you look at data

The other tool here is easy to overlook and is the fastest way to see something wrong. Bonsai will colour every object in the model according to the value of a property you name.

Colour the model by fire rating and the walls that have none are suddenly obvious, in a way that no amount of clicking through a properties panel would ever have made them. Colour it by classification, or by type, or by whether something is load bearing, and you are looking at the non-geometric part of the model using the one faculty that reads a whole floor at a glance. Colour schemes save and load in the same way queries do.

It is worth saying plainly what this is for. It is not a presentation technique. It is a way of making data visible so that gaps in it become visible too.

The same language runs everything else

Here is the part that makes this page structural rather than a convenience.

The query language is not a feature of the search box. It is what decides which elements appear on a drawing. It is what picks the rows of a schedule, and ifccsv uses the same syntax again to choose the columns. It even fills in the text of annotation, so a label can read a value out of the element it is pointing at.

So learning to say external walls on Level 2 of type WT01 is not learning a search box. It is learning the sentence that a drawing, a schedule and a check are all built out of. Which is why this page sits before What comes out rather than after it.

And it is the groundwork for the harder question. Once you can ask the model what it contains, you can ask whether what it contains is what somebody required - see Checking the model.

Last updated 3 September 2026.