Exploring Interoperability between Rhino and Revit through Rhino.inside

1. Introduction

^{Figure 1: Physical Representation vs Level of Development(LOD) of a Revit Model in various phase and where Rhino/Grasshopper/Rhino.Inside ties into each phase}

The field of architecture has seen an influx of tools that aid in designing at every stage of a building's development. The Level of Development (LOD) is designed to specify the detail and accuracy needed in a Building Information Model (BIM) at different project phases. (BIMForum ,2023) However, data need to be effectively managed and synchronized between models, and sometimes software limitations prevent complete data reflection. Due to tight construction timelines and complex geometries, architects often relinquish control of construction to contractors.(Kristof, 2013) Giving up on the understanding of construction and fabrication is one of the reasons that designs that were not developed in-depth easily get value-engineered out in the budgeting process.

To address this issue and bridge the gap between advanced design technology and the practicalities of construction sites, this paper presents two case studies. These studies demonstrate how Rhino.inside interoperability facilitates collaboration between Rhino and Revit, ensuring a consistent data flow that remains viable throughout the construction documentation process and can be expanded into a workflow that contains and store data in Grasshopper as a database that gets read from and store back data from LOD 100 to LOD 400 bridging every level of design, and to maintain the design information throughout.

2. Interoperability Software Competition

^{Figure 2: Diagramic Representation on the workflow of interoperability between Rhino and Revit , left is before Rhino.inside of Grasshopper comes into play, and Right is the ideal situation with Rhino.inside Grasshopper as the platform that coordinates between Rhino and Revit}

Over the years, numerous companies and software solutions have been developed to address the challenge of interoperability in architectural and design workflows. Examples include Geometry Gym and cloud-based platforms like Flux and Speckle. These tools target specific issues within the interoperability domain, yet often necessitate the use of additional software, such as AutoCAD or Dynamo, to manage other aspects of the design process.

The complex nature of switching between software tools like Rhino and Revit significantly increases the learning curve for users. This complexity can lead to friction between project architects and designers, who are responsible for managing different segments of the information flow. Moreover, as projects advance into the Design Development (DD) or Construction Documentation (CD) phases, it becomes impractical to rely solely on Rhino for modifications or updates to the façade model.

Ideally, a seamless and bi-directional information flow between platforms like Rhino and Revit would eliminate the need for multiple software tools or formats that only fulfil limited functions. Such an integrated approach would streamline workflows, enhance collaboration, and reduce potential conflicts arising from information transfer between different software environments. (Fig 2)

3. Dual Case Study – Method Overview

The two case studies presented involve distinct geometric approaches tailored to different types of projects. The NBBJ East Coast office, primarily focused on healthcare and science projects in the US, favours the first method. Meanwhile, the NBBJ West Coast office, with a more diverse range of projects including international headquarters and office buildings, tends to prefer the second method.

It's important to note that these methods are still evolving, and neither is considered superior to the other. The choice between them depends on various factors that need to be taken into account.

4. First Case Study – A healthcare project

^{Fig 3: An aerial view of the facade of an anonymous healthcare project from the East Coast office of NBBJ}

^{Fig 4: A close-up view of the facade of an anonymous healthcare project from the East Coast office of NBBJ}

Background

The first case study, adapted from an unnamed healthcare project by the NBBJ East Coast office (Fig 3,4), involves a 15-floor structure with two step-backs in the tower and penthouse sections. The building's façade features alternating solid and glass segments. The solid parts include elements constructed with spines. To recreate these in Revit, one approach is the labour-intensive optimization of the geometry to create Revit families. Alternatively, considering these complex elements are unlikely to be used directly from Revit for fabrication, one could bypass this by using imported geometries.

^{Figure 5: Diagramic Representation of the first case study interoperability workflow between Rhino and Revit}

Workflow Overview

The first workflow involves having most of the heavy geometry, scaling, and duplicating all through Rhino Blocks, which are later converted into Revit Family (Fig 5)

^{Figure 6: Simple blocks in Rhino, and simple surface representation in Rhino, which also contain the metadata of the panels.}

In Rhino

a) Setting Up Massing: Basic massing is established using simple curves from the concept design, which are then rationalized into rounded dimensions for easier construction.

b) Creating Blocks: Typical dimensions of the façade are developed into blocks for detailed documentation. Materials are organized in layers to facilitate future access. (Fig 6)

In Grasshopper (GH)

