Autogenerating and Optimizing Modular Air Duct Layouts in Revit

DANIEL KAYE: OK. Welcome, everybody, to our course. This is a case study on a Revit app we built that focuses on the title there-- Auto Generating and Optimizing Modular Air Duct Layouts in Revit. Let's dive into it.

So, here's a little list of what we're going to cover today. We'll start by going over the team, the players involved. And then, we're going to outline the problem we're trying to solve for this application. And we'll show you the solution, the application we built.

And we're going to dive into a couple of the features that we think are pretty cool about this-- simulated annealing, you'll know what that is by the end of this talk, for sure, user adoption, how we tried to achieve that, why it's important. And then, at the end, we'll take a little step to go beyond air ducts to show how the ideas we talked about in this talk, in this application, could be applied to a whole host of things in the AEC world.

OK. Let's get to it. So, the team-- these are the people and companies that were involved. I will start with myself. My name is Daniel Kaye.

I'm a classically educated architect, I guess. I got a five-year Bachelor of Architecture from Syracuse, but also a minor in computer science, which played into where I am now. So, I've been working for seven years.

I slowly transitioned from architect to BIM manager. And now, I'm at EvolveLAB, the last two-ish-- more than two years. I've been doing software development mostly.

I'm interested in lots of the geometric spatial algorithms, really. It's my favorite stuff. Oh, and I am our official Director of Memes. It's on our company website.

And then, I'm here with Ben today. Ben, I'll let you introduce yourself.

BEN GULER: Yeah, for sure. Thank you. Thank you, Daniel.

So, I'm Ben Guler, Partner and CTO at EvolveLAB. My background, similar to Daniel's, is in architecture. I went to school for that.

I slowly transitioned to a BIM manager. And then, learned how to code. So then, as soon as I did that, that was my new passion and really wanted to do that full time. An EvolveLAB opportunity presented, and so I jumped on that trail and have been on that ever since.

I really am a liaison here at EvolveLAB, where I help out with solutions for our clients and customers, to our code team. So, I also get to code myself, which is really fun. And I also have a wife and two daughters, which I enjoy taking hikes with. So, it's really great. Yeah, that's me.

The next slide, I think we're going to just briefly talk about EvolveLAB. So, EvolveLAB is made up of a diverse, eclectic group of individuals. We've got people with backgrounds in architecture, licensed architects. We've got people with computer science backgrounds, physics backgrounds, construction backgrounds.

It's a really cool team that we've got here. And essentially, we help architects, engineers, and construction professionals implement design technology throughout the AEC space. Yep, that's us.

DANIEL KAYE: Yeah, I can talk about Henderson a little bit. Ben, you can hear me, right?

BEN GULER: Yeah.

DANIEL KAYE: OK. Well, this is the engineering firm we work with. They also have Henderson Building Solutions. It's a whole separate-- but it's a really big company spread across the US. And these are some of the-- we're highlighting some of the people we worked closest with there, but it was a great team at Henderson. Yeah.

Now, let's jump into the reason this partnership-- why they reached out to us in the first place, which I would call the problem. "Why can't the contractor just work it out," which is a joke, of course. But it's not, and summarizes what we're getting at here. So, a little background first.

Henderson developed this modularized duct system. There's actually an Autodesk University paper on it, a white paper, by Adam Roth and Sean Turner, which I'd recommend checking out if you haven't read it. But basically, they developed the system with US Engineering Innovations.

You see pictured some of these modular parts and stuff. And there's a whole host of benefits to this, which they could go on about, streamlining the manufacturing and assembly process and design, all these sustainability aspects. But when we got together, the real crux was how do we get people in Revit designing using this kit of parts.

So, I'm going to go through just the setting for this application. What we have here on the left is a simple setup, a very well-defined problem. There's a VAV box, and then a branch duct, which has already created a little MEP system, if you will. And then, air terminal layout, also predefined.

And what we're trying to do is get to the result on the right, which is to take that branch duct and break it into these modular pieces that they've developed, and then connect each of the air terminals to one duct module. And that's also made out of all these modular parts that are part of this big system. And then, defining the problem like this for us to make this application really simplified and helped us get towards success.

