It came to my attention in one project that the IfcOpening for door and windows is showing me strange geometries. It happens only in curved walls where these openings are defined. So the IfcOpening does not have a shape of a bounding box, but it stretches to the center of the walls curvature:
I could not find any description in the documentation that this stretched geometry is possible or even allowed.
Is this OK? Anyone experienced problems with such geometries?
You’ll have to talk to the Archicad Tech/Customer Support about that. It looks like that is the “cutting geometry” of the opening in the wall. Since the faces of the cutting geometry can’t be co-planar to the opening itself (my understanding is that it’s about the math and geometry kernels), they extend past the wall faces. How that is determined is up to each vendor. In the past, I believe there was a “gentlemens’ agreement”, not even an official Implementation Agreement, on how far the geometry should extend.
I did contact the tech support from Graphisoft before coming to this forum.
They state, that it is an intentional behavior for such wall geometries and that this geometry does not have to be exact since it has to be parsed and cut from the wall (other applications).
The geometry looks visually wrong, but on the other side it has also incorrect values about its properties. As you can see below, it shows the total length and the surface of this stretched shape.
Concerning quantities, if you want to get the quantities of an IfcOpening I would expect you want to get it in the context of the wall (or floor or other object) it is subtracted from. I would advice to always get the quantities from an opening by applying a 3D intersection of the wall (or other object) without openings and the geometry from the IfcVoid / IfcOpening. Especially in curved walls the openings are (almost) always larger than the resulting opening, this to reduce the geometric artifacts from potential difference in segmentation from the opening curves and the wall curves. Also note that openings (as well as walls) can exist of a set of objects / layers that partially intersect, so a union of these objects is required before applying the intersection.
We’ve had it in the past within AC23 too. We assumed it was an authoring problem but didn’t contact the support service. We solved it by modifying the base wall curve into line segments.
We recently had this problem with curved walls from Archicad 23, where the opening geometry became visible as these elongated “spikes” when using the IFC file in Revit (they became “generic models”). Solibri and other viewers didn’t show these (as they hide opening geometry anyway).
As Peter explained: robust Boolean operations require sufficient overlap and preferably geometry that goes well beyond the edges of the object you intend to cut out. In Archicad, you don’t manage this overlap/extension directly, as the opening is managed as an object via its main size and contour. But with IFC export, they need to turn the opening geometry into actual BRep (I guess).
On second inspection, noticing that the cutting geometry represents a radial shape, where the resulting opening jambs are perpendicular to the curve at the points they intersect. This would then force the jambs/frame of the window to be non-orthogonal to itself. Isn’t this wrong in reality? If I were to construct this, the window unit(s) geometry would always be orthogonal and the opening geometry would then be cut accordingly, just like in a straight wall. Seems like the software engineer is making a decision that doesn’t match reality. The cutting geometry for these door and window units should be orthogonal to itself and not based on the radius of the curvature of the wall.
