Saturday, April 24, 2010

I Speak IFC

No I don't and nobody else does either. With my Revit focus, there are no applications that have IFC (Industry Foundation Classes) as their native tongue, sole language. I also can't help but think of Isaac Asimov's Foundation Series of sci-fi novels too.

For me trying to use IFC is like this scenario:

A room full of students in a Spanish class, none of whom speak Spanish but hope to learn. We study hard for a few weeks and then try to have a conversation. Lot's of talking, not much understanding and certainly not very effective. Even after more study we find that the Spanish we are speaking has changed because there is a new version. Now we need to study and review that version...repeat...

IFC as neutral format to help us share digital building information is a noble idea, just not sure it, or all the companies that have to conform to it, will ever live up to it.

[Edit/amended May 21, 2010] Guy wrote a post on his blog regarding this subject.

20 comments:

Josh said...

well said, Steve...good article!

James Van said...

Steve, I think your opinion of IFC is a bit short-sighted - no doubt assisted by Revit's lackluster implementation of the format. What we need out of our BIM vendors is a fully effective translator. We shouldn't need to understand the language and all of its nuances. Just realize that Autodesk should be an effective translator.

There are tools on the market that use IFC's...Solibri, Onuma Planning System, dROFUS...even some robust model viewers (DDS-CAD).

What happens when we have a test in Spanish? (i.e. A client requires it.) Should we say that we just don't understand the language? Or perhaps we should look at places where the language is actually used? A trip to Spain (or Scandinavia...for IFC).

Revit's IFC import/export abilities need to be upgraded to support better downstream use of our BIM data. We can't give up on this.

Steve said...

I'm not against IFC, just a bit skeptical. Not surprised you'd object to my post though considering your role *-).

My point about "Spanish" is there are no native IFC "speakers" to validate against. I can say I speak spanish and it sure "sounds good" but a native speaker will know in an instant that I'm not.

How "wall" is my "wall"? Is it IFC enough? When the definition (IFC versions and application support for versions) that says "it is" changes, all the various vendors have to revise again and they all do this inconsistently. Ultimately its a tower of somewhat incoherent babble instead of completely incoherent babble.

Criticism isn't rejection, "it" just doesn't live up to expectation.

And yes...with my Revit bias...

aireq said...

The industry needs to wake up and realize some painful truths about the current state of BIM and the usage of Revit. The projects we are designing and building today are going to be around much longer than AutoDesk has even been a company. In 25 years are we going be able to find a copy of Revit 2010 to open on our 256-bit version of Windows 15? I don't think so. Open documented standards such as IFC are critical to the success of BIM.

Although, I don't think the software companies are ultimately responsible for IFC's success or failure. At the end of the day they, like all companies, are in the business of making money. They are going to develop software that they think will sell, and if the industry is not asking for robust IFC support they aren't going to put effort into developing it. It's the industry's responsibility to start demanding it.

This transition from 2D CAD to 3D BIM is not the same as the transition from hand drafting to 2D CAD. Then the file formats did not matter because in the end whether you had a DWG or a DGN it would end up getting printed on paper. But now BIM models not just the digital paper that CAD was. There's much more information in a BIM model then shown on its paper representation.

Architects need to start taking as much interest in the digital representation of their designs as they do their graphic representation on paper.

Steve said...

Thanks for posting. I don't think we can be certain of any digital data working (being usable) 25 years from now based on technology today. Hopefully we can. I'm not sure a neutral format that will change over those same 25 years will guaranty it either.

It is clearly something to be concerned about. Right now we can pull a printed page out of a drawer to use later. 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.

aireq said...

I think a distinction needs to be made between "Open" and "Neutral". Neutral means the format was designed without bias from a specific group or company. Open means the format is at the very least publicly documented.

Neutral formats will help us today by allowing the software we are using to communicate with one another.

Yet what will matter 25 years from now is that the formats are at the very least documented.
A standard and neutral format like IFC would be preferred. But even a proprietary, but documented, format would be a step in the right direction.

