Advanced Inventor Modeling for Infraworks

DANNY LEWIS: Hi, everyone. This is going to be the "Advanced Inventor Modeling for InfraWorks." My name is Danny Lewis. I I'm the Hatch Global Lead for the Autodesk suite that we have in here. I'm also kind of known as the Inventor guru and all things related to Inventor and InfraWorks in the company.

So I'm going to start off, first, saying special thanks to the Autodesk team. Ara Ashekian at the InfraWorks. He's the Product Manager for that. And so he knows InfraWorks like the back of his hand. He's always willing and able to answer all the questions. And he's gotten me in touch with a lot of the developers to provide a lot of the know how that went into this presentation.

And then, Kris Landry, who's the Technical Solution Executive for Hatch. He introduced me to Ara, so he gets all the credit for that. And he's also good at finding the right people in Autodesk to ask these more difficult questions to. So before I begin, I've just got to pat myself on the back a bit. Last year, a colleague and I did a presentation for AU 2021.

And that was for the Tulu bridge. And that presentation was one of the top-rated engineering classes of that year. And so, of course, I'm going to be trying to go for another win. And hopefully everyone enjoys this presentation. So what are we going to be learning today?

Well, the topics we're going to cover are showing the path for models from Inventor to InfraWorks, showing how to create simple toggles in Inventor, showing the code for toggling lots of features at the same time using iLogic. And then, we'll discuss what blue parameters are versus the regular parameters in iLogic, discuss having this application versus this server in iLogic, demonstrate how to set up a log file in iLogic, discuss how to suppress things in iLogic, and demonstrate how to change part colors, how to change text, how to setup dropdown lists in iLogic, and as well as a bit of background coding.

I'm going to show off kind of by pattern coding thing that you can do with Inventor. And then, I'm going to do some showing off at the end to show some setup files from multi body to assembly. And this is something that we internally developed at Hatch. But I won't be providing the code for it. I'm just blatantly showing off.

So why so much iLogic? First off, because it's awesome. But iLogic kind of started I think almost by accident from how Inventor-- what I've heard. But essentially, it's a programming language to be able to access some of the things within the Inventor models. So you have VBA, which is great.

But iLogic was supposed to be this kind of simple version that people could easily use without having to know a lot of background coding. And to be honest, it kind of expanded from there. So with iLogic I can edit, manipulate any feature, part, or thing in Inventor with very simple coding. And then, once you connect toggles to those Inventor features, you can interact and manipulate them in InfraWorks.

And then, the options are almost limitless once you start tapping into the coding side of Inventor, because everything I do in Inventor with click, click, click, I can just easily do via program, and toggles, and iLogic. So in summary, it's incredibly versatile and powerful. And I would say, it's much better than Dynamo.

So road to InfraWorks-- and I specifically picked a blind person walking across the road for that, because it feels like that a lot of the time. So Inventor to Infraworks, it never actually leaves a Inventor. So InfraWorks is a very unique software to the Autodesk suite, because it's an editable hub. So everyone kind of knows that InfraWorks is this software that's housed in BIM 360, and it sits in the middle, and I can access it to ACC Docs, and ArcGIS, and all that fun stuff.

I can pull in Civil 3D files. And I can export back to Civil 3D using IMX. And that's great. And then, I can export files over into Revit. And I can pull Revit models in. And then, I can export it out to Navisworks. And I can export it to 3DS Max. And even by itself, it's a very pretty software with how it does the shadows and everything.

And a lot of the models on the bridge workflow, specifically, it actually creates Inventor models. And I can bring those into InfraWorks, as well. So just by itself, right here, I have it as a nexus of all these kind of major hero softwares from the Autodesk suite. So you can actually take InfraWorks and pump it back into Inventor.

And the reason you can do that is, InfraWorks is running Inventor Server in the background, which is essentially the same thing as Inventor, but without any of the user interface to it. So full functionality of Inventor without the user interface. It's kind of like turning off your monitor and playing with Inventor. So how do I get it from one to the other?

