Hey all - I just got back from Greenbuild Expo in Chicago, and over the 2.5 days there, I spoke to probably 15-20 manufacturers who came by the Autodesk booth - all to ask about BIM content creation. So that's great - way up from a half dozen per expo in years past. I was able let all the folks I spoke with, know about Autodesk's Seek team's cool new Content Services page where any building product manufacturer (BPM) can either get consulting on creating content themselves, or choose to have it made for them by one of a number of certified Autodesk Seek Content Service Providers (CSPs). Either way, you (manufacturer) can be sure you'll start off on the right foot.
One of the conversations I had in particular however, reminded me about the old family file size issue. So I thought I would give it some clarification here. A lot of users will look at a manufacturer's family file's size as the only crucible, and reject it out of hand if it seems too large for their liking. Yet, in so doing, they may just actually be passing up some excellent content and shooting themselves in the foot. The misconception among users is that size is all that matters, when often excellent content may be larger do to its information (the "I" in BIM) while still being geometrically simple. Why does this matter?
Well, I'm glad you asked!! I placed a 229K family file (rfa) in an empty, purged project, and that project file (rvt) increased in size from 4001K to 4145K which means a net gain of 144K in the rvt file. So adding a 229K file yielded only a 144K increase in the rvt file (i.e. not the direct 1:1 ration increase you'd expect). Then I copied the content around in the project/rvt file ten times. That increased the rvt file from 4145K to... 4145K!! Yes - a net increase of 0K - ZERO net increase!! Why? Because Revit is one big database, and just like in Excel when you enter in a value somewhere and then call it up in other places, it does not copy it around, rather it just reprojects that value from the database wherever you ask. Same for Revit. Wherever I visually copy it to is just another image of the real entity with a link to its rfa data back in the database. So the only impact I'm having on the rvt file is visual impact - that is more geometry instances impacting regeneration performance. And this is why having simple geometry often should be of greater consideration than just a family's file size. I repeated the test with a more geometrically complex file and while that extra geometry (a needlessly modeled trap that could just as easily been represented by model lines) needlessly increased the file size, once I had it in the rvt file, it once again increased the rvt file by only a fraction of the rfa file size itself, and when I copied it around, it did not increase the file size any further. The two files are shown below. If you'd like to see the actual numbers as I experimented with the files, you can download Revit Family File Size Calcs here.
If you'd like to hear the thoughts of one manufacturer regarding geometric simplicity of Revit content (in this case, as it pertains to logos et. al.), I have pasted below an email excerpt from a friend of mine - David VanSlyke, Lead Systems Engineer at McQuay International, that he shared in an email conversation I had with him a few months ago.
As always, if you have any comments on anything in this post, please do not hesitate to share them.
---------------------------------------------------------------------------------------------------------------------------------------------------------
<reprinted with permission>
Hello William.
As a lot of Revit families found online are of lesser quality (to put it nicely), one of the things we’ve been learning is that there are Revit MEP shops who choose not to use manufacturer-provided content in order to ensure that only high quality models are used in their projects. Obviously this is very expensive for them and creates issues because products change over time, likely without their knowledge.
So while it’s not possible to please all of the people all of the time, as Revit content creators our number one goal is to create Revit families that at least most Revit MEP users are reasonably comfortable using “out of the box,” as-is. This is primarily because as soon as they feel they need to modify the families we provide, they won’t want to download updates again in the future because they’d have to modify the updated files again.
Being comfortable getting the latest updated Revit families from any manufacturer every time they’re needed in a project is extremely important because products *do* change over time. So getting the latest versions of the families is critical to ensuring the accuracy and validity of the final BIM model.
As we’ve learned, rightly or wrongly one of the first aspects of a Revit family that users look at in evaluating it for quality is the file size. In part, this is because it’s a very easy metric to observe, without even having to open the family in Revit.
By far the biggest impact to family file size we’ve observed is the use of nested families. While using nested families can make it significantly easier for a content creator to generate Revit files because of the reusability benefits that nested families offer, the cost in final family file size is significant. We’ve seen individual nested families cause the final host family file size to increase by anywhere from about 65 KB to upwards of 200 KB.
The most common mistake we see (and were guilty of ourselves in the past but have since corrected) is including a company logo in the Revit family. Traditionally, on something like a 2D certified drawing, the “CAD content” provided to customers should include a company logo. And what manufacturer doesn’t want to have their logo visible at every opportunity?
But putting users first, in a Revit world where the “CAD content” is a 3D model, including a manufacturer’s logo is a very bad thing to do:
- It makes the family file size larger, increasing Revit’s memory requirements when loaded into a project.
- Logos are often complex shapes, slowing down Revit’s rendering speed, particularly if many instances are used.
- Logos can only be seen when zoomed in on the family, which is rare in a project.
- If a logo is even visible on a drawing it’s usually just an unreadable blob.
- Logos serve NO functional purpose. Revit MEP users are after functionality more than anything.
- Being basis of design and appearing in the schedule is what really counts, and including logos doesn’t change that.
In the past, one of our customers said that when they opened the family the first time and saw our logo, the very first thing they thought was “oh no, more bad content.” The next thing they did was delete the logo. We’ve since done that for them.
This year we’ve put extra effort into simplifying our families and – in particular – reducing the usage of nested families. In many cases we have literally cut our family file sizes in half by taking these measures. For example, one thing we did was replace a nested family with a simple model line representation. In other cases, we deleted the nested family and redrew the solid directly in the host family.
After having made Revit content of our HVAC products for over 2 years now, it never ceases to amaze me how we continue to find newer and better ways to create families, and to retrofit our existing families to make them better as well. Reducing nested family usage has made our families much lighter, without sacrificing any important functionality.
While there are many other aspects of a Revit family that negatively affect Revit’s overall performance, such as:
- Way too much geometric detail
- Overuse of instance parameters
- Use of voids
- Not using type catalogs (forcing all types to be loaded into a project every time)
family file size is a major factor at the very least in a Revit user’s perception of quality.
So even if in reality it’s only a fuzzy initial indicator of quality, careful attention to keeping family file sizes as small as possible should be very important to content creators.
- David VanSlyke
McQuay International
