For a motion-base dark ride that has to move a lot of guests, fixed projection is the safer default. Real-time XR headsets have to earn their place with measured evidence, not a vendor’s capacity sheet. Headsets bring costs: donning, sanitising and syncing that stretched coaster load times, sync failures that left a rider nauseous, and head-tracking latency, where users can notice a change of 15 ms. In return, a Breda University research project with Europa-Park found riders rated a coaster more positively with VR than without it. We have not found a published head-to-head trial of the two approaches on comparable ride hardware. So the decision comes down to a documented framework plus a timed load-ride-unload pilot at your planned vehicle count.
One distinction makes the rest of the decision easier. “Real-time versus pre-rendered” and “headset versus fixed display” are two separate choices. Vendor disguise says real-time content engines now suit projection-mapped dark rides, and Mine et al. (IEEE Computer, 2012) note that real-time projection systems suffer latency that makes perfect alignment hard to maintain. If the real attraction of XR is the ability to change content quickly, you can get that without putting a device on anyone’s head.
Do headsets make more riders sick than projection on a motion-base ride?
The sources reviewed here include no motion-base comparison of real-time headsets against fixed pre-rendered projection, so any claim that one makes fewer riders sick is an extrapolation. What the evidence does give is the mechanism, the rider factors and a few failure reports.
Visually induced motion sickness comes from conflict between what the eyes report and what the vestibular and somatosensory senses report. The early VR coaster simulations made people sick because the simulated motion had no matching physical forces behind it. A ride vehicle supplies those forces. According to the Wikipedia summary of VR coaster development, precise synchronisation between the animation and the train’s position made the nausea go away. That synchronisation depends on hardware that tracks the vehicle’s position and sends it wirelessly to every headset, which then runs in absolute tracking mode.
On a ride, then, headset sickness is largely a systems-reliability problem. Engadget’s 2017 report from a Six Flags VR coaster describes the headset view freezing for more than a second and then jumping ahead to catch up with the vehicle, which was nauseating. The park first pointed to Bluetooth dropouts caused by the track briefly blocking the signal in inversions. The real cause turned out to be animation files missing from that headset. Coaster101 (2019) reports smartphone-based headsets that cracked, froze, ran out of battery or failed to sync, plus one ride where the screen stayed black throughout. Each of these is a separate component that can fail on its own, and each turns into either a rider who sees nothing or a rider whose eyes and body disagree.
Projection is not immune. The term “simulator sickness” first described motion-platform simulators with computer-generated visuals and no head tracking. Cybersickness was coined later for problems specific to head-mounted displays, such as the delay between a head movement and the updated image. Mine et al. note that projection has fewer latency issues because projector and scenery move little relative to each other and theme park elements tend to follow known paths. That advantage reduces one cause of sickness on the projection side. The motion-versus-image conflict remains.
In one study, the rider’s susceptibility mattered more than display resolution. Hein et al. (2023) cite studies reporting motion sickness symptoms in 30 to 80% of VR users, depending on the application. In their own study of 146 participants, real-world susceptibility had a significant effect on symptoms, while higher resolution lowered nausea and hardly affected disorientation or eye strain. A 2018 review in Frontiers in Psychology finds that symptom severity rises with exposure time, though with no universal pattern, and that symptoms can last from 10 minutes to 4 hours after leaving VR. So ride duration and your guest mix shape the sickness outcome alongside the choice between headset and projector.
In a 2020 Frontiers study, an earth-fixed horizon line reduced visually induced motion sickness significantly, while an earth-fixed fixation cross and a head-fixed line did not. Even so, 8 of the 33 volunteers dropped out because of severe sickness, and the authors warn that their findings may only hold for mildly provocative stimuli. The authors suggest, as one possible explanation, that the horizon worked because it reached into the peripheral visual field, where the cross could not. That makes the edges of the headset’s view part of the comfort design, a point we cover in improving peripheral vision in VR for a wider field of view.
Which option produces fewer guest complaints and re-ride refusals at the same throughput?
The sources reviewed here measure neither complaint rates nor re-ride refusals for either approach, so this question has no evidence-based answer yet. On the positive side for headsets, Breda University of Applied Sciences (2018 to 2020, with Europa-Park) found presence was similar on VR and non-VR coaster rides and that riders evaluated the VR rides more positively. Against that, riders posting on a forum describe trains being emptied and cleaned after guests were sick on a VR coaster, and say a ride operator told them this happened “quite often”. Treat the complaint rate as a customer experience measure your pilot captures, not something you look up.
Can a headset ride reach 1,800 riders per hour once donning, cleaning and sync are counted?
A headset ride reaches 1,800 riders per hour only if every headset step fits inside the dispatch interval that target allows, and you can only find that out by timing it. Hourly capacity equals seats per vehicle × 3600 / dispatch interval in seconds, and Maurer Rides gives the example of a 10-seat vehicle dispatched every 20 seconds delivering 1,800 riders per hour. The number of vehicles you need equals cycle time (ride time plus station time) divided by the dispatch interval. Headset handling adds to station time. You pay for it with more vehicles at the same interval, or with a longer interval and lower capacity.
The reports below come from coasters, not dark rides, and several are rider anecdotes. Coaster101 describes sanitising and syncing that pushed train loads past 10 minutes. One CoasterBuzz rider estimated that the headgear more than quadrupled loading time. Another describes one train every seven to eight minutes on one VR coaster, against two to three minutes from stop to start at Europa-Park. A third rider reports a park expecting VR to cut capacity from 900 to 400 riders per hour, with real capacity nearer 300 because of unit problems. ASTM’s F24 committee lists capacity constraints, cleanliness and operational complexity as current challenges for VR and AR on rides.
Two designs tried to engineer some of this out. On SeaWorld’s Kraken, the headsets and their sync devices were fixed to the trains, so the ride never lost sync, but loading and cleaning stayed hard enough that the VR was removed. Battle for Eire, a motion-simulator ride, gives guests washable helmets before boarding and has them clip the seat-mounted VR unit onto the brim, so only the helmets need sanitising. Putting helmets on before boarding, as that design does, moves part of the donning off the vehicle. Where the dispatch interval drops below 20 seconds, Maurer recommends continuous loading, with vehicles moving through the station at up to 0.5 m/s under EN 13814 and ASTM. Whether riders can clip a headset in reliably on a moving vehicle at that speed is a question for the pilot.
Worked example: the dispatch interval a headset station has to fit
At a fixed target, the formula sets the longest dispatch interval you can afford: interval = seats × 3600 / target capacity.
| Seats per vehicle | Longest dispatch interval for 1,800 riders/hour | Working |
|---|---|---|
| 4 | 8 s | 4 × 3600 / 1800 |
| 8 | 16 s | 8 × 3600 / 1800 |
| 10 | 20 s | 10 × 3600 / 1800 |
| 12 | 24 s | 12 × 3600 / 1800 |
Every second of donning, sync confirmation, removal and wiping that happens on the vehicle uses up this interval, unless the vehicle count grows to absorb the longer cycle time. Projection puts no device on the rider, so it adds no station steps of its own.
How much longer does a vehicle dwell with headsets?
We are not aware of a published timed pilot that put real guests in headsets through a full load-ride-unload cycle on comparable dark ride hardware. The coaster figures above show large deltas, such as train loads past 10 minutes. They come from different headsets, sync methods and station layouts, so they cannot be carried over to your ride.
Which criteria should decide between real-time XR and pre-rendered projection when the ride has hard safety interlocks?
Three questions decide it: how much throughput margin the headset cycle leaves, whether the visual system can be kept out of the certified safety chain or certified within it, and how often the show content really needs to change. The table below sets out the full set of criteria.
| Criterion | Fixed pre-rendered projection | Real-time XR headsets | What settles it |
|---|---|---|---|
| Throughput | No extra station steps | Donning, sync and sanitising add station time; coaster reports show large capacity losses | Timed pilot at planned vehicle count |
| Shared experience | One image serves every rider in view | Typically one device per rider | Seats per vehicle and device count |
| Latency exposure | Fewer latency issues with slow, known-path scenery | Per-frame motion-to-photon latency and jitter on every headset | Per-frame latency distribution under load |
| Sickness drivers | Motion-image conflict remains | Adds sync loss and head-tracking delay | Interval sickness ratings in the pilot |
| Content updates | Major changes to pre-rendered clips need re-rendering and transcoding, per vendor disguise | Real-time content can change immediately | Planned update cadence; real-time projection is a third option |
| Lifespan and spares | Attractions are planned for 10 to 20 years or more (Mine et al.) | Spares and refresh plan over the ride’s life | |
| Safety analysis | Outside interlock logic if dispatch ignores it | Joins the failure analysis of safety-related systems if dispatch depends on headset state | FMEA or fault tree scope |
ASTM F2291-06 requires the manufacturer to carry out a failure analysis of the ride’s safety-related systems, using fault tree analysis, FMEA or another accepted engineering practice. Our view is that if any dispatch, hold or stop decision depends on headset state (all units synced, all units mounted), the whole headset and sync chain falls within that analysis. Every wireless link, file store and battery then becomes a failure mode you have to justify. The cleaner architecture keeps the visual system as an observed, logged subsystem that cannot block or trigger safety functions. Ride control then knows when sync has failed without depending on it. That is a strong default, not an absolute rule. Some ride concepts may need tighter coupling.
The standards landscape is also changing. ASTM reports that its F24.24 subcommittee has a task group on AR and VR that has written new requirements on equipment inertial effects and is drafting cleanliness protocols, and that F24 is developing a risk-assessment standard (WK78433) that covers new technology. Check the certification criteria with your certifying body before the pilot, not after it.
What latency and frame-drop limits must real-time XR hold on ride hardware?
Motion-to-photon latency is the delay between a movement, such as the head turning, and the matching change appearing on the display. The IEEE VR 2020 paper from Würzburg cites Mania et al. showing users detect head-tracking latency differences of 15 ms, so a 90 Hz display would cross that threshold if tracking data arrived even one frame late. In the same paper, a commercial HMD setup had a mean baseline latency of 56.14 ms with a standard deviation of 1.6 ms. Under full CPU and GPU load, the standard deviation grew to 8.62 ms. The authors found jitter even without load, and found that load raised jitter enough to cause dropped frames that a single mean value does not show.
For a ride specification, that means writing the limit as a distribution, with a ceiling on the worst stall, not as an average. The stall that made the Engadget reviewer sick lasted more than a second. The sources reviewed here give no guaranteed frame-drop or latency figures from production ride hardware that you could adopt as-is. Your limits have to come from measurements on your headset, your content and your vehicle. The Würzburg apparatus measures per-frame latency and, with adaptation, can be used on large-screen systems too, so the same method can measure both options.
How to validate the choice with a timed load-ride-unload pilot
The Frontiers in Psychology review recommends testing any new VR system on three temporal dimensions before rollout: how symptoms progress, whether riders adapt, and how long symptoms last afterwards. Add station timing and sync logging to that and you have a pilot that settles the throughput and comfort questions together:
- Fix the configuration. Use the production headset model, sync method, vehicle and station layout, so the pilot measures the configuration you will run.
- Screen and stratify riders. Give participants the Motion Sickness Susceptibility Questionnaire, and its visually induced counterpart VIMSSQ, so results can be read by susceptibility group.
- Time every station step separately. Record boarding, donning or clip-in, sync confirmation, removal, sanitising and battery swaps for each vehicle, including failures and retries. Then work out capacity as seats × 3600 / the dispatch interval you actually achieved.
- Log sync health on every seat. Record dropouts, stalls and content faults by seat position, since Six Flags staff said some seats lost sync more often than others.
- Rate sickness during and after the ride. The Fast Motion Sickness Scale runs from 0 to 20 and can be given every 60 seconds during the experience. The review advises comparing SSQ scores across time periods and monitoring for hours afterwards.
- Treat first rides with care. One study cited in the review stresses close monitoring, shorter trials and longer rests for first immersions.
- Run the projection baseline through the same protocol. Without it, the headset numbers have nothing to be compared against.
A simulation can narrow the options before the pilot, but it is only as good as its assumptions about how guests don headsets and how often units fail. Those assumptions are exactly what the pilot measures. The decision rule follows. If the headset cycle, including donning and sync, meets the dispatch interval with margin, sickness ratings are acceptable for your guest mix, and the sync chain stays outside the interlocks, XR is viable. If not, choose projection, and consider real-time projection if update flexibility was the reason for looking at headsets in the first place.
One question is still open after a successful pilot: whether the headset fleet, its spares and its content pipeline will last as long as the ride, which is planned in decades.
