Technical feedback on IFC5 development - Modularization and structural improvements

Developers IFC5 (alpha)
1

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:

  1. Modular file structure proposal
  2. Geometry handling considerations and efficiency
  3. Unified element definition approach

We welcome the community’s thoughts and insights on these suggestions, particularly from those involved in IFC implementation and development.

Cheers,

David

2

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.

3

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?

4

@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.

You can get familiar with the latest version of IFC5 developments by enrolling to this crash course:
https://ifc5.technical.buildingsmart.org/

@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.

5

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.