The IFC file format gives its users flexibility in the description of buildings and their building equipment. However, errors, misinterpretations or inaccuracies can easily creep in. These pose challenges for tools with IFC support and make smooth planning in the Open BIM workflow more difficult.


DIALux evo is also affected by this, but tries to import IFC models as completely as possible. This will not be possible for all IFC models. Some are simply too large and exceed the computer's resources or basic rules have been violated in the construction of the model. The data quality varies greatly.


This page is intended to provide a few tips on how an IFC building model for DIALux should be structured so that it can be imported into DIALux more successfully. Documentation on the IFC data model and its IFC objects can be found here:

1- DIALux specific requirements for an IFC model

  • If the IFC model does not define a building, the IFC import is cancelled. This means that, as a minimum, an IFC file should define the building with a storey including external walls and internal walls in order to be able to determine rooms from it later.

  • If the IFC model only contains site information without a building model, a trick can help. Draw in a small building with a single room. DIALux then accepts the IFC model and tries to read it in. This restriction will be removed in future as a result of our further development.

  • In order to successfully import a building including building openings and roof construction, the following IFC types must be combined in a single IFC file.

    - Site (optional)

    - Building and floor,

    - Exterior walls,

    - Interior walls (to determine rooms),

    - Windows and doors,

    - Roof constructions with skylights

    If these types are combined in a file, DIALux attempts to import the building model. This is necessary because DIALux evo 12 can currently only process one IFC file.

    It is often the case that different aspects of a building model are split across several IFC files. This is intentional in the Open BIM workflow. However, IFC tools can usually merge several IFC files into one and save them again (merge). Such a merge is currently still required. We are working on merging IFC files.

Which IFC formats are supported?
DIALux supports the IFC file format in version 2x3. New from DIALux evo 12 is also partial IFC 4 support. IFC 4 introduces a new description of 3D geometry. We do not yet fully support this new format. 

However, there are enough cases in which IFC 4 files fall back on the description format of IFC 2x3.The combination of an IFC 4 file with an IFC 2x3 geometry format is imported.This is important to know in order to export the appropriate IFC version for DIALux in the IFC tools.

2 - Tips for creating a compatible IFC model

These points relate only in part to DIALux, especially to the working method in other IFC tools. At DIALux we have gained a lot of experience in the quality of IFC models. Due to our high number of users, we receive many models from the market. There are very good and compliant IFC models that load well, but also less good ones. 

This is partly due to the way the designer or planner works, but also to the IFC conformity of tools. The following aspects are particularly important when designing:

About accuracy

  • Open BIM with IFC relies on the virtual construction of a building and requires the same level of accuracy as a real construction.

  • Walls should not float, but should be constructed to butt joints with the floor and ceiling. (accurate to the millimetre)

  • Walls that touch should also be constructed to butt joints. If there are gaps, these are also imported and displayed as such (accurate to the millimetre)

  • Components that penetrate other components or protrude into them are imported and displayed by DIALux in this way

  • Windows and doors are usually located in exterior or interior walls. The required wall opening can thus be reliably determined.

  • Storey floors or ceilings should be defined

  • The assignment of building part and topology should be consistent. For example, windows that are physically located on storey 3 should not be assigned to storey 1 in the IFC model. Such incorrect assignments are very common. We suspect that this happens when drawing the model. Whenever objects are supposedly displayed incorrectly, this may be due to their assignment. It often turns out that the physical position does not match the topological position.

           If an IFC model does not guarantee the above points, this manifests itself in various disadvantages in DIALux:

  • Performance problems increase

  • Storeys have no floors or ceilings

  • Rooms are poorly recognised as such

  • The calculation accuracy decreases

  • the visualisation becomes unattractive

  • visualisation problems increase

  • There is a lack of information on statics, material quantities, insulation, etc.

About windows, doors and wall openings
DIALux determines the corresponding wall opening for each window. Other CAD programs do not always do this, which is not wrong per se. If a concrete shell wall is constructed, it usually has an opening for a window or door. A window manufacturer provides IFC information on the window, but not on the necessary wall opening. IFC models should clearly define the relation of the wall opening to the window (door). If windows and doors are moved in DIALux, wall openings are moved at the same time. If these references do not exist in the IFC model, wall openings cannot be moved without errors.

