Adaptive Component Origins in Revit

Have you ever wondered how Revit manages the "Origin" (X,Y,Z = 0,0,0) of an adaptive component?
It is somewhat different from the way it handles origins and insertion points of traditional Revit families.  So here is an analysis of the differences between the two.

Traditional Family Insertion Points

A traditional Revit family typically has three reference planes that intersect at the origin point - representing the X, Y and Z axes.  To start with, the origin is the same as the insertion point when the component is placed in a model.  For this discussion we will only think about the X and Y axes in plan because the vertical insertion point (in Z axis) is locked to the level (in the family) and does not change (unless you use the Offset property - see below).
At some point those X and Y reference planes might be moved within the family.  This may or may not affect the insertion point, depending on the reference plane properties:

• If the reference planes are moved, and they are set to "Defines Origin" then the insertion point will move to the intersection of the two reference planes

• Alternatively, one or two other reference planes might be set to "Defines Origin" - if they are in the X or Y axis, they will take over the origin property from the Centre reference planes (and the centre reference planes will have that property unchecked);  if the other reference plans are not orthogonal then Revit will ignore that setting, and use the centre reference planes or the original origin point.
• If no reference planes in the family are set to "Defines Origin" then the insertion point will remain at the original X=0, Y=0 origin
• If only one of the reference planes is set to "Defines Origin" then the insertion point will be at the intersection of the "Defines Origin" reference plane and the original perpendicular axis.
• If the insertion point of a family is changed and then reloaded into a project  where some have previously been placed, it will overwrite the family definition in the project and will move the geometry in any placed components of that family (by the same amount that the insertion point moved).

For this reason it is good practise to make sure the two reference planes that define the insertion point are not moved from the origin once you have decided where it needs to be (keep them pinned).  Geometry should be moved relative to the origin if need be.

