utodesk’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.
David Rutten
“…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
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
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
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