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?
Nope, even API can’t tell us the number of Balusters: only baluster offset parameter has value, which is useless in our case. The other values are hidden under the “Baluster Placement” parameter, that acts as a separate Revit menu and is unavailable via the API. It turns out that this task could be only workarounded, and that’s when the Dynamo community comes in.
I’m talking about the custom node written by John Pierson from 60secondrevit. His node is called “Railing.BalusterCount”, and it’s packed into John’s Rhythm nodes package. The node explodes a railing element geometry to get the number of baluster elements. Frankly speaking, I thought that this node would do the trick for me, but guess what? I was wrong. While this is a great concept, it turned out that the resulting number of elements has some false positives. Take a close look at this example:
This simple railing has only 3 baluster elements inside, so let’s launch the Dynamo graph – it should also show us these 3 items:
Oops… the “Watch” node shows 4 elements instead of 3. Well, let’s tear this node apart and see what’s going on there (next figure shows the node’s entrails, connected to the input “Select Model Element” node):
Then launching the script gives us the following picture:
And here’s our false positive that we’ve been looking for, is circled in red. This guy comes from the upper surface after the “Geometry.Explode” operation. And as soon as the node takes “Vector.X” component, this results in the false positive(s).
My workaround is the following: while we cannot get rid of this extra point from the upper surface, we can ignore it by switching the node’s logic to “Vector.Z”. This is how my “Railing.CountBalusters” node works:
Although the basic concept remains the same, the “Vector.Z” component does the trick:
I’ve tested my node on different types and forms of Revit railings (see the first figure in this post), and each time the output was correct.
You may download the latest version of my dynamo package (Dynamo 1.3+, Revit 2016+) here: Dynamo packages