VR系列——Oculus最佳实践：七、虚拟幻境头晕（上）

• “虚拟幻境头晕”指的是使用模拟环境所引起的不适。
• 视觉和身体感官之间的不协调是造成不适的最终原因。
• 有很多因素造成虚拟幻境头晕，包括但不限于以下几点
  
  • 加速：减少加速度的大小和频率
  • 控制程度：不要剥夺用户的控制权
  • 持续时间：允许并鼓励用户休息
  • 高度：避免让地面直接填充视野
  • 双眼视差：有些人发现观看立体图像会不舒服
  • 视野：减少虚拟环境覆盖的虚拟视野大小可能会减少舒适度
  • 延迟：最小化延迟，在VR中滞后或失帧易感觉不适
  • 失真校正：使用Oculus VR的失真着色器
  • 闪烁：不显示闪烁的图像或细微的重复纹理
  • 体验：VR的体验会使你对虚拟幻境头晕有抵抗力（这是开发者最糟糕的测试对象）
• 已经从锁定玩家的惯性参照背景中发现能够有效降低虚拟幻境头晕症状。
• 为了在VR中有个更换的舒适感，各种方法正在不断被探索。
• 在收集数据来研究如何让你的体验更舒适时，SSQ可以作为数据收集的一种方法。

描述

虚拟幻境头晕是视觉诱发运动疾病的一种，这个与日常的晕动病是不同的。而晕动症是人们在实际运动中最熟悉的结果（诸如在船上漂泊会晕船），虚拟幻境头晕的主要不适感发生在当一个模拟环境下的视觉信息信号自移动时缺乏实际的移动。在任一情况下，如果在视觉、前庭（平衡）和本体（身体位置）感知下存在冲突，就会加大不适感。此外，虚拟幻境头晕包括一些症状，这些症状在使用虚拟环境是特有的，例如眼睛紧张/疲劳（虽然跟身体不适的原因可以不一致）。一些用户在使用耳机的短时间内会体验到某种程度的虚拟幻境头晕，而其他人可能从未感受到。

虚拟幻境头晕给用户和开发商带来一样严重的问题;不管你的内容多么得有吸引力或用户多么迫切想要要欣赏，几乎没有人愿意忍受虚拟幻境头晕带来的不适。因此，了解它的起因以及实现策略来减少它的发生是很重要的。不幸的是，虚拟幻境头晕（实际上包括所有的晕动症）的确切原因仍在研究。虚拟幻境头晕有个复杂的病因，这些因子对于引起不适是充足的但不是必须的，而且真正的“治疗”它需要解决他们所有。

虚拟幻境头晕是由一系列的症状引起，但主要特征在于迷失方向（包括共济失调，打乱平衡的感觉），恶心（应该是病原体引起，自动的虚幻知觉）和动眼神经不适（例如，眼睛疲劳）。这些都体现在虚拟幻境头晕问卷分量上（SSQ），[1]研究人员用来评估在虚拟环境用户的症状。

导致虚拟幻境头晕的因素

去追查引起虚拟幻境头晕的一个特定起因是困难的;不同的用户有不同的体验，对不同类的刺激的灵敏度是变化的，且症状需要一段时间来体现（可能是几分钟或者几小时）。作为一个VR设计师，你将花费很长一段时间沉浸在虚拟现实和长时间停留在虚拟环境，这样会导致大脑对结果不敏感。[2]同样地，专用VR开发人员相对大部分用户不会明显感觉到虚拟幻境头晕。在没有获得来自有经验的用户的反馈而直接从你的内容客观地预测用户是否将经历不适是很困难的。

在人群中每个人对晕动症的感受度是不同的，而且与一系列的虚拟幻境头晕经验强度有关。[3]这意味着那些经常在汽车、游乐设施或其他环境下感受到晕动的用户将会谨慎使用Rift。运用本手册中的建议可以提供帮助。

以下部分列出了已经在研究中的，对虚拟幻境头晕有潜在帮助的因素。部分因素相对其他因素比较不受开发者控制，但了解它们可以帮你最大限度地减少用户不适。还要注意的是一些这方面的信息与其他部分重叠，但这方面的信息为它们在虚拟幻境头晕上提供了更详尽的说明。

移动的速度和加速速度

移动的速度直接正向影响引起虚拟幻境头晕的速度，但连续得增加强度和速率也不会一定会引起不适。[4]尽管速度较慢的移动速度通常会感觉更舒适，但真正要注意的是加速，它会刺激前庭器官内耳回应。加速度（线性或角度，在任何方向上）从视觉传达而不是前庭器官构成了感官的冲突，这冲突导致不适。对于相同的运动速度，一个瞬间的急促加速相对缓慢的加速会舒适得多。

