The IfcEnvelopeExtractor enables users to automatically extract the building shell of an IFC-model and convert it to a CityJSON model. Automating this process allows designs to be quickly and easily analyzed on a city scale without the need for lengthy manual conversions. This is one of the steps required to close the gap between architecture/BIM and city scale models.
The software is able to extract multiple different LoD (Level of Detail) shells from an IFC-model. The actual LoDs it is able to extract is dependent on the accuracy and validity of the input model.
Current possible output shells:
- Lod0.0 - exterior only
- Lod0.2 - exterior roof outline, footprint, interior stories and rooms
- LoD0.3 - exterior roof structure only
- LoD1.0 - exterior only
- LoD1.2 - exterior and rooms
- LoD1.3 - exterior only
- LoD2.2 - exterior and rooms
- LoD3.2 - exterior and rooms (WIP)
- LoD5.0 - exterior and interior rooms
Current supported IFC versions:
- IFC2x3
- IFC4
- IFC4x3
For the extraction of the exterior shell the tool utilizes three different extraction methods that can be used on progressively more accurate models. Lower detail shells (LoD0.0 & 1.0) can be extracted based on only the vertices present in a model. Middle level detail shells (Lod0.2, 0.3, 1.2, 1.3, 2.2) can be extracted based on the model’s roofing structures. High level detail shells (Lod3.2) can be extracted based on the model’s objects that are part of the building envelope. This final extraction step only functions on well-constructed models, but yields an accurate result that allows for overhang and underpasses. These features are currently in practice only present in models that are made manually.
The extraction of interior shells relies more heavily on the source IFC file and does not scale like the exterior shells. For all interior export (Storeys, apartments/areas and rooms/spaces) a high quality input model is required with additional extra "special" semantic information to help the tool function.
More information about the input requirement can be found at the input requirements paragraph (here).
Below you can see a speed comparison between the software and manual processing of the exterior shell. Note that in this comparison the software creates the exterior shells for LoD 0.0, 0.2, 1.0, 1.2, 2.2 and 3.2 while the manual processing only creates LoD 2.2. This example is sped up 5 times.
This program is part of the CHEK project. Any suggestions, additions or changes that are made by other users could also be utilized by this project.
- How to execute
- How to build
- GUI
- Input file requirements
- Output file structure
- Outer shell generation methods
- Inner shell generation methods
- Settings JSON
- Additional stored attributes
- References
The tool can be used directly with the executables located in the Pre_Build folder. The folder should contain four executables:
- Ifc_Envelope_Extractor_ifc2x3.exe
- Ifc_Envelope_Extractor_ifc4.exe
- Ifc_Envelope_Extractor_ifc4x3.exe
- Ext_GUI.exe
The Ifc_Envelope_Extractor_ifc2x3.exe, Ifc_Envelope_Extractor_ifc4.exe or Ifc_Envelope_Extractor_ifc4x3.exe can be called with a path to a settings JSON file. This file is used to give the tool the needed information related to the IFC model (more info). This enables the .exe to be easily called by other applications. It is important to make sure that the correct executable for the IFC version of the model is used. An IFC4 file will not be processed by the IFC2x3 version of the tool.
If a more direct (human) user friendly approach is desired both the aforementioned .exe can be called with the help of the Ext_GUI.exe (more info).
If it is desired to compile the code locally the following libraries are required:
To set the IFC version of the tool a single line has to be changed. In helper.h the first lines are "#define IfcVersion". The IfcVersion can be changed to the supported IFC versions preceded by USE_. The currently supported versions are: USE_IFC2x3, USE_IFC4 and USE_IFC4x3. Each version creates an executable that can ONLY process IFC files of the version that the executable was created for.
#define USE_IFC4x3 //<- change this line to change supported ifc version
#ifdef USE_IFC2x3
#define IfcSchema Ifc2x3
#define buildVersion "IFC2X3"
#define SCHEMA_VERSIONS (2x3)
#define SCHEMA_SEQ (2x3)
#elif defined(USE_IFC4)
#define IfcSchema Ifc4
#define buildVersion "IFC4"
#define SCHEMA_VERSIONS (4)
#define SCHEMA_SEQ (4)
#elif defined(USE_IFC4x3)
#define IfcSchema Ifc4x3
#define buildVersion "IFC4X3"
#define SCHEMA_VERSIONS (4x3)
#define SCHEMA_SEQ (4x3)
#else
#error "No IFC version defined"
#endif // USE_IFCPlease note that CJT is developed in tandem with the IFcEnvExtractor. So possible version mismatches may occur due to CJT being updated at a slightly different time compared to the IFcEnvExtractor.
IfcEnvelopeExtractor can now also be operated via an GUI. This GUI enables the user to easily change the settings. The goal of the GUI is making the tool more accessible for non-expert users. The GUI is a python based front that automatically generates the Settings JSON and calls the suitable extractor executable.
The GUI can be accessed via two routes:
- In the Pre_Build folder the Ext_GUI.exe will start the GUI. Make sure this .exe is always in the same folder as the Extractor.exe files.
- In the GUI_code folder the python file will also start the GUI. This would require the user to have python installed on their system.
The algorithms in this tool have been developed to work with models created by people who may not be BIM experts. As a result, the tool can accept somewhat unconventional input files. However, To enlarge the chances of success, there are currently some requirements that should be followed whenever possible. The list with requirements for exterior extraction is divided over the three different complexity levels (more info). The requirements per level build on top of the ones of lower levels. This means that for middle level shell extraction, the middle detail requirements + the lower detail requirements are recommended. The requirements within one level are listed in order of importance.
These levels only apply to LoD models that are build WITHOUT interiors. If interior generation is enabled the requirements from all levels (low, middle and high) and the additional interior shell requirements have to be met.
Lower detail shells (LoD 0.0, 1.0 & voxel shells):
- Valid IFC4x3, IFC4 or IFC2x3 file
- Valid units
- Correctly classified objects* (recommended)
- No or limited use of IfcBuildingElementProxy objects (recommended)
- Site and building structurally separated (recommended)
Middle level shells (Lod 0.2, 1.2, 1.3, 2.2):
- Correctly modelled and watertight roofing structure
- No or limited use of triangulated objects (recommended)
High level envelopes (LoD 3.2):
- Correctly modelled and watertight building exterior
Envelopes with interior data:
- Correct IfcBuildingStorey use for storey creation
- No or limited use of "half storeys"
- Correct IfcSpace use for space and apartment creation (both semantically and geometrically)**
Performance of the tool is depending on the complexity of the input model. The tool has proven to function well on simple models in the current state but can struggle on more complex shapes.
*Default behavior of the tool is using the room bounding objects presented by Vaart et al., (2022) as space dividing objects. These objects are IfcWall, IfcCurtainWall, IfcWallStandardCase, IfcRoof, IfcSlab, IfcWindow, IfcColumn, IfcBeam, IfcDoor, IfcCovering, IfcMember and IfcPlate. If default settings are used it is recommended to have these object correctly classified in the file. Additionally added types would require the additional type to be correctly classified as well.
**Note that software like Autodesk Revit natively has some issues that can prevent it from doing this properly,
The output files are CityJSON format compliant but might follow a different structure than is usually encountered. Every object that represents a building is split up in 2 building parts: The "Outer Shell" and the "Inner Shell". The "Outer Shell" follows the regular structure that is often seen in established city scale models. It is populated with the different exterior LoD shells. The "Inner Shell" is, depending on the process settings and input file quality, split further over storeys, apartments and rooms.
Below the structure of the file can be seen.
CityJSON File
└── Building Object*
├── Outer Shell
└── Inner Shell*
└── Storey**
└── Space/Room***Object that does not directly store any geometry.
**Depending on the quality of the input, the nature of the input and the user settings these objects can occur many times.
The lower level LoD shells are created based on a subset of vertices of the model. This subset is collected from the IfcWall, IfcWallStandardCase, IfcRoof, IfcSlab and IfcWindow objects. A set of incrementally rotated bounding boxes is created to encapsulate these vertices. The bounding box with the smallest area is converted to the LoD 1.0 envelope. The ground surface of the bounding box is isolated and converted to the LoD 0.0 envelope.
Middle level detail shell (Lod0.2, 1.2, 1.3, 2.2) can be extracted primarily based on the model’s roofing structures. These roofing structures are isolated in two steps. The first step is a coarse isolation which is done via column voxelization. The second step is a filtering of the isolated objects via a column-like ray casting process. This will result in a collection of roofing surfaces.
To construct the LoD 0.2 and 1.2 shell these surfaces (And their vertices) are all projected to the xy plane and merged in one single surface. This surface can be converted to the LoD 0.2 shell. To get the LoD 1.2 shell this surface is extruded in a positive z-direction to the max z-height of the original model.
To construct the LoD 1.3 shell all the filtered roofing surfaces are also projected to the xy plane, but not merged. Instead every surface is translated back in the z-direction to the z-max of their original surface shape. These translated shapes are extruded in a negative x-direction towards the xy plane. The resulting solids are merged and converted to the LoD 1.3 shell.
To construct the LoD 2.2 shell all the filtered roofing surfaces are extruded in a negative x-direction towards the xy plane. The resulting solids are merged and converted to the LoD 2.2 shell.
The high level shells (Lod3.2) are extracted via a voxelization system that is refined by ray casting. The voxelization process is inspired by the room growing process described by Vaart et al., (2022). The starting point is a voxel that is outside of the building. Every object that intersects with the growing shape is stored. The surfaces of each found object are then filtered with the help of a ray casting system which casts rays from points on each surface to the center of the exterior voxels. The found objects are merged into the LoD3.2 shell.
At this moment in time this extraction method does not yet return solids.
Additionally the tool will also be able to export a shell based on the voxelgrid that is used in the other processes. This will be stored as LoD5.0. Note that this is a voxelgrid that is used primarily for filtering and raycasting purposes. Possibly this will follow different rules than are anticipated.
THIS EXTRACTION IS NOT YET PROPERLY IMPLEMENTED; THIS SECTION WILL NOT BE COMPLETELY ACCURATE.
Inner shell creation relies heavily on both geometric and semantic data in an IFC file. This means that for (somewhat) reliable interior extraction the model has to be constructed in an accurate way.
For storey extraction the elevations and related objects of IfcBuildingStorey objects are used. The related objects are split horizontally 50 cm above the storey's stored elevation. their outlines are projected on a horizontal plane and used to split this plane. The resulting outer wires of the split shapes are collected and converted into surfaces.
For space extraction the IfcSpace Objects are processed according to the LoD framework. For LoD 0.2 the top surfaces of the space objects are isolated, projected to the room's lowest z-height and merged into a single surface per room (if possible).
The isolated room top surfaces are also used for LoD1.3 and 2.2. For LoD2.2 these surfaces are kept at their original height but extruded downwards to the room's lowest z-height to create solids. And for LoD1.3 these surfaces are first flattened and extruded downwards.
The extraction of LoD3.2 space shapes is a 1:1 conversion of the IfcSpace geometry.
LoD5.0 space shells are created by using the voxelgrid but instead of growing from a point that is presumed to be exterior it is started from points that are presumed to be interior. The resulting shape is than compared to the pool of IfcSpace objects in the model to find its correct space name and other semantic data.
Due to the heavy reliance of the IfcSpace objects there is, aside from LoD5.0 export, no space export if the model has no IfcSpace objects present. The LoD5.0 spaces will be abele to approximate the space's shape but they will only have generic semantic data stored.
Method still in development
The settings json has a very simple structure. An example can be found below:
{
"Filepaths": {
"Input" :
[
"path to IFC file",
"Potential path to other IFC file"
],
"Output" : "path to export (City)JSON file"
},
"LoD output": [
5.0,
0.0,
0.2,
0.3,
1.0,
1.2,
1.3,
2.2,
3.2
],
"Voxel":{
"Size": 1,
"Store values" : 0,
"Logic" : 3
},
"IFC": {
"Rotation" : false,
"Default div": true,
"Ignore proxy": true,
"Div objects" : []
},
"JSON" : {
"Footprint elevation": 1,
"Footprint based" : 0,
"Horizontal section offset": 0,
"Generate footprint": 1,
"Generate roof outline": 1,
"Generate interior": 1,
"Georeference" : 1,
"Merge semantic objects": 1,
},
"Generate report": 1,
"Threads": 12
}The json has mandatory and optional inputs. If the mandatory inputs are missing the process will not execute properly. If optional inputs are missing a default value will be used.
Mandatory:
- The "Filepaths" "Input" is an array including 1 to ∞ input paths representing all the files constructing a single building.
- The "Filepaths" "Output" is a string representing the output filepath.
Optional:
- "LoD output" is an array including the desired LoD output. The options are 0.0, 0.2, 1.0, 1.2, 1.3, 2.2, 3.2 and 5.0 (for a voxel shape). Default value: 0.0, 0.2, 1.0, 1.2, 1.3, 2.2, 3.2.
- "Voxel" "Size" is a double that will be used for the extraction process. A value between 0.5 and 1 often suffices for normal buildings. Default value = 0.5.
- "Voxel" "Store values" is an int/bool (either 0 or 1) to enable the computation and storage of general shell summary values based on the voxelized shape as semantic attributes. Default value = 0.
- "Logic" is an int (either 2 or 3) that can toggle between the logic used for voxel intersection. 2 = 2D/plane intersection, 3 = 3D/solid intersection. Default value = 3.
- "IFC" "Rotation" is an bool OR double value that indicates a custom rotation of the input shape before processing. If bool false is used as input the tool will automatically compute the optimal rotation. Default value = false.
- "IFC" "Default div" is an int/bool (either 0 or 1) to set if the default space bounding objects are used. Default value = true.
- "IFC" "Ignore proxy" is an int/bool (either 0 or 1) to tell the tool to use IfcBuildingElementProxy as a space dividing object class. 0 = no, 1 = yes. Default value: yes
- "IFC" "Div objects" is an array including the additional space dividing objects (the Ifc types). Default value = empty
- "JSON" "Footprint elevation" is a double that will be the level at which a horizontal section will be taken of the building. This section is used to create the footprint from. Default value = 0.
- "JSON" "Footprint based" is an int/bool (either 0 or 1) to enable footprint based shape creation for LoD1.2, 1.3, and, 2.2.
- "JSON" "Horizontal section offset" is an double that dictates how much the footprint and storey sections should be offset from the found/submitted elevation. Default value = 1.2.
- "JSON" "Generate footprint" is an int/bool (either 0 or 1) to enable the footprint export for LoD0.2. If off the roof outline will be placed at footprint level
- "JSON" "Generate interior" is an int/bool (either 0 or 1) to enable interior shapes to be stored to the exported file.
- "JSON" "Generate roof outline" is an int/bool (either 0 or 1) to enable the roof outline export for LoD0.2
- "JSON" "Georeference" is an int/bool (either 0 or 1) to enable the Georeferencing. Default value: true.
- "JSON" "Merge semantic objects" is an int/bool (either 0 or 1) to enable semantic objects to be merged if they have identical attributes. Default value : true
- "Output report" is an int/bool (either 0 or 1) to set the tool to output a report file or not. 0 = no, 1 = yes. Default value = true.
- "Threads" is an int to set the maximum allowed threads to be used. Default value = hardware_concurrency according to std::threads.
more options will be added in the future.
The CityJSON output can be properly georeferenced if the input IFC file has a proper georeferencing. For IFC4 the method described here is adhered to. For IFC2x3 a custom method is apply that is used by the ifcgref tool. If these methods are not followed the output JSON is either not georeferenced or incorrectly georeferenced.
The EnvExtractor allows the voxel shell to be used for the approximation of a set of building output variables. Current computed values are the:
- Shell area
- Basement shell area
- Building shell area
- Footprint area
- Facade opening area
- Shell volume
- Basement shell volume
- Building shell volume
These attributes are prefaced with "Env_ex V" to highlight that these values are approximated utilizing the voxel grid. The accuracy of these variables are heavily dependent on the size of the utilized voxels and the shape of the buildings. If the proper voxel size is selected the volume approximations and the footprint area can be very accurate. However, the shell area computations area extremely unreliable regardless of the input variables.
van der Vaart, J. A. J. (2022, June 6). Automatic Building Feature Detection and Reconstruction in IFC models. TU Delft Repositories. Retrieved March 30, 2023, from https://repository.tudelft.nl/islandora/object/uuid:db6edbfc-5310-47db-b2c7-3d8e2b62de0f