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.
No comments:
Post a Comment