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