#08 | Axes and Mirroring: the Revit Nested Family That Holds Up
Umberto RinaldiThe moment everything seems to work — and then it doesn't
You're done. The host family is ready, the nested family is in, the parameters seem linked, the model is clean. You load the family into the project, place it, and then — almost by instinct — you mirror it. And that's when something strange happens. The drawer opens towards the wall. The handle is on the wrong side. Or, even worse, the geometry looks right but something is off — and you can't figure out what.
It's not a Revit bug. It's a decision you didn't make, or made without realizing it: where you placed the origin of the nested family, and how you set its axes.
In Inside the Files #07, we discussed what nested families are and when to use them. Now, let's delve into their construction — and address the two moments when a nested family can undermine even the most robust workflow.
The Nested Family's Axes: A Decision, Not a Default
When you open a new family template, Revit presents you with two intersecting Reference Planes and an origin. It seems like a neutral detail. It's not. The origin of the nested family is the point Revit uses to place it within the host. It's the anchor point, the invisible reference around which everything revolves — literally.
Where you place the origin, and why it matters
In the case of the nightstand, the drawer is a nested family that slides horizontally. The choice of origin is not random: the drawer's origin should be placed on the Back plane, with Center Left/Right alignment.
The reason is constructive: once nested, the drawer is "placed" on the Reference Line that controls its forward and backward translation. That line is the invisible rail of movement — and for it to work cleanly, the origin of the nested family must exactly coincide with that control point.
If you place the nested family's origin elsewhere — at the geometric center of the drawer, for example — the Reference Line doesn't have a consistent anchor point to control. The drawer will be positioned with an offset that you have to compensate for manually, and any subsequent modification becomes a chase.
The general rule I set for myself: the nested family's origin must coincide with the point the host uses to control it. Of course, there's no universal answer — it depends on the constructive logic of the family, but the decision must be made consciously, not left to the template.
The dialogue between axes
When you nest a family within the host, the nested family's Reference Planes communicate with the host's. If the axes are aligned and consistent, placement is clean. If they're not, you start dealing with strange offsets and unpredictable behavior.
A simple check: before nesting, open the nested family and ensure its main Reference Planes are labeled with the correct Is Reference properties — Left, Right, Front, Back, according to the family's logic. Don't leave planes unnamed or misclassified: during placement within the host, those planes become your control points.
Mirroring: Two Acts
Act 1 — The flip and the axes
When you mirror a host family in the project, Revit doesn't just mirror the visible geometry. It also mirrors the internal logic — and the nested family is dragged into this operation.
The nested family's behavior during mirroring depends on how its axes are set. If the host's mirroring axis is aligned with a correctly classified Reference Plane in the nested family, the flip works: the geometry inverts consistently.
If, however, the axis is not classified — or is misclassified — the nested family inverts geometrically, but illogically. The geometry appears mirrored, but the control parameters continue to work as if they were in the original orientation. The result is a family that seems to work until you try to modify it.
The critical point for me is this: the Reference Plane used as the mirroring axis in the host must be consistent with the Is Reference classification of the nested family. It's not enough for the axis to exist — it must be recognizable by both families.
Act 2 — The detail almost no one does
You've mirrored the host. The nightstand is oriented correctly, the front is right, everything seems fine. Then you try to verify the behavior of the drawer slide — the Reference Line that controls the translation — and something doesn't respond as you expect.
The problem isn't with the mirroring itself. It's in what happens immediately after, and what almost no one does out of habit.
When you mirror a family in Revit, the resulting copy loses its association with the Reference Planes. The drawer slide — which in the original family was constrained to its reference planes with surgical precision — in the mirrored version is free. It exists, it's visually correct, but it's not anchored to anything. It's placed, not fixed.
The practical consequence: the guide no longer follows the Reference Planes as it should. The drawer may seem functional until you try to modify the family, move it, or work on position parameters — and that's when inconsistent behaviors emerge, difficult to track because everything visually seemed fine.
The correction is simple, but must be done every time: after mirroring, select the resulting family and manually reassign the association to the Reference Planes. Thirty seconds of work that avoids silent and difficult-to-diagnose problems.
📐 Inside the Files tip
Always mirror in two steps, not one.
First: mirror the family and verify that the geometry is correct — consistent axes, nested family oriented correctly.
Second: reassign the association to the Reference Planes of the mirrored family. Don't take it for granted — Revit does not automatically maintain it after mirroring.
If you build this into a habit, you avoid an entire category of problems that manifest late, silently, and are difficult to trace.
The axes of a nested family are not a setup detail — they are a design decision that determines how the family behaves in every context: placement, modification, mirroring. Making it consciously, at the beginning, takes a few minutes. Not making it costs much more later.
Mirroring is the most severe test for a well-built nested family. If it holds up — correct geometry, consistent flip, maintained association with planes — the family is solid. If not, the problem is almost always upstream: in the axes, in the Is Reference classification, or in the missing step after mirroring.
In the next episode, we delve into the most subtle block: passing parameters from the host to the nested family. Everything seems to work — until it breaks at the wrong time, for an unexpected reason.