Using Dynamo and Generative Design to Simplify Complex 3D Schematic Design

LOUISE SCHLATTER: Welcome to this case study, Using Dynamo and Generative Design to Simplify Complex Schematic Design. It is our intent that you will pick up on some tools to help simplify complex problems, gain some insights towards your path of automating and optimizing your designs, and learn a bit about Dynamo and generative design from our experience. This will give us something to talk about in the Autodesk communities.

So where I'm coming from, I'm coming from the point of view of the AEC, or the Architectural Engineering Design and construction community. SSOE is my employer. It is an international firm operating in the AEC industry with a focus on designing and building the future for our clients, colleagues, and communities.

My contribution is primarily in helping to ensure you are provided with your favorite products, that the materials that you use and consume every day are recycled and recyclable and energy-efficient. I help provide the environments where you might be developing your employment skills and help to make more sustainable products available to you. I'm an architect registered in several states, including the location of Autodesk University 2022, the great state of Louisiana.

Our clients come to us with a vision. They're planning to increase their market share by 12%. They want to convert their facility to carbon-neutral by 2030. They want to provide a new service or make a product that's never been made anywhere except the laboratory. They want to improve the safety of-- well, you understand.

My task is to help discover what this means and to make it visible and understandable in AEC terms. Traditionally, the tools have been in 2D. One of my favorites is the matrix. It's one of the great 2D tools to explain what's going on in the project.

It helps to explain it back to the owner and starts to make the conversation visible and understandable to AEC community. There are other matrix that we use. For example, one that might be a summary of the project goals, how we're going to measure success, how much space is required, what utilities are required, and how many people do we need to accommodate?

The next step from the bubble is the bubble diagram. We take what we learned in the matrix and we convert it into something that's even more visual. We have an opportunity to start talking about the relationships between things. We start making information visible by different types of bubble diagrams. Each one's unique. They're all different, and the idea is to make the information understandable.

From here, we go into another 2D representation. We take what we've learned from the matrix and the bubble diagram and make it more building-like. We've been experimenting with this step in 3D, to which at this point is basically just 2D with a vertical. The advantage is that we're providing spaces that are developed for the things in it. The next step in our enhancement is to take the things that are going to occupy these spaces and organize them so that we can understand how these spaces are going to be working. While much of this is in common practice, I am part of an innovation team that experiments with electronic solutions and ultimately gets developed into applications for our staff.

So I love this industry. There's always something new. There's always a new challenge. And, of course, naturally, I'm here because one of our clients brought us one. They brought us a project saying that they have 100,000 things that they want us to help them organize.

This background is kind of a representation of what 100,000 things might look like. They want them to fit in an existing or maybe a renovated facility, of course, efficiently. They have lots of rules for how they want them organized. And they have no idea what the effect of the local building codes might be on this plan.

So the first thing we need to do is figure out what we do know. There's a lot of data. But is it the right data? What do we need to do to make this information visible and understandable to the AEC community? What effect do these local building codes have, and how do they interact with the client's rules for organizing them?

What does efficient mean, and what is fit? How big are these things? Are they all different? Are they all the same? If this was just a close packing problem, we wouldn't be here.

SSOE has found value in the philosophies of lean thinking. One that I found most useful is set-based design. It's about making the right decisions at the right time. In this case, we're focusing on understanding the data, trying to figure out what the owner needs. We start with the highest level of information we have and make some hypothesis and what that might mean. We explore each.

And as we get to the presumed outcomes, we abandon several of them, find out that they aren't the ones that we were looking for or the ones we needed. We find the one then, of course, that seems to be the right answer to that question and use it as the launching point for a whole other set of questions. So we're discovering what our client needs to do with these 100,000 things.

Introducing the Swidget. One of the first things we learned from our client is that 100,000 things are not moved around one by one. They are moved around in small groups. So we were able to consolidate them into something that we're calling a Swidget, which is just basically a planning module.

So the net result was is we had about 25,000 Swidgets. That's a much easier number to wrap your mind around. And you can see that the background in this case, which, of course, is 25,000 widgets, is at the point where you can almost see something else as squares as opposed to pixels.

Well, can we do this again? Is there something else about our Swidgets that we can do to reduce this number further? So it turns out there are some things in common between Swidgets.

The idea of Swidget families were born. We used the organizing rules to collect closely-related and similar widgets together into organizational units that we called families. These families in turn were then further grouped into groups of Swidget families. We were able to reduce the number of things that we were trying to organize down to 100. Now, this is much more palatable after trying to wrap your mind around 100,000 things, don't you think?

Now we have a deep understanding of the data. So now what? Can we organize 100 Swidget families? It's organized in a manner that we can start translating it into a building, into the building requirements, we think. But are we really ready to start? There are so many rules that must be applied. What we're going to do next?

Well, let's think about it. Being part of our technical initiative, it seems kind of natural that we would consider Dynamo and generative design as the tool to help inform the design. These tools work, but I've never seen it as an additive method in 3D building design. Can we do it? Seems like a good fit.

The features of generative design can assist with comparing nonlinear relationships and dissimilar data types. That's a fancy way of saying we have a way of optimizing. I love it. The output and stylized optimization graph is a great tool and a great way to start discussions. The challenge, of course, is that my programming skills are quite limited.

I need help. Fortunately, at SSOE, we have a virtual design group that can support these activities. I got our top Dynamo programmer assigned to me, my superhero number one. Dynamo is a visual programming system presented as a graph and built with nodes. If a new node is required, it takes some script-based programming to make it happen. It was deemed that this was a fairly sophisticated project that needed to do some serious programming.

That's why you periodically need a programmer who can speak computer language-- a programming language, rather. Because not everything you need and not every node exists in Dynamo or plays well with others in the Dynamo graph. If you're doing something unusual or complicated, some of the additional programming expertise is going to be needed. It's clear we needed some new nodes. We needed more help. So we reached out to Autodesk for a second superhero.

As part of our Autodesk agreement, we have access to Autodesk implementation Services. It's a great resource, and it saves you time of hunting down just the right consultant with just the right insights. And they so they assigned us superhero number 2 to the project.

So this is what we continued to learn about using Dynamo and generative design. Having the team together, we have a rough direction and we set off. Well, there's still more to learn. And these are a few of mine.

It's not magic. It seems like magic, but it's a lot of work. Running Dynamo and generative design may seem like magic to some, but it really is not. It just really is a lot of work to get to the point where it runs, particularly if it's something that hasn't been done before.

We met as a team weekly to discuss logic, approach and strategy, plan the outcomes, and review our progress. As the project grew and programming came together, we made tweaks on how it the Revit model was modeled, the format of the input, format of the output, redefined what and how we measured the outcomes and generative design.

One big lesson was that we needed to respect the factorial. When analyzing a set of different things and when they appear in different orders, they are considered unique, they are considered to be a different solution, the math is called a permutation. When the size of the set of things equals the number of things in order, this reduces the permutation to a factorial.

And if this relates to anything you can count, measure, or quantify, the factorial is the key to how challenging it might be. The factorial, in case you haven't noticed, is the product of all the positive integers less than or equal to the number of objects that you're trying to organize, count, or measure.

So let's look at the number five, see if we can wrap our mind around a factorial. So if factorial of 5 is 5 times 4 times 3 times 2 times 1, which, if you do the math, comes out to 120, which, of course, is just a line, one dimension. And what we're doing is in multiple dimensions. We have to get to 2D and then we have to get to 3D. And with factorials, with every different organization counting, its factorial times factorial. And in 3D, it's factorial times factorial times factorial.

Looking at our number 5 again, this turns the number in 2D to 14,400, from our 120 different ways we can organize five things. Now we have a 5 by 5, and it's at 14,000. We make it 3D, that's a 5-by-5 cube with five things on each side, and we're starting to approach 2 million.

You can get the idea that the numbers grow exponentially. So poof, we are back at our base design tool to control these numbers from getting out of hand. The factorial of 18, which didn't seem like a big number at the time, the factorial is in the quadrillions. That's a number with 15 zeros. We do not have access to enough computers nor the time to wait for the years of processing time it would take to deal with a permutation of 18 by 18 by 18 things.

The other thing we learned is about inputs in Dynamo. Dynamo can read parameters one time from Revit. And so the data transfer is one time in, and hopefully, one time out. There's a story to follow about that.

Dynamo can receive input from an Excel file, preferably that's in a CSV format. It does not like comments in the data. Dynamo cannot read a matrix. Its power is in lists. So when you present it data, it's going to want to be list-like. And, for example, from the matrix it into Dynamo, it has to translate as it shows on the screen. F could be A, B, J, L, S or T, and you have to write it with the underscores.

The other thing is the permutation qualities. This can completely derail you if you're not careful. When you run option, your choice of values in your permutation will significantly affect the outcome and the time it takes to run. For example, at one point, we were getting oddly-similar options.

Hunting for the reason, we discovered that the permutation step-- that was the bottom input there in the screen-- was set at 33. Setting the minimum at 0 turns out to be good practice. And what you choose to set as the maximum will determine how long your break is while you're waiting for the options to run. Keeping it small while you're working out the bugs keeps your frustration level to a dull roar.

Going back to the 33, you can quickly spot a less-than-useful permutation when it appears that the order of the input data drives the outcome. Cows tend to return to the same stall every time they enter the barn. If your data appears to do the same thing, you will need to look for the cause or a flaw in your logic. We saw this at one point when we appeared to be overrun with sliders. Our results improved when we removed several of the sliders and made more use of list and list manipulations.

Generative design works because you have a way to measure success. Sometimes this requires a little creativity. The ones that work for us are measuring the distances from the Swidget to a specific feature, like a room or door. Measuring the efficiency of the space utilization or measuring how much room was left over was also useful. In this case, the goal was not 0, but 10%, a number that represented flexibility in use of space.

We used a couple of these also for quality control. We measured that the organization was not random, verifying that things alike were together, verified that no Swidget was in the wrong place or facing the wrong way. So what do we have?

We have a Dynamo graph. I apologize for the resolution of the image. The organization counts. Notice the different colors and the color sectors and groups. Granted, it looks a little shadowy, but it also doesn't look quite as spaghetti-like as some of your traditional Dynamo graphs. One of the reasons for this is just an indication of how much programming was actually done.

Python does not look like English to me, in all honesty, although I'm getting better at reading it. There were a lot of time spent looking in meetings at different pieces and parts of the Python script. The stuff is what is behind that lovely, clean-looking graph and makes it work from the previous slide.

Dynamo worked. The good news is the graph does perform and does organize our Swidgets. The bad news is that at this point where this image was taken, it was ignoring the existing building heights. So the software does perform, the graph does work, and we are getting options.

So with the correct permutation, we got as many different options as we wanted. And the selection options from the customize graph, we were able to then refine what was the best organization out of our option set. And then we ran out of time. We had this lovely solution, but we didn't resolve how to get it back into Revit.

That's where we are today. We're in the process of refining it and getting it back into Revit. And we have a few other next steps as well.

One of the things that happens in programming with Dynamo is that distances are straight lines-- well, not really straight lines-- they're considered curves. They are not paths of travel. For buildings with doors, this would yield a false sense of nearness. It's a level of complexity for which we didn't have time in the development of the graph to date. It would be potential enhancement that I, being an architect, would like to see.

If you're looking to use these tools, please don't forget how to get the results into Revit. Dynamo and generative designs are new tools in our toolbox. We still need to get better at understanding how to use them to benefit our clients, colleagues, and communities. We have a working graph. But it requires someone who knows what we're looking at to use. We need to refine the user interface so that it can be used for other similar purposes.

Once we have that interface, we need to plan for how it will be accessed. We have recently embraced a library for graphs and need to figure out whether this is where it should live and from where it should be assessed. The set-based design theory is definitely one of the heroes of this story. We need to encourage others to use it to their advantage and to help organize their designs, work, and graphs.

I want to thank you for listening to this case study on using Dynamo and generative design to simplify complex 3D schematic designs. This is Louise Schlatter, and I look forward to interacting with you in the future on this topic. Thank you.