Dynamo - Max using Reduce

Wow, following Zach Kron’s very kind article over at Buildz, I guess I’d better get posting. Here’s a quick study using Reduce, one of the List Processing nodes I talked about last time. I’ve had a couple of comments suggesting that Reduce is a bit hard to understand, which implies I didn’t explain it very well. So here goes for a more detailed explanation. Or perhaps I should just stop while I’m behind.

There are lots of ways to find the maximum element in a list. This one uses Reduce.

Reduce takes a function, an initial value, and a list. In this case, my function is a custom node called Max, which returns the higher of two input numbers.

So I feed my list into Reduce, and set the initial value (the a input on the Reduce node) to the First value in the list. This way, I know that my final output will be a value from the list. (You might think you could just use zero as an initial value, but what would happen if all the items in the list were negative numbers?)

So Reduce takes the initial number (I tend to think of this as ‘the number it has in its hand’), and feeds it to Max alongside the first item from the list. Obviously, they’re both the same number, so Max outputs that number. Then Reduce takes that number and feeds it to Max alongside the second item in the list. And so on. At each stage, if the number from the list is higher than the number that Reduce has in its hand already, then Max gives that higher number to Reduce. And after Reduce has walked through all the items in the list, the number it has in its hand is the highest number in the list.

Does that make sense?

Here’s the definition of Max:

It’d be trivial to change this into a Min node that returned the smaller of the two numbers. Then you could plug that into Reduce to extract the Minimum value from a list.

So, Reduce steps through each item in a list and ‘has a value in its hand’. Your function needs to take those two values as inputs, and give an output value back to Reduce. The eventual output from Reduce is the output from the function when it’s invoked with the last item in the list and the value that Reduce has in its hand at that point.

Clear as mud.

Dynamo - List Processing

Many Dynamo layouts need to process lists. Lacing is one option, and recursion is another, but sometimes the built-in list-processing nodes Map, Reduce and Combine are just what you need.

Map applies a function to each element of a list and generates a list of the results. The function needs to have one unconnected input, and is called once for each element in the list: The element is fed into the unconnected input, and the function’s output is appended to Map’s output-list.

This is an example that doubles each element of a list:

You’d probably use Lacing for this in a real-world layout, but Map will work with custom nodes, whereas Lacing only works with Lacing-enabled built-in nodes at the moment. I’ll often create a custom node to ‘wrap’ a bunch of nodes, just to surface the single input that Map needs.

Combine is like Map, but takes two or more input lists. The number of unconnected inputs on the function needs to match the number of lists in the Combine. Just like Map, the output from Combine is a list of the outputs of the individual function calls.

And here’s an example using Combine to generate a series of Square numbers:

The same comment about Lacing applies…

In contrast to Map and Combine, Reduce just produces a single value, not a list. It’s inputs are a list, a function, and an initial value. The function needs to take one list element and the initial value, and output a single value. That value is then fed into the function along with the next element in the list. And the output from the Reduce node is the output from the last function-call.

As an example, here is Factorial implemented with Reduce:

Note that there’s nothing to stop you using a list as your ‘single input value’, so you can use Reduce to implement lots of other list-processing functions. And of course your function can inspect and edit the contents of the ‘single input value’ at each stage. Reduce is really very versatile.

Another example, generating a Fibonacci series using Reduce:

Which uses this Fibonacci custom node:

It’s a bit inelegant in places, but it does the job.

For the code-geeks, it does look as though the Reduce node in Dynamo is actually implemented as Fold in the underlying F#, so the name might change in future Dynamo releases.

Dynamo - Randomize and Export Image

So, once you have a way of generating random numbers and saving screenshots in Dynamo, you can generate this kind of thing:

I was interested in exploring these folded, origami-like stadium roof forms. Technically, this is an adaptive component repeated on a divided path. The adaptive component has three parameters: Twist, Fold and Bump; and the number of divisions in the path is parameterised as well. Which gives me a design space with four dimensions, containing a wide variety of forms:

Of course, with a bit of Dynamo, you can generate as many variations as you need:

The neat thing you’ll notice about the images is that they each include a readout of the values of the four parameters that generated that particular form, together with an index value. These readouts are made with model text, embedded in the mass family and parameterised. When the code sets the parameter values on the form, it also sets the parameter values on the text readouts.

Because I was interested in trying a selective, evolutionary mechanism for exploring this design space, I made Dynamo write out a text file:

Then, when I had selected the forms that had the right ‘feel’ and were in the right part of the design space:

I could select the relevant lines from the text file:

And then mix and combine these parameter values to create a second generation that explored this part of the design space in more detail:

The forms in the Second Generation are more alike than those in the First Generation, because they come from a smaller region of the design space. With subsequent generations, by selecting just the forms that appeal, I could focus in on smaller and smaller regions. And quickly zero in on the ‘ideal’ form from a large design space.

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: