Building RFAs: file size impacts & performance

[rstilleson]

We are trying to determine ways of building all of our generic architectural [Revit Family] RFAs. Here are a few technical questions that I have:


If we create 3D objects, and then turn their visibility setting off in a 3D View (through Visability Graphics) will that decrease the resources it takes to render that veiw? what other impacts might this have on a model?

What are the impacts (on graphical processing memory) of model lines and solid forms versus symbolic lines?

For instance, there is an ongoing debate in our office about constructing RFA files as 3D solid form extrusions or 2D symbolic resmblances of a 3D object. I think the biggest concern is taxing the graphics processing in a project, loading time and potential crashing of a project file.


Essentially, what are the major components that slow down the functionality and performance of a model? how do they slow down the performance? what can be done to work around/with the limiting/enabling functions of this?

Do large RFA file sizes slow down loading of the project? loading of views? processing the graphics in a view? and making changes to objects and updating the model?

[RobertB]

I would suggest that the models need to have the level of detail needed for the typical sheets on which they appear. For example, in a recent project, the architect dropped in a manufacturer's toilet model that was far too detailed, even showing chamfers on the union nuts. Which led to file corruption issues when exporting the model.

Also, consider if the object in question needs to provide a model for clash detection or rendering. If not, might be able to simplify the overall model by not providing unneeded family models.

The impact on file size for over-large Revit Families (RFA) is not as large as the impact on general performance. Too much detail will kill performance, whereas each placement of the object is only one record in the database.

[pjohnson.137155]

I would keep families as simple as possible and define the families as required. If you are going to render a family you may need a bit more detail.

Question you need to ask - do you want to spend more time designing the building or managing the file becasue of performance?

Patrick K Johnson
http://www.cadenhancement.com

[ruthellenwilliams]

Family sizes definitely affect project model performance!

Avoid using VOIDS in families. For instance, a panel door I found in a model was created from solids and voids in order to get 3D detail for the panels. Voids weren't needed in any case, and 3D panels were not needed for anything that was going to be printed. The file size decreased significantly when that one door family was replaced with one created from a single solid extrusion for the door and model lines to represent the panel configuration. Also, using model lines for the door panels allows them to show up in 3D views so everybody's happy!

Toilet families can be a huge problem. Might need one 3D if you're doing an interior rendering, but most can be a family created with only plan and elevation views.

Check out any family that you download to be sure that it is created efficiently and will flex properly.

[rstilleson]

Thanks for the input. Clash detection and rendering are some of the multitude of things that I will try to remember when creating Revit content.

One thing that we started to do was make families in 3D massing components and in 2D symbolic detail items. If the type parameters are defined to reference planes/lines, than it was rather quick to delete all of the massing and make a second RFA file in 2D. I guess it really comes down to how the user is going to use the families, what information needs to be included and to what detail level.

As for how Revit actually computes and graphically displays model components, my questions are still to be answered. Questionable as to the worth of pondering the subject.

[garethace]

I would suggest that the models need to have the level of detail needed for the typical sheets on which they appear. For example, in a recent project, the architect dropped in a manufacturer's toilet model that was far too detailed, even showing chamfers on the union nuts. Which led to file corruption issues when exporting the model.

Robert,

In this blog entry here,

http://designcomment.blogspot.com/20...anuscript.html

I discussed in brief detail my experience in a multi-disciplinary construction company, where we used AutoCAD XREFs and LAYERs to implement a quite sophisticated clash detection 'mechanism' or 'workflow' process, to allow structural engineers and architects to work on the same projects, on the same server. When you employ both engineers and architects in the same company, you do gain certain priveleges.

The construction company I referred to, Royceton/Danninger, was a construction and engineering company first and foremost. They decided it was best to bring in architecture as a discipline inside the design office, because of experiences they had, where the architect was a consultant external to the company. If you bring you architects inside the company, to work side-by-side with engineers, you are instruct your architects to provide CAD information to the engineers, which is drawn so as to be 'use-able' by those engineers. Not the toilet block symbols you refer to with the chamfers on the union bolts.

Of course, our architectural department in the construction company where I worked, never got up enough steam to really mature into a fully functioning architectural department. Most of my friends were horrified by the fact I would go to work for an engineering and construction company. It was like going to the 'dark side'. So the engineers still received CAD information from the regular architectural consultants they had always worked with in the past. The information coming in, was fairly predictable in its quality. Symbols which contained too much detail. Nested symbols, nested Xrefs, strange layers that were frozen within blocks and within XREFs.

Basically, if you looked at the architectural CAD file, you could picture in your mind the poor old drafts person who created it, having an angry, bossy principle architect standing over their shoulder saying - I'm paying you by the hour, why aren't those CAD drawings sent out to the engineers yet? By bringing the architects inside of our construction company, it was the goal that we would facilitate a more civilised and fruitful relationship between the two disciplines. In time, if things had gone well - and the engineers had decided to make a leap into 3D BIM modelling - then we could have worked out a system to suit both architectural and structural. But the basic principles would have been the same. To enable an architectural department that was capable of giving the engineers information that was use-able - as opposed to giving them chamfers on union bolts instead.

[RobertB]

Robert,

In this blog entry here,

http://designcomment.blogspot.com/20...anuscript.html

