From Morpheus Tower to the BHoM: a Tale of Object Oriented Programming in AEC (Part 1)

Introduction

I was recently invited by my friend Jason Carlow of the American University of Sharjah to help out with his fourth year studio.  As part of our week-long collaboration, I delivered a lecture to all the architecture students entitled “Finding Common Vernacular through Complex Projects”.  This presented a great chance for me to put together some material on the importance of Object Oriented Programming in AEC.  It is quite amazing to think it has been nearly three years since Jason Carlow last introduced me at the AIA event for Morpheus tower in Hong Kong.  It was a great opportunity for me to reflect on all that is happened since then in my personal and professional life as well since then.  A huge thanks to all the students, faculty, and staff that came to listen to me present at the University of Sharjah today – it was a full lecture hall of about 70-80 people!

In this lecture, I revisit some of the topics of the exoskeleton connection design we did on Morpheus we covered that AIA event’s lecture from years ago, but give it context by showing how such complex projects have driven us in the direction of the creation and open-sourcing of the BHoM.  Let’s look at the timeline on how everything has played out:

The video of the entire presentation can be seen below:

In Part 1 of this series, we will cover the first 30 minutes of this presentation to describe again the Morpheus computational workflow.  In Part 2 of this presentation, we will describe how we abstracted the object model from this and other projects to create the Buildings and Habitat Object Model (BHoM).

Morpheus Object Model (2013-2015)

Above you can see the overall script that we developed to help us deliver 2,500 exoskeleton connections for Morpheus.

In a nutshell, the Morpheus Grasshopper script essentially carries out the following tasks:

1. Import Finite Element Data from CSV files
2. Import Topology data of steel structure from Rhino and create “Node” programmatic objects
3. Map FEA data from step 1) to Node created in Step 2)
4. Determine which Nodes are Similar
5. Extrude members
6. Map forces from all nodes onto a target node
7. Create a connection based on the incoming member extrusions from step 5)
8. Push all info to FEA

For the purposes of this discussion, we will focus solely on step 2), specifically the “Node” object.  After referencing in the centerlines of the exoskeleton data and a bit of data massaging,  that geometrical data is fed into the “Curves” input of “Node Analysis” component:

As you can see, other information is fed in as well, but for the purposes of this discussion, we won’t go into detail as to what they all mean.  This is a custom Visual Basic script which has over 400 lines of code, and for this discussion, it more important that we understand what this component does on a global level.  Essentially, this component takes in a list of curves and spits out a list of custom Visual Basic objects.  Embedded within these lines of code is the underlying engineering logic that defines the primary metrics of where connections exist, what members are connection to them, and other useful metrics that will be useful downstream in the script.

Using the Grasshopper Visual Basic Script Editor, one can create a custom objects definition at the bottom of the script in the area marked ‘<Custom additional code>. 

Part of the programmatic definition of the “Lattice Node” object which is returned by the Grasshopper component is shown above.  Much like the rest of the code in this component, the properties of the object have all been inspired by first principles first on paper.  When designing this workflow to design connections, it was important to first understand from a high level what is the first-principles definition of a connection.  Once that is solved on paper, programming this type of a component to handle the heavy lifting of the data is just a means to an end.  The ultimate goal is keeping the machine in charge of data handling and the engineer in charge of the heuristic and creative design.  Being able to describe the ‘thing’ – in this case a connection – both on paper and to the machine forms the basis of the rest of the script.  From this component, our programmatic connection is passes from component to component – each one adding, reading, or changing the data embedded within that programmatic connection and with each iteration, the data within that connection becomes richer.  Eventually, the programmatic connection contains all of the data required to fully represent the connection as we want it to be on the building, at which point it is just as issue of presenting that data for once source in a proper fashion to other parties.

Other Projects’ Object Models (2014-2015)

In parallel with the Morpheus project, a lot of us in BuroHappold Engineering started to realize that we were all doing a similar thing as part of our script making – creating programmatic objects which were useful to our workflows.  For example, on one project I was helping out our facades team try to simply facade panels for a complex facade.  In this situation, we first sat down and defined first on paper what defined the variables for a panel that ultimately are the key metrics for our purposes.  The resulting panel definition was as follows:

This object definition, whilst much simpler than that “LatticeNode” definition, is the result of the exact same process of defining the problem on paper, then moving to the machine for the execution of the solution.

One other example such object creation is from the Load TakeDown Tool I was involved with creating for our project in Thailand, Suanlum Tower.  For this project, the programmatic object that was created was a “ColumnCell” which helped up capture load and subsequently take it down to the foundation:

These are just a couple of examples of the specific creation of objects on the backs of projects but it was becoming apparent that this was a common trend.  Once engineers were ‘graduating’ from simple Grasshopper and Dynamo techniques and reaching the limits of visual programming, they were increasingly turning to quick Visual Basic of C# scripts which compiled their data, curated by visual programming components and datatrees, into neat programmatic objects for ease of use downstream.

Those of us involved in this way of working were all doing something novel in the AEC industry – we were taking responsibility for our digital tools.  Our industry’s approach to all things innovation in the digital realm has been largely defined by the adoption of off-the-shelf software.  We have given the responsibility of digitally defining the objects which we create over to these software houses.  As our delivery methods have become more and more centered around the machine, we have seen that we have started to take on these software house definitions as the constraints on our designs, and have lost the ability to define from first-principles the objects we want to create.

Those of us freeing ourselves of these constraints by taking responsibility for the digital definitions of our design this way saw the power of working this way and knew it was the future of our industry.  It then became clear the way forward – let’s all start working together….

In Part 2, we will discuss how this all led to the creation and open-sourcing of the BHoM.