a) Division of Panels: Basic surfaces are created using Grasshopper to divide and align panels relative to structural grids. These surfaces are assigned data such as unit code, area, height, and width. Additional information, like mullion length and window-to-wall ratio, can be extracted and stored in Rhino as a copy, archived from Grasshopper.

b) Skew Panels + Naming Individual Panels per Scale Variation: Pre-built blocks are duplicated, scaled, and skewed to fit their assigned surfaces, creating non-uniformly scaled blocks in Rhino. However, since Revit cannot use scaled families and these blocks are not parametrically controlled in Revit, they must be exploded and re-blocked under a new name for reconstruction in Revit.

Import Into Revit: The blocks are imported into Revit via Rhino.inside, which accesses Revit’s API to create generic model families containing the geometries from distinct scaled blocks. Materials and other data are incorporated to ensure no loss of information in Revit.

Pros and Cons

The workflow under discussion has its own set of pros and cons. On the advantageous side, it proves to be efficient and straightforward, particularly for façades that require scalable changes. This method facilitates the easy swapping of blocks, which is especially beneficial for quick visualization during phases of design modification.

However, there are several limitations to this approach. While it allows for considerable control in Rhino, the adjustments that can be made in Revit are somewhat restricted. This is because families are created through Rhino.inside do not possess parametric controls. Consequently, any updates required during the Design Development (DD) or Construction Documents (CD) phases are heavily reliant on individuals who are proficient in both Rhino and Revit. This dependency can create potential bottlenecks in the workflow. Additionally, the method of scaling and re-blocking elements like mullions can result in a loss of accurate dimensional relationships. This issue can lead to inaccuracies and challenges in executing precise adjustments within the Revit environment.

5. Second Case Study – P2

^{_{Figure 7 (Left): An aerial view of the facade from Revit of an office tower project from the LA office}}

_{Figure 8 (Right): A close-up view of the facade from Revit of an office tower project from the LA office}

Background

The P2 Main Towers, Fig 7 & 8 are a standout feature in the master plan for a tech company's headquarters in Shenzhen, comprising a striking ensemble of three 150-meter-tall towers. These towers emerge from a shared base and, after rising for 18 floors, merge to form a gateway above the Common – a 2.5km park that weaves through the masterplan. Additionally, the complex includes a public viewing deck that offers a spectacular view of the bay from 2.5 kilometres away. The design of the towers' curtain wall is particularly notable, transitioning from a flat surface to a sawtooth pattern with a depth of one meter, encompassing a total of nine distinct profiles.

^{Figure 9 : Diagramic Representation of the second case study interoperability workflow between Rhino and Revit}

Workflow :

The second workflow (Fig 9) involves having most of the heavy geometry, adjustments all in Revit, through the parametric curtainwall family, data that Rhino and Grasshopper hold are just simple parameters, height, width, level, module and angle of mullions.

^{Figure 10: Creating a complex revit curtainwall family that works with instant parameters.}

Typical Revit Curtainwall Family

To effectively implement this workflow, the key step is to create a Revit family that allows for parametric control as show in Fig 10. This requires advanced planning for parameters such as panel type, panel heights, and mullion angles, which will be determined using data input from Grasshopper. Other parameters, including glass depth and material choices, can be directly managed within the family itself. This approach ensures that essential design elements are accurately represented and can be adjusted as needed within the Revit environment.

Process

Once the parametrically controlled family is established, the next step is to return to Rhino to set up the basic geometry. Initially, basic surfaces, contoured from the geometry control, are labelled with identifiers like tower ID, face ID, and level ID. These labels are added to the Rhino attributes of the surfaces, laying the groundwork for structuring data within Grasshopper. Additional data, such as module depth and level height, can be imported from an Excel chart or derived from the Revit model.

^{Figure 11: Rhino Attributes labelled on a lightweight surface model in Rhino.}

Throughout the design process, the Rhino model is maintained as lightweight as possible. Figure 11 illustrates the minimal geometry created for rendering purposes. This approach is used to confirm the design and check data management without fully detailing every aspect, such as mullions or operable window specifics, for each unit. This strategy helps in keeping the model manageable and efficient, focusing on essential elements and avoiding unnecessary complexities.

The control geometries for the Revit model consist of specific elements and a systematic approach to data organization. These include curves that define the positions of the curtain walls and additional curves for assigning gridlines to the curtain walls. All other control data are structured according to a data tree matrix.

