While this site still looks quite raw (I know) I nevertheless wanted to share something about the goal that I try to accomplish. IFC files have the repution to be large, dumb, static and hard to work with. Well, in parts because – if you look at what gets exported out of e.g. Autodesk Revit, they are.
Still – we can do better. After studying the IFC-schema in detail for more than two years (well, not full time, just every now and then) and trying to fix “issues” in numerous models I started to shift my work to improving the files per se. In fact, IFC files are just plain text that is interpreted by 3D viewers to display the nice 3D buildings that we are used to. But the plain text can be manipulated programmatically. And that’s what I do quite often, recently.
It is true – having to work with files that are hundreds of megabytes in size is slow, frustrating and makes you wish to switch back to your beloved BIM authoring software. However, if you take a detailled look at all the data that is in the IFC-file (that was created by the mentioned authoring software) you can see that it describes your building in a really dumb way.
Take one example – round columns. One would expect that a column would be represented by a simple cylinder. Well, it is not. First, 21 points are defined in a list. Then another line “creates” an area out of these points. One more line in the file declares that this polygonal profile is swept along a path (again, defined in another line). So you end up with lots of gibberish that tesselates a cylinder.
Instead of those many, many lines of unrecognizable “code” you could simply declare a cylinder by its radius and height. That’s all. One short line.
As you can see, it is possible to reengineer the original geometry without having to deal with the IFC exporter. And it can reduce the file size significally. We are talking 80 per cent here. And a readable structure like this even allows you to parametrically modify your IFC files; you can change the radius or height just by editing one value.
Round elements are a good example for the great potential of file size optimization. Rectangular profiles can be parameterized, too; in that case the reduction is not that much as only 4 Points are necessary instead of e.g. 21.
When scrolling through the raw IFC I recognize the same issues in multiple spots. The files are not optimized, i.e. there are lots of duplicates. Geometry data in those files can be reduced to less than 10 per cent if done correctly. I checked models that had 180 tesselated shape representations when only 9 different shapes were in fact necessary created from three (!) primitives.
That is the ratio that we aim at, 90 to 95 per cent reduction. That will give IFC files a better reputation and higher priority within the whole BIM discussion. Let’s be honest: what is more realistic – that you can open and read a native Revit / ArchiCAD file 30 years from now or an IFC file?