Now that the fall has come, it’s time to check out an updated Revit roadmap, which highlights the future of Revit. There’s a lot of cool stuff in there, so go ahead and see this article at Autodesk blogs
Lately I’ve been working on some Revit railing enhancements. This is still work in progress, but some of the Dynamo nodes are already available online in my updated Zhukoven.com (rev.2017.8.17) package. Below you can see available railing Dynamo nodes (please note that currently all of these nodes support only one railing instance at a time):
Currently there’s no direct link between the railing element and its hosted balusters through the Revit API. So in order to get the baluster profile data, we have to explode railing geometry and extract surfaces. Output values are diameters / widths of baluster elements.
This node calculates the number of railing balusters. See this post that explains the logic: Count railing balusters in Revit with Dynamo
Check if the railing element is hosted, and get this host element as an output (if applicable).
Get the list of lines that form the railing path.
Get top rail element (instance) from the input railing instance.
Input railing instance to get its type, primary handrail type, secondary handrail type, and top rail type. The node returns null values if selected railing type doesn’t contain handrails.
Good news, everyone! Revit 2018.1 update is now available for download from the Autodesk Account portal. It comes with some cool new features (see this article at Autodesk blogs for the full info), including enhancements to Dynamo Player. Now it finally supports changing input values directly through the Player UI, which is super handy:
As you can see, there may be plenty of inputs that could be changed without even launching Dynamo. But note that there are still some limitations:
- Code blocks as input strings are not supported – if you prefer to write text inputs in code block, using quotes, you’ll need to rebuild these Dynamo graphs (swap Code Blocks with Strings) to use with Player;
- Custom nodes as inputs are not supported – they are not shown in the Player UI;
- Frozen nodes will be shown as changeable inputs, while they’re not used in the script logic.
Anyway, this is a cool update, and I’m sure that these subtle issues would be fixed in the near future. And by the way, here is the quote from Dynamo community addressing these issues:
We will look into the frozen node and address them in the future.
For the Code Blocks it’s a little more tricky but doable if there is a strong request from the community.
For the custom nodes it would be really nice indeed to have that.
The way I see this as a possibility in the future : a third party will create the custom node on Dynamo and then will have to create the node UI representation in Dynamo Player ( using some Dynamo Player API which doesn’t exist yet ). So the third party will have control over the DB level of the node and also over node UI representation in Dynamo Player.
Good news is that things are designed internally to make this possible in the future.
However , since this still requires a significant development effort we need to have a strong request from the community so that decision factors prioritize this accordingly. So please tweet about it on every occasion !
Yet another post about Revit weirdness… Struggling with setting scope boxes to multiple views via Dynamo, I noticed that some of the views returned the “null” values. I opened the view that had a “null” value, and saw that the “Scope Box” parameter was grayed out:
The reason for this weird behaviour is simple: it turned out that Scope Box parameter becomes read-only if you modify the Crop Cregion sketch. Since the Revit Scope Box is a cube, it can’t be applied to those views that have non-rectangular Crop Region!
Counting something in Revit seems pretty easy, right? You’re able to extract lots of parameters from different element categories out of the box, and use them to create schedules or count quantities. This concept works great until you get to the system families. They usually make you scratch your head and turn your eyes towards Dynamo to get things done…
Say, we want to schedule the number of balusters by railing types. How are we supposed to count things like this?
The first thing that comes in mind – is to create a Railing schedule and check out available fields. And that’s when the first obstacle comes in your way: there’s no such thing as “Baluster” in the railing schedule:
The next step is to check railing instance or type parameters. Still, nothing useful here but baluster placement, that obviously can’t help us count the number of elements. Well, what if we check out available parameters in Dynamo?