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.

[No]des (it's a real word that I just made up)

First of all, I'm sorry. No really, it's been ages since my last post - but that's not to say that I haven't been active with this - just that I haven't found the time to get all my ducks in a row. Let's spend some quality time together, I'll put on that dress you like.

Aaaaanyway, this is a discussion about nodes, or rather, the lack of them. Or rather, the hack of them. Ha! See what I did there? Yea. So, adaptive components love nodes, but what happens when there are no nodes? Oh noes! What causes this? How do you snap adaptive points with any confidence of their behavior? Will the earth spin off its axis and collide with the sun? First, let’s look at a nice example of a mass surface with all nodes present and correct: 

 

In this simple example they are easy to manage and snap to – you can intersect the grid as you like and get amongst. However, when cutting a mass with a void, as the second diagram above shows, we are left without a stable interface.

With this very simple void manipulation, and despite the facts that the surface being cut is continuous, and no changes have been made with the intersections, the node points along the cut edge don’t/won’t generate. In order to get the surface to function, you need to create your own nodes, and this isn’t as hard as you might think – you’re about to get intimate with point elements. The first order of business is to isolate the surface that you’re dealing with, so that you can get your points to snap to the right edges/elements/surfaces. You might also want to include any levels or reference planes that you’re using/think you'll use to intersect the surface. It’s important here to think of point elements as an abstract entity – they’re not simply an x,y,z location in space, but an actual entity that has attributes and an identity of it's own damn it.

The next thing is to make sure that you understand how your adaptive component is going to snap/adhere to this surface – and this is really just to make sure that you’re not making things unnecessarily complicated for yourself – in all honesty, the fewer NOdes you have to fabricate the better. In a bit I'll show a pretty simple 4pt adaptive component just to give a feel for what’s going on. In a later post I’ll make it more complicated to illustrate how point elements need to be treated in this context.

Begin by selecting point element from your ribbon and then move it over your surface. This is where the isolation of the surface is important, because you want the point to be snapping to the right plane – I’ll explain that shortly. You want it to snap to the edge of the plane, so hit ‘Tab’ if you need to get it to cycle through, and then place the point.

It’s now hosted to the edge of your plane, huzzah! But don’t rest on your laurels just yet, because there’s mischief afoot. Not only will your adaptive component not enjoy this point as it is, but it’s not even in a logical location along that edge. Let’s deal with the latter first.

You can manipulate this point location in two main ways:

1. Move it manually to align with your surface grid. Inaccurate but quick (and really, your adaptive component should have some flex in it – especially if you’re doing a quick study) or;

2. Host Point by Intersection. This takes a little more setup from the beginning – basically you need to have a level or reference plane that your surface is going to use as an ‘intersect’. This is actually reasonably logical for an architecture project. Let’s discuss.

We’re going to place another 2 levels (besides the base system default one) in this example and then intersect the surface plane with them so that we can snap our point elements at their intersection. Confused? Would pictures help?

Step 1 - Unhide everything and select the system default  ‘Level 1’ plane

Step 2 - Hold down shift+ctrl and drag it upwards

Step 3 – Repeat

 

Step 4 - Now select the surface, drop down ‘intersects’ on your ribbon and select  regular flavor

Step 5 - Holding down ctrl, select both planes. Hit finish

Step 6 - Oh yea, I know what you’re trying to say girl

So now there are flexible lines included in the grid, which is where the planes are intersecting the surface. But more importantly, we now have a logic in the surface that we can exploit with the hosted point element. Let’s do that. Select the hosted point, and then locate the Host by Point Intersection button underneath the main ribbon dado. It’s important to note that the Level planes are what you’re going to intersect with, so that’s what you should select. Hosted! Perfect.

The point element will now move with the plane and surface together. Repeat these steps as necessary for your surface. I created only 4 NOdes to use in this example.

Now I'm going to go back to the “I’ll explain that shortly.” (van der Veen. "NOdes." digital blog. Web. about 5min ago.) and elaborate on why selecting the correct plane/surface edges is important. From this point on, you’re going to remove most of the flexible behavior in the NOdes you’ve just created – so it’s a good idea to have them in the right spot – and also realize that if you need to change things later, they will need to be recreated.

In the previous images, the selected NOdes exhibit a hosted relationship with the surface edge – that is, they display a perpendicular axis (the little blue square when selected), and that’s not much help for an adaptive component as the snappy adaptive points want to behave in certain ways. So, now that the NOdes are in the right place, we have to go through a process of disassociating them from the surface. If this sounds counterproductive, don’t worry - remember, this is a hack!

Step 1 – select the NOdes

Step 2 – on the Host drop down menu on your ribbon, select <not associated> (at this stage, the NOdes will become little fatties)

Step 3 – once this is done, on that same drop down menu, select one of the Level planes – it really doesn’t matter which – the important thing is that you want the NOdes to reference to something logical, like a ground or floor plane.

The points of doing this twice is to initially disassociate the point from the mass/plane/edge, and then re-associate it to a known surface that will operate predictably. Now when selected, the NOdes display a logical x,y,z adjuster. Let’s test with the previously mentioned simple 4pt adaptive component, and place it on the surface with our NOdes. Simple right?

 

Well, things get more complex according to how your adaptive component works – more specifically, how your adaptive point orientation is operating. Basically, you can get around this by rotating your point-element-turned-NOde in its properties to get the adaptive points to face in a direction that is consistent with the way its built. As the builder of the component, you should have some idea of what it needs.

This is most prevalent when dealing with angular or non-linear surface planes – just keep rotating as you need to to get it to work. You'll find that the adaptive component will exhibit weird orientation behavior or just fail completely until you get the NOde/s facing the right way. Hopefully this last part makes sense once you’ve been through the process – I’m working on a more complicated set of components to illustrate this at a later date.

The Complexity of Profiling – Nailed it or Failed it.

In my last couple of posts about profiling I suggested that creating complex profiles is an imprecise science, and exposes some of Revit/Vasari’s shortcomings.  I may have also used the words ‘failing’ and ‘hack’, and that’s really the essence of what I’m getting at. For this example, I’m going to focus on ‘spline by point’ massing types, as they seem to be simultaneously the most flexible, and the most problematic. Let’s start by making a general statement about what is hopefully going to be achieved:

Create an adaptive piece of geometry driven by parametrics that is flexible enough to be quickly modified within the project environment, and stable enough to mine information from.

Right, that’s a nice, simple, and realistic request of Revit/Vasari right? Well, no. The main problem is that while this program is powerful and has an established and progressive front end, the conceptual back end is very much a work in progress. Simple forms make the concept-to-project transition well, while more complicated forms are more complicated and create more complications.

So, the most frustrating part of generating complicated geometry is that when your conceptual forms break, you are not told why, or how to fix it. So this is a really a successful guide about unsuccessful form creation in Revit/Vasari using profiles. Actually, it’s more a list of questions I asked myself about the fundamentals of my approach when profile-rigs wouldn’t work (or stopped working) - which is just a nicer wait of saying I Failed It:

Is it the chain of elements that lead to the mass?

Is the fact that only the adaptive components move through the family hierarchy after placement?

Is it the line's inability to flex properly?

Is it the constraints of the underlying rig?

Is it the way the lines are hosted?

Is it the distance between the points along the line?

Is it the amount of points included in the spline?

Okay, so some of that was a little heavy, but the tentative conclusion of the problem here is really the behavior of the ‘spline by points’. The last few points really highlight the undiagnosed issue that Revit/Vasari has with complicated lofting and profiles. Let’s have a look using a more ‘in-place’ approach with 2 splines per rig.

Clearly it has failed to generate. Now, by making a seemingly simple modification to ONE of these rigs, we can get the WHOLE mass to work.

So, a couple of things we can say about this – and please note that these are my own conclusions – on how this kind of mass behaves and how to get it to work. Firstly, by pulling a singular point out of ‘alignment’, the mass functions. Secondly, you’ll notice that the points along this particular spline are quite numerous and close together - this is too complex for R/V to calculate/generate. After a lot of trial and error, I can give some pointers on how to construct these lofting profile-rigs:

1. Keep the number of points of your ‘spline by points’ to the absolute minimum. There’s a compromise here on your part as a designer, because you simply cannot constrain it as far as you’d like to. So how many is too many? Well;
2. The golden rule, for this mass at this scale, seems to be that R/V wants the points at around 2000mm/units  apart from each other at the more critical - that is to say curvilinear - locations (sorry to you imperial users - I have no idea how this will translate), and then it seems to function properly. This is an arbitrary number related to this example only.
3. The surprise third thing is that it is actually to do with the ratio of points. As in, the height of the loft, the regularity of the rigs, and the amount of points constraining each spline. So why did this example work?

By pulling the single point out of plane, it enabled the distance along the spline to be increased, or it shifted the relationship of the ratios at play. The 2000mm/unit golden rule is NOT a constant for all masses – it will vary from mass to mass. This is a very imprecise guide on how you might get it to work, and an issue I’m sure I will revisit as I learn more.

 

Nailed it.