From Prototype to Platform: Delivering New Design Capabilities on Autodesk Forma

PRESENTER: Hi, everyone. Welcome to our session From Prototype to Platform, Delivering New Design Capabilities on Autodesk Forma, presented by Lorenzo Villaggi and Dale Zhao from AEC Industry Futures at Autodesk Research. This session is based on a case study from Project Phoenix, a housing development project in collaboration with our customer, Factory_OS.

In the context of Project Phoenix, we will cover how we implement the software prototype for an innovative modular building design technique. To make the prototype accessible through a workflow based on Autodesk technologies that our customers are already using and familiar with, we will talk about how we integrate our prototype for modular building design with Forma, an Autodesk platform. We will also share our learnings from iterating the development of the prototype on a platform with our customer. And finally, we will summarize the takeaways from this case study and how they can be helpful for others who are developing software prototypes and planning to bring them to an Autodesk platform.

First, we'll give an overview of Project Phoenix which provides the background for the subject of the case study in this session. Project Phoenix is a 300-unit housing development that aims to address the housing crisis and demonstrate our net zero future. Project Phoenix is done in partnership with our customer, Factory_OS, a leading volumetric modular housing construction company based in California. Factory_OS combined pioneering technology with tried-and-true manufacturing methods to build multi-family modular buildings more efficiently and at a lower cost.

At Factory_OS, residential units are built as volumetric modules in an offsite construction factory. The volumetric modules are then transported to construction sites using trucks, lifted and stacked using cranes, and assembled into buildings with the utilities connected and a facade installed. With the modular building technologies from Factory_OS, Project Phoenix will be built on this empty lot in West Oakland, across the bay from San Francisco.

This is the current condition of the project site, a barren field where there used to be a steel factory squeezed between a highway and a residential neighborhood. The site has begun construction. Eventually, it will be transformed into a sustainable and habitable residential development that includes 300 affordable housing units. The research and the workflows developed for this project on this site will be generalized and applicable to other locations in the future as well.

To achieve the desired outcome of Project Phoenix, we need a way to navigate the trade-offs between a number of design metrics in different domains. On a total carbon side, we need to consider embodied carbon, operational carbon, landscape sequestration, and facade sequestration. On a habitability side, we need to think from the perspectives of the neighborhood, the site, and the units. Finally, on the cost side, we are balancing construction costs and net operating income.

To tackle the complexity arising from the trade-offs between these many different metrics, we utilize a generative design workflow. A generative design workflow involves three interdependent steps in a loop. Generate, Evaluate, and Evolve.

With generative design, first, we need to create the parametric model consisting of computational logic authored by a designer. It picks a set of inputs, such as geometric parameters, and projects specific settings, and generates a design with corresponding outputs, such as geometries and metadata. But initial inputs can be directly specified by the designer, or provided using some more systematic approach known as design of experiments. The generative design is then evaluated for metrics, which are often calculated by running simulations such as solar analysis and structural analysis, or by computing statistics such as floor area ratio or counting objects.

The next step is to evolve. Guided by metrics evaluated on generative designs and driven by an optimization module, the evolution process starts to explore the design space and learns to navigate in the directions that lead to increasingly high-performance designs. To close the loop, in the high-performing part of the design space identified through evolution, new and further improved designs are generated with iterated inputs.

Next, we will focus on the specific design model developed in Project Phoenix. This image shows one example of the countless designs that can be created using the generative design model in Project Phoenix. There are four main components in the design model, each responsible for part of the design. Midrise massing, townhouses, landscape, and facade.

Here on the left side are some of the inputs taken by the four components in the design model. Some inputs are variables, meaning they can be changed for each design. For instance, the townhouse starting locations and orientation settings can be different in each design, leading to a variety of siting layouts. Other inputs are constants, and they remain the same for the entire run of the generative design workflow. But they can be changed in different rounds. For instance, all the designs from a single run will share the same tree species and use the same unit catalog.

