BIM ecosystem

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 virtually 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 are 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.

BIM Ecosystem_All_1600x900

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 consider interoperability in our workflows seriously.

Design authoring

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 taken hold of as of yet. As a workaround, 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.

BIM Ecosystem_IFC_1600x900

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 competition. 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 recreate complex geometry accurately, 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.

Interoperability plug-ins

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-ins 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 characteristic limitations amongst them:

  1. Complex geometry – Apart from OpenNURBS, the plug-ins don’t actually export Grasshopper geometry you have created but instead 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 be translated accurately.
  2. 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.

  1. Unidirectional – With the exception of Chameleon and only recently, Hummingbird, most of the plug-ins are unidirectional, which significantly limits interoperability.
  2. 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 similarly to Rhynamo.
Logo_Mantis Shrimp_1600x800
  • 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’ to find a comparable node/component.


Dynamo for Grasshopper users primer

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 using key-value pairs. This way it is possible to treat a 3D Rhino model as a database, 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 through 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.

19 Comments on “BIM ecosystem

  1. I like the write up but I noticed at least a few mistakes and inaccuracies. I would point them out if you are willing to make corrections. Cheers!

  2. very funny: revit limitations are being listed, but not a word is being spoken about the conceptual designing in a tool where it does work: nemetschek’s vectorworks.
    it has an integrated massing model functionality (with sketchup’s push-pull as solid, not surface modelling), with the automatic generation of the floor plans, the parametric designing with the integrated marionette module (which is grasshopper pure), and the 3d modelling, additionally to the own parasolid functionality, via the subdivision module, resembling rhino and inventor.
    add to it the integrated space programming ability (resembling this time trelligence affinity), and you have a perfect macro bim application.
    add to it the perfect ifc integration, and you don’t have to mention revit at all.

    • I think you have missed the point of the post. I have no doubt that Vectorworks is a good program. I’m sure ArchiCAD is also good. I wouldn’t know because I’ve only used Revit. But the point is, regardless of which design authoring program you use, it can’t do everything. And why would you want it to do everything half baked, when there are so many specialist programs out there.

      The dominance of proprietary tools and a lack of true interoperability is a hot topic at the moment. Last week Autodesk and Trimble announced an agreement to improve interoperability but there are questions whether this is just for show or if real change will come about. For too long we have been arguing about which is the better program X or Y. It doesn’t really matter as long as its connected, hence the ecosystem. The conceptual massing example above was just one example highlighting why interoperability is important – at least for Revit. I’m sure all software, including Vectorworks, has its weaknesses.

      You may want to have a read of some of these other posts too:

      • my concern is the real interoperability, i.e. using open formats, and not the heavyweight native file type.

        there is one thing that is being missed in the post – it’s the notion of the workflow between the professionals working on a project. they exchange the geometry data as a reference of their contribution, then they work out the improvements based on the feedback brought in another open format. there is no round-tripping of geometry data.

        autodesk, instead of focusing on the open formats, still try to use the native ones, as the recent deal with trimble indicates. there is no secret that the relationship autodesk-ifc is not an ideal one, and it doesn’t change. they simply still try to bridge the path to any part of the design-construction (= ipd) processes with further native cooperations. if we want to follow the mcphee’s ‘different bims for each process step’ then we have to mention solutions that work in an open bim type for certain stages, if we want to study cases.

        purchasing a constellation of tools for initial macro bim doesn’t make sense, when there is one solution that works fine, and you don’t mention it. surely vectorworks has its flaws, too, but just for macro bim there is no better strategy. the question is, if the resulting ifc made of solid operations may be imported to revit at all.

  3. I agree that Autodesk hasn’t been doing enough for IFC integration. But what exactly are you arguing – that Vectorworks is the best and we should all use it? So Vectorworks can process large point clouds, offer cloud collaboration platforms, direct to fabrication capabilities, VR capabilities and clash detection? I can publish a book using just Photoshop but that doesn’t mean that is the best approach.

  4. ok,
    1. you’ve addressed macro bim (conceptual design and its evaluation). autodesk don’t fit here with their revit and assorted other tools (in spite of your suggestions), and vw is the best solution for this. just this, and nothing more.

    2. surely vw can handle large point clouds, and project sharing, but i haven’t mentioned this part of the process at all. my point is that, while speaking of case studies, and advocating open solutions, one should fairly mention things that work the best.

    3. revit, and all other bim authoring tools and incapable of the full design to fabrication process, so there is no point in mentioning this, too.

    • This is a revit based post. I state at the begining that “this post explores how to extend Revit’s modelling capabilities by combining it with McNeel’s Rhinoceros and Dynamo.” Claiming that Vectorworks is the best solution is your opinion only. At no point do I claim that Autodesk or Revit is the best. It fact, I’ve already commented that Autodesk needs to massively improve and I’ve previously posted about this issue in the past (

      It’s a futile argument and only serves to further fragment the BIM community. I am simply offering solutions to extend Revit’s capabilities and improve the situation. If you want to push Vectorworks than maybe this isn’t the forum for you. And by the way, Rhino and Grasshopper both work with digital fabrication, integrating with Kuka & HAL robots so if I can connect Revit to Rhino, than I can fabricate my BIM model.

      • you’re right, delving deeper into autodesk is not my thing, i don’t use any of those products, so it’s really not my forum. i’m an architect, and no rhino fabrication is useful for me, i need real cam products, and working with open formats.
        anyway, thanks for your time and attention, keep up your work and good bye.

        • the most pointless argument ive seen in a while. Haha. interesting post by the way

  5. and, btw, is revit cloud collaborating with other vendor products as well? or only with autodesk ones?

  6. Hi came across your blog and was wondering if I could have permission to use your BIM Ecosystem image in a dynamo presentation I’m doing at AU this year. Of course I will put a link to your blog post as credit. Let me know!

    • Hi Josh. Yep sure, go for it. Thanks for asking. I’ll be at AU. Maybe we can catch up for a beer. If I can get in on the waitlist I’ll come along to your class.

  7. Great post Paul, I totally agree with you, we shouldn’t limit ourselves to a single software, but rather use the best suitable solutions for the job. And then optimise the workflows between each of them.

    You mention the .sat workflow from Rhino to Revit, and the usual struggle getting Rhino perfectly into Revit. On the current project I’m working on, we use a lot of imported geometry from Rhino. And after many different approaches, both with .sat, dynamo etc. we found that AutoCAD 2016 is actually doing the best job as a translation tool. Since you can open native Rhino files directly in AutoCAD 2016, clean them up, relayer things a bit if needed, and export them out as .dwg’s that in most cases will go smoothly into Revit.

    Also if you set all your Rhino layers to be “by layer” in AutoCAD, you will be able to see and control the materials in Revit easily from the manage object styles tab. Very useful when using live rendering tools like Enscape etc.

    Thought it was worth to mention,

    I know the post is half a year old, but I just came across it today. And as I said, great read. Thanks.

    • Thanks for the tips Jens. I’ll check it out. Is there any benefit in going through AutoCAD at all, as opposed to just exporting out a *dwg direct from Rhino?

      • Hi Paul,

        Yes there is usually a big difference between a dwg that’s been exported directly from Rhino, and a dwg produced by AutoCAD, by opening the native .3dm directly in AutoCAD 2016 and then saving it out as a dwg. from there. As I mentioned in my earlier post, remember to clean, set things to be “by layer” and purge before you bring the .dwg into Revit.

        Geometry that usually breaks when you import the direct Rhino .dwg, will in most cases come in perfectly using AutoCAD as the middle man.

        But now that 2017 opens Rhino directly this workflow might not be as useful anymore, but I haven’t had much time to test this yet, as my current project is still running 2016.

  8. Hi Paul,

    Great article! Just want to ask if I could translate your article into Vietnamese and post it on my blog.

    Thank you in advance.



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.