There is a lot of facets to this problem, which I also recognize in the field.
On the matter of ‘harm’
I would say it solely depends on the necessity of this geometric detail. Unnecessary weight is harmful, necessary weight is, well, necessary.
- Necessary when no more efficient representation is available in the schema or model view, vs
- Unnecessary triangulation of e.g a planar surface (I’ve seen both)
Or information wise:
- Necessary representation of actual features that affect downstream use, vs
- Undesirable level of detail (e.g 10x more faces for a 0.1mm fillet radius, engravings, …) But this depends of course on anticipated downstream use.
I agree typically these detailed elements come from manufacturing catalogi where not every geometric feature needs to necessarily be mirrored in IFC. These are not elements manufactured on site according to the specs in IFC.
Efficiency of format
We’re exchanging information in this text based STEP / SPF format and it is not suitable for large lists (e.g OBJ is also text based, but more easily streamable, and specific purpose; more modern text based formats will typically also put the size up front so that you know what to allocate).
People have also discussed offloading geometric representations to more standard formats (specifically in the IFC-JSON group).
We have looked into STEP HDF5 (ISO 10303-26) and this is one of these cases where it is unambiguously useful. But overall the perspective in the community is I think that for investing time in a brand new binary format there are other challenges that we expected to be addressed (partial / incremental exchange, modern platforms, HDF5 is very desktoppy).
Ways of going forward
I think it makes sense to propose to add something to the validation service (validate.buildingsmart.org) to warn users about excessive geometric detail. There is plenty of geometric measures we could use. For inspiration read e.g here on the cost strategies for mesh simplification CGAL 5.5.2 - Triangulated Surface Mesh Simplification: User Manual This would be a quick solution to at least gather awareness and information on this problem. So that we have insights on how to enhance the specification to alleviate this issue.
There currently isn’t a way in IDS or mvdXML to impose limits on the number of facets in a geometry. But using any of the existing APIs and Toolkits it’s rather straightforward to detect the issue.
Regarding digital twins, there is likely other harmonization measures that need to be put in place before ingesting IFCs into a system. Harmonize exporter differences and properties, making sure that element categories are consistent and have the appropriate data. Again, using any of the APIs available, it should be pretty straightforward to apply mesh simplification (see above) or simply substitute the element with a bounding volume to create a lighter copy of the model to ingest into the digital twin. That’s at least the approach we take with our clients: asking the supplier to fix issues is time consuming and frustrating for everybody involved, some quick data massaging is much more streamlined.