Monday, September 27, 2010

Organizing BIM Content by how it is used

Implementing the Component: Primary, Secondary, and Tertiary

Components which are added to an architectural model can be categorized as primary, secondary, and tertiary. Exactly which category a specific component fits into depends largely on the individual or discipline. In addition to the architectural components, a series of structural, mechanical and specialty components are used to further detail the model for design and analysis through specialty consultants and contractors. For architectural purposes, it is not always necessary to add each structural element, mechanical equipment, or specialty components unrelated to the design intent. In many cases taking into consideration only basic dimensions and locations is acceptable to allow other contractors and consultants to design based on the spaces allotted. While this is a disjointed approach and in no way collaborative, it is not an uncommon practice, and as such should be taken into consideration when thinking about how to organize the various types of components used in modeling.

Primary components are made up of the core elements used to enclose and access spaces; floors, walls, ceilings, roofs, and openings. These elements of the project are the first to be added, often during schematic design. They divide spaces, create layouts, and enclose the overall building. Walls are added into a project and used to enclose and divide spaces. It is important to maintain a consistent reference point within the wall so that they align properly. Because walls have several materials within them, from structural, to surfaces, to finishes, and determining the reference point is often specific to the needs or type of project at hand. When creating exterior walls, using the exterior edge of the structural member as the reference plane may prove to be the most effective, where when creating interior walls, the center line of the wall may be most effective. Using a consistent strategy for aligning walls minimizes the risk of errors through design development. In many cases the number of layers and thickness of materials within the wall is unknown until well after the original walls have been placed. A great deal of time is spent manipulating these elements such that they may become permanent as design development progresses. Once the design begins to consider secondary components, it is common for errors to occur should the primary components need to be moved or changed. Developing a strategy for creating, maintaining, and organizing wall assemblies will allow walls to be swapped out at any time without the risk of moving walls due to differing reference points.

As Bim technology improves, the number of components which may be defined as secondary is increasing. Before they were made readily available, components like toilet partitions and fixed furnishings were not always graphically modeled. This is largely due to the amount of effort required to create a graphic representation of a component. As more manufacturers make their components available, the number of designers wanting to place them in their model increases.

Secondary components are essential to the design, but made remain largely unknown or undecided until later in design development. They rely on the dimensions and locations of the primary components for decision-making and product selection, and are generally non-structural in nature. The most common secondary components on projects are stairs and railings, fixtures and fittings, casework and cabinetry, specialty partitions, and certain types of fixed furnishings and storage. These types of components are essential to the understanding of spatial relationships, and the conceptualization of many aspects of the project. It gives the owner an understanding of what the space is used for. The walls may define the boundary of a kitchen, but the cabinets determine what it is.

If we think about different components in relationship to the overall size of the project, we can make the determination of how graphically accurate they need to be. Secondary components are those that are integral to the design, but not integral to the structure. In most cases these types of components are selected based on their appearance as much as they are based on their performance. When component is selected partially or entirely based on its aesthetic, how it is represented within the model becomes more important. The frequency at which these components are placed in the model is also a consideration when determining the graphic accuracy. If a component is placed in the project only once but is selected solely based on its aesthetic, it is reasonable to put more effort into its graphic accuracy, as maintaining its performance and file size is not as relevant as a component such as a door which may be placed hundreds of times throughout a single project.

Component size and location also come into play when considering the graphic accuracy of an object. A good rule of thumb is if you can't see it from 10 to 15 feet away in its installed position, don't spend a lot of time on it. This is a typical distance which is used for up-close rendering. Since the primary reason for making close representations of products is to improve the rendering aspect of the model, if it's not being rendered, it might as well be a cube. There are many components in a project that are actually very small. Whether it is a light switch, a drawer pull, or a window crank, deciding how accurate these components must be is important undertaking. While every manufacturer wants to think that their components are the most important, we have to look at the model in terms of scale. Ask yourself how important a window crank is to a 1,000,000 ft.² building, and what purpose it serves if it is not visible in rendered views. The answer lies in its ability to be quantified and qualified. If a component needs to be quantified or qualified, it can add value to the model. Let's go back to window hardware as an example and look at three possible scenarios: 1.) If a manufacturer offers several hardware options, and it will likely be visible in many rendered views, it should be added to the model graphically and have the ability to select options. 2.) If a manufacturer offers several options for the type of hardware used but it will not be seen in a rendered view, it is more effective to list the hardware as an attribute of the window without graphically modeling it. 3.) If only one type of hardware is available from the manufacturer, is perfectly acceptable to omit from both the graphics and the information contained in the project. If there are no choices which may be made, and the component is not commonly used for selection or specification purposes, then adding it to the model offers little value to the architect, specifier, or contractor.

