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?

[MatthiasWeise]

@buildingSMARTSpain Thanks for starting this thread, it's well put together!

Regarding the discussion about mesh vs other types of geometry:
I understand and support the goal of agreeing on a simple and robust way of describing geometry.
However, I would like to recall the discussion with the IFC4 reference view, where initially a geometry based on vertices was proposed as a common base (enforced by the MVD specification) and later extended to swept solids in special cases like reinforcement. I don't really see this as a file size issue as IFC already supports reuse of geometry via mapped definitions.

What is your view on this issue and what might be better with the USD approach?

[aothms]

extended to swept solids in special cases like reinforcement

Coincidently, for SweptDiskSolid, USD has a something built in for its (Basis)Curves, because thickness is a not a screenspace-pixel width but a worldspace tube radius [0] (You see this in other areas as well, eg. [1] tube_radius).

The approach we have now with the typespec schema allows us to on a case-by-case basis selectively add behaviour like this to specify the strict subset we need that can be unambiguously implemented.

[0] https://openusd.org/dev/api/class_usd_geom_basis_curves.html#UsdGeomBasisCurves_TubesAndRibbons
[1] https://docs.enthought.com/mayavi/mayavi/auto/mlab_helper_functions.html#plot3d

[nickger]

Absolute must for ducts, pipes, conduits and their insulation. It is a classical example how to blow up IFC x50 - add insulation to the export. These elements do not profit from mapping @MatthiasWeise.

[MatthiasWeise]

@aothms Thank you for the quick answer and pointing me to UsdGeomBasisCurves Class.
Are you planning to add UsdGeomCurves with the Width attribute then (as far as I see it is not part of the schema yet)?

Regarding the features being selected from the USD standard:
Am I right, if UsdGeomMeshComponent is part of IFC5, then all superclasses are included as well (i.e. UsdGeomPointBased, UsdGeomGprim, ...)?
I was wondering about visibility settings in your example. While the visibilty attribute seems to be inherited from UsdGeomImageable, you are using it with Over (which to my understanding is then a specific IFC5 configuration).

[aothms]

Are you planning to add UsdGeomCurves with the Width attribute then (as far as I see it is not part of the schema yet)?

We have curves for the Wall Axis representation and extrusion path:

IFC5-development/Hello Wall/hello-wall.ifcx

Lines 763 to 773 in 2e014f4

	{
	"def": "over",
	"name": "N93791d5d5beb437bb8ec2f1f0ba4bf3b_Axis",
	"attributes": {
	"UsdGeom:BasisCurves": {
	"points": [
	[0,0,0],
	[10,0,0]]
	}
	}
	},

But I agree, it would be good to create a reinforcing bar example to see whether the community agrees on this approach.

Am I right, if UsdGeomMeshComponent is part of IFC5, then all superclasses are included as well (i.e. UsdGeomPointBased, UsdGeomGprim, ...)?

I would say not necessarily. Also for the Meshes themselves there are aspects we are likely not interested in, such as the OpenSubDiv integration. I would phrase compatibility as: when we take data from our IFC5 JSON schema and convert this to USD (maybe even allowing ourselves some flexibility in mapping, we already did some naming harmonization because things in USD are not so consistently namespaced) then it needs to be valid USD. But this subset could be in some cases quite small like disregarding parent classes, only allowing a subset of values, all on a case by case basis.

I was wondering about visibility settings in your example. While the visibilty attribute seems to be inherited from UsdGeomImageable, you are using it with Over (which to my understanding is then a specific IFC5 configuration).

Yes this could also be one of the cases where we allowed ourselves a bit of freedom in this mapping. But also types in USD are quite flexible. Ultimately types are for (a) runtime management of the stage, so you traverse and only find imageble prims for example (b) validation of data post composition (c) default values for attributes. In all these cases it's perfectly valid to have one layer exert the type of a prim and another layer posting an opinion on an attribute governed by that type. So our way of applying an Over for the visibility is not necessarily wrong in USD. Types are not monolithic so to say in USD.

