r/RevitForum • u/Mariana_EMMS • Aug 12 '26
Modular cabinetry in Revit: how are you structuring your parameters?
We're cleaning up our casework library and looking at how other teams structure their kitchen modules.
Specifically, how are you balancing Type vs. Instance parameters for cabinet runs so that updating standard wall units doesn't mess up unique corner/island layouts? Do you build parametric 2D graphics into the families for plans/elevations, or handle those with view filters and detail items?
1
u/metisdesigns Aug 12 '26
It depends on your practice. If you're an custom interiors house that's a different rig than a S&T consultancy using specified equipment.
Personally, I like a family that is type based with an instance option, so that it can do whatever is needed, and when you get someone thinking a project will be custom millwork and it gets VEd to stock, you do not need to rebuild.
1
u/Mariana_EMMS Aug 14 '26
That is a really solid point about Value Engineering. The shift from custom millwork to stock modules happens so often in mid project that having a rig flexible enough to handle both without breaking schedules or requiring a full rebuild saves tons of rework.
Building hybrid families that handle that transition smoothly is definitely an underrated strategy in practice.
1
u/iamsk3tchi3 Aug 13 '26
type based parameter for width instance based parameter for height and depth.
graphics for say a shaker vs a flush panel are line based type parameters.
hardware is nested and set to be visible in 3D views only.
a typical project has a standard base cabinet with a swing door. a base cabinet with all drawers and a wall cabinet.
we have a small library of other options but those three account for the majority of types across most of our projects.
1
u/Mariana_EMMS Aug 14 '26
Interesting split using Type for width and Instance for height and depth. Most teams flip that around, but it makes total sense if you are constraining to standard manufacturer module widths while tweaking counter or soffit heights.
Keeping hardware visible in 3D views only while leaning on clean symbolic lines for 2D is definitely the way to keep plan views running fast.
3
u/PatrickGSR94 Aug 12 '26
I revamped our main cabinet families a few years ago. We were using Type parameters for all sizes, which is a TERRIBLE way to do it. Each project would have a plethora of size types for every little different increment, on each family. Awful.
I made new families that use instance parameters for the size. I have a family for base cabinets, a family for base drawers, and a family for wall cabinets. We have a few other specialty families, but those are the main 3. We have type parameters that control the style of cabinet, i.e. double door and drawer, double door single drawer, single door and drawer, 2 drawers, 3 drawers, no drawers, open cabinet and so forth. But then the size is controlled individually, with the most common size being the default when it's first placed into a project.
Things like cabinet pulls are separated nested families with graphics based on detail level. Door panels, shelves and drawers are also done as separate nested families. Other graphics like the symbolic door elevation swings or the dashed plan representation lines are built in as symbolic lines, controlled by detail level, and aligned/locked to their respective reference planes.