Dynamo – Random Numbers

There are two simple random number nodes in Dynamo: Random and Random With Seed. Random just generates a random number, while Random With Seed allows you to ‘seed’ (set the start conditions for) the random number generator.

I tend to use Random, but because of the way Dynamo evaluates the code (illuminated by Stephen Elliot in this post), you can get some unexpected results:

Here is a simple layout of one Random node and a pair of Watch nodes. Hit Run, and Surprise: The two Watch nodes report different values!

Why? Well I think it’s because, as Stephen’s description indicates, the Random node is evaluated twice, once for each Watch-node-branch, and it generates a different value each time it’s evaluated.

Bug, or feature? It’s just the way Dynamo works at the moment (this is in Version 0.5.0), so if you want to use random numbers in your layouts right now, you’ll need to take this behaviour into account.

The other option is to use Random With Seed:

This is a similar layout, but the Random With Seed node produces the same value each time it is called with the same seed.

Which is fine, but you will probably want to feed it with random seeds so you don’t get the same result each time you Run.

Dynamo – Export Image

This is the first in a sequence of posts explaining the work that followed on from the Parametric Punkinator. Some of which I presented at BIMShowLive in London back in May.

It started with the realisation that there wasn’t an effective way to explore the Punkinator design space. Every time you changed the input parameters, you had to wait for the form to regenerate. And then take a screenshot. And also keep track of which input parameters produced each screenshot, so that you could re-create the ‘best’ form. All of which took time.

First up then, a way to automatically take a screenshot. Now I’m sure it won’t be very long before the Team whip up a built-in node to do this. But until then, there’s Python:

This is a Python Script node that takes an input file name string, constructs an ImageExportOptions object, and passes that to the API call doc.ExportImage which saves an image of the screen. The Python code is from Daren Thomas at Daren@Work (and via the RevitPythonShell Wiki)

Then the only tricky thing was getting the file name and path to feed into the Python Script node correctly. The \ character that’s used in paths is interpreted as an escape character in Python strings. And in previous versions of Dynamo, those escape characters were evaluated on input to Python Script nodes. Now in 0.5.0, though, it seems as though they string is just passed through ‘raw’.

Put the Python Script node in a Custom node wrapper with a filename input, and you have a nice pluggable Export Image node:

You can test it with a simple layout like this:

But to do the job properly, you need to auto-generate the forms and the filenames, which we’ll come to shortly.

Dynamo - Row of Points with Lacing

If you’ve followed my previous posts on the revitator blog, you’ll have noticed that I made extensive use of Map and Combine nodes to handle lists in Dynamo.

The new Lacing functionality makes most of those constructions obsolete. This post uses Lacing to re-work my Row of Points example (which in turn was based on Nathan Miller’s RevitPythonShell example):

You can see how this old layout uses Map nodes to apply multiplication to the number sequences, and then a Combine node to feed the lists into the XYZ.

Re-worked in Dynamo 0.5.0, it looks like this:

The multiply nodes have Longest lacing, so they use the single slider values to multiply each value in the number sequence. The XYZ also has Longest lacing, so it uses the single zero Z-value alongside each pair of X and Y values:

Using the number sliders as inputs allows you to dynamically change the scaling of the row of points in X and Y:

Dynamo - Lacing 3D

The last post looked at Dynamo Lacing with 2 lists, using a UV node. This time, I’m looking at Lacing with 3 lists using an XYZ node.

Diving straight in with this layout:

The Number Sequence nodes create the three lists {10, 20, 30, 40}, {10, 20, 30} and {10, 20}, which are then fed into the X, Y and Z inputs of the XYZ node.

Changing the Lacing of the XYZ node generates these sequences:

First: {(10, 10, 10)}

Shortest: {(10, 10, 10) (20, 20, 20)}

Longest: {(10, 10, 10) (20, 20, 20) (30, 30, 20) (40, 30, 20)}

Cross Product: {(10, 10, 10) (10, 10, 20) (10, 20, 10) (10, 20, 20) … (40, 30, 20)}

And here are the screenshots:

First	Shortest
Longest	Cross Product

You can see how First creates one RefPoint; Shortest creates two (the length of the shortest list); Longest creates four (the length of the longest list); and Cross Product creates 24 (= 2 x 3 x 4, the product of the lengths of all the lists).

That seems to explain how Lacing works technically, but there’s more experimentation to come, to find out how best to make it work in practice.

Lacing

I wasn’t sure that I understood the new Lacing functionality in Dynamo (This post is based on Dynamo 0.5.0), so I did some experiments.

Each node in Dynamo has a Lacing setting (right-click the node, and select Lacing from the context menu), which can be First, Shortest, Longest, or Cross Product. Lacing controls how the node deals with list inputs. Each setting has a tooltip that gives you some guidance. For example, Shortest’s tooltip is: ‘For two lists {a,b,c}{1,2} returns {a1,b2}’

So the idea here is that you have a two-input node (a UV node for example), which can take a list on each input. The Lacing setting tells the node how to combine the elements from each list: Do you want all the combinations, or just a selection?

Based on the tooltips, I drew up this table:

The two input lists {a, b, c} and {1, 2} are along the top and at the left. In the middle of the table are the possible combinations. (a1), (a2), etc. And I’ve highlighted the combinations that are returned by each Lacing setting.

For example, First just returns (a1), so the UV node would just give you one UV element. Shortest returns (a1) and (b2), a List of two UV elements. And so on.

Put another way, First just combines the first element from each input list. Shortest combines the corresponding elements (a and 1, b and 2, etc.) from each list, until the shortest list runs out of elements. Longest does the same, except that it carries on combining until the longest list runs out of elements, re-using the last element from shorter lists as necessary. Cross Product combines all the elements from all the lists.

That’s the theory. How does it work in practice? Here is a layout I built to test the two-input case:

This layout creates a pair of number sequences, {10, 20, 30} and {10, 20}, and feeds them to a UV node. The output of the UV node is used to create RefPoints on a Face.

Changing the Lacing of the UV node does generate each of these sequences:

First: {(10, 10)}

Shortest: {(10, 10) (20, 20)}

Longest: {(10, 10) (20, 20) (30, 20)}

Cross Product: {(10, 10) (10, 20) (20, 10) (20, 20) (30, 10) (30, 20)}

And here are the matching screenshots:

First	Shortest
Longest	Cross Product

Next, Lacing with 3 lists!