Ben has, I think this year, another talk at AU that sort of focuses on that, if you can find it at autodeskuniversity.com, or wherever that-- wherever this talk is. Yeah, Ben?

BEN GULER: Yep. Yeah, we've got another one, which is going to be focused more on co-authoring. But yeah, this is a case study on how we were able to help out Henderson here.

DANIEL KAYE: Right. So, what Henderson did to start is-- this is how they attacked this problem. They built all these parts in Revit, like families, mechanical systems, et cetera. And then, they made a proof of concept with Dynamo, which is what you're seeing in the top half here, the script, which Dynamo is a great prototyping tool for things like this.

And they were running it through Revit GD to optimize it. Version 1 of our application actually literally translated their Dynamo script.

BEN GULER: Yeah, that's right. Yep. We actually literally took the Python code and transpired it to C#. And that's our first iteration. There were some things already figured out that we used for our generative loop basically to make the first iteration of the code.

DANIEL KAYE: But, I mean, the big problem-- this is a great tool for power users that they were working on. But the big problem here is-- I think this is a quote from Ben-- "power users design tools for power users." And Henderson's real goal here was to get their whole mechanical team on board, have everybody using this, not just the Dynamo geeks or whatever. So, that became, I guess, the crux of our problem.

So to summarize, Henderson developed this modular duct system. And they prototyped it with Dynamo and Revit GD. So, we knew it worked. They knew it worked.

The goal of this tool is to connect the VAV box to all the air terminals using this kit of parts and really make a tool that has high user adoption that people use, that people not just are willing, but really want, enjoy using. At least, that's the goal. Did we do it? I think so.

BEN GULER: That's right.

DANIEL KAYE: All right. What did we do? We'll get right into it. This is the app.

We called it the Mechanical Run-Out Duct Generator app. This is the case study. So, this is the case we are studying, essentially, this application here.

So what is it? It's a Revit Add-in that generates optimized run-out ducts, and sometimes branch duct layouts, using this pre-made DFMA kit of parts inside Revit. It combines different aspects of generative design and human input. You get a co-authoring approach, if you will. Let the computer do what it's best at. Let the people do what they're best at.

It has lots of analysis optimization, so you can sift through different solutions. And then, when you find one you like, you hit that little Bake to Revit button, and bam. It just makes a fully connected Revit duct system.

BEN GULER: It's always so rewarding to watch that, to see how it-- press a button, and all this content that's there, you didn't have to model yourself. It's there, properly connected. It's always fun to watch.

DANIEL KAYE: I know. I could watch this GIF all day, but we don't have all day. So anyway, you might look at this like, wow. That's pretty complicated, Dan.

How could I possibly understand that? Well, it's not that complicated. But luckily for you, we made this little course, Modular Duct Generator App 101, "a simple six step how-to for using your custom mechanical generative design application," because everybody has one of those, right?

Anyway, the six steps are-- you select a VAV Box, a variable air volume box, and different options. You draw that main branch duct frequency. And then, you generate solutions. Pretty simple, right?

And you can examine those solutions, and bake to Revit when you're all done, basically a summary of that last GIF. And the last step is a little different, but you can try to auto-generate that branch duct portion, too, if you want. We'll get to that.

Now, we're going to dive into each of these, really see how this thing works. Select your VAV box. So, everything's already zoned. So, you pick a zone of the box.

There's a bunch of display settings on the right, which you can customize. These two sliders, I think, are probably the most important settings on here. We're going to talk a bit more about them later.

But the problems we're working with, these are multi-objective optimization, which means if you make one-- if you improve one aspect of a design, it's likely that you made another aspect a little worse. So, those sliders allow you to assign weights about what's more and less important with this particular duct branch you're making. And then, down at the bottom, there's the Simulated Annealing setting, which we'll talk a bit more about later.

Step two-- so, you've got all your settings, got your VAV box. Now, you just click. Click at each vertices and it draws the main duct, branch duct. It starts making all the run-outs.

Notice how it's really splitting it up into modules. It's calculating the corners. It's using some sort of modular system. That's what it's supposed to do. Do I get specific--

