Motion Sickness Is a Bug Your VR Team Cannot Reproduce

Every VR team I have worked with has the same blind spot, and I had it too. After a few weeks of building in a headset, you stop feeling the things that make a first-time user queasy. The scene feels fine to you. You ship it. Then a trainee lifts the headset to their forehead four minutes in, says "it was fine," and never books another session.

Nobody files a ticket for that. There is no stack trace, no crash report, no angry email. The adoption numbers just sag, and nobody connects them to comfort.

So I have started treating VR motion sickness the way I treat any other bug that the team cannot reproduce locally: find the mechanism, list the triggers the code actually controls, and build a test setup that includes the people who can reproduce it.

The mechanism: two sensors disagreeing

The leading explanation is sensory conflict. Your eyes tell your brain you are moving. Your inner ear, which senses acceleration and balance, says you are standing still. When those two signals disagree, the body responds the way it does to seasickness: nausea, sweating, dizziness, eye strain, headache.

That gives you a useful rule for code review. Anything that makes the view move without the body moving is a risk. So is anything that makes the view fail to move when the body does. Nearly every comfort technique in VR either keeps those two signals in agreement or gives the brain something stable to hold on to when they cannot agree.

Susceptibility varies a lot between people, and enterprise users skew toward people who have never worn a headset and have zero tolerance built up. Your team is the worst possible sample.

The triggers that live in your code

1. Artificial locomotion

This is the big one. When the virtual space is bigger than the room, the app has to move the user through it, and smooth thumbstick movement is exactly the eyes-moving, body-still conflict. Gamers barely notice it. A meaningful share of everyone else gets sick.

Acceleration is worse than constant speed, and rotation is worse than forward movement. Smooth turning, where the world spins while the person stands still, is one of the most reliable ways to make a newcomer uncomfortable.

The comfortable patterns are well known:

• Teleport instead of glide, so there is no visible motion at all.
• Snap turning in fixed steps instead of a continuous spin.
• A dynamic vignette that narrows the field of view only while the user is moving, which cuts down what peripheral vision registers, and peripheral vision is where a lot of the conflict comes from.
• Best of all, design the space so nobody needs artificial movement: seated, standing, or room-scale walking.

2. Moving the camera for the user

In VR the user's head is the camera. Every time the app moves it for them, with a panning cutscene, a forced look at a point of interest, a screen shake on an explosion, or a vehicle that banks without warning, they see motion they did not start and could not predict.

If you come from flat-screen games or film, the instinct to direct attention by moving the camera is completely correct there and completely wrong here. In a headset you direct attention with sound, light, motion in the scene, or a character turning to look at something. You leave the head alone.

A cheap review question: does any code path write to the camera transform other than head tracking? If yes, it needs a very good reason.

3. Frame rate and latency

A headset renders the scene twice, once per eye, many times a second, and has to update every time the head moves. When the image falls behind the head, even briefly, the world appears to swim, and people feel it in their stomach before they can put words to it.

This is the part I most want engineers to internalize: a dropped frame in VR is a comfort bug, not a cosmetic one. A scene that runs smoothly in the office demo and stutters when a trainee opens the heaviest scenario is a scene that will make someone ill.

In practice that means:

• A frame-time budget per target headset in the spec from day one, not after content lock.
• An asset pipeline that optimizes for the target device instead of hoping assets fit.
• Profiling the heaviest scene on the weakest supported device, because that is where the problem hides.
• Extra discipline on standalone headsets, which have far less headroom than tethered PC VR.

4. Things that should hold still but don't

UI locked rigidly to the face, drifting text, a horizon that tilts. All of these hand the brain conflicting cues. People are more comfortable when the world has stable reference points: a floor that stays level, panels anchored to the space or to a hand rather than to the head, and a visible horizon where the scene allows one.

Passthrough and mixed reality help here, because the real room stays visible as an anchor. That is one reason overlay-style experiences tend to be easier on people than fully enclosed ones. ERIS XR, the firefighter pre-planning and training platform we built at Null Studio for ARCortex, blends virtual content with the real world, and that stable real-room anchor is doing quiet comfort work. Passthrough is not free, though. Latency or distortion in the camera feed can create its own mismatch, so you still test it on the actual device.

5. The stuff outside the software

Some causes are not in the build at all. A headset not adjusted to the person's eyes gives blur and eye strain. Long sessions raise the odds for everyone. A hot, crowded room makes it worse. Who fits the headset, how long a session runs and where the breaks go belong in the rollout plan, not just the codebase.

Design for the least experienced user

The single biggest comfort mistake is testing only on the people building the thing. Developers who live in headsets build up tolerance fast, and a scene that feels fine to them can be rough on day one for everyone else.

So design for the least experienced likely user:

• Comfort settings on by default, advanced movement opt-in.
• Seated or standing play where the scenario allows it.
• Short first sessions that ramp up.
• A clear, easy pause or exit that the user learns in the first minute, because feeling trapped makes discomfort worse.

Some audiences raise the stakes. Nystag, our VR eye-tracking diagnostics build on the Vive Focus 3, puts patients in a headset in a clinic. They did not choose VR, they may already feel unwell, and the session has to work the first time. When the person in the headset is a patient, comfort is not polish. It decides whether the tool can be used at all.

How to actually reproduce the bug

You cannot judge comfort from a video, a storyboard, or a demo run by the developer. It only exists in a headset, on the real device, with the real users. Here is the test setup I push for:

1. Prove the riskiest motion first. If the core scenario needs a moving vehicle or a long walk through a building, build that moment in the first weeks and put real users through it before any content sits on top of it.
2. Recruit people who can reproduce it. Include non-gamers, your oldest users, your least technical users, and anyone who says they get carsick. They are your real audience and your best repro devices.
3. Use a structured signal, not "how was it?" People understate discomfort, especially in front of the team that built the thing. A short standard questionnaire after each session, like the Simulator Sickness Questionnaire used in research, gives you something comparable across builds.
4. Log the behavior. Sessions ended early, headsets lifted to the forehead, and a slow drop in repeat usage are all comfort telemetry.
5. Run the heaviest scene on the weakest device. Every time.

The takeaway

VR motion sickness is not an unavoidable tax on the medium, and "people get used to it" describes the users who stayed, not the ones you lost. It is the predictable output of specific choices: artificial movement, stealing the camera, dropped frames, unstable reference points and long sessions in badly fitted headsets. Every one of those is cheaper to fix in the spec than after a rollout where adoption quietly stalls.

Treat it like any other bug that only shows up on someone else's machine. Find the people who can reproduce it, and put them in the loop early.

I wrote a longer version of this for teams commissioning XR builds, including the questions to ask a vendor before any content is built, on the Null Studio blog.