About materials and colours

It can happen that colours and materials look different between the CAD programs and DIALux. DIALux with its light calculation evaluates information on the reflection of surfaces in the IFC model. Colours look paler in DIALux, for example, because the reflection is included in the representation. In principle, this information is determined from the IFC model.

During IFC import, however, you can decide whether the reflectance values from the IFC model should be overwritten by the reflectance values in the DIALux settings. For normative verifications, the usual standard reflectance values can be set during import.

We have found that CAD programmes sometimes add textures and materials to the representation. When importing, DIALux is strictly orientated to the information it finds in the IFC model.

About the correct use of IFC types

Planners, architects and draughtsmen who create an IFC building model have it in their hands to use the correct IFC types. If, for example, sanitary facilities (IfcSanitaryTerminal) or lights (IfcLightFixture) are designed in the CAD programme using the furniture tool, the result is IFC furniture (IfcFurniture). 

DIALux analyses the IFC types when importing and classifies the entire IFC model according to these types. If types are used incorrectly, the affected objects have no recognisable function in DIALux and are not correctly taken into account for connections and power calculations.


For DIALux evo, for example, it is very important that windows are also defined as windows (and not as walls or furniture), as otherwise the influence of daylight cannot be calculated correctly. Facade curtains (IfcCurtainWall), which are actually window fronts, are also frequently constructed.

Which IFC types are supported?
DIALux attempts to import and display all IFC objects of an IFC model. From DIALux evo 12 onwards, information from other trades such as HVAC, sanitary installations or the electrical installation is also imported and displayed. For each IFC object in the model, it is checked whether it has a 3D geometry including material properties. If it has one, DIALux displays it at the right place in the building model.

Which IFC objects are not supported?

  • IFC spaces (IfcSpaces)

In practice, IFC spaces are unfortunately not always designed precisely enough for DIALux to recognise rooms without errors. DIALux therefore relies on its own mechanism for recognising rooms. IFC spaces contain relevant information that is important for a later IFC export with a description of the lighting system. We are working on importing the IFC spaces correctly.

  • IFC content in 2D context

The IFC file format also recognises various objects for displaying content in 2D, which are defined for a floor plan, for example. The IFC import currently only focuses on 3D content and initially ignores the 2D context. This will be supplemented by further development in the future

3 - Models cannot be imported despite the above points

If an IFC model cannot be imported despite observing the points listed above, the following information may be helpful.

  • IFC models can be too cumbersome for DIALux and/or the computer?
    Basically, the more complex the IFC model, the greater the impact on performance when working in DIALux. If DIALux cannot import a building model, there are ways to reduce the complexity.

    - The content of the IFC model is reduced. DIALux does not force anyone to plan an entire building. Especially if it is very complex. An IFC file can also contain only a partial model of a building, e.g. only one storey etc. The building is thus divided into several IFC submodels.

    - As of DIALux evo 12, a wizard can be used to select which information is to be imported from the IFC model. The entire building structure (Spatial structure) with all storeys and their contents is listed here. Planners can simply deselect entire storeys or only contents within the storeys. It is thus possible to import buildings without building equipment or furnishings. Even windows and doors can be deselected in order to calculate only the artificial light in closed rooms. 

4 - Helpful export settings in CAD programmes

Geometry BREP 

DIALux prefers geometries as BREP (Boundary Representation, description of objects by their boundary surfaces). Evo copes better with non-triangulated surfaces. The surfaces should be correctly oriented and form a closed volume, which unfortunately is not a matter of course in many CAD programmes. If the CAD programme allows export settings of this kind, this supports the import into DIALux.

  • Multi-layer construction elements: These building elements should not be separated into individual objects.

  • Elements in Solid Element Operations: Yes, as BREP

  • Elements with connections : Yes, as BREP

  • Slabs with inclined side face(s): Yes, as BREP

  • IFC terrain information: Yes, as BREP

  • IFC site location: at the project origin