What happened?
A 95 MB IFC4 file takes a very long time to convert: one core is pegged and the progress callback stalls between 0.13 and 0.17 indefinitely. I isolated it to two waffle-slab floors. Blank just those two representations and the same file converts in 46 s with the other 127 floors intact.
I raised this on the community forum and was asked to file it here with the file attached (attached below). The reply explained the mechanism: when shells are rebuilt from triangles, every triangle is matched against all faces built so far for that geometry, so cost grows quadratically with the face count of a single mesh — and a waffle slab's ribs and coffers produce exactly the pathological input, a large number of small coplanar faces. Filing so it's tracked, and because the isolation data below may be useful as a regression case for the new geometry engine.
Environment
- web-ifc 0.0.77, in the browser (single-threaded WASM), driven via @thatopen/fragments IfcImporter (@thatopen/* 3.4.x) in a Web Worker
- Chrome, Windows 10
- Source file: IFC4, Revit export. Geometry is polygonal facesets (the file contains 2,581 IFCINDEXEDPOLYGONALFACEWITHVOIDS)
Steps to reproduce
- Run IfcImporter.process() on the attached file.
- Watch the progress callback and CPU.
Expected: conversion completes (a 166 MB file from the same pipeline takes 39 s).
Actual: one core at 100 %, progress stops in the 0.13–0.17 band, completes after a very long waiting.
Isolation
The two elements responsible:
┌─────────┬───────────────────┬──────────┬────────┐
│ Entity │ Name │ Revit id │ Faces │
├─────────┼───────────────────┼──────────┼────────┤
│ #104181 │ Floor: INT CON-30 │ 13165968 │ 49,466 │
├─────────┼───────────────────┼──────────┼────────┤
│ #754208 │ Floor: INT CON-27 │ 13715840 │ 14,849 │
└─────────┴───────────────────┴──────────┴────────┘
The median floor in this model is 7 faces. Blanking the representations of just these two → 46 s for the whole file, all 127 remaining floors present and correct.
Why face count alone doesn't predict it
I tried to build a pre-flight size/complexity threshold and could not make one work. Same pipeline, same version:
┌───────────────────────┬─────────┬─────────────────────────────────────┬─────────────────┐
│ Model │ Size │ Geometry │ Result │
├───────────────────────┼─────────┼─────────────────────────────────────┼─────────────────┤
│ This file, unmodified │ 92.5 MB │ worst mesh 49,466 faces │ hangs (>38 min) │
├───────────────────────┼─────────┼─────────────────────────────────────┼─────────────────┤
│ Another project │ 166 MB │ 954,781 faces across 7,806 facesets │ 39 s │
├───────────────────────┼─────────┼─────────────────────────────────────┼─────────────────┤
│ Topography element │ — │ a single 44,974-face faceset │ 13 s │
└───────────────────────┴─────────┴─────────────────────────────────────┴─────────────────┘
So a smaller 14,849-face slab hangs while a larger 44,974-face single faceset converts in 13 s. Any threshold on triangle count, faceset size or file size misclassifies one of these. This matches the forum explanation — the predictor is how many small coplanar faces a mesh produces, not how many faces it has.
Hypotheses I falsified by measurement
Recording these so nobody repeats them:
- Giant n-gons — flattened all 6 faces with >500 vertices (largest 5,092) → still hangs.
- Hole/void triangulation — flattened all 2,581 IFCINDEXEDPOLYGONALFACEWITHVOIDS → still hangs.
- Oversized single faceset — disproved by the 44,974-face topography element above.
Questions
- Is there a cheap pre-flight signal an application could compute — e.g. counting near-coplanar adjacent faces per mesh — to warn a user before starting a conversion that will not finish? Right now a hang is indistinguishable from a slow parse, and there's no way to cancel usefully.
- Is this case expected to be covered by the new B-rep geometry engine, or would a bound/short-circuit in the current shell rebuild be worth having in the meantime?
Happy to run any instrumented build against this file — I have a reproducible setup and the isolated single-floor exports.
See below a link to download this IFC sample file
Version
IFC4
What browsers are you seeing the problem on?
Chrome
Relevant log output
Anything else?
I couldn't upload IFC file so here is a link to download it:
https://buildeyeai-my.sharepoint.com/:u:/g/personal/amir_buildeye_ai/IQBNpm4RwEntT4X8lBgIQdNWAUPVk9jhKfx06N-0asR3T8E?e=wxQAIq
What happened?
A 95 MB IFC4 file takes a very long time to convert: one core is pegged and the progress callback stalls between 0.13 and 0.17 indefinitely. I isolated it to two waffle-slab floors. Blank just those two representations and the same file converts in 46 s with the other 127 floors intact.
I raised this on the community forum and was asked to file it here with the file attached (attached below). The reply explained the mechanism: when shells are rebuilt from triangles, every triangle is matched against all faces built so far for that geometry, so cost grows quadratically with the face count of a single mesh — and a waffle slab's ribs and coffers produce exactly the pathological input, a large number of small coplanar faces. Filing so it's tracked, and because the isolation data below may be useful as a regression case for the new geometry engine.
Environment
Steps to reproduce
Expected: conversion completes (a 166 MB file from the same pipeline takes 39 s).
Actual: one core at 100 %, progress stops in the 0.13–0.17 band, completes after a very long waiting.
Isolation
The two elements responsible:
┌─────────┬───────────────────┬──────────┬────────┐
│ Entity │ Name │ Revit id │ Faces │
├─────────┼───────────────────┼──────────┼────────┤
│ #104181 │ Floor: INT CON-30 │ 13165968 │ 49,466 │
├─────────┼───────────────────┼──────────┼────────┤
│ #754208 │ Floor: INT CON-27 │ 13715840 │ 14,849 │
└─────────┴───────────────────┴──────────┴────────┘
The median floor in this model is 7 faces. Blanking the representations of just these two → 46 s for the whole file, all 127 remaining floors present and correct.
Why face count alone doesn't predict it
I tried to build a pre-flight size/complexity threshold and could not make one work. Same pipeline, same version:
┌───────────────────────┬─────────┬─────────────────────────────────────┬─────────────────┐
│ Model │ Size │ Geometry │ Result │
├───────────────────────┼─────────┼─────────────────────────────────────┼─────────────────┤
│ This file, unmodified │ 92.5 MB │ worst mesh 49,466 faces │ hangs (>38 min) │
├───────────────────────┼─────────┼─────────────────────────────────────┼─────────────────┤
│ Another project │ 166 MB │ 954,781 faces across 7,806 facesets │ 39 s │
├───────────────────────┼─────────┼─────────────────────────────────────┼─────────────────┤
│ Topography element │ — │ a single 44,974-face faceset │ 13 s │
└───────────────────────┴─────────┴─────────────────────────────────────┴─────────────────┘
So a smaller 14,849-face slab hangs while a larger 44,974-face single faceset converts in 13 s. Any threshold on triangle count, faceset size or file size misclassifies one of these. This matches the forum explanation — the predictor is how many small coplanar faces a mesh produces, not how many faces it has.
Hypotheses I falsified by measurement
Recording these so nobody repeats them:
Questions
Happy to run any instrumented build against this file — I have a reproducible setup and the isolated single-floor exports.
See below a link to download this IFC sample file
Version
IFC4
What browsers are you seeing the problem on?
Chrome
Relevant log output
Anything else?
I couldn't upload IFC file so here is a link to download it:
https://buildeyeai-my.sharepoint.com/:u:/g/personal/amir_buildeye_ai/IQBNpm4RwEntT4X8lBgIQdNWAUPVk9jhKfx06N-0asR3T8E?e=wxQAIq