BEN GULER: Yeah.

DANIEL KAYE: I mean, I'm not-- I made this job. I'm not a mechanical engineer. So, some of these are little funny wraps, but it shows what the tool does OK.

So, step three, you generate your solutions. And as you may have noticed, as soon as you start drawing that branch duct, solutions start being generated. I mean, the longer you stay in one spot and leave your mouse alone, the better that solution is going to get. And then, you can also-- there's a Regenerate button. If you change some settings, you hit Regen, and it'll run it again on the current branch duct.

Once you have some solutions, you can examine them in that little bar graph that you can click between them to activate different ones. If you hover over them, it'll give you a little more detail about each one and what those numbers and bars represent, like that. So, you can adjust some of those design constraints we looked at earlier in Settings and regenerate until you have solutions you really like.

And one thing I think is cool about this, those solutions right now in the GIF, the numbers are really close. But maybe that designer will look at them and say, well, this one is obviously better than this one, because it has a corner piece. It's near a column. That'd be really hard for the contractor to get in there and assemble, or something like that. It just comes back to this co-authoring, working together, the computer and the designer, to get the best output.

So, right, Bake to Revit-- so everything this app has been doing, we've been looking at it in Plan. It's all in 3D, the drawing, the algorithm. So, you just click that button in the corner, and then it bakes everything to Revit, fully connected. You can run analysis on these systems, whatever.

And a little shout out to the Revit MEP API, which is a portion of the Revit API, if you're not familiar with it. It's really powerful and really agnostic the way they set up these connectors. You can do a whole bunch of stuff with MEP components in Revit using it. We took advantage of it for this project. Oh, one more thing I want to add here, one of the best-- one of the best parts of this Bake to Revit button is it makes your designs less sacred, in my opinion.

BEN GULER: That's right.

DANIEL KAYE: Right. What I mean by that is if there's a change in the design, and you're like, oh, I don't want to adjust. I spent two weeks modeling that duct system. I don't want to-- now, you can just delete, do another design, and rebake. You could bake seven of them before your morning coffee. And that's the idea. It takes out all the monotony. It lets you really focus on updating the design with ease.

So, we have an Auto-Gen button in the bottom. When you click it, instead of you drawing that main path, it'll draw it for you. This is still in beta.

I mentioned it, because this was only 12 weeks of developer time on this project. But you can see, if we continue going, this might be the next step in improving this algorithm that generates the branch duct. Or maybe we move on to other things, like we start adjusting the air terminal positions to better distribute the airflow and shorten other spread out ducts, or the VAV, or create the zone, which air terminals are with-- all this stuff. We can just-- this is a preview of how we can expand it to that.

So, failure is part of the process. Right? So, I thought I'd share a few of these, like this system-- four air terminals, one VAV. You think four modules, up the middle, and be-- but it likes to add this double 90 degree kink.

Why? I don't know. I should know. I coded most of them.

BEN GULER: Silly.

DANIEL KAYE: We've got this zig-zaggy one, which you wouldn't build that in real life, too much air friction. But to its credit, I think the zigzagging is because it does make all the run-out ducts shorter, because it's trying to get as close as possible to each one. But again, we'd have to add some metrics to deduct points for extra corners. And then sometimes, like this one, spaghetti. Ben, yeah. I don't really know.

BEN GULER: A silly one, that one. Yep.

DANIEL KAYE: That's a beta feature. OK. So to recap, we built this Revit Add-in where you select a VAV box and options, draw your main duct branch, and then generate solutions, examine those solutions, pick the one you like, and bake it to Revit. And then, if you're brave enough to hit that Auto-Gen button, see what happens.

OK. So now that we know how it works, we're going to start diving into the good stuff, why it works, and in my opinion, some of the cooler aspects behind the scenes of this tool. Simulated annealing-- this is chapter 4.

BEN GULER: That's right. "The brains behind the BIM."

BEN GULER: Right. Now, a little warning, we're going to start getting a little technical here. So, feel free to go get a snack if you're less interested in this part. This is my favorite part anyway.

