Many of you will have been happy to see the extent of the features announced last week for Revit 2020.
It’s great to see Dynamo 2.1 integrated, for instance:
It seems the Dynamo version is being tied specifically to Revit, which is an interesting development. I assume this is driven by the need to manage complexity of end-user environment configuration, but I do wonder whether it will impact the ability for users to absorb changes delivered by the Dynamo team. But that’s the trade-off between control and flexibility, I suppose: we’ll see how it works out.
In addition, the new Path of Travel feature is really interesting, and I’m sure some of you will be wondering how it relates to the Space Analysis package we’ve posted for Dynamo and Refinery.
We met with the Revit team in the weeks leading up to the release, to understand how the work we’ve been doing in Autodesk Research relates to what they’ve created. As I’ve mentioned before, the low-level C++ library we’ve built – and wrapped for use in Dynamo – was intended to be something that could be used in simulations based on our open source SyDEVS library. We have the intention of making this underlying library open source, over time, although we don’t have a fixed timeline for this happening.
The Revit feature is based on a more mature library that’s been developed (and tuned) over many years. The Revit team has also invested heavily in the logic to extract boundaries and barriers from the Revit model for use in pathfinding analyses: this is super-valuable, and definitely not something we expect to want to do ourselves. What they’ve done is extremely interesting, and gives huge value to the use of pathfinding (where there’s more overlap with our package, for sure).
The long and the short of it is that we’re comparing notes to understand the relative merits of each implementation: should the Revit capabilities end up being exposed via Dynamo nodes, for instance, then there’s a good chance we’ll leverage certain aspects of their work alongside ours, and maybe even work to implement a common interface (which would make it much easier to switch between the two). It’s encouraging to see the Path to Travel feature already has an API exposed.
But it’s still early days: at this stage it’s important to know that the two systems are currently independent, but we’re talking about how best to minimise (or at least manage) the overlap, moving forwards.