不适感会随着频率，大小和持续时间的加速度而增加。因为任何时间的视觉呈现加速代表了一个时期的感官之间的冲突，最好是尽可能得避免它们。

注意：前庭器官对不变的速度不会有回应，所以不变的视觉运动意味着会减少感官之间的冲突。

控制程度

不让用户控制camera或让其不在用户启动的路线移动会导致虚拟幻境头晕。一些理论认为，提前预测和控制的能力在避开晕动症上发挥着作用，[5]这个原则似乎也适用于虚拟幻境头晕。因此，意外的相机移动（或停止移动）一旦超出用户的控制范围就会有不适感。同样的，这也就预示着即将到来的相机移动的虚拟形象可以帮助用户预测和为视觉运动做准备，有可能改善用户的体验舒适度。[6]

如果你有一个重要的事件让用户观看（如过场动画或重要的环境事件），应避免将注意力转到这些事件；相反，尝试提议让事件本身为自己聚焦， 例如，通过具有非玩家角色（NPC）望着它，通过声音效果把这些角色插入事件中，或通过将一些任务相关的目标（如敌人或采样器）放置在它附近。

如前所述，在虚拟环境中，不要将用户的运动从相机运动中脱离。

持续时间

在虚拟环境中逗留越久，越会感觉到虚拟幻境头晕。用户应该可以随意终止游戏，之后可以返回到他们闲暇时离开的那个确切点。适时得建议用户稍事休息，例如在游戏中已保存的一个时间点或休息点，是一个比较好的时间去提醒那些有可能沉溺的用户。

高度

用户的高度 - 即用户视点（POV）的高度 – 会是引起虚拟幻境头晕的间接因素。用户视点越低，越能感觉地平面变化，当用户的视野迅速的充满整个视点时越能创造一个强烈的视觉流画面。就如把楼梯往上移也会产生视野上的强烈的视觉流从而产生不适感。

双目视差

虽然双目视差是Rift关键的引人注目的深度线索之一，它也不是没有成本的。如Binocular Vision, Stereoscopic Imaging and Depth Cue这本书第10页所描述的，立体图像可以强制目光汇聚在一个深度的点上当眼睛投向其他地方时（聚焦在它本身）。虽然你在VR里必然使用全方位深度，但是把内容放在用户后续时间里有可能聚焦的在范围0.75至3.5统一单位（米）的距离点是很重要的（如菜单或第三人的头像）。

有些人觉得观看立体图像不舒服，研究已经表明，减少图像之间视差的程度（即，减少了摄像头间的距离）来创建一个单视场[7]（即，零相机间的距离）或微型立体 [8]（即，减少的相机间的距离）显示可以使体验更加舒适。在Rigt中，把任何规模的IPD应用在整个头部模型中是很重要的。

正如所叙述的，你应该从配置上在Rigt中根据用户的IPD来设置内部相机距离来达成深度和广度上真实的直觉。应用于眼分离的任何方面的因子（照相机的距离）也必须应用到整个头部模型，使头部运动相当于虚拟渲染相机的运动。

视野

视野可以参考这2种视野类型：对向显示的视野区域（通常叫做‘显示器FOV’ 或者在这份指南中叫做‘dFOV’），还有图形引擎绘制到显示器的虚拟环境区域（我们叫做’ 照相机FOV’ 或者 cFOV）.

一个宽的dFOV比较可能是造成虚拟幻境头晕的2个原因中的主要原因。首先，运动知觉在外围更敏感，使得使用者特别容易在外围区域受到光流和微妙闪烁的影响。其次，当完全使用其显示时，更大的显示器FOV比较小的显示器FOV为视觉系统提供更多的输入。当那么多的视觉输入暗示用户他们正在移动，它代表着和身体(例如，前庭和本体感受的)感觉的激烈冲突，这会导致不适。

减少显示器FOV可以减少虚拟幻境头晕症状【9】，但是同样会降低对Rift的沉浸和态势感知水平。为了妥协让敏感用户更好地去适应，你应该允许用户调节显示器FOV。屏幕上的内容能见度不应该受到改变显示器FOV的不利影响。

拥有一个驾驶舱或车辆会将周边的对流运动隐藏，因为同样的原因也会带来类似的好处。同样要注意这个小于用户环境的视野，更多的他们必须移动他们的头部或虚拟相机以保持情境意识，这同样会增加不适感。