So, we'll start with generative design. This is a huge industry buzzword. I think Autodesk has some good definitions I've thrown here, but I really like the "an iterative process from a computer's point of view," because once you know what these algorithms are doing, that's really what's going on.

Here's a diagram of the manual way. So on the left, we create our initial design. And it's pencil and paper. It's representative. You're doing this in CAD or Revit, I know.

I don't know. Maybe people-- some people still sketch duct layouts first. And then, you iterate. You red line.

You talk with people, change the design, update the model. It's just a cycle. You keep doing that until it's ready to build.

Now, take a look at the computational design way.

BEN GULER: Some similarities there it looks like.

DANIEL KAYE: Almost the same. All you got to do is take everything and put it inside a monitor icon. No, but really, the computer generates the initial design. And then, instead of iterate, it scores the design, some metrics. And then, it mutates, which is the-- it slightly changes the design, explores it again.

Is it getting better or worse? What should I do? And then, you build it when you have a solution you like.

What was I going to say? So, we're going to under-- you might ask, why can't I just generate every possible solution and then pick the highest score? And we're going to jump in the computer science world for a second and look at something called the traveling salesperson problem.

Ben, have you heard of this before we started this project?

BEN GULER: Yeah. I think I've heard of it before for a different kind of optimization thing that we were building. But yeah, it's-- definitely learned about it in the past two years or something like that, like, oh. We should get into this thing and try to solve it.

DANIEL KAYE: I'm going to use it to help explain. The idea is you have a whole bunch of cities, and you have a salesman who has to get to all of them. And you want to find the shortest path. And believe it or not, we don't have a way for computers to definitively solve this problem.

Here's a good example. An Amazon Prime delivery truck has to visit 60 addresses in one afternoon. What's the best order to get my Amazon optimization? So, if you look at this problem, with 6 cities, there's already 720 possibilities, which takes this really slow solver 11 seconds to try them all. If you add just two more variables, 8 cities, now there's 40,000. That's like-- it's a lot more. Anyway, this solver, it would take 11 minutes. It went from 12 seconds to 11 minutes just by adding two variables. So, imagine 50.

BEN GULER: That's a fancy word there. It's a pretty big number, looks like.

DANIEL KAYE: 30.4 vigintillion. I looked that up. This is how many years, at the same speed, it would take to try all those possibilities. Of course, computers will go a little faster, but not that much faster.

If one of our computers can't try every solution, how do we solve almost impossible problems like this? That's where we get into the field of metaheuristics. I feel really smart when I say this, because it's a big word.

If we break it down, it's pretty easy to understand. It's got two parts-- meta, heuristics. I'm going to look at heuristics first.

Essentially, how this was explained to me, it's like educated guessing. It's when you have a problem where we don't know the answer to. And we don't know how to-- we don't have a way to-- we don't know how to figure out the answer.

If it's too complicated or too time-consuming or impossible to actually solve it, we just use guessing. And this is used in all sorts of fields. And chess engines use a version of this. OK. And meta-- everybody knows what meta is. Not this one.

BEN GULER: Not sure about that one.

DANIEL KAYE: Meta-- it means overall. I think it's a great prefix. Looking at from a higher perspective-- that's good. It's also a common slang word these days-- that's so meta. That's why I have the Urban Dictionary definition.

BEN GULER: The meta game.

DANIEL KAYE: Right. So, here's the chart. This is a nice graphic. There's a whole bunch of metaheuristic algorithms. A computer's best guess is a really good way to summarize it.

A lot of these are nature-inspired. Now, the Revit generative design solver uses a genetic algorithm. So, we're going to look at those first to explain the starting point. You may have heard of these before. So, I'm going to try to go through this a little quickly.

What is a genetic algorithm? It's inspired by evolution. It's also a little slow, just like evolution.

So basically, you have a generation. And they make a bunch of offspring, I'll call them. And then, you take the best of those offspring, and you make more generations.

Here we have the scores, two offspring, and we're trying to go from regular people to really cool construction workers with badass glasses. So, I made a few more. And then, first generation, you pick the best one or two or however many. We've got some cool construction hats here, good PPE.

