October 7, 2013

IFC for content

I got myself into an interesting twitter discussion last friday regarding the use of IFC. It started out as a complaint from someone stating "why does one format (presumably Revit) get native content, whilst I have to deal with IFC (in Archicad). It evolved in a debate about whether there is something as a single-format-solution for all BIM software. And should we be able to all work together on a single IFC model, all being able to alter it.

Unfortunately as more and more people got into the debate, you end up having to send two tweets just to get one proper sentence out. So I figured I'd compose some thoughts here. Let's start with the first part, IFC for content. The part about a single IFC model will have to wait until later this week.

IFC for content

IFC was never intended for "dynamic" use. It is a format to hand information to someone else down the line. It was not meant for weekly exchange between design partners. That can be done, but is a stretch and needs further development.
What it certainly is NOT meant for, and imho is very very bad for, is creating content libraries. Allow me to give you a few reasons why it's a bad idea:

#1: IFC is meant for projects.

Here's a challenge: show me an IFC-file that is not formatted as a project. Because the assumption when creating an IFC from any vendor software is that you are creating a project. Not a piece of content. Off course, you can bypass this. And it's just a minor glitch. But it should be taken as a sign: it's not suitable.
Check the content in the UK National BIM Library. It's all formatted as a project... Which means the user will need to do some work (or the software) to get this imported as an object. Or it will just not work as expected...

#2: Object definition

The definition of an object in IFC can be done in several ways. There's ways that give you nice and crispy clean IFC's. There's also ways that give you a 3000 line of code to define a single water closet. Check the UK National BIM Library, go to the toilet section, download an IFC called "Concealed cistern" and open in Notepad. It has 2640 lines of code to describe a freaking cistern.

It would be too easy to call that a stinkin' pile of crap... Point is: this is modelled in some vendor software and exported. You don't have anything to say on how it's exported. The vendor software just does what needs to be done... Without any way of controlling this (unless you code a custom exporter).
But seriously? Stuff 300 of these in your project and let me see you twirl your model around...

#3: IFC Dialects

We all have different software. With different ways of defining components. With different source code and kernels. There is no way in hell there is going to be a one-size-fits-all content library. It won't work. That's the same as saying "I got tires that will suit a Mini, a Jaguar, a Land Rover and a tank. I guarantee equal performance on all". Not going to happen.

Also because a tank doesn't need tires...

Like I said, not going to work. The needs and desires from a piece of library content are just too different. What works for one software creates a mess in the other. Why is it that Archicad has different export settings for Tekla and Revit? Because they both interpret IFC differently. All three speak IFC dialects. IF you were to create an IFC object library, you would have to have several IFC dialects to make it work. Which is insane, cause then you could just as well simply create native stuff.

Enough with the freaking libraries!

Get it into your heads people: common content libraries are a thing of the past. It's thinking CAD in a BIM world. It's like wanting to invest heavily in a telephone landline infrastructure in Africa, while people there are standing around texting each other on their mobile about what those crazy foreigners are doing.
We once needed those because they were a graphical interpretation of object specifications. Back in the day when we didn't virtualize the entire building but only did a graphical interpretation of it in a bunch of 2D drawings.
The misconception about needing libraries is that we need something different from what manufacturers already have. I don't want a manufacturers library! I want them to give me the data they already have from their manufacturing or sales processes in a structured, uniform way. Every manufacturer with an automated production line has every piece on information we need to fully automate object creation.

Geometric data? They have machines actually making that stuff! Any pipe, desk, air handling unit, sink, window or steel beam that is created in an automated assembly line is fully digitized. Or do you imagine them turning on the machines in the monring just waiting to see what happens? It HAS to be specced, or they won't be any product at the end of the line!
So just give me the data you use there, and I can ask a software engineer to write me a nice little addon that takes that data and automatically creates the families I need.

Performance data? How do you choose which door you want to use? You go online, Google, look at websites and pick a door. Not just any door, but the door that meets your specifications. How did that info get on that website? Someone from the manufacturer put it there. If they're smart, they have this big database that's hooked into their internal Product Management System, and a selection menu on their website. You know, one that let's you specify if it's an interior or exterior door, fire rating, what kind of operation, and so on. When you checked the boxes, there's a list of possible doors. With a link to a downloadsite so I can get a component for my project.

