[aothms]

This is a difficult question and the the history to all of this predates my involvement.

Indeed, a fair amount of people believe that the IFC is intentionally unnecessarily complex to limit interoperability and retain a monopoly.

Over time, I've come to believe hanlon's razor is also in play here and it's more of a poor understanding of use cases, academic ideas blowing up scope and inheriting obscure schema and serialization tech.

Meshes + metadata can facilitate most of the use cases in industry today, which is coordination, interference checks and visualization.

But at the same time, there's some pretty compelling use of the standard that requires slightly more semantic geometry descriptions:

- calculating geometric quantities according to local norms, which requires some additional geometric knowledge on things like openings and the axis of a wall for example

- The opening direction of doors is often good to know, but this is just a convention on the local transformation matrix, so could be just meshes.

- steel manufacturing can derive quite a bit of information from the IFC geometry, like parametric cross section profiles and where to drill for bolt holes and using which diameter

And then there is the ultimate end goal according to some to be able to exchange all parametric and constraint information from the native model. But this is still quite far out.

The challenge for future editions of the spec is to better align required complexity of certain use cases with a more modular spec so that you depend on a more appropriate amount of complexity.

Btw. since you mention Blender. The BlenderBIM addon https://blenderbim.org/ is actually one of the most avid users of complex and parametric constructs in IFC :)

[onthecanposting]

IFCOpenShell was news to me. Thanks for sharing. You're doing God's work.