Kia ora Dynamo people,

After a couple of months of development time (Once again in full-blown remote Zoom mode), today we release the Dynamo Core 2.7 release! This release is a doozy, containing a bunch of work that has been a long time coming; upgrade work focusing upon modernization and a huge amount of bug fixes… the list is a long one!



A slew of Code Block improvements including better autocomplete, better Node2Code, and improved multiple definition warnings, speed improvements to the package managers dialog and package search, the introduction of Python 3 (phase 1), modernization of our graphical pipeline with visible rendering speed increases to the naked eye, increased testing, and a huge amount of bug and crash fixes all making a much more stable and consistent Dynamo: big #stability and #consistency wins!


But what is Dynamo and its flavours?

What is Dynamo Core?

Dynamo Core is a collection of bundled components that consist of the graphical interface, the compute engine, the scripting language DesignScript and the out-of-the-box nodes that are not specific to another program like Revit or Civil 3d.

What is Dynamo for <INSERT HOST HERE>?

Dynamo for [Revit, Civil 3d, FormIt, Advance Steel, or Alias] is a collection of host specific nodes that work with Dynamo Core and runs inside of said host.

What is Dynamo Sandbox?

Dynamo Sandbox is for package developers and other folks working with Dynamo code who want to stay up to date with the latest and greatest stuff coming out. Sandbox is Dynamo’s “Core” functionality distributed in a way that doesn’t interfere with other Dynamo installations and doesn’t require any other applications (except for a few windows components and some optional extras). You can read more about this distinction here.

Got it, can you now just tell me what’s new with Dynamo 2.7?

You asked, and we listened! So with the advent of Dynamo 2.7 we are releasing our first phase of the Python 3 interop upgrade works that seeks to modernize the Python scripting experience and bring you access to a whole new range of popular modern libraries such as NumPy, Pandas, and Keras! If you want a little more detail, have a read of our latest Dynamo Public Roadmap and explore Unleashing the (pythonic) beast! In short: We are integrating the CPython 3 native Python interpreter to enable Python 3 access in Dynamo as the IronPython project (Which we have used in Dynamo up until now) has not yet had a 3.0 release and has no ETA on it – #sadness.


There are quite a few differences between both IronPython and CPython and we will be writing a blog post on this soon, but if you want to jump into Python 3 now then keep an eye on our wiki page work in progress to improve Python 3 support as we collect known issues and scope what will be fixed, when it will be fixed and what we do not plan to reach parity with.


Integrating CPython 3 into Dynamo is one of our larger undertakings this year and will be split into a few phases. The first phase, released here in Dynamo 2.7, brings the following new funkiness for you to play with:

  1. An engine tag on each Python node that will show at a glance what engine this node will be using to execute Python code. The cool thing here is that you can have both IronPython2 and CPython3 nodes inside the same graph all ran via the same Python Editor experience!
  2. An engine selector that allows you to choose which Python engine you want this node to execute with via a dropdown menu inside the Python editor.
  3. learn more button that brings up extended documentation. At the top of the documentation browser there is a Report Python 3 node issue button that will link to a Dynamo Forum post where we are capturing any issues you may find – so please submit what you find! We can work through this together to get to the best possible Python experience. On top of the forum link, we have extended information discussing why we are changing the Dynamo version, what it means for you and some key syntax changes.
  4. The contextual engine selector node menu allows the Python Script From String node to be able to select an engine via the right-click menu as this node doesn’t have the Python editor. You can also access this on normal Python nodes for a quick switch!
  5. All buttons inside the Python editor now also have hover tooltips to explain, in brief, what each of them does as a nod towards a more informed Dynamo.
  6. Python nodes will also have an Engine serialized into the .DYN file and an Engine property on the node, callable via Extensions, but be cautious in referencing this as it may change as we iterate on the Python 3 interop.


New Python engine selector and learn more documentation


So I see you mentioned Phases, you ask, what other ones are in play? Good question! Below we have a timeline of our proposed scopes of work for integrating CPython3 into Dynamo – in Agile parlance these are called Epics. Unfortunately we are unable to give hard dates on this, as things are subject to change, but this is the currently projected sequence that we are adhering to:

  • Epics in Green are included in the Dynamo 2.7 release.
  • Epics in Orange are currently being worked on – all at various stages of completion.
  • Epics in Blue have not yet been started.

A quick note on [ 8 ] – we are not going to stop IronPython use in Dynamo, but rather will ship it via the Package Manager as an Extension. IronPython will become a choice for users and, as a special case, will also be understood by the Workspace References extension without needing data serialization.

Our Python 3 Epics timeline


