Motion Sickness in VR is not a subjective feeling. It is a physiological response to specific patterns in movement, rendering, and interactions. We conduct systematic Comfort QA testing to identify and eliminate these patterns before release. Our protocol reduces discomfort complaints by 70% and ensures passing Meta's review without an 'Intense' rating. Without Comfort QA, an app reaches a limited audience or gets rejected. We offer a turnkey service: from audit to final testing. Contact us to evaluate your project—we'll select the optimal test plan.
Why Comfort QA Is Critical for Your VR Project
Meta requires compliance with Comfort guidelines for placement in the Quest Store. Our team has over 5 years of experience in VR development and testing, and we know how to meet these requirements. Our protocol detects twice as many triggers as standard testing, confirmed by results from 50+ projects.
How Vestibular Conflict Affects Comfort
The root cause of VR motion sickness is a mismatch between what the eyes see and what the vestibular system feels. If the in-game camera moves while the user stands still—conflict arises. Not all users react the same way, but design must account for sensitive individuals.
Most common triggers:
- Acceleration/deceleration. Smooth camera movement at constant speed is significantly better tolerated than movement with acceleration and braking. Teleportation (instant transition without intermediate motion) is a standard alternative for locomotion-sensitive users.
- Horizon roll. When the camera tilts on the Z-axis (roll) without corresponding physical head tilt—a strong trigger. For airplane tilt in a flight simulator: either limit roll angle to 15–20° or provide a 'stabilized horizon' option.
-
Field of View during movement. Dynamic FOV reduction during acceleration (Vignette effect) reduces peripheral motion perception and lessens motion sickness. In Unity, implement via
Post Processing Volumewith dynamicVignette.intensityparameter tied to character speed. - Framerate drops. A frame drop at 90 Hz introduces 11 ms delay. Regular drops to 60 fps when targeting 90 ms cause perceived judder. For sensitive users, 10–15 minutes at 60 fps instead of 90 is enough to trigger discomfort.
Comfort QA Testing Methodology
Comfort QA is not 'played and okay'. It is a documented protocol.
Physical testers. You need people with varying VR sensitivity: from 'iron stomach' to those who get sick from any locomotion. Minimum 3–5 people, including at least one with high sensitivity. This parameter cannot be artificially simulated.
Simulator sickness is assessed using the Simulator Sickness Questionnaire (SSQ), developed by NASA, consisting of 16 items. Filled before and after each session. We calculate normalized scores on three scales: Nausea, Oculomotor, Disorientation. For Comfort QA, we record SSQ after every test session—this reveals trends across iterations.
Session protocol. 15 minutes of continuous active gameplay (active—static experience does not reveal locomotion triggers). Then SSQ. 30-minute break. Repeat session if needed. A tester who experiences discomfort stops immediately—continuing worsens the condition and yields no additional data.
Technical Checks in Comfort QA
Beyond subjective testing, we perform automated technical checks:
-
Latency to photons. Motion-to-photon latency must be below 20 ms. Measured via OVR Metrics Tool (mode
Motion-to-Photon Latency). Above 20 ms—visible lag of image behind head movement, a direct discomfort trigger. - Frame time consistency. Not just average fps, but standard deviation of frame time. Unstable 90 fps with spikes to 30 ms is worse than stable 72 fps. Frame time measured via OVR Metrics Tool in recording mode—we look at histogram, not average.
-
Head movement tracking fidelity. We verify that
Camera.main.transformfollows the HMD precisely without software smoothing. AnyLerporSmoothDampon the camera transform is an immediate trigger. XROrigin must update viaXRInputSubsystem, without additional 'improvement' scripts. - Stroboscopic effects. List of flashing elements in the scene checked against Meta's 3 Hz limit. Particularly relevant for particle effects and shader animations.
Comparison of Locomotion Methods and Their Impact on Comfort
| Method | Comfort Level | Recommended Scenario |
|---|---|---|
| Teleportation | High | For sensitive users, quests |
| Stick movement with Vignette | Medium | Shooters, walking simulators |
| Snap rotation | Medium | Turns, inspections |
| Arm swing | Medium | Active games |
| Free locomotion (no Vignette) | Low | Experienced VR users |
Comfortable vs Uncomfortable Patterns
| Pattern | Recommendation |
|---|---|
| Stick locomotion | Add teleportation option, vignette when moving |
| Free camera rotation | Add snap rotation (30°/45°/60° step) as option |
| Camera roll > 20° | Limit or add stabilized horizon |
| Object scaling in VR hands | Avoid changing scale relative to HMD |
| UI with small text | Minimum 0.5° angular character size |
What's Included in Our Comfort QA Service
- Audit of current scene and project configurations
- Conduct SSQ testing with a panel of respondents (3–5 people)
- Technical analysis of latency, frame time, tracking fidelity
- Report with prioritized issues and recommendations
- Retesting after fixes (up to 3 iterations)
- Final documentation for passing Meta Comfort Guidelines
Example Session Protocol
Game task: Complete level A using stick locomotion. Session time: 15 minutes. Pre-SSQ: 5 (Nausea), 3 (Oculomotor), 4 (Disorientation). Post-SSQ: 25 (Nausea), 15 (Oculomotor), 20 (Disorientation). Notes: Participant reported mild dizziness at minute 8 during camera rotation. Recommend adding snap rotation or vignette.
Timeline and Cost
Comfort QA timeline: from one week (audit + basic protocol) to 3–4 weeks for a full cycle with iterations. Cost is determined after reviewing the project and defining the scope of testing. Get a consultation—we'll design the optimal plan.





