Boundary representation in IFC

IFC offers quite a few ways to describe solid geometry:

• • you can use primitives like blocks, cylinders etc. and combine them using boolean operations like union, difference etc.
• you can make sweeps by extruding profiles along a path
• you can define multiple section profiles along a path
• or you can use boundary representation.

Boundary representation (“b-rep”) are probably the reason why IFC files are considered static and take so much disk space. Let’s have a look how b-reps are constructed to find out why.

Faceted b-reps are described by all its “corner” points. That is the start. So if you want to describe a cube using this geometry you need sight Cartesian points (with X, Y and Z coordinates).

You can already see how this is inefficient: having eight lines simply for the nodes instead of defining a cube with length with and height, right?

B-rep doesn’t stop there, we just “created” some points. Next we have to connect those points to receive edge loops that we define as the boundaries of our our faces (outer and inner if you have holes/voids). In case of a cube we need six of those.

Finally we have to list all faces that make up a “watertight” shell, again our six faces.

Let’s sum it up. For our simple cube we need:

• 8 points
• 6 poly-loops
• 6 outer boundaries
• 6 faces
• 1 closed shell
• • 1 final faceted b-rep object (because you could add other closed shells as voids)

That makes at least 28 rather long lines in an IFC file. Additionally they are hard to read for humans. So how comes this is used so often – or at all?

Because is a kind of last resort for geometry description. Each program has its own way of treating geometry (more or less, there are a few so-called “geometry kernels” available). So during export this geometry is converted to IFC geometry. That works mostly fine for simple extrusion (i.e. footprint + height). If no easy conversion is found the geometry gets “dissolved” into its “atomic” components to keep at least the looks of the object.

On the receiving side it’s also the “easiest” way to prepare a geometry for display in a viewer. The viewer simply has to take all the points, connect them to form triangles / quads / polygons (whatever is most efficient for the viewer, graphic cards are optimized towards working with those) and is basically finished. It does not have to know the different “syntax” for blocks, spheres, cylinders, tapered extrusions, sweeps along paths etc. The reason why objects “disappear” when imported into BIM-applications (authoring or viewing tools) often is that those don’t understand certain geometries. They cannot display what they cannot “read”. If you are lucky you receive a log file that tells you which geometry was skipped.

Sometimes you cannot avoid to have complex geometry that you can only describe using b-reps. However, for our usual day-to-day projects that should be quite rare (unless you put fancy furniture and accessories in your model).