A few months ago, Ben Sitler created a guide for making Grasshopper components where, tucked in the bottom, are instructions for viewing the Grasshopper source code. Download the .Net Reflector from RedGate, point it towards the Grasshopper dll, and there it all is. Dissecting Grasshopper like this is against section 3.2.1 of the Grasshopper terms of service, however just looking at the code is unlikely to draw attention, copying the code on the other-hand is both unethical and illegal.
It is fascinating to see the inner workings of production software. I was expecting it to be overflowing with elaborate geometric algorithms, graph theory and optimisations, these are definitely there but for the most part the code is user interface. This probably should not be surprising, the interface to Grasshopper is fairly sophisticated with many different buttons and controls, while the geometry is largely handled by Rhino. The dominance of interface in code seems to be true for many other projects, I used to sell small software plugins and was always amazed by how much time I would spend not writing plugins and instead packaging software, writing instructions and providing support. Adobe seems to face a similar phenomena, about 25 minutes into this talk about Photoshop at Google, the Adobe engineer mentions that the interface of Photoshop accounts for about 1/3 of the code base, surprising when you consider how simple the interface is relative to how complex the tools are. I think as a user the output of the software gets all the attention, however under the hood of production software are elaborate algorithms, not to generate the right output, but to help the user generate the right output.
Lately I have been very focused on the output of CAD software, and whether software engineering can teach us how to make better parametric models. I wonder if I have this the wrong way around, perhaps you need to start with the interface.
Edit 3rd of August, 2010: Removed the sentence that stated: “David Rutten, the developer of Grasshopper, has mentioned that decompiling code like this is often against the terms of service, but I can not deduce if it is against the Grasshopper terms of service – I think as long as you are just looking and not taking anything, it should be fine.” And replaced it with a sentence referring to the Grasshopper terms of service, thanks to David Rutten for clarifying this in the comment below.
I have spent the past month revising this project, and have come to the conclusion: I suck at parametric design. I set off with intentions of making the entire model parametric, but four weeks later I am left with a shambolic set of simi-parametric tools linked together with long manual processes and discarded ambition for the complex parts of the project.
Everything that I wanted to do with a parametric model could be achieved with a parametric model; this claim is the origin of the rhetoric for the flexibility of parametric models. In practice however, I did very little of the project with a parametric model, I did a bit of the project manually and I modified the the rest of the project so it was achievable. The result is a design that is distorted towards the strengths and away from the weaknesses of parametric tools. An example of this is the curves along the surface (illustrated below). The the curves are an explicit list of points that are wrapped onto the surface with a UV curve passed between them. Most of the time this curve looks straight, but at the ends of the surface (shown in the illustration in red) the UV curve starts to bend. The solution is to use a geodesic curve (the green one), but this breaks the relationships to the other curves. Given enough time, it would be possible to use straight geodesic curves but, given how long it would take, it is far easier to use UV curves and modify the design to allow the bend of the curve.
Bent UV curve shown in red, straight geodesic shown in green
It is a trade off: will the 12 hours I spend fixing the parametric model be noticeable in the final design. And in some cases: is it faster to get the parametric model to conform to the real world, or is it faster to get the real world to conform to the parametric model. People mistakenly associate this decision with choice and blame the architect for being a luddite. But the decision is loaded and biases the design towards things that are easy to do parametrically and away from things that are hard to do parametrically. In this way, just like any other CAD tool, parametric designs can be read as being in the language of parametricisim – dare I quote Schumacher – biased towards the easy solutions.
So parametric flexibility is more than being able to do something, it is the ability to actually do it. For me, what I am able to do and what I actually do is quite different. I suspect the difficulty in doing some of these tasks is related using mathematics as the intermediate language between designer and parametric tool, but that is a topic for another post. Have you encountered a similar phenomena in your models?
While over in Copenhagen I was able to attend a PhD symposium held between CITA, SIAL and the Bartlett. There was 17 PhD students presenting their research (full list of speakers and topics), and two trends stuck:
New materialism
During a question and answer session, Mark Burry pointed out that materials are back in the zeitgeist. I suspect this is probably because materials and construction techniques are rapidly being discovered by material scientists, giving architects a much broader range of materials to consider than steel, concrete and glass. To a lesser extent architects are also starting to drive the development of new materials (although this is still rare). This is unfamiliar territory for architects and much of the research is looking at how to bring the material scientist into the project team and how to design and compute with these new materials.
My favorite example is a project by Sarat Babu from the Bartlett called Microkinetics. In the video above he has printed two types of rubber to make a member. In the first half of the video all the rubber is in strands and it behaves as you would expect: as it stretches it also becomes thinner. In the second half of the video, the rubber is printed in a bow-tie shape. As the member stretches it also becomes thicker. Babu had other examples of this process being used to make things like a cylindrical rubber jug, which when picked up forms a spout. Unfortunately, I suspect due to commercial interest in his work, all the videos of this have been taken down.
The mash-up
Software mash-up was a more subtle trend at the symposium. The keywords were: “I linked software X with software Y.” This falls into a much larger trend in software engineering of script kiddies, web2.0, SDK’s and the App store. For architecture there are probably two major implications:
The first is that it is the end of CAD-as-god, or the belief that a single tool can solve all problems. Hopefully this is also the end of all the zealots who flood forums with stories about how Autocad or Revit or Archicad are better than Autocad or Revit or Archicad. Possibly it is also the end of employment for people who can only use Autocad or Revit or Archicad.
The second is that interoperability becomes a lot more important than ability. I know there are people like Arup, and I imagine other big offices, are looking at this problem, but I am not convinced that it will be solved in a top-down manner.
In the mash-up culture we are also seeing software offices shrink to the size of one person. A single person like Daniel Piker (who makes Kangaroo physics for Grasshopper) is able focus on solving one problem well, rather than building an entire CAD package. I hope that the App Store model extends to architecture, allowing a single person to make a living solving a niche problem exceptionally well, and giving us a mash-up of many well fitting solutions to a problem rather than one ill-fitting CAD package.
Computational architecture got off to a pretty bizarre start in the 1960s. Pick up a copy of Cross’s The Automated Architect (1976) to see what I mean: study after study of methods to optimize designs to reduce the distance occupants walked. Even by today’s standards, the distance occupants walk seems a pretty strange measure of design success. One can only conclude that architects in the 1960s must have lived in almost perfect buildings, where commodity, firmness and delight were taken care of, and all that remained was to minimise the distances between tasks. Unfortunately, the dream to minimise the distances between tasks ends abruptly about the same time as the publication of The Automated Architect, never again to be considered a measure of building success again.
I recently stumbled across Sean Keller’s explanation of this period in his article Fenland Tech: Architectural Science in Postwar Cambridge. Keller traces computational architecture back to the Second World War, a period when:
“The extremities of war had forced to the surface many doubts about architecture as a significant modern profession: Did architects possess special expertise? Was their expertise objective or merely based on taste? In times of real need, were architects necessary? In short, was architecture serious business?” (pg. 48)
Arising from a sense of war-time inferiority, architects attempted to legitimize the profession by turning to science and mathematics. In post-war Britain, architecture was centralised around the Ministry of Works, which enabled the funding of – what was seen as legitimising — research into environmental design. With it came the rejection of “intuitive skill,” “confusion,” “sophistical sciences,” “individual hunches,” “court jesters and acrobats,” “private pranks,” “pricey prima-donnas,” “hallucinations,” “extravagant and empty images,” “individual expression,” and “personal prejudice” that “threaten architecture and planning.”(pg. 51). This manifested itself in an attempt to generate the perfect plan though minimising distances people walked. Keller gives three reasons for the interest in distances people walked:
It was based on observed behaviour and statistics.
The architects were able to legitimise the work through the mathematics of topology and graph theory.
The result was not geometrical and did not require a (then expensive) screen.
By the mid-1970s this approach had fallen out of favor. Of the many reasons given, the most relevant are:
A functional study could not objectively translate into a formal representation of a building.
It is difficult to measure a quality of a building – the distance people walk is itself a function of the building.
A satisfactory, but not optimal, solution can be found intuitively. It is not worth giving up control of how the building looks, how much it costs and what the environment is like, in exchange for a small improvement in a fairly unimportant characteristic of a building – the distance people walk.
I would also add that telecommunication probably solved a large part of this problem. This speaks to the non-obvious nature of design, that the solution to reducing the distances people walked was the design of a protocol for exchanging information between computers, rather than the design of a perfect building layout. Tabor and Willoughby, two previous advocates of mathematical plan generation, concluded that “quantitative approaches have a limited use for certain very complex problems, and must always rely on many assumptions that cannot be quantified and on inherited typologies.”
Recently performance has been back on the architectural agenda. Optimisation in the 1960s has much to teach us about the dangers of false optimization and indifference to the resulting architecture. I think this is particularly important as optimisation becomes black-boxed and commodified. So with this warning, I welcome Galapagos, an evolutionary optimizer still in beta, developed for Grasshoppper by David Rutten. In the video below it has been linked with the physics engine Kangaroo to optimise the position of attractors.
In general I am not a fan of ‘theorists’ or anything else from the 80s. The exception is Neil Leach. I can still remember the first time I read The Anaesthics of Architecture, cover to cover under the afternoon sun, the whole text resonating. In the domain of digital architecture, even though it does not explicitly discuss the computer, it is significant because it establishes context for the emergence of digital architecture. This context of architecture at the end of the millennium is described by Leach as “Architectural design reduced to the superficial play of empty, seductive forms and philosophy is appropriated as an intellectual veneer to justify forms.”
It is against this Xeroxed backdrop of image based architecture that our current focus on performance emerges. I think Leach has articulated this shift better than anyone else, best summarised in his article Digital Morphogenesis, in Architectural Design, 79 (see full article here). The only critique I have is that Leach tends to downplay the role of the architect in digital morphogenesis, claiming the process is objective when in reality the architect exerts absolute control over the process – either through limiting the application of digital morphogenesis, or acting as an editor. In some cases this has lead to performance replacing philosophy as ‘an intellectual veneer to justify forms.’ Browsing the Grasshopper forum this becomes apparent, where project after project is rendered in the image of performance rather than being performative. In many ways the shift towards performance has been a fulfillment of John Frazer’s warning (issued in 1995) that computers “induce a false sense of having optimised a design which may be fundamentally ill conceived.” Whether or not the performance we are now seeing in architecture is ill conceived or intelligent, Neil Leach has been essential in exposing the trend.
A full list of all Leach’s publications can be found at http://neilleach.wordpress.com/ along with the picture used in this post.
On the 12th of December, 2009, Niel Leach gathered some of the most prominent digital intellectuals to talk parametric urbanism at Intensive Fields. It sounded amazing but was a bit too far for a day trip. Fortunately for those who could not make it, the University of Southern California has put all the discussions on their youtube page.
The following is the first lecture given and my dream setup: Neil Leach introducing DeLanda. DeLanda’s lecture focuses on simulation of urban emergence using Cellular Automa. He defines emergence as “the result of collective unintended consequences from intentional actions.” This definition encompasses emergent behavior from intelligent agents, or at least ones that have intentional actions.
Like in his book A Thousand Years of Non-linar History, DeLanda is arguing that emergence happens on many scales. This translates to a multi-layered understanding of urban development, necessitating that simulation occurs across scales. I remain unconvinced that Cellular Automata is the vehicle to explore non-linear history. It certainly has emergent qualities, but each simulation is so explicitly tied to a layer of understanding that multi-layered simulation is difficult to achieve. DeLanda somewhat addresses this critique in the panel discussion following, arguing that Cellular Automata should be seen as a form finding processes.
And the panel discussion afterwards: (left to right) Manual DeLanda, Niel Leach, Benjamin Bratton, Anne Balsamo, Lev Manovich and Eui-Sung Yi.
Prior to the 1980’s it was not obvious that computer simulation would drive architectural change. As Sherry Turkle explains in Simulation and its Discontents, this was a time of batch processing before the development of the immersive environment of computer simulation. Simulation and its Discontents follows the introduction of computer simulation at MIT, exposing the still present tension surrounding our understanding, control and seduction by simulation. Those early debates at MIT seem to foreshadow our current situation; a period where the two major events – the global financial crisis and global warming – exist in, and as a result of, simulation. A situation that was not obvious prior to the 1980’s.
Reading Simulation and its Discontents, the global financial crisis appears to be caused by economists “drunk with code.” A large part of the cause (although I am no economist, and even economists disagree on this) seems to be the ‘black-boxing’ of assets into mortgage backed securities. These securities are a way to collectively value to highly risky assets, however hidden inside them is assumptions regarding the default rate on mortgages. Architecture was black-boxed in a similar way during the introduction of simulation. Engineering equations were hidden behind on-screen buttons, which caused architects to worry that a generation of students would not understand the limitations of these calculations. They were probably correct to worry, and they should have certainly worried about the economists who had black-boxed assets to the point where they became so “complicated that the authorities could no longer calculate the risks” according to George Soros.
Complexity and black-boxing is not the whole story. The financial intuitions all had a big incentive to understand the simulation, even if it was hard, complex and obscured. The reason they did not understand the complexity is likely to be an equally complex story and some have even speculated the institutions understood the risks, but thought they were too big to fail. One reason not to follow up on the complexity is given in Simulation and its Discontents: “Simulation makes itself easy to love and difficult to doubt.” This is true if the simulation is returning pretty renders, but I imagine it is especially true if the simulation is making you billions. And by not doubting Turkle warns that “it can be hard to remember all that lies beyond simulation, or even acknowledge that everything is not captured in simulation.” Clearly much lay beyond the financial simulations, but they worked exceptionally well for a long time, making it hard not to be “drunk with code” on the success of these simulations.
The global financial crisis is more than a source of unemployment for architects. It should be a warning about our ambivalence towards simulation. That is not to say we should reject simulation, but rather we should, as Sherry Turkle has done, re-examine our relationship to, and dependence upon simulation. The concerns of architects at MIT in the 1980’s are still true today and the tension between understanding, control and seduction is present.
Recently I have been producing parametric models for Antoni Gaudí’s Sagrada Família; in Excel. When I agreed to use Excel to produce the models, I signed on certain I would fail, such was the unlikeliness of Excel succeeding in producing parametric architecture. While I cannot say much about the project, I should say that we were only using Excel for research purposes and that the design of the Sagrada Família remains one of the worlds most technologically advanced architectural projects. Using Excel drove me pretty close to the wall, particularly at 2am on a Friday as I got the model ready for a deadline and was trying to figure out a formula for a circle intersecting a plane in three dimensions. After two weeks on Excel I am not a convert, but I have begun to re-evaluate the worth of the more technologically advanced tools.
One of the curiosities of Excel is that cell relationships are hidden. A cell displays data and the only way to see relationships is to click on the data and view the formula. This is the inverse of graph based parametric modelling tools like Grasshopper and GC, which graphically represent the relationship between nodes but hide the data – in Grasshopper you need to hover over each node to see the enclosed data. Both approaches achieve a similar result, which got me thinking about why architects use the graph based approach while Excel still uses the spreadsheet based approach.
I am not the first person to consider this. In 1997, Spreadsheet 2000 competed against Excel with a graph based spreadsheet (shown above), which looks suspiciously similar to Grasshopper, complete with Bezier curves. Incredibly Spreadsheet 2000 was itself created with a graph based programming tool, Prograph, by Steve Wilson who went on to become the vice president of systems at Oracle, where he still probably maps out systems using graphs. This must have all seemed pretty advanced in 1997, it still looks advanced today, yet Spreadsheet 2000 failed before reaching the year 2000.
There does not seem to be any analysis on why Spreadsheet 2000 failed, so I am going to speculate: relationships don’t matter. The problem Spreadsheet 2000 was trying to solve was the invisibility of relationships in spreadsheets (Wilson talks about the aims of Spreadsheet 2000 here). The solution was to use a directed graph that exposed the relationships between cells. The graph is successful in doing this, although its verbosity makes it inefficient compared to a normal spreadsheet. For example the relationship between the top right table and the bottom middle table is inversion. Using a graph this takes up a significant amount of interface real-estate – two lines and an intermediate node depicting 1/x – it could have just as easily been communicated by adding a column to the top right data headed ‘Inverse’. The inefficiency of the graph increases with complexity since more nodes make it more difficult to interpret individual relationships from the spaghetti of code.
By exposing the relationships, Spreadsheet 2000 aimed to reduce errors. This is not the case. There is no correlation between knowing the relationships between cells and the number of errors. Stephen Powell’s “A Critical Review of the Literature on Spreadsheet Errors,” references a study where one group of participants were given a spreadsheet on paper so they could not see the cell relationships, another group were given an electronic copy so they could see the formula, and both groups identified a similar number of errors in the spreadsheet, 50%.* Anecdotally I agree with this; I have never stared at the Grasshopper graph and gone ‘there is my mistake,’ I do however see errors in the 3d model and then find myself working back through the graph, hovering over each node to see what the data inside looks like.
Spreadsheet 2000′s failure seems to be a common occurrence for visual programming paradigms. It is only in parametric architecture that I have really seen graph based tools like Grasshopper and GC become so widely adopted. I am unsure of why this is the case. After using Excel I feel there is still room to improve on these paradigms, particularly the emphasis they place on relationships, which are often only needed at the time of construction. Despite this, unless you are Gaudí, I wont be giving up my graph based representations again.
* Similar research has been done by the European Spreadsheet Risks Interest Group, a group that gives me considerable comfort knowing that someone is looking out for our accountants and the risks they face.
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.
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)
rss feed
