Clash Based Clustering Analysis - From the GBCO_VDC Top Secret Files

Clashing models has become SOP for the construction industry, and tools like Navisworks make our lives significantly easier when it comes to visualizing models in space.  The inherent problem with clash detection (and most other ****desk software tools is that they are built for the larger audience of the AEC, sacrificing targeted functionality for a good UI and ease of use.

Today, we'll show you how we took some of the raw information from Navisworks (where it sits, but is unusable), and turned it into something usable in Rhino and Grasshopper.  We then can push back the visual data into Revit or CAD, so that designers/fabricators can use the information in their native documentation software.

The first month I had been hired by Gilbane, John Tocci Jr. tasked me to figure out a visual way to represent, organize, and sort clashes in a better way than Navis provided us with the vanilla Roamer.  He and David Joslin had seen a cool LISP routine at another conference that did something similar in CAD, but it was bulky and tough to use for someone with little-to-no scripting experience.

David and I pondered for a week or so and came to the conclusion that we knew there was an exportable x,y,z coordinate for every clash in a model.

That weekend, in a fit of rage (KU basketball had just lost to Missouri in one of the worst officiated games in B12 history), I worked up the basis of the grasshopper script that would read the input excel document and convert it into tangible geometry. 

In nearly every drafting software, all elements either have a base-point (CAD) or their own center coordinate in x-y-z-coordinate space.  Additionally, when you clash two models or elements in Navisworks, Navis creates a new x,y,z coordinate.  We're pretty sure Navis takes the total intersection area and returns the centroid of the region.  This location data is actually contained within Navisworks.  This is the central crux to the workflow. 

Standard Clash - We see these every day in the industry:  We need to get location data from Navis to XML to Grasshopper.

XMLs in file

Proximity Script

Issues vs. Clashes:

The visual representation of the clashes is only part of the equation.  We needed a way to classify 'big' issues vs 'small' issues.  For instance, the clash in the first image is nothing in the scheme of a building.  However, 25 clashes in a 3' radius in a main MEP hallway is a big freaking deal.  That combination of clashes is classified by Gilbane as an 'issue.'  At Gilbane we don't track clashes, we track issues. Our proximity script allows us to do that.  

Raw grasshopper geometry to be exported to Navis/Revit

For the past 2 years, we have used some form of the script on over 10 different jobs, nationally and internationally.  As Jonathan Ammon showed in the below image at BIMForum, owners particularly like the ability to show their architects and engineers that design 'clash-free' does not equal 'free of conflicts.' Because of the work that Jonathan put into that process, Gilbane saved the entire design team a significant amount of heart-break and money when it came time to integrate some of the tenant systems into our core-shell job.

Soil Stratification Visual Analysis

One of the most difficult parts of construction is understanding the subsurface ground conditions.

How much soil is there?
What is the classification?
How long do we need to treat the soil once it's out of the ground?
Where can the soil go once it's been removed?
Why am I on this wall?
Where's Buttercup?

In the past, we've done some neat work with soil logistics once it's been removed, but what about planning while it's in the ground?  Sure, we have soil pre-characterization reports, but they tend to look like a civil engineer and Charles Dickens teamed up to write War and Peace II.

In a perfect world, we'd get a 3 dimensional model from the civil engineer in charge of the soil report.  Since we're a few years (or decades) away from that, the next best info we have is the excel chart of soils at depths.

With some creativity (and a little brain damage), we can make something visually intelligent out of a mess of a spreadsheet.

Step 1:  Determine what data is available to you.  Ideally, you'd get the actual soil core drill data.  With that info, you know the top and bottom dimension to each strata layer from a surface dimension.

Step 2:  Re-build the core, digitally.  We do this because we're going to have a mesh, and meshes are informed by points.  Cores are roughly circular, have a center point that is easy to locate on global x,y,z, and are easy for rhino/grasshopper to play with.

Step 3:  Use some grasshopper magic to create the meshes of each strata.  Yes, there is some error in the final mesh, but it is as accurate as the cores are.  That is, the more core samples you take, the more accurate the 3D model will be.

Step 4:  Section cut for clarity.

Step 5:  Export in STL format for 3D printing.


Voila!