Time flies when you are having fun

I stumbled upon one of those gadgets you take at conferences, one that probably you never used or you didn't even remember to have. Like this USB mass storage shaped as a card.

It was the 2nd Revit User Conference in Milan, huge venue this time, walking down the Rho Fair Exhibitions, wondering "can I do this roof in Revit?".

I remember that I learned about shared parameters for the first time at that Revit User Conference, I remember Philippe Daverio's speech, the venue, the people, so much more than the previous one. I remember what happened to make that roof possible in Revit.

It's been 10 years already. I've learned so much and I am still doing it, still having fun.

Revit Ideas Station: Delete Worksets API

Please vote!

https://forums.autodesk.com/t5/revit-ideas/delete-worksets-from-revit-api/idi-p/7575512

Many thanks :)

It must be Friday

Insert Revit Families from a Web Browser

I know, it's pretty ugly... just a prototype to insert families from an html page (look at the address bar in the floating window).

AmsterD(yn)am(o) Part 2

Here is the second clue.
There is even a Dynamo Street! The preview is hidden and there is a West Port for output, the lacing must be cross-product.

and here is the Custom node.

Set multiple parameters at once with Dynamo

It is common practice  using Dynamo to get and set objects parameters from Revit, I'd say this is one of the best features in Dynamo actually, something that empowers all the stakeholders in a workflow to communicate information and data seamlessly using the Revit model as an aggregator. What good is the BIM if we still have to populate the "I" manually, right?

It's also true that if you don't have Dynamo principles clear in mind, graphs tend to be messy, let's say not too elegant. There are even subtle mistakes that could actually prevent the graphs from executing correctly.

In the image above the example on the left is wrong, and as a matter of fact crashes Dynamo because there are two parallel branches in the graph that modify the same element on the same parameter. What should be the result in this case, value 1 or value 2? There is no good answer actually. On the right instead a sample of how it is supposed to happen from a graph flow point of view. It doesn't make much sense to change the same parameter but it's something that could potentially happen and it is better to avoid.

So in case of multiple parameters I very often see long chains of Set Parameter By Name nodes, one after the other, big space on the graph calling over and over the same function. It's working I know but the graph is not very concise.

Let's elements a collection of #n Revit elements, let's parameters a list of parameters names that these elements share, finally let's values a list of values with the following structure organized in a list of lists: each item of the main list is made of the values.

Now if you run this graph the result is not what one would expect.

Not all the elements are taken into consideration, the parameters are not set correctly because the replication calculations here are not helping. Changing lacing on the node won't affect the result in the way one would want in this case. There is need either for a new data structure that could cope with the difference in the rank on the input or for replication guides to force the execution of the Set Parameter Value By Name with a function.

Dynamo nodes

The Set By Parameter Name takes input of rank 0 (single values) but the elements and the parameters have rank 1 and the values rank 2. By default, the elements of the input that are occupying the same index position are combined together in the node function. In this example:

• the first element
• the first parameter name
• the first LIST of values

The first element is combined with multiple values over and over for the same parameter and it ends with the last value of the list. Sounds familiar? it's the same thing happening in the green group of the first image, definitely not ideal and, more importantly, wrong.

It is possible to introduce a list with rank 2 for the parameters, List of  repeated items, the same amount as the elements, rearrange the values with a Transpose to have the same amount of sub lists (this won't change the rank but only how the data is structured). The following graph will now work as intended.

Replication guides

Remember that each node in Dynamo is a function that can be recalled in its literal form (e.g. try Node to Code).

In DesignScript it is possible to drive the replication calculations and force how the functions handle the input. The replication guides are defined with one or more "< n >" after the name of an argument in a Code Block. It's like writing a series of nested for loops in Python, the lowest numbers come first.

In this case it would be something similar to:

for p, v in parameters, values: # Level 1

    for e, vi in elements, v: # Level 2

        e.SetParameterByName(p, vi)

Which in replication guides terms translates as follows.

The final output from the two methods is different but they are only one Transpose away.

This is something I recommend to start to use in your graphs to keep them tidy and use DesignScript at its full capabilities.

Finding Nodes in the Graph

One of the most annoying things with large Dynamo Graphs is to find a specific node given some properties, like the name for example, and have Dynamo to jump right on top of that node.

This video demonstrates a concept I've been working on using the Dynamo API.

It works using the name of Nodes, Notes and Groups.

The weird thing I couldn't explain is why after the execution one has to click on Zoom Out to center the node... but it's definitely better than nothing!

This also implies the usage of some best practices when creating the graph, renaming is the oldest trick that still makes the difference.