But in IFC5 I think there is more demand for validation on the component level pre-composition.

[MatthiasWeise]

Things are becoming more clear now!

Some more questions related to the current status of IFC5 (alpha):

1. I am seeing specific definitions for alignment, space boundary, etc. Is this an arbitrary selection and just for demonstration purposes or is there a scope definition for IFC5?
2. Is there any semantic implication if I point to an (old?) IFC class as defined in the example below?

"def": "over", "name": "N25503984660543a18597eae657ff5bea", "attributes": { "ifc5:class": { "code": "IfcWindow", "uri": "https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcWindow" } }

3. If the URI can point to any item of an external classification system, where do I find the information about classification system (or do I have to encode from the URI)?

I'm not sure how the harmonisation of features and names is intended, but if the USD definitions in IFC5 are not identical to the USD standard (and we may not have compatibility with existing USD tools), wouldn't it be better to use the Ifc5 prefix instead of Usd?

[aothms]

Is this an arbitrary selection and just for demonstration purposes or is there a scope definition for IFC5?

yes, correct, very arbitrary, just the union of the two arbitrary examples, we should make this clear, because there was already confusion about this when comparing this to the (huge) ifc4.3 schema.

Is there any semantic implication if I point to an (old?) IFC class as defined in the example below?

I think this question hints at topic of whether there is any restrictions applied at the 'entity level'. Can a component enforce constraints on another component when these are part of the same entity.

I think we'll have various levels of schema enforcement:

pre-composition individual layer || post layer composition on component || post entity-component composition on an entity

But also I think maybe bSI will claim less 'ownership' over that and leave that more to IDS. At least that's what I tasted at the impl meeting in Denver. That bSI has been very successful at defining the mechanisms and the terms, but that there are always exceptions to what makes sense as restrictions. E.g It makes 99.9% sense that an Pset_WindowCommon does not have a LoadBearing property, after all how many windows are loadbearing. But one could still argue that making this restriction on the data exchange specification level is (a) unnecessary (b) overly restrictive.

[MatthiasWeise]

yes, correct, very arbitrary, just the union of the two arbitrary examples, we should make this clear, because there was already confusion about this when comparing this to the (huge) ifc4.3 schema.

Ok, thanks for clarification! Is there a discussion about semantics of IFC5 (what classes/features should be part of the core IFC5 and what might be part of later versions)?

I think this question hints at topic of whether there is any restrictions applied at the 'entity level'. Can a component enforce constraints on another component when these are part of the same entity.

I think we'll have various levels of schema enforcement:

pre-composition individual layer || post layer composition on component || post entity-component composition on an entity

But also I think maybe bSI will claim less 'ownership' over that and leave that more to IDS. At least that's what I tasted at the impl meeting in Denver. That bSI has been very successful at defining the mechanisms and the terms, but that there are always exceptions to what makes sense as restrictions. E.g It makes 99.9% sense that an Pset_WindowCommon does not have a LoadBearing property, after all how many windows are loadbearing. But one could still argue that making this restriction on the data exchange specification level is (a) unnecessary (b) overly restrictive.

Isn't this a general challenge for standardisation? ;-)
My concern is that the more agreements we take out of the IFC specification and move to other places like bSDD, which represent national or even project-specific agreements, the less international interoperability we will have.
I am not talking about properties that in most cases are just key-value pairs without additional logic but rather about features that need to be understood by tools in order, for example, to position and visualize elements correctly (local placement, mesh geometry, orientation of a door opening, logical sequence of tasks, etc.).

It is fine to cherry pick features and define additional agreements, which in the end define a well selected subset of standardised features for specific use cases making it easier for implementation. I guess this is what you mean by "defining the mechanism and the terms"(?)

Regarding the load bearing window example:
A main argument for IFC5 is to enforce robust implementations, correct(?).
Would it not be counterproductive to allow exceptions to expected implementations?

P.S.: We may agree on using Pset_WindowCommon.MechanicalLoadRating or to use an element assembly in such cases, which would be in line with the IFC specification.