On the right side, the outputs from the design model reflect metrics in total carbon availability and cost, where the trade-offs have to be made through evolution, as discussed in earlier slides. As the loop of generation, evolution, and evolution continues, we will get a large number of design options from the design space with increasingly desired metrics over time. They're considered high-performing, but with trade-offs to be made between certain metrics.

With this many design options, how do we narrow down the designs of interest and identify one or a few to move on to the next stage of design process? For these purposes, we develop an interactive visualization tool for design exploration. Here, each point in the plot represents a design generated. Its various properties are encoded using different channels.

For instance, its x-coordinate encodes the landscape carbon sequestration. The y-coordinate is for unit habitability. The color is for embodied carbon. And the size of the point is for unit virulence.

Zooming and panning are supported to examine design subspace of interest. As before, additional properties, such as metadata from optimization, and a thumbnail of the design corresponding to a point, can be displayed. And the channels can be changed dynamically to visualize and compare other aspects of the designs generated.

This is interactive. This interactive visualization proves to be an effective technique for navigating the design space, as well as the trade-offs discussed earlier. This concludes the overview of Project Phoenix, including our partnership with Factory_OS, the site information, the desired outcome of the housing development, and the generative design workflow we employed in this project.

In this section, we will focus on the research software prototype we developed for modular building design as part of Project Phoenix. Recap. This generative design model in Project Phoenix consists of four main components. The subject of this section is the midrise massing. Midrise massing has a great impact on the designs, and the techniques for creating it are generalizable beyond this project.

Based on the volumetric modular construction technology itself Factory_OS introduced in the previous section, the figure shows an example the midrise massing generated using our software research prototype, which implements tile-based and example-based modeling techniques. On a high level, it takes the units from the unit catalog designed by Factory_OS, and features learned from a set of design samples, to create new designs guided by additional parameters and constraints.

The inputs of this process are shown on the left side. As with other components in the generative design model, the midrise massing design is also evaluated for certain metrics related to the total carbon availability and cost, as shown on the right side. Next, we will describe a few main aspects of this prototype and explain the benefits of the modeling technique with implements.

First, we will look at the unit catalog, which provides the basic building blocks for midrise massing. These are some of the unit types from the prefab unit catalog designed by Factory_OS, including studio units, one bedroom units, and two bedroom units, et cetera. They were originally created as Revit models for efficient use in the tile-based modeling procedure. Our software prototype converted these Revit models into a format with essential metadata and geometries at the proper level of details. The mapping between the converted format and the original Revit models is maintained, so that when a massing design is generated, it can be converted to a Revit model with full details when needed at certain points in the design process.

Next, we will look at the design samples. As the name suggests, design samples are themselves also massing designs created from Factory_OS's unit catalog. They can be from previous projects by Factory_OS, or can be authored by designers to specifically express features desired in new designs. The modeling technique implemented in our research prototype would then analyze the design samples for features such as what is allowed and disallowed for certain types of units to be placed relative to one another, how these placements are affected by the form constraints of the massing, and how often certain placements would happen in new designs.

Now that we have covered the unit catalog and the design samples, we will look at how, with other inputs, they can be used to generate new massing designs. The design sample set needed by the prototype can be as small as a single design. Together with other inputs such as unit weights, which affect the frequencies of different unit types appearing, massing length, and break direction, which determine the overall form of the massing, massing pre-constraints, which can be used to directly specify desired unit, or units, at certain locations, et cetera, one or more designs can be generated, incorporating the features and constraints from the design sample.

The design samples can be changed as needed. Then, based on features extracted from the updated samples, new designs can be generated accordingly. The midrise massing design does not only produce geometries. With metadata from the unit catalog, metrics on total carbon availability, cost, and so on can be evaluated. Furthermore, as shown in this animation, the metrics can be evaluated rapidly whenever a new design is created. This supports the navigation of trade-offs between a variety of metrics such as embodied carbon, cost, Net Operating Income, or NOI, pro forma, unit count, et cetera.

So why did we build this software prototype for massing design? Shifting to a catalog-based, product-driven business model, Factory_OS wants to enable their customers to quickly configure valid building layouts. But the current methods using shared Revit families are prone to user errors that impact constructability.

