How to Create Revit-like Adaptive Components in ARCHICAD?

archicad-gdl-peaks-troughs

I have been experimenting a lot these days with the GH-AC Live Connection and have been trying to push it’s limits and find new uses for some of it’s amazing features.

I was in a discussion with a fellow colleague about how when Revit Adaptive Components was introduced in 2011, it quickly became one of the most sought after workflows to create repeating parametric systems that conform to some user defined constraints. Adaptive points in Revit are created by modifying reference points. The geometry drawn by snapping to these flexible points results in an adaptive component. Adaptive components can then be used to pattern panel families, adaptive component families and conceptual massing environment.

I wanted to explore if we can create something similar to Revit Adaptive Components using the GH-AC Live Connection. This experiment is divided into 2 blog posts with increasing complexity and detail.

You need to have the latest Rhino, Grasshopper, ARCHICAD and the GH-AC Live Connection installed for this to work.

This blog post explores the idea of creating a simple parametric GDL Library Object in ARCHICAD and control the parameters of that Object via Grasshopper using the GH-AC Live Connection. To illustrate it with an example, I have created a mesh of points in Rhino that describes a surface consisting of peaks and troughs. Let’s now try to parametrically define and control the surface using Triangulated panels in ARCHICAD.

Point Mesh in Rhino

Creating a Parametric GDL Object in ARCHICAD

Let’s start by creating a simple Triangular Plane object in GDL. GDL (Geometric Description Language), is a parametric programming language proprietary to Graphisoft. It describes 3D solid objects like doors, windows, furniture, structural elements, stairs, and the 2D symbols representing them on the floor plan. These objects are called library parts.

I understand there is a general perception that GDL scripting is hard and complex, but it is not always so. In this case, we want to create a simple 3 point plane with a material attribute which we will later control from Grasshopper. We literally need only two lines of code; so stay with me.

Rhino file + Grasshopper script + ARCHICAD GDL Object

.Zip folder – 12.0 MB – 5 files

Download Now

When you create a new Object (File > Libraries and Object > New Object), the subtype is usually a Placeable ‘Model Element’. We can edit it to make the new Object as a sub type of any other building element like walls, beams or furniture. I will go into further detail about this in the next blog post, but for now, let’s leave it as it is.

GDL Details

We will have to write the code for creating a 3 point Plane In the 3D Scripts pane of the editor. Let’s refer to the GDL syntax manual published by Graphisoft for creating a Plane in GDL. The syntax is as below.

PLANE n, x1, y1, z1, ... xn, yn, zn

where PLANE is a polygon on an arbitrary plane with ‘n’ edges (n >= 3). x1, y1, z1, … xn, yn, zn are the 3D coordinates of the points making up the polygon. It is better if the polygon is planar, though the interpreter doesn’t check this condition.

Since we want to create a 3 point Plane, the syntax should be:

PLANE 3, X0, Y0, Z0, X1, Y1, Z1, X2, Y2, Z2

where X0, Y0, Z0, X1, Y1, Z1, X2 , Y2, Z2 are variables which we will control parametrically from Grasshopper.

Now that we have created the plane, it would be great if we can add Material properties to it. The syntax for that would be:

MATERIAL _mat

where _mat is the variable for surface material.

Click on the ‘Check Script’ button to make sure there are no errors. And that’s it. With just these 2 lines of code, we can create any pattern of Triangulated Panel geometry and parametrically control them using Grasshopper.

The 2D Script pane contains parametric 2D drawing description and allows us to visualize the 3D geometry in 2D. Let’s leave the 2D Scripts pane blank for now. We will get back to this in the next blog post.

GDL 3D Scripts

In the Parameter script pane, sets of possible values can be defined for the Object’s parameters. Since we created this new object as a subtype of ‘Model Element’, the default parameters for that subtype are inherited and appear in blue. We can either delete the parameters or choose to ignore them by clicking on the red cross button under Display.

Then, we will have to add the coordinate parameters, X, Y & Z for the 3 points as variables. You can click on the ‘New’ button and add the Variable (same as defined in 3D Scripts pane), Type (length, angle, boolean etc.), Name (as you want to see in Grasshopper) and Value (could be 0, since we will anyway control this from Grasshopper). Using this method, we will have to add all the 10 variables defining the 3 points and its surface material.

Although we have created the 10 parameters needed, Grasshopper, by default, cannot access the parameters of ARCHICAD’s Library Parts. We can enable Grasshopper to access the object’s GDL parameters by simply adding one more variable.

To allow that, we have to create a ‘Boolean’ type variable called ‘ParamcontrolByGrasshopper’ and set it to ‘On’. Click on the red cross button under Display to make the variable invisible on the user interface of Grasshopper.

After everything is set up, use File > Save as to save the Library Part under a new name to the Embedded Library.

