Opinion about high polygon count in IFC

Users IFC
1

Hi everyone,
I was wondering how do you deal with IFC deliverables that have geometries out of many polygons, or triangulations. IMHO this phenomenon increases file size since it needs more lines to be written in the schema.

Lately, I have been receiving models from stakeholders that contain geometries made by manufacturers. These geometries are almost 1:1 representation of the actual real element and in many cases have even their logos engraved in them. Some software are capable of detecting these high number of polygons or shapes. Some software, in my experience, even model pipes with tens of segmented surfaces.

Regarding the future development of the schema and the matter of “Digital Twins”, where specific built-in elements should be represented in the model, how is this case of complex geometries handled at the current time, and how is it going to be addressed in the future developments? Is it “harmful” to include such geometries? Should manufacturers get guidelines about modeling their components? Or should this topic be simply ignored, because it does not have any side effects?

Do you have any opinion about this topic?

2

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.

Schema wise:

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

3

thank you @aothms for the detailed explanation.

I am familiar with tools that simplify geometries. I understand this process, when we are dealing with for ex. end deliverables, as you mentioned for the digital twin. But is it appropriate to use such tools during the process of planing/building? At these stages we count multiple datadrops and for each time a process to reduce geometry would be necessary. Why not use from the beginning “dummy” elements to represent that simplified geometry?

I had once a discussion with a facility manager, where he complained that he received a model where the fire extinguishers were too realistic. He simply needed an extruded square with embedded information to it. There are many other situations where the modeling is simply way too precise, but in the end, nobody actually needs it.

I think you have a point there, that maybe it is a subject that should be addressed to the IDS. I think it is currently the best medium to set the definition for both user and manufacturer. Imposing regulations directly on manufacturers would be a rather big challenge. But while having a well-defined IDS, the interoperability could profit and both actors (user and manufacturer) would understand the importance of geometry. Each stakeholder could test their geometries against an IDS to see it if it fulfills the requirements before delivering data. In today’s modeling habits, I am noticing a trend going on, that having way too detailed geometries makes your model look “sexy” and “cool”. These are real quotes :face_with_hand_over_mouth:
Don’t you think the IDS could solve this?

4

I guess because simply because this simplified geometry is not universally understood. The model may be consumed by the client for example in a photo realistic rendering. So the accurate representation in that sense is the most “universal”. Also, I think where we have quite universally understood symbology in 2D, somehow for 3D this never really happened yet. So I can understand the “cool” and “sexy” extinguisher makes it into the model. Also textures are not used a lot, so to realistically represent something you need a high poly count. Anyway, lot’s and lot’s of potential reasons.

I think we should check with the people from Level of Information Need. I know they had plans for Level of Detail/Development of geometries and maybe also worked on means of distinguishing symbolic and realistic representations. @borrmann Any thoughts on this?

Don’t you think the IDS could solve this?

Well, geometry was purposely out of scope for the first version of IDS, because it gets very complex very quickly.

Something like this would be a bit in line with the current idioms in IDS:

<applicability>
    <entity>IfcFireSuppressionTerminal</entity>
    <geometry><facet /></geometry>
</applicability>
<requirement>
    <geometry><facet maxoccurs=100></geometry>
</requirement>

“When using a faceted representation on a IfcFireSuppressionTerminal the max number of faces is 100”. Where facet would automatically map to IfcConnectedFaceSet IfcTriangulatedFaceSet IfcPolygonalFaceSet and count the number of faces in each.

But it’d be very adhoc. But it’s good to gather some of these topics, ideas and use cases for when there is renewed energy for a new instalment of IDS. I noted this one down :slight_smile:

1 Like
5

you are reading my mind :slight_smile:
In this case, the IDS would not only check if the component belongs to an appropriate entity with attributes X and Y, but test its geometrical representation.
Well, one argument could be that IDS is designed to deliver information and not geometry. But from the “language description” point of view, geometry has also textual information for its description.

What are your thoughts @artur_tomczak about this case?
You have been lately working on IDS and developed some interesting results.

1 Like
6

IMO, simplicity is a huge advantage of IDS. I imagine it wouldn’t take off so easily if it was more complex and difficult to implement. The IDS can replace almost all typical PDF/Excel requirements without touching geometry. As @aothms said, geometrical rules get complex very quickly. Also, I can’t think of many use cases for such simple geometrical checks with IDS.

