Hi @aothms,
Thanks for your previous reply. I’d like to ask a more specific question based on your experience.
Have you ever benchmarked xBIM’s geometry engine on large IFC models and compared its performance to the workflow you suggested (using IfcConvert to generate glTF (.glb) for geometry and .xml for metadata)?
If you haven’t tested this directly, do you expect the performance difference to be significant when dealing with large or complex models?
I’m trying to understand whether the IfcConvert → glTF + XML pipeline would offer a noticeably faster and more scalable approach for visualization and data extraction in a .NET environment compared to relying on xBIM’s native geometry processing.
Any insight or assumptions you can share would be extremely helpful.
Thanks again for your time.

Hi, first of all, I consider the XBIM team highly knowledgable colleagues that deliver high quality software products. But there are a couple of differences you can expect when relying on IfcConvert (or IfcOpenShell in general).

1. IfcOpenShell has a hybrid geometry kernel which means in case of simple explicit elements (no boolean operations required) we can use a much lighter data model. You can easily expect a 4 - 10x speed up compared to using OpenCASCADE alone (as is the case in XBIM).
2. IfcOpenShell is committed to working in low-memory environments. This is still a bit experimental, but we can do a streaming conversion of IFC to the RocksDB key-value store and then do a streaming conversion to GLTF. These are recent developments, usable, but we're only beginning to apply this in production contexts.
3. In case of IFC4.3 infra structure sweeps, alignment and transition curves I think IfcOpenShell is among the most reliable including commercial offerings. Not sure where XBIM stands at the moment.
4. I don't know about XBIM's multi-threading capabilities. IfcOpenShell can do multi-threading geometry interpretation.

Thanks a lot for the detailed information, @aothms .
Your explanation about the hybrid geometry kernel, streaming workflows, and multi‑threading capabilities was extremely helpful. It gives me a much clearer picture of the performance differences and what to expect when working with large models.
If I decide to move forward with a .NET integration using IFCOpenShell (likely through the IfcConvert → glTF + XML pipeline), I’ll be sure to share my experience and results with the community.
Thanks again for your time and insights.

Thanks, @Moult — that’s a very valuable point.
I’m aware of the strength of IFCOpenShell’s Python API, especially for high‑level IFC authoring and editing, and I agree it’s a major differentiator compared to other libraries. Even though my current focus is on visualization and quantity extraction in a .NET environment, I may explore the authoring/editing capabilities in Python later on, depending on how the project evolves.
Thanks again for highlighting this — it’s definitely something I’ll keep in mind moving forward.