When Things Go Array

Last week, I was posed a question by a colleague who was attempting to build a fairly simple parametric circular array family, but having trouble constraining and controlling it. After a quick analysis of its parameters and geometric relationships, it became pretty clear that the family was attempting too much in the same place. I’ve found this is actually a pretty common problem when troubleshooting in general. What does this mean, and how can you help yourself?

Well, in short, it means that you should treat building a flexible parametric family in the same way you would prepare food for a group of people. You have to ensure you break it down into individual and manageable pieces and order them so that they arrive in the same place at the same time, and this will do three things:

1. Allow you to control and flex things independently
2. Locate and troubleshoot the pieces that aren’t flexing or just simply breaking. As I’ve discussed in earlier posts, parametric families are particularly bad at suddenly breaking and offering limited or no clues as to why – this is the failing of purely logic based algorithms, and the way they’re utilized by Revit / Vasari.
3. It will open more opportunities in the way that your parametric family can operate and behave in its parent family – I’ll get to this.

So this is a way to THINK about families (not just specifically circular arrays). The easiest way to start is to ponder this:

What parts of the family do you want to flex or make adjustable / controllable?

Write the parts down on paper – give them a line each. Draw a rough sketch of your finished family – be diagrammatic. When you’re confident you have the things you need to flex – count them. This is, roughly, the amount of sub-families you’ll need to nest, including your parent family. You can keep all the individual controls simple, and flex/test them before moving onto the next parameter. When you get better at this, you’ll realize that certain parameters/controls can be grouped together, because you understand the limitations better. Make a tree diagram of these individual components that make up the whole if you like – graphical thought is an excellent way to map these things in your mind and make the links and hierarchical order you need to. This is a confidence thing!

Nesting families is an excellent way to construct complex geometric relationships – so I’m going to use the circular array discussion I had as an example. Before that though, make sure you’re familiar with the way that ‘type parameters’ link through nested families, as this is key.

The breakdown should be sensible, so it’s a good base to start on. The ‘nesting’ relationship should be logical too – so you can conceive the way that each family will function together, and what they each individually bring to the table.

Basically:

Family 1 – Circle control (circle diameter)

Family 2 – Radius control (of final array)

Family 3 (parent) – Array control (parametric calculator)

Solid. Let’s get to work.

Family 1 – This is about as simple as it gets. I’m using generic family *.rfa’s because I find them the most flexible and least obtrusive. Draw a model line circle centered in the system reference planes, with a parameter diameter that (strangely enough) drives the diameter. NB: you can use radius if you like, I’m only using diameter because I want to talk about radius later in relation to the array driver and don’t want to confuse these two things. You’ll see that I actually have a controlled radius parameter here with a driver diameter parameter. Nest this in Family 2 once you’ve flexed it and tasted the enjoy.

Family 2 – This is going to host Family 1 along the horizontal plane, and so we’re going to add only one parameter, radius, that is going to be the array radius controller. However, we’re going to also create a diameter parameter in order to link the corresponding one from Family 1. Making sense? Good - then nest, link, and flex ready for Family 3.

Family 3 – This is where it gets complex my lovelies. You get to be picky-choosy about your flavour of choice for hosting / not hosting requirements. You can favour a family that may host in a particular way to suit your particular function / end-user.  Is it a wall opening? Then wall open it. Is it a door? Then door constrain it. Is it a ViewMaster? You’re in the wrong blog. After selecting your family template of choice, next is to place Family 2 into Family 3, centre to centre and create + link the diameter and radius parameters through. Flex these parameters and make sure they’re working. 

Now we need to create the array - hopefully you have a little previous experience with this kind of thing – the hardest part is understanding how to use the array tool in a parametric fashion, not the particular components you’re trying to array – you’ve already made that easy for yourself.

So, select the nested family 2 and hit array from your ribbon – pick the radial option and then place the centre of the rotation to the system reference plane intersection, and create ‘an’ array. Don’t worry too much about inputting numbers or angular separation at this stage; we’re going to make that all drivable soon. 

If you tab through and select the array now, you can see that it’s formed a pac-man type shape that should be adored and revered in equal measures for he is supreme. Revit should have applied some kind of arbitrary array integer (number of arrays) and an angular separation. While the array is selected, you’ll see that the parameter label drop-down box has appeared on the ribbon, so you can select this and add a parameter to control the integer output. Call this array_number or something equally as exciting. Depending on the angle you originally made (ie, if it was small), you might be able to adjust it – because it has built in information about how far to increment the additional groups of information. Regardless, you don’t need to test it just yet.

The last part of this is to get the array to actually function parametrically. There are two important things to achieve here – first of all, to break the rigour in which the array was created (ie, the spacing and number of objects arrayed), and then tell it what angle of the array is desired. The first is easy, although I’m going to explain why you need to do it, because it is VERY INTERESTING.

1. When you started the array in family 3, unbeknownst to you, you actually built it with a little bit of hard-coded information about the relationship of the angular distance between the arrays, and the number of arrays desired. When you select the array after it is built, it offers you the total angle of the array, the number of the arrays, and a radius that you can adjust, but they’re clunky and unintelligent. By creating this parametric tool, and nesting these families together, you’re essentially exploiting the array function as a skeleton framework for you to control yourself. This is an important concept to understand, because you can take advantage of a lot of the tools Revit / Vasari has to offer in this regard. Anyway, to break this, very simply untick the box on the ribbon that says ‘Append to End’. What this does is removes the hard-coded information that restricts the array, and lets it know that you want to tell it what to do in-between the first and last array objects.
2. The second thing is similarly easy – you just want to tell it what angle you’d like. So, you’re going to place an angle dimension between the resultant opening of the array. This is the mouth of paku-paku-man – and you’re going to have to tab through to get to his top and bottom lip. If you’re looking at the bottom left of your screen (as you should be when you’re tabbing!), it will read ‘array: array: reference’ when you have it. So, now you should have an angle dimension in there – my example reads 45deg.

The final step is to apply a parameter to this dimension – so grab it and label it array_angle. This should be now be flexible from within the type properties dialogue box. Winning! Alternatively, you could be a clever person and actually create a usable angle driver with a controller that subtracts the difference to inform this opening. So, for example, you could label the dimension array_controller  instead, place it under constraints and then create your actual driver parameter array_angle, and apply the following logic / formula to the array_controller:

360 – array_angle

The idea here is that you’re going to want to use this array by telling it what angle you want, not by working out what angle will be left over (and thereby needing to work backwards to get it!)

You can complicate this further if you like, but hopefully this gives you some idea of how to approach a parametric family build. Specifically, this is actually an easy family to build in terms of concept to finished entity, but the point is really about understanding how to pull the concept back to reality so Revit / Vasari can be used rigorously. It’s always difficult to pull a concept back to logic, but if you want it to be controllable and useful in an architectural interface, you almost certainly need to go through this consolidation/resolution stage.