Consider that right now the *only* way to get any information out of an RVT file is through an installation of Revit. Even the Revit API still requires that Revit is installed, licensed, and running. An even then there are large gaps in what information can be accessed in an RVT file through the API.

I doubt many architects even realize that their BIM is effectively being held hostage by Autodesk.

Josh Moore said...

Well, I read through all the comments, and I guess maybe I don't understand enough about what people actually want to do with this...I mean, in 25 years, yeah it would be great to be able to open up the model, but by then, who knows, I envision like virtual reality design and construction, where the BIM model literally becomes a virtual reality as it is designed...I think that the ability to open an IFC file and use it down the road (especially that far) may not be worth as much as we think it would today. I guess I am thinking in terms of new contruction that is designed using BIM models (Revit), and the use of the IFC file from that long ago.

It would be really cool to be able to take that IFC file into the future software and design methods down the road, but I guess I just wonder how valuable would actually be to future processes. I mean we already have laser scanners that we can put into a building and get accurate as built drawings from. Think in 10 years, how much more sophisticated that's going to be...what's really going to be the value of using an IFC file, that may or may not be accurate as to the as built condition, if say in 10 years, these laser scanners could be used to generate a 3D model for you that could be used in the future software workflows...just some thoughts.

Josh said...

P.S. I guess what I'm saying is that I see value in IFC for trying to go between software programs now and within a few years, but I don't think that in 25 years we will be looking at opening a Revit model or using IFC to get as built conditions.

Daniel said...

Finally some people give some good criticism on IFC.

Very well argumentented. I very much agree on the fact that IFC limits development of software.

I couldn't agree more on the api side. You see many programs writing their own interface to get the data properly.

Perhaps for archive purposes there is a role for an open format.

Daniel said...

http://xkcd.com/743/

they are both right in their own way

Christopher Hubbard said...

I am going to have to agree with James and say that people who disagree with IFC do not truely understand how it works and why it is important. And to compare it to the Office issue is not even close to the mark to be relevant.

Steve IFC is garunteed to be compatible going forward and does allow us to access older buildings. Hoepfully those buildings will be upgraded as IFC versions are, but it is in the mandate and testing.

To say no one speaks IFC is ignorant as well. Solibri and OPS both speak Native IFC and it is the only format they use, quite successfully I may add. There are also a number of databases and even a BIMserver that use Native IFC so again that argument falls down pretty fast.

Daniel how can you say IFC holds back development? Revit would be a much better tool if it used the OmniClass organization like IFC. To be fair so would ArchiCAD and Bentley BIM.

So while I have nothing against peoples opinions, when you post them they should be accurate.

My 2c

Steve said...

Christopher,

Thanks for sharing your thoughts. Solibri and OPS both support IFC by importing and/or exporting to the format. That isn't "native" in my mind. All applications have to pass information to and from IFC in one way or another.

My post was borne out of frustration with the whole process and the "not quite" there nature of if all.

As I've mentioned before I'm happy to be wrong now or in the future...just skeptical for now.

Steve said...

Christopher,

Blogger seems to have lost your reply when I published it. Can you post it again please? Thanks!

Christopher Hubbard said...

Steve,

I was saying OPS and Solibri both store data in Native IFC format. OPS uses a SQL database that stores IFC in its native format and only translates for other apps. Solibri is similar, the smc file stores the IFC data and adds the necessary data to perform the review. No transformation. I forsee ArchiCAD going this way as well, but we shall see.

New ArchiCAD integration with IFC looks really great, though it does appear to actually transform IFC to GDL. I should have my copy next week and try it out.

Steve said...

I've only used OPS casually once using their plug-in which seems a tighter integration than exporting to IFC and using their BIMxml converter etc. If their plug-in is using IFC then it's pretty effective.

I've not used Solibri but when I read their site it refers to importing and export to IFC. Gave me the impression that it is a compatible format, not a native format.

These two applications are not really trying to do the same things as Revit so IFC collaboration is more viable.

The notion of passing IFC data back and forth so that two different modelling tools can work on the same elements progressively without loss of fidelity on either end stills seems a stretch to me.

