CASE Party @ AU2013. We had over 500 AU guests packed into the Rockhouse in Vegas! |
AU2013 General Thoughts
I have conflicted feelings about large conventions, especially ones that are so focused on the goings-on of one company. Autodesk University is the end of the year hoopla for a company that is the most influential and pervasive AEC tool supplier in the industry. For a single week, ~9000 Autodesk employees, customers and fanboys* descend on Las Vegas for classes, product news, conversation, and gambling.*can something be done about the female-deficiency in the world of technologists?
Through motivational speaking and showy salesmanship, the keynote addresses asked us to consider reaching 'outside' for ideas and expertise (Autodesk Consulting, perhaps?) and to consider the advantages of a cloud-based approach to products (Software for rent?). However, the Vegas-style showmanship (Penn & Teller) and high volume marketing (disco robot) do very little to address big picture questions about the practicality and vision of the new technological realities that Autodesk is advocating for... and ultimately trying to sell.
With the broad spectrum of parametric tools, iterative analysis processes, and simulation environments now available, are these new processes making a tangible impact on the statistic that 40% of the world's carbon emissions come from buildings? Have our tools helped us move the needle which shows that 70% of buildings go over their construction budget? How will the cloud enable us to deliver architecture to the 65% of the world without internet... the parts of the world that arguably needs architecture the most?
However, these questions should also fall on the plate of Autodesk's users as they are the ones putting these slick new pieces of software to work. We should remember that the goal of a better process is not a better process... the goal is a better decision leading to a better building.
But I digress... as this is a computational design blog and I do want to spend some time reviewing what happening in that space at Autodesk. For another perspective, I also encourage you to read Daniel Davis's coverage of the Computation for BIM workshop over at DesignReform.
Zach Kron's Introduction to Dynamo class, a 90 minute course packed with architects, engineers, and BIM enthusiasts. |
Dynamo - A Canary in a Coal Mine?
Autodesk has not been known to be a purveyor of free and open source software. Sure, there are and have been smaller, 'low profile' projects in the past. This year we saw Dynamo make its way into Carl Bass' main stage keynote presentation and affirm a commitment to delivering a computational design tool to the masses. Dynamo is free, Dynamo is open source, and, based on class attendance, there is a lot of good will and buzz around seeing it succeed. The significance of having Autodesk embrace open source as a means for delivering a key product can not be understated and I hope it succeeds.
I'm rooting for this canary to make it because the main beneficiary is going to be the design community.
And what a difference a year makes. We have seen Dynamo grow from a laboratory test in Grasshopper-cloning into a mature graphical language uniquely tied to the Building Information Modeling world of Revit. That's not only interesting... that's cool. Designers can control and automate many aspects of the Revit model through the graphical node-based interface to achieve form creation, parameter manipulation, and information interoperability. Things that used to require expertise in Revit API manipulation can now be more easily achieved with some graphical wire work.
But there is more to Dynamo than just Revit. The team revealed that DesignScript is in the early days of being merged with the Dynamo core. DesignScript has long been in development as a scripting language for designers. As part of Dynamo, it will now be used as a means for translating Dynamo's graphic nodes to a code-based representation... and back again. It's a interesting computer science experiment at this point but I have yet to see a compelling use case for a designer looking to get their project out the door. I will reserve further judgement on this development until it has time to mature and I have had time to test it out.
Here are something observations about what works and what doesn't... Disclaimer: Given the pace of development, this review is already obsolete at the time of posting.
What works...
- Stability: Dynamo looks and feels solid. This is a huge development as users need the confidence to be able to try things out, make mistakes, and not worry about their computational ecosystem crumble down when connecting the wrong wire. Are their still bugs? Yes... but they have become more and more minor that I can now recommend Dynamo be tried out in a production environment. If you find a bug, be sure to report it and the team will get cracking on a solution!
- Revit Elements: The key advantage of Dynamo is how it is tied into Revit to control model elements and information. Dynamo's novelty is how you can design systems for placing families and controlling parameters... you can even use it to create a sheet set if your heart so desires. The tie between design and production is an area I fully expect Dynamo to continue building on.
- Package Manager: We all know that a major contributing factor to Grasshopper's success is the plug-in community that is constantly building new tools. The Dynamo Package Manager let's designers share custom nodes and scripts through a common marketplace that is accessed through the main UI. There are many packages available here and the workflow for getting new stuff is easy and straightforward. Be sure to check out LunchBox if you are looking around :)
- Python: Designers can code their own nodes using Python. This is a smart choice as it is a very popular language among designers. The implementation needs some work (see below), but it is an essential feature that I hope to see grow in the coming months. You can find some of my older Python samples at The Proving Ground wiki...
What needs work...
- Units: This is easily at the top of my list. Dynamo lacks a good concept for handling units in relation to the Revit document. This is not uniquely a Dynamo problem because Revit's API is built around decimal feet. Dynamo simply uses the same assumption which is a potential deal breaker for designers not working on projects in the US. There simply needs to be a better concept for linking Dynamo to the project units in the active document.
- Python: Yes it works... but it could be so much better. I would like to see better auto-complete for Revit API methods. Python could be a great way for a user to explore the Revit API but for now it feels like taking a shot in the dark.
- VB/C#: Why not include support for other .NET languages? Considering that most Revit API SDK samples are in either VB.NET or C#, would it not make sense that the Dynamo nodes also support these languages?
- DesignScript: As stated before, I don't have a full opinion on this as it is still early days for its implementation with Dynamo. In my previous experience with DesignScript on AutoCAD, the language does not feel any more or less 'intuitive' for designers when compared to other scripting languages. I am happy to have developer Luke Church make a case for me... and he seems perfectly capable.
- Color: I am with Daniel on this one... ditch the yellow/orange node look. This is a purely subjective opinion, of course. Personally, I could see Dynamo benefiting from a different color scheme. OR just give users complete control over the look of their canvas.
In 'Conclusion'
Dynamo is going to be a product to watch going into 2014 and CASE is really excited to be supporting it with our clients. As a consumer, I am pleased to see Autodesk embrace an open source approach to software development. As a designer, I am excited to have another tool for making cool architecture with BIM. As a consultant, I am thrilled to explore ways of implementing this tool with CASE's clients.
If you are interested in learning Dynamo or have ideas for how it could benefit your project, please contact us!
EDIT: Changed a the wish about adding reference to .NET assemblies in Python. This is certainly possible.
clr.AddReference('Newtonsoft.Json.dll')
from Newtonsoft.Json import *
import Newtonsoft
Easy peasy....
If you are interested in learning Dynamo or have ideas for how it could benefit your project, please contact us!
EDIT: Changed a the wish about adding reference to .NET assemblies in Python. This is certainly possible.
clr.AddReference('Newtonsoft.Json.dll')
from Newtonsoft.Json import *
import Newtonsoft
Easy peasy....