GDL Parameters

Controlling GDL Object from Grasshopper

Now that we have created the GDL object, let’s setup the grasshopper script that can define the surface consisting of peaks and troughs in ARCHICAD. The idea is to create a Grasshopper network that simply takes the surface generated in Rhino and creates a mesh of points which act as inputs to the GDL Object.

Once we have the network setup, let’s use the Object Settings node from the ARCHICAD tab in Grasshopper. Right click on the node to bring up a contextual menu from where we can choose the ARCHICAD Library Part and it’s parameters to edit. Remember to turn on the GH-AC Live connection (Design > Design Extras > Live Connection) for the menu in Grasshopper to show up.

Every parameter that we check in the menu will appear as an input parameter on the left side of the Object Settings Node. From this point on, we can define and control the GDL Object in Grasshopper.

GH-AC Live Connection Grasshopper Interface

Final Result in ARCHICAD

Once we setup the Grasshopper script completely and turn On the Live Connection, we can see the geometry being translated to ARCHICAD seamlessly as native BIM Elements. We can look at the X,Y,Z and material parameters of each object from the Object Settings dialog box in ARCHICAD. As we modify the mesh of points in Rhino, the BIM model gets updated automatically to form a surface of Triangulated panels in ARCHICAD.

Final Result

Option 2

Option 3

This post was imported into WordPress in one click using Wordable

Top 3 Computational BIM Workflows for Architects

For a long time, interoperability between Conceptual modelling 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.

In a previous blog post, it was discussed why it is often 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.

Let’s take a look at the various Computational BIM workflows that are currently in use in the AEC Industry.

Top 3 Computational BIM Workflows for Architects

Powerpoint Presentation – 3.5 MB – 30 Slides

Download Now

Computational BIM Workflows

Computational BIM Workflows

Loosely Coupled Workflows

Patrick Janssen, in his research paper, had categorized Computational BIM workflows as either Tightly Coupled (fully compatible) or Loosely Coupled (fully interoperable). With the Loosely Coupled approach, systems are coupled through model exchange. The graph-based system typically generates data in a standard file format like IFC that can be directly imported into the BIM system. The Industry Foundation Classes (IFC) is a neutral, object-based, open file format specification with a data model developed by BuildingSMART.

Geometry Gym

A complicated workflow, but allows for greater parametric control over IFC properties.

Geometry Gym Nodes

Geometry Gym for Rhino/GH

Geometry Gym takes the loosely coupled approach and generates data in OpenBIM formats (primarily IFC) that can be directly imported into any BIM software. This plugin uses the dataflow modelling capabilities of Grasshopper to directly generate the IFC exchange model, thereby avoiding the need for a separate exporter altogether. The advantage is that it doesn’t have to deal with the explicit geometry generated by the baking process. And it does a very good job of generating the IFC.

However, the disadvantage is that the dataflow model becomes riddled with data exchange nodes that have only marginal relevance to the parametric modelling task. These additional nodes significantly increase the complexity of the dataflow graph.

VisualARQ

An easy-to-use Rhino to IFC plugin.

VisualARQ for Rhino/GH

VisualARQ for Rhino/GH

VisualARQ supports import and export from and to IFC file format to exchange Rhino models with other BIM applications. It allows the user to create parametric architectural objects like walls, beams, stairs, doors, windows, roofs etc. and control them parametrically within the Rhino environment. Block items such as windows and doors can be moved or modified within walls without the time consuming process of rebuilding or patching wall surfaces as would normally be the case in Rhino.

However, not all Rhino commands are compatible with VisualARQ. One needs to get used to VisualARQ’s modelling toolset, which is a little different to Rhino, especially Boolean operations.

The best part of VisualARQ is it’s impressive ability to create, edit and modify NURBS based BIM objects and add IFC tags to those objects, all from a familiar Rhino environment. The Grasshopper Components add-on allows you to work with VisualARQ objects directly from Grasshopper as well.

Möbius

A promising web-based Parametric BIM Modeler.

Mobius

Mobius

Möbius is a web-based visual dataflow modelling environment for creating parametric models. It combines graph-based programming consisting of nodes and wires (like Houdini) and blocks-based programming consisting of sequences of code blocks (like Scratch) to support encapsulation, iterative looping and higher order functions. A big advantage is that Möbius runs entirely on the browser, on the client side. It is developed as an Open Source project written in Javascript that allows users to save their parametric model as pure Javascript code. These scripts can then be executed in other environments, independently from Möbius.

Additional viewers and function modules are being developed for BIM and GIS. It’s capacity to handle ‘nimble BIM’ models on the browser will determine its usability for Computational BIM workflows. Mobius is being developed by Dr.Patrick Janssen & Team at Design Automation Lab in NUS, Singapore.