You do it again. Notice the scores in general are going up. You can have as many children, as many generations, as you want. It just takes time.

But eventually, you can get to a really high level of mostly high-scored solutions, some really cool looking-- you got the monolens glasses. That's what you want. Right? And you could do the exact same thing with mechanical duct layouts, which is why we're here.

I just changed the icons again. By the way, all these icons, diagrams, I made with Autodesk provided icons for these presentations, which I'm pretty proud of. Moving on, so same exact thing with ducts. You could score them in different ways. Yeah.

So, if we hop back to the traveling salesperson real fast, you'll see on the left we're trying all possibilities. And on the right, we're using a genetic algorithm. All of that gray mesh, it's generating like 60 ideas a second, and then picking the best one.

And you can see how much faster already. The one on the right, that solution, is already much better than whatever's going on on the left. The important part-- this is the exact same number of guesses. The one on the right is just making better guesses, the genetic algorithm. That's what's called heuristics, smart guessing.

Now, we already mentioned genetics can be slow. Another con is they get stuck in local maxima and minima. What does that mean? I'm going to try to explain.

So, say you have an idea, or a generation, parent. You generate a bunch of offspring. You pick the best one.

Rinse and repeat. Generate offspring, pick the best one, et cetera. You can see that they're gathering near this higher score.

But since the gene pool gets smaller, the variation is smaller. So, they all end up clustering. And you think this is your best one.

But actually, this is what's called a local maxima. We don't know this, but there's a global max somewhere else that we just haven't found. That's really what we want to get to.

BEN GULER: And the reason for that, too, Daniel, is because you don't-- from 1, you don't go lower. You want to go better. You don't want to go--

DANIEL KAYE: Right.

BEN GULER: So, right.

DANIEL KAYE: Which is the hard part, right? You get what I call the idiocracy effect. And if you haven't seen this movie, it's worth a hoot. It's worth checking out. Good piece of social-- I don't know what you call it.

So, that brings us to this diagram again where we have another algorithm called simulated annealing. Now this one avoids those local minima and maxima a lot better. It's also nature-inspired. But it's inspired by the annealing of metal, which is where you heat and cool metal to make it stronger.

It's very customizable, except-- so, this is how annealing works in a really broad sense. You take a metal-- imagine these Tetris pieces are like the molecules-- and you apply heat to it. And the molecules start moving around real fast. And then, when they slowly cool, they form into a stronger, I'll say better, arrangement. That's annealing.

So, what is simulated annealing? It's an algorithm where we actually have something called temperature in the algorithm. It starts pretty high. And then, it slowly decreases based on function. And the higher the temperature, the more likely we are to accept bad solutions. You'll see what I mean in a sec.

That acceptance probability is the probability of accepting a bad solution or worse solution than you already have. If we take this graph and invert it so the left side is the score now, not the temperature, we have a range of acceptable scores. So as time goes on, the score has to be better for it to be accepted.

So, with this algorithm, we don't create generations all at once. We take one idea, and we mutate it. We just continue to mutate it into either-- like this red one, it will become unacceptably bad. And then we get rid of it.

Or, the algorithm will just mutate until it has our better or best solution. As long as it's still above the acceptable range you can keep going. The key point being, if you look at that blue line, the solution often has to get worse before it gets better, which is something genetic.

When you just keep picking the best, it doesn't do as well at, like the blue one. I mean, the red one, you can see that 71 is a local maxima. We're not going to get anything better out of that even if we keep iterating off of it.

Whereas when the 40-- it went all the way down to 13, that blue one. But from 13, we're able to change it into something really good. Like that quote, how's it go? You couldn't have invented the car by iterating on the horse. You've got to take a step back, then change it even more.

So, here's that same graph. We're going to talk about the local minima and maxima and follow a case study. So imagine-- now we're simulating annealing. So, we're not generating-- not generating offspring. We're just iterating on an idea.

And as that temperature on the left stays high, it allows us to keep making select-- 3 is a lot worse than 2. But since we have a high temperature, we can keep playing with 3. Now, it becomes even worse. But the temperature is still pretty high, so it's still OK. We're still playing around.