操纵照相机FOV会导致虚拟环境为了相应头部移动的不自然移动（例如，如果头部在虚拟世界产生10度的旋转，通常在现实中需要旋转15度才能达到）。除了令人不安之外，这也可能会导致短暂但会有被称为前庭眼反射（VOR）的不适应状态增益调整【10】。你的眼睛和前庭系统正常工作，共同确定有多少眼睛必须按头部移动顺序保持在一个固定的对象上。

如果虚拟环境导致这种反射使得保持平稳固定失败，它可能会导致两纵内侧和终止使用后不舒服的重新校准过程。

延迟和滞后

虽然开发商无法控制许多方面的系统延迟（如显示更新率和无法控制硬件等待时间），确保你的VR体验不会延迟或系统上丢帧来符合最低技术规范要求是非常重要。很多游戏可以减慢作为大多数结果或者更复杂的元素被处理或渲染到屏幕上；虽然在传统的视频游戏上，这只是一个小麻烦，但在VR上会对用户造成不舒服的影响。

对延迟的影响，过去的研究结果是好坏参半。许多专家建议最小化延迟来减少虚拟幻境头晕，因为头部运动和相应的显示器的滞后更新之间会导致在前庭眼反射感官冲突和错误。因此，我们鼓励尽可能的最小化延迟。

值得注意的是，一些关于头戴式显示器研究建议：创建一个相同程度的虚拟幻境头晕的固定延迟，无论是短至48毫秒或长至300毫秒；【11】然而，在驾驶舱和驾驶模拟器的可变和不可预知的延迟比平均水平创造了更多的不适。【12】这表明，人们最终可以习惯滞后的一致和可预测位，但波动的是，不可预测的滞后使得越来越令人不安的时间越长了，他们成为平均水平。

仍存在的是，调整延迟（现实世界与虚拟世界的差异）是一个不舒服的过程，它会导致当用户离开Rift之后回到真实世界时进一步的不适。这个体验类似于陆陆续续的上下游轮，经过一段时间距离的摇摆晕车感觉，很多人习惯了之后，震荡运动和晕船消失；然而，在返回坚实的土地之后，其中许多相同的人会真正体验到”disembarkment 病” ，因为身体又必须再调整一次适应新的环境。【13】

进入和退出VR之间让身体调整的越少，效果就越好。开发者敦促使用内置在DK2的延迟测试仪来测量运动到光子延迟，以确保尽可能的短和一致。其更多的使用说明在SDK中有提供。

---

原文如下

• “Simulator sickness” refers to symptoms of discomfort that arise from using simulated environments.
• Conflicts between the visual and bodily senses are to blame.
• Numerous factors contribute to simulator sickness, including but not limited to…
  
  • Acceleration: minimize the size and frequency of accelerations
  • Degree of control: don’t take control away from the user
  • Duration of simulator use: allow and encourage users to take breaks
  • Altitude: avoid filling the field of view with the ground
  • Binocular disparity: Some find viewing stereoscopic images uncomfortable
  • Field-of-View: reducing the amount of visual field covered by the virtual environment may also reduce comfort
  • Latency: minimize it—lags/dropped frames are uncomfortable in VR
  • Distortion correction: use Oculus VR’s distortion shaders
  • Flicker: do not display flashing images or fine repeating textures
  • Experience: experience with VR makes you resistant to simulator sickness (which makes developers the
    worst test subjects)
• Locking the background to the player’s inertial reference frame has been found to be effective at reducing simulator sickness.
• Various methods are currently being explored for greater comfort in VR.
• The SSQ can be used as a means of gathering data on how comfortable your experience is.

Description

Simulator sickness is a form of visually inducedmotion sickness, which differs crucially from your everyday motion sickness. Whereas the motion sickness with which people are most familiar results from actual motion (such as the bobbing of a boat that causes seasickness), the primary feelings of discomfort associated with simulator sickness occur when visual information from a simulated environment signals self-motion in the absence of any actual movement. In either case, there are conflicts among the visual, vestibular (balance), and proprioceptive (bodily position) senses that give rise to discomfort. Furthermore, simulator sickness includes symptoms that are unique to using a virtual environment, such as eye strain/fatigue (though not necessarily for the same reason as bodily discomfort). Some users will experience some degree of simulator sickness after a short period of time in a headset, while others may never experience it.

