Category: Dynamo

Seattle Dynamo User Group hosted at ZGF


The second Dynamo User Group was hosted at ZGF Architects in downtown Seattle last week. Architects, Landscape Designers, Engineers and Programmers were treated to lunchtime pizza and 3 graphs we have been working on over the past month.

The first Dynamo graph took adaptive panels that were hosted to a mass, read their profiles and redrew them using detail lines within a drafting view. These lines were evenly spaced, sorted, dimensioned and tagged.



The second graph presented, created room bubble diagrams by taking rooms from Revit and generating region fills with fillets. This automation was requested by a team who previously spent much time exporting plans and manually tracing these outlines in Illustrator. This graph was our first deployment using the Dynamo Player.

Room bubbler

The last and final graph showed how we could read a linked Revit file of 2D furniture and replace with 3D furniture. This workflow was important to a team that needed to have a documentation model of furniture and not be burdened with heavy 3D components; yet at the same time have updated 3D model for rendering and VR purposes.


I cannot upload and share these Dynamo files as WordPress does not support the dyn or zip file types. The Seattle Dynamo has a Slack channel where we troubleshoot and post our graphs and supporting material.  If you want to by added to the channel, please let me know. Also, check out the MeetUp site for future Dynamo User Group meetups. Hope to see you there!



Journey into the Energy Code

So part of my list of things to do for 2017 was to tackle a better workflow for documenting energy compliance when our designs go to the city for permit review.

The City of Seattle has a 2012 requirement to ensure buildings meet, and hopefully exceed energy performance. As Architects we work with our consultants and team mates to determine the buildings are adequately insulated, properly ventilated, heated, cooled and well lit. There is a little horse trading with design to get the space we want with the appropriate energy performance. After all, you can’t get a naturally well ventilated, day lit space without windows!

The Architect’s job is to show compliance to the Building Energy Code. They do this either by a component or prescriptive method. The component approach is by calculating all the external building envelope areas and multiply them with the U-Value. At the end of the calculation your building needs to be less than the benchmark set by the City. If this is not the case, you are in full building energy simulation and into the prescriptive approach.

Is it easy to document? The answer is no! Your building is constantly changing through design and the current process of checking compliance is time consuming and works better with a static envelope. Calculations are usually performed at milestones; but wouldn’t it be better if you could get feedback from your model in real time, really informing your design rather than complying?

The documentation in itself is time consuming. As with everything in Revit, there are multiple ways of approaching a task; but what’s the best? There is the laborious process of creating every wall assembly, adding the thermal conductivity and specific heat to all the materials, entering each components thickness to calculate the R and U values. It gets complicated when combining multiple elements into an assembly, such as a glazing and mullions. The advantage with this approach is that when the building changes, so too does the schedule. It does however mean that the team really needs to be integrated and understand what is happening to the assemblies, materials, schedules and model appropriately. A tall order when teams are scrambling to get the work done and members have varying skill sets with the tool. The other approach involves an individual to demarcate areas of building assemblies and assign the appropriate U-value – currently performed in Revit as Region Fills with scheduled material areas.

There are some that feel incumbent to create their own unique approach. This week I heard a colleague export elevations to CAD and reinsert these back into Revit within area plans to trace boundaries for the specific assemblies. I applaud the ingenuity, but to rely on a method that requires manually importing/exporting to another format and exhaustively tracing lines does not help in the workflow. Multiple area boundaries also have a tendency to hinder model performance and in turn, grind the laborious process further.

So what are our options? My current idea is to have a mass, split its face and assign the corresponding wall assemblies as painted materials with U-value parameters built-in. If the mass model could smartly update to the building envelope and somehow read the materials from the facade, projecting them onto the mass to schedule, we would be in business. I am hoping we can crack this nut as it will be a huge time saver to our Seattle teams. I believe this will start with massing, journey into Dynamo and probably end with some Rhino and Grasshopper.

If you have any bright ideas, please share as I would love to hear your thoughts. I will continue to post developments, so come back soon to how this project is progressing.

What Dynamo Needs?

So having dabbled in Dynamo on an off for the best part of the year, I am in no position to greatly comment on what Dynamo needs. It is a complex animal and seems you need a good bit of Python to tweak what is on offer. There is a good smattering of custom packages out there that can really aid in productivity and open avenues within Revit that were seemly impossible to do.


From newbie with no virtual computational experience, to having created a number of successful graphs either interoperating with Rhino and adaptive components, placing complex railings equidistant over a curved floor perimeter, or generating site plans with Open Street Map data, I am now in a position of understanding, yet having frustrations both at the same time.


It is a great feeling to nerd out and get a graph to function, minimizing the nodes and playing with Dynamo’s logic. It is frustrating to see those little yellow error messages appear without explaining very much, or that the definition seemingly works, only to find out the next time you run it, it inexplicably doesn’t; trying to locate that node to do something simple or that the Revit API isn’t exposing itself.


Arghh! Those error message, deprecations and unresolved statuses


My colleague Dane Stokes, a Grasshopper whizz and Rhino jockey, gets easily frustrated with Dynamo. He likens Dynamo to a British car: finicky, powerful but good luck getting it started and seemingly in the shop most days. 

The functionality and polish of Grasshopper attract many graduates, who typically aren’t constrained to producing construction documentation. Given a choice, most simply gravitate to Rhino and Grasshopper for their needs, leaving few that can aid with Dynamo in the professional setting.


Dynamo is a great tool to Revit, but best practices, workflows or documentation have not been developed in industry. The standalone Dynamo Studio is being used with FormIt to create geometric shapes and change their properties. Josh Goldstein at Autodesk has provided tools that generate louvers on a building or create a staircase in FormIt. Yet this added functionality provided by Dynamo already exist in the Revit product with parametric families and tools. So when is it appropriate to implement Dynamo with Revit? What are the best workflows if you are pushing data back into Revit in a Work Shared and live model? How can we share and document our custom graphs that we create?


Dynamo Studio Properties in FormIt


Dynamo Player has arrived as of Revit release 2017.1 which helps, but varying inputs need to be incorporated for the Player to function effectively. When we get input functionality, should we create a Dynamo graph or create a dedicated Add-in tool using the Revit API? I feel Dynamo works well for custom situations that require hacking Revit’s stubbornness, yet if there is a repetitive task or a function that is being used consistently on all projects, it is probably wiser to create a tool using the API to share with your entire firm or industry.

I realize that you have read all the way to here and I haven’t addressed what the title of this blog asks, What Dynamo Needs?:

I feel Dynamo would benefit by:

  • Improving search functionality speed.
  • Filtering a list of compatible inputs from an output.
  • Make error messages make sense.
  • A Python debugger.
  • Inputs to Dynamo Player in Revit – akin to the how Dynamo Studio interfaces with FormIt. I have been told by sources that this is coming soon!
  • Dynamo Studio communicating with a headless Revit in the Cloud.
  • Increasing mobility with an iOS application.


Kudos by the way to the Dynamo team to having done a great job on the Dynamo Dictionary and the new list level functionality. I look forward to future developments. It is fun to get under the hood!