Now, you always know where all your previous best solutions are. So, 5 is the best one we've had yet. But we can always go back to one of our previous best and iterate on it. Like, oh, can 2 get better? Well, it didn't get better. OK. Let's go back to 5. Did 5 get better? Oh, look. It did.

And as the temperature-- now, it's getting a little lower. It'll start clustering around the best solution. It'll iterate most around 7 and 8 and 9. So, the lower the temp near the end, it tries to only refine the best solution. And then, we get to the global max ideally.

And remember, in the solution space, this line I have of possible solution, that doesn't exist. You're just guessing. You don't know what solution is the best, just guessing in space.

So, we're building that graph, remember, because of the traveling salesperson. We can't possibly calculate them all. Yeah. That makes sense?

BEN GULER: Yeah, that would be the equivalent of-- us knowing the graph would be the equivalent of us running the brute force one, where it actually looks at every single possible one. It's invisible. So, it's really cool that you're showing that, how that's just-- we don't know. We're running this blind. And from the points, we extrapolate decisions to go this way or this way.

DANIEL KAYE: Right. So, the left image, it's not so important. It's the traveling salesperson in 3D being solved by simulated annealing. Check out that one on the right.

When the temperature is low, that red line is all over the place. It's really exploring the solution space. The lower the temp gets, the more the red line stays near the peaks. And if it gets really low, you can see it really focuses in on that one peak in the middle, because it figured out that's the max. That's the benefit of simulated annealing.

Sorry. I skipped this. Anyway, so if you look at it right here, back to the traveling sales problem-- one last time, I promise-- on the right, we have simulated annealing. And that red line is the solution we're playing with. It's not the best one. The best one is black. The red is different.

We're getting worse to see if we can take that worst one and find a better one. And as time goes on, the temperature is dropping. The red will start to-- you'll see less and less red, because the red and black are almost always the same near the end. It's like-- low temperature narrows that red line movement essentially. Hope that makes sense.

But, right. We're not here to talk about traveling salespeople. We're here to talk about ducts. So, let's bring it back to the ducts.

This is the exact algorithm we're using, the base of the algorithm we're using, to generate these things. That's what's going on. So, we're only drawing the black, the best solution. We're not showing all the light gray attempts or the red one. It's only the best.

But hopefully, some of these settings will start to make more sense. It's a quick way to get really good solutions, really good guesses, essentially. It might not be the absolute best, but it's pretty good in hardly any time.

So, we have settings. One of those is Simulated Annealing Start temperature, End temperature. Now, you know with these temperature things we're talking about, you can play with these numbers. Let it try for as short or as long as you want. Like I said, it's a very flexible algorithm.

And we have the results. You can see how many times, how many solutions, have been tried and improved. And I think when this runs, it'll give you 2,300 solutions. I mean, there's vigintiliions.

And it found a good solution with only 2,300 guesses, which is impressive, I think. Maybe I'm just a geek. I don't know.

BEN GULER: Right on. It's very impressive I think.

DANIEL KAYE: Right? OK, a recap-- so, we talked about what generative design is in this context. We made everybody here sick of the traveling salesperson problem. Maybe. And we gave you a word you can impress your friends with, metaheuristics.

We looked at this evolutionary-inspired algorithm, the genetic algorithm, and then some of the flaws with it, like how it's slow, can be slow, the local minima and maxima problem. And then, we dove into simulated annealing, which is what's going on here, and the pros and cons of that. So, now that we know how the foundation of the GD in this application works, we're going to talk about how we got people to use it.

Because really, if you build all this technology, but people don't like or aren't adopting it, then what was the point? I'm going to let Ben take over some of that. He's the expert.

BEN GULER: Definitely. Thank you for that, Daniel. So, let's see here. Right.

So, we'll start with-- so basically, without adoption, the tool is just expensive marketing material. And we have to make certain innovations so that we really foster adoption. And then, we build and design a tool that's not just for the power users that are very comfortable with minimal UIs, and just even a command-line UI, but it's actually intuitive and easy to use for designers.

