#10 | Everything Moves Together: Anatomy of a Parametric Cabinet
Umberto RinaldiHow Reference Lines, Nested Families, and Adaptive Formulas work in sync
There's a category of Revit Families that deceives you. Not through visual complexity — in fact, they're often the simplest to look at. A kitchen cabinet, four wicker containers, a wooden structure. Nothing spectacular. But when you open the Family Editor and start breaking down the internal logic, you realize that simplicity is the result of precise choices — not coincidence.
The Kitchen Utensil Cabinet is one of these cases. In this article, we take it apart together, layer by layer.
The Family in a nutshell
The cabinet is a Scandinavian-style kitchen utensil holder: wooden structure, wicker containers, available for free on the Factory268 Marketplace. It comes in two configurations selectable via a visibility parameter: four containers with four open compartments, or two containers with two open compartments. The materials — top, frame, containers — are instance parameters. The main dimensions are editable, but so are the details: the top thickness, the frame thickness, the position of the containers along the cabinet depth.
It seems like little. But behind each of these elements lies a modeling choice.
How the containers move
The first element worth analyzing is the sliding of the containers — that is, the ability to vary their position along the cabinet depth via an instance parameter.
The solution adopted is simple but effective, and is based on a Reference Line. Its endpoints are constrained to the lateral reference planes of the family. A dimension with a distance parameter — an instance parameter, therefore editable project by project — is associated with this Reference Line. The nested family of the container is associated with the vertical plane of the Reference Line: when the parameter changes, the Reference Line shifts, and the container moves with it.
No formulas, no conditional logic. A direct, clean, predictable geometric constraint. Those who read Inside the Files #04 will recognize this technique — it's the same logic applied to controlling drawer movement. Here it returns on a different object, with the same effectiveness.
The Containers are Nested Families
The wicker containers are not direct geometry of the host family — they are nested families. A deliberate choice, which allows them to be managed as autonomous objects with their own internal parameters, and to associate those parameters with the host's dimensional logic.
The container parameters are set as type parameters. The reason is simple: all containers in the host family have the same dimensions — instance-level flexibility isn't needed there. Dimensional variations are handled upstream, in the host, via formulas.
The Formulas that hold everything together
This is the most interesting part from a construction standpoint.
In the "Construction" section of the host's properties tab, the dimensional parameters of the containers — width, height, depth — are entered with formulas that calculate them based on the family's overall dimensions. The width of each container, for example, is calculated as follows:
(Family Width − Frame Thickness × 5) / 4
The logic is this: subtract from the total width the space occupied by the five vertical frame elements, then divide the result by four — one for each container. The result is that containers and open compartments always have the same width, regardless of how the family is modified. The same setup is applied to the formulas for height and depth.
When you modify the cabinet width in the project, you don't need to touch anything else. The containers recalculate on their own, adapt, stay proportioned. The family behaves like a system — not like a collection of separate objects.
The Visibility Parameter — Why one Family and not two
The two cabinet configurations — four containers or two — are managed with a visibility parameter, not with two separate families. It's a choice worth explaining.
Two separate families mean two files to maintain, two objects to update when something changes, two versions to keep in sync. A visibility parameter means a single family that contains both configurations and allows switching between them directly from the instance properties in the project. Fewer files, less risk of misalignment, more control for whoever uses the family.
The general rule is this: if the variants share the same construction logic and differ only in visible or hidden elements, a visibility parameter is almost always the most efficient choice.
Symbolic Lines — How the Family communicates in 3D Views
A well-built family doesn't exist only in 3D. It exists in plan, elevation, section — and in those views where communicating useful information without burdening the model with unnecessary geometry matters.
The Kitchen Utensil Cabinet includes symbolic lines for container opening and clearance — visible in plan and elevation views. They are not 3D geometry: they are 2D elements that exist only in the views where they're needed, controlled by subcategories and visibility settings defined within the family. In plan, they communicate the maneuvering space required to pull out the containers. In elevation, they define the actual footprint of the object in use — not just at rest.
These are design information, not decorations. And the difference shows when the model moves from render to drawing sheet.
Those who want to go deeper into the construction logic behind symbolic lines — how they are set up, how they interact with subcategories, and how their visibility is controlled across views — can read Inside the Files #03.
The Inside the Files Tip
When you design a family with repeated elements — containers, drawers, compartments — don't dimension them manually. Build the formulas in the host and associate the nested family's parameters with the calculated ones. The time you spend during setup you recover tenfold every time the family is modified in the project. A self-regulating family is not a luxury — it's the bare minimum for working professionally.
The Kitchen Utensil Cabinet is not a complex family. But it's a family built with method — and the difference shows when the project changes and everything keeps working without manual intervention.
Reference Lines for movement. Nested Families with type parameters. Adaptive formulas in the host. Three tools, one logic: everything moves together.
You can download the family for free from the Factory268 Marketplace and open it in the Family Editor — it's the best way to see up close the choices described in this article.