Getting BIM data into Unity (Part 7 - Alternative 3D transfer)

This is part 7 of a series of posts about getting BIM data into Unity.

In this post, we’ll discuss alternative approaches to the FBX import from the first two articles.
This is not a coding post, but a reflection, with some hints to implementation.
There are many roads which lead to Rome… And depending on your use case, it may lead via different passages.

Investigating our options to load models from CAD/BIM

There are a few more 3D Formats which can be recognised by Unity, such as Wavefront OBJ or 3D Studio for MS DOS (*.3ds). A more modern format that is supported is Collada (*.dae). Depending on your CAD or BIM software, this may be a direct way to get your geometry there.

The biggest “gotcha” we get here is that these models often don’t include any form of object-identification (as in: having a unique and predictable name). We relied in the previous blog-posts on the fact that the exported geometry still contained a hint in its name to the original object, which was the whole reason our schedule-export allowed us to recover BIM attributes. With all objects bearing an anonymous name or a name based on the material, we have no way of knowing where the geometry came from.

Alternative formats to get from ARCHICAD to Unity

You could start from one of the many other geometry formats that are supported by ARCHICAD, such as Wavefront OBJ, 3DS (old 3D Studio for MS DOS) or Collada formats (via the Google Earth support).

Let’s see what options give us the best BIM-oriented results.

WaveFront (OBJ)

ARCHICAD has support for this old format since about forever. This is a quite reliable format and widely supported for visualisation. There are basically two options to convert the model: by layers + surface or by elements + surfaces. The latter is most promising in a BIM context.



However, this leads to having all individual elements split by surface, so we get the wall split in its layers (skins in ARCHICAD terms), and named as tool_storey_surface, which loses the unique name, but also the building material and the element grouping. Not that usable…



The other export option is layer + surface, which is even less usable.
Here is a fragment from the OBJ file (which is an ASCII file, fairly readable)

g 21_BUITENWANDEN VERF_-_WIT
usemtl VERF_-_WIT
v 6.06358 3.46984 0
v 2.9441 3.46984 0
v 2.9441 3.61984 0
v 6.06358 3.61984 0
v 2.9441 3.46984 0
v 2.9441 3.46984 2.85
v 2.9441 3.61984 2.85
v 2.9441 3.61984 0
v 6.06358 3.61984 2.85
…

This indeed indicates that the “g” (for geometry) has a name that is not sufficiently identifying the element and a reference to the ARCHICAD Surface (not the actual building material, but the surface finish). This is fine for rendering or visualisation, but not usable to transfer information.

3D Studio For MS DOS (3DS)

Here we have several export options. This first one looks most fit for a BIM-context.



This gives us the following result inside Unity:



Objects are kept separately: 1:1:1 till 1:3:1 is one wall with three visible layers (the cavity is not exported as geometry). Grouping them again seems possible. But the naming scheme looses any identification from ARCHICAD. In addition, texture mapping is not surviving correctly.

The alternative (working by types) is not a solution either.



Here, elements are identifiable as individual objects and texture mapping is now retained, but no identification whatsoever. Just an index number.



The next option makes the “object = group name” option available, but as the 3DS format dates from the old MS DOS age, we have to obey a name convention of 8+3 characters. This wrecks our naming again.



We see the start of the layer name appearing… But that’s all. Elements are not even addressable individually.



Without the group name, not even the layer name is there, just a number. Even if the ordering of elements is stable, this leads to a lot of difficulties recovering what is what in the imported geometry.
The final option (Surfaces) is ideal for rendering and static visualisation, but not for BIM as the model is regrouped per material surface and no individual objects are still recognizable.

Collada (DAE)

With the Google Earth export, you can export a KMZ file from ARCHICAD. This file is actually a ZIP file and if you unzip it, you can discover an embedded Collada file (extension .DAE) and some textures.

The geometry looks OK, but the grouping is odd and only generic names are used, so there is no way to identify elements.

Moreover, only a single material is retained inside Unity, which is not usable.

Custom Exporter Add-in

While not supported out-of-the-box, ARCHICAD could be expanded to include an FBX-exporter if you can write a proper Add-in for that. This could then avoid the reliance on the intermediate CINEMA4D conversion (and the reliance on a software you may or may not have access to). This requires good understanding of C++ and the way ARCHICAD geometry is kept, but if you prepare this properly, you may end up with the exact model structure you want: e.g. building - stories - elements - parts… and use the guid or the Compact Element ID as the name. Mmmm.. This sounds really close to IFC, if you ask me ;)

As you may guess, I have not done this. In the past, I did write a Radiance exporter add-in, so the approach of parsing the geometry an putting it into text files for processing in another software is feasible. But this was not taking any information into account.

Alternative formats to get from Revit to Unity

Direct FBX export

Similarly we could look at the alternatives for Revit, but as already mentioned before, the direct FBX-export from Revit gives results that are less usable than the passage via 3ds Max.

The element naming in itself seems usable (Type + elementID are included), but with the direct export, we lose the materials in Unity.

Custom Exporters in the App Store

As Revit can be extended via .NET add-ins, you could write alternative exporters. Luckily, some people have done this. In the Revit App Store, there are a few examples, for STL, Collada and OBJ. Some of them are commercial.

There is a Collada Exporter in the Lumion plugin.

Alas, this provides a split of the model by anonymous materials.



There is the Kubity Revit to SketchUp plugin: http://www.rvt2skp.com

This gives a clean looking model (with an annoying “watermark” as part of the style). The bad part (in our scenario) is that every single triangular face from Revit becomes a separate component. No way to recover the original Revit object anymore…



And this is what Unity makes from it… Clean graphics - but useless model for information gathering.

What else is there?

Doing more with XML

Thinking about the XML-based version of FBX, we may even be able to embed our BIM-data directly into the exported file. Now wouldn’t that be nice? Every object directly carries its metadata. Not need for parsing CSV files or preparing separate schedules.
Alas, while not tested nor confirmed, I can almost predict that Unity would simply ignore this custom data when importing FBX files. In fact, none of the native geometry importers from Unity look beyond geometry, materials and animations.

Getting better import? Or even a custom export/import format?

We could “invent” our own format and write an ARCHICAD exporter and a Revit exporter and a Unity importer routine. Possible, but a lot of work for something that is non-standard. There are already countless 3D, CAD and DCC (Digital Content Creation) formats. Wasn’t Collada (DAE) meant as such format? Probably.


(Source https://xkcd.com/927/)

Using a BIM-format

The last option (of course) is using a format that is meant to capture geometry and information: the Industry Foundation Classes or IFC. The format is well supported in all BIM-software, but obviously not something Unity would support out-of-the-box. In a future post, we will look more into the intricacies of trying to support IFC inside Unity.

To be continued…