Add IFC Base Quantities

Compute quantities from geometry and write standard Qto property sets onto elements.

Compute quantities from an IFC model's geometry and write them back as standard buildingSMART Qto_*BaseQuantities property sets. Upload the model, choose the scope, and download a file whose elements finally carry the lengths, areas and volumes downstream tools expect to find.

Plenty of authoring tools export geometry without base quantities, or export them for some classes and not others. Everything downstream then reads the model as having no measurable content: takeoff tools return empty schedules, cost software finds nothing to price, and an IDS check requiring a volume fails on elements that visibly have one. The quantities are computable from the geometry that IS in the file — this writes them in, as proper Qto sets, so the model becomes takeoff-ready without going back to the author.

When to reach for it: When an authoring tool exported the model without BaseQuantities and downstream takeoff, IDS or FM tools expect Qto_* sets.

What you get: The same IFC with standard Qto_*BaseQuantities property sets (length, width, height, area, volume) written onto elements, computed from tessellated geometry in model units.

Example: Make a Revit export takeoff-ready for downstream tools that expect Qto_WallBaseQuantities.

Standard Qto sets, per class

Quantities are written into the buildingSMART set for each element's class, with the names that vocabulary defines — not into a custom set of our own that nothing else would look for. The measurements are chosen per class, because the meaningful quantity depends on what the element is.

Walls → Qto_WallBaseQuantities: Length, Width, Height, GrossSideArea (length × height — the wall's face, not the full mesh surface, which would double-count both sides), NetVolume and GrossVolume.
Slabs → Qto_SlabBaseQuantities: Width (the slab's thickness, taken as its smallest extent so it's right regardless of how the local axes were authored), GrossArea and GrossVolume.
Columns → Qto_ColumnBaseQuantities: Length (the vertical extent), GrossVolume and OuterSurfaceArea.
Beams → Qto_BeamBaseQuantities: Length (the longest dimension — beams run horizontally, so the local Z axis is usually the section height rather than the span), GrossVolume and OuterSurfaceArea.
Coverings → Qto_CoveringBaseQuantities: GrossArea.
Everything else physical → Qto_ElementBaseQuantities: Length, Width, Height, GrossSurfaceArea and GrossVolume.

Authored numbers are contract-grade, so they win by default

Overwrite is off unless you turn it on. A quantity the authoring tool wrote may be tied to a schedule, a cost plan or a submitted claim, and a computed value that differs by a few millimetres is not an improvement — it's a discrepancy nobody asked for. So a default run fills gaps only: elements and quantities that had no value get one, and everything already present is left exactly as it was and counted as skipped.

Turn overwrite on when you know the authored numbers are wrong — a bad export, a unit mix-up, quantities computed before a design change — and every matching quantity is updated in place instead.

Every value carries a MethodOfMeasurement recording that it was computed from tessellated geometry, so a quantity surveyor reading the model can tell our numbers from the authoring tool's rather than having to trust the whole set equally.

Dry run first, and units left alone

Dry run measures everything and reports exactly what a real run would create — how many quantity sets, how many values, how many skipped because a value already exists — and commits nothing. On a model you haven't written to before, that's the cheap way to find out whether the scope is right before you change the file.

Values are written in the model's OWN units, verbatim. IfcQuantityLength, IfcQuantityArea and IfcQuantityVolume are bound to the project's unit assignment, so converting to metres on the way in would silently corrupt a model authored in millimetres or feet. If you want a takeoff normalised to metric for reporting, the Quantity Takeoff tool does that conversion on the report rather than in the model.

Quantities are measured from tessellated geometry, which means the tessellation service has to be reachable. If it isn't, the run stops and says so rather than writing a partial set and reporting success — and if it fails part-way through, the affected element count is reported so a partially-written model is never mistaken for a complete one.

How to write base quantities into an IFC model

Upload your IFC file
Choose scope and whether existing values may be overwritten
Click Run to compute and write quantities
Download the enriched IFC

Under the hood

BIMCamel parses IFC files in the browser using the open-source web-ifc engine and renders models with @thatopen/components + three.js. Heavy operations (clean / optimise / validate / convert) run on disposable server-side workers using the same web-ifc stack plus our own .NET pipeline; results stream back to your browser as soon as they're ready. Uploads sit on our servers only as long as your tier's retention window allows and are never used to train AI.

Frequently asked questions

My IFC has no BaseQuantities — can I add them?

Yes. This tool measures each element from the model's geometry and writes standard Qto_*BaseQuantities sets — Qto_WallBaseQuantities, Qto_SlabBaseQuantities and so on — so takeoff, cost and validation tools downstream read them as authored data.

Will it overwrite the quantities my authoring tool already exported?

Not unless you ask it to. Overwrite is off by default: existing values are kept and only missing quantities are added, because authored numbers may already be tied to a schedule or a cost plan. Turn overwrite on when you know the authored values are wrong.

Can I see what it would write before changing the file?

Yes — tick "Dry run". It measures the elements and reports how many quantity sets and values a real run would create, and how many it would skip because a value already exists, without committing anything.

What units are the quantities written in?

The model's own units, unchanged. IFC quantity entities are bound to the project's unit assignment, so converting them on write would corrupt a model authored in millimetres or feet. Use Quantity Takeoff if you want a report normalised to metric.

How can I tell which quantities the tool wrote?

Every value it writes records a MethodOfMeasurement of "BIMCamel: computed from tessellated geometry". A quantity surveyor reading the model can separate computed values from the authoring tool's own rather than having to trust them equally.

What's the maximum IFC file size?

Up to 25 MB as a guest, 100 MB with a free account, 500 MB on Pro, and 1 GB on Team. The caps are on upload size only — every tool itself is available on every tier.

What happens to my file after processing?

Your file is uploaded over HTTPS and processed on our servers. Guest uploads are stream-only — the working files are deleted as soon as your download finishes. Free accounts keep results for 7 days; Pro keeps them 90 days and Team 180 days. Files are never shared with third parties or used to train AI.

Is Add IFC Base Quantities free?

Yes. Add IFC Base Quantities is free to use — guests get 3 runs a day with 25 MB uploads, and a free account raises that to 10 runs a day with 100 MB uploads. No trial clock, no watermarks.