Thanks for sharing.

Alessio Boco said...

Hi guys

I am a Revit manager of a big scandinavian company (architecture and engineering) and I am FIGHTING the IFC battle every day.

I am not an expert regarding databases, API or similar, but as an end user I see everyday which are the structural differences between a native file and a IFC.

Every week I have to pick up the phone to call clients (requesting IFC models) and try to set up a meeting to discuss a "BIM strategy". An IFC contains maybe 25-50 procent of the intelligence of my original database (i.e. forget about phases or design options with IFC), in the hoped case that the geometry is converted in the right way!!!

Moreover I got a general feeling that it will not go better but worse as IFC's development does not go so fast as wished (actually the gap between Revit or Bentley and IFC seems to increase every day).

Of course an open format is important and right now very useful, but I guess that quite soon we might discover some new utilities to "talk" directly with other software (without IFC).

Christopher Hubbard said...

Fighting the IFC battle every day you should be pretty good at it by now. We use IFC all the time and if you look at the exported data from Revit in the RAW IFC format in Solibri or even Navisworks you will see all the important data is generally preserved. However Revit cannot re-read that data back into the correct locations and people generally assume INCORRECTLY this is the fault of IFC when in fact this is Revit.

We will be looking closely at ArchiCAD 14 to see how well the new IFC implementation has been done. Early reports (though as biased as this blog) are very encouraging and it looks like they have gone a long way to solving the problem by using a plugin in Revit to send a Pre-set IFC file that Archicad can read directly. I favor this method rather than have a direct plugin developed because it will reduce the development curve for future implementatins not impede as a previous poster claimed.

We also have noted that Autodesk wrote a very good white paper a few years ago on developing shared parameters that actually export to IFC and can be re-imported to Revit because they are shared parameters. We have been using this for some time with good success. So all is not lost, and IFC is a necessary and viable transfer format that needs to be considered and Revit experts would be well served to be fluent in its use

Anonymous said...

I love IFC because I have a format for exporting my Revit models to GIS and can then create shapefiles of my 3D buildings -- with all the data already stored in each object.

What frustrates me is IFC allows for coordinates, but Revit will not let me tag a point with a real world Long,Lat or a value more than a mile from 0,0. So in GIS I have to reproject the model to the correct location -- or manually change the coordinates in the IFC file.

Ashes of Time said...

IFC is a dream that everyone in the industry could share something in common with ease and acceptable quality, and resolve the interoperability issue. However, is it true that everybody is at the same page is willing to share with others? More questions to follow:
1.Do the software companies still care about the compatibility with IFC, and will continue to invest in such commitments even so far they don't see much ROI from IFC?
2.buildingSMART International is championing the efforts to improve IFC, but are they financially sustainable as a non-profit organization?
3.If the purpose of IFC is create a general framework for interoperability, then does it make sense to rely on it to share detailed design and construction information? What is a perfect level of detail should IFC capture?
4. How about xml? XML seems to be much more widely used as a common format for information exchange, can XML (not ifcXML!) eventually overtake IFC and become a norm in the industry?
5. Lots of BIM software applications have internal database structure, CATIA, Microstatoin, SQL...But data is data, by nature it is the foundation of information. So, can ODBC become the key to resolve the interoperability issue that IFC cannot?
Just too many questions. Look for opinions and expertise.

etoledo said...

Trying to answer some of your questions:

1.The software companies will do whatever their customers demand. When GSA started requiring ifc files, Autodesk customers forced the company to implement it on its applications. It is up to us.

2. As with any voluntary effort, IFC will take more time to develop and improve than it would if buildingSMART had proper funding.

3. I think the goal is to be able to exchange constrution level detail. Not sure how far are we from that. Certainly it depends on the specific domain.

4. XML is a meta-language (a language for specifying other languages): by itself, XML cannot be used for exchanging data. ifcXML is a language specified by an XML schema.

5. If you don´t know how data inside a DB is structured, ODBC doesn´t help you much for accessing the data. In a way, IFC is an specification on how to structure the building data, much like the internal structure of any BIM application.