Home
WORK IN PROGRESS
While changing the manual delivery processes in AEC, you'll recognize that this won't work out as expected (and promised) by marketing of commercial software vendors. Mostly because they move digital frontiers inside there products (i.e. APIs) and let you play with the mess or because only subset of standards (i.e. IFC MVDs) are implemented. In both cases, you will need transformations of the provided/exported data to get conform to requirements like EIR (or in German: AIA).
So transforming data programatically or by other more declarative ways is a basic need, once you change from only using software to really living in data-centric universe. This need gets once more really intensive
- (A) when short living revisions of models have to be aggregated frequently
- (B) when multiple EIR/AIA requirements have to be fullfilled by the same software vendor application configuration (not every vendor has the same capability to switch seamlessly between different target export configurations)
- (C) when multiple disciplines with different solutions of software vendors produce A's and B's
That's the current state of AEC data mess.
The inital idea of TRex is to programmatically perform those transformations based on the common standard IFC meta model. To perform a transformation, you need an IFC implementation and a geometry engine. There are a few well known implementations (i.e. OpenIFC Shell). Here we use Xbim since TRex is also written on basis of .Net-Framework / .Netcore.
Principle transformation sequence with TRex: (1) export the IFC models in your software solution to IFC2x3 or IFC4 or use the model builder pattern to build an IFC model from scratch (2) let TRex read / use the IFC model (3) programmatically apply different predefined transformation patterns in a sequence and save the output to a new IFC model (4) delivery the final processed IFC model to your client/employer (5) optionally export the model to another model format (currently under development)
Transformations are using an async task pattern as a job. Each job takes parameters. Since some jobs need access to the geometry and scene transformation (base on Xbim Geometry), they are bound to a Windows sub system layout (due to the CLR/CLI bindings to OpenCascade wrappers).
| Class | Description | Win | *nix | state |
|---|---|---|---|---|
| PropertySetRemovalTransform | Remove property sets by black/ or whitelisting | yes | yes | stable |
| PropertyRemovalTransform | Remove property by name or pattern | yes | yes | dev |
| ModelPlacementTransform | Relocate a model by a given transform (offset and/or rotation) | yes | no | stable |
| ProductRepresentationRefactorTransform | Refactor multi-body representations (n-to-one bodies per product) | yes | yes | stable |
| ModelFilterTransform | Filter model by relations, entities and instances | yes | yes | dev |
| ModelMergeTransform | Merge models by common instances and / or common transform specifications | yes | no | dev |