DesignScript – Autodesk

Daniel Davis – 27 June 2011

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:

  1. pt = Point.ByCoordinates(1,3,4);

The associative dataflow aspects come into play if you write:

  1. A = 4;
  2. B = 3*A;
  3. 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:

  1. double: &B (*A * 3)
  2. 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:

  1. start = Point.ByCoordinates((1..5..1), 1, 0);
  2. end = Point.ByCoordinates((1..5..1), 5, 0);
  3. 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.

Design Script interface

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.

Share

Subscribe

Join the mailing list to receive an email whenever a new post comes out. Otherwise, you can follow me on Twitter, or add the RSS feed to your reader.

8 comments

  • David Rutten 20 July 2011 at 9:32 pm

    “…Grasshopper where the interface came first and the Grasshopper xml language is the consequence.”

    What xml language? There is no ‘script’ running behind the scenes in Grasshopper that could potentially be modified or written manually. It’s all precompiled code (dlls, basically) chatting with each other.

  • Daniel 21 July 2011 at 2:02 pm

    Hi David,

    The Grasshopper .ghx file (if it is not saved as binary) is an xml file.

    I did not mean to say that the Grasshopper works through the interface generating an xml file that is parsed into a parametric engine – without knowing exactly how Grasshopper works, presumably the interface invokes modifications to a DAG representation, and at a later stage this DAG can be saved as a Grasshopper .ghx (xml) file. The point is that the .ghx file is the consequence of the interface / internal representation and while it could be modified or written manually, this is not the intention.

    This is in contrast to Robert Aish, who is trying to generate a universal language, which a visual interface can save to, which a programmer can script with, which a CAD program can record actions with, and which can drive a Revit family. There may be some nuance in whether the visual interface generates a Design Script that is parsed through the parametric engine or whether the visual interfere will just invoke the Design Script parametric engine directly.

    Robert Aish directly compares the length of Design Script files with the length of Grasshopper .ghx files. This is of course a facetious comparison because the .ghx file incodes more information than the Design Script file – like the location and apparence of nodes. Which is why I say “Autodesk are precariously close to developing a universal language too general to be of use to any particular interface” clearly a visual interface can not save to Design Script without loosing information.

    Having said that, I think being able to compile Design Script files into Toolbar icons / Revit Families is a pretty interesting development. Anything like that on the cards for Grasshopper?

    Daniel

  • Dimitris 5 October 2011 at 3:51 am

    Nice post there! I watched the video about a year ago, and was looking for any new developments since then, but to no avail. I don’t like this secrecy at all, but the language does look promising, as the possible integration with revit families does… Also, placing more importance on the language than on the interface is a good thing, but that will mean that it will have much less appeal to a lot of people. What I understand is that they are making a tool having in mind more ‘advanced’ users (if i remember correctly, at some point he is answering a question saying something like ‘… we’ll pick up grasshopper users after they have reached the end of the learning curve in grasshopper’) but this will make it even harder for people to approach it…
    Looks like there is a new presentation about designScript in this year’s AU, so lets see how it is developed….

    • Daniel 5 October 2011 at 6:52 pm

      Dear Dimitris,

      Thanks for sharing the link to the AU presentation, I think there is also a workshop at the Design Modelling Symposium in Berlin this Friday (link).

      In my heart I am really hopeful but rationally I question whether all this secrecy is preventing them from ‘failing fast’ and iterating to the next idea.

      Guess the only way to know will be to watch the presentations 🙂

      Daniel

  • Mentioned 5 November 2011 at 3:14 pm

    […] 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 […]

  • Mentioned 6 August 2013 at 10:58 pm

    […] 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 […]

  • Mentioned 11 July 2015 at 4:27 am

    […] I think I am particularly interested the idea of associative programming from a user’s perspective. I have the feeling that, at least at an introductory level, it’s far more intuitive and manageable to create and maintain a hiearchy of objects and their interactions, rather than controlling their flow state at run-time. I once had a very interesting conversation with Robert Aish on this topic, and he admitted these were some of the ideas he had in mind when developing Design Script, which featured a custom scripting API that mixed imperative execution with associative declarations. You can read more about it here. […]

Leave a comment