1. Introduction
The challenge for building designers is increasing as the act of balancing multiple requirements and needs imposed by clients and regulations on cost, space, esthetics, and sustainability becomes harder. Meeting these requirements and needs can require novel design solutions and expanding the design’s solution space beyond that of previous designs. This process can involve both exploration and exploitation, depending on the project situation and the capabilities of the design team. However, time and resource limitations can restrict the opportunities for exploration [
1].
In exploration, the interest lies in probing an extensive set of solutions to find interesting regions within a design’s solution space. When a region is identified it can be narrowed down to find the best solutions subject to a set of criteria. The act of creating these novel solutions can, however, be resource intensive. To facilitate a design process that ends up with strong design alternatives, an efficient generation and representation of a wide range of feasible solutions is needed [
2]. One avenue that has received research attention within this area is the application of optimization approaches to reach near-optimum solutions for building designs regarding cost, energy efficiency, or carbon emissions (e.g., [
3,
4,
5,
6]). The goal of optimization is to find an optimal solution (or a set of optimal solutions, often referred to as Pareto solutions, in the case of multi-objective optimization) to a design problem. The application of optimization thus weighs more heavily into exploitation rather than exploration, which means there is a likelihood of ending up in a solution similar to already-existing solutions. Application of methods like multi-objective optimization has previously shown its ability to offer solutions outperforming the initial designs of concrete problems, such as life-cycle energy reductions in building design [
7]. The application of optimization thus has great potential at the later stages of design, when the design requirements are more defined.
Previous research has, however, pointed out a need to also support the exploration aspect in the earlier stages of design through generative design approaches (e.g., [
2,
8,
9]). Generative design is a term used to describe a wide range of methods with the aim of assisting product designers by using computational capabilities to generate feasible solutions and one of generative design’s primary objectives being the ability to explore larger solution spaces [
8]. The goal of generative design is to provide novel findings, rather than revealing what is already known, thus expanding designers’ reference frames. Despite its heavy emphasis on utilizing computational capabilities, and in contrast to fully autonomous methods, generative design is described as using computers as a ‘collaborative partner’ [
10]. Its usefulness is argued to be primarily found during the conceptual stages of design, where the design is still under formulation [
2]. With these underlying characteristics, generative design is in this work defined as the use of computer-based methods in interactions with designers to generate feasible solutions that facilitate exploration of a design’s solution space with the goal of finding novel solutions.
There are multiple ways that a generative design approach can be realized. For example, Singh and Gu [
8] presented a review of five generative design techniques (L-systems, cellular automata, genetic algorithms, swarm intelligence, and shape grammars). They identified potential uses of each technique given a design problem’s characteristics and highlighted each technique’s benefits and challenges. Based on their study, they argued that no technique could match all design problems’ needs, and that those needs might change during the process itself. It was, therefore, suggested that a generative design system needs to be flexible and provide agency to its user to select techniques used both initially but also progressively during a generative design process. Given this, generative design has a large scope of potential implementations and applications. Several frameworks, methods, and tools have been presented within the generative design research of which a set of relevant research publications are herein discussed. First, an example from the manufacturing industry is mentioned, followed by a structural engineering example, then several architectural examples are presented.
In a study by Krish [
2], the outline for a generative design method driven by a history-based parametric CAD-system and a random sampling technique to generate design alternatives was suggested. This method was then exemplified using a consumer product (an MP3 player). From their comparison with genetic algorithms, they argued that the use of a random sampling-based generative design approach is more suitable for conceptual design problems because of its ease of use, ability to use non-quantifiable criteria (e.g., aesthetics), and problem maturity. Shea et al. [
10] presented a study where they integrated a structural design system (called eifForm) with a modeling system (called Generative Components) to enable exploration of design alternatives in a performance-driven generative design process. Their study provided a practical example for the application of generative design on structural components and highlighted the importance of understanding how geometric relationships and modifications affect generative methods.
Nagy et al. [
11] described a workflow for generative design applied to architectural indoor space planning, where six performance metrics (adjacency preference, work style preference, buzz, productivity, daylight, views to outside) were subjected to a multi-objective genetic algorithm to generate design alternatives. Although their findings were encouraging, they described a need for more flexibility in their methods so that additional parameters could be exposed and controlled by multi-objective genetic algorithms. They also highlighted that the output from a generative design workflow should not be thought of as final, but as a baseline from where further analysis and development is needed to finalize the design. Abrishami et al. [
12] integrated a generative system with a building information modeling (BIM) environment to support conceptual design in an architecture, engineering, and construction (AEC) context by providing techniques for design solution generation and exploration. Their proposed framework was also recently developed into a prototype (see [
13]), with an emphasis on embedding information into generated solutions. Their findings showed promising results in the approach’s ability to support creativity and process information. However, they suggested further studies to investigate a broader range of design settings. Another example of a BIM-based application is found in Salimzadeh et al. [
14], where they proposed a method that uses a BIM-based process to generate layouts for photovoltaic (PV) modules and calculate the generated solution’s performance. Their proposal leverages object data in BIM models such that surface-specific conditions can be incorporated in the generation of PV module layouts, showing how BIM data can be incorporated as input to a generative design approach. A related concept can be found in Hamidavi et al. [
15], where they investigated the link between architects and structural engineers by proposing an automatic generation and optimization of structural models based on input data gathered from architectural models. Their study provides valuable insights into the potential usage of a generative design approach by linking models from multiple disciplines and how constraints derived from traditionally labor-intensive tasks can be alleviated by performing automatic generation based on those links. Gerber and Lin [
9] combined parametric modeling with multi-objective optimization to support the generation and evaluation of building project scenarios using energy simulation and financial models. Their findings suggested that having a high degree of automation in the evaluation of solutions was beneficial to the users by offering users instant feedback on design alternatives, as they tended to focus more on multiple objectives simultaneously, rather than on one objective at a time. Nagy et al. [
16] sought to investigate the potential of generative design on an urban scale. In their study, they demonstrated the application of an optimization-based generative design process for residential neighborhood layouts in which optimization of profit and energy generation from solar panels was performed. They concluded that a generative design process has the potential to reveal insights on tradeoffs between design goals, and that those insights can lead to better-informed designs. They also highlight that generative design on an urban scale needs further research, including studies looking at the complexity of design at the urban scale through the inclusion of additional design metrics.
Research Gap, Aim, and Method
Despite the growth and increase in popularity of generative design approaches and the potential increasingly understood, the field has nevertheless been sparsely explored. Work in the field has been described by some as rudimentary [
2] or in its infancy [
12]. Few studies also exist within an architectural design context, whose implications can differ from those of other domains. The existing studies within architectural design present frameworks with accompanying prototypes. Some frameworks are more focused on genetic algorithms [
11,
16], energy performance [
9], prototype development [
13], or the design process [
12], for example. Therefore, there is a need for frameworks focusing on the general and technical workflow of the generative architectural design system. There is also a need for a better understanding of how the design’s solution space should be represented to enable different types of exploration (e.g., bottom-up and top-down [
8]). Thus, further studies are needed that explore the applications of generative design in the architectural design context, and that provide additional findings that contribute to the formation of the generative design knowledge domain.
The aim of this study is thus to investigate the potential use of generative design in an architectural design context. This is done by iteratively developing a framework together with a functioning prototype that is eventually demonstrated in a case study to evaluate its applicability in a case of designing a residential block. The research design was based on a methodology from design science research by Peffers et al. [
17], where a problem drives a cycle of objectives (development, demonstration, and evaluation) from which suggestions are communicated by evaluating and reflecting on the results against the existing theory (see
Figure 1).
The iterative development of a framework and prototype was deemed suitable, as it allows for insights that are gathered during testing and demonstration to be piped back to the framework to improve its design. Furthermore, a case study approach was used for its potential in examining a phenomenon in a natural setting [
18], thus enabling the evaluation of the developed framework. Collectively, the exploratory approach of using a case coupled with the design and development of a framework and prototypes was chosen as the research design.
Three primary activities were iterated during the research process: framework development, prototype development, and case demonstration. The framework development was the initial activity, where abstraction of a system was described based on previous knowledge gathered from previous research and the authors’ own experiences. The use of previous research helped in the design and development of the framework by contributing existing theories (e.g., regarding the selection of generative methods [
8] or system architecture [
19]) to the framework’s formulation. The framework provided an outline of the generative design process, which in the subsequent activity was developed into a functioning prototype. The role of the prototype was to provide a platform from where a demonstration of the framework could be performed, and to assist in identifying potential obstacles in its technical implementation. The third activity dealt with demonstrating the use of the developed framework and prototype in a case study. When subject to a problem in a real-world context, knowledge and experiences can be gathered and used to refine and provide meaningful insights for the further development of the methods under investigation. These three activities were iterated throughout the research process, where knowledge gathered was used to revise and further refine the developed framework and prototype. The framework is described in
Section 2, and the prototype and case study are described in
Section 3.
2. Generative Design Framework
The study in this paper first set out to develop a framework for generative design that could later be applied to the residential block case. The developed framework supports the application of a generator to derive solution sets for a design problem bound by a solution space. Relevant models are created for each solution in the solution set, and evaluations are executed on those models to derive metrics that describe each solution. This serves as input to the exploration approach where solutions and their metrics are presented and subjected to preference management, and the filtering and selection of interesting solutions either result in a final set of feasible solutions or as input for a solution space modification in an exploration loop.
Figure 2 shows an overview of the framework, and the following sections describe it in more detail.
2.1. Solution Space
The solution space is the first point of contact in our framework. A solution space provides the boundaries, or what Krish [
2] calls the ‘performance envelopes’ within which feasible solutions exist. The term feasible solution here refers to a solution that lies within the boundaries of the solution space and fulfills all defined constraints. Thus, a feasible solution is one that could be chosen as the final solution of a generative design process. The solution space is there to capture design logic that is defined before the actual generation process, a technique also used in parametric modeling to facilitate rapid changes and design exploration through manipulation [
10]. The objective of the solution space is to narrow down the pool of alternative solutions, with the goal being to provide the exploration with a meaningful set of feasible solutions. By iteratively modifying the solution space, the exploration can progress towards a direction that provides an increasingly meaningful set of feasible solutions.
The solution space is defined by its three components: the product definition, design variables, and constraints. At the base of the solution space is the product definition. The term ‘product’ is here used as a term to define the entity that is subject to the generative design approach. The product can represent the results of an entire construction project or a subsection of it. A product can, for example, be a load-bearing component, floor plan, building (or sections of it), building site (with one or more buildings), or a city block. The product definition is there to describe the overall product (e.g., through a geometric model) for the design variables and constraints to interact with and to define constants and rules that apply in the generation of a feasible solution.
To establish a set of alternatives to explore, design variables are used to define variations in the solutions. Each design variable describes either a continuous range of values bound by lower and upper limits, or a discrete set of values. Design variables can affect both the physical representation (e.g., dimensions) of a product but also its properties (e.g., thermal properties through material selection). Examples of design variables include the length and width of a building, the slope of a roof, the thickness of a slab, material selection in a wall, and so on. By changing the design variables different solutions can be created, and it is these design variables that the generator will choose from in order to generate the solution set for the current iteration. Through design variables, boundaries are set for what constitutes a feasible solution; however, it is not always achievable to express these boundaries solely using the design variables. As a complement, constraints can define additional boundaries to the solution space. Examples of constraints include the total habitable floor area for a building that can vary its footprint and number of floors, or the total thickness of a wall when each layer’s thickness in a wall can be varied individually. Furthermore, constraints can be used to define the boundaries of a solution’s metrics to, for example, meet regulations regarding energy consumption.
Each design variable and each constraint that is used defines a boundary for the solution space, and the final solution space is the areas where each of the boundaries overlap. Because of the inherent effects of defining design variables and constraints on the solution space, careful consideration should be given to their choices, as they can affect the selection of generation methods [
8] and the outcome of the generative design process. Similar to parametric modeling, by carefully choosing design variables for an exploration, a more accurate solution space can be defined that is expected to lead to more meaningful conclusions [
20].
2.2. Solution Set and Generator
In order to meet generative design’s primary objective of exploring extensive solution spaces [
8] and discovering novel solutions [
10], there need to be systems in place that enable the generation of solutions. Thus, the generator is at the core of the generative design approach—it provides the ‘generative’ aspect of generative design. The output of the generator is a set of feasible solutions that are available for exploration.
Here, we define the generator as a method that can generate solutions based on the definitions and boundaries of the solution space, with its goal being to autonomously generate a set of solutions. There are multiple different methods that can be chosen for implementing the generator (e.g., see [
8]). A commonly leveraged method found in previous research on generative design is one based on genetic algorithms (e.g., [
9,
11,
16]). A genetic algorithm approach is driven by a set of biologically inspired processes (e.g., mutation, crossover, and selection), where each solution is evaluated by a fitness function (a function that numerically depicts the performance of a solution based on a given problem’s objectives). In each iteration of a genetic algorithm approach, the biologically inspired processes are used to generate a solution set (called a ‘population’) that with each iteration increasingly improves the fitness of its solutions. Given the focus of genetic algorithms on minimizing or maximizing different objectives (e.g., minimizing cost), genetic algorithms’ presence is typically seen in optimization problems, and has been shown to have potential for design problems with distinct and measurable objectives (e.g., [
21]).
Despite the existence of various intelligent and advanced methods (e.g., genetic algorithms), it can also be argued that some of the methods pose a hindrance because of knowledge requirements, implementation difficulties, or time-constraints—all factors that should also be taken into consideration. For example, setting up variables and objectives is a crucial activity in genetic algorithms that can require substantial skills and knowledge [
2,
8]. As such, simpler methods like random sampling can offer a suitable approach for conceptual design problems that are focused on exploration [
2]. A random sampling approach typically relies on pseudo-random number generators to generate solution sets by selecting solutions within the solution space at random locations. Using random sampling poses few restrictions on a problem’s maturity and criteria, as random sampling is not driven by well-defined measurable objectives and is arguably easier to set up and use (in contrast to genetic algorithms, for example). This also means that the responsibility of guiding the exploration’s direction is up to the user (in contrast to, for example, genetic algorithms), which can facilitate the inclusion of qualitative assessments of solutions (e.g., esthetics).
As Singh and Gu [
8] also concluded in their study, each method has its benefits and drawbacks, and the method chosen should be based on problem characteristics and objectives. The framework that was developed for this study is focused on supporting those generator methods that interact with an independently defined solution space (i.e., the solution space is not necessarily tightly integrated with the generator algorithm itself), and areas where solution metrics are derived for each solution to support preference management. Thus, the framework is suitable for use of both genetic algorithms and random sampling.
2.3. Create Models and Evaluate Solutions
The generated solutions (i.e., the solution set), together with the product definition, design variables, and constraints, only provide a general representation of a solution. To facilitate a user exploration of solutions, each solution needs to be passed through a set of evaluations that are used to derive metrics for each solution. A metric is a measurable attribute of a solution and is chosen based on the design problem and its objectives. For example, a metric can be the energy performance of a building, a building’s habitable area, or the weight of a component. By using multiple metrics, a diverse view on a solution can be presented, assisting the exploration stage with relevant data. This also enables a transition into the inclusion of more performance-driven aspects into the design process, a theme that is gaining more interest in architectural design [
22,
23].
The processing of evaluating solutions should be performed with a high level of automation to best facilitate the exploration of larger solution sets with multiple performance metrics [
9]. To support this, we build on a principle described by Sandberg et al. [
19], where a general representation is transformed into different models to enable evaluation. Each model contains the specific data needed for its purpose, and models are used to handle different representations of a solution so that it can be analyzed, evaluated, and visualized according to the requirements and objectives of the design problem and its metrics. Examples of models include models of energy simulations, quantity takeoffs, sunlight studies, and visualizations, among others. Depending on the model and what evaluation is required, the evaluation can include calculations, simulations, analyses, or other processes deemed necessary. The evaluations are an essential part of providing input to the exploration approach in the form of metrics and potential sources of visualization of each solution, as this are the information that will guide the generator methods’ and users’ decisions.
2.4. Exploration Approach
Following the model creation and solution evaluation in our generative design framework is the exploration approach itself. Because the generated solution set can be considerable in size, and in order to support users in the identification of potentially novel solutions, the generated solution set needs to be explored [
2,
10]. The objective of the exploration is to probe a set of solutions to identify interesting regions of solutions. The outcome should either be a solution or a set of solutions deemed satisfactory to end the generative design process, or a set of modifiers sent back to the solution space and generator to generate a new set of solutions. This consists of two stages: presentation and preference management.
In the presentation stage, the solutions and their metrics are presented to the user for their evaluation. Here, visualization plays an important role, as it allows for the transformation of data into, as described by Chien and Flemming [
24], “concrete objects that can be seen”. The visualization aspect is especially important in an architectural design context as it central to its practice [
25], and the representation of solutions should also be given consideration in a generative design approach. The role of the presentation is to swiftly and clearly relay relevant information to the users about each solution and its metrics in such a way that the users are assisted in making well-informed decisions. This entails a combination of 2D or 3D visualizations of a product’s geometry (e.g., through images, renderings, or models) and graphs and tables that describe the product’s attributes and properties.
After users have been given the presentation of each solution in the solution set, the next stage is to manage their preferences. This stage builds on the notion that generative design approaches should not be thought of as autonomous solutions, but rather as ’collaborative partners´ [
10]. In our generative design approach, some preferences are provided a priori at the definition of the solution space through design variables and constraints. However, as the direction of the exploration is partially dependent on what knowledge and experience a user receives [
26,
27], these preferences need to be modified accordingly. As such, the preference management here is responsible for collecting the progressive articulation of user preferences, so that the users can navigate the solution space by continuously modifying its composition [
2]. Combined, this means that there need to be support methods available that allow users to interactively explore the solutions through selection and filtering, to evaluate their fit to the current problem’s objectives, and to apply preferences that narrow down a solution space into smaller regions. This entire process, from solution space definition to exploration, is iterated until a satisfactory set of solutions is found and selected. That solution set can then be brought forward in the design process to be further developed into the final design of the product.
3. Demonstration of the Framework
3.1. Case Description
The case study performed in this study was a part of a larger research project that investigated aspects of sustainability in the development of new residential blocks. This study was a part of that project, with the purpose of studying novel methods that can support early design processes. The case in question for this study was of a residential block in Kiruna, in the northern part of Sweden (see
Figure 3).
The residential block is a part of the new city center in Kiruna that is being developed. Data and illustrations for the residential block were gathered from publicly available planning documents from the municipality for the area containing the block and surrounding areas.
The block is of a rectangle shape with the dimensions 62 m × 57 m. On all four sides of the block are roads that form the city’s infrastructure. Three sides of the block (south, east, and west) are adjacent to other building blocks in the area. The last side of the block (north) is adjacent to a large public park. The case study was performed together with a public property owner who was interested in developing the block with apartment buildings. The case was at a very early stage of development during the time of this study, and focus was still on conceptualization and potential ideas for the residential block.
3.2. Prototype
During the development of the framework, a prototype was iteratively developed for the case study to evaluate the use of generative design. The prototype consisted of three primary sections: one for defining the solution space and generating solution sets, one for creating models and evaluating them, and one for presenting the results and gathering preferences.
The first and last stages were both implemented using a set of custom scripts created by the authors in the programming language Python within a Jupyter Notebook environment. This choice was made as it allowed for a high degree of flexibility and ease of use regarding data management, presentation, and visualization, which was deemed helpful because of the exploratory nature of the study. Presentation of solutions was performed by linking data from the Python scripts to the three.js library for interactive 3D visualizations, and all graphs were created using the plotly library. Data from the Python scripts in the Jupyter Notebooks were sent using JavaScript Object Notation (JSON) files to the CAD software Rhino for the generation of models and the subsequent evaluation of each solution. Within Rhino, the visual programming extension Grasshopper was used along with the Ladybug tools package. This combination was chosen for its abilities and flexibility regarding generating and working with geometry, and its ability to offer easy access to various building performance evaluation tools. Within Grasshopper another custom Python script was used to receive and send JSON data for each specific solution and transform the solutions into the models required for the evaluations. A set of Python scripts, built-in functions, and tools from the Ladybug tools package were responsible for all computation of the metrics.
3.3. Solution Space Definition
The first stage in the case study was to analyze the residential block and set the boundaries for the solution space in the generative design approach through the product definition, design variables, and constraints. The primary guidance for these activities was from documents from the municipality in Kiruna that regulates the area, combined with data gathered from the case company during a set of meetings carried out during the project’s duration. The data gathered from the case company included their intent for the residential block and general guidelines for the project (e.g., habitable area, types of facilities, building typologies, etc.).
It was decided that a site composition of between one and four buildings should be used. This range was chosen to not only provide a difference in an individual building’s design, but also the block’s design as a whole, with the reasoning being that different site compositions (number of buildings and their positions) together with different building designs could provide potentially interesting solutions. The regulations from the municipality dictated that buildings should, to a great extent, be placed along the edges of the residential block. As such, each of the four potential buildings was assigned one of the edges of the rectangular building block. Each building was then given a set of design variables that could be individually controlled (see
Table 1).
The ranges for a building’s widths were chosen based on residential building typologies in the area and projects that the case company had previously been developing. For the heights of each building, regulations from the municipality were used where the maximum allowed height was specified. Here, the block had two regulations for different parts of it, hence the lower range for building 3 seen in
Table 1. The buildings’ lengths were defined as a relative value based on the length of the block’s edge where that building was located. Lastly, each building’s position was a value relative to how much it could move along the block’s edge whilst still being inside the boundaries of the block.
Based on the design variables, sets of constraints and rules were defined that controlled the transformation from design variables to a feasible solution. This led to the definition of a process in which a building is defined (see
Figure 4).
The first step in that process is to define a bounding shape for the building that represents the geometrical boundaries within which the building resides. The bounding shape is defined using its lengths, its width at each end, and its height at each end. Next, a set of cuboids are fit into the bounding shape, where each cuboid represents a section of the building. A rule was defined where the length of the building defines how many segments it will be divided into, and thus also how many cuboids are fit into the bounding shape. This rule was defined as the building’s length divided by 20 m, a value that was chosen based on empirical testing until a suitable division was found for the case in question. For each cuboid, a simple building section is then generated, and each building is positioned along its edge in the block. Next, a merge area is generated around each building. The purpose of this area is to identify buildings (or sections of buildings) that are in proximity to each other and are thus subject to being merged. A threshold value was chosen for the size of the merge areas that dictated that buildings closer than 6 m to each other be merged into a single building. The merging process itself extended the closest building sections in such a way that they intersected with each other.
3.4. Generation of Solution Sets
To generate the solutions sets, this case study applied a random sampling technique as the generator. The primary reason behind this choice was the emphasis on exploration, rather than exploitation. Although genetic algorithms have been a popular suggestion for the generation of solutions in generative design approaches in the past, they tend to be more applicable when concrete objectives have been identified, and when exploitation has a higher priority. Furthermore, it was determined that the simplicity of a random sampling technique was suitable as it shifted focus away from the intricacies of specific algorithms towards a general approach of applying generative design to a design problem instead.
The random sampling generation was implemented by using a pseudo-random number generator to select different combinations of design variable values, where each combination represented a potential solution. For each iteration of the generative design process, a set of 50 random solutions were automatically generated based on the definitions in the solution space. This size was chosen for the solution sets with the intent of providing a broad variety of solutions, whilst simultaneously keeping the number of solutions relatively low to make user exploration more manageable.
3.5. Models and Their Evaluation
The metrics chosen to evaluate each solution in the case study were sunlight hours, view, habitable area, disposable area, and variation. The metrics were chosen with the explorative nature of this study in mind, and with directions and interests of the case company considered. The sunlight hours metric was chosen primarily due to the northern location of the building site, as sunlight is limited during part of the year (around winter). Therefore, it was deemed interesting to evaluate how different solutions performed in contrast with the number of hours of sunlight that the block was exposed to. The sunlight hours evaluation used a geometric model containing the block, surrounding buildings, and a geometric model of the current solution itself (see
Figure 5).
The block was divided into cells of 8 m × 8 m, and the total amount of potential hours of sunlight that each cell received during an entire year was calculated. This cell size was chosen as a middle ground for balancing calculation time (a smaller cell size requires more extensive calculations, i.e., more time) and accuracy.
The same model as for sunlight hours was used for the calculation of views. The view calculation considered the potential views that could be had from each generated window in a given solution. This evaluated the ‘openness’ of a solution, where a more open solution was rewarded with a higher score, as a longer view range was deemed more desirable. For the calculations, a coarse isovist analysis was performed, with its origin points at the center of each window (see
Figure 5).
The view range of each ray was determined by calculating the distance from the origin point (i.e., the center of a window) to the point where the isovist ray intersected either the building itself or any of the surrounding buildings. A value of 100 m was set as the maximum distance at which an intersection would be searched for, due to the surrounding buildings only occupying the sites closest to the building site and the far distance being empty in the model. The average value of the view range was used as the metric for a solution.
For the two metrics related to areas, a simplified geometric model was used, as it only needed to quantify the floor areas of a solution. The first of these area-based metrics was the habitable floor area. The case company had an initial target of 3500 m2 for the total habitable floor area for the residential block in question. This was derived from a distribution of apartments and apartment sizes combined with a utilization factor of 0.8 to account for service areas, stairwells, elevators, and so on. For the case demonstration, it could have been used as a constraint where each solution had to target the set habitable floor area; however, it was decided that the generative design approach would facilitate a more exploratory approach if the solution space was not bound by a floor area constraint, as that would limit the variation in solution alternatives greatly. As a result, the habitable floor area was used as a metric, where a value closer to their target of 3500 m2 had a higher score than values further away from it. Besides using the habitable floor area as a metric, the remaining area available on the site (hereafter referred to as the ‘disposable area’) was also computed and used as a metric. This was carried out because different solutions (in terms of the number of buildings, their sizes, and their compositions) took up different amounts of space on the block. During the study, it was conveyed by the case company that the block was going to struggle with the available area on the site after the buildings were placed. The block should, preferably, contain facilities for waste management, car parking, and outdoor recreation (such as playgrounds, grass surfaces, etc.). Thus, a metric related to the disposable space on the block was deemed a potentially useful indicator to include.
The last metric included was that of building variation. It was stated in the regulations from the municipality that buildings (and especially larger structures) constructed on the site had to have variations to some extent to break up their volumes. The reasoning in the regulations was that large monoliths were something to strive away from, and that building designs should offer variation to the surrounding environment. Given this, a metric for variation was calculated using a mathematically defined model that used the design variables for a solution as input. The greater the variation in the design variables, the higher the score for the metric.
3.6. Exploration of Feasible Solutions
Each solution in the set was presented together with their metrics using 3D models, graphs, and tables (see
Figure 6). All the presented solutions were generated using the parameters described in
Table 1 and following the process outlined in
Figure 4.
For each solution, an interactive 3D model was used to visualize the residential block, its surroundings, and the suggested building composition on it. The interactive 3D model allowed the user to zoom, pan, and rotate the view so that they could observe the solution from any angle they deemed interesting. Accompanying the 3D visualization was a table describing the design variable values for the solution that highlighted the details of the current solution (e.g., the heights of each building). Lastly, the metrics of each solution were displayed using a simple polar chart, where each metric was normalized concerning the other solutions in the set, thus showing their relative difference.
Accompanying the presentation of individual solutions, a presentation of the entire solution set was also included (see
Figure 7).
This presentation showed a table for all solutions, and a parallel coordinates chart was used to show the distribution of values for each design variable in the solution set. This allowed for an overview of the current state of the solution space.
For entering user preferences, individual solutions that were deemed interesting or relevant could be selected using a toggle in the presentation view seen in
Figure 5. When entering the next iteration of the generative design process, a new solution space was defined using the selected solutions as references. For each selected solution, a region in the solution space was defined by only allowing design variable values that were within proximity of those of the selected solution. A threshold was used for each value to create new design variable ranges (e.g., ±10%). Since multiple different solutions could be selected, two different approaches were tested (see
Figure 8): the first allowed different ‘islands’ to be defined in the modified solution space (up to one per selected solution), while in the second the regions only modified the outer boundaries of the solution space.
The first of these approaches was able to more quickly narrow down the solution space and reduce the exploration, as it restricted the boundaries into multiple smaller regions (whose sizes were determined by the thresholds for each design variable). On the other hand, the second approach retained a greater solution space, especially if the user selected multiple solutions that were considerably different in composition to each other. The drawback, however, is that this can require additional iterations in order to reduce the solution space sufficiently enough from its initial size to provide meaningful insights.
Regardless of the approach, preferences from the user were gathered and the solution space could be modified iteratively multiple times. This is what allowed for an exploratory approach, where the solution space was navigated in search of interesting solutions. This entire process of iterating between generating and evaluating solutions and continuously modifying the solution space was performed until a satisfactory set of solutions was identified. Selected solutions could be further developed in more detail in the latter parts of a design process.
5. Conclusions
This paper presents a framework for design exploration using generative design in architectural design. The framework was demonstrated through a prototype developed for the early conceptualization of a residential block in northern Sweden, where residential building envelopes were generated and automatically evaluated for habitable areas, views, variations, disposable areas, and sunlight hours. Compared to related research in generative design for architectural design, this research contributes by including a more generic framework that shows the technical workflow of the generative design system. It also contributes by further exploring the effects on the solution space imposed by constraints and top-down exploration.
The field of generative design and its application in an architectural context shows promise and has the potential to be a part of a future designer’s toolkit. Further research is needed, however, to increase the knowledge on how and when generative design is most applicable both when it comes to what types of problems it is suited to, as well as what types of methods are most suitable.