InfraWorks requires a certain number of things before it accepts the Inventor model. And this is just to help it validate what its got, what it should be, where it is in the correct modeling system to it. And it's not perfect, but it's way better than the system that they've got for putting Inventor models into Civil 3D, which is just a big dumpster fire.

What InfraWorks will look for-- the .ipt, .iam the Inventor files, effectively. Then it looks for an XML file, which describes what your files have in them. And that's it. So then, it's got to JPEGs which is just going to be pretty icon pictures that it has for how it displays them in InfraWorks.

And then, it's going to take those and then put them into a geometry file. So if it put it in an assembly, it'll take that assembly and rename it as a Geom file. And then, all the other parts that are in that assembly, it'll just bring them along and put them into that folder. Then, it'll create an AC item in the background, which we'll kind of cover later, and very similar to what a JSON file is. Essentially, this is the file format that's going to carry all the information of the Inventor file once it lands in InfraWorks.

And then, I can also export a JSON file, which is how I would pull that information in and out of InfraWorks. And as well, you can actually create the JSON file beforehand, which is something we do at Hatch. And then, you can just directly import the JSON file as opposed to exporting it and doing all that.

But regardless, JSON file just think it's all the parameter information sizes, information in the data. It's not necessary to be able to put that in there, but it's nice to have if you have it. So how do I bring Inventor parts into InfraWorks? This not the right presentation for that.

So that has been covered by countless other presentations-- how do I get from Inventor Pro to InfraWorks? And again, the last year's class covered that really, really well. So I really won't rehash it. Also, Autodesk is making things better. So anything I was going to discuss over here might be out of date.

And as you might have saw on the last slide, I'll put a little caveat to say, here's the data. This might actually be out of date by the time you're seeing this. So user beware.

So ways that it's probably better based on what I know, you don't need to have the add in in Inventor to publish it into InfraWorks anymore. InfraWorks now lets you refresh your models and remembers the specific instances of the parameters of how they landed into InfraWorks. And so that was kind of a new feature, way better now.

And then, again, because you don't need the add in, it auto generate the JPEG files with a nice kind of fancy background instead of the ugly stuff it had before. And then, there are lots of other things that were broken with the add in. Those are now hopefully fixed. And then, custom property mapping to InfraWorks-driven things.

I'm not sure if they're going to have something like that available. I'm remembering what I wrote there. That's to say if I don't have a parameter exactly named correctly in Inventor, when I brought it into InfraWorks, I now have the capability to say, I named it this, but it's supposed to equal this InfraWorks parameter.

But maybe, they've even fixed importing the textures for the girders, because it barely works or doesn't work, however you look at it. Their size, the system, their user interface for doing that is still kind of poor, we'll say. Dropdown menus don't work at all. You can try it. Group nesting for making it clear how you have things grouped together in InfraWorks, not great.

Parameter visibility toggles-- being able to turn parameters off if they're not relevant, not available. And so now, we can get to the fun stuff. Which, for me, is Inventor model. So in this little video, I'm kind of showing how do I do a simple toggle. So what I'm going to be quickly doing is just putting together a simple model.

It's just a block with a hole in it. And so this is a quick demo to explain this is how Inventor works. Because a lot of the people watching this video, they're very familiar with Revit, and how great Revit is, and how much they love Revit, and how Revit is-- I just wish there was more Revit.

So this is just kind of an intro to show that Inventor is a very easy-to-use software. And icons are bigger, just to make it easier to use it. So I've created a hole. And now, I'm making a parameter. It's a numeric parameter. I'm just going to call it Toggle, Toggle Test. And it disappeared, because I had a filter on that only showed the key parameters.

