The latest update to Dynamo Core (which for now you can use via Dynamo Sandbox) has some really interesting enhancements, both in terms of usability and performance. Check out Sol Amour’s two blog posts that introduce Dynamo Core 2.12.
As it had been a while since I’d tried the MaRS graph in a new drop of Dynamo, I went ahead and loaded it.
I immediately noticed a couple of things: it was referencing an old, now-deprecated version of the Solar Analysis package, so I updated to the latest & greatest version on my system and then reloaded the graph to allow me to opt into a reference update.
I was also informed that there was still a dependency on IronPython 2 for certain Python nodes. This was a bit of a surprise, because I thought I’d worked through and migrated each of these (I was actually loading a partially migrated version of the graph, not the V2 graph that was posted publicly). It turns out I’d missed a few. The fact there was a warning message on load was really helpful, and the migration assistance made the migration of individual nodes a breeze – much better than my previous manual attempts at migration! Information on both these features can be found in this blog post from a few months ago.
One thing that I found myself missing was a Warnamo-like tool that allowed me to find the various IronPython nodes: while the nodes helpfully state whether they’re CPython or not, finding all the Python nodes in a large graph can be a challenge. Each time I migrated another one, I’d save and reload the graph, thinking “this time I must have found the last straggler!”, only to see the IronPython warning once again on load. For the very last node that needed migrating – which I’d given up trying to find visually – I resorted to loading the .DYN in a text editor, finding the one Python node mentioning “IronPython”: I then scanned through the file for the node’s ID, finding it in a known category that I could then locate and scan visually in the Dynamo editor. I got there in the end. The source code for Warnamo is on GitHub, in case anyone’s motivated to modify it to help with Python migration. :-)
Anyway, the updated, all-CPython MaRS graph (v3) is now posted available. For those of you interested in earlier versions, you can find them here.
This migration work doesn’t actually highlight any enhancements in Dynamo 2.12, of course, but at least you can now use Dynamo 2.12 to load this version of the MaRS graph with up-to-date package references and no warnings.
One updated feature that I really wanted to check out was node auto complete, something I last tried with Dynamo 2.9. It now has support for custom nodes, which is fantastic – I found I could build up a non-trivial graph using Space Analysis – a core component of the MaRS graph – using pretty much only the node auto complete feature. In Space Analysis we’re mostly naming the output ports via the type name – something that’s currently a requirement for forward completion (a term I just made up, by the way) – although we’ll have to go through and use type annotations in a future update, I expect.
Here’s a quick GIF showing the custom node support in action (stolen shamelessly from Sol’s post):
Speaking of future updates to Space Analysis… my colleague, Rhys Goldstein, has been working on taking the concepts used to implement Space Analysis to the next level. Space Analysis – cool as it is – is very much 2D-centric. Rhys has been working on “adding a D” to the library, which brings the ability to perform spatial analyses – such as pathfinding and daylight/visibility analysis – in 3D. This effort is coming along nicely, so expect to hear more news on that in the coming weeks/months.
Working with the next version of Space Analysis (which we’ll call Space Analysis++ for the purposes of this post) has me thinking about possibilities beyond Dynamo and Generative Design workflows. Space Analysis++ (like Space Analysis) is based on a C++ library that has been wrapped for use with Dynamo, but could also be used in environments such as Forge (if built as WebAssembly via Emscripten – something we’ll dig into at some point on this blog). This raises the possibility of doing some really interesting in-browser calculations for emergency egress, etc.
Which brings me to my last sub-topic for this post, the chance to work with Spot. Our Technology Centers team has been working with Boston Dynamics to secure access to one of their dog-like robots, and is currently reviewing proposals for residency projects that would harness the Spot SDK to explore the areas of ‘offline path planning and simulation (leveraging XR workflows, game engines, BIM, digital twin, etc); coordination of streaming dynamic sensors and the collection of reality capture data across multiple platforms; hardware interoperability and heterogeneous fleets of robots; the integration of machine learning and computer vision to improve the usability of multiple tools and enhance safety protocols and responses; the integration of new sensing payloads’. See this post to find out more and hopefully apply.
As an Autodesk employee I don’t think I’m eligible to submit my own project, but I do think there are some fantastic possibilities of combining a technology such as Space Analysis++ with Spot. If anyone applies, gets accepted and wants to find out more, then please do get in touch!
