This is part 8 of a series of posts about getting BIM data into Unity.
In this post, we’ll discuss IFC as a transfer format towards Unity.
As with the previous post, this is not a coding post, although hints and examples are provided.
Open BIM and IFC
Everybody who ever met me or heard me present on a conference or BIM-lecture will not be surprised to hear that I’m a strong believer in the Industry Foundation Classes (IFC), an open standard, with already two versions published as an ISO standard, being IFC2x2 and IFC4 (but surprisingly not IFC2x3 which is widely used). In the ideal world, this would be the format to use to transfer BIM data into another environment, such as Unity.
So what are our options?
Looking in the Unity Asset Store
Assimp is a library which supports multiple formats, including IFC.
I did a few attempts, but alas without any success. It is possible to compile the underlying assimp software library ourselves (and I succeeded to do so on my Mac), but in general, it failed with the different testing models I tried. Moreover, as this is only focusing on geometry, we still need alternatives to get the the model information at hand.
Writing a custom IFC import script from scratch
Yeah, right… And take a whole year or more to develop it… It is possible in theory (and a few smart people actually did this - but not directly for Unity). But with about thousand classes, data types and countless enumerations, this is a very expanded data scheme. You have two approaches: generating classes or objects directly from the specs or prepare all classes in advance. In both cases, people usually don’t write all IFC classes one by one, but parse the specs anyway.
Not from scratch then? Is there a library we can use?
Since Unity supports C#, we may want to look at .NET based libraries.
The two that come directly to mind are both open source: XBIM (the extensible BIM toolkit URL) and the libraries from Jon Mirtschin called Geometry Gym.
As it can be quiet involved to use them inside Unity, we postpone them for one of our next posts. Stay tuned.
Wrapping Native C++ Libraries
Libraries such as IfcOpenShell (http://ifcopenshell.org) and IfcEngine.dll (http://www.ifcbrowser.com) seem to be supported for .NET development, but that is implemented as .NET (not mono) wrappers around native C++ libraries and as such only supported on the Windows-platform. Others, such as IfcPlusPlus (http://www.ifcquery.com) or IFC-SDK (https://github.com/cstb/ifc-sdk) are pure C++ libraries. I discussed most of them in earlier posts on this blog, but due to the ever moving libraries and platform evolutions, will have to revise these posts in the future.
They can in theory be used when properly compiled as libraries, but you’d have to wrap them yourselves with C# code. And with a few hundred classes, this is not a small effort by far.
In the case of IfcEngine.dll there are almost no dependencies, but I don’t feel capable enough to compile this library to other platforms (and to have access to the source code requires a more expensive license). I know it supports Windows, macOS, Linux and even Android and iOS (with a static compiled library). While not that essential for my context, mobile support is “nice-to-have”. C# code which relies and C++ libraries requires these pre-compiled libraries to be prepared for every platform where you want to run the “game”. And forget about the WebGL platform.
You’d also have to ensure that the library itself is available on all platforms where you want to run the Unity app. E.g. on iOS, Android, macOS, Windows, Linux you need a usable library for the C++ part. Moreover, some platforms, such as iOS require static libraries, which is not always foreseen for that library. And they may introduce several dependencies along the way, so that is where I gave up.
Preprocessing in more convenient formats
IfcOpenShell is a very nice Open Source library, which has many usage scenarios. But it also depends on OpenCASCADE (https://www.opencascade.com/content/open-source-core-technology). This is a strength (as it supports advanced geometry processing) and a weakness (a reliance on a very large and complex library, which brings its own series of dependencies). This is the same geometry kernel supported by XBIM, by the way.
But there is a second approach. With IfcOpenShell, there is the IfcConvert utility (http://ifcopenshell.org/ifcconvert.html), which lets you convert an IFC model into a geometric model. A nice aspect of it is that you also have the option to create an XML export, which simplifies and flattens the IFC information content into simplified XML, containing one tree with the Spatial Containment hierarchy and one long list of PropertySets and Properties. The guids are retained and with some XML parsing, you should be able to reconstruct the objects with their properties from it.
So that is what I did. The trick for Unity lies in linking the different exports (geometry and information) to restore the model with its embedded information.
|Imported IFC file from the OBJimporter script|
As this goes quite into detail and requires scripting, this will be discussed in another blog post. This was required to get the model hierarchy (shown left) and some of the object properties (shown on the right "IFC Data")
(Teasing, I know…)
Different approach based on a Python library
Along my research on IFC-support libraries, I also found a nice and extremely small Python library. Actually, it is more an Express and IFC-file parser, relying on regular expressions.
It is written in Python but I have been able to translate it into C# code (even though still very rough and with many limitations). That said, this way you have a native code library, with no dependencies whatsoever and directly usable inside Unity.
Did it work? Sort of. It did allow to do some basic parsing, but to get actual geometry and full model information would require a huge extension of that library. That is not feasible here.
Stay tuned for the next episode in this series, with actual scripts to follow and use.