You'll note that I'm kind of toggling things on and off of key parameters. That's a nice to have. If I want to have it show up in InfraWorks, it has to be a key parameter, so I've gotten into the habit of doing it. Now that I've created a numeric parameter, I'm making it into a multi-value list. And then, I'm going to make it a unit-less parameter, so it's not 1 inch it's 1 and 0, without a unit behind it.

So I'll delete the 1 inch and add a 1 and a 0. And then, boom, I've got a toggle that's 0 and 1. They do have a True and False toggle, but there's some kind of limited functionalities with it. So it's actually better to just go with 0 and 1. And then, if I go and right click into the feature itself, I can hit Properties.

And then there's a baked-in thing that says, hey, suppress this if this parameter equals to a certain value. So if I make it to 0, then I've instantly got a toggle that will turn that feature on and off depending on the value of this. And then, of course, I change the color, because it is a little bit hard to see in the black.

So what if I want to make a little bit more complicated of a toggle? So in here, I'm going to put a double toggle onto this. So I want both toggles to have to be a certain value for it to actually activate. Lots of cases we're going to probably do that.

And again, I'm just showing how to make a multi-value list. Add 0 and 1, delete the 1 inch. Boom, there you go. Make it a key when you're done. And that's great. So now, using that existing properties thing wouldn't be sufficient in here. So I'm going to go to iLogic. I'm going to Create, Add Rule.

And I've just added a brand new iLogic rule. So here's what it looks like. I've got nothing in it. You can right click the hole and say Capture Current State. And I can see the dimensions of it. And I can see the feature that it's active. And all I'm going to do is put a little if/then statement on here where if this toggle and the other double toggle is equal to a certain value, then something's true.

Else, it's not true. And so very kind of simple coding language at the basics of it to be able to do this. And the reason I'm harping a lot of this iLogic stuff is, as it lands into InfraWorks, it will still have this capability to toggle it on and off. So if I put a toggle into the Adventure model, I will have that toggle available in the InfraWorks model.

So here, I've got if this is 0 and the other one is 0, then the feature is false. Else, it's true, because I realized, oops, I had both as false. And so that's why it wasn't working. And now, if I go back up to the parameters, I can turn one of them on and it's enough to turn them both on.

Or sorry, if one of them is equal to 1, the hole shows up. So that's kind of a complicated way to be able to access those parameters. So I can actually go into iLogic and add a form. So in that form, I see all the parameters that I have available. And again, if there are key parameters, they show up into this list.

And now, I just drag them into here. And I'm going to name the form the Super Duper Form. And now, I click that. And now, I've got a form. And I can toggle the parameters directly from this form with super, super ease to it. So simple toggles. And again, it just gets more complicated as you use more and more of them.

Within the toggles, you can also change a lot of things to it. So this is, again, a very simple form. And I kind of show how rather than listing them as a combo box, I can put them as a list box if I've got lots of things, or I can put them as a radio group, which is just a radio button.

I'm sure you'll recognize that when you see a radio button. I personally find it better to have two columns, because it's easier to see them. So then, I'm putting them both to be radio groups with two columns. Again, it'd be nice if you could copy/paste the style. But whatever. So now, I've got a simple, simple toggle.

And I can easily manipulate and test out my Inventor model and know that, hey, this is going to carry through into InfraWorks as a toggle. So here's a lot more complicated of a toggling thing. And again, you can see, I've got lots and lots and lots of features to it. And here, I take this sign.

And I can change whatever I want with it. So I've got a dropdown menu to that. It's got a list that it's looking to. Again, the logic is saying, hey, if this is a rectangle, then the rectangles are turned on. If this is white, then make this color white. And all of the times I'm changing these toggles, it's then triggering the code to run.

And it's going to activate it and then go on with it. So I kind of speed it up here, because it's just kind of rambling-y stuff. But it's just to show that you can put a pile of toggles and a pile of controls built into an Inventor model and then put all those kind of controls into an InfraWorks model, too.

