Revit… What is it good for?

Recently, I gave a talk at the SF Dynamo User Group on how to translate Rhino geometry into native Revit geometry and essentially how to “bake” native Revit geometry out of Dynamo (link to the recording – will be up soon).

In this presentation, I got a bit harsh with Revit and really addressed its place in the design process, as well as looked at how Dynamo interacts with Revit. Some of the conceptual ideology behind it came from Brian Ringley’s AU talk on interoperability (worth the watch).

I think I can speak for everyone who has worked in a reasonably sized architecture firm in the last several years, when I say, we’ve all been there: the design starts as this graceful sketch, which then gets modeled in Rhino and then suddenly (as if we didn’t know we need to do this all along) we have to take the forms into Revit for documentation. And…. that’s where the pain begins.

Revit has had a history of not playing nicely with most other programs, despite the fact that it was never a very good modeling program in the first place — in fact it was never more than a documentation management platform (sorry Autodesk, but its true). This raises a problem on most projects because many projects are required to deliver documentation in Revit, yet the design is then limited by the modeling capabilities of this tool. Design interoperability dictates that the design be at the center of the process and not the tools. Unfortunately, however, Revit has been in the center of this process for far to long. It is high time it was put in it’s place and we start pushing our designs through Revit and that it document the geometry we feed it regardless of where it came from.

For such a long time this has been the holy grail of most computational designers, and with the rise of Dynamo and the Spring Nodes packages by Dimitar Venkov, there is finally some hope that we can actually achieve this goal.

 

This slideshow requires JavaScript.

 

Over the past 9 months, I have been working on a large international project (which must, unfortunately, remain anonymous) and have gone through the journey described above. We began with some very graceful sketches, which turned into some very “swoopy” Rhino geometry as we liked to call it. The client fell in love with the seamless nature of the design and gave us their stamp of approval to proceed with the design. However, it began to become a problem as the Rhino file size neared 2 GB and we reach the close of the SD phase when we needed to issue the first set of drawings for the project in Revit. We tried everything we could to import the Rhino geometry into Revit manually, but ended up faking it with many filled regions and detail lines.

As we moved into DD, we knew that we could not sustain this workflow for the rest of the project and had to face the harsh reality how to tackle modeling these geometries natively in Revit. We opted not to pursue the use of Dynamo from the beginning so that the entire design team could “edit” the more complex elements should they ever need to. So a team of us (myself included) embarked on the slow and painful process of painstakingly modeling the complex structural swept beams, the cross beams, soffit and so on. However, the more we modeled and remodeled, the more it became clear that no one but those of us on this team would every touch these complex forms and as we struggled to keep up with deadlines it become even more clear that we needed to find a solution to automate some of these processes. The straw the finally broke the camel’s back came when we need to make a swept beam that followed a surface, with the top and bottom faces parallel to that surface but the size being vertical (or plumb) in the global z.We were finally forced to use dynamo regardless of the project management’s wishes.

Once we got going in Dynamo though, the and got a taste for how fast we could create some of these complex forms nearly everything this team modeled began to be in Dynamo. The problem, however, (among many) was there was not a good way to “bake” the geometry generated from dynamo into Revit so that it was native Revit geometry — in fact it was not better than importing an SAT. So why not just create these forms in Rhino using Grasshopper and import them as an SAT? Adaptive components did allow us to place manually created Revit families, however, this too quickly reached its limits. That is when we ran across the Spring Nodes package.

This package by Dimitar Venkov access a little hidden gem in the Revit API available starting in 2015 call a Free Form Element. This is essentially what you get when you are in the mass family and us the “create form” tool or create a loft in a generic model family. It is fundamentally “what Revit wants” — and how I am going to make Revit do what I want it to do. Through some creative python scripting using the Revit API in dynamo, Dimitar turns dynamo geometry into native Revit geometry. And for the first time we can now use Dynamo to make native Revit geometry that is not different than what you would manually create in Revit (except a lot more complex and a lot more light weight without all those reference curves and voids).

It was about this time that I was asked by another project in the office how to import Rhino geometry into Revit quickly for a design concept proposal. I realized that this project was reinventing the wheel that my project had just taken 6 months to learn. Their had to be a better way to do this. So I spent a few evenings figuring out how to use Dynamo and Spring Nodes (I opted not to used other plugins like Mantis Shrimp so as to keep the deployment as easy as possible) to make a very easy-to-use tool that would allow members of our design teams who knew Rhino to import their geometry into Revit using the same method I was using to “bake” geometry into Revit.

The tool was turned then over to various projects and parts of my project for testing and we started to see some amazing results where sheets in Revit containing geometry generated from both Revit natively, Dynamo, Grasshopper passed through Dynamo and Rhino were all being documented equally without any additional effort. Team efficiency began to increase, and for the first time, the design began to truly sit at the center of our process and not the tools that we were using to express that design.

 

~ by jluebker on February 14, 2016.