Hands-on with Project Rediscover: Generatively Designing the Autodesk Toronto Office
By Kean Walmsley for Autodesk University
Project Discover was the original project that launched Autodesk’s work around generative design for AEC, leading to the creation of Project Refinery, an optimization engine for Dynamo. It involved the generative design of Autodesk’s new office in the MaRS district of Toronto, a showcase for using generative design for architectural layout. While this project pre-dated the latest Autodesk tools in this space, Autodesk Research embarked on Project Rediscover to go back and retrofit the original approach to work with Dynamo and Refinery. This article takes a close look at the Project Rediscover graph, which is now publicly available for anyone to load inside Dynamo, and how people might use similar techniques to implement their own generative design workflows.
Generative Design
Generative design is a framework for combining digital computation and human creativity to achieve results that would not otherwise be possible. It involves the integration of a rule-based geometric system, a series of measurable goals, and a system for automatically generating, evaluating, and evolving a very large number of design options.
This approach offers many benefits for designing buildings and cities — including managing complexity, optimizing for specific criteria, incorporating a large amount of input from past projects and current requests, navigating trade-offs based on real data, structuring discussion among stake-holders about design features and project objectives, offering transparency about project assumptions, and offering a “live model” for post-occupancy adaptation. The framework consists of three main components: 1. generate a wide design space of possible solutions through a bespoke geometry system; 2. evaluate each solution through measurable goals; 3. evolve generations of designs through evolutionary computation.
Generative design is a flexible and scalable framework. It can be applied to a wide range of design problems and scales, from industrial components all the way to buildings and cities.
Autodesk MaRS Office: Generative Design for Architecture
Architecture can often become a more challenging problem than engineering. In fact, architecture, unlike engineering projects, involves qualitative aspects of the experience of space that are less tangible and more difficult to measure. In 2017 The Living pushed the boundaries of generative design and applied this framework to architecture for the design of the new Autodesk offices in the MaRS Discovery District in Toronto.
The geometric system incorporated several levels of constraints including the size of the space, the number of amenities and meeting rooms and fixed locations for cores and mechanical rooms. The goals combined qualitative aspects of human experience (such as ‘workstyle preferences’ and ‘adjacency preferences’) with quantitative measures (such as ‘daylight’, ‘buzz’ and ‘productivity’). The process allowed the designers to go beyond the one-size-fits-all type of approach to workspace design and offer a space that was diverse and rich in features. Through ongoing monitoring of the space and survey-based data collection, generative design can be used to suggest new design options and the scoring algorithms can be improved.
Related: Generative Design for Architectural Space Planning with Danil Nagy and Lorenzo Villaggi
Project Rediscover
The original MaRS project was code-named “Project Discover”, which goes some way to describe the sense of exploration: this was about discovering whether generative design could be applied in practice at the architectural scale.
Given the fact this was research — and that our tools didn’t have the capability to be used directly to solve this kind of problem, at the time — The Living went ahead and used other tools to solve the problem, including a significant amount of their own custom-built code. While this research was clearly very valuable, it was also important for Autodesk customers to be able to get access to examples showing a comparable workflow using Autodesk tools.
Hence Project Rediscover began, essentially to rebuild the workflow used for the MaRS project within Dynamo and Refinery. There were some functionality gaps that needed filling for this to happen — which led to the creation of the Space Analysis package — but overall we found it was possible to create a graph in Dynamo that worked similarly to the implementation made in Project Discover.
The first version of this graph was released at AU London 2019. At that time it was functional, but we hadn’t yet had the opportunity to fully document what amounted to a highly complex workflow. This article attempts to rectify that situation by examining the logic of the graph, step-by-step, and giving people more context as to what was implemented — and why — which should make it easier to apply similar approaches to other problems.
The Geometry System
The main constraint that defines the geometry system is the outline of the floor area, along with a definition of the window locations. For the purposes of this graph, this information has been hardcoded in a series of points that define a boundary, but it could equally have been implemented by loading this information from Revit or from an external file.
The next step is to define some areas that would be used for the generative design process. In this case we have a rectangular area at the top and an L-shaped area on the left and at the bottom. These are, once again, hardcoded in the graph.
Once we have these “GD regions” defined, we split them with a centerline to define axes for the division into neighborhoods.
All of these items are considered constant for the purposes of the optimization: they don’t change from run to run. There is some potential to cache their results using the Data. Remember node, although the recalculation cost isn’t very high, relative to the analyses performed later in the process.
The next step is to calculate the approximate center points for neighborhoods, specified by parameters along the region spines. This is the first item in the process that will vary based on input parameters (in this case the 8 parameters “nbr1 — spine” to “nbr8 — spine”).
These approximate centers are then moved slightly in a perpendicular direction away from their spine. The amount is controlled once again by input parameters (the 8 parameters “nbr1 — perp spine” to “nbr8 — perp spine”).
At this stage we have no need for the approximate points or the spines, so we’ll turn them off.
We’re now going to create a simple Voronoi partition of the space based on these neighborhood centers.
This splits the space into the neighborhoods. We can now ignore the centers, so let’s turn these off from here on.
We can clip the Voronoi partition using the boundary geometry to get our neighborhoods.
Next we’re going to divide each neighborhood with a line that’s a fixed distance from one of the edges. The specific edge that’s chosen is controlled by our last set of input parameters (the 8 parameters “nbr1 — am side” to “nbr8 — am side”). There’s a little more complexity than you might expect in this part of the process, mainly because we want to ignore short edges and make sure the line is placed in the right direction.
At this stage we can place the amenity areas. First we define the boundary curves by offsetting inwards.
These specify the amenity areas.
We then place the entrances to the amenity areas. These are currently specified as always being centrally located on the side of the line used to split the neighborhood.
Next comes the placement of desks in the remaining space. Desks are placed in double rows, with some logic to avoid columns, etc.
We can now remove the lines that split the neighborhoods, to get our final layout.
The Evaluation System
Based on the 24 input parameters — that define eight neighborhoods in the specified area — the geometry system in our Dynamo graph is able to generate thousands (or perhaps millions) of different layouts for our office, effectively defining the solution space.
The job of the evaluation system — which includes a series of metrics — is to provide a set of scores for each design that can be used to search the space and zero in on “optimal” solutions. With any sufficiently complex system with competing objectives, we’ll inevitably see trade-offs between different metrics. A big part of any generative design system is an environment that allows the designer to explore these trade-offs and identify which solutions are of most interest to them.
There are different search strategies for any complex solution space. Refinery allows us to perform random searches, cross (or Cartesian) product searches — which are comparable with optioneering studies — and a more targeted search using a genetic algorithm: what we refer to as an optimization study.
An important point to consider when defining your evaluation system is that optimization can only be effective if it has some continuity along each of the various metrics. It’s also important to make sure that small changes in input parameters generally result in small changes in the output parameters: otherwise the process is going to struggle.
Much like the original MaRS project, Project Rediscover has six different metrics that evaluate each design. Here are the metrics from the original Project Discover paper:
Want more? Download the full class handout to read on.
Kean Walmsley is a platform architect and evangelist working for Autodesk Research. He blogs and tweets about developing with Forge, AutoCAD, and other Autodesk technology, especially with respect to IoT, generative design, VR, and AR.
