Once when studying computer science I had to present a computer program to my lecturer, in his office. The computer in his office was dual-screen but all he had open was six text based terminal windows (like the DOS command line on Windows). He looked on expectantly, waiting for me to demonstrate my program by typing commands into the terminal. Coming from the School of Architecture I had never seen anyone operate a computer without a Graphical User Interface (GUI), and I had no idea how to operate it myself. After typing Abracadabra a few times, I eventually had to restart the computer and use the mouse and icons to open up my program. I left the office feeling pretty stupid. The feeling continued until I got my marking sheet back where my lecturer raved about how intuitive my use of the mouse and the GUI had been. The GUI is not all bad.
Recently I have been looking at old CAD programs, from the days before any sort of standard GUI. Like the story with my computer science professor, it is easy to see why in the 1980’s, mouse based GUI’s became so popular. But something I had not considered, until I started reading about these old systems, is what the architect gave up to use a GUI.
The most obvious ramification is that the GUI immediately limits the vocabulary of the architect. If the architect wants to draw a line between two points, there is probably an icon for it, but if they want to produce a catenary curve – like the curves of Gaudí and the Voussoir Cloud – they are probably out of luck. The software developer is entrusted with the generation of new vocabularies, dishing out new tools for the architect with every software release – doubly curved curtain walls in Revit 2010! The current trend towards scripting is a realisation of the GUI’s limitations and an attempt by architects to take control of their tools and as a consequence, their buildings. (See anything written by Kostas Terzidis).
A less obvious ramification of the GUI is that it destroys the history of how an object is created. In the pre-GUI days objects were created with lines of code, which provided a list of commands that needed to be executed to make the object. If the object did not look as intended, any of these commands could be edited, added to, or removed. However with the GUI, the focus shifted from editing how the object was made, to directly editing the object. This is because it is hard to visulise all the commands that generated an object with a GUI - in each instance the object is Tabula Rasa with its method of generation destroyed. So the only way to edit an object through the GUI is by adding further commands to it, or to undo the last command, thereby destroying the current one. The history of an object is important to architects who worship napkin sketches, smudges and Scarpa’s drawings – probably because how something was created tells us about why it was created. The history is also important if we want to revise a design and perhaps start with a square rather than a circle. Associative modelling and graph based parametric modelling are two techniques used to activate the history of a GUI based drawing.
I certainly could not live like my computer science professor and only use a text based interface on my computer. However the GUI is a bit like fast food, it is convenient, but it is important to know the sacrifice you are making to the health of your body or design for this convenience. It is reassuring to see that architecture has embraced digital technology to the point where some of these sacrifices are being mitigated.
The Voussoir Cloud Installation by IwamotoScott Architecture carries on Gaudí and Otto’s tradition of using hanging chain models as form finding tools.
A chain will naturally hang in pure tension, and inverting this shape produces an arch in pure compression. Producing a design in compression without any torsion or shear forces allowed Gaudí to build without flying buttresses, and the Voussoir Cloud Installation to be paper thin. In the Voussoir Cloud Installation, the form was found by specifying the points where the structure was to touch the ground and then, with software developed by Buro Happold, hanging virtual chains from these points, which define the edges of the surfaces. The shape of the curve is particular to the weight of the material. In this case the very thin timber veneer produces much flatter curves than if it was made out of concrete. The hanging chain model asks the material, almost in Kahn’s words, “what it wants to be” and the material falls into place. You can play with a similar tool called CADenary developed by Axel Killian and released free of charge.
WPA2 : Local Code / Real Estates is a project by Nicholas de Monchaux that utilises GIS data to identify abandoned sites, and Grasshopper to design a custom urban space for each site. 150 sites in total. With that many designs, even easy tasks like making a render becomes difficult: turning layers on an off in Grasshopper, sending each version to Illustrator and saving the image to become a single frame in the movie. But while the project shows of some dexterous file management skills, I still have some reservations about the architectural worth of this project:
My first concern is with what constitutes site in this project. Like in many digital projects, site has been reduced to the quantifiable parameters: solar incidence, wind direction, demographics and geometric data. This data driven, hyper-local approach leads to an erasure of context, as described by Francesca Hughes in AD 79:
“‘Context’ in the culture of parametric production returns, or is reinstalled, already digitalised, and edited to the bone: typically as a set of three to five measurable, and thus necessarily quantitative, physical parameters (latitude, wind direction, and typical rush-hour capacity, say). Once optimised, these parameters effectively ‘contextualise’ the system or proposal, argue that it is inthe right place at the right time. That is, context returns as a highly abstracted, carefully selected alibi. Architects have always, necessarily, artfully reduced context to harness it as a generator and justifier of action. This is nothing new.What is new is that with parametric systems this reductive process from the outset excludes any indeterminate or qualitative content –ironically such parameters are usually the more site-specific ones.”
With some much of the context excluded in Local Code : Real Estates, it is worth considering how responsive the designs actually are. Whilst they are geometrically unique, they have a universal, almost modernist, unity to them that denies context. Even in the renders context has been reduced to data – white geometric planes – with no indication of the inhabitants reacting to the lee wind planting necessitated by the data to reduce their energy consumption.
My second concern is the way the design is produced in Grasshopper. The code seems to use a rule based algorithm: place trees on the south side if there is no wind. The problem with this approach is that design can not be expressed in a formal logic. As Manual De Landa puts it in his 1993 essay “Virtual Environments and the Emergence of Synthetic Reason”:
“[early artificial intelligence] researchers explicitly put symbols (labels, rules, recipes) and symbol-manipulating skills into the computer. When it was realized that logic alone was not enough to manipulate these symbols in a significantly “intelligent” way, they began to extract the rules of thumb, tricks of the trade and other non-formal heuristic knowledge from human experts, and put these into the machine but also as fully formed symbolic structures. ”
In this situation, the computer un-intelligently executes rules on behalf of the architect who takes little responsibility for the results. It is a flawed method that finds neither the optimum or the apt-imum.
Both of these concerns might be answered with a “wait for the next revision,” a reply that has been given by various architects for decades. Sure, now with Moore’s Law we can produce hundreds more designs, much faster, but the fundamental problems of digital architecture remain: site is just data and design is just rules. I wish I could remember who asked “are we there yet?” but I suspect there have been quite a few. Local Code : Real Estates demonstrates that once we get there this technology will scale easily, but Local Code : Real Estates makes no progress towards getting us there.
I have a few details of this project wrong, so thank you to Nicholas de Monchaux for emailing me with a few further details. These designs are not intended to be built, like I assumed in my ‘First Concern,’ but rather act as an armature for public discussion. At about 3:30 minutes into the first video you can see people using the Berkeley Opinion software to comment on their local design. This of course brings up issues of public design, which have been endlessly discussed elsewhere. However what I find exciting about this proposal is how closely it relates to the Wikipedia bots, which were originally used to produce articles about cities from GIS and census data (that looked like this) these machine created entries could then be edited by individuals in the community to make them more relevant. Like the Wikipedia bots, I wonder if there is potential to open up a GIS API and let anyone develop a bot to populate these vacant sites. The bots would each design for the thousands of sites and the citizens would be free to pick and choose parts of each design that they liked. Such a system would not free us from the problem, identified by Francesca Hughes, of designing from data but the system might inspire us to move beyond the currently employed rule based design. (A bit like the Net Flicks Prize)
Another question I frequently get is what software do I use &/ what software should someone learn. The following is a summary of parametric software you can use.
Graph based: When we talk about parametric software, we tend to think of graph based tools. The two major ones being Generative Components and Grasshopper. Both of these use a two dimensional relationship graph to express associations between geometry. Generative Components is the older of the two and as such is more frequently cited to in books and papers and projects. Grasshopper has the benefit of a more modern interface, making coding as fun as playing with lego. Generative Components is probably more powerful at the moment, but with the lead developer of GC – Robert Aish – off to Autodesk, I would expect Grasshopper to pull past GC.
Stack Based: Stack based tools store transformations to objects in a one dimensional stack. Changes can be made at any location in the stack and propagated through the remaining stack. The best known of these is 3dsMax. 3dsMax also has the ability to link values together through the Wire Parameter option, and these can even be wired to sliders. The Smart Filters in Photoshop also work as a parametric stack.
Associative history: Associative history is an editable record of how an object was created. Maya uses associative history enabling you to do things like create a loft from two curves and then go back and edit one of those curves, updating the loft. The major software in this space is CATIA/Digital Project, used on The Birds Nest, Sagrada Família and all of Frank Gehry’s buildings. A licence is prohibitively expensive preventing most people from using it.
CAD tools: Both Revit and Archicad have parametric tools. Revit allows the creation of Revit Families, which are driven from parameters. Walls can also be constrained in a manner similar to CATIA. And the new conceptual massing tool features associative history. Archicad works through the Geometric Description Language, which allows you to code parametric objects (sort of like Revit Families). It is a favorite argument of Revit Fanboys, and while unnatural it is surprisingly powerful.
What you should learn:
All of them. And make your own. Each program has a particular mode of translation, so locking yourself into one program limits what you can express. Knowing multiple programs expands this vocabulary. In terms of employment, since the software is changing so rapidly, it seems to me that learning how to learn software is more important than learning a specific piece of software.
[edit 7-2-2009: My servers crashed an lost the comments on this entry, so feel free to comment again]
I have just started my PhD and have begun reading all those 1990’s books on how to do a PhD. Filled with useful advice like: when searching for a girlfriend, make sure she has transferable skills so that when you get employed overseas she can easily move with you; and start your research by phoning people in your area and asking them to post you papers. It is scary how much researching has changed in the last decade as information become freely accessible. I read almost everything as a pdf on the screen, downloaded from databases like CuminCAD. I get more fiction from the library than non-fiction (although most writing on architecture is fictitious). I have also been watching a bunch of lectures on Youtube by everyone from Steve Jobs to Neil Leach to Einstein to Manual DeLanda. In the 1990’s, only societies elite would have access to this information, now anyone with an Internet connection can watch Manual DeLanda deliver a lecture at Columbia University.
DeLanda’s lecture on Deleuze and the Use of the Genetic Algorithm in Architecture is a favorite of mine, for DeLanda’s stage presence as much as anything – no Powerpoint just an hour long rant without any cues. The lecture goes with a paper Delanda produced of the same name. To me, and the Youtube commenters, the philosophy DeLanda presents is a little dubious [i]. I wish he would throw it away like he has done to the Powerpoint and tell it straight because DeLanda, who was once a computer programmer, has a very good understanding of this subject. So since DeLanda wont and because an hour is a long time to watch Youtube, my summary of important points:
We have already used the genetic algorithm to design, most domestic animals are the result of selective breeding.
The genetic algorithm is a tool – although this somewhat contradicts DeLanda’s paper where he talks about architects becoming racehorse breeders, subservient to the code.
The genius of form can either be fixed, if it comes from a God like vision. Or it can be fluid if it comes from an evolutionary paradigm
Difference is critical to the process, and this corresponds to the paper where he says surprising results are important. If we are setting up genetic algorithm to produce homogenized shapes in a narrow range then why not just design them ourselves.
[i] I once had a girlfriend who was a philosopher who was very dubious of any architect talking about philosophy, as I think most philosophers are. Needless to say, this was before I had read the PhD books because philosophy is hardly a transferable skill and when I moved overseas things ended, so perhaps the PhD books do have some value.
Shot in 1962, this video of Ivan Sutherland’s Sketchpad is almost 50 years old. It shows Sutherland (just 25 year old) demoing his PhD project, a project that wins him the Turner prize (the Nobel prize of computer science). The program is running on the TX-2 – the last computer in America ‘to have its own roof’ (see the TX2 instruction manuals). There are a number of remarkable things about sketchpad:
It is the first use of a Graphical User Interface and the first CAD program. Prior to Sketchpad computers were just switches, lights and punch cards.
It is the first use of Object Oriented code. This is a coding paradigm which forms the basis of many modern programming languages.
It is an early example of a program not running as a batch. In batch mode there is no interaction, you put in the inputs and it would give you the outputs, in 1962, being able to interact in real time with the computer is quite remarkable.
For me the most amazing part is the way Sutherland constrains the lines. I thought seeing this done recently in Digital Project (2009, $30,0000 per licence) was cool, but to see Sutherland select a series of lines on different angles and morph them until they are orthogonal is pretty mind blowing. Using todays computer it would still be non-trivial to get the lines to morph into the right place, much less do it in real time on a computer that requires its own room. This feature makes Sketchpad not only the first CAD program, but also the first parametric CAD program. I also think the way objects can be referenced into the drawing is cleaver, and even Digital Project struggles to make instances of object like Sketchpad does.
A-periodic tiles are sets of 3-8 tiles that are specially shaped so that no matter what way they are joined they produce a pattern that never repeats. It seems counterintuitive to have a small set of regular shapes that can only make irregular shapes when joined. There is probably a mathematical proof for this but I have been trying to force a pattern, and disprove the theory, for long enough today to admit defeat. These shapes provide the potential in architecture is to create irregular structures from regular members; a building like the Watercube could be developed without needing to custom manufacture every joint and member.
The facade of Federation Square in Melbourne is made from pinwheel tiling. Just five regular shapes make the irregular pattern on the building.
Pinwheel tiling on the left (Source: Wikipedia), the same shapes are used in Federation Square, shown on the right (Source: Wolfram).
Marc Fornes’ creations use three-dimensional aperiodic tiling. While they look chaotic and irregular, if you look at his CNC cutting templates they are comprised from regular shapes. I am not sure of the exact tiling he uses but a basic version is the Danzer tiles.
The regular shapes cut out on the left, make the irregualr form on the right using 3d a-periodic tiling. Source: The Very Many
Graphemes is a spring based design tool developed by Sawapan. The interface – like the program – is unconventional, playful and esoteric. Steve Jobs would have a fit seeing something so non-standard running on an Apple computer, thankfully it only runs on Windows. Despite its unconventional nature, it is quite easy to grasp with a wee bit of playing, and judging by the videos you too can become a Graphemes ninja.
Essentially Graphemes allows the manipulation of a spring based topology that seeks equilibrium in real time. Analysis graphs can also be overlaid – showing bending moments and stress in the structure. Designing a spring based structure is probably of little utility (unless you are designing a space station) but what Graphemes hints at is a future where the design/analysis cycle has been compressed into a just a design cycle. This allows the parametric model to have a dynamic topology and embedded logic. An unconventional design paradigm wrapped in an equally unconventional interface.
Graphemes is free to download from the Sawapan website (click on Graphemes to the left).
Caliper Studio’s Genetic Staircase translates obscure computer code into an accessible metaphor. The literal correlation between a genome and the metal woven between the coiled stairs, produces an easy to understand diagram of a genetic algorithm. It is not the first time a genetic algorithm has been used to design (see my past post on Archikludge) but for many people this will be the first time they understand what a genetic algorithm does. As a communication device the Genetic Staircase is exceptional but as a staircase I still wonder if the genetic algorithm has been successful.
The program for the Genetic Staircase was a Rhino script. The script generates a population of individual staircases, each one with the diagonal members in different places. These individuals are then evaluated in an external structural analysis program (CADRE lite). The most successful designs produce offspring by splicing their diagonal members together using a single crossover point (Video of the crossover process). As an aside I think this is a technically limited method since Rhino script is slow and the structural analysis program had no scripting interface – both of these factors greatly limit the potential of the program to rapidly iterate between options.
The actual stairs are manually defined using a parametric model, as are the main runners and the handrails. It is only the criss-cross of diagonal members under the stairs that have been created by the genetic algorithm.The problem is so well defined that the solution found by the genetic algorithm could have been anticipated beforehand; it was always going to be random diagonal members running under the stairs. The genetic algorithm therefore is not operating as a discovery tool but more as an optimisation tool. But what is it optimising? The staircase is not cheap, lightweight or easy to construct. Presumably the algorithm has some variables that balance the cost of the staircase with the visual weight and structural stability. Correlating such variables in my experience is problematic since they are all in different units – creating a formula to balance structural stability against cost gives a false sense of authority to the process.
It is here that the Genetic Staircase is unsuccessful: it is great at explaining how a genetic algorithm works, but it does not demonstrate why the genetic algorithm could be better than the normative design methods. Then again I could have this all wrong and the genetic algorithm may just be there as an advertising device. If it is, Caliper Studio have done a wonderful job capturing the attention of non-geeks. A bold and exciting first step by Caliper Studio.
ArchiKludge is a project by Pablo Carranza that explores the automated design of architecture. Completed in 2004, the project is not technically innovative, but it is a simple and rare example of a genetic algorithm being used in the design of architecture.
The genetic algorithm used by ArchiKludge belongs to a family of algorithm known as search algorithm. These algorithm have been developed by computer scientists to search for solutions to problems, and recently architects like Pablo Carranza have appropriated them for use in digital morphogenesis. The way the genetic algorithm finds architectural solutions in ArchiKludge is as follows:
A population is generated - The population is made up of individuals and each individual is an architectural solution. The individuals all have genomes associated with them. In ArchiKludge the genome is a string of 64 numbers. Each number is connected to a cube in a 4*4*4 structure, when the number is set to 1 a room is created in this location, when it is set to 0, there is a void.
Individuals are measured – All the individuals are measured to find the best. In ArchiKludge the individuals score is a the sum of the average distance between connected rooms.
Breeding – The best individuals are breed together to form a new generation. It is not explained how this happens in ArchiKludge, but typically what happens is two parents are selected and a child is made from half of each parents genome.
Solution selected - ArchiKludge continues indefinitely, but presumably an individual could be selected as the final design.
The process used in ArchiKludge is made to look more complex through a fairly slick interface. Notably the cubes have been pushed and pulled a little bit to make the buildings look more interesting than the cubes the program is really designing. How individuals are measured is also cleaver because it produces unconventional buildings with voids, where as if the measurement was gross area it would quickly become a solid cube.
Being so basic I do not think ArchiKludge is particularly useful. The problem lacks the scope to find any surprising solutions – when I tested it, I could produce results of similar measures manually. There is also no point for the architect to interact with ArchiKludge and relying on one method of problem solving (computational) impoverishes the result. ArchiKludge suffers from problems typical with digital architecture: how to represent a building on the computer; and how to measure the success of that building. It is a cleaver diagram of a genetic algorithm, and at times it hints at an architectural application, but in my opinion it does not suffice as a way to produce architecture.
I recreated ArchiKludge in Processing, see it and download the source here. Incidentally I found ’sketching’ a digital project in this way a really useful way of understanding the project.
rss feed