So this one little model is super powerful all by itself. So what if I have lots and lots and lots of things to toggle? So the way Inventor actually works is, if I say I'm going to turn all of these steps that I've got here-- I'm going to turn them all off at the same time. It doesn't actually take it as a group.

So it won't run through the entire code, figure out what you wanted to do, and then just do it at the end. It will actually sequentially do it. And that can actually cause a bit of lag. So in this instance, it's the slow way of toggling them off. And it's going to-- you can see-- one by one by one go through each one of those features and suppress it.

So it's going to stop the code, go into it. So the faster way, which I'll kind of go into the code a little bit more later, is it just collects them all and turns them all off at the same time. So it's one triggering of it, as opposed to this one by one by one by one by one approach to it. And again, if it's slow in Inventor, it's going to be slow in InfraWorks.

It will look as if it's just done it all at once. But again, the way it works in the background of InfraWorks is, it'll trigger Inventor Server. Inventor Server will run. It will say when it's complete. And then, it'll send it back to InfraWorks. So you'll just see a slow model in infraworks. So you won't see that it's gone and done all this thinking in the background.

For anyone's interest, here is the code to do it the slow way, which is just to say x is equal to the number of steps. And I have a toggle up there in the code. And if it's equal to the toggle is true or false, then it runs through and turns them all off. So now, we'll get into the fun stuff, the code.

So this might look daunting, but it's not too much. The only part you really care about to do the mass selection is, I'm going to create a selection set. So I've got this object collection. And a lot of this code, you should be able to just copy/paste and use for your own purposes. But I've got the selection on and the selection off.

And then, I'm going to set up a bunch of cases where I turn them on or off. So that could be a nested if/then statement to kind of go through if this is that, then turn it on and off. Or we can use a select case scenario. And so as a bonus, this is the proper formatting, how to do a select case kind of thing.

And it's a very useful tool if you're just used to doing if/then statements. I just say, with this thing, if it's 0, do this. If it's 1, do this. It's 3, 4, and the cases can be whatever you want it to be. It can be text, it can be whatever. So then, once I've kind of gathered which features-- and if you notice in there, I'm adding it to the list to turn on or to turn off.

So I'm going to compile that list. And then, at the very end, I'm going to be running these two codes, which is just as with that list of things to turn off, suppress features all at the same time with the list. And with this list of things to turn on, unsuppress them. So those two lines are there, turn off the features, turn on and off on mass.

So now, we're going to get into the weeds. So blue parameters and regular parameters. So in iLogic, there are a couple of different ways to do a parameter call out. So I can call it out as the parameter parameter.param with the parameter name inside of it. So for example, step one. Or I can just put parameter step one.

To be honest, I don't really know what the difference is between one or the other. I kind of just use them interchangeably. But the benefit of these is that you can put a variable into it to call out the parameters. So as I have in the below there, I've got step with an ampersand to say x. And if we step 1, 2, 3, 4, 5, and then left-hand side.

So because I can put that variable in it, I can cycle through it pretty quickly. The other type is-- I'll just call it the blue parameter. But this is actually calling up the parameter name in your code. And when you do it this way, it triggers the second it changes, period. It'll always trigger your code if it's got that in there.

It's useful, though, because I can also create just a parameter called triggered by and list off a bunch of parameters that I want this code to be triggered by if those parameters change at all. And then, I've got a little bonus in here. This is a handy way to do the next line. And it cleans up a little bit of your code, rather than having one big run-on sentence parameters that you're going to do.

And another little bonus in here, because Inventor is a centimeters and radians core to it, if you want to be able to do the tan functions, and cos functions, and all that, you need to convert it to radians. And so here, I have an angle. And here's the quick, little way to convert it to radians. Is like equals math pi 1 over 80, and add n radians to everything, and then forget about it.

So this is a very important thing that I learned kind of late in the game. And I could not figure out why certain things weren't working. This is the why. So a common part of the coding is actually, tell the code what it's supposed to act on. It seems pretty obvious. So you've got this application, which is 99% of what you'll do for coding stuff.

