see part 2 here
This is step one in my process of creating an iterative Daylighting analysis workflow using Dynamo and Rendering as a Service.
To execute a series of studies, we need to detect the state of the model and change the state of the model. For changing the state, one of the first functions we need to build is a mechanism for changing a family instance parameter. Then, we need to check the state of the Revit environment because we'll need to start a render only when we've updated the model (it's not useful to re-render the same model with no changes). To control the state of the Revit model, we can use a Revit transaction.
First thing, I am going to illustrate this graph on a simple family with 1 instance parameter. It's an extruded circle to form a cylinder, the circle has an instance parameter radius that controls the radius.
You will need some kind of simple family instance that has been placed in another family or project.
Below is the main graph:
We use a select family instance node to grab the cylinder, get the 'Radius' family parameter and use a custom node to actually do the updating and image taking. This custom node becomes a function, the family stays constant each time it is used, the radius parameter stays constant as well, but the value to set the radius to changes to each value in the list. We use a map node to take the custom node (which is a function) and apply the it to each number in the list. Each number in the list gets input into the argument 'n'.
Effectively, we have called our custom node: 'UpdateParameterAndSaveImage' 5 times, once for each number in the list (10,20,30,40,50). Now let's see how UpdateParameterAndSaveImage actually works inside.
Inside the custom node there are a few things that need explaining. The first thing to note is the node 'PerformAll', which performs each branch connected to it in order from top to bottom. This lets us make sure the top branch completes before the bottom. In this case our top branch sets the family instance and updates the model of the cylinder. The bottom branch takes a screenshot of the current Revit view and saves it out to a file path.
There are also the two transaction nodes directly connected to the PerformAll, these tell Dynamo to wrap the current connected branches into a Revit transaction that will force Revit to regenerate the model. We use this to make sure the model is updated in the first branch before moving into the second branch and saving the image. If no transaction node was used, Dynamo would put all of the set instance and image view calls in one transaction and we would only get images of the last model update.
Upon running this graph you'll find 5 png files in your c:/Dynamo/ directory. A last note, you'll need to make sure whatever directory you specify in the custom node is already created.