Building Information Modelling (BIM) entails interdependencies between technological, process and organisational/cultural aspects. These mutual dependencies have created a BIM ecosystem in which BIM related products form a complex network of interactions.¹ For a long time interoperability between these products has been essentially non-existent, resulting in users unwilling to interchange between different software platforms. Rather than using the best product for the job, users have preferred to remain in the software that they are most familiar with, possibly to the detriment of the design. One such example of this is conceptual massing within Autodesk Revit. This post explores how to extend Revit’s modelling capabilities by combining it with McNeel’s Rhinoceros and Dynamo.
It is important to emphasise that BIM is an ecosystem and that there is no single software that can do everything. Within the graphic design industry, Adobe has recognised this and have produced a suite of software including; Photoshop, Illustrator and InDesign amongst others. Each software has a very clear and well defined scope. Photoshop is used for raster images, Illustrator for vector images and InDesign to compile it all together. Each software is separate but linked together in the workflow. In general, architects are accepting of this ecosystem and are agile enough to move between each platform. However, this ethos of a software ecosystem needs to be applied to BIM software as well.
Software ecosystems: Adobe vs Autodesk
The term ‘BIM’ can mean different things to different people. Despite BIM bridging across the entire project from conception through to facilities management, depending on who you talk to, different people will have different biases. For example, as an Architect, I am naturally more interested in geometry and the design authoring phase of BIM. These biases which are epidemic in the AEC industry is elaborated on in Antony McPhee’s post, ‘Different BIMs for different purposes‘. With so many perspectives of what BIM is, one needs to question the role of a BIM Manager. Dominik Holzer is his RTC Australasia presentation, ‘You are a BIM Manager – Really?’ discusses how BIM managers need to go beyond tool knowledge and develop management acumen. But that can be a hard thing to accomplish. Even if we focus on a particular BIM bias, say Design Authoring, there is a plethora of tools out there that a BIM manager must master, or at the very least, have an appreciation of. Here is just a few of them.
Most of the software mentioned above is generally accepted as part of a BIM workflow. Why then are so many people resistant to creating a federated model and instead insist that everything must be created within Autodesk Revit? It was a pleasure to see that this year’s RTC Australasian conference was run in conjunction with Archicon, ArchiCAD’s equivalent conference. This was a small acknowledgment from the profession that BIM is bigger than just a single piece of software and that we need to seriously consider interoperability in our workflows.
Although Autodesk Revit is often chosen as the primary documenting tool in many architectural offices, it is widely acknowledged that Revit is extremely limited in dealing with complex conceptual modelling. Autodesk’s attempts at introducing a dedicated conceptual modelling environment in the form of FormIt and Inventor haven’t really taken hold of as of yet. As a work around, many offices have adopted McNeel’s Rhinoceros, or Rhino for short, for the conceptual design phase and Autodesk Revit for the development and documentation phases.
The integration between McNeel’s Rhino and Autodesk’s Revit in the past has proven to be a challenge for many designers looking to combine freeform geometry with BIM. These interoperability barriers are partly due to Revit’s API limitations and also arguably, a lack of development of the Industry Foundation Class (IFC) file format, which promised universal interoperability within the AEC industry.
IFC: A promise of universal interoperability
The other barrier is one of culture and perception. Rhino is sometimes regarded as useful for conceptual modelling only, whereas Revit is preferred for documentation. Over and over I see these two worlds failing to collaborate. The scenario generally looks something like this: Young, recent graduates who are relatively computational literate, spend long hours at the office to win a competitions. These people then jump onto other projects and if the competition is awarded, a new team is put together to deliver the project. This will most likely contain more experienced architects more attune to developing and delivering the project. The Rhino model is thrown out and completely rebuilt from scratch within Revit. Sound familiar?
The problem with this approach is that it more often than not involves loosing much of the intelligence built into the original design. And since Revit is unable to accurately recreate complex geometry, the design needs to be dumbed down to comply with Revit’s limitations. This methodology couldn’t be further from what BIM set outs out to achieve. So what is the solution?
For some, the solution is simply to produce everything natively within Revit from the beginning. However, as shown in this case study, Revit sometimes simply isn’t capable of creating the desired forms. One therefore needs to look to other software that can, such as Rhino, but this too can have limitations.
Those that have attempted to use Rhino geometry within Revit will be all too familiar with the difficulty in successfully achieving this. The most basic method is to simply export a *sat file from Rhino and then import it into Revit. Best practice is typically to do this via a conceptual mass family. However, the result can be called ‘dumb geometry’ in that it is unable to be edited once imported, which is far from ideal in a BIM environment.
The next progression in usability is to explode the import instance. Depending on the base geometry, Revit may make editing the mass accessible via grips (push/pull arrows) but this is not always the case. However, the best method to generate native Revit elements from Rhino is to use the wall-by-face, roof-by-face, curtain system and/or mass floors commands. These elements will be hosted to the Rhino geometry. In theory, these elements can be updated if the base geometry changes but experience has shown that Revit is not always able to re-discover the host element and new elements will need to be created. Therefore, it is prudent to test the Rhino to Revit workflow before investing in too much time in embellishing the Revit elements.
The whole process of using Rhino geometry in Revit feels a bit like black magic. Often, the first attempt in importing the geometry will fail and there will be no guidance from Revit as to why it failed. This can prove to be very frustrating and many users will simply give up. However, if these best practices are followed when generating the mass in Rhino, integration with Revit should be seamless, or at very least, less painful.
The best practice mentioned above all rely on more or less the same techniques once in Revit: wall-by-face, roof-by-face, curtain system or mass floors. In other words, a base mass needs to be provided to host the element. But what if you want to create other elements which aren’t roofs, floors or walls? This is where third party plug-in come into play. Some of these (past and present) include:
- Chameleon – Uses Chameleon Adaptive Component Systems (CACS). The workflow is bi-directional whereby geometry can be created in Grasshopper, exported to Revit and then re-imported back into Grasshopper.
- Geometry Gym – Allows Grasshopper geometry to be translated into Revit using OpenBIM formats (primarily *ifc). The Industry Foundation Classes (IFC) is a neutral platform, open file format specification that is not controlled by a single vendor or group of vendors. It is an object-based file format with a data model developed by BuildingSMART. This workflow is probably the most complicated but potentially allows much greater control over the geometry and the element properties.
- Grevit – Enables you to assemble your BIM model in Grasshopper and send it to Revit or AutoCAD Architecture. Once the elements have been sent, their geometries and parameters can be updated by another commit.
- Hummingbird – This process exports basic geometric properties and parameter data to Comer Separated Value (*csv) text files. In Revit, this data is easily imported using the WhiteFeet ModelBuilder tool which is included in the download. In April, 2015 Hummingbird was updated to support Revit geometry into Rhino making it bi-directional.
- Lyrebird – Similar to Chameleon in that it uses adaptive components but is only uni-directional.
- OpenNURBS – Plug-in for Revit to allow Revit to automate the process of importing Rhino geometry.
Rhino to Revit plug-in comparison
Regardless of the plug-in adopted, there were common limitations amongst them:
- Complex geometry – Apart from OpenNURBS, the plug-ins don’t actually export Grasshopper geometry you have created but rather re-creates that geometry in Revit through a series of input parameters. For example, if exporting a wall from grasshopper you don’t reference the wall, but rather you are required to define the walls centre line and height for it to be rebuilt within Revit. Therefore, if the wall is irregular in height, it will not translated accurately.
- Longevity – As shown in the table below, many of the plug-ins have either been discontinued (as is the case with Chameleon and OpenNURBS) or made open-source (such as Grevit and Lyrebird) and has stopped being updated regularly.
Timeline of interoperability plug-ins as at June 2016.
- Unidirectional – With the exception of Chameleon and only recently, Hummingbird, most of the plug-ins are unidirectional which significantly limits interoperability.
- Classification – Only selected Revit elements were able to be created. If for example you wanted to create a ceiling or stair you couldn’t as there were no components for it.
However with the introduction of Dynamo, a whole new world of possibilities have emerged to facilitate interoperability. Since the release of Dynamo 7.2 back in September 2014, three new interoperability tools have emerged:
- Flux – The new kid on the block and without a doubt the most promising. Flux provides cloud-based collaboration tools to exchange data and streamline complex design workflows. Flux plugins work with Rhino/Grasshopper, Excel, and Revit/Dynamo, to automate data transfer to and from Flux. Flux also has plans to expand this design software to include: AutoCAD, SketchUp, Revit and 3D max. A Flux project is the focal point for data exchange and collaboration. You can invite teammates into your project to share data. Each user and application controls when to synchronise data with the project, allowing users to work in isolation until they are ready to share their changes with the team. Since Flux was developed by Google[x], it will only work with Google Chrome.
- Mantis Shrimp – Allows you to read Rhino’s native *3dm file type as well as export geometry from Grasshopper. Mantis Shrimp works in a similar manner to Rhynamo.
- Rhynamo – An open-source node library for reading and writing Rhino *3dm files. Rhynamo uses McNeel’s OpenNURBS library to expose new nodes for translating Rhino geometry for use within Dynamo. In addition, several experimental nodes are provided that allow for ‘Live’ access to the Rhino command line.
To assist Rhino users in becoming acquainted with Dynamo, I have produced a ‘Dynamo for Grasshopper Users‘ primer. Since everything is a little different in Dynamo, the primer provides a list of ‘translations’ in order to find a comparable node/component.
To date, most of the tutorials presented on Parametric Monkey have focused on Rhynamo. Since, Rhynamo doesn’t work out of Grasshopper (as it needs to have baked Rhino geometry) we will need to use Elefront for our data management. Elefront was developed by Ramon van der Heijden and is a plug-in focusing on managing model data and interaction with Rhino objects. The plug-in allows users to bake geometry to the Rhino model with the option of specifying attributes, including an unlimited amount of user defined attributes by means of key-value pairs. This way it is possible to treat a 3D Rhino model as a data base, where each object ‘knows’ what it is, what it belongs to, where it should go, what size it is, when it needs to be fabricated, etc. Instead of trying to store geometry in a database, Elefront stores data in a ‘Geometrybase’, thereby turning your Rhino model into a quasi BIM model. Elefront is therefore ideal for combining with Rhynamo to export Grasshopper data into Dynamo/Revit.
The purpose of this post was to present the notion of a BIM ecosystem and encourage an open and agile workflow amongst the AEC profession. To illustrate this notion, the post explored in detail how to extend Revit’s modelling capabilities by combining it with Rhino and Dynamo to create an integrated BIM environment. It is hoped that though a greater awareness of all software’s strengths and weaknesses, BIM professionals can use the right tool for the job, rather than being constrained to a single software.
1 Gu, N. et al. (2016). BIM Ecosystem: The co-evolution of products, process and people.