This blog is Part 3/3 of a three-part blog series covering the Dynamo Core 2.13 release: Please read Part 1/3 and Part 2/3 first. 

TL:DR

• Visually reimagined and refreshed Dynamo experience, introducing a modernized user experience, fresh color scheme, tonnes more information at your fingertips and clarity towards both paradigm and approach to how Dynamo works; nodes, wires, authoring behavior and the UI experience have all been jazzed up [Part 1/3].
• Implementation of two Dynamo Interactive Guides for First Time Use Experience and Packages, with more to come[Part 2/3].
• A refreshed Package authoring and download experience [Part 2/3].
• An expansion to the Workspace References extension to include local definitions and external files [Part 2/3].
• We now have a richer way to handle installed packages via states and resolve conflicts [Part 2/3].
• New Unit nodes [Part 3/3].
• More seamless Python 3 Autocomplete [Part 3/3].
• Performance improvements to Search, the scaling of graphs and the Virtual Machine improve Dynamo use [Part 3/3].
• A swathe of security updates [Part 3/3].
• A new node that groups curves together [Part 3/3].
• 35 bug fixes, with a particular focus on Crashes to improve stability of the overall Dynamo experience [Part 3/3].

Phew… a monster list! As usual, there is a whole bunch more so please do check out the release notes!

 

Tell me about all the rest of the awesome things in Dynamo 2.13!

Improving our nodal landscape

As part of our continuing improvements to the nodal landscape of Dynamo, we have two epic new additions to this release: Unit nodes, which enable you to do work with quantities, units, and symbols such as converting metric to imperial and vice versa… or combinations of both (Wowzers!), and a better way to group individual curves into Polycurves. Pretty big this one, and a shout-out to all the community packages that have forged the way on this functionality.

Forge Unit Nodes

Introducing 25 new nodes to the Library and updating a couple of old favourites. The addition of Unit Nodes opens up a whole swathe of new possibilities. So much so that we won’t be able to cover all of them here and will only drop a couple of use cases as a teaser… go explore and see what you can do! Otherwise, we plan to release a dedicated blog post that covers more interactions at a later date. The unit nodes are based on the Forge Unit SDK (Software Development Kit), ensuring that how they work in Dynamo will parallel how they work in other Autodesk applications that use the same backing technology. Imagine a future world where we are all in sync – how glorious!

If you are a developer also looking to utilize these public libraries, check out ForgeUnits.NET and ForgeUnits.Schemas on Fuget.org.

 

These epic new nodes allow you to do really cool things, such as parse string input math expressions (simply put, combine imperial and metric stuff together) when you have to work with multi-united elements, or simply want to convert your favourite recipe (yum!). Convert many more units in the updated Convert Units node, do complex multi-nodal flows around stringifying fractions, and much more.

 

• [ 1 ] The new Symbols node that allows you to explore hundreds of Symbol types, including but not limited to nautical miles, megawatt hours, and lux. Who knows what funky new things you can come up with this one!
• [ 2 ] The Symbol.StringifyFraction node will take any input and convert it out into a string representation based on your chosen precision and symbol. That esoteric 3.1415 can now truly become Pi in all its glory!
• [ 3 ] Using the Parse Unit Input node will allow you to type in a series of unique units and output in a chosen unit type. Look out for its siblings Utilities.ParseExpressionByUnit and Utilities.ParseExpression to fulfill all your closed loop needs.
• [ 4 ] We have also improved the Convert By Units node so that it now also uses the same underlying logic. Not only can it do all the cool things it could before, but now also so much more. Have a play and see what you can do!

We have also increased the precision of the Convert By Units node, enabling a much more precise working environment and giving you back the granular control. Want rounding? Then just add it back in with a Math.Round node!

 

Lets get geometrical, geometrical, I wanna get ‘metrical…

Continuing to improve our Geometry library, we have added in a brand new node, PolyCurve.ByGroupedCurves, which not only covers the same functionality that the PolyCurve.ByJoinedCurves node does today (hint: You can use this new node in all of those old situations now), but will also group the curves into discrete sets before joining them. This gives you the ability to pull in dirty data-sets of curves that are touching, but not in the correct order, and joining them without having to resort to some rather hefty logic or the awesome community driven packages that pre-date this node! Shout-out to Konrad Sobon with the Archi-Lab package and all others who made similar nodes.

 

• [ 1 ] A list of rectangles, exploded into lines and shuffled, giving us 36 randomly ordered curves that may or may not be touching.
• [ 2 ] Some DesignScript logic to color these curves in the background preview, showcasing that the first six in the list are randomized.
• [ 3 ] The PolyCurve.ByGroupedCurves node takes this arbitrarily organized list of curves, figures out which ones are connected, groups them into sub-groups, correctly orders them, and creates PolyCurves as output. Ooh the power!

 

