CAD object triangulation

Hello,

Some of the IFC files I convert using IfcOpenShell (for a visualisation tool) contains "small" complex CAD objects like the one in the attached picture.

Triangulating this kind of object generate a lot of errors like this :

...
[Error] {0VSPLTvm14jhquXPeYsp0x} Not enough edges for:
#313361=IfcPolyLoop((#288508,#313299,#288453))
[Error] {0VSPLTvm14jhquXPeYsp0x} Failed to process face boundary loop
#313361=IfcPolyLoop((#288508,#313299,#288453))
...

And the generated mesh has a lot of missing faces.

After tracing in the code, it seems that the problem is that the input IFC has a unit
length set to 0.001 (millimetre) and a lot of points for this kind of objects are removed
by remove_duplicate_points_from_loop(polygon, true, eps); (in IfcGeomWires.cpp).

Tweaking the code, I have managed to better a bit the result by commenting this line :
lowest_precision_encountered *= 10.;

in IfcGeomIterator.h (around line 260).

But then I have another kind of error :

...
[Error] {0VSPLTvm14jhquXPeYsp0x} Flattening face boundary
#301902=IfcFaceOuterBound(#301901,.T.)
[Error] {0VSPLTvm14jhquXPeYsp0x} Triangulating face boundary
#307735=IfcFaceOuterBound(#307734,.T.)
...

Perhaps a good solution would be to treat objects with a different kind of precision
level depending of their global dimension ? Or dimension of their smaller shape ?

regards,

    Stéphane              

[aothms]

This is a bit of an unsolved problem.

Perhaps a good solution would be to treat objects with a different kind of precision level depending of their global dimension ? Or dimension of their smaller shape ?

The issue is that when larger and smaller shapes are combined in boolean operations, you can easily get into inconsistencies when the smaller shape detail is in the same order of magnitude as the required 'fuzziness' for correctly resolving face overlap.

You can also check the Precision in the IfcGeometricRepresentationContext, as that's what this global tolerance in IfcOpenShell is based on. Maybe it's simply set too high for this file.

You might also want to check the 0.6 branch with --sew-shells, as that does vertex clustering instead of simply discarding small faces.

Also, the flattening / triangulating face boundary errors should be pretty harmless, but does indicate some problems with the file.

Thank you for the answer,

 I will have a look at the clues you mention.

 regards,

           Stéphane

[aothms]

Actually, I think your proposal of a relative epsilon makes sense, just committed that 20b3a8a

But only for the 0.6 branch (the 0.5 face boundary loop conversion functions don't know the extent of the complete shell) and only with --sew-shells but that will be the default at some point.

Hello,

 here is a far better result of the conversion using branch 0.6 : 

 There are other problems but I don't have clues to solve them at the moment : 

   the same file in BimVision : 

   I think perhaps you can close this ticket ? Thank you for your work on IfcOpenShell.

   Stéphane

[aothms]

It seems like there are issues with the faces with internal boundaries. There is code in IfcOpenShell to fix cases even when the orientation of internal boundaries is reversed. Can you share the file (a) here, publicly or (b) models@ifcopenshell.org privately?

[aothms]

I see now. Actually for the topmost missing face, the inner boudaries (the bolts) are intersecting with outer face boundary. It is disallowed by the standard and currently not supported / checked / fixed.

I will create a new issue to handle this more gracefully. It can probably be fixed with a little bit of boolean operations. But it won't have a really high priority because the IFC standard disallows this.

A face shall have at least one bound, and the loops shall not intersect

http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifctopologyresource/lexical/ifcface.htm

Closing this