Big and small yellow rubber ducks on pink background

Optimising IFC Files in Python

Digital By Sep 04, 2025 No Comments

I came across a Python-based IFC optimiser built on top of IfcOpenShell. It was solid, removing unused spaces, orphaned entities, and redundant metadata, but I saw room to push it further.

The original script handled:

  • Removing empty attributes
  • Cleaning up orphaned or unused relationships
  • Removing tiny geometry
  • Flattening the spatial hierarchy
  • Deduplicating shape representations

Good start. But I was dealing with a 517mb Ifc file and wanted to see what else I could get out of it, see if I could achieve some better results, and a few quality-of-life improvements.

What I Added

I forked the original and extended it with a few enhancements to make it more configurable and practical for day-to-day messy IFC exports.

You can find my version here: github.com/ryanlenihan/ifc_optimizer

  • The file I was dealing with contained values to 8 decimal places! So I introduced lossy coordinate rounding based on the IFCCompressor implementation. It’s a regex-based pass over the raw IFC text to round IfcCartesianPoint coordinates. Reduces file size without breaking geometry. Especially useful for overly precise exports from BIM tools. Interestingly, the original author says they included this method, but I couldn’t see it.
# Before
IFCCARTESIANPOINT((12345.12345678, 67890.87654321))

# After
IFCCARTESIANPOINT((12345.12, 67890.88))Code language: CSS (css)
  • Cartesian point merging. IFC files often contain thousands of identical points. The script now merges duplicates, reducing geometric bloat.
  • I added logic to merge duplicate instances of property sets and classifications. If two objects are identical, why store them twice?
  • Placeholder property removal. You’ve seen them. Properties with values like “-” or “N/A” (although note that N/A is a requirement on TfNSW projects if you don’t know the value). The script now strips these out, along with any empty sets left behind.
  • Added support for .ifczip output, which is handy for sharing optimised models.

Other Refinements

There were a few elements that already existed but I tried to tidy up, they were:

  • CLI arguments cleaned up for easier use in terminal or CI/CD pipelines
  • Temporary files (e.g. after schema conversion or rounding) are auto-deleted
  • Orphan removal logic now preserves critical relationships like IfcRelContainedInSpatialStructure, IfcRelDefinesByProperties, and IfcRelAssigns

Results

The updated optimiser still handles the basics such as unused materials, redundant spaces, orphaned geometry, but now offers a few extra features. Depending on the messiness of the source file, you can expect file size reductions in the 10–40% range. Lossy rounding and coordinate merging alone can yield surprising gains.

Real-World Testing

I threw the optimiser at a 517 MB IFC straight out of Revit. Based on the size of the original RVT model (80 MB), I expected a big reduction. But after all the tweaks of lossy rounding, point merging, orphan purging, the result was:

  • IFC file straight out of Revit (LOD: Low): 517 MB
  • After optimisation: 472 MB
  • Reduction: 45 MB (~9%)

Not bad, but not the earth-shattering kaboom I was hoping for. The file was still too large given the simplicity of the model.

So I decided to try something different: change the LOD setting in Revit’s IFC exporter. That’s it. No code.

This time I exported the same model with LOD set to “Extra Low”, and got:

  • Same model, exported from Revit with LOD set to “Extra Low”: 120 MB
  • After optimisation: 117 MB
  • Reduction: 3 MB (~2.5%)

The takeaway? The optimiser works, but the biggest gains came from upstream. Export settings matter. Authoring matters. You can’t polish an IFC boulder.

Visually, the “Extra Low” version looked fine. No perceptible loss in detail, no broken geometry. Just a much smaller file.

The best optimisation isn’t downstream, it’s upstream. Clean authoring + sane export settings will always beat post-processing.

Although, I’ll still say that having a solid optimiser in your toolkit is still very much worth it.

No Comments

Leave a comment

Your email address will not be published. Required fields are marked *