We have also improved the old PolyCurve.ByThickeningCurve node by adding in a Normal input. This has deprecated the old node (which will still work as it did in old graphs, but won’t be able to be placed again) in lieu of the new PolyCurve.ByThickeningCurveNormal node which has this added normal input. Functionally they behave the same if you choose not to add in your own normal input, but they give you a much greater degree of control over how thickening occurs. Rather than being arbitrarily calculated based on the creation method of the curve, you will now be able to specify exactly which direction your thickening occurs in. Rock on control!

 

• [ 1 ] The new PolyCurve.ByThickeningCurveNormal node replaces the deprecated PolyCurve.ByThickeningCurve node.
• [ 2 ] This node adds a normal input port, requiring a vector that dictates which direction the curve will thicken in.

 

Cleaning up the Python experience

From Dynamo 2.13 onwards, the default Python experience inside Dynamo will be CPython3, with IronPython2 (the old default engine) removed as it is no longer being updated by the Iron Languages team, meaning no more security patches. You can still access IronPython2 via the Package Manager by simply downloading the DynamoIronPython2.7 package if you wish to continue using it! Fun fact – this is also a special case in Workspace References that lets you know it’s missing.

• So what does that mean for you as a Graph Author? Well, if you are using the Python Node, you’ll want to get more familiar with Python 3, as there are some fundamental changes between Python versions 2 and 3. The epic thing about this is that you can use Python 3 to access a bunch of cool new libraries in the world of Python 3 such as Pandas, Numpy, Tensorflow, and many more!
• But what does it mean if you are a Package Author? Natively, you’ll want to work in CPython3 where possible, as this is our maintained Python version moving forward. Bear in mind that there are differences in implementation (as discussed in the Dynamo Core 2.8 Release blog post), namely that IronPython2 lived in .NET land (the language in which things such as Revit talk), and CPython3 lives in the world of pure Python. This means there isn’t parity between both Python engines, and not all code will migrate. Reading our wiki entry or the Dynamo Forum support thread will highlight some of these differences. If you want to keep your package in IronPython2, then the end user consuming your package will simply need to have DynamoIronPython2.7 installed, or install it.

We have also enabled CPython3 Autocomplete, natively playing as well for CPython3 as does the autocomplete in IronPython2. Consider this a parity experience for all the good stuff you love about autocomplete today!

We have also added new APIs to the “Dynamo.PythonServices” namespace, which is located in the DynamoServices assembly, such as querying available Python engines or interacting with each of these available engines. Oh to the possibilities you Pythonic superstars will cook up!

 

• [ 1 ] The lower left of the Python node will now show CPython3 as the default Python engine, unless you set it otherwise inside of the Preferences Panel.
• [ 2 ] Available Python engines will be queryable through Dynamo.PythonServices.PythonEngineManager.Instance.AvailableEngines collection, showing you what you can work with.
• [ 3 ] API users can interact with each available python engine through the Dynamo.PythonServices.PythonEngine class.

 

Ensuring Dynamo performs well

Making search faster

Search inside of Dynamo has had a clean-up pass, eliminating redundant NodeSearch iterations, making Dynamo’s Node Search faster. Specifically, we removed a double search event caused by UI events (no gain, only pain), avoided adding the whole search text if there is only one word using whitespace as a separator, limited the search to 300 characters (a limit we would be impressed if anyone hit!), and optimized some back-end code.

• Searching for “all elements of category” went, on average, from 879ms –> 380ms, returning the result 2.3x as fast.
• Searching for “category” went, on average, from 315ms –> 73ms, returning the result 4.3x as fast.

2-4x is great I hear you say, but it’s only a few milliseconds, so why does that even matter? Ah, great question! Every single time you type a key into search, the search algorithm will fire across 1254 Node Entries and 28110 Tags, which is quite a lot of stuff and takes time to return you a result. If you want to search for “category”, you’ll need to start with “c” and traverse the word sequentially, so the performance of each letter really does add up.

We will be taking a deeper look at search to gain even more performance and ensure that the experience of using search is a joyful, fruitful, and useful one.

 

Removing memory bottlenecks

Dynamo had some UI architectural decisions (as in the software sense of the word) made in the past that haven’t translated well into the modern Dynamo landscape. As more and more users built more and more complex graphs, Dynamo started to run into scaling issues inherent in those architectural decisions of a bygone era. So, we ensured that Dynamo will now more linearly scale, having a much smaller memory delta between large and small graphs, and dramatically reducing the memory bottlenecks that arose. Performance-wise, this is roughly the same as previous Dynamo iterations, but carved out space for us to make the user interface much more complex without adding performance costs to it and, coupled that with way better memory usage.

Specifically, we made all the Node, Port, and the newly minted Wire context menus lazily loaded, being created on the fly and destroyed after use. This adds an imperceptible performance cost at the point of creation in small graphs (we would be surprised if you noticed it all all!) that gave back huge memory and loading improvements, while also reducing Dynamo’s memory burden. How did we achieve this, you ask? Well, historically, every single nodal action is loaded but not visible… on every single node. Think the aforementioned context menus, List@Level spinners and the like. Not a problem in a small graph, but a massive scale problem as you start building larger, more complex graphs, so we hit the most egregious offenders for 2.13 and have near-term plans to loop back over the overall performance and memory allocation architecture of Dynamo to holistically remedy.

