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.

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.