Geometry Service

[ikeough]

None of the IFC-gen implementations of IFC can handle geometry currently. What would be interesting, would be to create one geometry service that can be called from every implementation of IFC, possibly using gRPC around Open Cascade, or at a higher level, around python-OCC. This would allow the community to contribute to one, and only one, geometry implementation.

I would like to learn more about @aothms' experience with Open Cascade for IfcOpenShell and whether there is a possibility to do some complementary work here.

[aothms]

Hey Ian,

My experience with Open Cascade has been good enough, I still see it as the most viable open source solution to build IFC support upon, given it's support for many STEP primitives. Our CGAL implementation [1] has not really taken off yet (but is in a somewhat working state) due to the bigger implementation effort and more stringent constraints on valid geometry. With infinite time I'd like to try for example [2] as an alternative as well.

Your proposal of a geometry service is similar to what we did with IfcGeomServer [3], mainly for the Java-based BIMserver project [4] [5]. This has been working well now for some years, but has a very minimal interface, it just enumerates geometries for the products it finds in the IFC file you pass it.

It's tricky to find the appropriate level of abstraction. IFC has this dichotomy between things that happen at (a) the level of IfcRepresentationItem ie. extrusions, boolean ops, surface colors and (b) the product level ie. also boolean ops for openings, also surface colors by material associations (including layersets, ...). And then there is global state, such as (angular) units and geometric tolerance. All these interactions are non-trivial and you probably don't want to leave them as an exercise to implement in every interfacing language. This is why most implementations, including e.g [6], simply enumerate product geometry. At the same time you probably want to allow fine grained control and access to how individual representation items are processed (and re-used) which speaks for a more low level interface.

An even lower level interface around Open Cascade makes calls very leaky. You need to have the appropriate checks before and after operations to avoid hard crashes and there are fixes to recover from invalid state that you might or might not want to apply depending on what types of geometry you are processing. Return types are inefficient to serialize and often need to be iterated over. A set of wrapper bindings using e.g. SWIG could be an option. Open Cascade has paid options for C# and Java btw [7].

Something I planned on doing in the past has been to decompose all IFC-based geometry operations into trees of well-defined and well-understood geometry operations, such as extrusions, boolean ops, ... that way simplifying the effort of providing geometry support as there is a whole lotta ways of doing the same thing in IFC, leaving only several stubs to implement (sorted by prevalence in IFC). Desktop apps anyway probably have their own geometry kernel to begin with, so it would make sense to help developers use their own tools to build IFC support. This, of course, never happened. Also, the overlap with 10303-42 is large enough to get reasonable support with most CAD geometry kernels that speak step if you're able to map IFC back to vanilla STEP.

So to summarize, if you're fine with geometries per product, there are working tools available. Lower level interfaces lift a lot of work to end-user applications, because geometry can be somewhat intricate. Perhaps an intermediate set of definitions that map the 100+ rep items in IFC to a limited set of more familiar terms can help if you're thinking about fully native implementations (e.g a mapping to csg.js).

Are you coming to NY this month? Perhaps we need to make this an item on the agenda?

[1] https://github.com/aothms/IfcOpenShell_CGAL/
[2] https://github.com/solvespace/solvespace
[3] https://github.com/IfcOpenShell/IfcOpenShell/tree/master/src/ifcgeomserver
[4] https://github.com/opensourceBIM/BIMserver/
[5] https://github.com/opensourceBIM/IfcOpenShell-BIMserver-plugin/
[6] http://rdf.bg/ifc-engine-dll.php
[7] https://www.opencascade.com/content/advanced-samples-and-tools

[ikeough]

Thanks @aothms! This is a lot of great info. Your answer confirms my suspicion that OCE is probably the best thing out there. I'm currently investigating pythonOCC to make a prototype of this geometry service. If that works, I'll probably wrap the service interface around OCE directly.

I'm curious about your idea to "decompose all IFC-based geometry operations..." What would this look like? IfcGeometricModelResource and IfcGeometryResource seem to contain the types that would be the target of this work. Would this mean finding "the one way" to make an extrude amongst the several possible ways and implementing that way first? I agree that mapping out the required functionality would be great. I certainly don't want to do duplicative work, and I would like it to be clear to people using the service what methods are supported.

I don't intend to propose modeling capabilities at the level of any of the design applications that we use day-to-day. But, it seems that in order to build interesting functionality with geometry on top of IFC we need the ability to do volumetric and surface area calculations at the very least, which require actually constructing geometry as opposed to simply "enumerating" geometries.

[aothms]

If that works, I'll probably wrap the service interface around OCE directly.

Do you mean moving to C++? Probably Python has better primitives for networking, with coroutines and all, and you can skip the long compilation times. You get reasonable performance anyway as the the underlying heavy lifting is in C++.

There are a couple of features introduced in OCCT 6.9 that are relevant. n-ary boolean operations and fuzzy boolean ops. They are currently not exposed in pythonOCC if I'm not mistaken as it's not updated yet.

decompose all IFC-based geometry operations

IfcBooleanResult, IfcOpeningElement, maybe even IfcCircleHollowProfileDef, ... all basically represent boolean operations. If you can get from the IFC definition to a canonical tree of geometric operations you only need to implement those basic geometric operations agnostic of all 100+ rep items. I never worked this out in great detail, so not sure what it'd look like. But it could also be a way of properly defining schema semantics, so it's a double edged sword. I mean, who knows what a IfcCraneRailAShapeProfileDef [1] ever looked like? Similar to placements, there's a bunch of them and IfcCartesianTransformOperatorXXX, they all just represent matrix multiplications that every geometry library understands. If you define these equivalences/mappings in some higher level set of definitions (but hey perhaps that's was EXPRESS was meant to be) it'd be much easier to get IFC support from an arbitrary geometry library.

[1] http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcprofileresource/lexical/ifccranerailashapeprofiledef.htm

actually constructing geometry as opposed to simply "enumerating" geometries.

Sorry wasn't very clear there, that's of course what happens. I used enumerating to say that it's maybe not something you were imagining if you're thinking of gRPC for example, it's just IFC in, interpreted geometries out.