To Host or Not to Host
Families are the building blocks of an Autodesk® Revit® model. According the Revit help file, “A family is a group of elements with a common set of properties, called parameters, and a related graphical representation.” They are the “things” that contain and display information in the model. In Revit terms, without families there would not be a Revit model.
Because families are so integral to a Revit model, it might be said that a proper grasp of Revit itself requires a proper grasp of families. However, the topic of families is a broad subject with several layers of complexity. In this article we will explore just one aspect of families: hosted versus unhosted.
There are three basic types of families: system, loadable, and in-place families. System families include elements like walls, duct, piping, and conduit. These family “systems” cannot exist outside of a project or template (.rvt or .rte, respectively).
In contrast, a loadable family is one that can exist externally from a project or template. These families have their own file type (.rfa) and can be created and modified independently of a project or template. Because these families can be stored in external file locations, they can then be loaded into projects on-demand, hence the term loadable families. When modifying or opening a loadable family, it is automatically opened in what is called the family editor, providing functions and controls specifically for family creation and management—different from what you would see in a project or template.
Lastly, in-place families are those that are neither a system nor a loadable family. They are project specific and generally reserved for unique scenarios where a loadable family is not pragmatic. In-place families are the least used kind of family.
From an MEP perspective, loadable families make up the vast majority of the kinds of elements that get placed in a model: air terminals, duct accessories, pipe fittings, mechanical equipment, electrical equipment, electrical fixtures, data devices, security devices, etc. Placing content in these Revit categories is what gives families their “intelligence” and also provides visibility controls for that content within a project.
There are several considerations when planning to create a loadable family. The help file does a pretty good job stressing the importance of planning what your family needs before just jumping in and beginning. Why? Because some decisions, once made, are not easily undone. Some properties cannot be toggled on and off. Understanding the desired behavior of the finished family and how to achieve it is essential to creating a successful family.
One such important consideration when creating a family is what Revit refers to as “hosting.” In the most basic terms, families are referred to as either being hosted or unhosted. Within each camp there is then further specification. Technically all family content in Revit is hosted, be it a wall, ceiling, level, or face. But the terms as they are used have taken on special meaning.
Hosted Families
A hosted family is one that requires a host in order for the family to be placed in the model. Types of hosts can vary and include walls, ceilings, roofs, and faces (the face of the hosting element; still hosted but less specific). For example, if a family is built to be wall hosted, that family can be placed only if a wall is available in the host model. This approach has its advantages. One is that geometry within the family can respond to properties of the wall, such as wall thickness.
Another consideration is that placement of the loaded family is a littler easier. During placement, if an acceptable host is not found it cannot be placed. When an acceptable host is found, the family “sees” orientation of the host and responds accordingly. Proper placement is therefore less manual.
However, for most MEP uses, hosted families of this type are not practical. For starters they do not work across linked models. Very few projects have all disciplines working in the same model, so the most common approach is to have the architectural model(s) linked in as a background. In this approach, a wall-hosted family could not be placed in the MEP model because the walls exist in the linked model, not the host model.
Another rather large disadvantage is that if the host is deleted the hosted element(s) is also deleted. This makes sense (you can’t really have a door without a wall) but in terms of coordination across teams, deleting a wall could have unintended consequences. The deleted wall would also remove any wall-hosted light fixtures, air terminals, or electrical fixtures hosted to that wall.
A compromise of sorts are face-based families. These families look for the “face” of other elements, but not specifically a wall or ceiling, etc. This allows them to retain some of the automatic nature of the hosted family types. They see and orient to faces that can act as hosts. They work across linked models. If the hosting element is moved, the family will move with it when updated. If the hosting element is deleted, the family remains, unlike ceiling-, wall-, or roof-hosted families.
How a family is hosted is one of those properties that is not easily changed. It is a decision made at the beginning of family creation and cannot be changed later. Ten years ago or so, when MEP for Revit was beginning to catch on and manufacturers were beginning to offer more Revit content for download, this was a fairly common dilemma. What is the solution in this case? A convoluted process where you copy/monitor the hosted family which creates a face-based version of the family. Further adjusting and tweaking is still required, but it is often the best option compared to rebuilding content from scratch.
Face-based families also have two key characteristics that are important to MEP workflows. First, face-based families have a parameter called Default Elevation. This a hard-coded parameter that only exists in face-based families. It tells the family at what elevation (height) to be placed. This parameter only applies when placing content in plan views (not 3D or section) and only applies at instance placement. Changing the default elevation parameter value will not affect already placed elements and it also cannot be scheduled (Figure 1).
Figure 1
Secondly, certain family categories of face-based families have another important parameter to be aware of: Maintain Annotation Orientation (Figure 2). Because nested generic annotations are a common workflow in MEP, this forces those nested generic annotations to appear correctly in plan view. All the “device” categories have this parameter (data device, fire alarm device, electrical fixture, etc). Mechanical equipment, electrical equipment, and lighting fixtures do not.
Figure 2
There is a caveat: this only works if the element is parallel to the plan view. For example, if a ceiling or bottom of deck is sloped, the family will correctly host but the nested generic annotation will not be visible. A tag or other means will have to be used.
Face-based families do have some shortcomings compared to hosted family types. For one, they do not respond to the properties of the hosting element—wall thickness, for example—like other hosted types.
Second, while it is a positive that a family placed on a face will respond and move accordingly if that host is moved, it can also be a negative. If a ceiling moves too much in the vertical, it can cause duct connected to air terminals to have to “disconnect.”
Furthermore, the hosting information of a face-based family is tied to the element ID of the host. In order for the family to move with the hosting element, the hosting element must be moved—it cannot be deleted and redrawn.
There is also a known issue where the elevation of a face-based family placed in vertical (on a wall) is relative to the bottom of the wall. Therefore, if the bottom of the wall is changed, the face-based elements on that wall will also move (incorrectly) in vertical. It is cases like this where automatic movement of face-based families can still go mysteriously “missing” when a linked model is updated, requiring users to find the elements that moved unexpectedly.
Revit does have a feature called Reconcile Hosting (Figure 3) to help find elements that have lost their host. Revit calls these elements “orphaned.” This can aid in finding elements or discovering where changes were made in the linked model(s).
Figure 3
Unhosted Families
If all this sounds like too much trouble, the other option is unhosted families (non-hosted/not hosted). As mentioned earlier, these families are still technically hosted. Unhosted families are hosted by a level. As such, I have gotten in the habit of calling them level-based families.
While these families lack the “intelligence” of seeing and orienting to model geometry, this can also be seen as increased flexibility. Translation: unhosted families can be placed independent of geometry (or reference planes), even if walls, ceilings, or floors are not in the model yet.
Both face-based and level-based families can easily be moved or copied in plan view, albeit differently. In plan view, a face-based family is constrained to the vertical face of its host. It can easily be move or copied along the face of that host. Moving or copying to a different face requires it to be “unconstrained,” if using the move or copy command. Two other methods are to use Pick New Host or Create Similar.
For a level-based family, its constraint is the level. Its level association can be changed if desired. It can be moved or copied easily in plan view, but rotation must be achieved manually. This can be done using the Rotate command or by using the spacebar, which will rotate it in 90° increments.
One area of difficulty for level-based families is placement on sloped elements or planes. Taking a sloped ceiling or deck as an example, in plan view the symbol may look correct, but in 3D or section, the element will not be oriented correctly to the ceiling or deck. Because it cannot be rotated in the project, the solution is to build rotation parameters into the family to control its 3D geometry.
Unlike face-based families, a level-based family WILL BE deleted if its host, a level, is deleted in the project. Thankfully with Revit 2019, we are now warned that elements, not just corresponding views, will be deleted if the level is deleted (Figure 4).
Figure 4
Level-based families have an option to make them “work plane based” (Figure 5), which is as easy as toggling a checkbox in the family editor. This allows them to be hosted to faces and planes, but they will not host to vertical faces in plan view like face-based families.
Figure 5
Want to know if a family is face based or level based? In a project, Revit offers many visual cues. When placing, if you see “Place on Vertical Face,” “Place on Face,” and “Place on Work Plane” in the ribbon (Figure 6), you know it is a face-based family. Also, a face-based family will display a stop sign and the family or nested generic annotation, if using, will not be visible when placement is not possible because a suitable host is not found. Conversely, a level-based family will not have these options in the ribbon and the family or nested generic annotation is always visible, assuming it is within the view range.
Figure 6
In the family editor you can determine if a family is hosted or unhosted by looking at its Constraints parameter properties (Figure 7). If it is hosted it will say wall, ceiling, etc. If it is face based it will say face. And if it is unhosted/level based, the value will be empty.
Figure 7
Final Thoughts
One area where level-based families have a clear advantage over face-based families is when it comes to grouping. Groups and face-based families simply do not get along. You can make a group containing face-based families, but try to use that group in the model by rotating it or placing on other levels and watch the errors fly and the confusion set in (Figure 8).
Figure 8
So, hosted or unhosted families—what is the best choice? That depends. I was a die-hard advocate for face-based families, but now I take more of a calculated risk approach. It certainly depends on the desired goal and behavior of the family and project. Take a security camera as an example. It tends to be a unique placement, not replicated in the same location on multiple levels and not tied to a physical system, like duct or piping. This is a good candidate for a face-based family.
Now consider data devices as another example. These tend to be duplicated, depending on furniture and office layouts. A situation like that can typically benefit from groups to quickly and easily lay out devices. Thus, a level-based family may be a good choice.
This article has barely scratched the surface on the topic of Revit families. New user or seasoned veteran, when building Revit families it is always wise to consider the choices, and their consequences, before embarking on creating families. Over time, a library of families can be built to meet a multitude of scenarios and project requirements. To host or not to host? The choice is yours!
Nathan Mulder has more than 10 years of experience in the AEC industry. He is currently the BIM and CAD Manager for Guidepost Solutions, a global leader in investigations, compliance, and security consulting, offering design services for security, telecom, and technology systems. A Revit MEP Electrical Certified Professional, Nathan is always looking for ways to fully leverage software to improve the project design and management process. Contact him at mulder.nathan@gmail.com or on LinkedIn.
