Using Dynamo in conjunction with Revit seems like the only way to do modeling for Civil Infrastructure (CI). I personally think, and many agree, that modeling for Civil Infrastructure is always a balancing act of using the right software to the right extent, keeping in mind transferability of the created content at each stage of design development.
Over the last several years I have seen massive Dynamo scripts written, often replicating functionality of professional civil design applications. Many of us are visual creatures, and that’s why this kind of programming gained such popularity in recent years. In this article, I would like to share with you an approach which will try and ensure that you are using the right tool for the right job and establish the solid workflow for your everyday tasks.
Bringing the context (terrain, roads, earthworks, under- and above ground utilities) inside Dynamo is usually quite a laborious task, and often it's unnecessary. Most of the context can be clearly seen in civil design software. Sometimes even a DWG plan drawing is sufficient to understand what’s going on. Not to mention the whole concept of Information Modeling going gradually through Levels of Detail, first of which is always a flat plan information.
Speaking from my experience, feeding a Dynamo script with 3D strings exported from a civil design software causes lots of issues and warning messages in the process of script development. Even if in the end you manage to have a workable solution, chances are it’s not going to work in each and every situation with other inputs/other projects. That’s why I prefer keeping the model “live” within civil design software for as long as possible, and then exporting consistent outputs to feed the Dynamo graph with. The Dynamo graph should be as clear and understandable as possible and supplemented by smart and flexible Revit content.
We will have as an input an Excel spreadsheet of the following format:
Getting these outputs from Civil 3D shouldn’t be too complicated. There are numerous ways of doing it in Civil 3D. Here is just one suggestion:
1. Spread out Pile dynamic blocks (if needed for clash detection check, even with 3D geometry) using path array and then project them onto Top of Pile Design Surface.
2. EATTEXT Easting, Northing and Z value. Half of the spreadsheet done.
3. Projecting the same blocks onto Top of Wall surface and EATTEXTing will give the rest of information needed.
This Excel spreadsheet will drive the Revit content positioning through the Dynamo Script.
Mindmap of the process:
And a more visual representation:
Individual panel maximum height is driven by family type parameter Panel_Hts_MAX.
Railing application requirements are driven by family type parameter Railing_Hts_MIN.
Revit Family Creation
Intertrack Wall Column
This family was initially created as a single-level based one, with shared parameters driving top of the pile and top of cast-in I-beam levels. This allowed those parameters not only to be scheduled but also to have them in Revit tags. I thought it was an elegant solution which keeps a dynamic link between element positioning and schedules/tags. (The user just needs to place them with Offset=0 to Height Datum level.)
But then I understood that this family won’t work in every situation, simply because sometimes these levels might have negative (below Datum) levels. So, I decided to rebuild the family and make it two-level based. I thought I was genius at that moment, because now I can place a family setting both Base and Top Levels as Height Datum and then assign Top and Base Offset to whatever values I want. Yes, we can even have these values in Revit schedules.
But the negative side of this approach is that the only way the user can tag it is by faking these parameters with duplicate shared ones and then make Dynamo “magic” work to read actual offset values and write them to the fake ones. But I don’t think it’s a good idea, so I left it as it is.
Intertrack all assembly parameter linking structures.
Railing is a simple family modeled in different Levels of Detail.
Precast panel, also modeled in different Levels of Detail.
The next step is to nest the panel and railing into a Generic Model family and create an array of panels with the railing on top. All the available parameters of these nested families should be “mirrored” with the ones in this assembly family.
As always with arrays in Revit, a single panel family is placed in addition to array one so that the family doesn’t break in a single panel scenario.
The next step is to assign correspondent visibility parameters to single panel, array panel, and railing.
This panel assembly then is imported into a two points adaptive family. Here is the screencast showing how it’s done.
The resulting family adapts to setout points and has main design and manufacturing criteria assigned via Type Parameters. This allows design inputs to be easily changed even after the model is built (providing the plan setout stays the same). If the plan setout changes, then it’s always better to return to the civil design application and re-do the arrangement simply because there are too many things a designer needs to take into consideration, which none of the scripts can capture and interpret.
Dynamo Script Overview
Each input is marked with the input type and has a prefix in its name denoting in which part of the script it is used. A numeric naming convention is used for data processing and manipulation. An alphabetic convention is used for placing Revit families and setting their parameters based on calculations.
The main processing parts are:
01_Getting data from Excel;
02_Transforming World Coordinate System into Project one;
03_SetOut Points from XLS;
04.1_Extracting Control String information from the file name;
04.2_Pile Number from Excel to Mark family parameter;
04.3_Python Script_^_Post Rotation Calculation;
04.4_Panel Placement Determination;
04.5_Panel Height Calculation;
B_Posts Placement and rotation_3D;
A Dynamo script is built so that it should be able to guide the user through it by itself, and you don’t need to move your eyes away from the script.
Valentin’s bridge engineer career started in 2011. He has worked on major projects in Moscow, Russia, for more than 5 years using AutoCAD at its maximum. He started getting into all things Information Modeling for Civil Infrastructure in 2014 and has been using a combination of Civil 3D, Revit, and Dynamo since 2016. He moved to Sydney, Australia in 2017 in pursuit of career development. Valentin learned a lot from watching Autodesk University classes online and contacting presenters with additional questions.
What are the main benefits Dynamo can bring to civil infrastructure modeling? To what extent should visual scripting be used, and to which Revit elements' parametrics? This class will cover these areas and show the application of Dynamo to real civil infrastructure projects.