Simulator sickness poses a serious problem to users and developers alike; no matter how fundamentally appealing your content is or how badly a user wants to enjoy it, almost no one wants to endure the discomfort of simulator sickness. Therefore, it is extremely important to understand its causes and implement strategies to minimize its occurrence. Unfortunately, the exact causes of simulator sickness (and in fact all forms of motion sickness) are still being researched. Simulator sickness has a complex etiology of factors that are sufficient but not necessary for inducing discomfort, and truly “curing” it requires addressing them all.

Simulator sickness is comprised of a constellation of symptoms, but is primarily characterized by disorientation (including ataxia, a sense of disrupted balance), nausea (believed to stem from vection, the illusory perception of self-motion) and oculomotor discomfort (e.g., eyestrain). These are reflected in the subscales of the simulator sickness questionnaire (SSQ),[1] which researchers have used to assess symptomatology in users of virtual environments.

Factors Contributing to Simulator Sickness

It can be difficult to track down a particular cause for simulator sickness; different users will have different experiences, sensitivity to different types of stimuli can vary, and the symptoms can take a while (anywhere from minutes to hours) to manifest. As a VR designer, you will be spending long periods of time immersed in VR, and long exposure to virtual environments can train the brain to be less sensitive to their effects.[2] As such, dedicated VR developers will be less susceptible to simulator sickness than most users. Objectively predicting whether a user will experience discomfort from your content without obtaining feedback from inexperienced users can be difficult.

Motion sickness susceptibility is widely variable in the population and correlates with the intensity of subsequent simulator sickness experiences.[3] This means users who know they tend to experience motion sickness in vehicles, rides, and other contexts should approach using the Rift carefully. Applying the recommendations throughout this manual can help.

The following section lists factors that have been studied as potential contributors to simulator sickness. Some factors are less under the designer’s control than others, but understanding them can help you minimize user discomfort. Also note that some of this information overlaps with other sections, but this section offers more elaborated explanations for their role in simulator sickness.

Speed of Movement and Acceleration

Speed of movement is directly proportional to the speed of onset for simulator sickness, but not necessarily the subsequent intensity or rate of increase.[4] Although slower movement speeds will generally feel more comfortable, the real enemy to beware is acceleration, the stimulus to which the vestibular organs inside the inner ear respond. Acceleration (linear or angular, in any direction) conveyed visually but not to the vestibular organs constitutes a sensory conflict that can cause discomfort. An instantaneous burst of acceleration is more comfortable than an extended, gradual acceleration to the same movement velocity.

Discomfort will increase as a function of the frequency, size, and duration of acceleration. Because any period of visually-presented acceleration represents a period of conflict between the senses, it is best to avoid them as much as possible.

Note: The vestibular organs do not respond to constant velocity, so constant visual motion represents a smaller conflict for the senses.

Degree of Control

Taking control of the camera away from the user or causing it to move in ways not initiated by the user can lead to simulator sickness. Some theories suggest the ability to anticipate and control the motion experienced play a role in staving off motion sickness,[5] and this principle appears to hold true for simulator sickness, as well. Therefore, unexpected camera movement (or cessation of movement) outside the user’s control can be uncomfortable. Having an avatar that foreshadows impending camera movement can help users anticipate and prepare for the visual motion, potentially improving the comfort of the experience.[6]

If you have a significant event for the user to watch (such as a cutscene or critical environmental event), avoid moving their gaze for them; instead, try to provide suggestions that urge them to move gaze themselves, for example by having non-player characters (NPCs) looking towards it, cuing them to events with sound effects, or by placing some task-relevant target (such as enemies or pick-ups) near it.

As stated previously, do not decouple the user’s movements from the camera’s movements in the virtual environment.

Duration

The longer you remain in a virtual environment, the more likely you are to experience simulator sickness. Users should always have the freedom to suspend their game, then return to the exact point where they left off at their leisure. Well-timed suggestions to take a break, such as at save points or breaks in the action, are also a good reminder for users who might otherwise lose track of time.

Altitude

The altitude of the user — that is, the height of the user’s point of view (POV) — can be an indirect factor in simulator sickness. The lower the user’s POV, the more rapidly the ground plane changes and fills the user’s FOV, creating a more intense display of visual flow. This can create an uncomfortable sensation for the same reason moving up staircases, which also creates an intense visual flow across the visual field, is so discomforting.

Binocular Display

Although binocular disparity is one of the Rift’s key and compelling depth cues, it is not without its costs. As described in Binocular Vision, Stereoscopic Imaging and Depth Cues on page 10, stereoscopic images can force the eyes to converge on one point in depth while the lens of the eye accommodates (focuses itself) to another. Although you will necessarily make use of the full range of depth in VR, it is important to place content on which you know users will be focusing for extended periods of time (such as menus or a 3rd-person avatar) in a range of 0.75 to 3.5 Unity units (meters) away.

