"Don't Judge Me by my Size - I'm Pretty on the Inside!" (Smart family file quote.)

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

Comments

[Tim]

VERY interesting indeed William, thank you for sharing! My recommendations to customers will now change accordingly :)

[Gabe Cottam]

Large file size remains a valid test of whether or not the content creator knows what they are doing. I opened an 804 KB model of a Florida Heat Pump, deleted and purged their logo and saved it out at 224 KB.

The "I" in BIM stands for information - not intelligence. And the information in MEP families (parameters) just should not add much size. And please William, when you talk to manufacturers, tell them to use type catalogs.

[David VanSlyke]

In the FHP example removing the logo MAY have dropped the file size by nearly 600 KB, but that's unlikely.

Revit has a nasty habit of doubling your family file size sometimes when you do a Save.

The best way we've found to guarantee the smallest family file size is to do a SaveAs to a totally new file name.

Odds are in your case doing a SaveAs first would have dropped the family file size to about 400 KB, then deleting the logo and doing a SaveAs again would have dropped it to the 224 KB final size.

[William]

Good catch Gabe - indeed it is "Information" and not Intelligence - not sure what I was thinking. Perhaps subconsciously I am hoping that all contents' information would be intelligently done too, like using type catalogs like you suggest. I think I'll focus the next post on type catalogs.

[Alex Gore]

That is interesting to hear that nested family cause such a size issue, I would also advocate for their elimination because of the difficult of manipulating a model with multiple nested family. Good post!

[Antony McPhee]

Visual complexity is more important than file size. We have large Revit files ~400Mb, which do take a while to load. But you only do that once a day. The biggest annoyance is regen time. And regen time is linked to how much calculating Revit has to do to work out what is hidden behind what. So some tips:
- use Visibiliy/Graphics Overide in families to hide things that won't be seen in a view direction, or will appear tiny (e.g. switches seen from left/right).
- never use model geometry in plan view. Turn if off using Visibiliy/Graphics Overide. Use Symbolic lines & masking regions instead.
- avoid curved surfaces where possible.
We are currently trialing families that have 2 sets of geometry in them, full 3D, and simplified 3D. Each is on their own sub-category (3D Rep & 3S Rep) to control visibility in views. It means we can have 3D views showing full representation for design presentation, as well views with simplified geometery for everything else.

A note on 'SaveAs' - you don't have to save as another name, just hit the Options... button bottom right of SaveAs dialog, and tick 'Compact File'.

[William Spier]

You make some good points Antony. I failed to delineate in my own mind, and to clarify when I wrote that, that larger file size does not necessarily mean you have a file that will slow Revit down. It is, as you correctly point out above, geometric complexity that wears away at Revit's speed and responsiveness.

Your idea about creating a two-in-one file with one detailed and one simplified is intriguing, and I am sure anyone following this will want to know how it turned out for you. Please do check back to let us know if results were favorable or not.

-Wm

[خقق]

مشكووور والله يعطيك العافيه

goood thenksss