Also, this often requires tedious rework of Revit models between their design partners and factory engineers. The prototype addresses the challenges by providing an intuitive experience for their customers to engage with their unit catalog, and rapidly creating validated designs that conform to requirements based on previous designs and additional inputs. With the generative design model and the workflow described earlier, they will be able to effectively explore the design space.

Focusing on the prototype alone helped us move fast in the early phase. We could rapidly experiment with ideas and make adjustments. As we made more progress on the prototype itself, we started thinking about leveraging capabilities from Autodesk platforms to support further development of the prototype, as well as bringing the outcome of the research to technologies that are accessible to our customer, Factory_OS. In this section, we will discuss how we transitioned from prototype to platform, and share the results we have by the time of this presentation.

The platform we integrated our prototype with is Autodesk Forma, a cloud-based platform for early-stage planning and design. Autodesk Forma helps planning and design teams deliver projects digitally from day 1 with its conceptual design capabilities, predictive analytics, and automations to make solid foundations for a design project. To learn more about Autodesk Forma, we would like to invite you to visit its homepage using the link on this page.

What makes it possible for us to move our prototype to Autodesk Forma is Forma API, currently in beta phase. Forma API allows the user to introduce their custom design capabilities into Forma in the form of extensions while leveraging the powerful features available from Forma. Currently, there are four ways to extend Forma, with different ways to access in the UI and targeting different functionality.

Embedded views, as the name suggests, allows embedding custom UI and run front end logic in JavaScript or WebAssembly. Generators allow integrating custom logic for creating geometries in a Forma proposal based on parameters provided by the user. Analysis takes the geometry and project data as inputs and returns information to guide the user's decision-making process. Finally, data providers provide contextual data to the project, such as property boundaries or terrain.

The massing design prototype developed for Project Phoenix is integrated into Forma as a generator. We are also experimenting with extension via embedded views. But in this session, we will talk more about the Forma generator.

Forma supports two types of generators, script-based and HTTP-based. Depending on scenarios, one may be more suitable than the other. A script-based generator runs directly in the browser, which means it is subject to the limitation of client-side runtime environments such as features and performance. It is suitable for highly responsible user interactions with instant rendering.

An HTTP-based generator, on the other hand, runs on a server of the developer's choice. Forma communicates with the generator using HTTP requests, hence the name. This means that the runtime environment of the generator can be very flexible.

There is a trade-off on performance, though. An HTTP-based generator is less responsive than a script-based generator due to the communication over network. But since it runs on a server side, it is possible to incorporate complex computation without impacting UI responsiveness.

The cool part of the software prototyping, Project Phoenix is integrated out into Forma as an HTTP-based generator. One reason is that, over time, the prototype has been developed primarily using Python and C#, which are more suitable for server-side deployment. Also, a powerful server environment allows us to add more computationally intensive logic in the future, such as evaluating a complex metric.

Now let's take a look at the Forma extension developed based on the massing design prototype in Project Phoenix. The prototype is wrapped into an HTTP-based Forma generator, which is essentially a server with HTTP endpoints as specified by Forma generator framework. The Revit unit catalog created by Factory_OS is first converted into a format that can be efficiently used by the massing design prototype, then hosted on a storage server. It is worth noting that both the Forma generator and the unit catalog are hosted on infrastructure of the extension developer's choice, as long as the generator can be accessed via HTTP. This can be, AWS, for instance, or even a localhost server for debugging during development.

Forma extension framework receives parameters, inputs from Forma UI and sends the parameters to Forma generator. The generator executes the modeling logic from the prototype internally and returns the model created back to the extension framework, which then asks the model to a Forma proposal so that it becomes part of the design. Now we'd like to share a demo of the current version of the Forma extension running on the actual site in West Oakland.

We select the generator named Factory_OS Tile-Based Modeling, set the display mode to Unit Type, and change the number of rows to 3, then draw a line that guides the footprint of the midrise building directly in the viewport. Firstly, a massing is generated based on the footprint guideline and other inputs. It uses the units from the catalog and design samples which are currently not shown in this version of the generator. The parameters remain connected to the design and can be changed.