On the other hand, as part of modelling QA, I agree we should avoid redundant geometry (or information in general), and there are ways to do that. Just don’t think this falls within the IDS scope. I liked @aothms idea to consider such functionality at some point in the Validation Service. cc @Evandro

1 Like
7

We indeed “had” plans on describing the geometric information when the EN 17412-1 was published in 2020. Currently, there is work ongoing to expand the requirements on geometrical information in ISO 7817 (to replace the EN 17412 series). However, this is not published yet. Contribution and input from buildingSMART is welcomed and there is a liaison where buildingSMART can actively participate in the work. But then somebody has to jump in and work with the slower pace of standardization work.

Geometry was (deliberately) left out of IDS. I can understand why. So don’t try to force it in there, without proper thought and alignment to other efforts, e.g. at CEN and ISO.

The current approach in EN 17412-1:2020 is to describe geometric information in terms of detail, dimensionality, location, appearance and parametric behavior. Draft work for Part 2 goes into “how” to describe detail. Mostly in plain text, but also being looked at to embed it in an exchange format for Part 3. That exchange format is different from IDS.

Triangle count is just the tip of the iceberg. Right now, you may be better off by looking at MVD and explicitly disallowing Triangulated FaceSets, but then you may not have any software that is ready for that, as they are focused on default MVD Reference View and the older Coordination View, where faceted representations are valid.

Rest assured that we are aware of IDS, but also understand that IDS is not fit to cover all that needs to be covered for “level of information need”. I’m convinced that in the (near) future, an appointing party expressing their information requirements can do so according to the Level of information need standard, possibly using a web-platform or app to collect requirements and that a subset of those requirements can be captured in an IDSxml document, for integration into tools such as BIMQ, Solibri, Simplebim and others.

1 Like
8

I started the conversation to get a general opinion about the usage of complex geometries in IFC. At least we all agree that such geometries should be at best avoided. Some do it better and others don’t.

Maybe there is still no finished solution to this case, but it looks that there is effort being put into. In the current state of the industry, we will keep fighting these geometries with validation tools or even verbally.
Anyway, I appreciate your valuable inputs in this discussion.

9

Define “complex” geometries…

  1. Everything is a mess/mesh… Easy to read, to visualize, GPUs love it. This is e.g. what is inside the dotbim simplified format and is well supported in generic 3D formats (FBX, Collada, USD). But also highly inefficient for any non-planar geometry, as it needs to pre-tessellated into triangles. The tessellation happens mostly with the modeling software, so at the receiving end you get a fixed amount of triangles. Take it or leave it. Subdivision Surfaces have proven a good approach for organic geometry which can be transferred efficiently between software, but there is no support for it in IFC.

  2. Everything is parametrically defined in extrusions, sweeps, NURBS, Boolean operations… but you need a powerful geometric kernel to deal with that. This keeps IFC files compact and the geometry is closer to the source definition and has a higher potential to remain editable (essential for the Design Transfer MVD). This geometry is obviously supported in the model authoring software and is also a necessity for IFC toolkits like IfcOpenShell and IfcEngine and others, to be able to read geometry (and possibly tesselate it for display in a viewer). However, interpretation is more tricky and you get additional translations: from native to IFC and from IFC to the receiving software.

For the “level of information need” standardization work, we only look from the point of view of expressing requirements: what is needed by the receiving actor in terms of geometrical information, alphanumerical information and documentation? Not HOW it will be delivered or in what format. That is a choice and was deliberately left out of scope.

IDSxml clearly focuses on the IFC scheme and the whole format is currently scoped to only cover the alphanumerical information. That is a valid option, but also proves the scope difference of both approaches.

10

It is a long time I am having the idea that IFC should allow more than one Body representation for various quality of surface geometries from draft to fine level of details.

11

Gaming engines like Unity have a “Level Of Detail” system, where multiple meshes can be switched in a viewer based on camera distance. This can be separate meshes or one could use a mesh-reduction algorithm to generate such representations.

I’m not sure having the different detail levels of body representations also embedded in the already large and rather inefficient Tesselated geometry structures in IFC will help in reducing the size and the high polygon count issues… on the contrary.

IMHO, this is more the responsibility of the viewer or analysis software at the receiving end. Most viewers dynamically hide parts of the model, although typically on an element level.

1 Like
12

Sorry about bumping an old topic. But IFC has externally defined styles. I’d love to see externally defined geometries that integrate with things like glB, USD, OBJ…