As buildingSMART Spain, we recently published an analysis about IFC5’s development path (available at: The Evolution of IFC: The path to IFC5 - buildingSMART Spain). Following this publication, we received valuable technical feedback from our community that we’d like to share with the broader buildingSMART International community for discussion.
The feedback comes from an experienced IFC implementer, who shared these insights:
"I want to congratulate you, David, on your excellent analysis in the article. You have accurately captured the challenges faced by current versions of the IFC format, as well as the challenges that IFC 5 format must overcome to advance interoperability and efficiency in BIM workflows.
It is a great insight that modularity is proposed as one of the key principles for the evolution of the IFC format. I want to add that an efficient possible solution would be to transform the format into a compressed file containing multiple specialized sub-files, such as one for geometry, another for object properties, among others. This approach would allow optimization of both data creation and querying, adapting to various user needs.
Regarding geometry, although for those of us working on standard implementation it would be ideal to directly handle triangulated meshes, we must recognize that it is not practical. This would generate unmanageably large files. One of the great virtues of the STEP standard, which inspires IFC, is its ability to describe complex geometries, with thousands of vertices, in very few lines of text. This is a balance that we must not lose sight of.
Finally, I hope that the new IFC format does not opt to define different structures for each category of construction element, as currently happens with hundreds of specific definitions. It would be more efficient and sustainable for all elements to share a single general definition, in which one of their properties is the category to which they belong. This would ensure that format readers can remain functional even when new categories are incorporated in future updates. This change would be key to improving the format’s longevity and adaptability."
Key points for discussion:
Modular file structure proposal
Geometry handling considerations and efficiency
Unified element definition approach
We welcome the community’s thoughts and insights on these suggestions, particularly from those involved in IFC implementation and development.
Here are some immature opinions:
Triangular meshes or surface feature-based structures such as Brep are sufficient to realize the transfer of geometric features. Further development is very difficult.
There is no consensus on the standard of parameter-driven geometric models in the modeling and BIM software I use.
ArchiCAD essentially uses GDL to implement complex parametric models.
Revit and Catia support parametric models based on constraint systems and model trees. We may be able to introduce the latest STEP standards such as STEP242 to achieve lossless support for geometry created by such systems.
SketchUp has its own “dynamic component” system.
Most parametric models in Rhino are implemented using visual parametric nodes (Grasshopper), which may be a nightmare for the standardization of transferable parametric models.
If possible, can our parameter-driven geometry be implemented in a common standard based on a method similar to javascript driving html? If there is a common language and conventions for binding variables and IFC attributes in language codes, these things may become simpler.
I think IFC modulation is super important and I am dedicated to thinking about it. On the one hand, large infrastructures generate very large files (GB of data), making it impossible to view the stakeholders in a CDE and validate the project. On the other hand, the fragmentation generates substructures for the execution of works, budgets, planning… generating a central federalized file with disciplines and the like. I have invested in Blockchain technologies to support the development of more complete “model view definitions” (MVD). What are the recommendations for scientific files to support future research associated with IFC 5 modulation and BlockChain?
@ArchiBC, Even if the geometry is produced with tools like Grasshopper, the parametric script is still ‘baking’ a usual mesh/brep geometry representation in Rhino model, which could be reflected in IFC5.
Parametric geometry can be added, but the mesh representation is a key for fast and reliable rendering. Each object can have more than one geometry representation depending on the needs.
@Dean, standard mvd’s are no longer desired, and you can read more here: The curious case of the MVD - buildingSMART International. When it comes to blockchain, I don’t considered it relevant to IFC5, but since IFC5 is all about data exchange, I imagine you could consider blockchain technology for facilitating the data exchange. Personally, I don’t see great value in distributed peer-to-peer transactions in this use case, as construction projects usually have clear stakeholder relationships with established central party and mutual trust.
For parametric geometry, I might be more concerned with the transfer of design ideas and design logic than with the complete transfer of shapes to other software.
Thanks for the tip, I’m going back and taking the time to study this course seriously.
We could in theory imagine the parametric descriptions (which are native to the authoring software anyway as indicated above) to be embedded alongside the fall-back baked geometry, being encoded as Brep surfaces or triangulated meshes. These native descriptions could be formatted as “code fragments” or linked as an external document reference. But that would only be relevant if the receiving software understands these concepts, which is a use case where native file exchange makes more sense anyway.
The STEP geometry is providing at least a common ground for more elaborate geometric descriptions (e.g., extrusions, sweeps, Boolean operations, clipping, …). With meshes only, we have to pre-assess the needed tolerance and tessellation settings, which can be hard to do, since you are often unsure what the receiving end will use as toolset.
All in all, I don’t expect such an approach to make geometry exchange much smaller, especially when you are (to my current understanding, I could be wrong) obliged to ALWAYS embed tessellated geometry into your IFC5 export, alongside the OPTIONAL other geometric descriptions. This may even increase the amount of information you need to transfer.
A nice feature of the proposed IFC5 structure is that you could split exchange into packages of e.g. geometry (with the triangulated meshes) and other packages with the alternative geometric descriptions and even other packages with e.g., alphanumeric information and semantics.
One of the disadvantages of the current IFC4/STEP format is the fact that you always need to parse the whole dataset.
With IFC5 you are free to split up the model however you want (e.g, separate files for geometry). But unless there are specific conventions in place (filename, some embedded metadata), you still need to parse all parts of an information delivery, since you cannot guess which parts you could skip. So a large part of the advantage may be hard to realise.