Alternative display modes are available. For instance, we can color-code the units by carbon embodied based on data from the unit catalog, or similarly by net operating income switching back to Unit Type display mode. And we now change the random seed used by some stochastic process in the modeling logic to create alternative designs. The footprint guideline is still connected and interactable. So making adjustments will trigger the generation of the updated designs.

The design created by the extension works with multiple types of building analysis in Forma. Scenario analysis works on the massing, even with some floor geometries. And here is the daylight potential analysis on all the buildings on-site.

We are also able to run two modes of window analysis, Comfort mode and Direction mode. And here is the microclimate simulation at different times of year. Finally, the noise analysis based on the traffic data on the roads surrounding the project site. The extension has yet to support area analysis and operating energy simulation, which requires additional metadata on the design created.

Here is a demo of stress testing the Forma generator by creating a massing with a lot of units. Due to the use of geometry instancing, there is little impact on the performance. The Forma generator also supports showing floor plan views at a selected floor. This allows the user to verify the details of the massing and examine them in the context of the construction site.

It is worth noting that we are not developing the research prototype alone. Instead, we are iterating the development along with our customer, Factory_OS. In this section, we will briefly cover how Autodesk Forma as a platform helps us achieve this collaboration effectively.

To get our customer involved in more depth, we can deliver our evolving prototype in the form of Forma extension. With just the extension ID we shared, Factory_OS can easily install the Forma extension, which remains unpublished as a prototype, through whichever updated Forma projects that need this functionality. Factory_OS can then experiment with this Forma extension prototype from their own devices and provide feedback based on their hands-on experience.

We can then discuss the feedback together and respond by adding features, making improvements, fixing issues, and supplement future works. Updates will be pushed to the cloud infrastructure hosting the Forma extension. The new version will be instantly accessible by Factory_OS with no re-installation needed.

Streamlining the customer feedback and development iterations is one of the major benefits from delivering prototype over a platform. Delivering the prototype on Forma as a platform enables the user to perform Revit design iterations with essential information front-loaded in the process, which leads to greater predictability. Specifically, the essential information is extracted from the Revit unit catalog and turned into a format that can be used in early stages of the design process. The quick modeling capability is provided by the Forma extension based on our research prototype.

Another piece in the design build, Revit design analysis, comes from Forma's built-in analysis features. Such a workflow makes it possible for Factory_OS to achieve mass customization as they transition to a catalog-based, product-driven business model. Another area of the feedback from Factory_OS we need to focus on is the generalized usage of the Forma extension prototype in different contexts.

For instance, Factory_OS should be able to update the unit catalog as their business evolves, and the prototype should expect and handle such changes. Also, the modeling technique should be applicable to other sites that Factory_OS will work on in the future, which can be very different from the one in Project Phoenix. On top of this, the Forma extension needs to maintain the ability to quickly test-- for quickly testing out new design iterations in different contexts. By iterating with our customers through the delivery of an evolving prototype on a platform, and learning the changes required, the generalizability of technologies can be considered and supported from early on in the development process.

Finally, we would like to summarize what has been covered in this session into a few takeaways. In section Project Phoenix, we covered all challenges from Project Phoenix in collaboration with Factory_OS, guided the scope of research and the identification of an effective design workflow. In section A Prototype for Modular Building Design, we shared the what, how, and why of our software prototype for midrise massing design. Focusing on the prototype first helps us move fast in tackling core research problems. In section From Prototype to Platform, we demonstrated our Forma extension based on the prototype and how it leverages the capabilities from Forma and makes sure that research is integrated with Autodesk technologies that our customer uses. In section Iterating with Customer, we explained how delivering the prototype on the platform supports our efforts in iterating the research and development with our customer, which leads to better outcomes for both sides.

This concludes our session From Prototype to Platform, Delivering New Design Capabilities on Autodesk Forma. We hope the contents will be helpful for your current or future projects. Please feel free to reach out to us for any questions you may have regarding this session. Thank you for joining.