AU Class
AU Class
class - AU

Integrating Inventor into the Revit BIM Environment

Share this class

Description

This session will present a workflow between Inventor and Revit software using Dynamo as an automation tool for production. Our firm has an extensive history of using Inventor for bridge infrastructure modeling and using programming to automate production. Structural concrete or steel, reinforcement, bolted connections, and construction details are represented in our parametric models. Our firm chose Inventor as a primary 3D production tool due to its short learning curve with new 3D modelers, approachability, and native parametric functionalities. However, to be within a building information modeling (BIM) environment for collaboration with partnering firms and clients, we pushed these Inventor models into Revit using a combination of location data from our analysis models and Dynamo inside Revit. With this workflow, we can automate the assembly of our Revit intelligent model, establish Inventor as a BIM support tool for modeling within the production team, and retain our firm's Inventor assets for future BIM projects.

Key Learnings

  • Learn about 3D BIM modeling production.
  • Learn about 3D model automation.
  • Explore intelligent model interoperability.
  • Discover workflows through visual programming.

Speaker

Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Transcript

      IVAN LIU: Hello, everyone. This is the Integrating Inventor into the Revit BIM Environment session. Session number is CES602214. My name is Ivan Liu. I'm a PE here in the Tallahassee COWI office. So just a slide for the safe harbor statement.

      OK. In this session, we're going to be talking about the COWI North America Southeast history with Inventor's parametric production. We're going to talk about utilizing Inventor models as a BIM support tool, which is a very key point here in this presentation. We're going to understand a workflow between Inventor, Dynamo, and Revit to create a federated project within Revit through interoperability. Through this, we're going to try to incorporate the analysis modeling inputs and also some programming languages that will automate this workflow. So overall, this will open opportunities for us to organize and distribute the model production work to build the federated project.

      So what we're going to learn in this session is 3D BIM modeling production, 3D modeling automation, BIM model interoperability, and then workflows through visual programming. And throughout this session, multiple videos are provided. A project example is developed for this particular session that will help people understand what each step is for this workflow.

      So once again, my name is Ivan Liu. I am a registered professional engineer here in the United States. I am a senior bridge engineer here in North America, specifically in the Tallahassee office in Florida. I have 10 years of bridge experience mostly in design and construction of bridges.

      I got my master's and bachelor's from Texas A&M University with a structural engineering focus. And over those 10 years, I've worked on a variety of complex bridge construction projects from segmental bridges to cable stayed bridges and some steel bridges here and there too. But in the beginning, I started using 3D modeling software and the corresponding tools in college for a student steel bridge competition.

      So most of my experiences are from the steel bridge competition. That kind of led to the motivation of use of Inventor for North America. But really in a sense, my motivation for this session and development of the workflow for this session is to be able to provide an inclusive workflow for our project team here at COWI for be able to use any type of modeling software to produce what we need to produce for the BIM environment.

      So first section of our session is to talk about introductions, mainly the history of our work here at COWI North America Southeast. So who are we, the COWI North America Southeast region specifically? We were formerly the Finley Engineering Group and were acquired by COWI North America back in June 2022. The Finley Engineering Group became the southeast region of COWI North America. So for us, we have two offices, one here in Tallahassee, Florida, where I am and then another in Czech Republic in Prague.

      For us, we're focused on bridge design and construction engineering for a variety of complex bridge structures. Mainly, our core strength is integrating innovative engineering workflows with a practical application for projects, the very key and strong point for us for our very experienced engineers here as well as our new engineers that come into our staff. Since 2016, we've performed project production using 3D models through Autodesk Inventor. And we combine that with programming languages such as Python and Grasshopper. So we'll show you the example of that.

      So what is our scope of work here in COWI North America? So for us, we do engineering work for low to high complex bridge projects ranging from steel to concrete bridges. And we perform both design and construction engineering on projects which include stage load analysis, geometry control, some construction sequencing, some detailing as well too. Included in our construction work is develop of integrated shop drawings from 3D models which are used for visualization, clash detection, and also the automation of drawing development for our projects. So what you see here is a variety of our past projects which we used our workflows for.

      So if we narrow it down specifically to our 3D modeling work, we build 3D models for almost everything we work on. Specifically, it's precast and cast-in-place segmental bridges, some concrete stay cable bridges, so tub girder bridges, concrete arches, and then temporary works for construction. So what does that lead to? We do our detailed design drawings from those 3D models, obviously do interface model checks with the 3D model environment. We produce our integrated shop drawings that have all of the 3D model details shown in the 2D format.

      And then to our client we give a 3D proof model, which is a direct export from our integrated shop drawing model. And clients use that however they need to visualize what they see on the drawing. And one of the newest things we've heard about from our clients is how much they love our bridge construction visualization models. It gives them a very easy to digest method to read what we're proposing in terms of bridge construction.

      So for us in this office or in this region, we have a 3D innovative culture. For us, it's not always 3D everywhere all the time. We are, of course, try to be as practical as possible for our 3D modeling. So our production team focuses on pushing practical 3D modeling for our project tasks and submittals, meaning that if you have a one hour task, you don't necessarily need to do a fully baked 3D model out of it. We can do our 2D work but use our 3D model to our best advantage for whatever the project needs.

      For our engineers here in the office, we always connect our engineering work with CAD production. We strongly imply that the engineering always connects to the CAD production. And so in our offices, our engineers perform both CAD and engineering work in their daily lives. So all of our team members are knowledgeable and capable of using modeling software and programming.

      We have a very strong training program here for Inventor. And we like to onboard our new engineers whenever they use it for a project with those training programs. And with the ease and the use of Inventor, it becomes very easy to pick up and to be able to make them a very efficient member of the project team.

      Each of our offices in this region have champions of the production workflow and as well as very knowledgeable in the software for any kind of training and technical Q&A. So there's at least one person in each of our offices that you can go to that has very difficult questions, very basic questions, but, in general, that person will know what you need to produce, what the final product will be, and how to get there. And a strong point for us and what we love to see is to be able to motivate our engineers to be innovative and efficient with their software capabilities. So we'll never downplay any potential innovations in terms of automation, or production, or efficiency. We always love to grow that within our staff.

      So for COWI, what are the expected requirements? What do we expect at minimum for our BIM models? So for our project team, usually the client requirements are a big one; what BIM platform we want to use with the other disciplines, because there are so many out there; model ownership, who owns what and who manages what.

      Data and change management is included in that. And a big one too is issues and quality control procedures. Everyone has a different way to do it. And so that's one of the things we need to determine for our project team. For our clients, standards such as ISO 19650 or something similar is a standard that people usually or clients usually use as a basis for what they want.

      Well, we see out there a lot of clients are learning the new BIM standard requirements. And it's always good to follow those kind of standards because that's what the client's expecting. Level of detail requirements are something very vague because there are so many different definitions, but you should be very adamant to define what that is for throughout your stages of your project.

      Software requirements, what they want to use and what you need to deliver your model in, which most likely is related to the BIM platform. And you know, IFC exports are also a new thing we're seeing too where the delivery can be an IFC model instead of a particular modeling file such as Revit.

      OK. Inventor history. What can we do with Inventor in COWI? So our first project in Inventor was the Veterans Memorial Bridge in Daytona Beach, Florida. This was an early 1900s style bridge that utilizes precast arches and a precast superstructure as well, too. So for this project, we wanted to test Inventor with some precast elements and to produce some precast element drawings out of that.

      And throughout that process, there were a lot of growing pains in terms of what we had to model. For example, modeling splices in a 3D precast element. There's one way to do it in your 2D drawings where you can break a line to show a splice. But in reality, when you draw it in, 3D they will all overlap. And so that's kind of a new thing we kind of discovered. Never really thought about when we got to the 3D modeling world.

      But for us, it was really successful. And we were able to produce the first set of 3D construction drawings and construction [INAUDIBLE] drawings that you see on the right there where we can produce those 3D views in a very easy fashion directly from the 3D model and be able to just annotate it as we need to to send to the client.

      Then afterwards, we started branching out to different bridge structures. And one of the next few ones was the Towatina Bridge in Edmonton, which was an [INAUDIBLE] bridge that was built using a cast-in-place form traveler in a balanced cantilever method. It also had a pedestrian bridge hanging off of the bottom of the superstructure as well, too, that was staged in a particular way for construction.

      So for this second project, we wanted to keep using Inventor to grow our staff and to grow our experience with our staff as this was a new program within our system. But with Inventor, after the modeling to produce these construction sequence visualizations, the save views and parametric properties of the model made it very easy to produce these models and produce multiple stage sequences.

      So this model here is the next level where we started doing more of the bread and butter projects we have, which are segmental bridges. So what is shown here is the Wakiva Parkway Bridge near Orlando, Florida. It's the signature bridge there. And for us, precast and cast-in-place segmental bridges have a very common style of modeling. And we decided to make most of our standard work in terms of modeling and in terms of programming for the segmental bridges because we had so many projects aligned to do it.

      So this model shown here is the example of our full construction manual model that will be eventually made into a series of drawings for the construction staging. But with these models here, as you can see in the video, we utilize our integrated shop drawing models that was used for the drawing production. And so we were able to recycle and we efficiently use the work we had previously done.

      So after multiple projects similar to this and similar to the projects we've showed previously, our library was growing. And so now we have more methods to model these types of bridges. We have more innovative means of creating things like this and shortening the front end time for development. And just the growth continues until this day.

      OK. So these two models here are some examples of our shop drawing models that include the rebar concrete outline, post tensioning, any embedment items, and so forth here. So all these models due to Inventor's native capabilities are all parametric. And we are able to create multiple variations of that particular segment by modifying those parameters.

      So on the top is a typical segment on the bridge, meaning that there are more than one of these type of bridges or type of segments on that bridge structure. And on the bottom is a pier table structure which typically for a project like this is unique to the project, meaning that we would consider this as a one-off and so we wouldn't need to put as much effort into making it very parametric and very sequenced to produce multiple versions of it. However, it doesn't stop us from making a very highly accurate model that has all the reinforcement in there to provide the visualization for it.

      As you can see, there are lots of parts and subassemblies within this main assembly here. And from the beginning, our idea originally was to use Inventor for segmental bridges to assemble pieces of that segmental bridge like this cast-in-place element, like a car engine. So your car engine, you have multiple bolts, nuts, gears, parts in it that come assembled together. And that's really not any different than a precast or cast-in-place concrete element.

      OK. So going away from concrete, we also do steel structures as well too in Inventor. This right here is a single span shallow steel arch bridge in California that we're working on. And it has a heavy counter for foundations as well at the ends. But with the capabilities of Inventor for steel, we were able to model the structure very efficiently and create all the details we need as well as incorporate some of our concrete element work for our foundations.

      And then of course, in Inventor, the drawing production for steel is a lot faster than you would in doing it in 2D line by line whereas all of your edges, and bolt lines, and things like that are automatically produced from the drawing model versus drawing it line by line in say a program like AutoCAD.

      All right. So outside of our bridge projects, we also have a large archive of temporary works models as well too and temporary works meaning any kind of temporary structure that's used to build a bridge. And so in the slide here, there are three examples shown, one which is a formwork support structure for a hammerhead pier cap.

      The bottom left is the launching nose for a large concrete girder system, superstructure. And then on the right there is a movable platform for that Towatina Bridge that slides along the wings of the superstructure and was used to erect the pedestrian bridge hanging off of the main superstructure and, of course, used for finishing the concrete superstructure as well, too.

      And so as a part of our CD work, we create temporary structures through Inventor to be able to help visualize what our designs are but also produce the drawings directly from it. And usually, our temporary works is unique to the project. And so there are some things that are very creative and a little bit hard to understand in a 2D view. But with 3D modeling, it becomes instantly understandable for someone that can't really read a 2D set of drawings there.

      So just a few more examples of some of our rebar concrete models that we make in Inventor. And so these three models here are from a long span by span bridge in Hawaii that had over 1,000 different segment types. And with Inventor, we were able to produce each one of those 1,000 types using the assembly model and using the programming work that we have incorporated into it.

      And so what does our programming in Inventor take? We produce all of our inputs into a master spreadsheet, which is the Excel file you see on the left there. Each row has a particular set of constraints or triggers for the 3D model. And we produce every single different type of segment based upon how many lines there are in the input.

      And the video on the right shows the process from start to finish from model generation with that master spreadsheet to running the logic script that changes the model, produces the particular files, produces the particular files for the drawing using our database of templates, modifies the views as required and annotations corresponding to it, and then, in the end, producing the main set of drawings that is a multiple sheet PDF that is delivered to the client. So with iLogic and with our master spreadsheet, that is the method and means to the madness that is that Inventor assembly model.

      So in our world now, 2D delivery drawing, 2D drawing delivery is still the king. And so in the end, all of our 3D models, even though they're very nice and very accurate, it still needs to be put into a 2D drawing. And so for us, Inventor was a very easy tool to be able to produce these drawings, making 2D cuts from a 3D model, getting all the linework in there, and just really creating the annotations corresponding to it. And with all the metadata that's in those Inventor assembly models, we're able to spit out the parameters into a really nice table format and be able to provide parameters in a format that could be used for a rebar bending schedule and things like that.

      And for us, you know, we all like our 3D model for visualization. And it's become a very strong tool for our design bids and our construction work. Everything is just easier to visualize in 3D. And in this project in particular, we created an assembly model of that existing bridge in Minneapolis and created multiple stages to show the deconstruction and reconstruction of the project.

      And for this bridge here, we created 400 plus drawings, all animated, to show each and every thing, each and every removal of concrete, each and every move of the equipment, the bridge structure, and also the replacement of all the bridge elements as well, too. And all of these stages and drawings were driven by an Excel spreadsheet similar to that master spreadsheet shown previously, which could be modified and tied to the contractor's [INAUDIBLE] schedule as well.

      So how are our clients using our models? We usually share our models up in Autodesk cloud storage. And so we send those links to the clients and they can open up in their computers, their phones, their tablets, whatever, even if they're on site. And since these cloud models are the models we use to produce the drawings, all the metadata is there. Anyone can click an object in that 3D model and can see the properties that we use that is also produced on the 2D drawing. And then, typically, since we're in the Autodesk environment, it's easy to import and export to other software such as Navisworks to coordinate with the other disciplines.

      All right. So let's start a project, talk about scope, the level of detail, and project organization. So let's say we start a new BIM project. What needs to be done? So we have a project example here, which is a three span precast segmental bridge project. It has a single cell box girder cross section. Its variable depth in terms of height along span. It has a constant vertical grade and a constant horizontal bridge curve. And it's a post-tensioned structure so it'll have some PT inside of it.

      So what is our scope of work for the 3D model? We need the top of deck coordinates along the bridge center line to be able to align the geometry. We need the concrete geometry of the superstructure. We need the PT profiles. We need the fabrication level details such as the rebars or any amendments in that concrete element. We need temporary towers, if any, for construction and any other construction details that may go along with it. So that's what we need in general for a 3D modeling BIM project there.

      All right. So level detail. So how far do we take this dream modeling for this project example? Level 100. Just modeling the superstructure and substructure with preliminary geometry. And level 200, looking at putting in all the superstructure variations, PT profiles, things like that. Level 300, nailing down the concrete PT geometry, modeling design reinforcement, miscellaneous details, removing any kind of hard clashes.

      At 400, high level details developed for the shop drawings so that you can build that for construction or 500 where we go into as-built modifications that are implemented after the precasting yard has completed, the casting and the erection is done. So for this project example, we'll go between level 300 and 400 here but there's no reason why we can't go to level 500 if the project continues forward with it.

      So in our workflow, how is the work distributed? So part one is setup. We need to produce the project coordinates, the bridge center line, and also the Excel databases for inputs that drive the Inventor models and also the assembly in Revit. So who really does? It's the project engineers who do that and usually the BIM coordinator or manager that kind of drives this work.

      In production stage, we look at actually producing the Inventor models and actually producing the Inventor models for the superstructure, and the substructure, and also the temporary works as well, too. So once again, the project engineers are responsible for this and as well as any CAD technicians that may be on the project as well.

      And the final stage in the workflow is to produce the Revit model that is for the BIM project or for the BIM export. So we create the Revit project. We create Dynamo scripts and run it to insert the Revit families in the Revit projects. And we create the IFC exports. So technical leads or BIM coordinators are usually the one who does this and takes the work from the production in the setup side of things.

      So going into production, so let's look at the overall production workflow. So in general, that's going to be explained in the next few slides and sections. We're going to talk about Grasshopper and Excel, which we're using Grasshopper to develop the bridge geometry and using Grasshopper as well to export Excel files or CSV files that contain the model coordinates and all the parametric values that Inventor will use.

      When you create the Inventor models that have all the geometry for the superstructure and substructure and the concrete construction details, you'll use the Export Excel files as the means to drive all the parameters. And in that stage as well too in Inventor, we'll show how to convert these Inventor models into Revit families or Autodesk Data Exchange files that will then be used by Dynamo to place them into Revit through our scripts and also to read the Excel coordinates from Grasshopper, too. And we'll cycle through that Dynamo script as many times as we need for any kind of modifications within Inventor or Grasshopper. So finally, in the end, you have your Revit model that contains the federated model of the 3D elements from Inventor and then which would be used to create the IFC file in the end.

      So what do we need as input for this workflow, specifically for Dynamo? And so inputs are first retrieved from your bid or design plans, whatever you have for your project. The data is stored in Excel, CSV, or text format to be read by Grasshopper. The data consists of the vertical and horizontal roadway geometry, the bridge equations for the overall geometry, such as the height, width, whatever it may be for the superstructure; our substructure pier heights; the bearing locations; any variable bridge elements; and then construction staging.

      So for our project example, we will gather the bridge center line curve. So we have a constant radius and a single vertical slope. We have the pier and bearing geometry. So we have two pier locations, and two abutment locations, and two bearings at each one. We have the segment joint locations. So we have an 11-segment cantilever, three closure pours, and two end spans. So we have that many joints along the superstructure there to define.

      And for our geometry variables for our specific project, we have a constant deck width. But we have a variable height and also a variable length of the precast element. And the overall PT geometry, so we need to know what type of PT deck is there in the top slab of those precast elements, the bottom, and anything really within side the box girder that's defined as future tenants there and then stage numbering of the elements too so that we can define the cantilever construction sequence.

      So on the right are just a few very simple examples of what we have in Excel, for example segmentation, the definition of the segment joints, and the PT geometry, the local x, and y, and z definition of that profile of the tenant. So Excel has these inputs. And on the left is the Grasshopper example that we use to read in the Excel file and develop that bridge geometry. And so for us here, for a project like a segmental bridge, which is our bread and butter, we have very well defined workflows to create these bridge curves that define points of interest and also generate the cross section in its variable state along the bridge curve.

      And so for us, that Grasshopper script is also used to make our analysis model, which is kind of the single-- which is going to become the single source of truth between our analysis and our production side. So the procured inputs for the 3D production are used also within the Grasshopper-made analysis bundle.

      And with Grasshopper and its components, we're able to generate all the bridge geometry, which is then exportable and then which gives us that connection between 3D production and analysis side. So once again, single source of truth. And so on the right is an image of that project example with all the segmentation, all the joints, all of the pure geometry in general in our analysis software, which is sophisticated in its example.

      So just a closer look at the project example in Grasshopper. So on the left there is the rendering of the Grasshopper components in Rhino. So you see the same thing that you saw in the sophisticated analysis model. And for us on the right is the groups of scripts or the groups of components that we use in Grasshopper to define each and every component on there.

      So there's a section of the overall Grasshopper script for bridge curves, the superstructure elements, the substructure, the bearings, and then geometry control. So there are multiple copies of it for however many elements you have. And the geometry control section of our analysis script is a very important thing to remember because that is what we're going to use to pull out the model coordinates that we're going to use later on in Dynamo and in Revit.

      So what do we need for Inventor? Specific numerical values and triggers are obtained from our analysis models and Grasshopper scripts. And when I say triggers, I mean things like, is there a concrete tendon blister inside of this particular location or segment, is there a tendon anchorage in that segment, and things like that. So this is a little bit further beyond what we had initially for the inputs because we're using it for more detailed production in 3D. So you have a little bit more information than what you had into the analysis. But in general, most of the inputs are tied to our analysis development.

      So repeating again items such as heights, slab thicknesses, lengths, those are things that Inventor needs to read. And then once again, trigger items, positions of unique structural elements, access holes are another thing too. And then once again, everything is in Excel format, read by Inventor through iLogic.

      And so an example of some of our spreadsheets that have this information is the segment variables on the top left, which has the height, width, thickness for the start and the end of the precast element, and also the length of the start of the sides of the precast element as well too. And especially on a curb structure, your precast element is going to be shorter on one side than the other to create that curvature.

      On the top right are examples of triggers. It's very simplified but, with Inventor, we have subassemblies that are triggered to be shown or not shown or suppressed and not suppressed based upon these x's and dashes on our input. And for the PT geometry here, there are a trigger at every joint to where you can say, OK, I have a post-tensioning duct that will appear here. And then where is it located in a local XYZ location? So that's what you see on the bottom right there as well, too. So all these inputs, there are multiple versions of it that drive the assembly models that are in Inventor.

      So after all the inputs are collected, we go and create the models. We use past projects, past project parts and example assembly models to use as a basis or even be able to completely reuse it. We definitely reuse all of our iLogic scripts to be able to produce all of our automated elements. And we sometimes use, of course, the layout of our 3D model to help guide newer team members as well to see how they should set up the hierarchy of parts, subassemblies, and assemblies.

      So what was created for this project example in Inventor? We created a model that contains the concrete, the rebar, and the geometry. We created a model for the substructure with just the concrete and geometry for now. And we have a temporary works model that has the steel plus the steel connections.

      So for our project example, this is what a superstructure precast segment model would look like. So we have our variable concrete that would be modeled in. We have our rebar parts, all the reinforcement that's in there. And it's a patterned state. We have our post-tensioning that is shown on there as well, too, that is piers and piers based upon that input. And if you can see on the top left there, there are embedments such as a scupper, a drainage scupper, that would be included and would be triggered if that segment contains it.

      For our substructure, we have our concrete elements shown here. And with substructure, at least for segmental bridges, they're usually one-offs, meaning that there's no two alike between projects. And so we don't put as much effort to model everything as needed and sometimes even we don't even need to create a full rebar model because the 2D drawings are sufficient enough to build off of. So for our temporary works models, we have this example here, which is a span beam that supports some of the precast elements during construction. And so we would model the steel and steel connections here and can implement that into our full model.

      So we've created a folder that has-- we would have a folder that has all the Inventor models. Now what do we do to get it from Inventor to a state that we can use it for Dynamo? So what we want to do is create a folder of Inventor exporter models that would be utilized by Dynamo and Revit.

      So these Inventor exporter models would contain the geometry and also the custom parameters inside of it that are specific to the exported parts. And in general, for this workflow, you want this to be as automated as possible for potential model revisions. And so I'm going to go through three different examples of how to create that Inventor-exported model database, the first one being what I call a native Autodesk export which is performed by Inventor through the BIM content environment. And it creates symbolic Revit family files.

      The second method is what I call the Revit family export. And this is usually created through a third party plugin that creates individual Revit family files, the last method being the Autodesk Data Exchange. And so you would upload your models from Inventor into the Data Exchange server. And that's, of course, stored in the Autodesk Construction Cloud.

      So the native Autodesk export method. So this is what it's already included in Inventor. And what it does, it creates a Revit family file, a .rfa, that combines all of the objects in your Inventor assembly into one family. But the problem is that this Revit family is symbolic, meaning that it's only there visually and it's not a true mass and you should really only use it for visual purposes. So it's very good if you want to do something quick and dirty and use it for general visualization of inventor models inside Revit. And so Autodesk Inventor has a very prescriptive procedure to do that.

      So the Revit family export method. That uses a third party plugin in Inventor. And in our case here, we used a plugin called BIMDeX. And what this does is it creates a Revit family file that combines the Inventor assemblies into either one family or multiple families, meaning that if you have multiple rebar elements inside of your concrete assembly, like we do in our project example, you can either combine all of that geometry into one Revit family or you can break it apart where you can have a single family for every piece of rebar in there and it would assemble it all together for you.

      But the geometry in the Revit family is a generic model type. That's very important. And it also uses a workplane-based attribute which is important for what we're going to do with the scripts in Dynamo. And of course, there's no point if the geometric details and metadata aren't included in the export. And so with every export we have, all the details are there and it can be used and retrieved within Revit.

      So an example is shown on the video on the right. What we do is we pack and go Tableau assemblies and then we store them all into a single folder location. And we usually do this use using iLogic. But if you don't have that many, you can do it manually.

      The video shows a part example just to speed things up. But what we do is you open up the plugin. You convert it into their format, which is .bxf, very specific to BIMDeX. And then we the corresponding plugin in Revit, which converts that .bxf file into a pure Revit family. And so we'll do this for every single Inventor model that is included in that model database.

      So the last method, the Autodesk exchange method, Data Exchange method, uses the Autodesk exchange workflow, which is hosted through the ACC, the Autodesk Construction Cloud. So from Inventor, you export that or upload that into ACC using the Inventor Exchange plugin. And the geometry in these families are generic types as well similar to the RFA method. And we bring them back in through the similar Revit Data Exchange plugin. So same thing as usual-- same thing as the RFA method. All the geometry and all the metadata are exported through as well, too.

      So it's a lot less steps and a little bit more seamless with the overall workflow. See in the video you show the exchange plugin opening and loading a exchange repository. We upload the model here so I'll skip a little bit ahead. And then we open up the corresponding exchange profile in Revit and then bring it back down into Revit so you see the same geometry there.

      So out of the three methods, which one do you choose? You choose the most efficient one for the project team's abilities and also the requirements. Be practical. The Revit family method works well but does have a lot of preprocessing with that plugin. But the files are locally based versus cloud-based that the Autodesk Data Exchange has. But the Autodesk Data Exchange is a bit more seamless but also requires more development for complex models for large quantities.

      So now we get to assembling our models from our database into Revit. So what do we do? So first thing we want to do, we know we're using DynamoDB to run the script and place these Inventor exporter models into Revit. So what inputs does it need? The first being the name of the family to be inserted into Revit. The second is the insertion point and the secondary point of the Revit family within the overall project coordinate system. And you can see those points shown in the figure on the right. We also need the angle or orientation of the family within the project coordinate system as well, too.

      And so for our project example, we have the insertion point, which is usually, if you're a bridge segmental person, is a bulkhead side. And the second point is the [INAUDIBLE] side. And the angle that we need as well too for our final geometry requirements is the superelevation, the rotation along the bridge axis. So these inputs are retrieved from the analysis Grasshopper script and to a CSV or Excel format that's read in by Dynamo.

      So here is an example of that Excel file, which contains your object ID, the family name, three columns for the x, y, z of the insertion point, x, y, z of the second point, and the rotation angle required there. So for us, we create a cluster of Grasshopper components that retrieve items from that geometry control section of the overall Grasshopper analysis script.

      So for our project example, we copied the main workflow of those clusters in Grasshopper for our various categories of elements we're going to put in, one being the superstructure or precast segments, the cast-in-place closure joints, the substructure, and the deck inputs. And the reason why we copy them differently for closure joints, substructure, and deck inputs is that, for those elements, either the family is the insertion point in the Inventor model for those families are defined differently or they're just some very peculiar things that you need to have from Grasshopper that you need for Dynamo that may be a little bit too much if you make a very general component. For example, the substructure is in a different axis and different offset. So we can incorporate some additional components from Grasshopper into our general cluster for geometry coordinate retrieval just to make it unique for the substructure endpoint.

      So now that you have your inputs, you have your Inventor exporter models, and you have your families for it, what do you do? Now if you went with the Revit family export method, then all the Revit families you have would need to be imported into your new Revit project. So you can either insert that with Dynamo or you can just simply select all and just use the load family and put it all into it there as once.

      And now you have your collection of families in there. And with the Data Exchange method, you can connect and sync Revit into the AEC project repository and pull that all down and create the families within Revit using Dynamo as well too using geometry there. So now in the end, we have our families inside of Revit that we can retrieve using Dynamo to be placed.

      OK. So now we're getting into the Dynamo script. So to break it down, we have five general steps. The first step is importing those Excel coordinates from the Grasshopper analysis model, that spreadsheet we saw before with the points. Second, we sort the inputs from Grasshopper for the insertion point, second point, and axis rotation angles. And sorting it allows us to utilize our nodes and our clusters inside of Dynamo.

      So inside of the nodes in Dynamo, what it does to place these Revit families is to create a coordinate system that is at the insertion point, or the base of it is at the insertion point. And then it's aligned between the vector of the insertion point to the second point. And then it's rotated along that vector based upon the axis of rotation from your inputs.

      After that, you have your coordinate system and plane to make your direct shape. And direct shape is required because that's what you need as an input for the work-based family. So when you insert the family in there, you need to insert it on a direct shape or on a work plane. And after that, the script goes through and cycles through all the rows of families we have to input or have to place and goes through and places each family using direct shape as input for location and orientation.

      So for just a full view of the script, as you can see, it's a very simple script for a very simple task of just grabbing a family and placing it in space. So we have five general sections of it and then steps three through five is converted into a custom node in Dynamo. So for us, we can just copy that custom node after we copy and organize things for step one and two.

      So for step one, this is where we read in our Excel file from Grasshopper and pull out all of the parameters with it. And in step two, this is where we read from the Excel file, split up all of the sets in there into their corresponding IDs, insertion point x, y, z's, second point x, y, z's, and the angles that the custom node will use for the placement.

      So this is kind of the configuration for the creation of the coordinate system. The node to create the coordinate system at the insertion point, we aligned to create a vector between the insertion and the second point to define the y-axis of that coordinate. And then we just do a simple coordinate system rotation with the angle parameter that is pulled from the inputs.

      Step four is to start creating the direct shape on the project coordinate system or the coordinate system at each insertion point. So what we create is a four-point system, a square, there. And it's aligned already once you define the definition of that square on that coordinate system.

      And then finally, step five is to use that direct shape, its alignment, and its four corners to be able to define where the placement point of it is, where the first orientation is along one axis, and then the second orientation on the other axis there. And the names of the inputs for that node to place the instance is from the inputs in Excel. And so one of the important things to note is that the name of your family must correspond to the inputs as the Dynamo will try to find the exact name of your family type in there. And so one of the key things to think about as well too is the subtype or the subname of that family as well, too.

      So this is an example of one family being placed in Revit. So the right is the custom node from steps three through five. And then we have on the left there just a very manual input of steps one and two. So what I've done here is place one segment, played around with the angle rotation there, played around with the second point to change the orientation of it, and then tried to translate the segment vertically in place there.

      So in general, once we have-- that's the breakdown of the script. And once we have the script, your procedures to use that script is the following. One, open script in manual mode. Confirm your families are loaded or today's changes are connected. Confirm your inputs are configured and the nodes that have the file path are to the right place. And then after that, you run your Dynamo script.

      Some things to note is that you want to avoid automatically running the DynamoDB script as there are things that can get lost and looped in an endless loop. And you would have issues constantly running something through that. And typically, what I do when I use a script is to freeze the Dynamo nodes to be able to confirm some of the inputs in Dynamo prior to actually placing the family instances in there.

      So this is a video to show the full run through of starting Grasshopper, creating your inputs here, creating those CSV files that have all of the points you need, the x, y, z's and the rotation angle for every single location or every single family that you want to place in Revit. So once you start a new Revit project, you want to load in all of the families that you have. So we'll kind of skip ahead a little bit here.

      So I've loaded both the superstructure and the substructure families. So now I have and confirm that all my families are inside of Revit. You can open your script in Dynamo now in the manual mode and then just confirm that all of your nodes and your clusters are there. You have every single one you need for your categories of items you're going to place.

      Run through and make sure that all of your file paths are where they need to be. And after that, once you double check things, you can hit Run. And then you will place your family instances inside Revit. So if we go back to the Revit model now, kind of Zoom out a bit because we're looking at zero, zero there, you can see that we have final bridge structure with everything placed in the right coordinate system.

      So let's say we want to make-- we've done a first run, put our model in, and now we want to make modifications to it. So what's the procedure? So before we rerun the script, we want to make sure that all of your Excel inputs are modified and you run through all of your Inventor models again and export the metro models to your Revit families using one of the three methods. After that, you have to replace, reload all of the Revit families into Revit before you rerun your Dynamo script there. So some things to note is that you should document your revisions within the input files to just track changes. And if you're not replacing them, you should purge all the unused Revit families within a project that are made from Inventor.

      So just a short example of us doing a revision on this pier structure. So I have the bridge there now. I want to add this temporary support from Inventor that I made. So I'm going to go through and export Inventor into a Revit family, which I have shown here. I have my Revit family now that has been loaded. And I'm going to just go into Grasshopper, make sure that I change my inputs that are from Excel. So I pier one there now, which is shown on Revit but I want to change it to the family full tower one, which is the family that contains the temporary towers.

      I'm going to rewrite the Excel file input. And then just to confirm it, I'm going to open it as well and see that the file has been updated with a new date. So I thought I'd go back to Dynamo, double check my file path, and then run a script. Once I do that, it will place it and then, voila, simple as that. So that's just a simple example for one location but, of course, if you have multiple modifications all on the bridge, then this will be a simple method to modify all of them at once.

      So now, we have our assembled Revit project. So what you see on the screen now is that project example that was made from Inventor, exported from Inventor into Revit families, and Dynamo was used to assemble this model in an automated fashion into the right project coordinate system inside Revit.

      So now what? How will we use that assembled model in the next phase? So like we saw, we have our Inventor-made Revit project. And it's now available for sharing into the federated model. So with this now, you can send this to project teams and they can assemble the other disciplines' items in there and have one Revit space for coordination. We would be able to put in the site profile underneath that bridge there to show the value that that project may be in. We can export our IFCs from the federated model which, of course, can be used for the deliverable for the client. We can integrate with other BIM software and we can also use issue tracking software such as ACC.

      And of course, this whole workflow leads us to the federated project which we like to have because it's a very high level of visualization and accessibility for the client and it will also maximize that client interaction. And for us from our experience we know that no client wants to deal with multiple or intricate software to just simply view a model. They want something that's highly accessible and that would lead them to be more engaged, and give more feedback, and also be more involved with the coordination. So tools like Autodesk Construction Cloud is a good and simple all-in-one project storage software and can give a lot of accessibility to the client.

      So to conclude, why did we do all this? So to summarize, for us, we're able to export bridge geometry and our center line profiles from Grasshopper and use it within the analysis side of our project. We can create new adventure models or recycle them from a project archive of our Inventor models. We're able to automate the conversion of Inventor models into usable models for Revit import. And we can now automate the assembly of Inventor-based Revit families into a Revit project through Dynamo.

      So what do we see in the future? 3D BIM models can be created using multiple platforms without loss of information. So I know we only focused on Inventor to Revit families and then place that family into Revit but with this overall workflow, imagine using something other than Inventor to build a Revit family or build a geometry in Revit and place it with Dynamo. So it allows us to stretch the view of what we can use in terms of software to build our 3D BIM model and be able to simply assemble it with a script in Revit. So that means that the production can be built around our project team's various technical skills and we don't need additional training. So if someone is able to use Inventor or not use Inventor, then we can allow them to use the non-Inventor software to be able to help build our BIM model.

      With programming and automation, the assemblies of large scale models can be very simplified. And it can be repeated and modified. And with time and development, the interoperability of software will advance and increase the dependency on this type of distribution of work. So it will just get better over time with what we can do between the Autodesk environment.

      So establishing Inventor as a bench support tool. So for COWI, these developed workflow abilities allow us to still use Inventor as our main 3D modeling tool. So we don't have to focus on just using Revit only. For us, we can make models up to LOD 500 and sometimes that's even beyond what Revit can do. And so it gives us the advantage there.

      We're able to recycle our large history of Inventor models for projects and be able to shorten that front end development of 3D modeling. And with a low learning curve in Inventor and well-established training processes we have, new staff members can quickly become a productive member of the project team. And that's how we established Inventor as a BIM support tool.

      Thank you for listening to my session and feel free to ask any questions.