ProcessSpatial Computing
From BIM to headset: a seven-step spatial data workflow
Taking a BIM model to a headset is a data pipeline, not an export button. The model is filtered to what the task needs, simplified to the device's rendering budget, converted to a runtime format with element IDs intact, aligned to the site through survey control and kept in step with the common data environment. This workflow sets out each step, what it produces and who owns it.
On this page
Why a design model stalls on a standalone headset
Authoring models are built for documentation and coordination. They carry every fixing, hidden layers, design options and thousands of properties, and their geometry is often far denser than a mobile graphics processor can draw at a comfortable frame rate. A headset that drops frames makes people uncomfortable, and one that takes minutes to open a model will not be used on a busy site.
Coordinates cause a quieter problem. Project models are often placed at real-world eastings and northings, far from the origin, and real-time engines commonly use single-precision math that loses detail at large coordinate values, which shows up as jittering geometry. The pipeline has to separate the model's local origin from its georeference and keep the relationship between the two explicit.
Finally, a careless export strips meaning. If geometry is merged to save memory and properties are dropped, a site user can see a duct but cannot ask which system it belongs to or raise an issue against it.
Seven steps, each with an output and an owner
Define the use
Name the job the model must do on the device: clash review in the site office, as-built comparison, installation guidance at the work face or a client walkthrough. Each needs different disciplines, detail and accuracy, so write down the use, the users and the location first.
Export and filter to IFC
Export each discipline to IFC, the open schema published as ISO 16739-1:20242, using an agreed model view. Leave out what the use does not need: annotation, unused design options, the insides of closed equipment and properties nobody will query.
Optimize geometry
Set a polygon and texture budget for the target device, then decimate dense meshes, generate levels of detail for large scenes and instance repeated elements such as fittings. Check visually that simplification has not removed what the use relies on, such as a sleeve outline or a fixing point.
Align to the site
Read the georeference from the IFC file, where IfcMapConversion relates local project coordinates to a projected coordinate reference system5, and establish survey control points on site. Align the device's map to those points rather than to an eyeballed corner, and record the residual error at each one.
Version and govern
Publish the converted model as an information container in the common data environment, with a status and revision, following the information management principles of ISO 196506. Devices used on site should load only models in the published state.
Close the feedback loop
Let site users raise an issue against an element on the device, with a viewpoint and a photo, and export it in BIM Collaboration Format, which identifies components by their IfcGuid7. The design team then sees the issue against the right object in its own tools.
glTF, USDZ or streamed rendering for site models
| Factor | glTF | USD / USDZ | Remote rendering (streamed) |
|---|---|---|---|
| Where it fits best | Web viewers, Android-based headsets and most real-time engines | Apple platforms, and pipelines built on OpenUSD | Any device with a strong, low-latency connection |
| What limits model size | Device memory and draw budget | Device memory and draw budget | Server capacity; the device only decodes frames |
| Element metadata | Custom properties per node, or an ID lookup | Custom attributes on prims, or an ID lookup | Held on the server; queries cross the network |
| Offline use on site | Yes, once downloaded | Yes, once downloaded | No; needs a connection throughout |
| Standardization | Khronos specification and ISO/IEC 12113:20223 | OpenUSD specification, including the USDZ package4 | Vendor-specific services and protocols |
| Main trade-off | Must be simplified to fit the device | Must be simplified; tooling centers on Apple devices | Latency, network dependence and running cost |
Many teams output both file formats from one optimized scene, and reserve streaming for models that cannot be simplified without losing what the use needs.
How far to trust an on-site overlay
Questions and answers
Which file format should we use to put BIM models on a headset?
Use what your target devices render natively. glTF is widely supported across real-time engines, web viewers and Android-based headsets, while USDZ is the natural choice on Apple Vision Pro and iPad. A well-built pipeline can output both from the same optimized scene. Keep IFC as the exchange format upstream and treat the runtime file as a derived product, regenerated whenever the source model changes.
How accurate is an on-site BIM overlay on a headset?
It varies with the device, the alignment method, the number and spread of control points and how far the user moves from them, so measure it rather than assume it. Aligning to surveyed control points and re-checking residuals regularly gives a defensible figure for each location. Treat the overlay as a way to find discrepancies, then confirm them with survey instruments before acting on them.
Can large BIM models be streamed to a headset instead of simplified?
Yes. Remote rendering draws the model on a server and streams frames to the headset, which removes the device's own geometry limit. The price is dependence on a strong, low-latency connection for the whole session, which construction sites often lack, plus server running costs. Many teams stream for design reviews in an office and use simplified local models on site.
Who owns the converted headset model under ISO 19650?
Treat it as an information container like any other deliverable. Assign the task team responsible for producing it, give it a status and revision in the common data environment and record which source models it was derived from. That makes it clear which version site users are seeing and who must regenerate it when the design changes.
Do we need IFC if our authoring tool exports directly to glTF or USDZ?
Not strictly. IFC earns its place when several disciplines use different tools, when the client requires open deliverables, or when you need stable element identifiers and georeferencing that every downstream tool can read. A direct export is quicker for a single-discipline review; IFC is the safer backbone for a pipeline shared by several parties.
Sources
- Spatial Computing: ColdAI's approach to spatial applications and data — ColdAI
- IFC 4.3 approved as a final standard — buildingSMART International · checked 10 October 2026
- Khronos glTF 2.0 released as an ISO/IEC International Standard — The Khronos Group · checked 10 October 2026
- USDZ file format specification — OpenUSD · checked 10 October 2026
- IfcMapConversion (IFC 4.3 documentation) — buildingSMART International · checked 10 October 2026
- ISO 19650-1:2018 Information management using building information modelling, Part 1: Concepts and principles — ISO · checked 10 October 2026
- BCF-XML documentation (BIM Collaboration Format) — buildingSMART International · checked 10 October 2026