As a Revit user or BIM Manager, you’ve probably had people ask you about “LOD” or “Level of Development”. When it comes to Revit content, this usually translates to asking which LOD your families are designed to meet – 100, 200, 300? You might also be asked about creating different LOD versions of the same families, in order to swap them in and out of models for different stages of deliverables.
These are questions we’ve encountered too many times over the years, and in our view they reflect a misunderstanding both of LOD and of how Revit families are designed to work. This post is an attempt to synthesize our perspective on how LOD applies to Revit families based on our decade-plus of experience creating content and working with consultants, architects and manufacturers. It’s our answer to what works, what doesn’t and how to think about LOD in order to get the most out of Revit content for teams working in projects. But before we get to our answer, let’s back up and clarify what LOD is exactly.
LOD Concept Origins
LOD is a concept first created by the AIA back in 2008 to define the amount of information contained in a BIM element. The AIA established five different “levels of development” that a model element could achieve – 100, 200, 300, 400 and 500 – later adding a sixth level at 350. For example, LOD 100 would only offer generic representation of an object without detail on size or location, while LOD 300 would include specifics on size, shape, orientation, location and quantity.
This core concept was then taken up by the BIMForum, who defined exactly what each level should cover for different types of building components and systems. This took the form of a Level of Development (LOD) Specification first published in 2013. As of this July, the BIMForum has just published an updated 2018 Draft Specification currently available for public comment.
At a high level, LOD makes perfect sense when it comes to looking at how a BIM model will progress over the course of design, construction and maintenance. As more and more of a building’s components and systems are fully specified and made operational, more and more accurate information about them can be incorporated into the model. The architect can say, “A door that looks like this should go right about here,” while later on the contractor can say, “This door model XYZ by manufacturer ABC has been purchased for such-and-such amount and installed in this exact location.”
Problems with LOD and Revit
1. Forbidding “higher LOD” elements in your models.
When it comes to Revit families, the adoption of LOD standards leads to two common misconceptions. The first is the belief that families should not have more detail than required for whatever LOD a firm needs to fulfill. For example, if a firm is responsible for delivering a model at LOD 200, they might have a policy that forbids using any manufacturer-specific Revit families in their model, since LOD 200 is defined as a generic representation of an object, system or assembly.
The thought process behind this lowest-common-denominator approach is something like the following: “If we put in a manufacturer-specific family, then we’ll be liable for having specified that object, and we don’t want to be responsible for that!” What this attitude misses is the fact that just because a model element has more detail does not mean that it meets a higher LOD.
In fact, BIMForum takes pains to make it clear that LOD is not equivalent to “Level of Detail”. In their 2017 Specification, they include the following explanation in a section titled “Level of Development vs. Level of Detail” (section 2.2, italics are theirs):
LOD is sometimes interpreted as Level of Detail rather than Level of Development. This Specification uses the concept of Level of Development. There are important differences.
Level of Detail is essentially how much detail is included in the model element. Level of Development is the degree to which the element’s geometry and attached information has been thought through – the degree to which project team members may rely on the information when using the model.
In essence, Level of Detail can be thought of as input to the element, while Level of Development is reliable output.
What this means is that the LOD of a model element is not automatically determined by the degree of detail or amount of information that it includes. Rather its LOD depends on the amount of detail and information that “project team members may rely on” when examining that element. If you deliver a Revit model containing 100% manufacturer-specific elements, but you clearly state in your handover that the model elements are all LOD 200, then they are all LOD 200 – they are to be relied upon for generic representations only and not for specification.
Trying to forbid higher LOD content also puts the responsibility for compliance on the wrong people. Architects, engineers and modelers shouldn’t be burdened with ensuring no piece of content qualifies for a higher LOD. Aside from a plain template or brand new project, any Revit model will end up having manufacturer-specific content. It just might not be visible right away.
Rather than pursuing the lost cause of prohibiting higher-LOD content, you will save time, improve the saleability of your work, reduce mistakes, and increase the likelihood that your design choices and preferred products will be incorporated in the final result.
So from the standpoint of a firm’s liability for delivering models at a certain LOD, it’s not necessary to prohibit more detailed information from entering the model. What’s necessary is to have a good disclaimer or documentation that makes it clear what LOD the model elements should be treated as. Meanwhile, rather than pursuing the lost cause of prohibiting higher-LOD content, you will end up saving time, improving the saleability of your work, reducing mistakes (e.g. no more tiny generic box for a fan that can’t possibly be manufactured), and increasing the likelihood that your design choices and preferred products will be incorporated in the final result.
2. Creating families to meet a specific LOD.
The other common misconception that people make when trying to apply LOD to Revit content is to insist that families be created to one particular LOD. This misguided approach usually follows from the first one described above – if a firm generally delivers at LOD 200, then what better way to ensure no “higher LOD” families make it in than to create all families at LOD 200!
As we noted above, this approach is rooted in the misconception that a family’s LOD is determined by the amount of detail it contains. Instead, we clarified that it’s determined by the amount of information that project team members should rely on from that family.
LOD 300, for example, requires that a model element have a specific quantity, location and orientation.
It’s also worth pointing out that LOD involves aspects that simply are not inherent to Revit families themselves, but rather are driven by the model context in which families are used. This includes things like quantities, location and orientation. LOD 300, for example, requires that a model element have a specific quantity, location and orientation. But whether those attributes are specific or not depends entirely on how the family has been placed in a project. The family itself, outside of the project context, will never have any quantity, location or orientation. So strictly speaking, it’s not even possible to create a Revit family to LOD 300.
In addition, trying to create Revit families to a particular LOD means overlooking two of Revit’s key features for families, namely Levels of Detail and Visibility Graphics. These are features that let you control exactly which family geometry displays in different views within Revit. It means you can have a family that displays a symbol (LOD 100) in coarse plan view, a generic-looking unit in 3D medium view (LOD 200), and manufacturer-specific geometry in 3D fine (LOD 300).
Andekan-made Toshiba Revit family in Fine, Medium and Coarse 3D views
You can also use family types and parameters to display or hide different geometry and metadata for different instances of a family within a project. So you could have a piece of mechanical equipment with an instance parameter for “Hanging Rods” that can be toggled on when you want to show that detail of how the unit needs to be installed (LOD 400). Or you could have a family with a generic type that doesn’t include any manufacturer information in it, and then specific types that include manufacturer name, model number, etc. (not that we would recommend that particular approach).
In short, Revit is designed so that your families can display with different degrees of detail as project needs dictate. Trying to model your families to just one LOD would mean throwing away that flexibility and losing out on one of Revit’s most powerful and useful features. If we accept the conclusions above that LOD depends not just on what information the element contains, but also on what LOD you claim the element meets and on how the element has been incorporated into the model, then why not create your families to allow for the maximum possible range of LOD?
Andekan-made Chargepoint Revit family in Fine, Medium and Coarse 2D views
Conclusion: Make Revit content as useful as possible.
Our simple advice to firms building new Revit families is to make your content as useful as possible based on what you know and the resources you have available. You have three levels of detail available in Revit, so make use of them by showing a volumetric mass in coarse, a generic representation in medium, and a more specific representation in fine. Even if you never specify products in your deliverables, you still ought to base your families on comparable manufacturer products so that they look and behave as realistically as possible within a project. If you know that the object should show a symbol in plan views, go ahead and add one as a nested annotation and display it in plan view only. If you have a preferred manufacturer for a certain product, go ahead and list it in the family’s Identity Data parameters. If you’re aware of a certain installation detail that ought to be taken into account for coordination, make sure it’s included and can easily be displayed when needed.
Sure this approach takes more planning and effort than just building a library of generic blocks to meet LOD 200, but the payoff in project quality and usability will be more than worth it for your team and project partners. You also save yourself the headache of scrambling for substitutes and new versions when you run into a situation that requires a different LOD output. Your library will stand the test of time, and the next time someone asks that dreaded question of which LOD your families meet, you’ll have the perfect answer: whichever one you need.
