AI in Generative Design – a closer look!

Generative Design

AI in Generative Design – a closer look!

This Story is part of a series.

  • Vincenz Marschall
    Vincenz Marschall Design Engineer, designaffairs

There is a popular, if somewhat misguided, view that artificial intelligence (AI) technology is coming to take our jobs; that the rise of AI and machine learning will soon render us humans obsolete in the workplace. I don’t really agree with this rather fanciful notion, but the COVID-19 pandemic has made me think a little bit more about such doomsday scenarios.

In this article – the first in a series of two – I want to take a closer look at AI as it applies in the field of Generative Design, with a view to hopefully dispelling the premise that it somehow means the end of humankind as we know it.

Let’s start with the basics. Generative Design (GD) describes a process whereby a computer designs a specific product component, while using AI to take account of multiple influencing factors simultaneously. As a creative mechanical engineer in our product-design team, this actually sounds a lot like what I do in my daily work designing technical structures and components.

To illustrate a simple example of GD in action, I present to you the humble pillar, that ancient symbol of the rise of civilization. A pillar exclusively bears a uni-directional load, e.g. the weight of a roof. Hence the original pillar (below, left) looks very familiar and straightforward to us, whereas the GD version of a pillar (below, right) shows an unexpected and rather strange three-legged capital and base design.

Ancient pillar (left) and GD pillar (right).
Ancient pillar (left) and GD pillar (right).

Why the difference?

The classic approach: specification, drafting, validation

Firstly, let me explain the classic engineering approach employing natural intelligence (as opposed to artificial intelligence). When looking to devise an engineering solution, we analyze the problem and define the minimum requirements we need to provide a viable outcome. We call this ‘specification’. Then we outline various plausible solutions, which we call ‘drafting’. Finally, we test our draft to see if the proof works in practice. We call this ‘validation’.

Validation failures set us back to the drafting stage. Some people (negatively) call this back and forth process ‘trial-and-error’, but we actually have tools that help us pick the best draft. We can deploy heuristics, i.e. looking for solutions in similar situations, and simulation, i.e. calculating a greatly simplified model of our solution design. That said, we tend to be naturally prone to choosing the ‘we-have-always-done-it-like-this’ solution, instead of exploring new ideas and new approaches.

Improving drafting and validation via simulation

Simulation sets out to forecast a draft’s behavior by stressing a simplified model in a virtual environment. This approach generates vast amounts of calculations, which we handed over to computers a long time ago. Today, the ever-increasing processing power of computers allows for more complex and more realistic models and results. Therefore, simulation helps us to bridge the gap between what might look promising during drafting and what turns out to actually work during validation. It also provides a viable alternative to expensive physical prototypes. Nevertheless, simulation on its own still only allows us to submit drafts based on our own experience and our own – sometimes limited – imagination.

GD versus simulation

GD builds on simulation and leverages the greater processing power of cloud computers to generate its own drafts and simulations, changing little bits here and there, simulating again, always improving. After completing multiple iterations, only the most viable working solutions are left. In this way, results can be generated faster, more cheaply and, in many ways, better than what I would have come up with if I only had access to simulation. In short, GD refuses to be limited by our human experience or imagination.

Topology optimizationanswering the pillar question

To return to my pillar example, let me take the popular game of Jenga. Jenga is a great example of topology optimization. Leveraging GD to find the best solution, the computer discards unnecessary material (i.e. blocks) from a predefined building volume (the Jenga tower) by removing areas of low stress (the loose blocks).

In order to determine the level of stress, the computer quickly simulates a behavioral scenario for each individual block.

By contrast, we humans would probably look for a low-risk center block or try to move a block to see if the tower starts to show signs of collapse (the heuristic approach). Following this logic, the GD-generated pillar thus features a three-legged design.

Another good example is the brace (picture below left), which is exposed to more complex loads than the pillar. We then leverage topology optimization to strip it down to the final design on the right.

Traditional brace (left), excess material removed by topology optimization (right).
Traditional brace (left), excess material removed by topology optimization (right).

GD’s ability to grow along multiple dimensions

Instead of just eliminating the unnecessary, true GD grows structures into empty spaces, literally making it a creative process. In doing so, it considers several influencing factors at the same time, which is very hard for us humans to do. For example, GD today can already optimize a design along three dimensions at once: lower weight, greater stiffness and suitability for milling . In the traditional design process, we tend to consider factors consecutively (as opposed to simultaneously) as we work to deliver a balanced design. However, by handing over decisions to GD software, we exchange time for control and effectively create what I like to call the Google dilemma situation: did we arrive at the best result or the only one?

Limitations of GD

As children, my little brother and I spent years stacking toy blocks. However, we built much more than pillars or towers: we created scenery for our imaginary stories. Generative Design is only able to optimize along predefined dimensions. As of now, these dimensions revolve around hard engineering categories: stresses, deformations, physical material properties, etc. It will not come up with tasteful or pleasing designs – at least not intentionally. Certainly, GD can create results that look appealing. For example, the architect and programmer, Michael Hansmeyer, exhibited Subdivided Columns during the 2011 Gwangju Design Biennale. Hansmeyer curated the most appealing ones from an array of (randomly) computer-generated columns. In order for GD to take over the task of curation, we need to be able to define the dimension ‘appealing’. Besides the philosophical discussion around handing over to the machine, how does this change the way we give it input?

Michael Hansmeyer - Subdivided column, 2010
Michael Hansmeyer - Subdivided column, 2010

Michael Hansmeyer’s Subdivided Columns.

The change in human input 

In the short term, we can pick the most appealing result from the myriad solutions presented by the machine, or we can wrap the result in an emotional envelope. However, in the long run, this island of undefined dimensions will be submerged. Active human participation in drafting and validation will shift towards improving existing algorithms or changing them along new dimensions. At designaffairs, we have developed a pretty cool tool called SimuPro, which uses psychological research findings to quantify the emotional dimension of a product or brand. The data classification model behind SimuPro could develop into an algorithm along the emotional dimensions. That way the machine itself can become the curator providing designs that fit the brand style and are considered aesthetic.

Human-machine collaboration

The idea of voracious AI technology enslaving humankind is a little over dramatic. We should instead look at GD as a result of a society based on the division of labor. Maybe it’s just a semi-finished product, like a large block of quarried stone that hasn’t yet been fashioned into the pillar of a Roman basilica.

It can only fulfil its purpose in the context of interdisciplinary collaboration. What if the quarryman, the mason or the architect is a computer scientist, engineer or GD designer? GD can undoubtedly be an efficient and powerful tool – but only if we trust each other and work together. After all, we designers are all in the same boat, looking to produce solutions that will unburden our fellow humans from their daily struggles.

In the second part of this article, I focus on how we at designaffairs are embracing GD to improve people’s daily lives. Please click here to read it.

The people behind our thoughts

Saved to Reading List

Navigation Portal

Navigate through our stories by selecting the appropriate tags:

Reading List

Your selection of stories:

Your Reading List looks a bit empty – feel free to add some stories!

My Reading List

Your personal history and selection of stories.  You can share this list via the following link:

Your Reading List looks a bit empty – feel free to add some stories!


Explore beyond your boundaries!

Error 404

Sorry, but we couldn’t find what you’re looking for. Maybe try one of these stories instead?

Saved to your Reading List
Removed from your Reading List
Link copied to clipboard