IFC - Questions from a beginner

Developers
1

Hi, I’m a software developer and I’m new to the 3D modeling programs for the building industry.

My goal is to make a separate application that takes a building and does a Life Cycle Assessment (LCA) on it. It’s about how environmentally sound it is. Down the line I might look at life cycle costs as well.

For this I need to:

  1. Read and interpret a file format that all 3D building apps (Revit, Rhino, etc.) can export to easily.
  2. Make geometry from what has been interpreted
  3. Do calculations on volumes of different building parts and determine how environmentally sound it is.

I’ll be making the application in Unity3D using C#. I’d like to have a quick iteration process between the building app and the LCA app. Make a small change in the building → see the change quickly in the LCA app.

I’ve been recommended IFC as a file format to carry data from building app to LCA app. Where is a good place to get familiar with this format? I have a long list of questions about it. Will the same object always have the same id in subsequent exports? What’s the best way to read IFC and make geometry from it in the LCA app (separate of any building apps)?

Thanks in advance.

1 Like
2

Welcome to the buildingSMART community.

Some good places to get familiar with IFC and tools:
https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/

https://technical.buildingsmart.org/community/software-implementations/

http://ifcopenshell.org/

Will the same object always have the same id in subsequent exports?
To some extent yes:
Building elements usually have same “Globally Unique Id” (GUID) in subsequent exports from the same authoring-software.
GUIDs of element types, property sets, relations, etc. are different in subsequent exports in some authoring-software, for whatever reason.

If you try to import an IFC file to another authoring-software and immediately re-export to IFC without any manual changes (round-trip) you will get a nasty surprise:

IFC is far from perfect but it is the best what we have for software-independent model exchange of building information and civil engineering project information.

Best way to read IFC:
Take a look at IfcOpenShell, xBIM, blenderBIM,…
https://technical.buildingsmart.org/community/software-implementations/

Best regards,
Herbert

1 Like
3

@Herb provided all the resource you need

Also, I’m not sure but I think Unity supports IFC, also Unreal Engine

However, as you mentioned you need some specific workflows from inside the IFC and outside to do LCA and LCC

4

You mention a quick iteration in your post. I would warn that the current state of the industry is not quite there yet on quick iterations of IFC data.

Perhaps something like Speckle might be suitable in the meantime.

This page may help: https://wiki.osarch.org/index.php?title=AEC_Free_Software_directory#Software_Development

5

In FOSS maybe but in the commercial atmosphere there’re some interesting tools that are not complete yet but follow good path

For instance, https://avanova.de is somewhat automatic

