The Paradox of IFC

I had an interesting discussion with mr. Velez, the head developer IFC from Autodesk. Which I thought would be nice to share with you all...

I reached the conclusion that there's an interesting loophole in place when it comes to the acceptance of IFC in the AEC industry. I could even say in the Revit-using part of it, but that would probably sell the non-Autodesk disbelievers short. So let's keep it general for now. Don't know how Angel feels about my philosofical insights yet, since he's sleeping now (hopefully). But here it goes:

Standard conversation.

Let's lay out the standard IFC-conversation I have with a lot of people not wanting to use IFC:

Them: We need partners to work with Revit
Me: Why?
Them: because we can't communicate if they don't, which kinds of defeats the purpose of BIM
Me: Why won't you use IFC then?

(from this point onward, the discussion is the same for people using other software, regardless on whether they use IFC or not)

Them: because there's always a loss of information
Me: No there isn't
Them: Yes there is.
Me: Maybe when you do it, I can get any piece of information I want
Them: No you can't
(btw, I never said these conversations are very intellectually challenging)
Me: Have you tried?
Them: Yes, we exported an IFC once. It sucked. All kinds of information missing.
Me: What settings did you apply?
Them: Settings...?

And so on...

Point is: IFC has difficulty in getting accepted because of the supposed loss of information when exchanging models. And that's partly right, however for the wrong reasons. Insufficient implementation in (ALL!) software is what's causing this, not IFC itself. The format is capable of carrying through each and any piece of information you would ever put in your model, and much more. Losless. It's just not implemented that way.

Getting this done is actually the easy part of IFC implementation. It's just a matter of mapping. Which native parameter goes into it's IFC counterpart. And which ones don't have an IFC counterpart? Nice to know, since IFC does allow you to create custom properties for any and all objects.
It's supposed to be relatively simple...

So why aren't we fixing this?

Basically because everybody keeps focussing on getting all the geometry right.
And off course this is important. You don't want to be losing all kinds of objects. But seriously: how often does this happen? 

Let me rephrase: how often does it happen and NOT because of the guy modelling it?

Cause I haven't seen it yet. I haven't seen ANY project where the loss of geometry was NOT caused by the way stuff was modelled, exported, or mapped. Period. And I've seen a lot, trust me. So maybe I haven't seen those few projects where there actually is an inexplainable loss of geometry. But it can't be more then a handful.

Yet there seems to be a huge imbalance between geometry and information in terms of focus and budget. As in: the focus is almost solely on geometry, leaving the information part with improvements that require no more then an hour of programming time max.

Is geometry that important?

No it isn't. Not in my opinion anyway. Now don't start with that "but you're just a consultant, we have real projects" bull. My clients aren't toying around all day and I get paid to deliver results, just the same as anyone else. No results = byebye consultant (even more easily then with employees I might add). It's not about projects, it's about the process.

The majority of firms uses IFC throughout the project as a means of communicating with different project partners. So you get an update every other week or even weekly. Those are used for clash detection, design sessions and so on.

By definition there is stuff missing, incomplete or not there. You're still in the design phase for crying out loud. It's supposed to be that way! Seriously, who cares whether stuff is missing because of the fact it's yet to be designed, or because something went wrong in the export. In fact, there's only one point in time when the IFC needs to be perfect, and that's when it's time to create the deliverable. And I'd rather experience all those errors upfront instead of upon delivery. That way they pop up during design sessions. And I can fix them...

So no, I'm not saying we should except the fact that stuff might go wrong. I am however saying that the impact of those errors is grocely overrated. The first thing I say when someone starts telling me horror-stories about IFC's not being correct is "wow, what did that cost you in penalties from your clients?". I usually get a blank stare... Followed by "uhm, they never knew. We found out during our first design meeting and fixed it".

Fact of the matter is: these are tools. Tools fail sometimes. Revit fails some times. Project files get corrupted all the time. Stuff goes missing, gets omitted from schedules due to wrong filters or modelling methods. Gets accidentally deleted because it's on the wrong Level or a Linked element that is remodelled.

How can someone using Revit tell me that they intend to focus solely on geometry when it comes to IFC until it's 100% reliable? Like Revit is? But when it comes to our primary tool, we build safeguards in our process. So why regard IFC differently?

Now for the Paradox.

On the one hand it's usage in the (Revit-minded) AEC industry is being held back by the general consensus that you lose information when exchanging IFC's. On the other hand, the people that DO use IFC with Revit pressure Autodesk into allocating the vast majority of their resources into focussing on geometry exchange instead of fixing the information drain. 

At the same time, fixing the information loss can be overcome rather easily. It's a User Interface thing. You need to be able to map information from Revit to IFC and back. That's it. The second part, the geometry is way, way more complicated. Needs far more resources.

Now since Autodesk is a commercial company they, to some extend, listen to their customers and drive development on their needs. And budgets are defined based on the size of the (expected) user base and commercial gain. Nothing wrong with that, that's how commerce works. The guy paying the bills gets to make the decisions. 

What we have here is the situation where existing IFC users force Autodesk away from implementing relatively cheap solutions that would actually make IFC more attractive for non-users (eliminating loss of information), which generates a bigger user base, which in turn generates larger funds to tackle the more complicated geometry-related problems.

The Paradox of IFC Implementation is that that the people actually using it with Revit prevent Autodesk from taking big steps in the implementation of it's strongest feature (and major advantage towards geometry based formats such as 3D dwg): the ability to exchange object information.

How to solve this?

I don't know really. Somehow I don't think that after reading this everyone will say "he's right, what was I thinking? Silly me...".
But I am glad I focus on the "easy" part of IFC. That might just make it possible to have another go at the whole programming thing and start doing it  myself.
More on that later...

