VR training and property walkthroughs built around comfort and completion records

What this actually solves

For training, the reasoning is arithmetic rather than enthusiasm. Some skills can only be learned by doing them, and doing them for real is either expensive, dangerous, or both. Practising on a live crane, a running production line, an energised panel or a patient means occupying an asset that should be earning, supervising it with someone senior, and accepting that a mistake has consequences measured in injuries and insurance rather than in marks. In a headset the same mistake costs nothing, can be repeated as many times in an afternoon as the trainee needs, and can be recorded. The purchase gets approved when the finance case is written that way — hours of downtime avoided, incidents avoided, and a defensible record that the training happened.

For property, the problem is distance and imagination. A buyer in another country, looking at a building that is currently a hole in the ground, is being asked to commit real money to a floor plan. Reading a floor plan is a skill, and a buyer is not required to have it; a rectangle labelled with dimensions does not convert into a sense of whether the bedroom is big enough or what the window faces. A walkthrough lets them stand in the room, look up, look out, and decide — which is why developers use it to sell before completion rather than after.

What both share is that the value is not the 3D. It is the decision or the competence produced at the end. That is why this work is scoped around what someone should be able to do afterwards, and why the completion record and the pass criteria matter as much as the visuals.

How the work runs

1. Define the learning or the sales outcome. For training, what specifically must the person be able to do, in what order, and what counts as passing — written down, agreed with whoever owns the training standard. For property, which units, which viewpoints and what a buyer needs to be convinced of. This document, not the model, is what the build is measured against. One to three weeks.
2. Choose the hardware and set the performance ceiling. Standalone or tethered, how many devices, how they are managed and charged, and where the sessions physically happen. From that comes the technical budget — polygon and draw-call ceilings, texture limits and the frame rate that must be held rather than averaged, because in a headset a dropped frame is a physical sensation and not a visual blemish. Three to five days.
3. Build the environment. The plant, the room, the building, modelled and optimised against that ceiling from the beginning rather than being reduced at the end. Lighting largely baked rather than computed live, because real-time lighting is the fastest way to lose the frame rate you must not lose. Three weeks to two months.
4. Design and build the interactions. What can be picked up, what cannot, what happens when it is used wrongly, and how the user is told. This is where training either becomes real practice or becomes a slideshow with a headset attached, and it is the phase most often underestimated. Movement is implemented with comfort as the constraint — teleport and snap turning by default, with settings the user controls. One to two months.
5. Comfort and usability testing with people who are not used to headsets. The people who built it have acclimatised and are the worst possible testers. Sessions run with genuine first-timers, watching for nausea, disorientation, controls nobody discovered, and instructions that made sense on a screen and do not in a headset. Findings feed straight back into movement, pacing and signposting. One to three weeks.
6. Deploy and wire up the records. Onto the devices with the management approach agreed at step two, plus the administrative side — who completed which module, what they scored, where they failed, exportable for whoever needs to see it. Then a handover session with the people who will actually run it. One to three weeks.

What moves the price

The range is $5,000–$60,000 across 2–6 months, and three things decide it.

How many modules. One well-made scenario and a curriculum of eight are not comparable. Each module needs its own scripting, its own interactions, its own pass criteria and its own comfort testing, even where they share an environment.

How deep the interactions go. Looking around a space is inexpensive. Picking up a specific tool, applying it to a specific component in a specific order, and being told why that was wrong is where the hours live. Interaction count is a better predictor of the estimate than square metres of environment.

Whether it is multi-user. Two people in the same virtual space at once — an instructor and a trainee, or two operators on one task — brings networking, synchronisation and voice, and changes how every interaction has to be written. Decide it at the start, because retrofitting it is close to a rebuild.

What usually goes wrong

Movement is chosen because it looks good in a demo video. Smooth, gliding locomotion is cinematic on a screen and is the leading cause of trainees taking the headset off partway through a session. Comfort-first movement looks less impressive in the sales deck and is what allows a shift to complete the training in one sitting.

The headset is not named before the environment is built. An environment built to a workstation's performance budget and then asked to run on a standalone headset does not get optimised down; it gets rebuilt. Naming the device in the scope document is a one-line decision that protects the entire modelling phase.

It is scoped as an experience rather than as training. No pass criteria, no record of who completed what, no way to show a regulator, an auditor or an insurer that anyone was trained. You are left with something impressive to demonstrate to visitors and nothing to put in a compliance file, which is usually not what you were actually buying.