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
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
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:
