Design use cases
While a lot of model authoring platforms for Building Information Modelling (BIM) provide IFC export, only few allow customization or even adaption of your own rules and requirements. Most are limited to customization of property sets and properties. The basic intention of TREX is to overcome those issues with the help of open source and to provide open access to the functionalities for model-post-production. Since most civil engineers and architects don't have programming skills (and no time to spend), the initial idea was to bundle complex functions into a visual workflow tooling like Dynamo. The adaption of toolchains is done visually and can be handled by engineers while the processing is hidden (but open sourced) in plugin libraries and is driven by software engineering concepts.
In general the Industry Foundation Classes (IFC) is a reference meta-model with physical representation as STEP21 (through EXPRESS standard) or XML. Once you modify contents and try to save it again, you'll get into naming trouble. It's essential to know which file is the unmodified source and which one is the modified result. Otherwise, once you start later with an already modified file as source, you'll note unexpected results while applying transforms.
TRex introduces canonical names. Each modification (transform) can append its own fragment, such that a source IFC MyIfcFile.ifc will become i.e. MyIfcFile.modified.ifc. Alternatively, you can relocate a IfcModel physical storage location and omit fragments.
The IFC save node exposes an separator in port which wraps a string to separate cononical fragments. If given filenames will generated by canonically defined names otherwise the original filename is taken.
In this case (without separator) use the path relocation node, in order to separate source and target model files from each other.
As a part of the Employeers Information Request (EIR) a commonly agreed reference point is share among all parties. But not all authoring platforms are capable to align the IFC export according to this requirement. So post processing IFCs and post-aligning models given a translation and rotation is required. This alignment takes two source and two target points to compute two reference rays which will be assigned to the X-axes. In general the global Z-axis is directed against gravity (simply upwards).
The whole workflow will load IFCs, apply the alignment and save the modified IFCs either by same name to a different folder, or the same folder but with different name.
There are two modi:
- Either use the existing (root) placements and adapt the change to it. This method will yield a minimal foot print to the modified model but changes existing placements (see IfcObjectPlacement@IFC4)
- Or inject a new common root placement. This option does not change existing placements but will likely produce more new data depending on the count of existing root placements. Furthermore, this option isn't really support by IFC2x3 (although it is also not really forbidden) because of a pure virtual placement without product.
There are different alignment inputs available:
The pure offset alignment will shift the model to another point given by absolute coordinates.
The pure axis alignment will only rotate the current X-axis to the newly defined X-axis.
This alignment constructor takes two source reference points and two target mapping points. All with absolute coordinates.
The axis and offset option will use vector coordinates instead of absolute coordinates.
Example Dynamo Graph with rotation
The filtering is more complex due to the provided options.
-
excludeSetsmeans IFC property set names to be excluded explictly. -
includeSetsmeans IFC property set names to be included explictly. -
caseSensitive, if true upper and lower letters are not the same
If given excludeSets but no includeSets, any set name matching the defintion will be dropped. If given the otherway around, any set name matching the definition will be kept, any other will be dropped. Include will override exclude, if conflicting set names are defined.
Typically site models will be recreated by visualization since the model authoring in design and in visualization are different aspects of the task. TRex provides an export node using Assimp libraries. So at least no geometry has to be recreated. There are over 20 different file formats (i.e. FBX, DAE, GLB ...).
Transformation of the coordinate reference system (CRS) and the model scaling is a crucial step before export a scene. TRex will aggregate the tessellated geometry into an intermediate scene model which is somehow between IFC and pure visualization format specifications. In order to export you'll have to define a CRS transform node and a Unit scale node. Both have to be associated to the original scaling nodes of the intermediate scene model.
The unit scale exposes different predefined units (with Meter as default). Note the nested in port which is <null> by default. Once given, a relative scaling factor is calculated.
The CRS transform node provides options for different global coordinate systems with slightly different meanings for up, forward and coordinate axes. Note also the crs input and offset input. Once another preceeding CRS is given, a relative CRS transformation is computed. If not given RHS-Z-Up is assumed by default. The offset provides an optionally shifted origin of the CRS against which the exported geometry is defined relatively.
Finally, the scene export takes these inputs
It also takes a separator to be used as separating fragment between the canonical parts. If left empty/null, the original filename with the appropriate file extension is taken as full filename.