Visualizing Building Information – Clash Detection

One of the more useful applications of building information we’ve been experimenting with has been visualization. We first started experimenting with visualizing building data back in 2010. You can see a presentation I gave at KA Connect 2010 on the research we were doing on this front with SOM here. The research we did on that project has evolved into a full fledged web based tool that is helping them manage their thousands of gigs of BIM data production.

Since I’ve become obsessed with other applications of visualization. Let’s look at what it can do to clash detection or conflict analysis. This is an area I spend a lot of time on since it is at the core of our Project Consulting services. Model progress comparisons, conflict analysis, audits, craft, etc… are all critical parts of the continuous BIM data management responsibilities that go along with BIM project delivery.

Of course, the objective behind visualization is to help emerge some other interpretation of the data that can provide further insight, whether it be through a new pattern that is recognized, grouping, or something else. It must teach us something new by viewing the data from a different perspective.

Here are a couple of examples:

1. Plotting the x and y coordinates of clash instances

clash detection visualization by x and y coordinates

clash detection visualization by x and y coordinates

Though seemingly obvious, the above image helps us tremendously to quickly understand a simple clash test. By plotting the x and y coordinates of each clash instance, and coloring them by the discipline, we are able to quickly identify the area and model that have the most issues. On the image above, the lighting model has an area of severe congestion on the north-east of the building. Without having gone through every clash, I already understand, at a high level, where most of my time should be spent.

Conflicts by x and y

Conflicts by x and y

Similarly, on this analysis we see an x y plot that quickly categorizes the source files of the clashes by color, labels the elements by name, and indicates the severity of the clash by the size of the bubble. This analysis looked at conflicts between curtain wall components against the building’s superstructure.

2. Ranking BIM elements by number of conflicts and severity

BIM visualization by element clash severity

BIM visualization by element clash severity

This image takes each distinct BIM element and ranks it based on number of identified conflicts and sizes them by severity. From this, we are able to quickly assess the type of elements that may need the most amount of attention. Not to imply that clash quantity is the single source for qualifying a coordination issue, it is not, but elements that have a high number of clashes of high severity should be addressed.

3. Model version comparison analysis

BIM version comparison

BIM version comparison

In this case, we are comparing one model version versus a previous one. We are interested in seeing how much, and what has changed between submissions. We see, very quickly that on this MEP model, most of the work has gone into re-routing plumbing systems and relocating electrical fixtures. This can be incredibly helpful on large projects to understand model progress and keep an eye on craft.

Dissecting the BIM execution plan

Following up on some posts I’ve made referring to the importance of the BIM execution plan (BEP), I wanted to go a bit more high level and talk a bit about what exactly it is that this document is supposed to do.

There are 5 major questions a BEP must answer:

  1. What is the objective for BIM on this project?
  2. What process will we be implementing to achieve said objectives?
  3. What standard of performance must the model meet in order to meet said objectives?
  4. What is included in the model, and who is responsible for including it? (This is your MET)
  5. How are others allowed to use the model?

There are, of course, other elements that people can add to this, like legal disclaimers, but at the core, this is what we should see. Naturally, a process change can create friction and unease. The BEP should go a long way to clear up any open questions across the team. Done correctly – allowing people to comment and participate – the process of developing a BEP should result in a clear definition of the rules one must respect in order to play the game. Without it, everyone plays by their own rules and the aggregate is no better than the sum of its parts.

Another couple of points to take into consideration are model ownership and whether the model has been defined as a contract deliverable or not. These will also have a large impact on how the BEP is structured. Usually, ‘self driven’ BEPs are much less strict and allow room for interpretation. Whereas ‘imposed’ BEPs can be hyper specific and dictate many areas of both the processes and technologies. We see this with the large owners usually…

All in all then, I believe that we should look at models like in a similar manner than we do the buildings. Many resources and processes are dedicated to their development and the end product should be representative of those who made it in both quality and reliability. When working with other parties toward a common goal, setting forth clear expectations is only good project management.

Beyond this, most BEPs will have a pretty tactical breakout of process and deliverable requirements. Unfortunately, most people see this as a sort of checklist that needs to be filled out. This isn’t the case. Defining the objectives for a BIM process on a project can and does have a huge influence on project delivery and should not be taken lightly. This touches everything, from people to decision-making, to contract documents. Losing control over deliverables is never a good place to be…