The biggest issue with OpenBIM and IFC...

An article about IFC that I wrote recently made it to the AUGI-library today. Which got tweeted by +Shaun Farrell (thanks for that btw!).
Which in turn provoked some dude to go all ballistic on me: https://twitter.com/ShaunF1969/status/411027695707750400

Now, usually when the tone of voice comes to this I bail. Don't get me wrong, I love a good debate. And I am never shy to vent my (usually rather explicit) opinions. But there's two rules I have:
1. be prepared to adjust your opinions.
2. at least try to have some sort of logic behind your opinion.
These kind of people usually have neither, so there's really no point in trying to talk to them. But still, they annoy the crap out of me. So here's a once and for all rebuttal, next time I can just point them in this direction.

So please, if you don't want to waste your time on my rants, stop reading here. Next few hundreds words will be lost on someone that probably doesn't even give two cents on what I have to say anyway. His mind is made up: if you roll with the Devil (Autodesk), you are the Devil.

Let's get one thing straight

I'm very much aware of the fact that I do not know everything about anything. Or that I even come close. In fact, I usually just know a tiny little bit and guesstimate my way from there. Which works very well btw.
But every now and then I get my wrist slapped for uttering something wrong. And I adjust my opinion accordingly. You live to learn right?

So even though I have strong, and often controversial, opinions they do tend to have a reason behind them. At least in my mind they're backed with actual facts and can stand a critical peer review.

Why tell you this? Because I don't care whether you're strongvoiced and explicit. I am too. And I can take it from others. I might even adjust my opinions if it makes any sense. But in my experience, your kind of people usually just parrots each other. I haven't read one single (even remotely) valid argument that would justify these words.

So what is the biggest issue with OpenBIM then?

Here's my opinion: the biggest issue is guys like you. Big-ass loudmouths who spend their lives bitching and moaning about the Big Bad Autodesk not supporting IFC enough. Who interpret anything anyone that uses Autodesk software writes or says about IFC/Open BIM as an attempt to "bury" it.

Without actually contributing anything to the Good Cause themselves, except buying an "open BIM" software.

Big freaking deal! Did you ever look up the definition of Open Source? It's not the same as "free" you know. Open Source means that developing it and bringing it to the next level depends on the actual commitment of people using it. That's why you don't pay for a license with IFC. You should be either donating or actually making a contribution. And buying a software that has a big shiny marketing sticker on it that says "Open BIM" does not constitute to any of this.

Flaming others that actually do make a valid contribution does not either btw.

I can take the crap from Autodesk Fanboys (and -girls). They genuinly believe that their one-stop solution is the best. I disagree, but hey, I can respect an honest opinion. You people on the other hand are something else. You are full of "collaboration" and "interoperability". Yet you condemn anything remotely related to Autodesk to be against these ideals. You don't care what people like me say or do. You consider us traitors to the good cause no matter what. All we do is try to "bury", "flame" or "badmouth" IFC. No matter what.

Let me tell you this: Autodesk, let alone people like me, aren't the biggest problems for Open BIM or the acceptance of IFC. It's people like you. You are it's Trojan horse. The enemy within, poisoning the roots and foundation on which the whole concept of interoperability is built. You talk about open standards and freedom of choice whilst in the same breath you condemn and write off a whole group of people just because they use the wrong software.

Let's compare size

Want to be in my face? Fine, bring it on. Here's my list of achievements:

1. First AUGI author to write an articles (let alone 3) on the use of IFC with any Autodesk software

2. First Autodesk University AND Revit Technology Conference speaker to talk solely about how to use Revit and IFC (and possibly any Autodesk software and IFC)

3. Main author of the first and only Open Source Revit Standard (as I define Open Source as freely accessible to anyone)

4. Main author of the first and only Revit Standard and Workflow that even mentions IFC. And this one does actually work. I can get ANY piece of geometry AND information out to IFC with Revit. 

5. Instigator of the first and only 3rd party contribution to the Autodesk Open Source IFC Exporter. Responsible for creating the ability to map Revit information to IFC information.

6. Instigator of the second 3rd party contribution to the Open Source IFC Exporter: creating the ability to create custom IFC Property Sets and fill them with any kind of information from Revit. Still in beta though due to lack of funding

7. And all of the above roughly cost me $100,000.- in lost gross revenues when I put my consultancy firm on hold for a year working on this.

These are real things. More then just some big words on Twitter.

Next time you wanna pick a fight, bring your list of accomplishments on the development and implementaton of IFC. If anything less then this, we're not even going there. You're not worthy of my time. I can spend it more wisely on actually getting shit done. So please, do step aside and go bark up some other tree while the big boys make a difference.

Or, you know, do some freaking research on the guy you're calling out.

End note

I should probably have refrained from writing this. Be the better man and not let myself get dragged into this childish fight. But you know what? Screw that, screw you and the likes of you. I'm sick and tired having to put up with this shit from a bunch of twobit slackers who feel they have moral high-ground just because they once bought the "right" software. 

I actually studied IFC. Made an effort to understand it. Improve implementation in my software. Shared my knowledge with others and with that gave people the ability to use it better.

You just bought a freaking piece of software. A tool. And when it comes to IFC, yes: a slightly better tool. Big freaking deal.

What REAL effort did you put in there? Where's your contribution to Open BIM? You know, one that didn't get paid for by your boss or clients? Or you didn't have to do anyway to actually do your freaking job? Have you ever even spent one moment of your time improving the Open BIM workflow? And share that knowledge with others?

Probably not. You just assume that because you bought the right tool you have the right to come to my door and pick a fight. 

Well guess what: wrong day, wrong guy. 

Fuck off.