And if you look it up on the iLogic forums. But remember, InfraWorks is running the server, not the actual application of it. So the code you need is this server. And luckily, it also works in regular Inventor. So you can just throw in this server willy nilly, and still run the code, and see if it works.

And it'll work in InfraWorks, as well, if you have that proper nomenclature on there. Another word you can use is This Document. And that works in both, obviously, still, too. It's essentially just saying, whatever's open in Inventor at this time, that's what I want this code to run on.

So the proper ways to declare them is a couple of examples down here. So if you declare it as the part document or as an assembly document as a document, if you see there, I've got all of them or This Document. But the reason I would do it specifically like that is because if you do proper declaring, then you get the helpful pop ups in the code.

So if I know that I'm going to be working on a part file, then I should list it as a part file or part document in the proper declaration so that the part document pop ups show up when I'm doing the coding to it. So the takeaway from this whole slide is, this server is a very important thing that you should be doing if you're doing any kind of import coding.

So cutting logs, this is another useful one, because InfraWorks will just break. And you won't really have a good indication of when or why. They have added a little bit of smarts into it, where you can now export your model back to Inventor as the exact parameters that it has. But sometimes, this is actually more helpful.

So iLogic is not restricted to just Inventor. And so the Inventor server can also create and manipulate things outside of Inventor-- and therefore, outside of InfraWorks. So the best way to do this is, here's this little snippet of code, where the first line writes/creates its own text file.

So here, I've got write system io file append text. And that's just a background Windows system logic to it. I give it a path. And then, it's going to create that file. This little try/catch thing that I've got there, it's going to try to write to an existing one. If not, it's going to create the text file.

That's all that the thing is there. And then, the bottom line is saying, hey, write this into that file. And then, in this example here, I've got that Base Rule.txt. And I can see, hey, it's been pounding out these things every time it's been triggered. So this is good, because you can put anything from your code into your very own log files.

So if I wanted to really understand, hey, how many times is this triggering? What kind of parameter values do they have? Normal things that you typically put into your logging statements as you're doing your code, you can build them into your own little log file, and have that exported as InfraWorks is running, and then just check it as you need.

So suppressing things in InfraWorks-- in Inventor, there is Enabled, Visible, Transparent, Suppressed for features, bodies, parts, and assemblies. And it can get confusing very quickly, obviously. So this is just meant to be the quick easy guide to say, hey, for parts, you want to suppress a feature, its Feature.isActive('(Feature Name)') true or false.

And again, caveat to say, this is the slow way to do it. The faster way is to gather all the features together, and suppress them, and unsuppress them in one mass. So this is what they look like when they're suppressed. There you go. Suppressing a body, if I've got a multi body, the simple answer is, don't bother with it, because the better way to do it is just bring it into an assembly, and then suppress the component once it's in assembly.

So component is active, component name, true or false. And again, this is where turning it visible and invisible doesn't really do anything when it gets to InfraWorks. And so here's what it looks like when the component is suppressed. And when I say component in this regard, it's part files, and assemblies, and subassemblies.

So here, I'm showing the part file being suppressed. It's the same thing if it's a sub assembly inside of an assembly, there. So changing colors-- big old pile of code to chew through. Top part is just the general declarations to say, it's this document, blah, blah, blah. Then, I'm going to set some asset colors.

So in this example, the parameter exactly matches paint blue. And so I named a paint color called blue. And then, I know to call it out that way. So the dropdown list matches the actual paint colors in there. So that's what the parameter name is going to be matching a paint color, there.

And then, this little part here is what changes the body color to the asset. So in this sense, I'm actually changing the body color, and not the feature color. But I think later on, I change the feature color, too. And then, this is some conditional statements of when to turn one thing one color or not.