So, we started with integrating this directly within Revit. Any learned behavior of navigating through Revit, controls, things like that, is-- you don't have to learn that again. It's right within Revit. It's not a different software. It uses a native element.

So, as you can see in this animation here, as you move those air terminals, if you hit Regen, the connections go back to those new locations basically. So, it really works off of the native content, and it produces that native content. And this really starts to enable a co-authoring approach to the solution.

So, in order to enable co-authoring, we had to make certain app architecture trade outs. And here are some of them that we had to do. One of them is interactivity over speed. We'd rather want to feel like the application is never frozen, always responsive, and showing to the-- displaying to the screen what's happening versus waiting a second, and then, when it's done, that's when you see the result.

Speed over accuracy-- so, this really played a hand in our choice in the genetic solver-- or the metaheuristic solver, where we needed something that's really fast right away and has a decent result that's pretty good. So, we really-- at the cost of not using the perfect algorithm that does the best of the best-- because we wanted that interactivity to be there. We wanted the user to co-author with the tool so that in case there's any changes that needed to be brought, let's say, the solution is only 80% there, the user could fill that gap and fix that.

Simplicity over customability-- so, as you could see in the UI, we don't have-- most of these settings that are under the hood, that are a bit more elaborate, are hidden away. Those are just stored in the JSON file somewhere where we don't have to expose all of that. All that's baked into that.

And another trade off we did is specific over general. And shout out to the Henderson team for this one. They really made the problem modular for us where it's just the-- no pun intended-- it's just the VAV box to the air terminals. It's not doing all the way from the RTU to even placing the air terminals.

So, the problem itself is encapsulated. And if you think of it as a module, you can have that module. You can have another module for just placing the air terminals, like you've talked about earlier, Daniel. We could really modularize the problem. And then together, they could connect and grow into something even more comprehensive that we already have here.

Another consideration that we've made-- yeah, I'm going to go to my next slide here-- is obviously we have to pay good attention to the UI design. And so, this is very important for user adoption. If I go next here-- probably right there. So, many of you have probably seen this tool and have probably even used it to rename PDFs.

It's pretty cumbersome and intimidating to use, but very powerful. So obviously, not like this. We don't want to have something that is intimidating to use. But we want to foster and have that intuitive layout.

So, what we went with is a vertical design here where everything is scrollable. And at the top, we have the inputs. In the middle parts, we have all the settings and adjustments where you could adjust your constraints.

We have a simple design options graph. We could switch through the design options at the bottom. And then, at the very bottom, we have this static bar that has your action buttons, like Drawing and Baking to Revit.

The other side to the coin for UI is UI's user experience. And what we have on the screen here is displaying how our lightweight geometry is streamed to Revit where, when we turn off the ortho mode, because that might make it seem a bit more choppy, you could see really how smooth the geometry is being rendered to the screen so that the user could, at any instance, really-- if you move the cursor a little bit, you can really visualize that and start to make decisions as it's computing on the fly, live, essentially.

Another portion that that enables us to do is you could see the work in progress. So, when the GD solver runs, right away it has an iteration, an idea of how things get connected. But, it's not finished.

It's constantly thinking. And as soon as you change your inputs and you move your cursor, it's thinking more and restarting that, because it has new inputs. So, you always see the work in progress of what the solver is doing as you're moving your cursor, clicking away through your design.

Another thing that we really have to pay attention to and will enable this co-authoring workflow and essentially enable fostering adoption is the output. So the output is workable output. It generates native content.

The modules, the families, everything is interconnected properly such that once you bake the solution, you could still make minor adjustments if that solution is not exactly what you needed it to be. And that gives the designer a bit of a comfort and trust and ability to have a fallback in case something is not exactly the way they wanted to model it for that condition.

And the last thing that I'll touch on here is make it fun. So, it's really rewarding to use the tool, to have it animated and interactive, and see this geometry being rendered to the screen. And it feels-- it really feels good to generate all this content and just press Bake, as we've seen earlier. It's just all this native content is there. And then, you think about it. I didn't have to actually model that myself. And I could edit it, and it's there. And it's there for the project. So, it's really great.

To recap, essentially, is these are some of the considerations that we had to make and really drive to foster adoption. It's integrated within Revit so that you don't have to relearn new behaviors, new software, the app architecture trade offs, where we have to have certain values of other values, intuitive UI/UX design, workable output so that the user has a comfort for a fallback method, if anything. And then, make it fun so that it's enjoyable to use a tool. And make it so that other people could see-- show off the tool, like, hey, look. I'm working on this thing. And someone else could see it. Like, oh, this is fun. I want to try that tool. So, just trying it, it's really fun to use.

DANIEL KAYE: It is fun. I think it is fun. I think other UI and UX designers we've had-- yeah, a lot of fun. I hope the Henderson engineers enjoy using it.

BEN GULER: Yeah. And one thing I was going to mention, too, is, I mean, these are things that we've learned on this project together and utilizing this technology. But obviously, we could go way beyond ducts. And even within the ducts, as you've already mentioned, Daniel, even there, there's space to grow there. And maybe you could talk more about that.

DANIEL KAYE: Right. I mean, I'm hoping by the end you can see this technology. We applied it to ducts, but a lot of it, lessons learned, technologies we've found out or developed, et cetera, we could use them for so many things. We're going to show you a few examples.

This is not just ducts, this presentation. It's so many things in or even outside the AEC industry. So, one example, we made this schematic plan generator for this large architectural client. And what it does is creates interactive, scored, schematic floorplans. And it uses a physics-based metaheuristic generative design algorithm, which we know what most of those words mean.

I mean, it's really cool. It employs similar co-authoring techniques. It's on a different platform, but it still communicates with Revit. It's still multi-objective optimization. This one has 30 sliders, the Henderson, since it was such a boxed problem. I think it had two or three, depending on which build you're looking at. I could give a whole talk on some of these algorithms.

Then, we have Morphis. This is one that I think Ben is giving, again, another AU talk this year about. Right?

BEN GULER: Yeah, definitely. And just a little bit on this one. Basically, it's using the same kind of ideas and concepts that we talked about in this case study, and applying it to layouts.

And then, on the screen right now, we have just a perfect concept of an office where you just dealing with low resolution volumes that are mapped to families. And then, you can just iterate through them and see metrics and what your ratios are. And then, you can even see how if you move a wall, it's responding to that.

And if you draw, it's actively tracing your cursor. And when you're ready to have something that's somewhat acceptable, you can just hit Bake. And then, similar concept, you have all that content generated for you from the schematic geometry within Revit as native Revit content.

DANIEL KAYE: Already in Revit, responsive, reactive, similar UI techniques, some other unique stuff in this one. That's for a different talk. Anyway-- and I started making a list. But really, in my mind, the possibilities are endless.

Like just with ducts, we talked about laying out the air terminals or choosing what VAV boxes go with what zones or maybe without modules, sizing the air ducts. You could go into any discipline, like arranging gravity drain pipes or sprinklers. That's a big one, I know.

All these different construction applications, some of these we actually have similar projects we've worked on. But all this and many more, I'm sure. I hope you guys watching this can imagine other ways to use these type of techniques.

In summary, coming to the end here, we'll summarize what we looked at today, what we learned. I hope we learned. We looked at the problem, how to get Henderson's mechanical engineers using their modular system within Revit, and the app we built that was the solution to that problem, and then some cool aspects of it, like simulated annealing and different metaheuristic algorithms, optimize-- and ways to optimize speed and allow co-authoring, how to increase user adoption with lots of UI and UX design, and a whole host of other things that we've learned from trial and error and user testing.

And then, how hopefully some of these ideas from this presentation and technology can be taken beyond just modular duct layouts, although these are really cool, I'll say. But to-- so many things that I'm sure we didn't even list. I guess that's pretty much it.

But if you have any questions, I personally could geek out over any slide in this presentation for a few hours. So, if you want to send me an email, I've got this picture-- sorry, Ben-- from our last--

BEN GULER: I love it.

DANIEL KAYE: --company resort. You're in there, some of our other teammates. But again, any questions with this online presentation? Feel free to reach out. Otherwise, I think-- unless you have anything else, Ben-- that is most of it for today's talk.