This review of Mark Burry’s Scripting Cultures (On Amazon) – like my review of

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 experienced scripters 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 journal available 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:

1. Scripting cultures
2. Contextural summary of computing, scripting and speculative design
3. Cultural defence
4. Resources
5. Dimensions
6. Scripted productivity: Gaudi’s rose windows
7. Composition and form
8. Simplifying complexity for fabrication
9. Scripting narrative space: Our world and The Third Policeman
10. Performative scripting
11. Cultural account: Scripting and shifts in authorship
12. Glossary
13. Scripting tools
14. Recommended reading

—

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 2^nd, 3^rd and 9^th 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). 4^th 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 full list of most popular nodes can be downloaded here.

2. Strangely unpopular

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 159^th place. There are a few reasons for this:

1. Cluster has only been available in Grasshopper 0.8 while the models in the Grasshopper forum stretch back to version 0.6.
2. People are probably more inclined to share small snippets of models on the forum and therefore don’t require clusters.
3. 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.

Download model

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/

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.

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.

Yeti is now available for download from yeti3d.com. It is still a proof-of-concept more than a parametric modelling environment, but there is enough going on that others may find it useful – particularly for setting the underlying geometry of models.

The latest version allows the generation of custom objects (shown in the video above). The geometry remains really limited – points, straight lines and circles – until I sort out how arrays of data will work.

Yeti is written in C# and I made the source available at bitbucket in case anyone is curious about how it goes together or wants to make it better.

Innovation comes from funny places. In 2005 Apple introduced the Dashboard; a largely impractical application that overlaid the desktop with little Widgets reminding you of the time, weather and stock-market prices. The most redeeming feature of the Dashboard was that when you added a new Widget to the Dashboard, it made the screen ripple like it was made from water, and since not all computers at the time were powerful enough to do this, the Dashboard’s rippling became an unofficial performance benchmark. Despite the frivolous nature of Dashboard, the Widgets have an important legacy (other than being a precursor of the iPhone apps).

Dashboard Widgets are made up of HTML, CSS and Javascript – the same stuff websites are made from. Except Apple added one extra word to the Widgets vocabulary: canvas. This little, propitiatory, modification of HTML, allowed Widget designers to write Javascript code that drew shapes in the Widget, much like Processing.  Three years later, in 2008, and HTML standard was updated, to standardise the drawing of drop-shadows across browsers (a big deal if you are a webdesigner) and to include the canvas tag as part of the official HTML standard (a big deal if you are an architect). Now in 2011, ‘canvas’ has been extended to allow the drawing of 3d shapes with WebGL.

What is WebGL?

Prior to WebGL the only practical way of drawing 3d objects in a web-browser was through a plugin like Flash or Java (not the same as Javascript). Plugins are slow because the when the plugin code decides to draw a line, it must ask the plugin, which must ask the webbrowser, which must ask the operating system, which must ask several other layers of the computer, to draw the line onscreen. This journey through the grapevine is inevitably slow. WebGL skips these layers by allowing Javascript access to the GPU, meaning WebGL can send data straight to your videocard to be rendered. WebGL also has the advantage that it is native to the browser, so users don’t need to download or install any additional plugins to view 3d content – currently only the latest versions of Chrome and Firefox support WebGL, but all browsers (except possibly IE) will support it in the coming months.

Why WebGL is important to CAD

It is inevitable that in the near future CAD models will be able to be viewed in a browser using WebGL. There are already some early examples of this happening with PythonOCC/WebGL which exports 3d models to WebGl; the Surface Explorer, which draws doubly curved surfaces from equations; and most beautifully in the Google Body Explorer, which allows you to interact with a rather complex 3d model of the body. And I have it on good authority that at least one major CAD manufacturer is making a ‘dropbox for CAD files and project data.’

With 3d models now viewable on the internet, the critical question becomes how much interaction will be enabled. Will you be able to view associated model data? Will you be able to modify a model? Will you be able to generate a model? Will the browser become your preferred way of designing?  Some early applications like CloudSCAD, 3dTin, Shapesmith (shown above) and TinkerCAD, would say ‘yes’ to all of the above. There are some advantages to this approach:

1. Users don’t have to download software and updates can be made instantly.
2. Theoretically the application is cross platform and cross device.
3. Users can use less powerful computers to do more complex tasks by offloading the work onto the server. The server might be able to do the rendering or object population, the server could also load a really large model while giving the user a simplified version of the area they are working on. It is also a better use of resources to have one server constantly working hard rather than every user intermittently working their computer hard.
4. Live connections to other databases. A few years ago I helped start ProductSpec, and it has always been on the roadmap to have the Productspec database linked to CAD models so that as manufactures change product data, this is reflected, in realtime, within the model.
5. All of the associated advantages of cloud computing: less piracy, more payment granularity, online storage/backup ect.

However even with the examples of early WebGL CAD software and all the advantages listed above, I am still not entirely convinced we will be designing with WebGL in the future. For one thing CAD manufactures, who have a lot invested in large code bases, are going to be slow making the switch. There may be a new generation of companies that develop WebGL applications but (at least initially) they are going to look underdeveloped compared to their desktop rivals. Secondly, as painful as C++ development can be, writing a CAD program in Javascript is simply sadistic – there are problems with browsers being consistent, there are performance issues, there are security issues. Instead I think WebGL is going to spark a new generation of software, which are more interactive than a printed drawing and less featured than a full fledged CAD package.

It is interesting to see that the next iteration of architectural representation isn’t emerging from the past 20 years of discourse flowing out of architectural theorists and philosophers, but it comes from a technology Apple developed to add a bit of bling to the desktop.

What are threads?

Roughly speaking, a thread is a list of tasks for the processor in your computer to execute. All programs and scripts get compiled into a thread of tasks, which are then feed through the processor in linear order to produce the desired outcome. Conceptually this could be thought of as a chain of grasshopper nodes being evaluated one at a time by the processor.

One processor works on the graph while the other three sit idle

Threads get interesting when you have more than one processor, like on the Quad-core Intel processor, which has four processors sitting in parallel. With a multi-processor computer, you can have each processor working on a separate thread. So the Quad-core processor can work through four threads simultaneously (it can actually work through more due to some processor magic but that is getting a little technical). The difficulty with a multi-processor computer is that the processors can not ‘talk’ to each-other, so (as shown above) a thread can only go through one processor at a time. This essentially means that if one of the processors on the Quad-core processor gets a really long thread of tasks, it cannot ask the neighboring processors to help out with some of the tasks, even if they are sitting idle. This is why sometimes you will be updating a really complex model in Grasshopper, and see the processors only working at 25% – there is only one thread going through the processors so only one of the four processors is actually working.

Multi-threading

Since the processor can not break a single thread into multipul strands, we have to break the tread up for the processor. Essentially rather than giving the processor one long thread of tasks, we can break the tasks up into little bundles of work, and generate a thread of tasks for each bundle. That way we can send a single thread of tasks as multipul threads and get each processor to work on a little part by itself.

By splitting the thread up, it can be sent to more than one processor

Multi-threading in Grasshopper

To test threading in Grasshopper I decided to recreate the Project-point-to-surface node in Grasshopper. The full node can be downloaded from Parametric Model. The critical line of code in the node comes within this for-loop:

for(int i = 0; i < total; i++)
{
  if(p[i] is Point3d)
  {
    int tempI = i;
    Point3d tempP = (Point3d) p[i];
    taskInfo task = new taskInfo(tempI, tempP);
    System.Threading.ThreadPool.QueueUserWorkItem(pntToSrf, task);
  } else done--;
}

Essentially this loop works its way through every point passed to the node. It then adds the point and the point’s index to a taskInfo object – a custom object created to store the information about the point being projected to the surface. The point is then projected onto the surface by calling the pntToSrf function and passing the taskInfo object in this line:

    System.Threading.ThreadPool.QueueUserWorkItem(pntToSrf, task);

