Following on from Of the year 2010, a look back at a year full of clouds, patents, and WebGL.
Software of the year
My pick for Software of the Year is something I don’t use very much, you probably don’t either, but it hints at what we might use in the future. It is ShapeSmith by Benjamin Nortier.
ShapeSmith can be described with all the popular buzz words: AJAX, NoSQL, three.js, open-source (on top OpenCascade), Amazon Elastic Cloud Storage and HTML5 / WebGL. In this list, the last three items are the significant jargon:
OpenSource: There are ranges of openness, from open API’s and open data formats through to complete open-source (like in ShapeSmith). Either way, all this access is making it increasingly easy for small development teams to create software only large corporations could have made a decade ago. With it comes innovation. The all encompassing software silos are slowly giving way to ecosystems of software, built in many small parts like ShapeSmith.
Cloud Computing: Cloud computing was the fabled solution to every problem this year: too complicated to compute, put it in the could; need access anywhere, in the cloud; teamwork, the cloud; global warming, clouds. Yet all the talk resulted in little more than hopeful diagrams. This is because ‘the cloud’ is far more ephemeral than people realise. Yet ShapeSmith actually operates in a cloud. There are difficulties with latency, with paying for the cloud computation and with control. But having a rack of Amazon computers crunch your geometry is a tantalising trade off.
WebGl: I wrote a post about WebGl back in May. A bit like tablets, it is a solution seeking a problem. ShapeSmith is probably is not the right problem – in the sort term WebGl will likely augment rather than replace your CAD software. But like so much of ShapeSmith, I would not be surprised if it has predicted the future.
Quote of the year
One of the most revealing quotes this year came from Daniel Piker in the Kangaroo Physics release notes:
note : regarding the planarization functions – I have been asked to draw your attention to the patents held by Evolute, Helmut Pottmann and RFR: http://www.evolute.at/technology/patents.html
In the debate that followed the majority felt Evolute was unethical, and Evolute responded essentially by telling the architectural community to pay up.
However my favourite quote this year has to be:
… use computation, but stop fucking talking about it. Your project isn’t any better because you told me it was scripted from the secret code found in the lost book of the Bible handed to you by your Merovingian great grandmother. Nor because you spent a semester producing the most intricate parametric network ever seen by man, & still ended up with three crumpled potatoes in glossy grey.
Somehow Gramazio & Kohler and Prof. Raffaello D’Andrea herded a swarm of flying robots to intelligently stack bricks. The installation is an outcome from the Flying Machine Enabled Construction project, which conjures up images of bees and Archigram and R2-D2. It is a great counterpoint to the relatively trivial and unimaginative applications of computation we have seen recently. Hopefully this level of thinking occurs more in the future, or at the very least more flying robots in the future please…
Search of the year
Periodically I check the search terms people use to discover this blog. It’s one way to find questions needing answers. So to the 41 people who came this year asking “what software does zaha hadid use?” the answer is: everything. For the five that wonder why “computational architectural design sucks”, you need to remember computational design is a technique and the outcome is a reflection of your own abilities. But for the three of you who came in search of “patrick schumachers wife”, and you know who you are, I hope you put some thought into your resolutions this new year. To the rest of you, I hope you have an enjoyable break!
In cracks between the evangelical facade that cocoons parametric modelling with a blanket of positive writing, you catch glimpses of dissent. These are the things you catch people talking about in private between drinks – tall tales of unexpected work, of rebuilding the model, of mistakes and incompetence. As significant as it is, I have never seen anyone write a whole paper on it (unfortunately so much of what is important goes unstated in the rules of publishing). The following six quotes are as close as I have ever got:
David Gerber: “When the topology of a project changes the [parametric] model generally needs to be remade…” (2007, 205)
Rick Smith “A designer might say I want to move and twist this wall, but you did not foresee that move and there is no parameter to accommodate the change. It then unravels your [parametric model]. Many times you will have to start all over again.” (2007, 2)
Jane Burry: “… to edit the relational graph or remodel completely is also commonplace.” (2007, 622)
Dominik Holzer et al. “… changes required by the design team were of such a disruptive nature that the parametric model schema could not cope with them.” Part of the model was rebuilt. (2007, 639)
Robert Aish and Robert Woodbury: Parametric modelling “may require additional effort, may increase complexity of local design decisions and increases the number of items to which attention must be paid in task completion.” (2005, 151)
Mark Burry: If a critical change is made “there is no solution other than to completely disassemble the model and restart at the critical decision.” (1996, 78)
—
Aish, Robert, and Robert Woodbury. 2005. Multi-level Interaction in Parametric Design. In Lecture Notes in Computer Science, 151-162. Berlin: Springer.
Burry, Jane. 2007. “Mindful Spaces: Computational Geometry and the Conceptual Spaces in which Designers Operate.” International Journal of Architectural Computing, 5 (4): 611-624.
Burry, Mark. 1996. “Parametric Design and the Sagrada Família.” Architectural Research Quarterly, 1 (Summer): 70-80.
Gerber, David. 2007. Parametric practices : Models for design exploration in architecture. Harvard University.
Holzer, Dominik, Richard Hough, and Mark Burry. 2007. “Parametric Design and Structural Optimisation for Early Design Exploration.” International Journal of Architectural Computing 05 (04): 625-644.
Jason Calacanis, a technology entrepreneur never shy of hyperbole, exclaims that:
Anyone who has an iPad — a device that did NOT exist 18 months ago — says it’s their primary consumption device or tied for their primary consumption device. (via Launch)
When I stopped to consider where I consume media – like others Calacanis interviewed – the answer is: primarily on my iPad. But consumption doesn’t matter for those of us looking for a tax write-off on our Christmas present to ourselves work related expense. The all important question is whether you can do anything productive on an iPad. So a quick review of what is available for architects and where it might head:
3D Viewers
All of the major CAD companies have put out CAD viewers for the iPad.
These apps all work in much the same way, allowing you to open, view and present 3d files on the iPad. It turns out rendering geometry is a task the iPad is surprisingly good at. The controls inside Graphisoft’s BimX are probably my favorite, allowing you to walk around a building like in a computer game with an overlay of the floor-plan based on your location. One of the major hindrances to all these apps is Apple’s clunky solutions for getting content onto the iPad. Take for instance Bentley’s helpful guide for exporting models to the iPad:
Bentley doing what they do best
This particularly painful diagram from Bentley is partly because your drawings need to be exported into a special mobile format. The same is true of Graphisoft’s BimX. However, Dassault, McNeel and Autodesk use the native file format of their desktop counterparts. This makes importing files much easier but the true significance is that these companies have worked out how to port code from desktop apps to the iPad – an important first step in creating something more than a 3d viewer.
Of all the vendors, Autodesk have been the most enthusiastic about the iPad. In total they have produced 16 apps; a grab-bag of 3d viewers, drawing apps, a photo manipulation app, a clock, a game and a book. It seems Autodesk senses something is happening, but their scatter-shot approach gives the impression they are not (yet) sure of the larger vision. Nevertheless, it is exciting to see Autodesk throw their might behind speculative innovation – we are seeing it with apps and also their recent cloud efforts: Autodesk 360 & Autodesk Cloud.
Apps to create architecture
Autodesk’s experiments have produced two notable apps for creating geometric designs:
AutoCAD WS is largely a viewer for AutoCAD files but also has tools to draw circles, lines, rectangles and text. AutoCAD jockeys are not going to be rushing to produce drawings on the iPad but it is probably enough to markup changes if you are away from the computer.
123D Sculpt is a push-pull mesh tool that lets you shape an object like it is clay. The interface is suited to the iPad but the organic forms are probably only appropriate to architects of a certain ilk (Gehry).
Not my most flattering self-portrait - in 123D Sculpt
There is a smattering of other apps available, none of them particularly amazing. My favorite is Home Design 3D. It is a very basic CAD tool where in 2d you can draw walls (orthogonal only) and add windows, doors, and furniture. Once complete you can fly around a 3d rendering of your rooms. It is no Revit, but for non-architects wanting to mockup things like renovations, I would recommend it over Sketchup.
New interfaces
The CAD offerings on the iPad are currently pretty dismal, mostly because the touch interface has not found a place beside the precise, memory intensive desktop counterparts. It has taken 18 months for the iPad to be a primary consumption device but the CAD industry is moving much slower than this. On the other-hand the games industry is moving very quickly and we see games for the iPad that have architectural aspects like Touch Physics, Zen Bound, Cut the Rope, World of Goo, MineCraft and even Angry Birds (although admittedly about the destruction of architecture). These might hint at where the industry (Autodesk?) is going, as Ben Regnier asks, “why the hell don’t I get to use this at work?” (Work, mostly play)
I would love to find more apps, please post your favorites in the comments.
This review of Mark Burry’s Scripting Cultures (On Amazon) – like my review ofThe New Mathematics of Architecture (also by Mark) – carries the disclaimer that Mark is the supervisor of my PhD. I should also confess to illustrating the project in the final chapter, for which I will shoulder the blame if it doesn’t look as good as the other chapters.
Scripting Cultures investigates why designers choose to script. Burry suggests two motivations: productivity and control. The evidence for these claims consists of a biographical account of Burry’s own work, intermixed with a set of ‘thought experiments,’ and a set of interviews with thirty of the industries leaders (including: Casey Reas [Processing], Robert Aish [Generative Components + Designscript], John Frazer [An Evolutionary architecture], Axel Kilian, Neil Leach, Denis Shelden [Gehry] and Hugh Whitehead [Fosters]).
On the surface, productivity and control seem like utilitarian motivations to script, especially when compared to the writing normally associated with scripting: chest thumping proclamations of new paradigms footnoted with references towards incomprehensible continental philosophy. In place of these typical grandiose proclamations is a very honest assessment of how scripting can be applied to the design process. Burry admits that despite being introduced to scripting in a class taught by William Mitchell in the 1970′s, he had no interest in scripting until he needed it for part of the design of the Sagrada Família in 1989. And even after picking up scripting Burry says he still finds it difficult and time consuming – as do all of the other 30 scripting wizards he interviewed. Burry’s openness about the scripting process is not a dry utilitarian argument (despite appearances) but rather a refreshingly frank account of how scripting can augment the design process.
Burry sees the designer as central to the design process. His definition of design – the “mapping of an idea through to an intended outcome” – focuses on the designers aspiration rather than fetishising algorithmic effects. As such Burry views scripting as a conduit to enhance the design process, whether it is using productivity to iterate faster, or whether it is using the control of scripting to break free from the confines of black-boxed drafting software. The second half of the book focuses on a number of case studies where this happens. The case studies are characteristically honest about the challenges they faced and design method employed. I personally preferred the first half of the book to the case studies, but that might be because I am familiar with the case studies – I imagine someone who has not scripted before could find it insightful to see the nuts-and-bolts application of scripting in practice.
The book concludes by arguing for scripting as “an essential component of 21st-century design education.” In doing so Burry cautions against classifying scripting as a single culture that could be seen as an “exclusivist force.” Instead Burry affirms the importance of the designer in the scripting process, suggesting scripting is at home with the many cultures of design practice.
From my non-objective point of view, Scripting Cultures seems to articulate a maturing in our understanding of digital practice, away from self-congratulatory ego-shots demonstrating how clever we could be with scripts, and towards a time when scripting becomes a part of the everyday culture of design. For beginners I imagine this un-embellished description of scripting could offer some useful pathways into understanding the history, culture and role of scripting in design. For experiencedscripters it is reassuring to hear 30 experts tell you they find it difficult as well. My major gripe with the book is that it only comes in physical form. For a book that so fully celebrates the capacity of technology to contribute to culture, waiting for it to be printed and mailed to you seems a little perverse. This is made even more stranger by the fact that Wiley – the publisher – is relatively progressive in making AD the journalavailable online. Yet for Scripting Cultures not even the contents is online (I put it below) and equally strangely there is a website where you can download some of the scripts from the case studies http://www.wiley.com/WileyCDA/Section/id-611118.html but it was not mentioned in the book. However medium aside, Scripting Cultures makes an important contribution to the culture of scripting.
—
Somehow I have managed to end up with two copies of Scripting Cultures. If you would like my extra copy (its hardback) enter your name and email below. On the 17th of November I will randomly select someone to send it to. If you don’t win you can always pick it up on Amazon and leave a comment on this post. Good luck!
18-11-2011: The winner of the competition was Harri Lewis, a post-graduate student at the University of Bath and blogger at HarriLewis.com
—
Chapters:
Scripting cultures
Contextural summary of computing, scripting and speculative design
Cultural defence
Resources
Dimensions
Scripted productivity: Gaudi’s rose windows
Composition and form
Simplifying complexity for fabrication
Scripting narrative space: Our world and The Third Policeman
Performative scripting
Cultural account: Scripting and shifts in authorship
I have begun writing my PhD, which is simultaneously daunting and invigorating. One aspect I am contemplating is how to make an 80,000 word document applicable to a wider audience than the two examiners and as accessible as this blog. No doubt there will be posts on this over the coming year. However central in my contemplation at the moment is the question of why we want flexible representations, why architects need parametric models.
MacLeamy curve (2004)
In 2004, Patrick MacLeamy drew a set of curves based on a pretty self-evident observation: an architectural project becomes more difficult to change the more developed it becomes. For this earth-shattering revelation MacLeamy named the curve after himself (although the title should probably go to Boyd Paulson who drew the curve much earlier [see Noel's comment to this post]). You have probably seen the graph before, it gets trotted out in every slide deck promoting BIM / IPD / or early stage environmental analysis. The key point is that architects expel their effort at a time when design changes are relatively costly. MacLeamy and his disciples advocate shifting design effort forward in the project, frontloading it, in order to reduce the cost of design changes.
MacLeamy would argue that shifting design effort forwards is for the benefit of design [via youtube]. However the portfolio of buildings the architecture firm HOK has designed with MacLeamy as CEO is decidedly uninspiring. MacLeamy’s real design position is indicated by his choice to measure design changes in terms of cost, since I think most designers would perceive their decisions as adding value to a project. Further, the shift in effort assumes the design process can be anticipated and the design problem can be known before the design commences. But we have seen this curve before…
Boehm's curve (1976)
28 years prior to MacLeamy, Barry Boehm drew a curve based on a pretty self-evident observation: a software project becomes more difficult to change the more developed it becomes. For this earth-shattering revelation Boehm named the curve after himself. It is pretty striking how similar the curves are, both in shape and even in what the axes signify. Boehm’s curve is often used by software architects to justify upfront design – much like MacLeamy’s curve is in architecture. However Boehm’s curve has been challenged…
Beck's Curve (1999)
In his book ‘Extreme Programming Explained’ (1999) Beck drew a radically different version of Boehm’s curve where cost approaches a horizontal rather than vertical asymptote. It is an audacious idea, but Beck thought it could be achieved by changing the culture of programming, moving away from up-front design and towards continuous design supported by a new generation of programming tools. 12 years later we see evidence of Beck’s curve manifesting. One example is Facebook, which somehow manages to run co-current versions, while they integrate new features, while changing the underlying infrastructure, while half a billion people visit the site, and all the changes happen on the fly, at a rapid pace, with no down time. It would be like the designers of Boeing designing and changing the plane while it was flying. If Boehm’s curve held true, the existing Facebook code base would be growing exponentially more costly to change, slowing the rate of change. Instead we see something resembling Beck’s curve where the rate of change remains steady.
Beck’s curve would never work in an architectural context because architecture, unlike software, is very difficult to change once it is constructed (although some cradle-to-cradle people might disagree with this). Significantly for architects, the Beck’s curve demonstrates the location of our design efforts do not need to be controlled by the cost curve, instead using new design tools and a new design culture we can control the cost curve to suit our design efforts. So I propose another graph…
Davis curve? (2011)
This graph is based on the pretty self-evident observation: an architectural project is difficult to change once it is built but using flexible modelling tools designers can delay finalising decisions until the model is baked. For this earth-shattering revelation I have named the curve after myself. The curve is aspirational rather than reality, since parametric modelling in contemporary practice still requires significant frontloading and still frequently encounters moments of inflexibility. The curve appears to be amplified by particular architectural topologies and for a few categories of problems, notably patterns and panels, the curve already exists. As parametric models become more supple to discrete changes, I think there is a possibility this curve could manifest on a wider range of design problems. You heard it here first.
I also note that while I have drawn this curve in terms of cost (to aid comparison with MacLeamy’s curve) I think it is better stated in terms of flexibility. Cost is a measure of the designers capacity to make change, the designers ability to design. Designers have more capacity to make change on a flexible representation, while at the other end of the spectrum the designer has very little influence over a brittle representation. Being able to change the design empowers the designer to explore the solution space, to reconsider the design problem and to respond when forces outside their control influence the project. While there is a cost associated with changing a design, flexibility aims to lower this cost by making designs more susceptible to change. That is why architects need flexible representations, why architects need parametric models.
EDIT, 25th of October, 2011:
Another version of the graph based on suggestions in the comments. Perhaps we can call this one the Regnier curve
rss feed
) – like my review of 
