Creating a powerful, efficient and flexible Rhino to Revit workflow is the holy grail of computational design research for our time. The aim of this project is to explore how python programming could be used to improve work flow between Rhino and Revit in order to utilise the design customisation capability of Rhino and the documentation production capability of Revit to their full potential.

Rhino remains the best tool on the market for the design phase, due to the vastly more expansive variety of tools for 3D modelling and 2D drafting, as well as a thoroughly documented API for enhancing design with visual programming tools such as Grasshopper or more advanced Python scripting. Despite this it is underutilised by most companies in the architecture profession, who still use inferior software such as Sketchup, or go straight to BIM and limit the project’s creative potential. Many companies only use Rhino for visualisation modelling, and still use outdated CAD software like AutoCAD for documentation, even in the BIM age. Even for 2D CAD drafting Rhino is superior, but the true capability lies in the 3D geometry and logical data structures that can be produced which are just not possible in other software. What Rhino lacks is the 2D/3D simultaneous workflow that is available in BIM packages such as Revit and ArchiCAD, as well as the fully parametric functionality. While third party proprietary attempts such as VisualARQ have been made, they are still not as good as real BIM.

Revit remains the market leader in BIM, and is more widely used than its competitors by not only architects, but engineers, MEP specialists and other construction industry professionals. But for designing, Revit is cumbersome, clunky and inflexible, where every object is so parametrically tied together that unless you want to stick to standard orthogonal architecture, you need to do some programming to produce anything geometrically complex. While Revit has attempted to replicate Grasshopper with Dynamo, it lacks the functionality and flexibility because the way Revit constructs geometry is inevitably more complicated for BIM reasons. The Revit API is less well documented for Python than Rhino. Where detailed explanations of the functions and their underlying RhinoCommon functions are documented within the application, to hack the Revit API takes much more digging via RevitLookup or trawling internet forums.

Until a few years ago, the only option to get Rhino Geometry into Revit was importing a .Sat file then manually tracing it. This is very time consuming, and data may be lost in the process. Inevitably, firms that fail to employ computational designers and offer a supportive environments for research that does not have an immediate benefit to a particular project will fall behind their competitors. Various attempts have been made to bring Rhino and Revit together. They all have different methods for doing this, cost structures, file formats, capabilities, open source vs proprietary etc. Currently on the market we have Geometry Gym, Flux, Mantis Shrimp, Hummingbird, VisualARQ, Elefront, Lyrebird, Grevit, Rhynamo and probably more.