Some people find viewing stereoscopic images uncomfortable, and research has suggested that reducing the degree of disparity between the images (i.e., reducing the inter-camera distance) to create a monoscopic[7] (i.e., zero-inter-camera distance) or microstereoscopic[8] (i.e., reduced inter-camera distance) display can make the experience more comfortable. In the Rift, it is important that any scaling of the IPD is applied to the entire head model.

As stated elsewhere, you should set the inter-camera distance in the Rift to the user’s IPD from the config tool to achieve a veridical perception of depth and scale. Any scaling factors applied to eye separation (camera distance) must be also applied to the entire head model so that head movements correspond to the appropriate movements of the virtual rendering cameras.

Field of View

Field of view can refer to two kinds of field of view: the area of the visual field subtended by the display (which we call “display FOV” or dFOV in this guide), and the area of the virtual environment that the graphics engine draws to the display (which we call “camera FOV” or cFOV).

A wide dFOV is more likely to cause simulator sickness primarily for two reasons related to the perception of motion. First, motion perception is more sensitive in the periphery, making users particularly susceptible to effects from both optic flow and subtle flicker in peripheral regions. Second, a larger display FOV, when used in its entirety, provides the visual system with more input than a smaller display FOV. When that much visual input suggests to the user that they are moving, it represents an intense conflict with bodily (i.e., vestibular and proprioceptive) senses, leading to discomfort.

Reducing display FOV can reduce the experience of simulator sickness,[9] but also reduces the level of immersion and situational awareness with the Rift. To best accommodate more sensitive users who might prefer that compromise, you should allow for user-adjustable display FOV. Visibility of on-screen content should not be adversely affected by changing display FOV.

Having a cockpit or vehicle obscuring much of the vection-inducing motion in the periphery may also confer a similar benefit for the same reasons. Note also that the smaller the user’s view of their environment, the more they will have to move their head or virtual cameras to maintain situational awareness, which can also increase discomfort.

Manipulating camera FOV can lead to unnatural movement of the virtual environment in response to head movements (for example, if a 10° rotation of the head creates a rotation of the virtual world that would normally require a 15° rotation in reality). In addition to being discomforting, this can also cause a temporary but maladaptive condition known as vestibular-ocular reflex (VOR) gain adaptation.[10] Your eyes and vestibular system normally work together to determine how much the eyes must move during a head movement in order to maintain stable fixation on an object. If the virtual environment causes this reflex to fail to maintain stable fixation, it can lead to an uncomfortable re-calibration process both inside the Rift and after terminating use.

Latency and Lag

Although developers have no control over many aspects of system latency (such as display updating rate and hardware latencies), it is important to make sure your VR experience does not lag or drop frames on a system that meets minimum technical specification requirements. Many games can slow down as a result of numerous or more complex elements being processed and rendered to the screen; while this is a minor annoyance in traditional video games, it can have an uncomfortable effect on users in VR.

Past research findings on the effects of latency are somewhat mixed. Many experts recommend minimizing latency to reduce simulator sickness because lag between head movements and corresponding updates on the display can lead to sensory conflicts and errors in the vestibular-ocular reflex. We therefore encourage minimizing latency as much as possible.

It is worth noting that some research with head-mounted displays suggests a fixed latency creates about the same degree of simulator sickness whether it’s as short as 48 ms or as long as 300 ms;[11] however, variable and unpredictable latencies in cockpit and driving simulators create more discomfort the longer they become on average.[12] This suggests that people can eventually get used to a consistent and predictable bit of lag, but fluctuating, unpredictable lags are increasingly discomforting the longer they become on average.

Still, adjusting to latency (and other discrepancies between the real world and VR) can be an uncomfortable process that leads to further discomfort when the user adjusts back to the real world outside of the Rift. The experience is similar to getting on and off a cruise ship. After a period feeling seasick from the rocking of the boat, many people become used to the regular, oscillatory motion and the seasickness subsides; however, upon returning to solid land, many of those same people will actually experience a “disembarkment sickness” as the body has to readjust once again to its new environment.[13]

The less you have to make the body adjust to entering and exiting VR, the better. Developers are urged to use the built-in latency tester of the DK2 to measure motion-to-photon latency to ensure it is as short and consistent as possible. Further documentation on its use is available in the SDK.