Problem
axiolid_kernel currently always performs real opening/boolean subtraction (supports_openings() == true, uses axiolid_v0_4_subtract_many for every IfcRelVoidsElement). That is correct default behavior, but there is no way to opt out of it.
passthrough_kernel skips real boolean work entirely (supports_boolean_operations() == false) and is dramatically cheaper as a result -- confirmed empirically this session on a 608-element fixture (SverchokFacadesIfcSverchok.ifc): axiolid did 608 objects / 63,922 verts / 32,126 tris in 0.159s vs passthrough's 362 objects / 27,522 verts / 28,910 tris in 0.131s. The gap is because axiolid does real subtraction and passthrough does not, not a performance defect.
For workflows that only need coarse bounding geometry, fast previews, or want to trade correctness for throughput on very large models, there is currently no way to get axiolid's superior taxonomy coverage (shells/solids/extrusions/loft/sweep) while skipping the boolean-subtraction cost specifically.
Proposal
Add an opt-in IfcOpenShell settings flag (e.g. disable-opening-subtraction or reuse/extend an existing settings key if one already covers this intent) that axiolid_kernel's convert_openings checks before calling into Axiolid's boolean provider. When set, convert_openings should return the unmodified host solid(s) unchanged (same behavior passthrough already exhibits), skipping the axiolid_v0_4_subtract_many call entirely.
Scope:
- IfcOpenShell-side only (
src/ifcgeom/kernels/axiolid/axiolid_kernel.cpp's convert_openings). No Axiolid core/C-ABI change required -- this is purely a call-site guard.
- Should be a per-conversion settings toggle, not a compile-time flag, so users can pick fast-vs-correct per run.
- Document the tradeoff explicitly in the settings help text and this kernel's README (openings ignored entirely, not approximated).
Context
Discovered/discussed 2026-09-03 while benchmarking the new axiolid_kernel IfcOpenShell integration (see this repo's native/CMakeLists.txt BYPRODUCTS fix, issue #69, and the SHARED-linkage SONAME gap, issue #70, filed the same session). The axiolid_kernel C++ implementation itself is currently local/uncommitted work in a private IfcOpenShell checkout (not yet upstreamed to IfcOpenShell/IfcOpenShell), so this issue tracks the feature request against axiolid/kernel as the closest active issue tracker for this integration effort, pending a decision on where the IfcOpenShell-side kernel plugin code eventually lands.
Problem
axiolid_kernel currently always performs real opening/boolean subtraction (
supports_openings() == true, usesaxiolid_v0_4_subtract_manyfor everyIfcRelVoidsElement). That is correct default behavior, but there is no way to opt out of it.passthrough_kernelskips real boolean work entirely (supports_boolean_operations() == false) and is dramatically cheaper as a result -- confirmed empirically this session on a 608-element fixture (SverchokFacadesIfcSverchok.ifc): axiolid did 608 objects / 63,922 verts / 32,126 tris in 0.159s vs passthrough's 362 objects / 27,522 verts / 28,910 tris in 0.131s. The gap is because axiolid does real subtraction and passthrough does not, not a performance defect.For workflows that only need coarse bounding geometry, fast previews, or want to trade correctness for throughput on very large models, there is currently no way to get axiolid's superior taxonomy coverage (shells/solids/extrusions/loft/sweep) while skipping the boolean-subtraction cost specifically.
Proposal
Add an opt-in IfcOpenShell
settingsflag (e.g.disable-opening-subtractionor reuse/extend an existing settings key if one already covers this intent) that axiolid_kernel'sconvert_openingschecks before calling into Axiolid's boolean provider. When set,convert_openingsshould return the unmodified host solid(s) unchanged (same behavior passthrough already exhibits), skipping theaxiolid_v0_4_subtract_manycall entirely.Scope:
src/ifcgeom/kernels/axiolid/axiolid_kernel.cpp'sconvert_openings). No Axiolid core/C-ABI change required -- this is purely a call-site guard.Context
Discovered/discussed 2026-09-03 while benchmarking the new axiolid_kernel IfcOpenShell integration (see this repo's
native/CMakeLists.txtBYPRODUCTS fix, issue #69, and the SHARED-linkage SONAME gap, issue #70, filed the same session). The axiolid_kernel C++ implementation itself is currently local/uncommitted work in a private IfcOpenShell checkout (not yet upstreamed to IfcOpenShell/IfcOpenShell), so this issue tracks the feature request against axiolid/kernel as the closest active issue tracker for this integration effort, pending a decision on where the IfcOpenShell-side kernel plugin code eventually lands.