From those touting that the tool will replace our jobs to those that speak of it's impending demise, generative design has had a rocky start... but what if we looked at generative design from a different angle? What if we took a co-authoring approach to generative design? We will look at a few case studies utilizing generative design for Revit with Dynamo, but where it will get very exciting is when we start to demonstrate how you can use generative design as a co-authoring tool directly within the Revit project environment. This is where we personally believe the most value lies - where the tool becomes an extension of the designer, and where co-authorship gives you powers not known to be so intuitive. Join us as we enter into this next chapter of building information modeling - co-authorship through generative design.
Key Learning Objectives:
Use Dynamo to create a generative design for Revit studies
Know what is possible and not possible with Generative Design for Revit
Use model assist tools within Revit to automate design
Leverage co-authoring generative design directly within a Revit project
Original Recording: Autodesk University 2022
Introduction
In recent years Generative Design has some criticism in the AEC community including from Senior Researcher Daniel Davis where he posted a very provocative article to his blog in February of 2020 on why “Generative Design is Doomed to Fail”.
Article Reference: February 20, 2020 https://www.danieldavis.com/generative-design-doomed-to-fail/
The following year Paul Wintour with Parametric Monkey posted another article titled “Generative Design Fail – Why aligning design goals & digital processes is important”
Article Reference: July 27, 2021: Parametric Monkey - https://parametricmonkey.com/2021/07/27/generative-design-fail/
Both articles are very well written and have some very thought provoking ideas in them on why Generative Design is either not a pragmatic process all together misses the mark on goals we are trying to solve for. Both articles also discuss the process of how designers work and whether or not Generative Design is actually useful in how we as professionals in the AEC space would use this technology. For our class we will be taking some of these criticisms into account and we will beg the question- do we need to throw out the proverbial generative design baby out with the bath water or are there some useful ways to leverage “Generative Design” in the AEC community?
We at EvolveLAB personally believe the most pragmatic place for Generative Design is “Coauthoring”. Daniel Davis said it best when he said:
“Until we get to a point where algorithms replace designers (which may never happen), algorithms will only be practical if they work with humans.” – Daniel Davis
Algorithms help us think faster…
The challenge of multiple objectives
We’d like to start today with the Architect and Engineer’s dilemma. On any given project an architect or engineer is responsible with having to coordinate multiple facets of the project ranging from daylighting, circulation, structural performance, thermal protection and much more.
Reference: Autodesk MaRS Office Study
The problem is as humans it is very difficult to calculate let alone optimize all the given tasks that are being given to us at any given time. According to research, our brain can only process two objectives at a time. As soon as we introduce a 3rd tasks, one of the two original tasks are removed.
Multi-Objective Optimization
Generative Design helps overcome the “Architect’s/Engineer’s multi-tasking (objective) Dilemma” by using multi-objective optimization. In the example below of the Autodesk MaRS office we at EvolveLAB were able to translate this dynamo algorithm to a generative design study optimizing Adjacencies, Buzz, Views to Outside, daylight, and workstyle all simultaneously.
Bound By Time and Deadlines
The other problem that is not unique to Architects and Engineers is the concept of time. Architects and Engineers have real deadlines constrained by real timelines.
With this finite amount of time there are only so many hours in a day to complete our design studies and meet our deadline.
As humans we are bound by it, constrained by it, and cannot escape it no matter how much money we have. We are given the same 24 hours in a day that Warren Buffet has. Bill often likes to reference his days of working at HDR when he was working on a hospital design study. He remembers needing to create 21 design options over the course of 21 days. He had to crank out at least one design option in Revit every single day. He was bound by the 10-12 working hours I put in every single day. But what if he wasn’t? What if he was able to cheat time? What if he could analyze the same amount of options, it would take over 6 months in 6 minutes? None of us are still doing long division or multiplications. We use calculators for that because they are faster.
Whether it is a calculator or Generative Design for Revit, these are simply tools…tools that help us do our job faster and more efficiently.
EvolveLAB Generative Design Study for View Optimization
Generative Design Process
Let’s take a look at the typical Generative Design process for Revit using Dynamo.
Generative Design and visual scripting can be a very technical, so let’s use some analogies to understand some of these core concepts. Let’s use the analogy of baking a pie. When you typically start baking a pie, you look at a “Recipe” which has a series of “Ingredients”. With different variations of ingredients, you can create a lot of different kinds of pies. With Dynamo our constraints become our “ingredients”, the variation of those constraints become our “Recipe” and our solutions become our “pie”.
In Dynamo it typically looks like the following...
EvolveLAB Dynamo Recipe
Constraints = Ingredients
Constraint Variations (Algorithm) = Recipe
Solution(s) = Pie(s)
When creating your script you should think about the metrics that make up your design options. What kind of solutions do you want to minimize? What solutions do you want to maximize? For example, perhaps you are creating a space planning script for a hospital. Some of your goals could include: Minimize travel distances for nurses
Maximize daylighting for patients
Minimize adjacency distances for departments
EvolveLAB Script Written For Atlas Group London’s modular healthcare design solution
Creating Generative Design solutions for Revit via Dynamo is an iterative and multi-faceted process. It includes Defining constraints, generating options, analyzing/ranking those options, and integrating solutions found into your overall model. Let’s take a look at an interior design example.
A recommendation that we often make is to use Generative Design for very targeted design studies. One example could be a point attractor tile pattern study for a bathroom. Using this example, lets layout the process outlined earlier
1. Define Problem = Wall Tile Pattern Design
2. Define Constraints = Sort tiles based on the distance to attractor point.
3. Generate Options. Generative Design For Revit gives us 4 ways to study our designs.
From the Generative Design Primer, the definitions are the following.
Randomize - 'Randomize' generates a specified number of design options by randomly assigning a value to each of the input parameters.
Optimize - 'Optimize' is the method for doing an optimization run with Generative Design. During an optimization run, Generative Design will develop the design based on the evaluator's outputs.
The optimization process works by creating multiple 'generations' (or iterations) of a design, where each iteration will use the input configuration from the previous generation to optimize the new design options.
Cross Product - 'Cross Product' lets you explore the entire design space of your design by combining each step of every parameter with the other parameters available.
Like This - 'Like This' will make Generative Design apply slight variations to your current input configuration. Using this method, you can explore different variations of a design that you already like.
Rank: The next step is to rank your options. You can do this either with the parallel graph chart or using the scatter plot method.
Once an option is selected, that last step is to “Integrate”. To do this you can use the “Create Revit Elements” button in Generative Design For Revit. Your design option is then baked into Revit.
Let’s cut through the theoretical, and look at a case study…
Case Study
Project: Hobbs Trail
Tools Used
Pen/Paper
Dynamo
Revit 2021
Generative Design for Revit
The Hobbs Trail project is an ideal use case for using Generative Design. The problem is well defined and specific where using Dynamo scripting is the most time efficient way to generate solutions and explore options. With the script, we could explore different base surface shapes, different ways to segment the shape, the cost & complexity for fabrication and the aesthetic. The aesthetic is especially important as it is a subjective “metric” that cannot be quantified. Using Revit GD, we were able to preview the different design options in the 3d viewer alongside the metrics that affect fabrication.
Image Reference: Hobbs Trail form KC Global Design & Hufft
When using generative design some presuppositions are that you can’t use analog tools such as pen and paper. Nothing could be further from the truth. Sometimes using pen/paper helps us with the “thinking process”.
Image Reference: Hand sketch completed by Ben Guler
As mentioned, when setting up your studies, you want to think about what constraints and metrics you’d like to use for your GD solver. Here are the ones that we used on the Hobbs Trail project.
Constraints (inputs)
Number of Sections – the number of divisions along the Z axis of a shell surface that affects the extrusion lengths, number of segments, and aesthetic
Y-Attractor – defines how the surface sections are oriented (converging closer or further along the surface) that mainly affects the aesthetic and constructability
Extrusion Size – the square steel size: larger sizes yield less members and a more pixelated aesthetic
Extrusion Length – the length of the square steel members with priority to minimize unique lengths (the interlocking point moves but the steel member is the remains the same size)
Perimeter – adds cap segments to the perimeter of the shell structure for rigidity, and affects the aesthetic
Solution Metrics (outputs)
Count – number of steel segments to fabricate
Cost – compounds the number of segments, sizes and lengths
Aesthetic – subjective to the designer, previewed in the 3d viewer
You can see we used a combination of the scatter plot and parallel graph chart when interrogating the different options we were trying to optimize.
Image Reference: Hobbs Trail Generative Design study executed by EvolveLAB
We further added extrusions to represent the tube steel that would be fabricated for the project. This also gave us the ability to explore the geometric aesthetic we were looking for.
Image Reference: Hobbs Trail Generative Design study executed by EvolveLAB
We then handed the solution to Hufft who ranked the solutions and baked them into Revit. Further they also completed the permit drawings and fabrication of the structures.
Images Reference: Hufft Permit Drawings
Image Reference: Global Design New
What’s possible/not possible with Generative Design for Revit?
What's Possible | What's Not Possible |
Fitness Studies | Real Time Co-Authorship |
Optioneering | Iterative Design |
Different ways to Study Models (Randomize, Optimize, Cross Product, Like This) | Local Modifications |
What’s the right tool for the job?
“Power users design tools for power users, not everyone else...” – Ben Guler
Dynamo and scripting in general are ideal for prototyping, custom solutions, and specific scenarios. When we start to generalize scrips and make them adaptable to multiple projects & conditions, the script becomes increasingly complex. For scalability, deployment, and ease of use, we find that add-ins have been more successful. Addins also enable a more customized user experience.
Complex scripts are not very maintainable due to the limited testing environment and change tracking of source code. Many times, running complex scripts feel like temporary solutions, reminiscent of the “marble machine v1” from Wintergatan.
Wintergatan Marble Machine 1
This complex machine automates playing instruments for an entire band. However, it can only be run by the maker, and it is constantly updated so that it doesn’t fall apart. It’s made of plywood, which is easy to form and does not require expensive and complex machinery. The plywood can be quickly formed which allows for rapid iterations when prototyping.
This machine was a complete marketing success and an internet sensation. However, due to its flimsy design, the machine was never played in a concert, which was the original purpose for making it. This story is quite analogous to many Dynamo initiatives. They are successful in the author’s hands, and when the author is on a project, that project has an incredible boost. The marketing team can use the graphical output of the automations and significantly improve their standing in the industry by showcasing their technological abilities. When we try to deploy the Dynamo and GD solutions to other non-power users, adoption is not as vast as we would like.
Dynamo scripts have unique tradeoffs:
Fast to develop, slower to scale
The more scaled, the more complex
The more complex, the slower they run
The slower they run, the less likely non-power users are willing to learn how to use and adopt them
Wintergatan Marble Machine X
Then, Marble Machine X was developed. The design requirements are now well known and using the lessons learned, the design was updated, and the materials used are more robust. This machine is made with metal which is slower to form, and needs more skill to weld, bend and cut. More expensive machinery was also needed to fabricate the parts: CNC, lathes, and metal 3d printing. The updated design is more robust and performant.
Revit addins and Dynamo have a similar relationship. Dynamo is better for prototyping, reacting to change and faster to develop while addins are better for scalability. With addins, we can implement automated testing for supporting multiple conditions and multiple projects. We can also customize the user experience with tailor made user interfaces and with direct access to the Revit API & beyond.
Addins also come with their own tradeoffs:
They are slower to develop
They require more expertise (coding in C#)
They cost more
More scalable
Can better handle complexity
Customizable UX
Better for non-power user adoption and deployment
When designing a co-authoring tool that has a GD solver embedded, it was clear that the right decision is to create an addin and use Dynamo only for prototyping. A Revit addin allows full control over the execution speed, accuracy, optimization, and user interactions within Revit.
How did we get here?
If we take a step back and look at how we got here, we can observe the progression from CAD to BIM to GD. When digitally drafting in AutoCAD, the basic building blocks that users interact with were points and lines (curves). With the migration to BIM, the basic building blocks were point based and line-based families. As we foray into Generative Design, the basic building blocks that users interact with are sliders, toggles, and element selection. From BIM to GD there is a jump from drawing walls to generating buildings.
There seems to be a dramatic gap between users interfacing with point based and line-based objects to toggles and sliders. We believe that this jump is skipping a critical step. With CAD and BIM, a user can click and instantly see a result. However, from BIM to GD, responsive feedback is important for learning, and trusting a tool is missing.
Generative algorithms are powerful in computationally solving difficult problems. Coupling metaheuristic algorithms with a co-authoring approach allows designers to harness the computational benefits while retaining the simplicity of working with line-based elements. Co-authoring + generative design makes generative design as simple as drawing a wall.
How do we approach GD Co-Authoring?
What would we want from a co-authoring tool powered by a GD solver?
This app would need to allow for an iterative design process instead of linear one, as this is a more natural way designers work. A designer cannot wait 10 minutes to generate another 100 options after making a change in the constraints, priorities, or other inputs. The generated output needs to happen in milliseconds allowing the design process to take in flexible dynamic inputs in real time.
Immediate feedback to changes in inputs allows designers to understand how the changes affect the generated result. Moving a slider from one side to another should immediately start to regenerate the solution and present the in-progress work on screen so that the correlation is made between the input and the generated output.
A responsive app allows designers to make split second decisions and change their mind as the generated results are rendered in real-time.
We want this app to be intuitive, so that there’s a shallow learning curve. The complexity needs to be hidden or remain internal to the app and only the most important aspects presented as options to the designer.
EvolveLAB Morphis Revit Addin
When designing this application there are certain tradeoffs necessary:
Interactivity over speed
Speed over accuracy
Simplicity over extensiveness
Specific over general
Interactivity over speed. The ability to interactively render the active solution to the screen is more important than making sure that the generative algorithm is ultra optimized. The execution speed for generating solutions is critical. However, we would rather sacrifice a few milliseconds and render what the algorithm is “thinking” every tenth of a second instead of waiting three seconds before viewing the first “final” solution. Rendering the geometry in real-time might cost a few milliseconds, but we’re ok with waiting 3.1 seconds and witness the work instead of waiting 3 seconds and only see the “final solution”.
Speed over accuracy. When generating multi-objective solutions, it’s better to reduce the time it takes to run the algorithm instead of trying to make sure that the metrics are optimal and that the constraints are accurate. This tradeoff played a significant role in the metaheuristic solver algorithm. With fast solution generation, the designer can curtail and carve a better path to get an optimal solution, by making quick decisions that rapidly change the output. The inaccuracy gap is then filled by the designer.
Simplicity over extensiveness. Using the app should be as simple as drawing a wall. It should be simple to get a design generated without needing to change how the generative engine functions. The “under the hood” functions need to be optimized for good performance, so that users do not need to know how to change the settings, and therefore not need to expose these settings.
Specific over general. The generative problem to solve is well defined. The app does not need to solve all the problems, as this general approach can negatively impact performance. There is a fractalization effect of breaking larger problems into sub-problems, and those modular sub-problems are optimized for high performance. When combining these “sub-problems”, workflows can be composed for extending the scope of automation. For example, the duct generator addin developed with Henderson Engineers solves the VAV box to air terminal connections in a well defined and encapsulated way; it does not solve the entire RTU to placing the air terminals in one go. These solutions are sub-divided and could be combined in the future.
Henderson Engineers & EvolveLAB Partnership on Modular Duct Generator Tool
Why These tradeoffs?
Changing behaviors is Hard!
Some might remember the challenging transition from AutoCAD to Revit. New concepts had to be learned while previous concepts were left behind. A CAD user would pose questions and challenge this demand for the change in behavior:
I need levels now?
Why is it called a family? It’s a block!
Where are my Layers?!
I miss being able to draw anything anywhere.
Ref: https://accelerate.uofuhealth.utah.edu/resilience/why-is-behavior-change-so-hard
The tradeoffs described aim to reduce the need for changing behaviors and extend the already learned behaviors. For example, if the click order is click, release, then click again and release to draw a wall in Revit, we will not introduce a new click-and-drag for drawing a line based element. There is an existing behavior learned in Revit, so we reuse that behavior.
Since the application is a Revit addin, it’s safe to assume that the designer is well versed in Revit. We can then reuse and extend these behaviors. Since the generated results are streamed directly to Revit, we do not need to design a 3d navigation system, or a view browser feature. We can use the same style of shortcuts that Revit uses, and the same click release order patterns.
EvolveLAB Morphis Revit Addin
What Can These Tradeoffs Offer?
These application design and tradeoffs build trust, foster user adoption, and allows for dynamic scaling of generative solutions.
Build trust with the designers using these co-authoring features:
Visualize feedback – Always show what the engine is “thinking” when it’s “thinking”
Minimize response time – Low latency shows the designer how changes in inputs affect the generated output instantly. The immediately generated output might be way off, and it might take a few seconds for the design to settle, but showing what is changing and what is not changing allows the designer to create the correlation between inputs and outputs.
React to user changes – When the designer moves the cursor, presses a button, or moves a correlated Revit element, these inputs and updates need to be reactive to further reinforce how these changes steer the generating algorithm in a different direction.
Metaheuristic algorithm – The generative metaheuristic algorithm is optimized for speed which yields quick results and it allows for showing work-in-progress solutions as it’s trying to solve the problem.
Predictable – Users expect a level of predictability even when generating unpredictable results. A generative application should not solely aim to generate solutions that are novel. There are many multi-variant and multi-domain problems that can benefit from solution automation as they would take up a lot of time to resolve manually. The other aspect to predictability, is knowing which kind of conditions the generator will solve successfully, where it could introduce novelty, and which conditions are too difficult for the current algorithm to solve. This predictability builds user trust in the application.
Workable output – The generated solution bakes to native Revit elements that are properly modeled and connected. This approach allows partial solutions to be acceptable as the user can make any minor changes to the baked Revit geometry in the same way it would have been done without the application.
EvolveLAB Morphis Revit Addin Users gaining trust in the application fosters adoption:
Trust breeds adoption – Trusting the application and its automation leads to sharing the good news with other team members
Rewarding to use the app – App actually works by solving a pragmatic problem automatically, allowing designers to complete tasks faster
It’s fun and feels good – The interactivity makes it fun to use the app. Automatically generating all that Revit content with just a few clicks feels really good!
Measure Adoption – do not only take the users’ word for it; measure adoption with analytics and confirm whether the predictions hold. Draw conclusions from the data and interpret the data with the user feedback. This way we can extract whether non-power users are using the app, and whether the app is used on actual project, not sandbox test projects.
Dynamically scale the application as the needs evolve:
Local versus global GD scope – Scale the solution by starting locally and expand towards the larger problem in a modular way.
Don’t ignore the power users – Designing the app for the majority of users, but provide a path for those users to become power users.
EvolveLAB Morphis Revit Addin The co-authoring and GD approach ultimately help with automating pragmatic solutions in a way that fosters user trust and adoption across the team. Co-authoring democratizes generative design by lowering the barrier for entry. Automating one thing across many users is better than automating many things restricted to one user.
About The Authors:
Ben Guler is Partner + CTO at EvolveLAB. As a design technology fanatic, Ben has been a vital driver for computational design, process management, and standardization. With a gamut of technological avenues at his disposal, he has successfully identified and executed appropriate solutions for a robust set of project deliveries. His architectural background, knowledge of BIM platforms and software engineering allows for a technological bridge that is critical to being effective in the computational design paradigm.
Bill Allen is President of EvolveLAB, Disrupt Repeat, and On Point Scans. These firms synergistically help Architects, Engineers, and Contractors optimize the built environment. He has over 15 years of experience managing technology for buildings in the AEC industry for cutting edge firms. Bill Allen has been a keynote speaker as well as featured speaker at multiple events, and has the most watched Autodesk University talk ever "The Future of BIM is NOT BIM, And It's Coming Faster Than You Think".