Hot Tip:  If you lose track of the true origin, just create an Autocad file with a cross intersecting at X=0, Y=0.  Save the dwg and import it in to your family at "Origin to Origin"; trace over the cross with reference planes or lines; delete the dwg; purge the dwg (since you can't link dwgs into a family, you need to import, then purge).

Offset.
Most traditional unhosted Revit families have an "Offset" system parameter that is automatically created when you load the family into a project (this contols the Z offset from the placement level or workplane).  Recently we found some old plumbing families (baths) that did not have the Offset parameter - we believe that this is because they were created from very old family templates that pre-date the addition of this offset capability, from the dim distant Revit past.  Hosted and face-based families usually have an "Elevation" system parameter (rather than Offset), which works like Offset but only in the project vertical axis, whereas the Offset parameter works in the local z axis of the family, which may not be vertical in the project.

Adaptive Family Insertion Points

Adaptive components behave in a different way.:

• Although they have a true origin with two reference planes intersecting there, the insertion point can be overridden by adaptive points.
• If there is no adaptive point in the family then it behaves almost like a traditional family, except that the "Defines Origin" parameters appear to make no difference - the origin and insertion point remains at 0,0 regardless of whether any reference planes have that property checked
• If there is an adaptive Placement Point in the family, then Revit uses that as the insertion point of the family;  however it still remembers the true origin

 

• If the only adaptive points in the family are Shape Handle points, then Revit uses the traditional origin as the insertion point (not the adaptive point)

• If a placement adaptive point is deleted (in the family) or changed to a shape handle point, Revit does not move the geometry when the family is reloaded into a project.  This is because Revit knows and remembers where the origin is even though it uses adaptive placement points for insertion - this is logical but can get confusing.

If a placement adaptive point is moved (in the family) then reloaded into a project it might move geometry of previously placed components - it depends if the geometry is hosted on the adaptive point or not.   In this example the hexagon is hosted on the adaptive point;  the circles are just placed on the level workplane, close to the origin point.

Geometry in the family

Geometry in the model

• Any geometry hosted on the adaptive point remains where it was in the model when the family is reloaded; 
• Any geometry placed in the  family but not hosted on an adaptive point will move relative to the 0,0 origin point - so if the adaptive point is moved/flexed in the family it will end up a different distance from the point in the family;  when reloaded, the unhosted geometry will move in the project so that it retains that distance, while the hosted geometry remains put at the insertion point

 

• Once you are in the project environment, and you move the adaptive point, something different again happens:  all the geometry in the family moves together! (this can be hellishly confusing).

Offset. 
Adaptive components do not have an Offset system parameter.  Instead they have an "Elevation" parameter, which does not appear to do anything - neither unhosted elements nor elements hosted on adaptive points will move when this Elevation value is altered.

Adaptive Component Reference Planes

Most adaptive component demos that I have seen show the placement of adaptive points in random locations in the family.  Why?  Probably just because you can.
I am more careful - I always put adaptive point #1 at the origin (intersection of the two reference planes that exist in the family template).  I do it for a reason, even though it takes a few extra steps - I have to go to a plan view because points won't snap to ref plane intersections in 3D.  If there is a second adaptive point I will snap it to the X axis for the same reason:  . . . .

• Let us assume that you place an adaptive point in a random location;
• Make it adaptive
• Then place some geometry associated with the point (set the work plane to its horizontal plane first)

•  You could place a dimension just to check how far it is from the origin

• Load the adaptive family into a project and place one (it uses the adaptive point for insertion)
• Try placing a dimension to roughly the same distance from the adaptive point as it was in the family - the hidden reference plane in the family will highlight and allow you to snap to it

•  Once you place the dimension, the highlighted reference plane disappears

• You could do the same with the other axis reference plane
• Revit will attempt to snap to those reference planes and their intersections during many other commands that involve snapping - even to remote objects.

Its not very helpful is it?  In fact it is downright annoying when you have lots of adaptive components placed.

• Imagine what happens when you have two adaptive points placed in the family at random, with some geometry between them?  

• The hidden reference planes are now at crazy angles in the project and cause all kinds of random snapping locations

Hot Tip:  In v2013 the developers gave us a solution to this issue by enabling the  properties of those reference planes to be set to "Not a Reference" [that did not work in v2012, I think]

Good Practise: 

1. Chances are that you will forget to change this setting some time, so it is a good idea to get into the habit of putting adaptive point #1 at the true origin, and point #2 on the X axis so that these reference planes will be orthogonal to the geometry.
2. Whenever you flex the family by moving the adaptive points, remember to put them back to where they were, so that you don't get strange behaviour where unhosted elements in the family might move in the model when you reload the family into the project.

For more differences between traditional and adaptive families refer to Rival Revit Environments

Circular repeater geometry in Revit

In previous posts I have described how easy it is in Revit to use a circle as a rig to host regular geometric shapes like squares and hexagons.  It occurred to me the other day that circles would also be ideal hosts for parametric stars;  put that together with Repeaters and you get some interesting possibilities . . .

Here is how to create a parametric star:

• Create a new adaptive component;  
• Place a point at the origin; make its reference planes visible
• Set the horizontal ref plane as the work plane
• Place a reference line circle onto the point
• Make its radius dimension into a parameter

• Select the circle
• Divide Path

•  It will create a divided path on top of the circle with 6 nodes

• Create another Adaptive component
• Place two points, and make them adaptive
• Place a line between the points, remembering to enable "3D Snapping" first

• Save the second family (eg. as "AC 2pt Line")
• Load it into the first family
• Place one of the components onto two non-adjacent nodes

 

• Select the two-point component and click on the Repeat command

• You should end up with a triangle
• NB.  if you placed the two-point adaptive line component onto adjacent nodes you'd get a hexagon

• Actually, a triangle is only half of what we want, but we need to backtrack to get the correct result - so, UNDO the repeat command
• Place a second two-point adaptive on alternating non-adjacent nodes

•  Select both lines and click on Repeat

•   
•  You should end up with a six pointed star, which is now a "Repeater"

• Select the divided path, and change the number of nodes to 5, giving you a five pointed star

•  Change it to 4, which gives a cross (not so useful)

•  Change it to 3 for a triangle

•  Change it back up to 7

•  And then to 8 - this gives an eight pointed star that could be useful in tiling patterns when repeated itself on a divided surface

•  As the number of nodes increase, the shape becomes closer to a circle

• Now all you need to do is turn the number of nodes into a parameter to get yourself a one-point adaptive parametric star component
• Oh, one more thing - you need to make the nodes of the divided path not visible otherwise they will show up when this component is placed in a project or another family

How useful is this going to be?  We'll investigate that in a future post . . .
Here is one possible use - geometric patterns

Troubles with overlapping pads in Revit

Have you ever hasd that infuriating message about not being allowed to have overlapping pads in Revit?  Why should it matter?  It would be so much easier if the lower pad took precedence in the overlapping area, and just cut into the topography.  Well that is not the way that the software is written, so here is the technique that I use to get around the problem:

Pads at different heights cutting into a Site terrain (building hidden)

 

You can see from the image above that the building being modeled has a basement over part of its floor area, so a pad is required for the basement, and then other pads are required for the various different heights of floor slabs at ground level.  Some of the pad edges need to be curved.

Option 1.
To make sure that the pads don't overlap, you could try creating the basement one first, and copy the sketch lines (to clipboard);  then start the next pad and paste the sketch lines in the adjoining area where they share a boundary, before completing the rest of the sketch.  Well, this can work sometimes, but usually not if any of the shared boundary between pads contains arcs - Revit usually considers two adjoining pads to overlap even if the adjoining boundary is one arc of exactly the same radius in the same place (perhaps it segments the arcs but does it differently for each pad?  Who knows, but it does not work).  You could try segmenting the arcs yourself to ensure that copy and pasting lines works.

Another problem with this method (assuming no arcs), is that when it comes time to change the pads you have to do a lot of double handling with temporary changes, copying lines between pads, then final changes, all to avoid any overlaps during the change process. 

Option 2.
A much better solution is to create Reference Planes along the common boundary lines between each pad, before creating the pads.  Then, when sketching the pad boundaries, you need only to pick the reference lines and lock to them (and trim the corners).  This will ensure that the boundaries do not overlap.  Another big advantage is that when you want to change the pad, all you need to do is move each reference line, and it will alter both pads at the same time, ensuring that you don't get those annoying messages - and you don't even need to go into edit/sketch mode for the pads.

 

 

 

Reference planes define boundaries for pads

You might want to put the reference planes into a workset that has its visibility hidden by default so that they don't clutter the screen, and so that they don't get accidentally deleted.  Just to be sure, you might also name the reference planes (pad boundary 1, pad boundary2 etc) so that your users know what they are for.

When it comes to arc segments of adjoining pads, you can use the same technique providing the extent of the arc segment is identical in length (as well as radius).  Obviously you cannot create curved reference planes so you'll need to use another technique - perhaps a gridline or just a line (model or annotation).

I hope this saves as much time for any readers here as it has for me.