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

Introduction

In Part 1, we discussed how the demands of complex projects had driven some in the industry to take coding and data into their own hands.  This has meant learning Object Oriented Programming in AEC breaking with the decades old tradition in the AEC industry of use exclusive use of off-the-shelf software.  In Part 2, we will describe how the BHoM was born from this need and why it represents a tectonic shift in the AEC industry.  Fast forward into the following video 30 minutes if you’d like to see a presentation on Part 2:

BHoM – A Change in Priority (2015-Present)

Defining objects in Visual Basic, C#, or Python to be used in Grasshopper or Dynamo, whilst extremely useful on a project, leads to a new bottleneck – the creation of new digital objects from scratch on every project.  However, the definition of those objects may be very similar to a definition that was made by somebody else on another project or in another programming medium.  For instance, I could have created a custom “Beam” object using Visual Basic in Grasshopper, but you could have done the same in Python from Dynamo.  But certainly, there should be one definition for common objects, right?  After all, there must be certain properties that holistically define a “Door”, “Wall”, “Street”, or “Beam” which we can all agree upon.  What’s more, a custom digital object defined in Visual Basic in Grasshopper cannot be easily transmitted out of the Grasshopper medium, thus limiting the scalability of this way of working, as it inherently limited by the choice of software in which the objects are programmed, thus making this way of working unconducive to collaboration and teamwork.

The creation of the BHoM was aimed at solving these two problems:

1. Defining a framework in which the industry could collectively define the digital definition for objects
2. Providing a scalable, open-source platform by which mass-participation in coding could take place

Collectively Defining Objects

The first idea is with the hypothesis that if we all sat around a common scripting library which everyone could change and tweak to their common needs, eventually, the community would converge on the holistic definition of an object collectively.  At the start of the creation of any BHoM object, there are some exciting conversations as to the hierarchies and dependencies of various objects we use as part of our design process.  For instance, as a structural engineer, we would ask questions like “What’s the definition of a ‘point’?”, “What’s the definition of a ‘node’?”, and “What’s the relationship between a ‘point’ and a ‘node’?”.

This conversation marks a key change in the industry – taking responsibility for the digital definitions of our designs. 

Why is this such an important change?  Well, in the example of ‘node’ vs ‘point’ for instance, many a structural engineer have been predisposed by their particular software of choice to think of these two items as one in the same.  The reason for this is simple – the AEC industry has no common language.  We have never agreed a common vernacular which consistently leads to miscommunication.  Instead, we have given the responsibility of that common vernacular over to the software houses.  Therefore, our lingua franca has become more about software, rather than first-principle design, and inevitably confused first-principle definitions with software specific definitions.  One of the main problems with this is that the software houses are not on the front line of design and do not have their fingers on the pulse of the industry as much as the day to day designers.  What’s more, the software in our industry has been monopolized, which has disincentivized companies to innovate.

However, once we stop letting these software houses be the be all and end all of the our objects’ digital definitions, magic happens.  In this new way of working, we begin by breaking free of software constraints and defining on paper the holistic definition of the object in question.  This leads to deep conversations as to the fundamental nature of the objects we use on a daily basis.  These conversations eventually converge to a series of object definitions which have been collectively discussed, tested, and defined by the people closest to the design action and not in some far off software house.  What’s more, the code that eventually comes as a byproduct of these first-principle discussions eventually becomes the dictionary of vocabulary terms for the industry.

Therefore, now that the BHoM is open sourced, anybody in the world can go open the code of the BHoM and see the definition of a ‘node’ or a ‘point’:

As can be seen above, even though this example is a structural engineering example, it’s quite simple to look at the code and understand the hierarchy of objects:  A point is a piece of geometry whereas a node is an object that contains a point and another object called a constraint.  Not only does this help us digitally, but also, it helps us communicate on a human level – if you and I are both working to BHoM terminology and you say ‘node’, I don’t need to ask any further questions – I speak the same language as you.

Because it’s a digital dictionary, if you didn’t know what a “Constraint6DOF” was, you could just right-click the name and go to its definition to get more information on what it is:

Again, we see that a constraint has 6 doubles and 6 enums.  Doubles are just numbers, but what are the enums? Even if you don’t know what that is, again, you can right click again to find out:

Now, we’re down to just text and numbers.  This is the beauty of the BHoM – the objects which we use for our designs are digitally transparent.  You can inspect any digital object until you hit digital ‘bedrock’ – i.e. get down to its fundamental atoms of numbers, text, booleans, etc.  And the best news – if Visual Studio scares you, no worries!  You can do the same investigation in Grasshopper or Dynamo:

Again, the idea is that over time, with more and more people collectively defining objects will come a convergence of these objects definitions and hierarchies.  This represents a fundamental change to the way we design and build the built environment.

Scalability

The BHoM has been designed with the idea that it would be open-sourced which will allow for mass participation in the definition of digital objects for the built environment.  What this really implies is that the BHoM has been designed to be scalable.  It is easy for many different people, with different background, in different parts of the world to collaborate and contribute to the BHoM.  Much of this comes down to the BHoM’s underlying structure:

As can be seen above, each object in the BHoM repository has its own class definition.  This means that if I want to add a new class, I can very easily without interrupting anybody else’s workflow.  But what about if I wanted to change an existing item’s definition, such as the definition of a Grid?  Certainly that would cause problems for somebody else who is also using that object.

In this situation, we are led to the communal nature of the BHoM – one is not just allowed to change the BHoM for everyone else without everyone else having a review and their say on the matter.  Remember all that talk before about collectively deciding what our digital definitions of our objects should be?  This is it right here!  This conversation is built into the mechanics of the BHoM – by contributing code, you are also contributing to the conversation as there is not committing code without a code review and associated conversation.  Also, it should be noted however that if I wanted to change the definition of a grid to suit my own purposes I can certainly do so without pushing that change to the BHoM GitHub repository.

So by its very setup, the BHoM forces these unique conversations about the digital definitions of our objects but also, because of its structure, allows for simultaneous contribution from people all over the world.  This is what makes the BHoM scalable – it is ready for increasingly many contributors.

Another example of scalability in the BHoM is its relationship to commercial software:

We have been focusing on only the aspect of the BHoM which relates to defining all of our objects.  This aspect of the BHoM is scalable in the sense that the code repository is set up such that many people can contribute simultaneously in an efficient fashion.  Yet, a common language also helps cut down on software interoperability issues in the AEC industry.  Once you have a common language, it then becomes very easy to talk to one another via that common language.  Instead of having to write a translator from every software to every other software (graph network on the left above), we can simply create a two-way translator (a BHoM adapter) from each software to the BHoM, allowing for seamless flow of information from one party to another.  Again, this methodology is inherently scalable because everyone can be working in parallel to translate their software of choice to the BHoM.  This means that now when you write your translator to the BHoM, instead of just getting interoperability with just one piece of software, you get interoperability with all other softwares for which people have made adapters.  Therefore, your bang for your scripting buck is much greater than before.

In conclusion, the story of the BHoM is still developing from its origins of complex projects, but already, those of us using it know that it is the future.  The more people that get involved, the closer we will get to the future of the AEC industry – a industry of practitioners who wield first-principles of engineering, architecture, and construction hand in hand with first-principles of computer science.