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. 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
Sorry there hasn’t been many posts recently, I have been spending a lot of time on Yeti. Version 0.2 is ready for download at yeti3d.com. Above is a video tutorial I made for reproducing Axel Kilian’s Generative Components Roof with Yeti. It might go through stuff a bit fast because I tried to get everything into one video. Next up is trying Yeti out on a few of my own projects in the coming weeks.
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.
Autodesk’s ‘acquisition’ of CAD visionary Robert Aish is about to reach maturity and the return on investment is looking a little shaky. After three years working at Autodesk, Robert Aish has tentatively been previewing his latest thesis: DesignScript.
Although you wouldn’t know it.
The release of DesignScript parallels Aish’s release of Generative Components while at Bentley: presentations and papers at conferences; faux secrecy; and an extended private alpha with invited practitioners. It worked for Generative Components in 2003 when the computational design community was primarily limited to an old boys club of conferences and invited projects. In 2011 it remains to be seen if you can successfully launch a project while ignoring the expanding computational design community online - there is currently no details of DesignScript on the internet and it took me a month of emailing Autodesk to finally get a video of DesignScript (which they posted publicly here).
So in an internet exclusive, I am going to save you a month of emails to Autodesk and just tell you what DesignScript is.
The language
DesignScript is a new parametric programming language, which Aish has seemingly produced by combining Generative Components transaction files, with Python, mixed with dataflow programming techniques. Initially it looks like a pretty standard scripting language, to generate a point you write:
pt = Point.ByCoordinates(1,3,4);
The associative dataflow aspects come into play if you write:
A = 4;
B = 3*A;
A = 5;
In a language like C, Python or Java, this would evaluate to A = 5 and B = 12. However in Draft Script A = 5 and B = 15. The reason for this is that on line 2, B is not set to three times the current value of A and is instead related to A, so a subsequent change in the value of A also effects the value of B. This is a bit like how a spreadsheet, or any other dataflow programming language, operates. However the metaphor gets mixed when the value of A changes because unlike a spreadsheet, where a variable can only be defined once (a cell can only have one value), in Draft Script the value of A is defined twice and uses a normal procedural paradigm to decide what version the final value is. Confusingly this means the order of certain statements (A=4 & A=5) matter, while other statements (B = 3*A) could be anywhere in the script and have the same outcome. Contrast this with Yeti:
double: &B (A * 3)
double: &A 5
This evaluates A = 5 and B = 15. You will notice the order of A and B do not matter however, to avoid confusion, Yeti only allows you to define each variable once.
DraftScript also has some pretty neat handling of lists. Take for example:
start = Point.ByCoordinates((1..5..1), 1, 0);
end = Point.ByCoordinates((1..5..1), 5, 0);
line = Line.ByStartPointEndPoint(start, end);
The code (1..5..1) defines the list of numbers: 1, 2, 3, 4, 5. So the first line actually produces 5 points starting at 1,1,0 and ending at 5,1,0. Straight lines are then drawn between these points on line 3, starting with the first item in the start points, and starting with the second item in the end points (signified by the <2>), making diagonal lines between the points.
The interface
DesignScript is currently just a scripting language, and while Autodesk focus on getting the language right it is clear this is the foundation of something quite a bit larger. Like a Generative Components transaction file, there is no reason a DesignScript could not be generated from a visual interface – or even from the action of modeling itself. This is the opposite approach to Grasshopper where the interface came first and the Grasshopper xml language is the consequence. Autodesk are banking on this approach to deliver one universal language to underlie many different parametric interfaces, and at the same time Autodesk are precariously close to developing a universal language too general to be of use to any particular interface. However the real draw of DesignScript is its larger interface: AutoCAD.
AutoCAD
Lets face it, the worst part of Generative Components is Microstation; architecture definitely went through its hipster period in the 2005 when the most innovative architecture in the world was being produced on software that belonged in the 1980′s. AutoCAD is perhaps no better, however I am fairly confident it is the most installed CAD software in the world and, for CAD monkeys of a certain generation, the most known.
The killer feature of DesignScript is that it can be compiled into an AutoCAD feature, so along side your line tool and your square tool, sits the beam tool you wrote in Design Script. With AutoCAD and Revit both belonging to Autodesk, they must be thinking about compiling DesignScript into Revit Families. Queue jokes about Revit stealing another feature ArchiCAD has had for 20 years. But unlike ArchiCAD’s GDL language, which is this badly neglected Visual Basic like language, DesignScript is being developed at the forefront of Autodesk’s research efforts. Compiling scripts into Revit families would eliminate the current practice of baking Grasshopper or Digital Project models and importing them as static geometry to be sliced and diced by Revit. Instead you will be able to open the DesignScript model in Revit and associate it directly with the geometry in Revit, if you make a change in Revit you don’t need to go back and rebake the geometry, the DesignScript model (and the meta data) updates automatically – or so I hope.
The future of DesignScript
Despite three years of development DesignScript, in its current state, appears quirky rather than revolutionary. Its future success depends heavily on the forthcoming interfaces – something Robert Aish has never quite got right – and the integration between AutoCAD and Revit – something Autodesk have never quite got right. While these look uncertain at the moment, if Autodesk and Robert Aish can pull them off, DraftScript may make parametric modelling as common as the Revit BIM models it resides in.
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:
