BIM Mindset-Shift #2 - Derived Objects Pinned Featured

Derive the object, not just the value

As a “traditionally educated” construction professional, I was used to calculating missing information: was a surface area needed? I created a formula; a quantity was missing from the model? I calculated it in Excel; a situation was too complex? I rolled up my sleeves and started measuring patiently. 

I obtained a value, placed it somewhere, and continued working.

→ BIM data processing opens a much more scalable possibility:

Instead of only calculating the value… why not derive an object, to which that value can “belong” ?

This may sound almost upside down at first… Why derive an object, when all we need is a number?

→ Because an object gives us much more than a number. 

Let’s see what, and how.

Premise

First, let's clarify this: I don't mean manually modelling another physical object. 

What I mean is: the information we need for a specific purpose often already "exists implicitly" in the model - it simply hasn't been "brought to life explicitly", for example as an object. 

→ BIM data processing, combined with our logic and experience, can change that.

What the derived “object” is, depends on our purpose

Some examples:

🟢 A surface can be an object

Let’s recall the examples of the wall surfaces needed for painting or for tiling. The model contained Spaces and Walls, but not the explicit surfaces on which this work will happen. Traditionally, we might calculate their areas using formulas, room data, drawings, or spreadsheets. 

By processing the existing model data, instead, we can use the relationship between each Space and its bounding Walls, to derive corresponding Wall Surface Objects:

→ Now, we don’t just have a surface value: each generated surface has its own geometry, identity, and quantities; also, references and selected properties of the original Space and Wall.

This implies that we can now for example:

• see the surface in 3D;
• limit the height subject to painting/tiling, if that doesn't extend over the full wall height;
• group by room or work type; 
• group by apartment;
• export as IFC and data, for downstream use.

The surface value has now found an object to belong to - and is explicit in our model, together with other useful information!

🟢 A filler can be an object

In a renovation project doors and windows are removed and their openings need to be filled. The model we receive may 'show' the element to be removed, but the new filler wall segment very likely doesn't yet exist as a 'usable' BIM object:

→ Using the existing opening geometry, we can derive a Filler Object, which can be:

• quantified, here as volume to be filled;
• connected to the hosting wall;
• classified;
• included in a 4D or 5D workflow;
• exported to IFC, data table, csv.

A construction activity that was only implicit in the original model becomes explicit - and structured BIM data.

🟢 An intersection can be an object

When a pipe crosses a wall, we often think immediately of clash detection. But an intersection represents much more than a clash: it can actually be a very productive moment in the model!

It may represent a sealing activity, a fire-stopping requirement, an opening or sleeve - any piece of work that requires quantities, time, cost, responsibility, and status information.

→ So, instead of just “reporting” that two objects intersect, we derive new objects, that represent “the intersections themselves”:

Such derived objects now contain:

• intersection geometry, dimensions, and quantities;
• references to the original objects;
• classification and status information;
• data required for coordination or execution.

The collision between two objects becomes an explicit and usable BIM object!

🟢 A location slice can be an object

This is one of the construction companies’ favourites because construction work and quantities are commonly organized by location. A wall may cross several apartments, zones, or takt areas. Its total quantity is useful, but it does not tell us how much belongs to each location. 

Traditionally, we might calculate the location shares 'outside' the model. But: what if we split the main element at some meaningful location boundaries - creating separate location slices?

→ This is the idea behind Simplebim's “Location Prisms” (read more here how to use them without Dataflows or inside a Dataflow). The resulting slices automatically receive recalculated quantities and, as a nice bonus, the corresponding location data:

The same principle applies to long elements that cross several sections in infrastructure models, such as roads, water channels, or railways:

Again, it practically means that we can now, for example:

• visualize the slices, generated according to our logic;
• verify or group them;
• quantify;
• schedule;
• export as IFC or data, by location.

The value of a location share is no longer just a number in a spreadsheet. Now it “belongs” to the corresponding location-slice object.

→ The Mindset-Shift

A calculated value usually answers one predefined question.

A derived object, instead, can “participate” in many workflows! 

Since it has geometry, identity, quantities, properties, and relationships, it can be:

• selected and visualized;
• grouped for different purposes;
• enriched with properties;
• validated;
• classified;
• connected to other objects;
• exported to IFC;
• reported in tables;
• reused in 4D, cost estimation, procurement, or BI workflows.

A model does not need to - and honestly cannot - contain every object required by every downstream use case. 

It just needs to provide reliable source objects and geometry. 

From there, we can derive meaningful objects we need for our purpose.

At that point, we are no longer managing only one calculated value:

We are managing structured, visible, verifiable, and reusable BIM data.

For me, this was another powerful BIM Mindset-Shift.

Perhaps we can collect a few more examples together.

For further context, feel free to read my previous BIM Mindset-Shift #1 - Groups and the Valentine post about BIM relationships.

What are we still calculating “outside” the model - that could instead become a useful object “inside” it?

🙂💡