Skip to main content

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.

PastedGraphic-2018-01-22-12-03.png

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…

PastedGraphic1-2018-01-22-12-03.png

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.

PastedGraphic2-2018-01-22-12-03.png

This gives us the following result inside Unity:

PastedGraphic3-2018-01-22-12-03.png

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.

PastedGraphic4-2018-01-22-12-03.png

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

PastedGraphic5-2018-01-22-12-03.png

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.

PastedGraphic6-2018-01-22-12-03.png

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

PastedGraphic7-2018-01-22-12-03.png

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.

PastedGraphic8-2018-01-22-12-03.png

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.

1__%2524%2521%2540%2521__PastedGraphic-2018-01-22-12-03.png

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.

1__%2524%2521%2540%2521__PastedGraphic1-2018-01-22-12-03.png

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…

1__%2524%2521%2540%2521__1__%2524%2521%2540%2521__PastedGraphic-2018-01-22-12-03.png

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

1__%2524%2521%2540%2521__1__%2524%2521%2540%2521__PastedGraphic1-2018-01-22-12-03.png

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.

standards-2018-01-22-12-03.png
(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…

Comments

Popular posts from this blog

Improve usage of BIM during early design phases

When I was collecting ideas for a book chapter on BIM (that seemed to never have emerged after that), I collected 10 ideas, which I believe still reflect good recommendations to improve the usage of BIM during the early design phases. These ideas are related to BIM software, but you can apply them in any flavor, as long as you can model with Building Elements, Spaces and have control over representation. Introduction This article gives an overview of several recommendations and tips, to better apply BIM applications and BIM methodologies, in the context of the early design phases. Many of these tips are applicable in any BIM application and they are based on experience gathered from teaching, researching and using BIM software. Sometimes they could help software developers to improve the workflow of their particular BIM implementation. Tip 1 : Gradually increase the amount of information In the early design phases, the architect makes assumptions and lays out the main design in

Getting BIM data into Unity (Part 9 - using IfcConvert)

This is part 9 of a series of posts about getting BIM data into Unity. In this post, we’ll discuss the IfcConvert utility from the IfcOpenShell Open Source IFC Library to preprocess an IFC model for integration with Unity. This is (finally?) again a coding post, with some scripts which are shared to build upon. Conversion of IFC into Unity-friendly formats The strategy with this approach is that you preprocess the IFC-file into more manageable formats for Unity integration. Most Web-platforms do some sort of pre-processing anyway, so what you see in your browsers is almost never an IFC-file, but an optimised Mesh-based geometric representation. However, it wouldn’t be BIM-related if we’d limit ourselves to the geometry, so we will parse the model information as well, albeit using another, pre-processed file. IFC to Wavefront OBJ I used a test IFC-model and used the IfcConvert-utility converted it into OBJ en XML formats. The default way to use it is very simple:

Getting BIM data into Unity (Part 8 - Strategies to tackle IFC)

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. https://assetstore.unity.com/packages/tools/modeling/trilib-unity-model-loader-package-91777   I did a few attempts, but alas without any success. It is possib