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?
An updated version of my Dynamo nodes package (rev.2017.6.2) is now live at Dynamopackages.com. This version contains the Dynamo node that builds a Navisworks search set XML from the input data:
Based on the original code by Luke Johnson from What Revit Wants (Bakery package), this node gives you the freedom in Navisworks XML file creation. You’re able to specify the Navisworks Search Set name & group, and choose which Navisworks parameter you’re going to use. This XML file stores data in the structured way that could be easily read by Navisworks. This means that you can use the power of Dynamo to automate your Navis searches, and even set the rules that couldn’t be otherwise done without workarounds. … Zhukoven.com dynamo package update brings Navisworks SearchSet XML creator
Scope Boxes in Revit are very handy when dividing building into separate blocks. You can set these scope boxes in view properties, or even in view templates, and get cropped views in a matter of seconds. Yet there’s another handy thing that could be used to boost your productivity: the “Name” parameter, which by the way is the single available parameter of the scope box. So how can we use it?
Say, we’d like to divide our Revit model into blocks, using some distinctive names: “Block A”, “Block B”, etc. Using the named scope boxes, we can set this name to all desired elements that intersect the scope box:
Our architect asked me recently, if it’s possible to add the level prefix to room numbers in Revit. Assuming that the building is relatively large, this is certainly the task that requires automation. However, this could also be done in a semi-automatic way via the Revit room schedule… So let’s take a look at both Revit and Dynamo workflows, and see the difference between them.
Revit semi-automatic renumbering
Create Room schedule with the following fields: Number, Name, Level, Shared parameter (RoomLevel in our case):
Yet another small Dynamo node that may be handy if you need to watch for an element orientation. There are different use cases for this – like placing wall openings by doors & windows, or placing elements with preset rotation (e.g. stadium seating). What it does – is simply illustrates element’s facing orientation by drawing a line in Dynamo:
Each line starts from element location point, and indicates its facing orientation. Resulting lines could then be used to place elements or set rotation angles.
I packed this workflow into the custom node called FamilyInstance.VisualizeOrientation to make it reusable. If you’ve already installed my zhukoven.com package, you’ll need to download the latest update (Rev.2017.5.25). Or simply follow this logic to build your own workflow:
An updated version of my Dynamo nodes package (rev.2017.5.19) is available at Dynamopackages.com. It’s now equipped with Railing.CountBalusters custom node, which is based on the “Railing.BalusterCount” node from Rhythm package. I had to rebuild the original node to get rid of the ‘false positives’ in resulting number of balusters. Below you can see the difference between these two nodes, and the numbers they show as an output:
I’ve tested the tweaked node on different railing types: horizontal, sloped, and curved, so it should work correctly.
Please note that Railing.CountBalusters can handle only one railing instance at a time, so do not try to feed a list of multiple elements into it.
I’m going to write a dedicated post to describe my node, and why did I have to rebuild it. In the meantime, you can download an updated package here: Zhukoven.com_(Rev.2017.5.19) or via default Package Manager in Dynamo.
This little Dynamo graph may become handy If you use individual Revit worksets for each of the linked Revit files. While operating with linked files via worksets becomes super comfortable (you can even unload links before opening your Revit model), it becomes a pain to manually create separate worksets for each model.
This is where Dynamo will come in handy:
As you can see, the logic behing this graph is simple:
Scan your current document for linked Revit files, and retrieve their names. This is done using Archi-lab.net package by Konrad K Sobon, so you’ll need to install it (if you haven’t already done this) before running the script;
Then we cut off all the unnecessary symbols from the link names using the node “String.Split” and add our desired prefix via “String.Insert”;
The last one node “Workset.ByName” is also listed in Archi-lab package and basically does the rest – creates worksets by the input list of names. Although I don’t check if some of the worksets already exist, it won’t give you errors or warnings.
To start with, I’d like to say that I’m not willing to build an all-in-one dynamo package, collecting everyone’s custom nodes. My intention is totally different: I’d like to share my ideas that cover some white spots in Revit and Dynamo. I mean that if I managed to find solution to one particular problem, that has not been solved yet on dynamo forums or somewhere else, why should I keep it in secret?
(drumrolls): Introducing the very first Dynamo package!
Well, while I’ve already published the first version – rev.2017.5.16 (and here’s the link to the dedicated packages page), it is still work in progress, and of course there are some unfinished nodes that I plan to include in the future releases. So stay tuned and enjoy! And don’t forget to report issues and your ideas via the contact form on dynamo packages page.
What is Visual Programming , and why does it generate a lot of hype among AEC professionals? In simple words, Visual Programming lets you build your program by manipulating with graphical elements rather than by specifying them textually. VP basically acts as a mind map, connecting one’s design ideas with the software API (“application programming interface”) to put design ideas to life. You’ve probably seen my previous post with the “Hello, World!” image from Dynamo (Dynamo == Open Source Visual Programming Revit addin):
It’s been a while since I wrote my last post on the previous blog called “liveBIM“, and now I’m starting all over again here. There were several things to be changed (from my perspective), like blog platform, blog name, and domain name, so finally I have the right moment to do that.
As far as I’m a tech savvy person, acting as a BIM Manager in the design firm, I am keen on the cutting edge technology. It becomes our duty to see how new technologies get born, evolve, and finally become obsolete. Remember those CAD Managers in your firm? They are fading in the past, and so would BIM Managers do in the near future. This is inevitable, and all we can do is adapt to this ever changing tech world.
Some 5-10 years ago such technologies as Internet of Things, Big Data, Neural Networks seemed more like a science fiction than reality. What we see today is the rapidly emerging technologies, that seize almost every aspect of our lives. That’s why now we’re standing on the edge of the fourth industrial revolution that is coming much faster than you think. And our goal, as AEC industry professionals, is to drive our industry forward by integrating cutting edge technologies with building design.
Wouldn’t it be great to see an architect thinking more about how to improve the building design, instead of how to drive parameters from one BIM element to the other? In my opinion, the answer is pretty obvious: don’t waste your time and let computer do all the dirty work for you.
As for myself, I’ll do my best to share my knowledge and expertise with colleagues. I hope that my future posts will save some time and nerves of yours.
Now that the starting point and vector are set, let’s go ahead and move this rusty AEC thing to the bright future.