PlusSpec

Probably the easiest SketchUp to BIM workflow, but expensive.

PlusSpec

PlusSpec for SketchUp

Sketchup is the most popular 3D modelling tool for concept design with a base of 30+ million users. PlusSpec works inside Sketchup, taking advantage of such a large user base, to introduce new parametric power to draw, edit and inspect BIM elements and produce building specification. There has not been any serious BIM plugin that helps speed up modelling, drawing creation, materials takeoff, and all the admin tasks and coordination that are usually less optimal to do in SketchUp. PlusSpec fills that gap quite well with a light-weight BIM approach and is ideal for small-mid scale projects.

But what might probably put many people off is the high cost of this plugin. This BIM plugin costs as much as Sketchup itself, and whether that cost is worth it or not is for you to decide.

Tightly Coupled Workflows

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.

One of the earliest plugins that was developed for Rhino-Revit interoperability was Chameleon, which was released way back in 2012. It uses Chameleon Adaptive Component Systems (CACS) to translate geometry from Grasshopper to Revit. It has a bi-directional workflow where BIM elements created in Revit could also be translated to Grasshopper for manipulating parameters and re-imported back to Revit. Unfortunately, the plugin has not been updated in over 3 years and is not active anymore. But if you are still keen to use this plugin with Revit 2016, there maybe a workaround.

  1. Install Chameleon for Revit 2012 following the install instructions.
  2. Copy the files in this folder:
    C:/Users/yourusername/AppData/Roaming/Autodesk/Revit/Addins/2012
  3. To this folder:
    C:/Users/yourusername/AppData/Roaming/Autodesk/Revit/Addins/2016
  4. Open Revit 2016.

Lyrebird is another plugin similar to Chameleon that also uses Revit Adaptive Components but is uni-directional only. Even this plugin hasn’t seen an update in over 2 years and is not active.

Let’s take a look at those plugins that are under active development.

Hummingbird

Works well for simple projects with repetitive elements.

Humming Bird

Hummingbird for Rhino/GH & Revit

Hummingbird was developed as a set of Grasshopper components that enables the creation of native BIM elements in Revit. The process involves exporting geometry and its associated parameters as a CSV text file. This file is imported into Revit using a plugin called WhiteFeet ModelBuilder which then recreates that geometry in Revit through a series of input parameters. This workflow is rather slow and tedious especially where the model is quite large. Also since it cannot accurately transfer complex geometry such as tapering walls and doubly curved surfaces, it is quite limiting in it’s use case.

Grevit

A promising plugin for Rhino/GH & SketchUP to Revit interoperability.

Grevit

Grevit for Rhino/GH, SketchUp & Revit

Grevit allows to assemble a BIM model in either Sketchup or Grasshopper and send the geometry to Revit or Autocad Architecture as native BIM elements. It can work concurrently such that a user working in GH and another user working in SketchUp can both send their models to the same Revit instance using Grevit. Every Grevit component instance gets a unique GUID when it is being created. In Revit, this GUID is stored in a parameter and is used to identify the element in Revit whenever an update is being pushed from GH or SketchUp. In SketchUp, the user has to simply name the SketchUp Components in his model as wall, floor or column and import the SKP file into Revit using the Grevit SketchUp Importer.

Grevit is Open Source and still under active development. So the user may encounter a few bugs in the process.

Top 3 Computational BIM Workflows

All the plugins discussed till now link Rhino to Revit by calling the Revit API directly. So a lot of their shortcomings are mainly due to the limitations of Revit API. But when Autodesk, in 2014, introduced an open-source Visual Programming tool called Dynamo, it seemed to open up a lot of possibilities for better interoperability between Conceptual Modelling tools and Revit. Since then, a few plugins have been developed that translates Rhino/GH geometry to Revit via Dynamo.

3. Rhynamo & Mantis Shrimp

One of the better Rhino-Revit interoperability plugins.

Rhynamo

Rhynamo for Rhino & Dynamo; Mantis Shrimp for Rhino/GH & Dynamo

Rhynamo is an open source plugin authored by Nathan Miller that enables reading and writing of Rhino .3dm files inside of Dynamo. This plugin also allows users to create bi-directional workflows where one can author Rhino files from Dynamo. However, Rhynamo operates only with baked Rhino geometry and not directly with Grasshopper. So data management is an issue. As a workaround, one may have to use another GH plugin called Elefront to add attributes to Rhino objects. Elefront stores this data in a ‘Geometrybase’, thereby giving Rhino objects a layer of embedded intelligence. Once baked, this ‘nimble-BIM’ model can be transferred to Dynamo using Rhynamo.

