Steve’s post on IFC and the comments that follow, mirror discussions I’ve had on IFC on numerous occasions. I’m going to be more blunt than Steve though ;-) . Don’t get me wrong, an open interoperability layer is vital for BIM but IFC is not the long term solution. For archiving and satisfying jurisdictions that require an open solution, IFC is arguably the only solution currently, however even then it is an incomplete solution. Good luck opening a current generation IFC model in 20 years or the structural analysis.
Before I continue, I better state some caveats:
- I don’t know what Autodesk think of IFC, although they were one of the originators of the project. I have had no discussions with the Factory on IFC support or plans.
- What I believe to be the preferred long term solution for model communication is currently not a complete solution .
- My main concern here is discussing data exchange during the design phase.
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. Yes Autodesk could improve the IFC translators in Revit to improve the ArchiCAD experience. But then in lies the problem, every vendor who has an application that implements IFC has to account for subtle differences in implementation or mapping to their object models . This increases the amount of testing and development required for each and every IFC application that is utilising your IFC files. Not to mention the broken workflow.
The way forward
What is an open standard? I believe Autodesk’s idea of open is a freely available self documenting API as we have with Revit. The fact it’s not a complete API is really the problem. Were all vendors of BIM applications to commit to full open API’s for their applications we would be able to implement lossless interfaces to our 3rd party applications. While this may increase the amount of upfront development, by the use of well designed code libraries this can be minimised. It will have the benefit of significantly reducing testing requirements as well as providing the possibility of a richer user experience more suited to the host vendors application.
Full open API’s are inherently self testing, it would not be a lot of effort to test this for the major BIM vendors. Were 3rd party vendors to commit to open API’s as well, interesting mashups would result further increasing the rate of BIM innovation. Because open API’s are self documenting it allows vendors to innovate rapidly without having to worry about maintaining IFC compliance. This would significantly reduce testing.
Using the existing Revit API as an example, we are now starting to see the benefits of this open API approach. The new solar radiation technology preview for Revit 2011 is an excellent example of a fluid user experience in this case implemented within the Revit UI using the Revit API. Equally the API could be used for direct external communication of object data.
Archiving
Steve summed it up nicely:
“If we don't print stuff at some point in the future for archiving and just rely on it being available digitally everything will have to be saved/stored in some "neutral" format...not just BIM or CAD or doc files etc.”
I don’t see IFC as any more a guarantee for archived BIM projects than a closed Autodesk file format. And regardless of which file format, would a BIM project file be a true reflection of a buildings’ as built state in 20 years time? The only real solution for all data is to serialise it into a human readable format like XML. Entirely possible with a full open API.
A Revit user and don’t agree?
If you’re a Revit user and you don’t agree then you better start searching for an alternative because Revit is living proof IFC plays no role in a fluid BIM experience. Revit Structure and Revit MEP both use direct integration and 3rd party analysis via the API to provide a workflow than would never be possible via IFC. The new solar radiation technology preview for Revit 2011 is just the start. As the API develops we’ll see further examples of direct integration via the API providing an improved BIM and IPD experience over the IFC alternative.
Summary
What will provide a vastly improved experience for architects and all those involved in building design is not better IFC tools from Autodesk and other vendors but a move by vendors to open and full API’s for their applications. And that goes for the 3rd party vendors as well. This would allow lossless data exchange and vastly improved BIM workflows.
So if you want to hassle Autodesk about anything, hassle them about the API and extending it to provide a lossless bi-directional pipe to 3rd party applications. If a vendor is moaning about IFC, tell them to look to the API instead. There is much missing in the current API around element configuration and element creation.
I see a full API as a win-win for Autodesk and end users. They get to concentrate on innovation without having to reveal and document their file formats or trying to convert to a lower common dominator file format such as IFC. The end user gets a framework for rich, interactive applications that will increasingly become required tools for BIM and IPD.
For project archiving, I don’t see IFC as anymore a guarantee than any other solution. A move to vendor supported serialisation of project data along with the appropriate schema would seem to be the only real possibility for lossless rebuilding of projects in the future. Even then, would the model represent the current as built structure? With the current state of the Revit API a certain level of serialisation is possible now. With published schema that mirror the API it would be possible to write rich importers for future versions of Revit or any other BIM application.
In conclusion, while some vendors and countries are pushing IFC, BIM and in particular IPD is still in it’s infancy. A push for software vendors to provide full open API’s to their application would I believe, provide a win-win for vendors and users. So hassle Autodesk about the API and hassle your 3rd party software vendors about the API instead of IFC.
Subscribe