Why do Architects need Computational BIM Workflows?

BIM is a Workflow

Let's face it. BIM is not one software. BIM is a workflow involving an entire ecosystem of tools, scripts, plugins, and software. There are different BIM workflows for different purposes depending on the phase of the project we are in; Survey, Design, Construction, or Facilities Management. For eg. A FM BIM model is a static virtual model of what is unlike Design BIM or Construction BIM which are virtual models of what is to be. Antony McPhee elaborates on these different BIM workflows in his blog post on 'Different BIMs for different purposes'. So there is a growing acknowledgment within the AEC community, that BIM can mean different things to different people depending on what they set out to achieve from their BIM workflow.

BIM can mean different things to different people depending on what they set out to achieve from their BIM workflow

For a long time, interoperability between Conceptual modeling tools and BIM software has essentially been nonexistent. Hence, instead of using the best tool for the job, a large section of designers chose to use one BIM software that they are most familiar with for both design exploration and interrogation, possibly losing out on creative freedom. This, of course, made economic sense to many small to mid-scale offices that do not have the resources to purchase and maintain multiple software licenses. They couldn’t derive much value from investing a lot of money in Design Exploration tools when all one could bring into BIM was ‘dumb’ geometry.

Tool vs Toolbox

Instead of using the best tool for the job, a large section of designers choose to use one BIM software that they are most familiar with for both design exploration and interrogation, possibly losing out on creative freedom

However, things are changing faster than ever. In the last 2-3 years, many interoperability plugins have been developed to significantly improve the robustness of BIM workflows.

What is the need for Computational BIM Workflows?

Although Revit, ArchiCAD or Vectorworks is often chosen as the primary documentation tool in most Architectural offices, it is widely known that they are not the preferred tools for conceptual modeling. Autodesk's efforts at pushing FormIt, a browser-based conceptual modeling environment, hasn’t seen much uptake from the AEC industry. Most firms still use either Rhino and/or Sketchup as their primary conceptual modeling environment and use BIM systems only much later during design development and documentation phases. The barrier to the integration with BIM early on is primarily because of two reasons.

SHOP Architects Workflow

Firstly, most architectural contracts in Asia are split between Concept design and Detailed design with the latter awarded only when the former is fully approved by the Client. Since the timeline for the Concept design phase is generally short, designers tend to use tools that are better suited to design exploration than design interrogation. It also makes sense, in the Concept design phase, to keep the model ‘nimble’ since designers may not yet have the ‘information’ part of BIM.

Once the Firm is awarded the subsequent contract for the project, another team takes over and the model is re-built from scratch in Revit or ArchiCAD. In the process, a lot of parametric and associative intelligence built into the Conceptual model is either lost or dumbed down to comply with the BIM tool’s limitation.

Top 3 Computational BIM Workflows for Architects (PDF / 3.5 MB / 30 Slides)

Some could argue that the solution is simply to create everything natively within the BIM software from the beginning. Which brings me to the second reason, that, most BIM tools are extremely limiting in creating complex geometry natively. If one doesn’t have a firm grip over scripting, it is quite tedious to develop certain building forms natively in BIM. It is comparatively simpler and quicker to model in Rhino or Sketchup.

Also, it is quite common to generate complex, non-standard structural or facade elements using Parametric modeling tools like Grasshopper (GH), Blender, or SideFX Houdini. Unlike BIM tools, such Dataflow and Procedural modeling tools support multi-operation iteration that helps create complex building forms quickly and is therefore ideal for design exploration.

Most BIM tools are extremely limiting in creating complex geometry natively. If one doesn’t have a firm grip over scripting, it is quite tedious to develop certain building forms natively in BIM which is comparatively simpler and quicker to model in Rhino or Sketchup

Another option is to use an embedded BIM system that supports both design exploration and interrogation like Autodesk Dynamo, Vectorworks Marionette, or Bentley Generative Components. They are largely targeted at users who prefer to remain in the BIM software that they are most familiar with. But, even for them, it may not be a practically viable option for two reasons.

First, BIM models are by their very nature large complex datasets. As a result, allowing users to parametrically explore such models may severely reduce the latency and robustness of the system. This is already evident within Revit, where making parametric constraint-based changes to large models can become slow and may often result in errors that are unclear even to expert users.

Second, BIM systems already have very complex user interfaces, and adding advanced dataflow and procedural modeling capabilities may result in a user-interface that is overly complex for either use case. Again taking Revit as the example, the user interface can already be seen to be very complex, with multiple different but interrelated modeling modes, resulting in a steep learning curve for most users.

BIM Ecosystem

Therefore, it is better for designers to create a federated BIM model using Computational BIM workflows rather than struggle with the limitations of any one BIM system. Although integration of geometry from tools like Rhino/GH with BIM has always been a bit of a black box, many interoperability plugins have been developed to significantly improve the robustness of Computational BIM workflows.

Why Not Direct Import-Export?

For a long time, the only way to get Rhino geometry in Revit was to export a *.sat file and then import it into Revit via a Conceptual Mass Family. But this was ‘dumb’ geometry which cannot be edited in Revit, unlike native Revit elements. It acted more like a placeholder geometry to extract drawings from Revit rather than become a complete BIM environment. Later, Autodesk introduced the option of creating native Revit elements from Conceptual Mass Family using the wall-by-face, roof-by-face, mass floors, and curtain wall system commands. These elements are hosted to the imported Rhino geometry and can be updated if the base geometry changes.

But, from experience, it is known that Revit doesn’t always recognize or re-discover the host element and new elements will have to be created. And when it fails, the user will have no clue why it failed, adding to the frustration.

There are, of course, best practices for creating Rhino geometry that would allow for easier integration with Revit. But what if we want to create elements that are not walls, floors, or roofs? Also, what if we want more precise control of the BIM elements and all of its properties? This is where the third-party interoperability plugins for BIM becomes extremely useful.

How To Classify Computational BIM Workflows?

Patrick Janssen, in his research paper, had categorized Computational BIM workflows as either Tightly Coupled (Fully compatible) or Loosely Coupled (Fully interoperable). Areo in their blog post had described the same in a diagram below representing ‘degrees of interoperability’.

Degrees of Interoperability

With the Tightly Coupled approach, systems are coupled through the Application Programming Interface (API) provided by the BIM system. In this case, graph-based systems communicate via the API of the BIM system, directly instantiating geometry in the BIM model each time the graph-based model is executed. Examples of this approach are GenerativeComponents which uses the AecoSIM API, and Dynamo, which uses the Revit API.

With the Loosely Coupled approach, systems are coupled through the model exchange. The graph-based system typically generates data in a standard file format that can be directly imported into the BIM system. An example of this approach is GeometryGym, a plugin for Rhino/GH that uses IFC as the exchange format. The Industry Foundation Classes (IFC) is a neutral, object-based, open file format specification with a data model developed by BuildingSMART.

Computational BIM Workflows

Both these approaches have their inherent advantages and limitations depending on the level of BIM maturity one is seeking. The advantage with the Tightly Coupled workflow is obvious; it is fully compatible with the BIM system of one’s choice. It is of no surprise that it is the most popular workflow in Architecture firms because the user knows in advance which BIM system should the model end up in. However, the sharing of models with consultants will be file-based collaboration and not on any open standard.

The fundamental advantage of the Loosely Coupled approach is that it is workflow agnostic, allowing users to link together tools and systems to support various forms of collaboration and exchange. For example, since GeometryGym outputs a standard IFC file, users have the choice to link to any BIM application that can import an IFC file.

Though, in practice, there are still many issues with IFC implementation among major software vendors. It requires the vendors, buildingSMART, and the extended community to work through some limitations and constantly improve both the standard and its implementations.

The fundamental advantage of the Loosely Coupled approach is that it is workflow agnostic, allowing users to link together tools and systems to support various forms of collaboration and exchange.

Conclusion

The diagram above shows all the plugins developed for enabling Computational BIM Workflows. A few of them have been discontinued or stopped being updated on a regular basis. Nonetheless, it is important to understand the capabilities and limitations of each of these workflows. Let us take a deep dive into these plugins, comparing, contrasting, and evaluating each of them in the next blog post.