Basically this line of code calls the pntToSrf function, but rather than calling it on the main thread (as you would do in a singally threaded application), it sends the function to the ThreadPool where a manager runs it on the next available thread. The ThreadPool has many different threads running through each processor in parallel, so the manager will send the pntToSrf function to whatever processor is not doing any work, which utilises the power each processor.

A couple of tricky things happen inside the thread, like the arrays are locked whenever data is written to them, to prevent the threads sending data into the array simultaneously:

lock(locker)
{
  outP[index] = myPoint;
  outUVP[index] = uvPoint;
  outD[index] = myDis;
  done--;
}

Finally, since the threads are executing co-currently to the main thread, we have to pause the main thread until the other threads have finished processing before returning the data from the node. For simplicity sake I have used a really naive method of waiting, which loops until the right number of tasks are done.

while(done > 1)
{
  System.Threading.Thread.Sleep(2);
}

And that is it.

In terms of performance, on my quad-core computer, the normal Grasshopper srfCP node can project 1,000,000 points onto a sphere in 10.0 seconds. Compared to both Digital Project and GC, this is remarkably fast, although it is nothing like the performance of Open Cascade. The same task performed with my threaded srfCP node takes 4.5 seconds, which is roughly a 2X improvement over the non-threaded version. You will notice using four cores does not result in a straight up 4X improvement, this is in part because some processor power is used to manage the threads, and partly because aspects of the code still happen in serial.

Native types in Grasshopper

outP = new GH_Point[total];
outUVP = new GH_Point[total];
outD = new GH_Number[total];

Some keen eyes would have picked up that the C# node is returning an array of GH_point’s rather than an array of point3d’s. When a C# node returns a point3d, this is automatically converted by Grasshopper into a GH_Point (allowing it to be baked ect.). This conversion is computationally expensive, presumably because Grasshopper is checking the data is valid. To avoid this performance hit, we can sidestep the conversion by giving Grasshopper the data back in its native format, a GH_Point. The other native Grasshopper formats can be found under Grasshopper.Kernal.Data. Similarly if the inputs to a node are of a specific type, Grasshopper does an automatic conversion. By asking for the inputs as a System.Object this conversion can be avoided.

A word to the eager

While multi-threading offers significant speed improvements, it is not without downsides. It can be challenging and frustrating to debug threaded code since interactions between threads can throw unforeseen errors from bugs that are invisible in the Grasshopper IDE. These errors will often crash Rhino: save frequently. Furthermore, not all functions in Rhino 4 are thread safe. So if you use the unsafe function of  plane-brep intersection in different threads, you will  either crash Rhino or end up with strange results. Rhino 5 addresses some of the thread safety issues and once it moves to .Net4.0 there will be access to even easier threading functions. For now take this post as an explanation for why CAD software hasn’t gotten any faster in the last three years, but expect to see significant performance increases in the near future once CAD finally catches up to processor developments.

For more information about multi-threading I recommended Joseph Albahari’s excellent tutorial on C# threading.

An early sneak peak at a project I have been working on: live parametric programming for Rhino. As you edit the script, in real time, the geometry is created and modified. There is slightly more going on behind the scenes than just phrasing the text and turning it into geometry, because it is based on the Yaml language (hence Yeti), which allows references between objects. So you can name an object with a ‘&’ and refer to it with a ‘*’, effectively establishing a parametric relationship between the objects. It is still in the early stages, but the parametric engine is there, as is most of the phrasing stuff, so hopefully I can push out a demo / the source in the near future.

I have been neglecting this blog lately, but it is for a good cause. My time has been spent setting up a new website: parametricmodel.com, which is basically Wikipedia for parametric model components.

The site is straight from my Ph.D. research where I an currently looking at reuse within parametric models. It is quite striking how little people reuse parts of their models in subsequent projects, or use parts from other peoples models. This is surprising when you consider how often the same problems are solved in a parametric model. An ad-hoc community of people sharing components has sprung up on the Grasshopper forum but from my research, it seems people turn to the forum as a last resort, mainly because the forum is hard to search, makes tracking changes difficult, and provides components in ways that are not always useful. The idea with parametricmodel.com is to provided a slightly structured environment where people can easily post their components (and hopefully announce it on the Grasshopper forum), make revisions to others and find the component they need. In my own work, I have found that this little bit of structure – such as explicitly defining inputs and outputs – is critical in reusing your models.

