SOME HAVE CLAIMED THAT BIM TOOLS HAVE STUNTED Architecture. Theses crafted in poignant terms with powerful examples illustrate one thing most architects have known all along: the human imagination greatly outstrips the capacity of 100 percent of all digital tools. (see: Architosh, “Viewpoint: How BIM is Crushing the Art of Architecture and How to Stop It,” 4 Nov 2013).
Despite this, and partly to address it, global elite marquee architecture firms have long adopted the most advanced 3D modeling technology, from Gehry’s Digital Project to the much more pervasive Rhino 3D with its attendant Grasshopper “algorithms-aided design” (AAD) environment. In fact, “computational design” (another generalized term for AAD) has evolved since the early aughts from being a designer’s new “BFF” for form-making to today’s pathway to 1:1 digitally-driven prototyping.
While this nearly two-decade evolution has happened, something else has transpired in AEC: BIM has become standard practice for large and mid-sized architecture firms around the world. And in that process, Autodesk has taken up a notable market leadership position, at least in the United States.
Thus the problem of how to get Rhino 3D models to have a longer, more fruitful, and continued existence through the BIM-centric stages of today’s typical AEC workflow.
“Part of the reason we started playing with this,” says Bob McNeel, “is there has always been this workflow process where a lot of conceptual work is done in Rhino, and then when the project mature enough detailing and documentation starts in the BIM product of choice.” McNeel makes the point that the geometry coming out of Rhino can often be too complex to be easily ingested by the BIM product.
Dan Belcher of McNeel says that for years now, Revit and Rhino users have had at least seven different ways to hack in Rhino and GH geometry into Revit, but hacking up solutions is painful. Rhino.Inside for Revit—which functions as an add-on to Revit, like any other add-on to Revit—links up Rhino and GH (short for Grasshopper) APIs (application programming interfaces) with Revit APIs.
“Now, in this present situation, you have a Rhino file open. You can set up a GH definition for a particular project or piece you are interested in, and you can push them as native objects directly into Revit,” says McNeel. “And once that is set up, you can go back and make changes in Rhino and rerun the definition.”
But Rhino.Inside is about a lot more than just round-tripping geometry.
Rhino.Inside is a family of open-source host application plugins that interact with Rhino. (Rhino.Inside Revit, Rhino.Inside Excel, etc.)
While McNeel has put the initial efforts into it based around the AEC industry needs of Rhino and Revit users, advanced users and third-parties are free to explore its potential uses. Thus far, folks are working with Rhino.Inside for AutoCAD, Rhino.Inside for Excel, Rhino.Inside for Unity, and other Rhino.Inside projects. Plus, Autodesk’s BIM rivals like Bricsys have already demonstrated Rhino.Inside technology in their BricsCAD BIM solution at its last annual conference, held in Sweden. (see: Architosh, “BRICSYS 2019—Lift Creativity, Reduce Complexity, Act as One,” 30 Oct 2019)
We are just adding componentry to GH that is aware of the Revit SDK that knows how to manipulate native Revit objects in the way Revit likes.
Part of what makes Rhino.Inside really exciting to many folks is the Grasshopper side of the story. Rhino.Inside is equally “Grasshopper.Inside”—inside of the host application you plan to integrate it with. In other words, the host application can gain a computational design (or AAD) canvas whereby Grasshopper components can be written to speak to the specific types of 3D objects or elements in the host application.
Well before Rhino.Inside, both Tekla and ARCHICAD had already developed deep Grasshopper integrations with their respective platforms,” adds McNeel. “Rhino.Inside will just make this easier for others to follow.”
In the case of McNeel’s work with Revit, “We are just adding componentry to GH that is aware of the Revit SDK that knows how to manipulate native Revit objects in the way Revit likes,” says McNeel, “directly through the SDK like if you had written something in Python or done something in Dynamo. The code for these Revit-aware Grasshopper components is open-source so that architects can use them as a starting point for more specific workflows.”
Towards a Diverse Ecosystem
The popularity of Rhino and Grasshopper means that there is a vast ecosystem of best-in-class plugin tools for both Rhino and GH, unrivaled by any other computational design platform. Food4Rhino is a critical source for accessing this ecosystem. There are over 365 tools for Grasshopper alone.
When a host application incorporates Rhino.Inside, they gain not just Grasshopper but the entire ecosystem of plugins for the Rhino + GH world. McNeel also adds that Rhino can read and write 40 different CAD industry file formats, and those capabilities also come over to the host application, significantly expanding its capabilities.
But the big news about this expansion via Rhino.Inside of other apps—particularly other AEC design applications—is those third-party developers have an exploding “addressable market” for these plugins and add-ons for Rhino and GH.
How does a BIM platform compete with other BIM platforms if other BIM platforms can bring inside not only Rhino 3D’s powerhouse modeling but the most popular AAD tool in Grasshopper and the entire ecosystem of plugins written for it?
I asked Bob McNeel this question. “I think just about every AEC tool has a connection to Rhino and/or GH, or, will soon, now that Rhino.Inside makes it so much easier,” he says, in speaking about the BIM world’s key players. But Revit isn’t the first BIM application to get Rhino and GH inside. The first company was GRAPHISOFT with ARCHICAD, one of Revit’s stronger market challengers. And they did it using different techniques.
GRAPHISOFT integrated Rhino and Grasshopper into ARCHICAD several versions and years ago, and the integration keeps getting more productive. McNeel says GRAPHISOFT’s pathway for this integration was to set up a communication pipeline, one that works in both directions. “So they basically have to expose individual functions that can talk to Rhino or talk to Grasshopper and then add an equivalent thing on the other side,” says McNeel.
Rhino.Inside—A Tech Dive
Rhino.Inside is an open-source technology that embeds Rhino + Grasshopper inside another application’s memory space. It runs only on 64-bit Windows machines (more on this limitation below). Belcher notes you can also load Rhino.Inside in C Python so that you can be calling into Rhino itself from Python. “It could be very interesting to the scientific programming community or anybody writing hardcore Python code where a geometry kernel is needed,” says Belcher.
Rhino.Inside links up the SDKs of host applications to the SDK for Rhino + Grasshopper. By doing that, you expose each set of SDKs to the user, and data naturally flows between Rhino, Grasshopper, and the host application in a bi-direction way, based on the way the host application ideally wants it. As noted earlier, in the case of Revit, you can bring in the Rhino ecosystem into Revit. “So now you can extend everything that Revit does, for example, on the host application, with everything that third-party applications do inside of Rhino,” says McNeel.
As powerful as this sounds for the host application, there is one big catch: it only runs on Windows.
Not everyone has that limitation. GRAPHISOFT does not. “They have the advantage that their solution is also cross-platform,” says McNeel. Belcher also says they have another advantage in the BIM market—”they have done a lot of the hard work of figuring out what are the useful components in GH to an ARCHICAD user.”
So now you can extend everything that Revit does, for example, on the host application, with everything that third-party applications do inside of Rhino.
For some host applications with large or exclusively Mac-based user bases, they will face two paths: either do what GRAPHISOFT did or take the open-source code base for Rhino.Inside and port it to work on Mac. Belcher and McNeel didn’t mention if anybody will do that, but they did say why they are limiting Rhino.Inside today for Windows.
“We have a limited amount of people who understand how architecturally things work on Mac,” says Bob McNeel. “It’s basically a different engineering problem, which means some different expertise on our side. And we don’t have that depth of expertise.”
But there are many CAD and BIM companies that do have that expertise—chief among them the two Nemetschek stalwart BIM providers GRAPHISOFT and Vectorworks. It’s not clear if Nemetschek companies will be the first to help take Rhino.Inside cross-platform, or if those companies will formulate more liberal optional paths, particularly since one of those companies (Vectorworks) already has its own AAD toolset. We don’t know that today—and another strong Mac software company may port it over instead—and we also don’t know when McNeel will invest in those resources to take Rhino.Inside to Mac itself. They have not ruled that out; they just don’t know when that might be.
What we are sure of today is the Rhino.Inside technology is exciting users across the BIM spectrum and beyond and looking at how to further democratize AAD workflows from the earliest stages to the end stages of the AEC delivery cycle.