Cycling through all the features, there's a little, handy code for that. And then, here's the code to change the part feature to the color asset. Same thing. Changing text-- so this one's a weird one. Here's the key part of codes of general declarations, again. Again, I'll note, everything is always centimeters when it's in the iLogic code.

So you do have to convert it if you want it to show up in the right format for yourself. And then, in this one, the magic line is this oTexbot.formattedText. So what it's saying is, this sketch, first, I have a part. I have sketches in it. And I have one sketch. And in that sketch, I've got text boxes.

And I've got one text box in there. And there's some formatted text in it. And that formatted text is equal to this run-on sentence of style override, font size, whatever the value I'll want to have for that font size, whatever your text is. And then, it's closed bracket on the style override.

And for the keen observer, they'll say, that's a different coding language than the iLogic code. And you're correct. I think it's JavaScript, but I'm not actually sure. There is more things you can do than just changing the text height, like you can make it bold. I would just Google what the style override commands are. But it's all going to just be working into that big, long run-on sentence in the formatted text line of it.

So now, we're going to go even deeper, because this is still pretty easy, I think. So dropdown menus. How do I make a dropdown menu in InfraWorks? Well, all you have to do is go into the background and adjust the background code of the program.

Sounds super simple. Why bother paint getting any easier? So this is the little magic statement. And it might look complicated, but it's not. It's just a parameter name, the details. I think the false and false is the visibility of how it's going to show up and whether it's editable.

34 is kind of like what number it shows up within the list of parameters. And then, you get into DataType 3. DataType 3 is dropdown menu. And then, this enumeration run-on sentence is to say I've got the labels and I've got the keys. Now, the unfortunate part of how it's coded right now is, it won't return the label value.

So if I program something, or an event, or to say-- I've got red, blue, green. And my out logic sees the words red, blue, or green and does certain things with it. When I land it into InfraWorks, I'm going to click Red. And it's going to return 0. And my code needs to adapt to that for now.

This is where the path will be to store the AC item. A little caveat is you probably can just use the JSON file, as well. But the AC item is what's actively being looked at by InfraWorks in the background. And so we'll show how to edit that if I really want to see these things show up correctly.

Once you go to that path, you'll see these three folders. And just be aware that some of the bridge content is actually under the generic object structure, because they're generic objects. So cross braces would be one that would be in the generic object structure. So good luck. You'll get a pile of AC items.

And it'll help you if you can figure it out. Best way I find is, change it a little bit in InfraWorks. And then, go take a look at the date modified. And the latest edited one will be your AC item that you're looking for. If you open it back up, you'll see a whole mess of stuff like this.

And you'll scroll down to kind of see this specific parameter. And then, you'd be saying, here is that parameter I wanted. And I'm going to write this all in so it says DataType 3 in there with all my keys and my labels to it. Then, I'm going to scroll down. And then, I can look for the part records. And then, in that part record, I'm going to go look for that super beam type whatever.

And I'm going to give it the default value. So this is the value that I want it to show up as a default when I go and use it. So good luck on that. So this is just a neat and handy thing in Inventor, but I've seen lots of use cases for InfraWorks, so I thought I'd show it here.

So sometimes, you want to pattern things, but in a really messy way. And there's the regular patterning tools within Inventor, so linear pattern, and circular, and however you want to do that. And then, I just call this one the fancy pattern tool. The correct term is the Sketch-Driven Pattern. And what this does is, I can duplicate any kind of thing wherever I put a work point to it.

So the beauty of it is, I can have a pretty complicated geometry. And wherever I put a work point, that geometry is going to land there. And I can actually have it create a separate body for however many points I've got. But here's the neat kind of way to do this. If I have a really complicated geometry-- for example, that last one was a parabolic diaphragm pattern that I need to map to.

So what I'm going to do is, I'm going to first do my preamble. I'm going to define some transient objects and stuff like that. I have to define some points. And points are kind of defined weird in iLogic, where you need to define both the x and the y separately, and then bring them in together.