As called out recently in the Dynamo Public Roadmap we have been working over the past few months on modernizing our 3d Graphics experience by upgrading the component we use for our background preview rendering, Helix Toolkit. Dynamo 2.7 has now incorporated this work which delivers a more modern and streamlined 3d graphical experience that is improved, more performant and smoother overall. The first piece of this puzzle is a parity play where we match the existing functionality that Helix offered in the past: with the added benefits of years of feature improvements, bug fixes and performance gains! So, while we talk about this as a parity play, it’s more like a fresh cake WITH the cherry on top!


Modernizing Helix means that we now have a much more maintainable code base by improving many under-the-hood features such as shaders and lighting, we have an easier way to make future changes and also access to all of the cool new features that Helix provides. You may notice a slightly different way that Dynamo renders graphics right now but we’ve strived to match things such as lighting direction and colour as closely as possible. You should also notice some performance gains in the rendering speed! While we haven’t quantified this as it’s pretty difficult, we can anecdotally say that it’s #fasterToTheNakedEye(tm).


If you are an Extension author who used Helix in the past there may be some changed behaviour that falls outside the semantic versioning that Dynamo typically adheres to as it will only affect a smaller number of extensions and gets these upgrades in the hands of many well before a major version shift. Please go and have a read of the Dynamo Graphics Update blog post if you think you may be affected and feel free to reach out for more information.


Shader and Lightning differences that may be very, verrrry subtle! However, some cases may not be this close.


With the upgrade of our new and improved 3d Graphics engine, Helix, we have also fixed a pretty annoying bug when rendering too much geometry: Previously, Helix would raise an exception when it ran out of memory causing Dynamo to crash. We have addressed this by dynamically switching off the 3d rendering preview if you hit this limit and showing an error message that shows you hints how to avoid running into an out-of-memory problem! If you really need more geometry rendered, then you have options to turn off erroneous node’s previews or lower your render precision (Note: T-Splines are a pretty big offender if you are using them… thousands of triangles stat!).


Out of Memory Exception error message showcasing hints on how to resolve


We have also put some effort into improving the Package Manager experience by improving the speed of package download from the Workspace References by removing the need to search for the entire metadata associated with dependent packages and is now streamlined to searching via the version number itself. This manifested itself in packages that have lots of versions causing latency issues. We also added new tests to make sure slowness doesn’t creep in again – #winningAtFutureProofing. We also made the UI display for the Manage Packages Dialog pop up faster and dramatically improved the search speed when browsing for packages. Some of you may remember circa ~2 minutes of waiting for the Package Manager to load around November 2019… we’re now down to mere seconds. No fancy images on this one, you’ll have to just check it out for yourself and as an aside all of the server side work will benefit every version of Dynamo, not just 2.7. Hurrah!


We also had a community Github submission of a String.ToTitle node by Chuong9x – so a big shout-out and massive thank you for this new functionality Hồ Văn Chương! This new node adds to the swathe of string modification nodes such as String.ToUpper and String.ToLower to bring more options to you – the string gurus of Dynamo. You will find the String.ToTitle node under the String -> Modify section in the Library and it will take every word from your input string and capitalize the first letter. 


The fancy new string node… with text that isn’t quite accurate anymore! Oops.


We have made a few improvements to the Codeblock Node that improve the auto-complete behaviour by fixing inconsistencies when multiple definition warnings are thrown: in essence conflicts in naming between an out-of-the-box node and a packaged ZeroTouch node that mimics the same name. This means less annoying warnings in your graph and less having to qualify the namespace (Fancy speak for tell your Codeblock where to look for the correct function!). We have also fixed a raft of bugs associated with Codeblock autocomplete and in Node2Code that hides the need for namespaces and improves the ElementResolver. Suffice it to say that the overall experience should be smoother and more consistent… now go DesignScript up all the things! There is a lot of good stuff in this one and a huge shout-out goes to Aparajit who has extensively documented his work in this Pull Request which is very much worth a read if you’re into the more technical stuff.


Old way shows Namespaces while the new approach hides them


And, last call-out but not least, we fixed a long-standing legacy bug with the Surface.FlipNormal node that caused the trimming edges to be lost resulting in some rather annoying behaviour. The bug fix now correctly retains the trimming edges allowing the node to behave as expected. A big win on the consistency front and a direct bug report from you awesome users, so keep those coming!


Hurrah for fixed behaviour 🙂


You’ve sold me, so where can I get my hands on Dynamo 2.7?

Dynamo 2.7 will be made available in our host integrations at a future date and can be explored right now through the 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.7, go check out our release notes: this particular set is huge, so well worth a read – especially on the bug section!

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