^{Figure 12: A composite image showing the step-by-step process of building the Revit curtainwall model based off from just curve and rhino attributes.}

The process of inputting data is sequential (Fig 12), with each step depending on the geometry created in the preceding step. For instance, the curtain wall gridlines need an existing curtain wall geometry to act as a host. Similarly, the curtain panels require the curtain wall to be segmented by these gridlines for accurate placement and assignment. This step-by-step method ensures that each component is correctly aligned and integrated within the overall structure, maintaining the integrity and coherence of the design.

Final Product

^{Figure 13: Assigning Rhino Attributes into Parametrically controlled Revit Curtainwall Families}

Once all the geometries are constructed in Revit, each of the panels, being native Revit elements, can be modified as needed for documentation purposes. This flexibility allows for various changes to be made, such as swapping panel types to accommodate mechanical louvres or replacing them with full-size panels. (Fig 13) The use of native Revit elements ensures that all modifications are seamlessly integrated into the model, providing a high level of adaptability and precision in the design and documentation process.

Geometry Loop Back to Rhino

^{Figure 14: Using Rhino.inside to extract and sort geometries out from the complex curtainwall family, to be use inside Rhino}

Prior to the introduction of Rhino.inside, the methods for interoperability from Revit to Rhino were largely confined to importing CAD solids as blocks, offering limited scope for editing and control. Rhino.inside has revolutionized this process by enabling the breakdown of geometries within complex curtainwall families into individual components(Fig 14), such as specific materials or elements based on a user-defined order. These components can then be organized into distinct layers in Rhino, facilitating enhanced rendering and coordination. This advancement significantly improves the workflow between Revit and Rhino, allowing for more detailed and precise design manipulations and visualizations.

Pros and Cons

The integration of Rhino.inside with Revit presents a blend of advantages and challenges. On the positive side, this workflow simplifies the adjustment of parameters in typical curtainwall families, enhancing efficiency and flexibility in the design process. After the initial setup in Revit, the model becomes highly adaptable, allowing for easy modifications and updates. Additionally, working with a lighter Rhino model streamlines the design process, making it more manageable and faster to work with.

However, there are also some drawbacks to consider. This approach is most suitable for projects that have progressed to the Design Development (DD) or Construction Documents (CD) stages, where major design elements are already finalized. The process of setting up a parametric family in Revit can be complex and time-consuming, requiring a detailed understanding of Revit's capabilities. Moreover, successfully implementing this workflow demands a comprehensive knowledge of Revit, as managing the intricate details of the software's features and functions is crucial for achieving the desired outcomes.

6. Conclusions and Future Opportunities

^{Figure 12 (Left): Photo of 2TP tower, showing the taper conical corner - Photo courtesy of NBBJ (Vincent, 2020)}

^{Figure 13 (Right): design to fab documentation for VMU, showing the taper conical corner (Vincent, 2020)}

The two case study projects demonstrate two workflows through Grasshopper and Rhino bridging one of the gaps architects and designer faces when concept design transfers into the construction documentation phase.

Future exploration would be how Grasshopper would also be the database that runs throughout all phases from design to construction,(FIG 1) feeding data into other software like Tekla for structures and FEM design for structural analysis, bringing it back for data storage and possibly leads to a straight to fab workflow with suitable configured towards digital fabrication or robotic fabrication.

As a proof of concept, Fig 13 shows the author's previous work of fabrication documentation for a portion of the conical cornered tower, with cylindrical optimization for machine bending, straight out from a façade model from Rhino and Grasshopper.

By acquiring the necessary expertise to bridge the digital-reality divide, architects can reassert their influence over the construction process, a domain that’s relinquished to contractors and manufacturers.

The author wish to acknowledge and thank the team in NBBJ Los Angeles, Boston and Hong Kong studio, especially Sam Keville and Leo Li.

All images are provided courtesy of the author and NBBJ unless otherwise stated.

BIMForum (2023) 2023 Level of Development Specification Guide. http://bimforum.org/lod/. Accessed 20 January 2024

Ip, Vincent. “Managing Constraints- An Integrated Design to Construction Workflow”, Facade Tectonics 2020 World Congress,2020

Crolla, Kristof. “Building Simplexity – The expansion of digital design into “contractor space”, In W. Huang, Y. Liu, W. Xu (eds.), Digital Infiltration & Parametricism: Proceedings of the DADA2013 International Conference on Digital Architecture, 2013, Tsinghua University Publishing House, Beijing, 2013, pp. 30-40