Or EC3 (https://buildingtransparency.org/dashboard) in LCA area which is promising, however, still, it’s not complete and just support Design phase

Or One Click (https://www.oneclicklca.com)

All in all, in both 4D and 5D and also LCA and LCC what you need is “automatically recognize building elements” and other data/information

6

Thanks, Herb. XbimEssentials seems to do my step 1 (read IFC file) and XbimGeometry seems to do step 2 (make 3D geometry). So that’s great. I was slightly worried I’d have to do step 2 myself even though it would be a fun challenge.

Regarding round-trip problems: this will be a one-way trip from building app to LCA app, so I shouldn’t run into that problem. In the LCA app I’ll store extra data about materials etc. for the environmental impact calculations, but they will not be transferred back to the building app. For that reason it’s also important that each building element has the same ID in each transfer via IFC to LCA app. From what you say it sounds like that’ll work well enough. Thanks again.

7

Pixyz has a paid plugin for Unity that can import while you’re in the Unity editor. I haven’t been able to find any other solutions. It can’t import in a compiled Unity app though, and I need that.

8

What do you mean by this? Does export/import take a long time? Or is it the quality of material data?

9

FWIW, getting IFC in Unity has been an ongoing theme in my blog for some time. I have shared my experience + code samples here:

My experience:

  • C# in Unity has evolved enough to make it more up to date than it was - earlier on, it was a limited customised mono-version, now there is at least dotnet 4 support.
  • XBIM Geometry libraries are required for interpretation of geometry. However, they rely on an external library (OpenCASCADE). The dotnet wrapper around OpenCASCADE in XBIM is limited to the Windows platform. On my Mac, I could only get the XBIM Essentials package running inside Unity to parse the IFC structure (so no geometry conversion);
  • GeometryGym also provides a C# library. I have used the open source version in Unity with similar results (no geometry);
  • In all cases, without full support for interpretation of geometry, you are best to ensure your export only contains Triangulated BREP, as that is the most straightforward to interpret. You could optimise an export with SimpleBIM to only use BREP geometry.
  • As an alternative, I also tried IfcConvert (from ifcopenshell.org) to convert the IFC file into an OBJ file and also into a separate XML file. The trick was to set the option to use the GUID as names for the geometry, so I could reconnect the properties (from XML) back to the geometry (from OBJ).
  • Full access to material information is very much dependent on the way the model is created in the authoring software. There are several threads on this forum, but the main issues are:
    • Many models have multilayered elements, yet their export only shows the whole geometry or the splitting does not provide clean solids per material;
    • Information about materials is not always exported into the IFC file;

So in general, for LCA, you’ll have a good challenge ahead of you.

1 Like
10

First, your post is invaluable. Thanks a lot. I’ll spend some time going through your blog.

Ideally I want Windows, Mac and Linux support. Or at least the first two. So that leaves out XBIM unfortunately. But it sounds like IfcConvert might do the trick.

11

Hi,

There is another option, although it is not free of charge:

Tridify is a free asset downloadable through Unity Assets Store that allows you for import of ifc files. However, you need to sign up for a Tridify account for the conversion of ifc files; there are several plans, NONE of them is free. tridify.com

You may also want to take a look at the Unity Reflect solution, which currently links dynamically Revit and your Unity application. It is intended to extend in the future to main BIM modelling software. It allows for nearly real time modification of the elements inside Unity after modifying the Revit model (live link) It is unidirectional (BIM tool to Unity), the way back needs to be programmed (file update in xml or json format), but it is doable (there is a video on a use case). It is not free of charge and it requires also a Unity Pro licence.

I have not used Tridify myself, but I have tested Unity Reflect. An advantedge over using ifc convert is that dynamic conversion of obj files is much slower than the linkage provided by Unity Reflect.

12

Yes, ifc Convert should do the trick, and there are several Unity assets (some free, some not) that allow for dynamic loading (on the fly) of obj files. Loading performance and potential loss of data is an issue, depending on the model

13

Thanks for your input, Juan.

Where would this loss occur?
building app → IFC?
IFC → OBJ?
OBJ → Unity?

14

Anytime we import and export models in different software for sure “Data/Information Loss” happens

Does Unity support “glTF?” The answer should be: Yes

So, instead of “IfcConvert” that parses geometries/topologies into OBJ or XML, use Blender and BlenderBIM and export your geometry/topology to glTF and import in Unity
I think this way is better

15

Blender has started to support USD (https://github.com/PixarAnimationStudios/USD) too

16

@ReD_CoDE I’d like for the end product to be as simple to use as possible. Another step through Blender before getting into the app made in Unity is not ideal. The workflow is ideally

  1. export file from any building app
  2. import file in Unity app (not the Unity editor)

Perhaps step 2 is even automatic.

17

I was referring mainly to the IFC export from the native modelling apps and, more specifically, Revit. You have an option of exporting all the Revit properies (an option which generates extremelly heavy IFC and maps this info to custom property sets) or you can follow a mapping procedure which is not straighttforward for the common users. Also IFC 4 file generation is only in beta version. More info here, courtesy of Moult: https://thinkmoult.com/how-to-create-better-ifc-files-with-revit.html

1 Like
18

@chris1 If you want Windows, Mac, and Linux support, you should look at IfcOpenShell. It offers similar functionality to xBIM as you described your needs above, but is a bit more portable, and can be used in C++ instead of C#, and also offers Python bindings. It also uses OpenCascade.

IfcConvert is a light wrapper on top of IfcOpenShell.

There are many other utilities included with IfcOpenShell that are not advertised on the homepage, including IfcCOBie (to and from COBie spreadsheet templates), IFCCSV (partial data export and import of IFC to and from CSV), IfcDiff (comparisons between IFC files), IfcPatch (execute predefined templates to modify IFC data), IfcClash (clash detection in IFC), … etc, they are all also cross platform.

Going through Blender is not necessary nor recommended.

Most BIM authoring programs treat IFC as a monolithic import and export procedure with very limited capabilities to import or export portions of the model or IFC data. They do not stream data, nor write diffs. An export for a complex project may take an hour. An import will take another hour.

Any conversion of IFC into a raw geometry format (e.g. OBJ) will lose a huge amount of data, as OBJ cannot capture the same depth of metadata and relationships that IFC can.

Methods to mitigate this data loss include converting an IFC into two formats, a geometry format (e.g. OBJ, glTF, DAE) plus a data format (e.g. XML, JSON), which are correlated on the client-side (web, Unity, etc) at runtime.

Might I convince you otherwise? :slight_smile: IFC can store this data and it is the perfect place to store it!

A word of warning that some BIM authoring platforms do not maintain these IDs correctly. For example, in Revit, IfcZones created from rooms (can be important in environmental calculations) have a new ID generated with every export. Another example is IfcDistributionPort objects. I also warn that some BIM autohring programs don’t expose the ID very easily within their native interface.

2 Likes
19

Dion explained the workflow very well

Just an extra information that shad some light:
For LCA and LCC you don’t need to convert all data/information (especially semantics) into Unity
Process IFC data/information on backend/server-side and just mount results on “presentation” geometries on Unity

I mean you don’t need calculate everything on Unity after parsing all data/information into it, you can use IFC for processing

20

Thanks for you input, @Moult. It looks like IfcOpenShell is the way to go. You also mentioned Speckle earlier – I’ll have a closer look at that later to see if that could improve the data transfer time.

Yes, definitely. All the new material data from the LCA app might as well be stored in the IFC file. But is there a good way to send that extra material data back to the building app? It is possible to create a new project from an IFC, but importing the new material data into the existing project would be ideal.