I discussed in brief detail my experience in a multi-disciplinary construction company, where we used AutoCAD XREFs and LAYERs to implement a quite sophisticated clash detection 'mechanism' or 'workflow' process, to allow structural engineers and architects to work on the same projects, on the same server. When you employ both engineers and architects in the same company, you do gain certain priveleges.
...But the basic principles would have been the same. To enable an architectural department that was capable of giving the engineers information that was use-able - as opposed to giving them chamfers on union bolts instead.

There are undeniable benefits to colocation of the design team. BIM is, to a large extent, about communication. The more closely such communication can be performed, the better for the project. At the expense of the traditional architect to consultant business model. However, even when communications occurs, it must be acted on to be effective. For example, the architect was informed of the issue yet the model was never corrected.

[garethace]

To repeat what Robert said above,

I would suggest that the models need to have the level of detail needed for the typical sheets on which they appear.

There is so much wisdom in that statement, it may even be a life time's worth. So much more collaboration, communication, and lateral thinking in our design process would be possible, if people were able to think clearly as suggested by Robert's sentence above.

One of my pet hates to give one example, in the 2D CAD output from most architectural firms - they have been using the same window frame CAD block for years. One which was received from the window manufacturer and contains all of the little neoprene seals and recesses used by the window manufacturer to solve the weatherproofing problem. The architecture firm drops in this little window frame symbol from the manufacturer CDROM and choose to repeat it several hundred times across a set of CAD drawings. Without any heed to file size increase and performance loss due to unnecessary information. The window frame block might have 10 layers! The same 10 layers that were originally created by the German window manufacturer, that no one bothered to clean up.

There has to be a critical appraisal at some stage in the game, of where to include the detailed information and where to leave it out. It confounds me, that so few architectural CAD drawings ever try to apply that logic. When engineers want to reference in a couple of architectural floors plans, they have to sit and watch their screens redraw, and get 'egg timers'. Even though the engineer only needs the architects floor slab outline. The architect includes that awful window frame block in all their drawings, and it bogs everything down.

Then you try to switch off the layer with the window symbol, and instead of the window frames going - half the architectural floor plan disappears too, because of poor layer management. This is everyday standard output from many architects. Or at least that is what occured in Ireland during the boom years in construction. Eventually the engineer decides, why bother? The process of collaboration and sharing of information deteriorates to where each party only does the bare minimum to get by.

When both engineer and architect are working on the same side, in the same company, you can have a fairly blunt conversation about workflow. Because both parties have their interests aligned. The time saved not having 'egg timers' can be re-invested into improvement of information delivered to the construction site and general standards of the finished product. You can aim higher in all sorts of ways, because you are no longer fire fighting. The problems I referred to above can all be found in the 2D CAD environment. What makes us so sure that attitudes will be different in a 3D BIM modelling environment? When every CAD user has 16GB of DDR memory? I fear the increased 64-bit memory space will get filled up with more and more window blocks with neoprene seals.

Sorry to sound so glum about things, but there is a battle being lost on the 2D drafting front. I cannot imagine was booby traps lie in wait, as far as 3D BIM design goes. The problems are less technological and more to do with humans and cooperation.

[RobertB]

Sorry to sound so glum about things, but there is a battle being lost on the 2D drafting front. I cannot imagine was booby traps lie in wait, as far as 3D BIM design goes.

Here's one you are going to love!

[garethace]

Here's one you are going to love!

Sounds very like a nice brick wall I hit into almost a decade ago, in an architectural practice I was working for. I wrote about it here;

http://forums.augi.com/showthread.php?t=119508

I stuck my neck out and decided to introduce 3DS Viz into the workflow in the office, which had been Bentley MicroStation based for years. The reason I finally took the plunge was because MicroStation Java 7.1 release included a brand new solid modelling kernal, which they had licensed from Parasolids. Prior to that, MicroStation solids were only kinds of surfaces capped at both ends, and they would literally fall apart when you tried to export to any other software. I hoped to offer Navisworks type of functionality to some of our residential clients, by bringing models into 3DS VIZ. I used to export 3DS Viz models as panorama files, so that the clients could travel around inside their building months before it was constructed. It turned out to be a really powerful way to design for a client - as the client could give you a lot more feedback on their aspirations for the design - much, more than if they were trying to interpret 2D drawings. We forget that as professional CAD users, that most people go through their lives without ever looking at blueprints.

In the past I had always blamed MicroStation for the road blocks in our 3D workflow. But when I started to bring models in VIZ and use millimeters as units, the viewport viewing went all horrible on me. It is all described in the linked thread above. With clipping planes occuring which I had no control over and so on. I wouldn't mind, but I spent a bit part of the budget on Quadro cards, memory and licenses only to realise it wasn't going to work out as I had hoped. I had a good fun and games with the units settings in 3DS Viz (that was about a decade ago), until I decided to shelve my plan. The worst was, half of the office was hoping I would encounter some difficulty - I was a quite confident kind of guy as far as computer aided design went. But the tools let me down badly. The tools would have been great, had I lived in the United States and worked with Imperial scales. Such is life. I am glad that things work better nowadays and the kids here in the Metric part of the world have a range of nice software/hardware options they can choose. But things weren't so easy a decade ago, and you had to stick your neck out a lot to get funding for your ventures.

I remember someone explained to me some years later, the hybrid rules that exist for rating of automobile tyres. For some reason, the ratings for car tyres contain both Imperial and Metric! How odd is that? It's a very interesting problem this Imperial-Metric issue. I am always watchful of it now, having had the experience of 3DS Viz release 2.