Bob's BIM Tip: If you can't see a component from 10 to 15 feet away in its installed position, don't spend a lot of time on it.

Tertiary components are those which are added during detailing, or not at all. While it is my belief that every component that is used on a project should be brought into the model in some way, shape, or form, that does not necessarily mean it should be done graphically. There are ways to embed information regarding components without actually placing them in the project, and there are ways to simplify how a tertiary component is placed in a model as well. Hopefully this will minimize the number of tertiary components within a project, and increase the number of secondary components. Over time this could translate into more accurate models, and a greater demand for as-built models as a final deliverable to the owner.

A component like door hardware is an essential element within a project, is found in hundreds of locations, and even has its own special schedule, yet it is arguably a tertiary component which is often overlooked or omitted. Most architects choose not to deal with door hardware for the amount of effort necessary versus the benefit received from placing it in the model. Components like this are often better represented in context. Door hardware is a function of a door, and as such should be placed and controlled from within that door. Rather than attempting to place door hardware components at each location within the project, making door hardware a function of the door itself can allow it to be a graphic aspect of the model, and carry the important information to its respective schedules.

Accessories, movable furnishings, and equipment are tertiary components. Because they may be relocated at any time, and are more commonly used for conceptualization and space planning, these types of components are typically not modeled. As a general rule, when the placement of a component is not integral to the structure or the design of a project, the component can be considered "tertiary". Another way to look at it is if there is no specification section for the component within the project, it is probably a tertiary component.

Saturday, September 11, 2010

High Performance Annotations

The method I use to annotate with BIM is to add a material AND its Specification Section Number to the annotation for vendor neutral materials that are not specifically called out. (06 11 00_2x4 Dimensional Lumber – Species as Noted in the Contract Documents) or (07 54 00_TPO Membrane – Thickness as Noted in the Contract Documents). I use the term "Contract Documents" here as there are changes happening in the industry, and while the contract document now would be the Project Manual, in the future, it may not be. One may reference a tabular specification, or formatted data sheet of some kind. The descriptions are very fluid and allow for modification based on the amount of information known…

A knowledge manager may handle the annotations for the Roof Membrane Layer in a section view of a roof like this:

  • PP - (07 00 00_Roof as Noted in the Contract Documents)
  • SD - (07 50 00_Roof Membrane – As Noted in the Contract Documents)
  • DD - (07 54 00_Roof Membrane - Thermoplastic – As Noted in the Contract Documents)
  • CD - (07 54 23_Roof Membrane –.060 TPO – Tan)
  • Post Bid - (GAF EverGuard .060 TPO Membrane – Tan)

The idea is to give an appropriate description based on the amount of information known at a given time, and reference the Contract documents for the next pieces of information which may be necessary. This allows the annotation to always be correct, regardless of how much effort is put into the annotations, or if they never get updated past Schematic. I use phases as an example above, but I see phases as we know them disappearing to some degree with the growth of BIM. Because effort is recyclable in BIM, we can actually have detail views in Schematic Design that have merit. Standardized views can be moved from place to place within a template project, and only the annotations need be moved in order to create "Progress Drawings" at various phases of the project.

All in all, It's my belief that the concept of keynoting really only pertains to the drawings, which are ultimately viewed by the Contractor. With my background in General Contracting, I truly think that requiring them to reference information in a specification in order to get the BASIC information that they need to do their job to me is just plain LAZY! Drawings should follow the same CSI principles as Specifications (Clear, Concise, Complete, Correct) and the fifth C; Consistent. Keynoting makes incomplete drawings, as there is no single unified keynote structure, and there is no practical way to take into consideration EVERY possible component within a given specification section. It took over 1200 different BIM materials for a metal framing manufacturer to represent their Metal Stud offerings which consider dimension, yield strength, web depth and spacing.

Drawings are created before specifications, and BIM is the root of both. As information goes into the Model, it becomes a function of the drawing FIRST, and the attributed information becomes a tabular specification which can be used to develop a text based document. It is actually very simple (and very beneficial) to add the attributed information into the individual materials and components, as BIM provides not only the ability to TOGGLE between keynote, and annotation globally, but to actually concatenate attributes to create an accurate Callout.

The syntax for annotating a material goes something like this:

  • Keynote Only: [MF Number]
  • Keynote Only: [07 54 23]


  • PP: [MF Number]_[Component] [Type]
  • PP: [07 00 00]_[Roof] [as Noted in the Contract Documents]
  • PP: [07 00 00_Roof as Noted in the Contract Documents]


  • SD: [MF Number]_[Component] [Type] – [Material]
  • SD: [07 50 00]_[Roof] [Membrane] – [As Noted in the Contract Documents]
  • SD: [07 50 00_Roof Membrane – As Noted in the Contract Documents]

  • DD: [MF Number]_ [Component] [Type] – [Material]
  • DD: [07 54 00]_[Roof] [Membrane] – [Thermoplastic]
  • DD: [07 54 00_Roof Membrane - Thermoplastic – As Noted in the Contract Documents]

  • CD: [MF Number]_ [Component] [Type] – [Thickness] [Material] – [Color]
  • CD: [07 54 23]_[Roof] [Membrane] – [.060] [TPO] – [Tan]
  • CD: [07 54 23_Roof Membrane –.060 TPO – Tan]

  • Post Bid: [Manufacturer]_ [Trade Name] – [Thickness] [Material][Type] – [Color]
  • Post Bid: [GAF] [EverGuard] [.060] [TPO] [Membrane] – [Tan]
  • Post Bid: [GAF EverGuard .060 TPO Membrane – Tan]

Because of this structure, I use ONLY the 6 digits of MasterFormat, with no following enumeration that corresponds to a construction or specific material. A keynote is great if a machine needs to read it, but we are not machines. We are humans who want to see the information that we need, not have to follow a path in order to reference a different document. The BIM database already does this for us, and by mapping the information in such a way that it is no additional effort to create the more detailed information, there is no reason NOT to use full text callouts. We are all collaborating on a project, and should consider the needs of the individuals who are actually using our deliverables.

I do understand that you can only put so much information on an E sized plot, however, with the on screen digital world right in front of us, changing scale, and creating additional sheets which apply to specific trades at a more detailed scale is a simple Duplicate w/ Detailing Command.

All of this information is searchable within the model, and allows for analysis, so by adding a few attributes to each material, an annotation is automatically created, and can be globally updated based on the status of the project, or who needs the information. Whether or not keynoting is relevant and useful is no longer an issue in my estimation; That ship has sailed already. I think the idea is how detailed the annotations need to be in order to suit the needs of EVERY member of the project. If BIM can automate the annotation and keynoting process by leveraging attributes from within the material, assembly or component, the bigger issue is the accepted taxonomy and structure for the information which needs to be managed.

Wednesday, June 2, 2010

No More Shared Parameter Confusion - Omniclass Table 49

There is a format in existence called Omniclass, that has been around for years without a practical purpose. It is a series of tables which organize information the same way MasterFormat™ does. In fact, MasterFormat™ is based on one of the tables in the series. For those using Revit 201 or newer, you may have seen references to Omniclass Table 23 embedded in the families. This is the table that organizes products into logical categories. I'm not going to go into great depth in this post on the value of Omniclass to the success of BIM, but I will say that it is THE most effective way to organize and homogenize all of the data that you are accumulating.

During its redevelopment and update (Which is still ongoing), a few active CSI volunteers and I, were responsible for updating Omniclass Table 49 "Properties". This table is a series of attribute names that are slated to become the standard naming convention or taxonomy for attributed data within Building Information Models. Upon finishing the update to the table, it occurred to me that the best way to implement this into practice was to create a Revit Shared Parameter File. I just finished the effort moments ago with tremendous success, as my custom Shared parameter file works like a charm.

A beautiful aspect of this file is that I customized the GUIDs (Globally Unique Identifiers) so that they align perfectly with the exact location of a parameter. Just as you drill in from Division to section to Part to Article using the CSI formats, This allows me to actually create similar Shared parameter files based on specific needs (one for SPie, one for Windows, one for Doors, one for Wall, one for HVAC, etc), so you can pick and choose which SP file you use without sacrificing data organization. One irritating point about shared parameters is that even if you name the parameters identically, they don't schedule together unless they are form the same shared parameter file. This is based on the GUIDs being different. if I enumerate them and keep the data organized. it should all work out nicely.

If you're interested in, or know someone who is interested in taking this Industry standardized 923 parameter Revit SP file for a test drive, reach out to me and I'll send you a Beta version.

Tuesday, June 1, 2010

BIM Content and File Size - 6 Points to Making a Faster Family

When Dealing with BIM Content, size is an essential element of its success or failure. While most look only at the overall size of the file, there is another type of size in this respect; computational size, or how quickly the software can load, process, and refresh the file. I have developed components that are 250KB that are slow as molasses on the load, and others that are 1.5MB and lightning fast on the refresh. Always consider BOTH aspects when determining which components you put in your project. Unfortunately, there is no way to quickly quantify and qualify what the computational size of a models is, there are a few ways to determine whether or not a piece of content will be fast or slow.

  • Family Types vs. Type Catalogs - Each family type in a component requires Revit to churn through the regeneration process every time its loaded, changed, accessed or reloaded. I try to limit the number of family types that are pre-loaded into a model to five. Any more than that, the model bogs down trying to refresh. Type catalogs are the most appropriate solution as they make the models fast on the load/reload, give the user the ability to sort and filter through choices based on data in the model, and also allow ONLY the types that are needed to be placed in the model. This is a tremendous help when trying to stay organized within your model.
  • Calculations - While helpful, they can slow down the speed of the model by forcing Revit to constantly recalculate when the value is more efficiently placed in a family type or type catalog. Calculations have their place though. Instance parameters are perfect for calculations. I wrote a calculation that returns if and in which zones a window will meet ENERGYSTAR based on the U Factor and Solar Heat Gain Coefficient that is inserted by the user. Since those values are determined based on which glass is used, it is better suited to allow the user to insert the values, else the type catalog can become unbearably large.
  • Void Geometry - I'm not going to say not to use void geometry, but I will say to use it sparingly. for whatever reason, it seems that voids slow down BIM content. Avoid creating hollow solids where the inside of a component is not visible (Water is not really going flow though that pipe), and join multiple solids where possible.
  • Really Small Polygons - This applies to both solid and void geometry; don't bother with the 1/16" just and jogs in the profile of a window frame. While this type of detail is great on Engineering drawings, nobody is going to export the family file for machining.

    Rule of Thumb: If you can't see it from 10 feet away in its installed position, think carefully about its relevance.

  • Arrays - Again, use them, but use them sparingly. Arrays are a computational HOG. In many cases there is no way around them, but use simpler geometry, and array nested families instead of solids where practical.
  • Nesting a Nested Nest - I am a true believer in the use of nested families, especially shared nested families. The streamline everything and allow you to create some powerful tools, but that is another blog entry. It's important not to nest items too deeply though. If you nest twice, three times or more, each step requires computation. If you nest everything into the host and align reference planes accordingly, you'll end up with a faster model with less fat, not to mention less chance of errors in forgetting to link parameters together.

Generally speaking, I like to keep content to roughly 600KB with a load/refresh of less than 5-10 seconds, unless its a very detailed component that's only being used once (Like a entire ice hockey rink in one family). There is more to content size than the number of Kilobytes it takes up. How quickly it computes is just as important as how big it is in terms of the file size. Many of these points speak to both file size and computational speed, so go forth and find that delicate balance between size and speed. It's a fine line, but it's important that we walk it.

