Skip to content
August 2, 2011 / Brendan McFarlane

IFC is rubbish, it never works properly

How many times have you heard someone say this, or read it on the web? Plenty of times I’m sure, you don’t have to look very hard to find people with very negative views on the buildingSMART IFC model data format. But if you analyse why they consider the data format to be flawed, you will find that their views are not based on a scientific, in-depth review of the definitions and scope of IFC, but of their perceptions from the implementation of the format in the supporting software.

This is exactly the same as being critical of HTML as a data format because your favourite Internet Browser doesn’t correctly display a website, and yet while most rational people would blame their browser, or the website when this happens, if an IFC model does not render correctly in a BIM tool, these same, supposedly rational people, immediately jump on the data format as being the culprit.

Consider this classic piece of mumbo-jumbo from the article linked above:

Why IFC is bad

The problem with IFC is it takes a lowest common dominator approach to BIM. So even though Revit has IFC certified importers and exporters there is invariably a loss of data fidelity. An example of this is the new ‘improved IFC’ plugins Graphisoft have written for ArchiCAD 14 to Revit Structure and MEP . Frankly, this shouldn’t be required if IFC was the solution for interoperability.

If I allow myself the luxury of picking apart this absurd argument for a moment, first of all, Revit’s IFC certification was granted in 2007 for Revit Building 8, and has not been reapplied for since then, despite several version releases. Revit Structure and MEP are not certified for IFC import/export. The ongoing IFC2x3 coordination view certification V2.0 process includes Revit Architecture for exchange (import/export) of architecture only, so no support for MEP and Structure is planned for Revit in the near future.

HTML rendering gone wrong

HTML rendering gone wrong

The reason Graphisoft (and Tekla) have had to invest their own precious development resources in improving the import and export of IFC from Revit by creating plugins, is pretty obvious to anyone with even a modicum of intelligence, and it is not because the IFC format is poorly defined for structure and MEP. It is because Autodesk simply have not been able to develop the IFC exchange for these services to the very modest standards that were required for IFC2x3 certification. Loss of data fidelity is a product of miserable implementation, not a deficient format.

And the solution proposed by the writer of the piece was even more ludicrous, all the world’s BIM tool vendors have access to the Revit API, and should therefore write their own plugins to allow them to work with the Jesus System™. This comment does not even deserve the acknowledgement of a riposte, as it is beneath contempt. You have to admire Autodesk, it has managed to create an army of fanboys (see the excellent definitions in the Urban Dictionary) who evangelise their products with an unquestioning religious zeal that is truly mind blowing.

But enough of the Autodesk bashing, back to the subject in question, IFC, rubbish or not? First of all some facts:

  • IFC is an ISO (16759) standard, based on the same architecture for product data exchange that supports the defence, shipbuilding and aerospace industries; STEP (Standard for the Exchange of Product model data).
  • IFC is now mandatory for information delivery on government projects in many countries.
  • The scope of IFC2x3 always allowed for the definition of objects not explicitly defined in the schema by using property sets.
  • IFC2x4, which is due to receive its official ISO approval (ISO 16739) later this year is a major refresh of the format, with support for structural analysis, GIS, QTO, NURBS and many other detail improvements and additions.

One of my personal gripes has always been the IFC certification process. Back when I was involved in the ifcMBomb project, it was clear that the quality of the certified applications implementation was at best mixed, and at worst, appalling. There seems to have been too much leeway given to vendors in approving their applications, seemingly just to get them on board. This light touch approach to certification was a mistake as it allowed applications out in the wild which had no right to carry the IFC certified badge, and has done the reputation of the data format no end of harm.

Thankfully, the good doctors at buildingSMART have seen the error of their ways and have instigated a much more rigorous testing process which should mean that tools which receive V2.0 approval will be fit for purpose. This should prove to be a huge boost to the confidence in IFC, as vendors will no longer be able to have half-baked implementations certified.

With the certification process fixed, and IFC2x4 launched, I have a feeling that the arguments against IFC will begin to evaporate pretty quickly, and as more and more clients mandate its use, the case for an openBIM approach will be very strong, as there will be no excuses any more for using second rate tools, just because the data format was rubbish.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: