We strive to be a platform agnostic firm, making sure we take advantage of whatever tool seems to fit the job best. Even so, our two most common tools are Rhino, often with Grasshopper, and Revit. Typically this has taken the form of Rhino being utilized as a nimble design platform and Revit as a robust documentation platform, leading to the frequent need to take Rhino and/or Grasshopper geometry and translate it in Revit.
The decision on how to transition between platforms usually comes down to the question: “Do we need to transfer the data?” Sometimes it’s perfectly valid to import geometries without taking the time to translate the data behind them. Other times it’s important that we create native geometry and data so that we can utilize Revit’s scheduling or to allow further manipulations of the geometry after it’s inserted. For projects that do require native geometry we then have to decide on the most efficient way to go between software platforms. Sometimes someone just has to put in the hours to remodel the geometry and input the data, but we’re increasingly trying more sophisticated methods to go between the different platforms.
One of our first attempts to find a better way took place back in 2010 as we developed our first custom tool called Cricket to translate geometry from Grasshopper to Revit. While Cricket was never demonstrated on this blog, it was mentioned during Part 4 of our Med Mart discussion about facade coordination. Cricket allowed us to save out family, type, location, and orientation information to a file and then use that information to place families in a Revit project, not unlike more recent workflows we’ve discussed using other third party plugins.
We’ve used third party plugins with a fairly good success rate, but over the last year we’ve found ourselves in need of something that gave us more control over our translation between programs so we’ve come back to the idea started with Cricket. Making our own tool also allows us the freedom of not only customizing the workflow between GH and Revit, but also to add more platforms as they become necessary. This also allowed me to find a way to cut out the middle men of interoperability, namely TXT, CSV, and XLS files. They have a tendency to aggregate in a project folder and it can become difficult to know what the most current or best file to use is, and I prefer to have less places to look for the truth of a design.
Where we’ve wound up at this point is demonstrated in the following video. The idea is that we have logical data structures within Grasshopper that we can then use to populate other models using objects with comparable intelligence. So on the Grasshopper side we’re just sending out information in the form of a data tree of text strings that can then be interpreted on the other end by other software using their native API’s. The first program that we created a receiver for was Revit, allowing us to specify a family type and then identify the incoming lines of data as a point, an orientation, or a parameter and allow Revit to place objects based on this. We’ve continued our research with Catia (previously here and here) by producing a receiver for Catia V5. In it’s current implementation it will instantiate a user features based on incoming data and allow you to change parameter values in a part object, but we’re already starting to to implement features to take advantage of Catia V6 and to generate assemblies by placing parts rather than instantiating user features.
Aside from what’s shown above we’re starting to plan other options like flowing the data in the other direction (Revit to GH, Revit to Catia, Catia to GH?) and other platforms we may want to support. Download the plugins below and give them a shot.