Technical feedback on IFC5 development - Modularization and structural improvements

[buildingSMARTSpain]

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.

This post is also published on forums.buidlingsmart.org ( https://forums.buildingsmart.org/t/technical-feedback-on-ifc5-development-modularization-and-structural-improvements/5788 ) if someone thinks that is a better place for it. We never know where the right people are for a productive discussion.

Cheers,

David Delgado Vendrell
Technical Coordinator, buildingSMART Spain

[aothms]

Thanks for providing detailed comments. Some random replies from my side:

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.

I think this is covered in the ways we can compose using layers. USD goes a bit further in that you can also package multiple layers as sublayers and do this recursively. In our IFC5 prototypes this assembly currently has to happen manually. I think the flexibility to organize how people want themselves is better than imposing a consistent and strict structure, but it depends a bit on the proficiency of the target group.

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.

It's important not to overlook the interoperability aspects of this. Today in my mailbox was this issue [0], but it's constant. There is currently 0 interoperability expected on advanced brep. [Extrusions are better (also when there is a curved footprint).]

Also, I think this kind claim needs to come with numbers. Let's come up with a meaningful curved geometry and see how it would be represented in binary USD (for example... - but let's not take our current JSON examples as the benchmark).

[0] FreeCAD/FreeCAD#18319

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

Technically speaking, IFC4 is already fully generic. We just have products and these products have a representation and psets. I'm not entirely sure what this aspect is referring to.

[nickger]

With all respect, how can you say that advanced BRep interoperability is not expected..? It has been a shame since the first day of IFC. 99% of building elements are manufactured with usage of mechanical engineering software and full power of their modelling kernels, but as soon as they arrive on a building side, they are dumped to meshes. And 30 years later we do not even expect any changes here..?

As soon as I am here: when finally will systems be implemented as first class objects? Building is not a mechanical assembly it's a system of systems both conceptually and physically, but no schema supports it. Any thoughts in this direction?

[aothms]

Aren't we saying the same thing? Do you still expect things to improve after 30 years?

If I look to other industries, outside of my day to day line of business, I'm under the impression that e.g automotive more or less gave up on vendor neutral exchange between modelling kernels and settled on point to point translators implemented in software due to interoperability issues on concepts like adv brep.

Adv brep beyond the simple cases is a lot of heuristics, implementation detail, I can imagine the pains of trying to standardize upon that.

At the same time, more and more jurisdictions are embedding IFC into legal frameworks, we can't have any of that kind of ambiguity.

But also some nuance: I think the focus being established here is 'reliability/explicit first' and especially this approach also allows for embedding secondary schemas in the exchange where much richer parametric intent can be encoded.

As soon as I am here: when finally will systems be implemented as first class objects? Building is not a mechanical assembly it's a system of systems both conceptually and physically, but no schema supports it. Any thoughts in this direction?

I think this is simply because (a majority?) of modellers sees a BIM model primarily as a bag of objects and not systems of systems. For them modelling systems of systems is simply more work, so it doesn't happen, modelling happens under tight deadlines and there is not a lot of value extracted from the model. Standardization is an attempt to formalize existing practice. There's valid reasons to try and influence this to become a more holistic approach, but it's a touch message to sell in this sector.

[CDETragsa]

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?