BIM ecosystem

6 min read

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.

A software ecosystem

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

Different BIMs for different purposes

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 on 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? BIM is bigger than just a single piece of software, and we must therefore seriously consider interoperability in our workflows.

Revit’s conceptual modelling limitations

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

Cultural barriers

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 attuned 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 losing 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.

Rhino to Revit 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 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 the very least, less painful.

Interoperability via Dynamo

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. With the introduction of Dynamo, a whole new world of possibilities has emerged to facilitate interoperability. 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


The post presents the notion of a BIM ecosystem and encourages 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.


Leave a Reply

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

2022 year in review

2022 year in review

Parametric Monkey 2022 year in review and where we are headed to achieve our aim of helping AEC businesses do better things.


© 2023 Parametric Monkey
Parametric Monkey and the Parametric Monkey logo are trademarks of Parametric Monkey Pty Ltd.


Drop us a message and someone from our team will be in touch with you shortly.


Thank you for your interest. Someone from our team will be in touch soon.


To find out about upcoming public workshops or to organise a private workshop, please submit the following contact form and we’ll be in touch soon.