Findings about the generative design prototypes

This section contains conclusions about the four prototypes presented above. The prototypes’ principles and the presumed principles of the generative design system developed throughout sections IV-VIII are compared and discussed. I focus on:

1. the potential pitfalls or limitations of the prototypes and how a given prototype could benefit from the presumed principles;

2. the advantages and benefits of the prototypes’ principles and how these principles could be verified and improved.

FINDINGS RELATED TO A BUILDING MODEL

To denote a building model, the authors of the prototypes discussed use terms such as: an individual, a (design) solution, a phenotype, a (generated) design, a (generated) model, a (generated) building. The building models of all the prototypes are composed of clearly defined sets of building elements.

The ‘operational space’ is three-dimensional and in most of the cases the requirement of spatial coherence (e.g., that the building elements do not overlap and that the walls/ windows have no random breaks, etc.) is fulfilled.

An exception is prototype 3, in which a building model is represented in a quite an abstract way; this makes it difficult to relate its elements to their physical representatives such as walls and windows (in this prototype, building elements are vertices, faces and surfaces). Prototype 3 approaches a building model generation from an aesthetic point of view. The focus is on shaping a complex, unexpected, ‘sculptural’ form, which can be interpreted in many ways, and which is thus meant to be an inspiration for an architect.

Prototype 3 lets the user operate directly on the level of the building elements (vertices) with the following possibilities of modification: insert, delete, fold, lift, poke-hole.

Unlike prototype 3, prototype 2 relates a building model and its structure to the physical building elements (walls). Moreover, it combines the walls into functional entities, like rooms, which can be interpreted as groups of elements. It also makes calculations determining areas of the rooms, and it examines the spatial adjacencies of spaces. Prototype 2 further includes a basic hierarchical structure of the building model. The building model of prototype 2 is a relatively balanced representation of a detached, 2-storey house.

The construction of the building model of prototype 1 is based on facades, and it consists of walls, windows and roofs, which are distributed over the facades on a predefined, constant volume. The definitions of the complex building characteristics such as energy performance and daylight illumination are realistic, and they require complex simulation and computing.

The situation is similar in prototype 4. Here the general shape of the building model is predefined – it is a single room. Building elements are windows, doors and an air supply pipes that are distributed over the walls of the room. As in prototype 1, the complex characteristics – thermal and ventilation performances - are specified through simulation.

Unfortunately, none of these prototypes attempts to define a

comprehensive set of building elements and building characteristics, making their building models comparable to those currently used in BIM systems. A more comprehensive definition of building models would make the solutions more unanticipated and interesting, because the size of the search space

would significantly increase. Moreover, a more comprehensive building model implementation would provide more elaborated building

environments.

FINDINGS RELATED TO A BUILDING ENVIRONMENT

In all the prototypes analysed, there was no clear distinction between the design requirements and the design intentions.

When it comes to site constraints, only prototype 1 takes into account the geographical location of a building. The intensity of the sun in a given location plays a crucial role for the thermal performance of the building.

Other site parameters, such as the shape of an allotment or the form of a terrain are not included in the system. There is no need, however, to consider other site parameters in prototype 1, because it does not operate on the form of the building model, but only on the facade solutions. Consequently, a building model definition that is limited makes a broader definition of site constraints unnecessary. The three remaining prototypes do not take into consideration the site constrains and their potential effect on building models.

Only prototype 2 encompasses building codes. The local building codes are applied in terms of lighting, energy consumption and minimal space for furnishing.

None of the prototypes directly refers to the master plan regulations. The authors probably assumed that the master plan regulations should be inputted as a part of the design intentions.

The prototypes discussed make no distinction between the client’s intentions and the architectural qualities. In prototype 1 and 4, the genetic algorithms serve more as a design optimiser (in both cases energy efficiency was optimised) than a fully operative design generator. Prototype 1 is not capable of altering a building model’s form while prototype 4 reduces the form to a box of various sizes. On the other hand, prototypes 2 and 3 do operate on form. Especially, prototype 3 is focused on form and it can generate very complex and refined forms; however, it neglects all the remaining building characteristics. The building forms generated by

prototype 2 are relatively simple as they consist of boxes distributed over two floors. In contrast, they are well balanced by building characteristics. Thus, it seems that prototype 2 is the closest to the approach advocated in this thesis, as it reflects the structure of the environment in a most complete way. It implements local building codes, takes into account construction recommendations, and it considers design intentions such as space adjacencies and rooms’ areas (the last two correspond to the client’s

intentions). Prototype 2 is also interesting because it operates within the housing architecture.

Furthermore, prototype 3 and 4 involve the user in the evaluation process.

Though it seems inevitable in the case of architectural design, the strength of Evolutionary Computing is that a large number of evaluation and

modification cycles are performed in a relatively short time. The algorithm takes advantage of the computing speed of a machine only if the process is not interrupted by users. Assuming that each evaluation has to be confirmed by a user, the algorithm’s ability to generate, evaluate and transform generations of individuals within seconds is compromised. Thus, it is desirable to reduce the user’s involvement as much as possible. One solution may be to limit the number of the user’s interventions (e.g., to every

hundredth cycle). But then, the system’s evaluation capacity would be reduced, which could result in undesirable solutions. Specifically, in the case of prototype 4, a building model might become very energy efficient, but it would lack basic functionality or it would be unattractive.

Summing up, the common drawback of all these prototypes and probably the reason why they did not find application in the actual design practice is that they include only a few building characteristics (though their

implementation is deep). In other terms, their building environments are deep but they have low resolution. It is worthwhile to recall the principle I propose in section VII, saying, that a building environment development should start with a high resolution and low depth. Progressively, the depth could increase, in consideration with the results and performance of the system.