AI and 3D Construction Takeoffs
A construction takeoff turns the scope in a set of drawings into quantities: feet of pipe, square feet of slab, cubic yards of concrete, and counts of structures. A 3D takeoff gives those quantities a place in a model that you can inspect.
On September 8, 2026, I used Astra to help build a browser-based model and takeoff workflow for a job around $50 million in size, before lunch. Work I would have expected to spend a week on had moved into a morning. That is my experience on this job, with partial model coverage and review still open; it is not a measured benchmark for every plan set. The personal account is here.
The stack, from drawing to quantity
- Read the plans. Python and PyMuPDF extract vector paths, text, and reference images from the PDFs.
- Build usable geometry. Shapely helps assemble lines and polygons. Coordinate transforms align sheets; profiles and schedules supply elevations and dimensions.
- Keep structured records. JSON holds the element geometry alongside its source sheet, units, scope, phase, and verification notes.
- Review in the browser. Three.js draws the model inside an HTML page. JavaScript connects selections, filters, source references, and quantity summaries.
- Export the work. CSV carries quantity rows into estimating; GLB carries the 3D scene into compatible viewers and modeling software.
These components are visible in the project scripts and viewer I used that morning. AI helped write and revise the workflow. The extraction, rendering, and arithmetic still run as code.
Where the third dimension comes from
A plan view can locate a pipe or a slab in two dimensions. Depth comes from additional evidence: an invert elevation, a profile, a slab thickness, a footing schedule, or a section detail. The workflow joins those sources. It cannot recover a missing elevation just by displaying a line in 3D.
The viewer distinguishes routes with reconstructed profile geometry from routes whose elevations remain unresolved. It also exposes coverage and coordination holds. That is useful estimating information: a gap should remain visible until there is a source to resolve it.
The quantity has to match the scope
For a uniform slab, volume in cubic yards is area in square feet multiplied by thickness in feet, divided by 27. An illustrative 30-by-20-foot slab, 6 inches thick, contains 11.11 CY before waste. Openings, thickened edges, and separate footing volumes need their own treatment.
The current workflow keeps the bid workbook total, partial modeled subtotal, and visible selection subtotal separate. A duct-bank corridor envelope is not automatically the volume of encasement concrete. A pipe centerline length is not excavation volume. The quantity record needs its measurement basis as well as a number.
Why the speed matters
The useful change is how quickly an estimator can get from a plan set to something inspectable, correct a rule, and regenerate it. Access to a capable coding model such as Astra lowers the barrier to making these tools. Construction judgment, readable source documents, and review still determine the quality of the result.
For openmud, this is a workflow worth building toward: quantities tied to geometry, geometry tied to source evidence, and outputs that can leave the application. This morning's custom workflow is a working example, not a claim that openmud already performs the entire process automatically.