The Different Ways of Room Arrangement: Pull-Push

Intro

Over the course of this project, a few ways of arranging rooms neatly, while all adjacency requirements are fulfilled, have been suggested. I have not yet settled on which method to use, and I am still writing different  experimental sketches exploring then. Currently I am exploring two ideas: the Pull-Push algorithm, and the Throw-Stuff-At-The-Wall-and-See-What-Sticks (Throw-and-Stick for short) algorithm. Both methods are Box-Packing algorithms at their heart. I feel that the most important part of a program like Autoarchitect is the geometric solver, i.e. the "room packer". How good can the program be if it can't even make sure that the kitchen is away from the bedrooms? or that the garage opens to the front? Today I will talk about the Pull-Push algorithm.

Pull-Push

The first prototype, shown in an earlier post, is based on an algorithmic idea I like to call Pull-Push. It assumes that the rooms are physical objects that have physical relationship with each other, and they attract each other if they are related. The rooms are placed initially in their relative correct places, so the room which needs morning sunlight is placed on the east-ish. This influences the room's eventual position in the room. Then all rooms that are related to each other, or would be marked as "adjacent" in an adjacency schedule, pull each other. Then it goes through all the rooms to check if they're intersected or not, then pushes them out of each other. 

Starting position

Starting position

To best illustrate this, see the above diagram. (Please excuse the crudeness of these drawings, as animating boxes is a bit more difficult than I anticipated.) It shows three rooms that are related to each other, as you can see by the black pipe connecting them. The first step would be to pull them towards each other in a straight line. However, due to the original position of the rooms, two of them end up intersecting each other.

Pull

Pull

This is resolved by the second part of the operation: Push. The algorithm identifies intersecting cubes based on their geometries and positions, and pushes them away from each other. You end up with three adjacent rooms. Naturally, with a plan with more than three rooms, the second step does not necessarily resolve all conflicts. So you go back to the beginning to adjust rooms that should be related to each other, then resolve any intersections: Pull, Push.

Push

Push

One way the basic logic of this algorithm could be improved is to bound it by a site boundary, so rooms are not pushed outside the site. This prevents some weird bugs and infinite loops from happening.

In the next blog post I will post about the Throw-and-Stick algorithm, also known as Genetic Algorithms. The implementation is fairly simple, but the results are not necessarily so.

Previous art

There are similar projects to Autoarchitect. They usually approach the problem from slightly different perspectives. For this post, I will be talking about some of them, in addition to some related research.

Towards a Scientific Architecture - Yona Friedman

In his book, Friedman mentions a proposal for what he calls an "apartment writer". He cites the Tyranny of the Architect, the tendency of architects to advance their own ego over their client's needs, as a major problem, and proposes a new task for Architects and Planners. Mainly this: design should be treated like a restaurant menu, where there is a repertoire of architectural elements the client can pick and choose from. Every item has a warning that is either the food combination or the price. The role of the Architect becomes like the Chef in that analogy: to organize and curate the repertoire. Here it is in Yona Friedman's own words:

This example demonstrates the method that propose for setting up a repertoire for the architect’s client to use. The repertoire will be made up of a complete list of all the possible linkages and labeling (the mapping of the problem itself). The client (earlier we called him the future user) will actually have the freedom to choose any possible combination instead of having to go along with the preferences of some architect or other.
For each possible combination, the repertoire will have a corresponding warning indicating its cost. The warning will tell the client the cost expressed in effort; this is the intrinsic property of each combination, that is, the advantages or inconveniences of this combination in terms of the client’s particular mode of use.
— Toward a Scientific Architecture - Yona Friedman

Other authors have echoed Friedman's sentiment, like Nicholas Negroponte in Soft Architecture Machines (a part of which Friedman introduced). Negroponte frames it under the title User Participation in Design. He separates the field of user participation into 3 categories: more info, more advocacy, and the part least protective of "professionalism", citing Friedman: control. The two categories are not really considered participation. He likens the traditional architect-client relationship as Paternalistic, as follows:

Father knows best for a long time. However after a while he begins to lose credibility rapidly. Inconsistencies and unexplainable “musts” make the original institution of paternalism more and more suspect to a child; the doubt probably starts as early as age one or two. Nonetheless, for a long time the issueof Father’s rightness is less important than the comfort of knowing he is around. In this sense, it is interesting to question the role of the architect in terms of comfort and confidence; can it be embraced in a machine and thus avoid the potential orphanage of participation?
— Soft Architecture Machines - Nicholas Negroponte
 

An adaptive approach to residential design - Bruno Postle

A Pattern Language, published in the late 70's by Christopher Alexander, tried to envision a brave new world for Architecture. It defined a series of "patterns", or rule sets, that encapsulate what is according to him good design principles. It encapsulates Architecture, and by extension any design process, into a series of individually and scientifically testable rules, which can be taught and expanded on and adapted. While the book was more or less a dud in mainstream architectural circles, it became a huge influence on the field of software design. Coders and designers came to define their own design patterns and use them as a guide for good and efficient software design. One programmer, Bruno Postle, figured he should take the idea back to Architecture through an algorithm called Urb.

Postle used genetic algorithms to produce plans and designs for residential houses, using Alexander's patterns as fit criteria. In other words, the algorithm generates thousands of house designs then basically picks the one that satisfies Alexander's patterns the most. Every individual pattern was assigned a score, and each generation was scored by all the patterns, and all the scores were multiplied. The higher the product, the better the house is in theory. The algorithm, when applied to generate cities, seems successful as replicated traditional house designs. The project is written in Perl (for some reason) and is open sourced. It can be found in its homepage.

Population of a single house after 32 genertions

Population of a single house after 32 genertions

 

Housing Agency System (HAS) - Architecture Research Lab

This is an attempt to solve the problem that most houses designed are designed without paying attention to the eventual resident. The only party with input into the design is the developer, whose best interest lies in having the exact same design for all the houses they build. HAS tries to find a compromise between developers' needs and clients' needs, by creating a a mass-customizable house design that can be customized by the buyer using very simple criteria, such as the shape of the site, the existence of a car, and so on. This affects items like how long the rooms are, the angle of certain joints, the number of floors, all within a ready design structural system that can apply to all these solutions. More details about the process can be found in their website.

 

Other relevant research

 

To end this post, I would like you to ponder this quote, while thinking about the status of typesetting in today's world:

The writing of this book was completed in the summer of 1972. By fall it had advanced to a computer-readable format (paper tape). It is appearing only now, in 1975, for a number of reasons related to its production. The author and the publisher share the embarrassment that most of the delays were caused by the use of automation, in particular, computerized typesetting. The only redeeming aspect of this episode is the shared belief of those involved that, while this is a feature of computerization today, it is not an inherent and everlasting property.
— Soft Architecture Machines - Author's Note - Nicholas Negroponte

The images from the article came from the books and websites mentioned just before.