The Different Ways of Room Arrangement: Pull-Push


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.


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.



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.



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.

The Housing Problem of Riyadh

Riyadh is the capital of Saudi Arabia, with a population of 5.7 million. It is one of the least dense cities in the world, at 2,500 /sq.mi. (Dubai is 6,863. Istanbul 7,060. Los Angeles 3,189. Chicago 11,864.) There is no public transport available, but they are working on it.

Right to left, top to bottom: #1: 4000sf is too much, 3000sf is enough. #2: 3000sf is too much, 1000sf is enough. #3: 1000sf is too much, 400sf is enough. #4: 400sf is too much, 20sf is enough.

Right to left, top to bottom: #1: 4000sf is too much, 3000sf is enough. #2: 3000sf is too much, 1000sf is enough. #3: 1000sf is too much, 400sf is enough. #4: 400sf is too much, 20sf is enough.

Yet for a city with so little density and that is literally in the middle of the desert, it is currently in an ongoing housing crisis. 50% of residential units are of the typical "villa" type, which means a walled, but not wall to wall, 2.5-story house. Land available to buy and build is too scarce, leading to an increase in prices as the demand for houses rises, while income remains largely the same.  Land that is available for sale to build on is becoming smaller and smaller. 

This has prompted a research project in my first semester in SAIC : an investigation on how Houses grow. Starting from the simple observation about how houses of the Middle East grew historically with their families, I speculated into how could that be applied to the Riyadh houses of today. It started with an analysis of a typical Riyadh house and the rules and patterns that generally govern it. The rules had to written in a way that allowed potential extendability in the future.

In addition to speculation about how could a single house grow and how the neighborhood would grow with it. For the case study, I took the house I grew up in, and imagines a past and a future for its extendability, spaced over the typical growth of a Saudi family, based on a study by an undergraduate classmate, Ahmad Alfarhan.

Eventually, this the original exercise led to the first prototype of Autoarchitect. A genetic algorithm was created to design house based on the number of family members, and a typical program based on earlier research. The prototype, while not including doors and windows and staircases, accounted well for rooms that intersect with each other and sent rooms up to the second floor as needed. The only problem is that it took a long time and the result was nowhere useable. 

This was, in a nutshell, the first version of Autoarchitect. In the next blog post I will share some of prior art and some of the writing on the subject that influenced me then and later.