Building VR training simulators for equipment familiarisation

Familiarisation and procedure training are different products

Familiarisation answers 'what is this machine, what is on it, and where'. The trainee learns the layout, the names of things, the scale of them, and what is behind a panel they will rarely open. It is mostly free exploration with labelling and guidance.

Procedure training answers 'can you do the task, in order, under conditions'. It needs a correct sequence, a definition of failure, and something watching. The two share a 3D model and almost nothing else: the interaction design, the scenario layer and the assessment are separate work. Deciding which you are buying is the biggest cost lever in the project.

What VR genuinely does better here

• Scale and position. Reaching for something at the wrong height is a mistake you can only make in a 3D space, and only correct there.
• Access. Cutaways, internals and the inside of an assembly can be opened in a way the real equipment cannot without taking it apart.
• Availability. The real machine is often in service, remote, expensive to stop, or hazardous to practise on.
• Repetition. The same drill can be run a hundred times without consumables, wear or a second instructor.
• Mistakes that carry consequences but no cost, which is the whole reason the sector buys simulation.

Interaction fidelity costs more than visual fidelity

The common failure is a photoreal model whose controls behave like buttons on a web page. A latch that opens with a click teaches nothing; a latch that needs the other hand on the housing, resists, then gives, teaches the real motion. The same goes for a panel that keeps showing a plausible reading after a step was skipped, instead of what the real panel would show.

So I ask early which controls are operable, which are scenery, and which give feedback when used wrongly. That list drives the budget far more than polygon count, and deciding it at the start is much cheaper than retrofitting.

Where the 3D model comes from

There are three usual sources and each has a catch. Manufacturer CAD is the most accurate and almost never usable as-is: it arrives as dense tessellated geometry with assembly structure rather than interaction structure, and generally needs rebuilding before it will run in a headset. Photogrammetry suits equipment that already exists and can be photographed, and gives you the worn, real article rather than the catalogue one. Hand-modelling from drawings and reference photographs is slowest per item but gives clean geometry built for the interactions you need.

Whichever route, treat model preparation as its own line in the schedule: it is routinely underestimated and sits on the critical path, because nothing else can be tested without it.

Standalone or tethered

A standalone headset runs on a mobile-class processor, which puts real limits on geometry, draw calls, texture memory and lighting. In exchange there is no PC per trainee, no cabling, and a session can run anywhere — which usually decides the question for a training programme that has to reach several sites.

A tethered headset driven by a workstation lifts those limits and suits a single high-fidelity facility. The honest way to choose is to start from how many trainees, in how many places, on whose hardware — not from the fidelity you would like.

Comfort decides how long a session can be

Standing at a machine and using your hands is the comfortable case for VR: the viewpoint moves because the person moved, which is what the inner ear expects. Discomfort mostly arrives with artificial locomotion, so if the trainee has to cross a space, teleporting between positions is the safer default and smooth movement is the option to justify. Headset weight, heat and battery cap a session regardless, which is a reason to build a trainer from short drills with clean stopping points rather than one long run.

How I approach it

I build the interaction layer against a plain description of the equipment, not against the headset SDK, so the trainer runs and is tested on a desktop without a headset on. That is how the mixed-reality project in my case studies is built, and why the logic can be tested automatically rather than by putting on a headset for every change.

The first milestone is one piece of equipment, a few genuinely operable controls, and a build you can run yourself — enough to find out whether the interaction design teaches anything before the rest of the machine is modelled.