product focus
Revit Architecture
2012
By: Nicholas M. Kramer
Super Families: A Kit of Parts
➲
B
uilding Information Modeling (BIM) revolves around data, and in Autodesk® Revit® most of that data is stored within families. Unfortunately, the family editor within Revit is one of the most difficult things to master. However, breaking it down and standardizing an entire category can help to simplify this. Standardizing one category into a single family or group of families can make it more intelligent and easier to use. This standardization is typically referred to as a Super Family. Using a door as a case study, we will walk through the basic outline and process of super-sizing any category.
Define Your Requirements
Based on these requirements, a single family controlled primarily by instance parameters2 seemed to be the best fit. This set up allows drop-downs and check boxes within a schedule to control the graphics, construction, and code analysis without accidentally changing other objects. In addition, the door was broken down into its main parts: panel, frame, and swing. Each one of these parts is created and manipulated separately and then loaded into a host1 or container family. This limits the number of objects that need to be created while allowing any number of combinations amongst them.
Back of House Set Up
These constraints led to the use of shared parameters1 and family type parameters1.
The first thing to do with any Revit family is define what you want out of it. This means that the end goals of the family determine how and what is built. In the case of doors, I knew the following. Most of the editing occurs within schedules. Historically, the bid and contract documents are based on the schedule. This has led to a workflow where data is input into a schedule and the graphical ramifications are not necessarily checked. This means that the scheduled data needs to directly control the graphics in order to take advantage of Revit’s links between the plan, elevation, and schedule data. The doors need to be tied to exiting and code analysis. Generally people expect to be able to pull things such as exiting width and door signage directly from the door. While this complicates the back of house creation and maintenance of the door (you need to know the code and associated formulas as well as understand shared parameters1) it makes things significantly easier for a project and end user. The end user controls need to be simple. In general, you get to pick what part of the family is complicated and what part is simple. This means that simplifying the end user controls complicates the back of house set up or vice versa. Fortunately the back of house set up is typically a one-time process or at a minimum is accessed significantly less than the day-to-day work Figure 1: Super Families, creating on a project. a door’s kit of parts. 32 www.augi.com
Shared parameters allow the door to be manipulated from the schedule as well as providing a unified system for controlling and tagging the parts. Family type parameters allow you to create multiple objects, nest1 them into a host family1, place only one of them, and then switch between all of them. The downside of family type parameters includes: • The drop-down list is populated by every family and type of a single category that is nested into the host family. This means that in order to prevent a panel from being used as a frame, each part of the door must be created as a separate category. I use the Generic Model category for door panels, the Doors category for door frames, and the Windows category for the door operation. • The full name of the family and type is displayed. This leads to the need for simplified names for both families and types. We use A-Z for frames, 1-99 for panels, S for single, and D for double (i.e., a single door panel of type 1 will show up as 1:S in the schedule). • They cannot be used in formulas. This reinforces the simplified names above. • Standardize parameters. Any assocated1 instance parameters need to be standardized between all types within a grouping1. If an instance-based parameter exists in type A, but not type B, switching from A to B will cause this parameter to become disassociated. This means that if the height of the door panel is deDecember 2011