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
Category: Revit
Dynamo deletes previously placed elements after each run – workaround
If you need to iteratively place multiple Revit elements with Dynamo, like these stadium chairs, then you are in trouble. The problem comes from element binding – a Dynamo feature which preserves the link between DesignScript and Revit elements during the current Dynamo session. This is how Dynamo works by design, preventing your model from an avalanche of element duplicates, created in ‘Auto’ mode:
Either you run the graph in ‘Auto’ mode (like in the figure above), or re-run the graph manually, Dynamo places new elements while removing previously created ones. This kind of behaviour sounds pretty logical and straightforward – look what you’ll get if there’s no element binding at all (using one of the workarounds): … Dynamo deletes previously placed elements after each run – workaround
Revit 2018.1 update comes with enhanced Dynamo Player
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 !
Unable to apply scope box to Revit view
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!
Count railing balusters in Revit with Dynamo
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?
Using Revit scope box to change intersecting elements parameters
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:
… Using Revit scope box to change intersecting elements parameters
Renumber rooms by level – Revit and Dynamo workflows explained
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):
… Renumber rooms by level – Revit and Dynamo workflows explained
Zhukoven.com dynamo package update
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.
(UPDATE): here’s the link to the dedicated post about Revit railings: Count railing balusters in Revit with Dynamo
Create Revit workset by linked file with Dynamo (updated)
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.
A few words about Dynamo and Visual Programming
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):