Monday, October 12, 2009

BIM and Roof Systems

In developing a BIM roof system, it is important to understand that the actual materials are what determine the performance and construction of the overall roof. The type of roof covering used is considered based on not just aesthetics, but roof slope and local weather conditions. The secondary roofing materials are determined based on their individual merits as well; substrates are based on the building’s overall design, structural properties and locale; a vapor barrier is selected when or if certain moisture vapor properties merit its need; insulations carry specific R-Values important to the energy performance and code compliance of a building; the roof system attachment method is typically based on requirements of local codes. It is not necessary to understand how and why to use the specific materials when developing a BIM roof object. Realize though that the roof system is not just a slab that stops water from coming in. The appearance of the materials used in the roof system will determine how the details turn out. Use an appropriate surface pattern to convey the basic appearance of the upper most layer of the roof. Layers embedded inside of the roof will never be visible, and have little or no value to the model’s success. Cut patterns assign a symbolic appearance to various types of materials. The Uniform Drawing Standard (UDS) and National CAD Standard (NCS) have uniform symbolic patterns assigned to various materials. Using industry accepted patterns allows existing technology to be implemented into BIM technology without the need for reinventing a perfectly useable process. Each material has the ability to carry its own set of performance values which can be leveraged for model analysis and quantity estimation. A model calculates the length, area, and volume of a roof or roof material, but does not consider the unit by which the material is sold (Roll, Pail, Gallon, Cartridge, etc.) Where unit coverage rates are specified for given materials, an accurate estimate of the number of necessary units can be derived from the model, considerably decreasing the amount of time required to estimate a project. Later in this chapter, we will discuss in more depth the types of calculations that are possible from roof materials which carry a substantial amount of information. Roof System Components There are five main components that make up the basis of design for a roof system. In some cases others may be added and some omitted, but the primary components that should be considered for roof systems will allow others to be built from them and easily reused. § Substrate - The roof substrate is the structural component associated with the roof system. Functionally, it is the deck on which the thermal and waterproofing products sit. There are several types of substrates which may be used, the most common being Wood, Concrete and Steel. Unless the framing members are placed individually as described in chapter 28, roof systems should contain a material layer for the structural framing in order to consider the overall thickness for potential clash detection analysis.


*While the roof deck is arguably not a part of the roof system, it is not appropriate or effective to create one roof for the structure and deck and another roof above for the waterproofing system. It creates a conflict when placing components on the roof that are designed to cut a hole in the roof on placement.

§ Air/Vapor Barrier - Vapor barriers are very thin membranes typically placed between the substrate and the insulation. Even though the thickness is negligible, it is important to represent them in the model with a thickness appropriate enough to graphically display the material in a section view. Without giving the air/vapor barrier a thickness, providing call-outs or annotations of the material in detail section views is made more difficult.

§ Thermal Barrier - Roof insulation provides the thermal barrier between the building and the outside world. Just as a hat protects your head, since hot air rises, insulating a roof keeps the building’s heat from escaping. In some cases the insulation may be placed below the roof deck, and in other cases, it may be placed above the deck. In either case, its thickness should be easily adjustable and carry its R-Value in order to determine qualify the appropriate thermal protection used in a project. In addition to thermal properties, roof insulation may also provide slope, so the ability to taper the insulation independent from the roof structure is important.

§ Waterproofing Material - Shingles, membranes, metal and sprayed elastomeric coatings are all types of waterproofing. In most cases, this is the uppermost layer of the roof, and should carry some type of surface pattern to differentiate it from other roof types within the model view. Often, the roof covering is selected based on its appearance, and since there are so many options for roof coverings, it is important to have a good sample image swatch available for rendering the roof’s final appearance.

§ Roof System Attachment - Regardless of the type of roof, it needs to be attached in one fashion or another. Because it can affect how the roof performs or whether it meets the local building code’s requirements, it is important to add it as a layer in the roof system. Having it in the roof system as a layer allows the attachment method to be quickly called-out or switched if necessary.