Here's a suggestion: do that inside my software. Create an internet database with all geometric and performance data. Hell, let an organisation such as the NBS in the UK govern it and add as many manufaturers as possible. Build a plugin for my software that connects to it and give me that selection tree inside my software. Then let me use that database to create objects as I need them. Do you have new products? Add them to the database and send me an email. 

And we're all done. For a fraction of a tiny bit of a small percentage of the costs it would take you to get a global, all-encompassing library of manufacturers products. The manufacturer doesn't need to keep a gazillion families up to date for several versions of multiple software platforms. I don't need to worry about stripping manufacturers content off useless garbage such as 2D representations and wrong linestyles, repathing parameters and object styles, and all that other stuff I do to get the content to look the way I want it and carry the information I need.

Too expensive? Not doable? Think again. I've seen a Dutch company that sells interior doors taking their "webshop", put the desired parameters in an Excel workbook and let the entire family be created from a Revit plugin that reads that database. As a user you just type in some specs and it will create the families needed. This is done by 1 guy without any previous experience with coding...
Agreed, it took him some time and he had help from an experienced programmer (who knew diddly squat about Revit or the Revit API) but it's there. With very limited resources. They are now working on expanding the addon to include more detail (locks and hinges, and so on). You know what the fun part is? They don't have to redo a whole library. Just add some code. They don't have to re-publish the whole library. Their users don't have to re-download the whole library. Just update the addin.

IMHO that's the way we should go: get some data-architects in a room, let them agree on a common output specification for manufacturers and let them develop some plugins for different software vendors that can read and translate this output specification using user-defined project and family templates.
Then, manufacturers only need to provide us with data instead of countless digital versions of their products . And we can re-use that to create content that is always up to date in our own native formats.


  1. Martijn, just to let you know; CIBSE, BSRIA and the Landscape Institute are already working on those standardised data formats in the UK. We are taking IFC and SPie as a starting point, extending them to properly define each component type, running that past various manufacturers, manufacturers institutions and trade bodies, contractors, FMs and consultants, so we are covering the whole life cycle.

    We are looking to start publising for consultation soon on BIMtalk.co.uk and we are hoping to include Architecture and Structures soon as well.

  2. Hi Avatart,
    That's great news. I would very much like to know more about that initiative. Can you drop me an email on martijnderiet at mdr-advies dot nl?

  3. Interesting discussion. While IFC objects are currently not ideal (e.g. each IFC file has a project-site-building structure, whereas you'd only need the object itself), it is good to think about how they might work.

    I struggle with the idea of how to actually create them. My first thought (which can be wrong) was to either start from a native model and live with the limitations of IFC export (e.g. GDL object in ArchiCAD + added IFC parameters).

    Another thought was to go from a parametric, procedural approach (focused on IFC structure) and than generate native models from it (GDL, Family, ...).

    Both approaches have severe limitations, so I would love to get an idea of how to tackle it better.

  4. Hi Stefan,

    I would opt for the second one. For instance Grasshopper has the ability to create native IFC components based on parametric rules (as I understand it). Having to create natively and then export has some backdrafts that I don't see getting solved for quite some time:
    - The inability to to control the way an element is exported. Look at the cistern I mentioned, it's probably created in Revit and then exported. While the shape is fairly simple in Revit, the export engine turns it into a giant mess.
    - Every software speaks some sort of IFC dialect. Which will reflect in the resulting IFC. Again, as a user you don't have any influence on that. It will hurt performance in other software.

    But in theory it should be possible to just write an IFC (and I mean that literally) component. The syntax is known, so it shouldn't be a problem to create a simple modeller that let's you create solids and such and add parameters.
    Now to find someone who can and will actually build that.

  5. Hi Martijn,

    Thanks for the post. I look forward to reading more. I put my response here:

    Cheers, Jon

  6. Each software speaks it's own dialect when exporting to IFC. If we would have a native IFC component (created in an application that still needs to be invented) will this then solve our problems? Will each of the software then import it correctly? Won't we just end up with the same dialect issue?

  7. Martijn, great thought about Revit content creation via DataBase. As manufacture, I have to create self-service lines. How can I build one self-service line with different refrigerated countertops, bain-marines, neutral equipment, cash-register etc. Also I should add accessories like: sneeze guards, tray sliders (with different height from the floor), legs or casters etc.
    Another aspect I should consider is rendering. My self-service line could have different materials for external panels and for worktops.
    Is it possible to encapsulate all this data into DataBase? Can it be done?
    I'm presume in near future not. In long term period probably yes, but with what instruments?