Sunday, October 5, 2014

Gilbane VDC's Minority Report Glove has arrived (And it plays nicely with the Rift!)

The Myo Dev Kit is Here

So this is the Thalmic Myo.  It arrived yesterday.

It uses the muscles in your arm and key binds it via Blue Tooth to most open source devices.

As part of the Dev Kit, Thalmic has given us integration with:


and, most importantly, Unity!

For those of you who don't know, here at Gilbane VDC, we're using Unity and the Rift for AEC visualization.  

What the Myo means for us, is the ability to continue to push the virtual interaction with our buildings in a way that no one has ever been able to do in the past.  In addition to using the Rift for the visuals, we will soon be able to pick up and interface with objects in the scene we're showing architects and owners.

So enjoy our demo of holding a cup of coffee while wearing the armband!   

Monday, September 29, 2014

Why we use Grasshopper and Rhino

I was recently asked:

"Why do you guys rely on Rhino and Grasshopper so much?  Aren't Revit and Navisworks enough?" 

It's a good question, after all, Revit and Navisworks are stupid-expensive platforms.  Shouldn't they be able to do everything that we need?

Well, the answer to that is complicated, because Grasshopper is seen primarily as design tool in the same vein as SketchUp: It doesn't carry industry standard sizes or ISO standard geometry in the way that we can lean on Revit for.

But when it comes to point data, that is, center-points, centroids, and most importantly, multiple lines through 2 points in non-linear planes, Grasshopper and Rhino are your best friends.

A great example of this is getting ceiling crid lines from 2D Drafting Views in Revit to show up as useful linework within Navisworks.

There is a workflow within AutoCAD that would require lots of movement with Ortho turned on, but let's face it, no one likes working in 3D CAD.  It requires you to draw in Orthographic viewpoint, and you start to feel like M.C. Esher after about 15 minutes.  


Don't you love getting shop drawings in flat-ortho?

Our fix is to write a custom projection script within Grasshopper that lets us assign 2D grid lines to the entire piece of 3D geometry for the ceiling, not just the bottom.  In CAD, this requires a ton of duplicitive clicking.  Oh yeah, and we can do an entire building with one run of the script.

We'd rather finish in 15 minutes than 2 hours.

Contributions from Ben Peek, John Myers

Wednesday, April 30, 2014

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.

Wednesday, April 9, 2014

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.


Sunday, January 12, 2014

The Better Building Bureau is headed to Stuttgart!

As part of an exciting new opportunity with Gilbane, I will be headed to Stuttgart to work with Zublin's 5D/VDC Group.

It's been an awesome 1.5 years in Boston, and I'm excited to be headed to a new opportunity.

I'll be in Stuttgart for 3-5 months, and will continue to post photos and words of wisdom from our German cousins.

I should be back in Boston in early May.

Auf Wiedersehn Amerika!