This is also the reason why in 2.13 we disabled the ability to use PolyCurve representational connectors (wires) in lieu of spline connectors. Leaving both on was not only a scale problem, but also a general memory overhead issue in Dynamo, and we opted to retain the more common user choice. For those of you who preferred angular wires, we apologize and hope you find a new found appreciation of splines and our newly added wire pins.

 

Boosting the DesignScript Virtual Machine 

In the Dynamo’s Virtual Machine many operations occur, least not the execution of your graph! But what happens to stuff that Dynamo needs to know in the moment, but then forget? It’s ran through a Garbage Collector, a specific feature in software applications to manage memory and attempt to reclaim memory that was allocated by Dynamo.

Suffice it to say that this work optimized the sweep pass for full garbage collection after any change to the graph that causes re-execution, focusing on Dispose() and allowing it to bypass steps that added unnecessary overhead.

In practise, this took a test graph with ~150,000 items to collect down from 2seconds to 0.5seconds (4x performance boost) and lowered the memory allocation from 800mb to 16mb, a whopping 50x improvement.

 

Looking at faster Geometry Tessellation

We have also improved the tessellation of Geometry inside of Dynamo, which is the dividing of geometry into polygons suitable for rendering, by adding to the generalized tessellation methods with overrides for Surfaces, Solids, Meshes, and TSplineSurfaces to improve their performance, removing unnecessary calls and related events. What this means as a user is that your rendering time will decrease – hurrah for more time looking at your cool stuff rather than waiting for it!

 

A bunch of API changes

For the developers out there, we have a bunch of API changes landing in Dynamo 2.13, allowing you to do awesome things such as get the file size of a path or select up and downstream nodes from an originating node. API changes are as follows:

• DynamoCoreWPF has had many controls which are no longer used removed.
• ProtoCore has a bunch of new methods added:
  • Utils.StringUtils.BreakTextIntoLInes
  • Utils.StringUtils.IsStringSpacesWithTabs
  • Utils.StringUtils.SpaceToTabConversion
  • Utils.StringUtils.TabToSpaceConversion
  • ProtoFFI.CLRModuleType.FFIMethodAttributes
• DynamoCore has two new constructors, and four new methods 
  • Constructors:
    • Dynamo.Graph.Annotations.AnnotationModel.AnnotationModel
    • Dynamo.Graph.Notes.NoteModel.NoteModel
  • Methods:
    • Dynamo.Graph.Annotations.AnnotationModel.ContainsModel
    • Dynamo.Graph.Nodes.NodeModel.SelectDownstreamNeighbours
    • Dynamo.Graph.Nodes.NodeModel.SelectUpstreamNeighbours
    • Dynamo.Graph.Nodes.NodeModel.SelectUpstreamAndDownstreamNeighbours
• DynamoUtilities has two new methods:
  • DynamoUtilities.PathHelper.FileInfoAtPath
  • DynamoUtilities.PathHelper.GetFileSize

 

Smaller buckets of work

We have completed a bunch of smaller items, such as adding a menu item to show/hide preview bubbles globally, addition of many security updates to improve the overall security landscape of Dynamo, and removal of CEFSharp and replacement with MSWebBrowser in the Library, which will stop many dependency conflict issues that have plagued many a Dynamo user in the past. We also improved our product analytics to paint a stronger picture on failure points, crashes, and popular feature use, and now allow the loading of custom UI node views from separate WPF-based assemblies in packages.

We fixed a tonne of bugs, ~35, that smooth the overall experience of Dynamo. Some notable ones are stopping Dynamo unnecessarily uninstalling package dependencies, allowing Node Autocomplete to now work on a node with multiple output ports rather than always putting the wire to the top port, and fixing the Dynamo menu access keys so that you can now use things such as node alignment with Option E A T/L/R/B.

We also do have a few known issues that are being looked at for 2.14, so please have a look at our release notes. If you run into something strange, report it to us if it’s not on the list!

 

Say no more… Where can I grab Dynamo 2.13!?

Dynamo 2.13 will be made available in our host integrations at a future date and can be explored right now through the dynamobuilds.com website or the Github build page – available in the Sandbox version of Dynamo.

 

If you’re curious, you can also read our Release Notes

In order to keep a semblance of propriety to this blog post, we’ve skipped a few things! For more information on other minor features, bug fixes, and known issues in Dynamo 2.13, go check out our release notes: This particular set contains 35 bugs and a bunch of other smaller items! 

A big shout-out to everyone who contributed to the release and the entire Dynamo community for continuing to support our work. As always, please let us know if you have any feedback or suggestions!

 

The Dynamo Team