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. 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 (1981)
23 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 vesion of the graph based on suggestions in the comments. Perhaps we can call this one the Regnier curve
Recently I edited out a section from a top-be-published journal article because it meandered off topic and past the word count. Despite the journal editor’s draconian word count, I thought it potentially useful to other people. So here it is, rewritten and free of word counts.
—
There are 2035 parametric models shared publicly on the Grasshopper forum. I downloaded these models and looked for trends in the way they were structured.
1. Most popular nodes
Unsurprisingly the slider was the most popular node with 11,842 occurrences in the 2035 models. Panel, Group and Scribble come in 2nd, 3rd and 9th place, which is the result of people documenting their models (in the forum people know their model will be read so they put some effort into explaining it). 4th place is occupied by ‘List Item,’ which leads a group of list management nodes – Series, Cull, Graft, List Length, Flatten Tree – dominating the top 30 most popular nodes. It is significant that the most popular modelling operation in Grasshopper should be list management. When teaching Grasshopper I find list management to be the hardest topic to explain, and yet Grasshopper’s list management tools are some of the most powerful short of pure scripting. It should be pointed out these results are a little biased in that there are many different types of geometric modelling nodes and while no single node is popular, in aggregate they are popular. Nevertheless the list of most popular nodes should serve as a useful guide for teaching Grasshopper and the customisation of the Grasshopper menus.
The neglected nodes speak volumes for how people use Grasshopper. Falling down the bottom of the popularity list is poor old ‘Cluster,’ who sits in 159th place. There are a few reasons for this:
Cluster has only been available in Grasshopper 0.8 while the models in the Grasshopper forum stretch back to version 0.6.
People are probably more inclined to share small snippets of models on the forum and therefore don’t require clusters.
Clusters was buggy when it was re-released.
Yet, if we only look at the models created in Grasshopper 0.8 and only look at the models that contain more than 26 nodes, only 3.6% have one or more clusters in them This means most of the models people are creating in Grasshopper, even the really really really large ones, are totally unstructured, like the example in the next section:
3. Model size
The medium size of a model shared on the forum is 26 nodes, probably lower than what you would expect in practice due to people often sharing just small snippets of models. Yet a couple of models contained over 1000 nodes. The largest model I could find on the Grasshopper forum is a monster by the name of ‘hybridB02 (2).ghx’ (in this thread) weighing 20mb and containing 2584 nodes. It looks a little bit like this:
hybridB02 (2).ghx is a pretty classic case of copy-paste, and if it gets the job done who cares. But this type of unstructured model could be a huge liability if it ever needs to be edited. Say the original pink box is wrong, you edit it but to propagate the edit through the model you need to delete every instance you copy-pasted and copy-paste in the new version. Or, as we often do, start again.
I was curious about what the model would look like refactored and quickly attempted to refactor it myself (see above). One of my first moves was to reduce the dimensionality of the model. There are approximately 500 sliders in the original model, so the model is effectively no longer parametric since moving the 500 sliders would be just as difficult as moving 500 points on an explicit model by hand. Often a formula is used to reduce dimensionality of a parametric model, however in this case I used rotational symmetry to simplify things. This might have made the geometry too neat for some tastes but you could always use a formula to tweak each rotated instance. The resulting model has 126 nodes and 20 sliders, making exploration of the design space far more viable – although the model is by no means perfect.
Refactoring the model introduced quite a few of the list management nodes. This is both the reason they are popular (they are really useful) and the reason managing lists is problematic (people starting out in Grasshopper are unlikely to use them). In completing this research I had planned to make one more list of my own, a list of popular combinations of nodes but this will likely have to wait for another paper and a more friendly editor. It looks like my friend the cluster will have to wait a while longer too, as I have quite subconsciously left him out of the refactored model.
—
And if you are in, or near, Melbourne in November, we are going to be hosting a week long computational design workshop with Hugh Whitehead – Director of the Specialist Modelling Group at Fosters. Find out more at http://designingthedynamic.com/
When Google bought Motorola last week many speculated it was for their 17,000 patents. Patents are valuable arsenal in the wreckage of a broken patent system. In daily posts, the tech blogs have been documenting the buildup of portfolios that guarantee mutually assured destruction (MAD), while the tech giants call one another trolls and play a high stakes game of chicken. For the most part it is entertainment. A tragedy rather than a comedy, for it is sad to see the economy’s great technological innovators competing with the unintended consequences of laws rather than competing with better products.
Today something caught my eye in the latest update of Kangaroo (the geometric tool that allows you to do some pretty nifty stuff with real time physics). It was a minor update to improve compatibility with Grasshopper but one line of the release notes, tucked away in a very small font, caught my eye:
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
On first glance this seems innocent enough: parts of Kangaroo do similar things to the Evolute tools (see videos above) and Evolute probably just want to make sure Kangaroo isn’t flat-out copying them. However this is not what the patents assert. The patents actually protect a specific type of geometry, which is:
Freeform
Panelised with planar quadrilaterals or hexagons, or made out of developable strips.
Yes you read that correctly: Evolute didn’t patent their way of generating geometry, they patented the geometry itself.The videos above demonstrate that Kangaroo and Evolute generate geometry using totally different methods – Kangaroo in a bottom-up manner through physical principles and Evolute by applying mathematical rules in a top-down manner to pre-existing surfaces. Even though these methods are totally different Evolute asserts ownership of all freeform surfaces panelised with quads used in architecture, independent of the production method. If you manage to create one of these surfaces with Kangaroo, or even accidentally in Autocad, you legally have to apply to Evolute for a licence to build the structure.
Are you fucking kidding me.
Now there is a case for patenting geometry. Architects have long argued, particularly in practice lead research, that designed objects contain tacit knowledge which is as valuable as the explicit knowledge generated by hard science. For instance, the design of a car body is the manifestation of a long string of design investigations and as such constitutes unique and specialised knowledge, which should have patentable protection. However, patenting everything with four wheels and an engine would be absurd. Yet Evolute has done this. They have not patented their method of creating surfaces, they have not patented the geometric output of their software, they have patented a whole shape topology.
I suspect, I hope, Evolute can not defend these patents because of prior art, but I am not a lawyer and clearly a real lawyer has advised Evolute they are defensible. Their defence could set a disastrous precedent. Other companies will try to cash in like Evolute and patent other topologies of shapes, architects will have to ensure their designs (while conforming to the other legislative constraints) do not infringe on these patents, large architecture firms will buy patents as ‘protection’ and very quickly architecture could go down the same unproductive path as Apple, Google and Motorola.
Whether the patents are defensible, whether Evolute has the right to do what they did, does not absolve it of being a douchbag move.
Up until about 8 hours ago I considered Evolute to be a good actor in the community; they shared their research with others and they released a free (if severely crippled) version of their tools. But this is like calling a farmer generous for feeding his animals. Evolute fattened the market for their patents through these ‘good’ actions, while only a few weeks ago they began telling Kangaroo et al. about the patents, despite holding the patents since 2007. In some ways it is shrewd to defer the cost of Evolute until the construction phase of projects since $1000 for a patent durring the construction of a million dollar roof lacks the pain of paying $1000 for software upfront (to use on one project).
This could be Evolutes legacy. All of the mathematical innovation out-shined by a single legislative innovation. I personally would much rather see Evolute making money and innovating in the tools they produce, innovating in the way they consult, innovating in how they teach in academia and industry workshops. It is sad to see Evolute (like the economy’s other great technological innovators) competing with the unintended consequences of laws rather than competing with better products. While there is a case for patenting geometry (particularly geometry with embodied knowledge) being able to patent a geometric primitive is wrong. It is even worse to take advantage of this ability and set a dangerous precedent in the process. Until this is fixed I would be cautious of working with Evolute, there is the real possibility you would hire them to refine your geometry, and then when you went to build the geometry they would try to sell you a licence to build the refined geometry. Hopefully by speaking up we draw attention to Evolute’s practice and form some sort of consensus around how to prevent someone patenting the cube. Seriously.
I am very interested in:
Whether you think Evolute has crossed the line here
How you think patents of geometry should be handled
If you have been approached by Evolute regarding these patents
Leave comment with your thoughts or get angry in your own forums and leave a link.
—
UPDATE: 31 August, 2011:
Evolute posted a response on their blog, claiming that they are not patent trolls. My response can be found in the comments section of this post.
UPDATE: 3 September 2011:
Daniel Piker, the creator of Kangaroo physics, has posted a considered summary on his blog of his relationship with Evolute and what this means for Kangaroo (full-steam ahead basically).
Be sure to checkout Lee’s comment way down the bottom of the post. He point out the patents are only applications and the applications are being challenged.
I removed the claim that Evolute “quietly added a licensing section to their website,” this was inaccurate, they have had a licensing section since 2010. Interestingly the Wayback Machine has caught their initial licence fee: no more the 1% of construction cost, or a 10k payday on a million dollar project…. http://web.archive.org/web/20110531212224/http://www.evolute.at/technology/patents.html
In Australia we rank conferences – academics being academics can’t resist the allure of a quantitative measurement. The Australian bean-counters give CAAD Futures a grade of ‘A’, which was enough to justify my attendance this year. By my own qualitative measurement, CAAD Futures gets the grade of ‘pretty awesome’.
Held every two years, CAAD Futures is the place to go if you want to talk earnestly about the future of computer aided architectural design. This year it was in Liege, a slightly run down former coal mining town in Belgium better known to architects as the home of Santiago Calatrava’s elegant train station (home is probably the wrong word to use for something so alien and don’t let the money shots fool you, this is a functional disaster).
For me the week started with an excellent workshop by the Robots in Architecture crew, Sigrid and Johannes, who demonstrated how to link Grasshopper to a Kuka robot (hopefully they will launch the Grasshopper component shortly). The next three days focused on discussing CAAD, which since the first CAAD Futures conference in 1985, has come to encompass a wide range of topics. This year it stretched from mobile, to shape grammars, to way-finding for the blind, to environmental design, to parametric design, to early stage performance analysis.
One of the more interesting developments that emerged from CAAD Futures was a practice lead critique of CAAD tools. This was kicked off by Andre Chaszar, who chaired a discussion on the first day about collaborative modelling. Chaszar’s position is that centralised management of CAD models (A.K.A. BIM) makes for a compelling diagram however in practice the model normally finds itself distributed into domain specific silos. When we normally talk of BIM, despite the industry push towards BIM, we are discussing a common geometric model from which each discipline recreates their domain specific model. Chaszar’s acknowledgement of the difficulties with BIM led him to explore ways to facilitate this mode of practice; a fantastic contrast to the typical academic confused as to why no-one is using their hopelessly optimistic and overly complex frameworks.
This practice lead critique continued with parametric modelling. The Woodbury clan have been exploring this for a while: Diliara Nasirova giving a compelling demonstration of the difficulty in detecting changes resulting from parametric models (a case for unit testing perhaps?), and Temy Tidafi demonstrating a SVN-like system for storing a version tree of a parametric model. Patrick Janssen gave a simple but highly useful comparison of using Grasshopper, Generative Components and Houdini to produce a parametric model, concluding that iteration and the management of lists is one of the most challenging aspects of parametric modelling in practice. And I will sneak my own work into this category: a paper looking at ways to overcome parametric inflexibility by using modular programming, which to my surprise was selected as the best paper of CAAD Futures and can be viewed here.
In the past CAAD has typically been discussed in a gushingly positive light. I suspect one reason is that historically the small community of people qualified to discuss CAAD have had an incentive speak positively about CAAD: would The Logic of Architecture be compelling if Mitchell admitted his system would not work? would the early optimisation studies be funded if the researchers admitted the optimal layout of floor plans was not important to practice? Would anyone care about Lars Spuybroke if he wasn’t talking about how awesome the computer is all the time? As CAAD has fledged and taken a firm hold in practice, the discourse in recent years has become more robust. It was exciting at CAAD Futures to see the loop between practice and academia close a little bit, with practice starting to inform academia. Obviously there was more to CAAD Futures than this line of discussion, so hopefully you can get full the proceedings on CuminCAD in the coming weeks.
I try to solve almost any problem with a Genetic Algorithm. And when you have a hammer as big as a Genetic Algorithm, with almost 3.7 billion years of user testing, it is hard not to see many Genetic Algorithm nails sticking out all over the place. On any other year I would have given this to the Genetic Algorithm, but 2010 has really been the year of the Spring Algorithm. There have been some fascinating projects: Kangaroo physics (above), Ander’s work with the Maya Nucleus Engine, projects by Supermanouver and Kokkugia, and even I dropped the genetic algorithm and picked up the spring algorithm for a while. Also all those tensegrity projects you have seen everywhere this year: spring algorithm.
What I particularly like about the spring algorithm is that it is our algorithm. Most of the other algorithms are hand-me-downs from computer science, in a list that contains all my old favorites: Cellular Automata, Genetic Algorithms, Simulated Annealing, L-systems and Shape Grammars. But there is something inherently spatial about the spring algorithm that makes it useless for anything other than physical stuff, and I like that.
Software of the year
Draftsight almost won this by completely pissing on Autodesk’s release of Autocad for OSX, by launching an almost identical product, weeks earlier, for thousands of dollars less (free). Not only that, Draftsight actually works. While Draftsight certainly had the biggest bang this year, Grasshopper has spent the year slowly cranking out significant features. It started with the new plugin system, which has grown into a sizable array of tools, including: Kangaroo, Rabbit, and Weaver Bird. Add onto that the release of Galapagos for Genetic Algorithms, and the re-release of clusters, 2010 has been Grasshoppers year.
Walk into any university final year exhibition and you are certain to find a Grasshopper definition lurking in more than one of the panels. I spoke to some Autodesk developers this year and you could tell that Rhino and Grasshopper – despite their small market share – had really fired Autodesk up. Autodesk desperately wants to be cool again. In the long run they might be because Grasshopper seems to have taken the concept of graph based parametric modelling almost to its conclusion. I think the next major development in computational architecture will not be a more refined version of Grasshopper, but an entirely new take on it. Autodesk, having acquired Robert Aish, have quietly been working on some physics based modellers and the new Designscript project. And as we saw with Autoplan, it wouldn’t be the first time Autodesk have come from behind to conquer a market, that is if Draftsite/Dassault don’t get there first.
Call of the year
How about you? Do you have convictions about what constitutes a meaningful for contemporary architecture? Or are you unsure? (Do whatever we feel like??? What then? Or what people want??? What do they want?) Do you have the opportunity to work according to your own convictions – if you have convictions? Are you able and willing to state the principles that underly your work? Could these just be valid for you? Who is Daniel Morales to have principles all for himself? Which client should by into Daniel Morales’ personal perspective???
18th of May, Schumacher decides the best defense of parametricism is to go on the offensive against Daniel Morales. With comments like this, rightly or wrongly, 2010 was the year of parametricism.
Fornes has been producing projects in this vein for years, and in 2010 it seems everyone caught on making their own large-scale-installation-of-mass-customised-lazer-cut-pieces-distributed-on-irrational-surfaces.
I like 10 Sukkah City because it is beautiful. I like it because the surface is mathematically interesting, and difficult to panel around the holes. But I mostly like 10 Sukkah city because it collapsed. 10 Sukkah City represents where computational architecture is today: we can make beautiful structures, we can design with fancy and complex mathematics using computation, but we are struggling to deploy them at building scale, we are struggling to embed function, and we have no idea how to calculate the structural load. These problems are masked in a large-scale installation (whereas they are not on a building), the collapse of 10 Sukkah City pulled back that mask a little bit and gave an honest insight into where we stand at the end of 2010.
—
Please nominate your ‘of the year’ in the comments. I hope you all have an enjoyable new year. I am taking a short break back to New Zealand but will be back here shortly.
It has been a strange week. It started in Copenhagen with me teaching students how to build wooden reciprocal frame domes. I was preparing to leave Copenhagen and spend some time in London so that I could, amongst other things, gate crash the launch of Patrik Schumacher’s new book The Autopoiesis of Architecture. But as I was packing my bags, my Grandfather died. I decided to skip London so that I could return to my family, and I spent the next 48 hours recreating the journey my Grandfather made when he was my age and immigrated to New Zealand from London – only his trip cost 10 quid and took 6 weeks. At some stage while I was floating in the jet-stream, in between timezones I have never visited, I received a message from London, from Patrik Schumacher, in response to this blog post, that began: “Hi Daniel, Don’t be such an ungenerous prick!” To be fair, a Google search for “Patrik Schumacher” used to show as the 9th result: “By far the biggest villain in all of parametric design is Patrik Schumacher,” which is a quote from me, so his response was on the level. Schumacher mentioned being “attacked by a blogger from Australia,” in his lecture at the launch of The Autopoiesis of Architecture, and at almost the same instant Schumacher made this statement, on the other side of the world, I helped bury my Grandfather.
I don’t place any significance on the interweaving of these two events, but I do find the circles in the narrative interesting.
Once things settled down, a long debate between Schumacher and a couple of other readers emerged on the blog. It seems a shame to hide such a significant debate in the comments, so with this post I want to highlight what was said, and direct your attention to the original comments (here) – although judging by the number of people who have ‘confessed’ to reading these comments (as if this blog is my secret diary) you might already know about them.
There is something to be said about the character of Schumacher that he would respond to critique like this. I think it demonstrates that Schumacher is serious about Parametricism – this is not just some idea he dreamt up for a speaking gig or as a way to increase his publication count (not looking at any academic in particular). His response is not so much a defense of Parametricism as it is an invitation to participate, for even a rebuttal of Parametricism achieves Schumacher’s goal of getting architects to consider how ”harnessing generative computational processes” advances architecture. With such a broad idea, an idea that Schumacher is still – very publicly - working out, in a very fractured community, it is little wonder he has stepped on a few toes. But it is apparent from both his words and his actions that he wants others to join in refining this vision.
On the name Parametricism, Schumacher writes:
“Perhaps you can try to come up with a better label, or argue why you think that any such labels are not useful. This argument was made quite a lot – and I have an answer to that: a name is an anchor for self-description, collective reflection, and a fighting slogan for outward proselytizing and media recognition. Why should we leave these advantages to others. Why should we impoverish our discourse?”
Parametricism is definitely double sided. On the one hand there is something very marketable and memorable about it, which is partly why students are so seduced by it. On the other hand it invokes notions of parametric design, when Parametricism is fairly agnostic to design methods. I think for many people in the area of computational design, it is hard to get past this, it has taken me almost three months.
On the perceived lack of context for Parametricism, Schumacher writes:
“I am not a full time lecturer, I am a practicing architect before I am a theorist, and I have a lot to show even before going into somebody else’s work … I encourage anybody with the passion, insight and the time at hand to do this work of presenting the best work within the framework of parametricism.”
An almost perfect critique of Parametricism would be to evaluate historic architecture in terms of parametricism principles. This would get away from the application of other value systems in the discussion of Parametricism and would critique it with its own logic.
On the design methods that applied to Parametricism, Schumacher writes:
“Do not forget that parametricism as a style is not only defined via its design techniques but also via its ambitions and certain key features of its results, i.e. the general increase in the spatial complexity (sustaining an increase in programmatic complexity) as well as the general intensification of relations, i.e. an intensification of communication between spaces within a building and between the building and its surroundings. We need to understand what all this is good for in the end. What are the advantages of parametricism for the progress of our civilisation?”
Is ZHA a parametric firm:
This was very articularly answered by Matei in some earlier comments, but Schumacher adds:
“ZHA projects are always following the heuristic principles of parametricism , even if not all of them are always computationally driven. But we should also not forget that an intelligent and talented designer can – to a certain extent – articulate adaptive correlations between object and context, volume/façade and environmental parameters, between the variously differentiated subsystem within the building via mere modelling without deploying algorithms. The intelligence that is able to invent and think through such correlations is prior to its computational implementation. And, to a limited extend there can be ‘computation without computers’.”
And finally, on emergence vs parametric
“You make an interesting point about GA s in the context of a circumscribed optimisation problem, but you might decide to speak about bounded vs boundless emergence, or introduce the concept of relative degrees of circumscription with respect to emergence.”
For some reason ‘degrees of boundedness’ really resonates with me and has helped start me thinking about what happens in the middle of these two extreme positions.
—
I am still tentative about agreeing with Schumacher, but what is the alternative? People are more than willing to kick him, but are reluctant to put forward their own vision – I very much belong in this group. In this sense perhaps Parametricism has been unsuccessful at getting architects to consider how ”harnessing generative computational processes” advances architecture, for we have become so focused on our niche it is hard to see the advances of architecture through the details of parametricism. In a weeklong twist of fate, I have become sympathetic to Parametricism and Schumacher’s arrogance, and I fear yet another blog post might need to be dedicated to Schumacher once my copy of The Autopoiesis of Architecture arrives.
William Mitchell sits between architect, science fiction writer, and perpetual optimist. The world needs more people like him – if only to combat the ecological pessimists, and baby-boomer guilt. His enthusiasm for the future of architecture helped spawn the MIT Media Lab, and gave rise to some particularly entertaining books (ME++ and The City of Bits, among others). Like anyone who predicts the future, Mitchell is wrong more than he is right. He is definitely wrong in The logic of Architecture. However, the myth Mitchell tells in The logic of Architecture is not interesting for Mitchell’s incorrectness, but for what this incorrectness can teach us about our own myths.
Roughly speaking, Mitchell’s thesis can be broken down into three parts:
We can express architecture as words, and these words can be expressed in a logical syntax.
We can use grammar to anticipate what will come next in the logical syntax.
We can use this to design architecture.
Mitchell wrote this in 1990, so while logic programming and shape grammars were in existence (Mitchell did work on them in 1978), Mitchell’s contribution was to provide a framework to popularise these concepts. Much like the 1960′s space planning movement, the projects that flowed from The Logic of Architecture were fruitless applications of enthusiasm and computation, although it did produce some sweet patterns. We are still living with the residual effects of this, and the following list is lessons that I think can be taken from the failure of The Logic of Architecture:
Architecture is not binary
One of the most valuable lessons I learnt at architecture school was to be cautious of anyone speaking about binaries – they are most likely wrong. Mitchell is no exception. Many of his grammar rules are based on the idea of something being ‘adequate’; the structure is adequate to hold up the building, the room is adequately proportioned for the function, ect. These are all binary conditions, the structure is either adequate or the structure is not adequate. This naive view of the world masks one of the biggest problems with Mitchell’s system: in the real world there are degrees of adequacy and the architect’s main job is satisficing the conflicting objectives of a project. Resolving conflicting goals in a digital system remains an unsolved problem, and a significant one at that. I will return to this point at the end, but in short, the real world is far more complex than we often assume it to be – and binaries are a give away that something is oversimplified.
Structure is not logic
Small section of Wikipedia links by Juhan Sonin
Mitchell’s logic language describes how something looks and how it relates to other objects. For example you could say the wooden block is on the metal table. In our ocularly dominated world this makes sense, but I can’t help but wonder how Mitchell would describe Wikipedia if he saw it. It is tempting to describe W as a network of links, since this is how we perceive Wikipedia when we use it. The diagram for this would be like the one above, times about a million – a super complex description. However in reality Wikipedia is structured like the diagram below, pretty simple. I would love to think such a diagram exists for architecture, and we can get away from these verbose descriptions of what something looks like, and go into the true logic of the object.
Actual structure of Wikipedia from Wikimedia
Language is plural and restricting
Just like there are many ways to describe Wikipedia, there are many ways to describe architecture. Mitchell’s development of a language in The Logic of Architecture is not particularly novel. But what is interesting is his realisation that languages defines the scope of architectural possibility (the search space) and the best language defines all the design options we would possibly want, without being cluttered with the ones we do not want. So when Mitchell shows an image of Tarski’s World, I am blown away anyone would want to design with it (you can with this java applet).
But then again, scripting is not the most obvious way to describe a building. It is interesting to think of Grasshopper, and GC and Processing, in twenty years time, looking as clunky as Tarski’s World. I wonder what part of the design space we are currently missing by describing our buildings through mathematics.
Do it, don’t talk about it
Confirmation bias runs rampant in architectural academia. It is too easy to design a new way of producing architecture, test it on an idealised project and then extrapolate that you have changed the world. Or alternatively (as apparently happened at ACADIA this year) look to French continental philosophers as confirmation of your correctness. Had Mitchell tried to produce more than reproductions of 1:200 plans in The Logic of Architecture, I am sure he would have reconsidered his thesis in light of the gritty reality of real projects. In Mitchell’s time this would be a tall ask, but today, with so much of the underlying technology in place, there is not reason not to make these tools. So along with anyone talking in binary, I am immensely suspicious of anyone who describes a theoretical design tool, or one only tested on hypothetical projects. Thankfully Mitchell gave up doing this after The Logic of Architecture and just started telling us how the world was going to be – and Michell’s reality is not bad at all.
And with that, I think Digital Morphogensis is officially one year old, thank you to all the readers, commenters and twitters for helping make it happen.
Edit: 11-December-2011
Tarski’s world was mistakenly called Peano’s World. Thank you to Ruwan for catching this.
I have been neglecting this blog lately, but it is for a good cause. My time has been spent setting up a new website: parametricmodel.com, which is basically Wikipedia for parametric model components.
The site is straight from my Ph.D. research where I an currently looking at reuse within parametric models. It is quite striking how little people reuse parts of their models in subsequent projects, or use parts from other peoples models. This is surprising when you consider how often the same problems are solved in a parametric model. An ad-hoc community of people sharing components has sprung up on the Grasshopper forum but from my research, it seems people turn to the forum as a last resort, mainly because the forum is hard to search, makes tracking changes difficult, and provides components in ways that are not always useful. The idea with parametricmodel.com is to provided a slightly structured environment where people can easily post their components (and hopefully announce it on the Grasshopper forum), make revisions to others and find the component they need. In my own work, I have found that this little bit of structure – such as explicitly defining inputs and outputs – is critical in reusing your models.
I stuck up a couple of components I often use, including a revision to Giulio Piacentino’s ‘Bake with color’ script that works with Grasshopper 0.7.
Please add your components, make revisions to the existing ones, and take from the site (all the content is creative commons).
Any feedback would be appreciated, either in the comments or via email (contact form under ‘About’ on right menu).
Edit: 12 December, 2010
Matie has an interesting follow up post on his blog here, where he discusses how difficult it is to reuse parametric models, and provides example Grasshopper definitions from his own projects.
And Parametricmodel.com has had its first user contributed submissions and edits, as it starts to grow.
rss feed
) – like my review of 
This means most of the models people are creating in Grasshopper, even the really really really large ones, are totally unstructured, like the example in the next section:
