From Revit to Headset. The Hardware Half of a BIM-to-VR Pipeline.

Most guides to doing this focus on the software half of the pipeline: how to export a Revit model, which plug-ins to use, how to optimise geometry, which engine to load it into. That half matters. But the pipeline has a second half, and it is where many AEC teams get stuck: the hardware that actually displays the model, and the conditions in which it is used.

This paper covers that second half. It assumes the reader knows the software side exists and focuses on what the headset or glasses must handle, in the office, in client meetings and on site.

Where the pipeline usually breaks on the device side

Typical pattern. A practice exports a large hospital model and loads it into a review application. On the design lead's workstation with a tethered headset, it runs well. The team then takes a standalone headset to a client meeting. The model loads slowly, the frame rate drops in the busiest areas, and the client feels uncomfortable after a few minutes. The model was never prepared for the device it ended up on.

The pattern repeats across firms. Building models are rich: every wall layer, every fixture, every family with its parameters. That richness is what makes BIM valuable, and it is also what overwhelms headsets that need to redraw the scene smoothly many times a second.

The hardware decision therefore cannot be separated from how the model will be prepared, and both depend on where the review will happen.

A short reminder of the software half

The usual steps from Revit to a headset are:

1. Prepare the model. Hide or remove elements irrelevant to the review, simplify detailed families, fix materials.
2. Export. Convert to a format a real-time engine or review application can use. glTF, published by the Khronos Group, is increasingly common for real-time 3D; FBX and others are also used, and IFC is used where an open BIM exchange is needed. Exporting to some formats from Revit typically requires a plug-in or third-party tool.
3. Optimise. Reduce geometry, combine objects, compress textures and split large models into sections.
4. Load into an engine or review platform. A dedicated BIM review application, or a game engine such as Unity or Unreal for custom experiences.
5. Deploy to the device. Install or stream the experience on the headset.

QWR's paper on hardware requirements for AEC deployments covers the broader AEC requirements. The rest of this paper is about step 5 and what follows it.

Headset choices for office review versus on-site use

Office and studio review

In the office, the review usually happens in a fixed place, with a workstation available and time to set up.

Tethered headsets connected to a powerful workstation can display large models at high fidelity. They suit detailed design review where reviewers need to read labels, inspect junctions and judge clearances.

Standalone headsets suit quick reviews and meeting rooms without a dedicated workstation. They need more optimised models.

Streamed rendering, where a workstation or server renders the model and streams it to a standalone headset over the network, can combine the two, if the office network supports it reliably.

Client presentations

Client meetings happen in client offices, site cabins and showrooms. Portability and reliability matter more than maximum fidelity.

What to ask. - Can the headset be set up in a few minutes in an unfamiliar room? - Does the experience run without depending on the client's network? - Is the headset comfortable and simple for someone who has never used one?

The last question deserves weight. A client's first experience of VR shapes their view of the design. A headset that is uncomfortable, confusing or slow to respond undermines the presentation.

On-site use

On site, the questions change. Teams may want to compare the model with what has been built, check a service route against the structure, or plan installation in place.

VR on site is limited: a fully immersed person on a construction site is a hazard, and VR headsets should not be used or left in direct sunlight, because their lenses can focus sunlight onto the displays.

Passthrough headsets and see-through AR glasses let users see the real site with the model overlaid. These are the usual choice for on-site comparison, but they bring their own requirements.

What the device must support for on-site overlay

Alignment

An overlay is only useful if the model sits in the right place. A duct shown half a metre off its true position is worse than no overlay at all.

What to ask. - How is the model aligned with the real building: by markers, by surveyed control points, by matching features? - How accurately does it hold alignment as the user walks around? - Does alignment drift over distance, and how is it corrected?

Alignment accuracy depends on the device's tracking, the alignment method and the site conditions. Test it on a real site, not in an office.

Tracking in construction conditions

Camera-based tracking relies on visual features. Construction sites change daily, and some areas are featureless (bare concrete, blank plasterboard) or poorly lit. These conditions can reduce tracking reliability.

What to ask. How does the device perform in low light and on plain surfaces? Has it been tested in partly built interiors?

Daylight readability

For AR glasses used on open floors or outdoors, the display must remain readable in bright conditions. QWR's paper on light engine selection for see-through AR explains how display technology affects outdoor visibility.

Protective equipment and durability

Site rules require hard hats, safety glasses and high-visibility clothing. Devices must be wearable with the required protective equipment and tolerate dust, knocks and weather. QWR's paper on IP ratings across AI glasses explains how to read ingress protection ratings.

Offline model access

Site connectivity is often poor, and client offices may restrict network access.

What to ask. - Can the full model, or the relevant section, be stored on the device? - How large a model can the device hold and display offline? - How are updated models pushed to devices when the design changes?

Model versions matter. A team reviewing an outdated model on site may make decisions against a design that has already changed. Fleet management that pushes the current model to every device reduces this risk. QWR's paper on kiosk mode, secure boot and remote MDM covers the mechanisms.

Multi-user review

Design reviews involve several people: architects, engineers, the client, contractors. Multi-user sessions let them stand in the same model together, in the same room or remotely.

What to ask. How many users can share a session? Can some join on screens? What network does it need? Can annotations made in the headset flow back to the BIM coordination process?

The last point decides whether VR review becomes part of the design workflow or stays a presentation tool. If issues spotted in a headset have to be retyped into the coordination system, many will be lost.

Development and content portability

Firms that build custom experiences in a game engine should consider how portable those experiences are across devices. Content built against the OpenXR standard, published by the Khronos Group, is generally easier to move between headsets than content built for one device's proprietary interface. QWR's paper on evaluating an XR platform's developer ecosystem covers engine support, OpenXR portability and the support model.

Typical pattern: one pipeline, three device settings

Typical pattern. A multidisciplinary practice settles on a single pipeline with three outputs.

• Detailed design review: the full model, lightly optimised, on tethered headsets in a review room.
• Client presentations: a heavily optimised model with curated viewpoints, stored on standalone headsets that work without a network.
• Site checks: sections of the model relevant to the current works, aligned with surveyed control points, on see-through glasses worn with standard protective equipment.

The practice optimises once for each output rather than trying to make one model run everywhere.

Where to go next

For broader AEC hardware requirements, read Hardware Requirements for AEC Deployments. To match each review setting to a device class, start with the Platform Finder.

Sources

• Khronos Group: glTF and OpenXR specifications.
• Meta Quest help, "Avoid sunlight damage with your Meta Quest headset" (cited as a manufacturer safety reference).
• buildingSMART International: IFC.