Super Families: A Kit of Parts
Building 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.
Figure 1: Super Families, creating a door’s kit of parts.
Define Your Requirements
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 parameters(1)) 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 on a project.
Based on these requirements, a single family, controlled primarily by instance parameters(2) 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 host(1) 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 parameters(1) and family type parameters(1).
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 family(1), 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 grouping(1). 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 determined by “height” in one family, but “height” does not exist in another, switching between types will cause A to lose its association to the “height” parameter—even if you switch back to type A.
Note that an instance of the category for which you are creating a family type parameter must already be in the host family. Otherwise you will not be able to create the family type parameter.
Templates
Once you have a road map set up for how to make the parts of your family, a template should be created for each one of them. Each template should contain all of the potential parameters for that part as well as the full range of flexibility that the part may need. This complete integration will help to address the parameters mentioned above.
The panel template is created in the generic model category out of one extrusion with two voids in it. The voids can be “turned off and on” and their extents and infill pieces controlled. This allows for the creation of any number of the panels in Figure 2. Note that all solid geometry should be placed onto an appropriate subcategory (i.e., door panel, door glazing, and door louvers) to allow control within the project.
Figure 2: Door panel template.
The frame is created in the door category and made to accommodate sidelights and transoms of any (regular) shape or size. While these parameters may not be used in every frame they need to be there so as to not break the link for those doors that use them.
Note that all solid geometry should be placed onto an appropriate subcategory (i.e., door frame and door glazing) to allow control within the project. Note that this method may need to be modified if you are using copy/monitor extensively for openings.
Figure 3: Door frame template.
The door operation family is created in the window category. These tend to be fairly simple families with the plan representation created as annotation lines and the elevation symbol created using model lines. These families should use the same set of standard parameters for height, width, and swing as the other parts. This will help minimize the number of parameters as well as make the families more user friendly.
Note that you may want to switch the line types depending on your graphical and project needs. For example, if door arch lines are to be painted on the ground, the swing line may want to be a model line. Alternately, the elevation swing lines may want to be annotative so they are not constantly showing up in renderings and walkthroughs.
Putting it All Together
Once all your templates are created, they can be assembled into the host family1.
To assemble your parts, load at least one panel, frame, and operation family into the host. Each one should then be placed and locked to the family centerline. The parameters from each part are then mapped to the host so that they are accessible within the project. The mapping of the parameters includes the family type parameter. This is always set on the instance properties of a family and is called “label.”
Figure 4: Associating family parameters.
The host family is also where you set up formulas to be tagged in the project. While you could set these up within the nested pieces, changes would need to be made to every instance of the nested part and could create potential conflicts if one part is overlooked during an update.
I also place some limited geometry within the host family itself. Mostly this just consists of the panic bar, which is a generic block that applies to any door when panic hardware is required. While this could be part of a nested family or even its own piece, it is easier to create and control it once in the host rather than in every panel.
Once the basics are put together, you need to determine the kit of parts that will be used within the project. Additional frames, panels, and operation types can be loaded, modified, and changed within the family. For instance, our template contains a door with types 1-8. If you plan on using only types 1, 3, 4, and 8, the unused families could be deleted and the others renumbered. This is best done at the start of a job; otherwise the parameter value in the project may need to be adjusted as well.
What Comes Next
Make sure you test your family and its parts as you go along. Test them in the family editor as well as a dummy project. Also, be sure that you get the input of others throughout your development process. The worst thing to do with any family is to make it in such a way that no one else can use it.
Once the family is “working properly,” place it in your project template and set up legends, schedules, and tags. Remember to place all of your shared parameters into the template as well. This will allow you to manipulate the family in the project as well as use the values in schedules and calculation.
Other parts may need to be added. I have created door access clearances along with a one-button schedule that can be used to check access compliance in plan as well as check for other clearance and compliance issues. This, along with several other items, could be added based upon your project needs.
Using a family in a real project inevitably changes the way you think about it. Start off with a basic kit and add on from there. Over time, your needs—as well as Revit’s capabilities—will change and evolve. Starting out with a modular kit will help you stay in step.
Conclusion
Families may be difficult at first. However, breaking them down into parts simplifies their creation, use, and editing. Plan for what you need now and for potential growth in the future.
Finally, remember to document your concepts and process so that others can use what you created.
Samples and Reference Files
Definitions:
(1) Family Type Parameter: Switches an instance of a nested family within the host family between other families of the same category.
Host Family: The family that is placed into your project. This family primarily contains nested families, but may contain native geometry as well.
Associated Parameters: Connecting a parameter from a nested family to the host family.
Nested Family: This family is not placed directly into a project, but is instead loaded into a host family. This family primarily contains native geometry.
Nesting Group: Nested families are grouped based on their use (i.e., panel, frame, and operation). Each group is defined by a consistent set of parameters.
Shared Parameter: Are user-created parameters that have a specific ID that allows them to be tagged, scheduled, and edited within the project, not just the family?
(2) Instance vs. Type: The projects I work on tend to be less repetitive. If you work on projects that have a significant amount of repetition (i.e., hotels) you may want to use type-based parameters instead.
(3) Reference Files: http://db.tt/TqUzQD19
Nicholas M. Kramer, LEED AP BD+C, is a project leader and BIM project administrator at HMC Architects in Ontario, California. He is the company-wide resource for BIM content creation and standardization on a wide variety of education, healthcare and civic projects. Nicholas is currently serving as the president of the BIM User Group Inland Empire (BUG.IE), Program Manager for the Revit Technology Conference North America, and has lectured on BIM and sustainability at Autodesk University and other forums. He can be reached at kramernicholasm@gmail.com
