Monday, March 28, 2011

IFC is BIM’s equivalent of Esperanto...

Thanks, I’ll rather go for English;

I can say that.
English is my third language. Fourth if I count German that I learned but forgotten.
I speak English with a thick Finn Ugor-Slavic accent and muddle up my tenses regularly.
I am very careful with the ‘their’ and ‘there’ but still get ‘than’ mixed up with ‘then’.
‘To’ and ‘too’ I’m OK with, but got to be careful not to address ‘staff’ as ‘stuff’.
I am hopeless with the ‘th’ sound (ask the daughters!) and do not get the double negative .

So, you’d think I’d be happy to have a ‘neutral’, made-up language I work with when I do BIM, but no.
I’ll go for a robust proprietary one any time.
Give all of them an equal chance to prove themselves, to gain traction and coverage.
If English is the language that comes up strongest, I’ll go with it ahead of others.

Relevance to BIM?
Well, IFC is being aggressively promoted as the ‘open BIM’, read ‘play nicely’  BIM language (file format).
 A ‘common’ language.
Also a bit of a bland – lowest common denominator format.

I am being a bit ignorant here, not just the usual arrogant since it’s been ages since I last tried using IFC.
I had tried it though and I’d sooner go for a 3DS format or EVEN DWF now!


  1. My personal opinion is that your thoughts on IFC are probably representative of most, and I think that is a real shame as IFC is capable of so much more than it is presently being utilized for.

    Typically IFC is used for coordination, not really sharing or transferring models. It's easy to point fingers at software vendors (on the suspicion that they are protecting their vested interest in retaining models within their software). But really the "partial" adoption/utilization of neutral bim formats is attributed to all parties involved.

    There is a degree of truth of lowest common denominator aspect (I can't see how there can not be for a neutral format) but it is much more capable than it's present use. For a start I would like to see some of the key BIM applications at least importing more accurate and capable shape representations than linear extrusions and faceted breps.

    Higher levels of collaboration and a push from users and clients can only help progress advances and better use of interop and model transfer.

  2. Interesting to see where you will end up.
    - no such thing as a complete software package (so we are to use a variety?)
    - IFC is flawed, proprietary is better (acknowledging the limitations of moving content between packages?)

  3. The key to understanding IFC is to realize that it is a geometric, not a parametric, data standard. (It is also, unlike 3D CAD, data-rich.) For a typical project team, this is not a bad thing. If I'm an architect, I would like to reference in the structural engineer's model to my architectural design, so I can easily check for conformance and (yes) collisions. IFC allows me to do this easily, whilst not giving me "too much rope" to inadvertently change the engineer's design. If you "let go" of the idea that BIM exchanges need to be parametric, you begin to see the value of IFC.

    (I should post a disclaimer here, I'm on the board of BuildingSMART Alliance, the US organization charged with promoting the user of OpenBIM workflows.)

    For some reason, IFC has begun to gain some momentum in the US after languishing for a decade or so. Perhaps its the support by governmental agencies in the US and in Scandinavia.

  4. I think your problem with the ifc format is not with the format itself, but with the implementation of ifc within software, expecialy the import bit....
    ArchiCAD, tekla, solibri, and DDS, all are pretty good, and I know the rest is working hard. Mostly because of goverment agensies requireing and using ifc.