I stuck up a couple of components I often use, including a revision to Giulio Piacentino’s ‘Bake with color’ script that works with Grasshopper 0.7.

Please add your components, make revisions to the existing ones, and take from the site (all the content is creative commons).

Any feedback would be appreciated, either in the comments or via email (contact form under ‘About’ on right menu).

Edit: 12 December, 2010

Matie has an interesting follow up post on his blog here, where he discusses how difficult it is to reuse parametric models, and provides example Grasshopper definitions from his own projects.

And Parametricmodel.com has had its first user contributed submissions and edits, as it starts to grow.

The past week was filled with software launches. For me the most curious of these launches is Dassault’s DraftSight, a clone of AutoCAD (free to download here). Dassault are better known for CATIA and Solidworks, two high end, 3d parametric modeling programs that champion file to factory manufacturing.  Previously Dassault half-heartedly had a go at 2d modeling with their DWGEditor, but DraftSight is a totally new product and a serious move into this market. I have heard some colourful explanations for this move, including file to factory not being adopted / profitable, and the 70′s being back in vogue. To me it seems like Dassault are trying to kill Autodesk’s cash cow – AutoCAD – which retails for approximately US$4ooo a licence. Significantly DraftSight stole the thunder from Autodesk’s release of AutoCAD OSX by releasing before them and for free, which is bound to have an impact on the profitability of AutoCAD OSX if everyone is testing a free alternative before the launch. So far the reviews seem very positive, I am not a serious AutoCAD user and I know people who use it are very particular so I defer any review to them (Solid Smack have a good comparison). Ironically the features DraftSight is missing (and probably unlikely to get) are the features Dassault is best known for – constraint modeling and 3d modelling – two features that have been integrated into recent versions of AutoCAD. In some bizarre way, Dassault’s focus on basic 2d modelling makes sense, although a battle over 2d is not something I thought I would see in 2010 and it seems AutoDesk were banking on that as well. I am sure there are some very interesting meetings happening at Autodesk right now as they plan their response.

At the same time DraftSight was released, Autodesk released AutoCAD WS for the iPhone for free (iTunes link). There is something jarring about seeing a 1970′s interface on a touch based device. Still this is probably the cutest, if unimaginative, translation of AutoCAD to date. Unfortunately it is almost crippled by Apple’s arcane file management on iOS, requiring users to upload their .dwg’s to an online server, and be connected to the Internet with their phone to be able to view them in the app. I would like to think Autodesk has something larger planed for iOS than translating desktop apps. A demonstration of what might be coming is the Nervous System iPad model maker (video below), which takes advantage of the touch interface to conceive of a new way of generating their two layer rings.

And also launched this week was the Evolute tool kit for Rhino. Evolute has previously contracted to companies such as Gehry Technology to optimise surfaces, and in the process they built up a formidable body of research on how best to carry out surface optimisations. The Evolute tool kit is their first attempt at commodifying this knowledge by making parts of their in-house tools available through a Rhino toolbar. Evolute is being understandably cautious about opening up these tools, and unfortunately the current Beta version is crippled by some rather harsh restrictions that make it impossible to test out the utility of these tools on large scale projects or without an Internet connection. When it does work, the toolbar enables a type of low-polygon mesh editing and provides tools to optimise the paneling of a mesh. Thankfully they have just put up a series of tutorials on how to use the software because I was finding it seriously confusing. In many ways Evolute’s success depends not on their research, but the quality of these videos and documentation; they can black box sophisticated algorithms all they like, but the user still needs some understanding of what is going on to operate the tool. The same can be said of Dassault’s DraftSight, which is conceptually not very far from their DWGEditor, but the DrafSight interface is in a different league, with its familiarity, responsiveness and cross-platform capabilities. So perhaps this was not a week of new tools, but a week of new interfaces to old algorithms.