Mantis Shrimp, similar to Rhynamo, is a Dynamo and Grasshopper interoperability plugin that allows you to read Rhino’s native *.3dm file type as well as export geometry from Grasshopper. It is an open source project written in Python in the form of a user objects (on Grasshopper side for exporting) and custom Python nodes (on Dynamo side for importing).

With both these plugins, the user has to create and manage two separate dataflow graphs; one in grasshopper to communicate with dynamo and another in dynamo to communicate with Revit. This split may cause a lot of stress for users, especially when working in large projects, to create these dataflow graphs, collaborate on them with other users and keep version control under check.

2. Flux

The future of software interoperability and collaboration.

Flux

Flux for Rhino/GH, SketchUp, Revit/Dynamo

Most of the workflow discussed until now requires the user to merge data, convert it and manually transfer the data to the tool of his choice. This workflow is not only tedious, but also error-prone. In this aspect, Flux is probably the most promising because it provides cloud based data exchange and collaboration without having to worry about interoperability. It is unequivocally focused on data rather than on files. The user can send and receive geometry and data from most of the common AEC tools (like SketchUp, Rhino/GH, Revit etc.) currently in use.

The most useful aspect of Flux is its ability to exchange disparate pieces of data from multiple software and later combine it into a consolidated whole. It can therefore support any kind of computational task related to building design such as what-if analysis, evaluation of various criteria, simulation, and even generative design. A hint of the building cognition capability of Flux, is showcased in the experimental tools and solutions of Flux Labs.

However, Flux may have a steeper learning curve compared to other plugins, mainly because of its focus on data. Like Rhynamo and Mantis Shrimp, the user has to create and manage multiple dataflow graphs (GH, Dynamo, Flux web interface), but the ease of collaboration and version control is much better comparatively.

1. GH-ARCHICAD Live Connection & Rhino-GDL Converter.

The best-in-class Computational BIM workflow ever.

Rhino/GH-ARCHICAD Live Connection

Rhino/GH-ARCHICAD Live Connection

Rather than re-invent the wheel and develop an algorithmic design tool from scratch, Graphisoft decided to integrate with the most popular application for that purpose, Rhino/Grasshopper. The Live Connection tool leverages the strengths of three design environments: Rhino for advanced 3D modeling, Grasshopper for algorithmic design, and finally ARCHICAD for BIM.

Unlike the many plugins that exists to enable Rhino-Revit interoperability, ARCHICAD’s integration with Rhino/GH goes a lot deeper, with a ‘live connection’ that enables real-time, bi-directional geometry transfer between the two applications. The connection is actually ‘live’ and operating in real-time, allowing users to conceptualize building forms and create native ARCHICAD components directly from Rhino/GH interface. In addition to creating the geometry of the components, users can also control other input parameters such as surface material, layers, dimensions, colors etc.

The Live Connection, in comparison to all other plugins, is extremely simple to use, fairly quick and works like a charm everytime. A big advantage of this workflow over Rhynamo, Mantis Shrimp or Flux is that the user has to manage only one dataflow graph in Grasshopper that allows for both Parametric exploration and BIM interrogation. Here is a wonderful case study of the process.

Another nifty tool is the Rhino-GDL converter that allows users to save a selected part of a Rhino model as a native ARCHICAD object file (.gsm or .lcf) format. Though this is not a ‘Live’ Connection, it is still a very useful means to bring organic forms that can be modeled directly in Rhino into ARCHICAD, without any scripting.

Conclusion

In a previous blog post, it was discussed why it is often better for designers to create a federated BIM model using Computational BIM workflows rather than struggle with the limitations of any one BIM system.

This blog post aims to showcase, in detail, the many Computational BIM workflows currently in use in the AEC industry. The idea was to adopt a tool-agnostic approach in dissecting the advantages and limitations to each of these workflows. While the top 3 workflows have been picked for the benefit of the uninitiated, there are other factors like cost, that needs to be taken into account when making a decision. So, it is strongly advised to adopt a ‘horses for courses’ strategy when it comes to choosing the right tool for your job.

Why do Architects need Computational BIM Workflows?

toolbox

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 acknowledgement 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 modelling 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 licences. 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

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 modelling. Autodesk’s efforts at pushing FormIt, a browser-based conceptual modelling environment, hasn’t seen much uptake from the AEC industry. Most firms still use either Rhino and/or Sketchup as their primary conceptual modelling environment and use BIM systems only much later during design development and documentation phases. The barrier to integration with BIM early on is primarily because of two reasons.

SHOP Architects Workflow

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 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 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

Powerpoint Presentation – 3.5 MB – 30 Slides

Download Now

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 modelling tools like Grasshopper (GH), Blender or SideFX Houdini. Unlike BIM tools, such Dataflow and Procedural modelling 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 modelling 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 modelling modes, resulting in a steep learning curve for most users.

BIM Ecosystem

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 a 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

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 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

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, 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.