No check for IfcFaceOuterBound.Orientation when used in IfcClosedShell

[civilx64]

(Discovered by @RickBrice) - The Validation Service (v0.8.4) does not flag an issue with IfcFaceOuterBound.Orientation when used to describe an IfcClosedShell. Specifically, the Orientation attribute is used to indicate if the sense of the face normal is the same or opposite of the solid normal (pointing from finite to infinite).

A sample model exists; however it cannot be shared publicly at this time.

[aothms]

It is accounted for in the code, curious what the issue is.

ifc-gherkin-rules/features/steps/utils/geometry.py

Line 75 in 15c3aa6

loops = [(b.Orientation, b.Bound) for b in filter(is_a("IfcFaceBound"), deps) if b.Bound.is_a('IfcPolyLoop')]

https://github.com/buildingSMART/ifc-gherkin-rules/blob/main/test/files/GEM/gem001/pass-gem001-bound_orientation.ifc

[RickBrice]

I think the code handles it correctly (reverses the normal if Orientation = False).

The problem is that the example file has Orientation= True and all the normals are pointed inwards. That issue is not detected.

I'll send you my analysis and the example file privately.

[aothms]

https://xkcd.com/2403/

>>> import ifcopenshell, ifcopenshell.geom
>>> f = ifcopenshell.open(...)
>>> sett = ifcopenshell.geom.settings()
>>> sett.set('iterator-output', ifcopenshell.ifcopenshell_wrapper.NATIVE)
>>> min((elem.volume(), elem.guid) for elem in ifcopenshell.geom.iterate(sett, f, num_threads=12))
(-30.541096083161595, ...)

(returns the exact same element from your PDF)

So for GEM001 we only looked at the combinatorial rules in IfcConnectedFaceSet which only govern topology, an infinite solid outside of the shell, which is what reversed orientation represents, is fine.

But looking a bit deeper. ManifoldSolidBRep does require the volume to be finite so this is indeed disallowed. We can add a new rule that requires outwards orientation of solids.

https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcManifoldSolidBrep.htm

I don't think we can do this now in a new rule though as our window of opportunity for that for this year is pretty much gone. This is well understood stuff, but there is a small complication. I think you really only want to do this after you have checked for combiantorial validaty (GEM001) and no self-intersections (disabled?), because before that checking for this independently is just weird (not wrong per se), we don't have this kind of rule dependency currently well tested (I have a prototype though).

Thanks for reporting, Rick.

[RickBrice]

A bit more background - this is related to our discussion at IfcOpenShell/IfcOpenShell#7734

I applied the mesh decomposition code to the bridge deck geometry. I was getting the bottom surface instead of the top surface. After digging it, the root cause was the direction of the surface normals.

Checking for the negative volume alone isn't enough. No self-intersections is a prerequisite. Also a prerequisite is that polyloops must have the same winding direction so common edges are traversed in opposite directions.

[aothms]

I was getting the bottom surface instead of the top surface.

Hm yes that's also due to my choice to use max((v + normal).z for v in verts) whereas maybe avg(v.z for v in verts) instead would have been less dependent on orientation.

Checking for the negative volume alone isn't enough. No self-intersections is a prerequisite. Also a prerequisite is that polyloops must have the same winding direction so common edges are traversed in opposite directions.

Agreed: So that's GEM001 + Self-intersection + Positive volume

[civilx64]

So for implementation this would involve additional logic (scenario) added to GEM001, correct?

[aothms]

No I wouldn't add new scenarios. Just a new GEM rule "Outwards orientation for solid boundary representations". Self-intersection we essentially but disabled.

[civilx64]

@RickBrice fyi we have assigned a new rule code GEM012 for this check and have it on the development backlog.