But in this code, you're deleting all the old points. And then, you're adding new points. And what will happen is, it's essentially-- I'm clearing the slate, and I'm just putting all the points on. And that's where I want those new objects to land. So here's the function that would do that, so adding the new points.

And in this example, I've got kind of a weird pattern that's going left or right, and left or right, and left and right. And if I want it to-- if it goes beyond a certain point, I'm giving it some value to exit it as it needs to. So what does this look like? So you can have a diaphragm pattern that looks like this on a Super T, where I've got three diaphragms in there.

And I can switch it to this, which is a complex pattern of internal diaphragms. I can have a whole pile of optional pattern overrides. And again, this would be what you'd see in InfraWorks, as well. And it's all within the same model. Good luck trying to do that with Revit.

So I would say, I think I'm pretty tight on the iron. But here's my little victory lap. So in InfraWorks, if you want your final product to be an assembly, you need to publish it from Inventor as an assembly. So if I want it to show up in Revit with individual parts to the different things, it can't be a single multi-body part in Inventor.

But a lot of the fancy functionality you want is best done as a multi-body part in Inventor. So how do you go from a multi-body part to an assembly? There is a tool within Inventor that allows you to make components. And so I can split a solid into multiple different kind of things into an assembly, but it sucks.

And so we built our own tools. And this is going to be showing how they work. So off the bat, I'll be showing how the original tool from Autodesk works to make components. We click it. It prompts you, what template should the assembly be? And then, I have to go in. And I have to select all the different solids that I want to use in this new thing, click Next.

And then, I have to go one by one by one and say, you should use this template for this one, or this template for this one. Shocker. It's blank part every single time. And I'm making everyone go through it, so they can feel the pain of how slow this is. So if I had a part with maybe 100 different parts into it or bodies into it, I would have to click that stupid thing 100 times.

So now, I hit Apply. And I think I kind of sped it up a little bit here. And it's done. But now, I go back into the part file. And so I'm going to see, I've got parameters that find these little magic cubes that I've got there. And if I go to the assembly, I won't have those parameters. And the problem is, when I put this assembly back into InfraWorks, I don't have anything to control.

Because it's only going to look at the assembly model to say what parameters do you have, and I'm going to change only the assembly parameters. So here's our little home-baked tool doing it. It runs in kind of the same fashion as the Inventor one, but better. And inside of the assembly, I now have parameters.

And those parameters exactly match the original parameters from that multi-body solid. And in fact, they're mapped back to that multi-body solid in the first place. So the way this works, I would change that one parameter in there. It's actually editing the parameters back into this multi body that are then shown in the assembly and then refreshed.

So I'm actually still editing the part file, even though I'm in an assembly. And I'm showing a bunch of different parts, even though I don't really care about them. So our little code will kind of embed its own iLogic into the new assembly that drives its backwards compatibility like this. And it works for parameters, and user parameters, and reference parameters, and so on.

But let's say I wanted to do something even better with it. I've got an assembly already. And now, I want to insert another assembly that's already this super-powered driven assembly. So we've got another tool for that we've built. I think, in here, I'm showing, I've got those parameters in the assembly, still.

And then, I'm going to add that assembly to my other assembly, here. And so through movie magic, it takes a couple of seconds. And then, it loads in. So now, I've got an assembly that had its own pile of parameters. And I've now inserted another assembly that is then referencing back to a multi-body part that is referencing back to blah, blah, blah, blah, blah.

And even from here, I can then put this back into InfraWorks. And if I change these parameters, [INAUDIBLE] C, it will still work and work perfectly. And in this new assembly that I've got, it as well embedded a new iLogic code that goes back and works its way back through all the different piles to you to drive those parameters to the way they need to.

So that's my plug for Hatch to say that, yes, InfraWorks is good and Inventor is good. But boy, it pays to know when you know what you're doing. And that is the presentation. So I will leave it there. And I will answer questions next.