VR系列——Oculus Rift 开发者指南：二、初始化和传感器枚举

初始化和传感器枚举

这是初始化LibOVR的例子，需要可用HMD的相关知识。

看以下的代码：

// 引用OculusVR SDK#include <OVR_CAPI.h>void Application() {    ovrResult result = ovr_Initialize(nullptr);    if (OVR_FAILURE(result))    return;    ovrSession session;    ovrGraphicsLuid luid;    result = ovr_Create(&session, &luid);    if (OVR_FAILURE(result)) {        ovr_Shutdown();        return;    }    ovrHmdDesc desc = ovr_GetHmdDesc(session);    ovrSizei resolution = desc.Resolution;    ovr_Destroy(session);    ovr_Shutdown();}

正如你所看到的，ovr_Initialize被调用于任何其他API方法之前，且在你退出程序之前，ovr_Shutdown被调用以关闭库。在这些方法调用之间，你可以任意创建HMD对象、访问跟踪状态、执行应用程序渲染。

在这个例子中，ovr_Create(&session &luid)创建了HMD。使用它返回的LUID，为ID3D11设备创建的物体选择IDXGI适配器。最后，必须调用ovr_Destroy，在关闭库之前清除HMD。

你可以使用ovr_GetHmdDesc()获取HMD的描述。

如果没有Rift插入，ovr_Create(&session, &luid)将返回一个失败的ovrResult，除非通过RiftConfigUtil，使得有一个虚拟的HMD可用。虽然虚拟的HMD不支持任何的传感输入，但是它对调试Rift兼容的渲染代码、对没有物理设备的一般开发，是很有用的。

HMD的描述（ovrHmdDesc）句柄可以使用ovr_GetHmdDesc(session)检索。

以下的表格描述了这些字段：

字段 类型 描述 Type ovrHmdType HMD的类型，如ovr_DK1或ovr_DK2。 ProductName char[] 产品的名称。 Manufacturer char[] 生产商的名称。 VendorId short 头戴USB设备返回的供应商ID。 ProductId short 头戴USB设备返回的产品ID。 SerialNumber char[] 头戴USB设备返回的序列数字串。 FirmwareMajor short 传感器固件的主版本号。 FirmwareMinor short 传感器固件的次版本号。 CameraFrustumHFovInRadians float 位置跟踪视锥体的水平镜头视角。 CameraFrustumVFovInRadians float 位置跟踪视锥体的垂直镜头视角。 CameraFrustumNearZInMeters float 从位置跟踪器到近视锥体边缘的距离。 CameraFrustumNearZInMeters float 从位置跟踪器到远视锥体边缘的距离。 AvailableHmdCaps unsigned int HMD目前支持的能力，由ovrHmdCaps描述。 DefaultHmdCaps unsigned int 目前HMD的默认能力，由ovrHmdCaps描述。 AvailableTrackingCaps unsigned int HMD目前支持的能力，由ovrTrackingCaps描述。 DefaultTrackingCaps unsigned int 目前HMD的默认能力，由ovrTrackingCaps描述。 DefaultEyeFov ovrFovPort[] 每只眼睛视野的建议光域。 MaxEyeFov ovrFovPort[] 视野光域的最大值，可以（将画面）尽可能地呈现给每只眼睛。 Resolution ovrSizei 全HMD屏幕（两只眼睛）的像素分辨率。 DisplayRefreshRate float 在HMD创建时的HMD理论每秒刷新率。

头部跟踪及传感器

Oculus Rift硬件包含一些微电子机械（MEMS）传感器，包括陀螺仪、加速度计和磁力计。

从DK2开始，还有一个跟踪头戴设备位置的跟踪器。从这每一个传感器获取的信息，通过传感器融合过程被合并，以确定真实世界中用户头部的动向，并同步实时的用户视图。

默认情况下，SDK将使所连接的HMD的所有可用跟踪功能有效。如果你想切换跟踪功能，你可以调用ovr_ConfigureTracking。这个方法有以下特点：

ovrResult ovr_ConfigureTracking(    ovrSession session, unsigned int requestedTrackingCaps,      unsigned int requiredTrackingCaps);

ovr_ConfigureTracking需要两套能力标识作为输入。它们都使用ovrTrackingCaps中声明的标识。supportedTrackingCaps描述了HMD可用时使用的跟踪能力。在调用应用时由HMD支持的、使操作能正确的能力，是由requiredTrackingCaps指定。如果所要求的能力不存在，调用ovr_ConfigureTracking会失败。

一旦ovrSession被创建，你可以通过调用ovr_GetTrackingState，轮询头部位置和定位的传感器融合。调用如下代码所示：

// 查询HMD当前的跟踪状态.ovrTrackingState ts = ovr_GetTrackingState(session, ovr_GetTimeInSeconds());if (ts.StatusFlags & (ovrStatus_OrientationTracked | ovrStatus_PositionTracked)){    Posef pose = ts.HeadPose;    ...}

该例子是在只要求基础定位跟踪时，使用定位器、偏航校正和位置跟踪能力（如果可用）初始化传感器。这意味着代码对DK1有效，但是将自动使用DK2基于跟踪器的位置跟踪。如果你正在使用一个DK2的头戴设备，但是在调用期间DK2的跟踪器不可用，在后续才会插入，那么跟踪器由SDK自动启用。

在传感器初始化后，通过ovr_GetTrackingState可以获取传感器状态。这状态包括由StatusFlags描述的预期头部姿势以及当前HMD跟踪状态。状态可以基于可用的设备和用户的行为，在运行时变更。以DK2为例，ovrStatus_PositionTracked的标志只有在HeadPose包含源于跟踪器的绝对位置跟踪数据时，才会上报。

上报的ovrPoseStatef包括全部6个自由度（6DoF）的头部跟踪数据，包括定位、位置、以及它们的第一和第二阶导数。该位置值上报以确定用于预测的特定绝对时间点，通常对应于这一帧图像将要展示在屏幕上的未来时间。为了有助于预测，ovr_GetTrackingState使用很短的绝对时间，作为第二个参数。绝对时间的当前值可以通过调用ovr_GetTimeInSeconds来获得。如果传入ovr_GetTrackingState的时间是当前或更早的时间，返回的跟踪状态将是基于传感器最后读到的无预测的值。然而，在产品应用中，你应该使用由GetPredictedDisplayTime返回的实时计算值。在帧计时之内，预测过程将被更多细节覆盖。

正如之前讨论过的，报告包括一个三维位置矢量和方位四元数。定位报告为右手坐标系的旋转，如下图所示。

图一：Rift坐标系统

x-z平面是与水平面对齐，而与相机定位无关

• 自下向上是Y轴的正方向
• 自左向右是X轴的正方向
• 自前向后脑方向是Z轴的正方向

旋转作为一个单位四元数，也可以通过三维空间的右手笛卡尔坐标表示（ yaw-pitch-roll）。当你朝着每个坐标轴负方向看时，是按逆时针方向旋转（图中的旋转箭头的方向是逆时针的）

• 俯仰（pitch）是绕着X轴旋转，也叫俯仰角，正向转动时就抬头
• 偏航（yaw）是绕着Y轴旋转，也叫偏航角，正向转动时就向左转
• 翻滚（roll）是绕着Z轴旋转，也叫翻滚角，正向转动就是让XY组成的面向左偏转

最简单的从ovrPose获取俯仰角、偏航角和翻滚角的方法是利用C++的包含库的数学辅助类。下面的示例就是直接将指定的ovrPosef转化为等价的C++ Posef类，你也可以使用Quatf::GetEulerAngles<>来直接获取所需的欧拉角。

为方便开发者和操作者的使用，所有OVR提供的简单的C数学类型，比如ovrvector3f和ovrquatf都有相对应的C++类，这些类型可以相互转化。

位置追踪

这个视景是由水平、垂直视野和前后的水平距离定义的。

这些参数的近似值可以通过ovrHmdDesc的结构体访问到，如下所示：

ovrSession session;                                                        ovrGraphicsLuid luid;                                                        if(OVR_SUCCESS(ovr_Create(&session, &luid)))                                {                                                                           // Extract tracking frustum parameters.                                          float frustomHorizontalFOV = session->CameraFrustumHFovInRadians;            ...      

下图显示了DK2位置追踪器安装在PC机的监控和结果跟踪的视觉表现

图2：位置跟踪摄像机和跟踪台

相关参数和典型值如下：

Field Type Typical Value CameraFrustumHFovInRadians float 1.292 radians (74 degrees) CameraFrustumVFovInRadians float 0.942 radians (54 degrees) CameraFrustumNearZInMeters float 0.4m CameraFrustumFarZInMeters float 2.5m

这些参数使得应用开发者能够提供可视化的跟踪体。之前的数据也展示了默认的跟踪源和对应的坐标系统。

注：虽然跟踪器轴（以及跟踪台）看起来稍微往下倾斜，但是追踪坐标系始终向水平状态调整，因此坐标轴始终与地面平行。

默认情况下，追踪源位于追踪器视轴方向一米远的地方，而高度与追踪器一致。
默认的源方向与地面在同一个水平线上，并且负轴指向追踪器。
换句话说，0度的头戴式偏航角相当于用户望向追踪器。

注：这个可以通过API调用ovr_RecenterPose 重置追踪源到头戴式设备的当前位置，并且设置偏航起源到当前头戴式设备的偏航值。注：追踪源被设置在每一个基础应用上；在不同的VR应用间切换焦点同时切换追踪源。

通过调用ovr_GetTrackingState来返回头部姿势，返回的ovrTrackingState数据结构包含多个与追踪位置相关的项：

• HeadPose-包括头的位置和方向；
• CameraPose-与追踪源相关的追踪器的状态；
• LeveledCameraPose-与追踪源相关的追踪器的状态，并且翻滚角和俯仰角为零。你可以把它当作一个参照点，在正确的位置上来渲染真实世界的物体。

StatusFlags变量包含三个与位置追踪相关的状态位：

• ovrStatus_PositionConnected-当位置追踪器已连接并且正常运行时，设置该状态位；
• ovrStatus_PositionTracked-该状态位只有当头戴式设备被追踪时设置；
• ovrStatus_CameraPoseTracked-在追踪器初始化后设置。一般情况下，在开始追踪后一秒左右，要求头戴式设备在视野范围内合理固定。如果在进入VR后，ovrStatus_CameraPoseTracked 标志没有被迅速设置的话，及时告知用户是非常必要的。

有些情况会导致位置追踪被中断，进而导致标志被置零：
- 头戴式设备部分或全部被移动到追踪范围之外；
- 头戴式设备采用了一个不容易被现有的硬件追踪到的方向（比如背对追踪器）；
- 从追踪器的角度来看，头戴式设备的表面被部分或者完全遮挡（比如头发或手）；
- 头戴式设备的速度超出了预期范围。

假设上面的那些情况不存在，在被干扰之后，追踪器快速恢复正常并且重置ovrStatus_PositionTracked。

用户输入设置

为了给玩家提供最舒服、最直观、最有效的交互效果，头戴式追踪器需要为大部分应用集成一个现有的控制算法。

例如，在一个第一人称射击游戏（FPS）中，玩家一般使用左操作杆向前、后、左、右移动，使用右操作杆向左看、向右看、向上看、向下看。使用Rift的时候，玩家可以使用他们的头向左看、向右看、向上看、向下看。然而，玩家不应该频繁地180转动头部，因为这样会给玩家造成不好的体验。通常地，他们在VR时需要调整自身，这样他们才会感觉舒适（如果想要向后匆匆一瞥，需要转动我们的身体，是同一个道理）

概括来说，开发人员在为VR设计应用程序的时候，需要认真考虑他们的控制算法以及如何结合头部追踪。OculusRoomTiny 应用提供了示例源码，描述了如何整合Oculus 头戴式追踪器以及上述标准的FPS控制算法。

更多关于好的和坏的实践信息，请查看《Oculus Best Practices Guide》。

关于健康和安全的警告

使用设备时，所有使用Oculus Riftd的应用程序显示健康和安全警告。

当Rift第一次展示VR场景时，会短暂的出现警告，当按下按键或者轻拍头戴式设备时消失。目前，用户第一次配置一个新的配置3秒后，该警告显示至少15秒。

该警告自动显示为一图层。

健康与安全预警可以通过Oculus配置应用程序禁用。在注意安全和健康的同时，请注意，当警示语在屏幕上消失的同时，你同意了你所看到的警告，并且其他人在没有读到警告的时候不会使用头戴式设备。

使用Oculus配置实用程序来取消健康和安全警告窗口的弹出，Windows版本必须添加注册表项，非windows版本需要添加一个环境变量

对于windows，必须要添加下面的注册表值：

HKEY LOCAL MACHINE\Software\Wow6432Node\Oculus VR, LLC\LibOVR\HSWToggleEnabled

在Oculus的配置项中的高级设置面板中，设定HSWToggleEnabled的值为1，可以禁用健康和安全警告。对于非Windows版本，您必须创建一个值为“1”的变量Oculus LibOVR HSWToggleEnabled。

---

原文如下

Initialization and Sensor Enumeration

This example initializes LibOVR and requests information about the available HMD.

Review the following code:

// Include the OculusVR SDK#include <OVR_CAPI.h>void Application() {    ovrResult result = ovr_Initialize(nullptr);    if (OVR_FAILURE(result))    return;    ovrSession session;    ovrGraphicsLuid luid;    result = ovr_Create(&session, &luid);    if (OVR_FAILURE(result)) {        ovr_Shutdown();        return;    }    ovrHmdDesc desc = ovr_GetHmdDesc(session);    ovrSizei resolution = desc.Resolution;    ovr_Destroy(session);    ovr_Shutdown();}

As you can see, ovr_Initialize is called before any other API functions and ovr_Shutdown is called to shut down the library before you exit the program. In between these function calls, you are free to create HMD objects, access tracking state, and perform application rendering.

In this example, ovr_Create(&session &luid) creates the HMD. Use the LUID returned by ovr_Create() to select the IDXGIAdapter on which your ID3D11Device is created. Finally, ovr_Destroy must be called to clear the HMD before shutting down the library.

You can use ovr_GetHmdDesc() to get a description of the HMD.

If no Rift is plugged in, ovr_Create(&session, &luid) returns a failed ovrResult unless a virtual HMD is enabled through RiftConfigUtil. Although the virtual HMD will not provide any sensor input, it can be useful for debugging Rift-compatible rendering code and for general development without a physical device.

The description of an HMD (ovrHmdDesc) handle can be retrieved by calling ovr_GetHmdDesc(session).

The following table describes the fields:

Field Type Description Type ovrHmdType Type of the HMD, such as ovr_DK1 or ovr_DK2 . ProductName char[] Name of the product as a string. Manufacturer char[] Name of the manufacturer. VendorId short Vendor ID reported by the headset USB device. ProductId short Product ID reported by the headset USB device SerialNumber char[] Serial number string reported by the headset USB device. FirmwareMajor short The major version of the sensor firmware FirmwareMinor short The minor version of the sensor firmware. CameraFrustumHFovInRadians float The horizontal FOV of the position tracker frustum. CameraFrustumVFovInRadians float The vertical FOV of the position tracker frustum. CameraFrustumNearZInMeters float The distance from the position tracker to the near frustum bounds CameraFrustumNearZInMeters float The distance from the position tracker to the far frustum bounds AvailableHmdCaps unsigned int Capability bits described by ovrHmdCaps which the HMD currently supports. DefaultHmdCaps unsigned int Default capability bits described by ovrHmdCaps for the current HMD. AvailableTrackingCaps unsigned int Capability bits described by ovrTrackingCaps which the HMD currently supports. DefaultTrackingCaps unsigned int Default capability bits described by ovrTrackingCaps for the current HMD. DefaultEyeFov ovrFovPort[] Recommended optical field of view for each eye. MaxEyeFov ovrFovPort[] Maximum optical field of view that can be practically rendered for each eye. Resolution ovrSizei Resolution of the full HMD screen (both eyes) in pixels. DisplayRefreshRate float Nominal refresh rate of the HMD in cycles per second at the time of HMD creation.

Head Tracking and Sensors

The Oculus Rift hardware contains a number of micro-electrical-mechanical (MEMS) sensors including a gyroscope, accelerometer, and magnetometer.

Starting with DK2, there is also a tracker to track headset position. The information from each of these sensors is combined through the sensor fusion process to determine the motion of the user’s head in the real world and synchronize the user’s view in real-time.

By default the SDK will enable all of the available tracking features for the attached HMD. If you’d like to toggle the tracking features, you can do so by calling ovr_ConfigureTracking. This function has the following signature:

ovrResult ovr_ConfigureTracking(    ovrSession session, unsigned int requestedTrackingCaps,      unsigned int requiredTrackingCaps);

ovr_ConfigureTracking takes two sets of capability flags as input. These both use flags declared in ovrTrackingCaps. supportedTrackingCaps describes the HMD tracking capabilities that should be used when available. requiredTrackingCaps specifies capabilities that must be supported by the HMD at the time of the call for the application to operate correctly. If the required capabilities are not present, ovr_ConfigureTracking will fail.

Once the ovrSession is created, you can poll sensor fusion for head position and orientation by calling ovr_GetTrackingState. These calls are demonstrated by the following code:

// Query the HMD for the current tracking state.ovrTrackingState ts = ovr_GetTrackingState(session, ovr_GetTimeInSeconds());if (ts.StatusFlags & (ovrStatus_OrientationTracked | ovrStatus_PositionTracked)){    Posef pose = ts.HeadPose;    ...}

This example initializes the sensors with orientation, yaw correction, and position tracking capabilities if available, while only requiring basic orientation tracking. This means that the code will work for DK1, but will automatically use DK2 tracker-based position tracking. If you are using a DK2 headset and the DK2 tracker is not available during the time of the call, but is plugged in later, the tracker is automatically enabled by the SDK.

After the sensors are initialized, the sensor state is obtained by calling ovr_GetTrackingState. This state includes the predicted head pose and the current tracking state of the HMD as described by StatusFlags. This state can change at runtime based on the available devices and user behavior. For example with DK2, the ovrStatus_PositionTracked flag is only reported when HeadPose includes the absolute positional tracking data from the tracker.

The reported ovrPoseStatef includes full six degrees of freedom (6DoF) head tracking data including orientation, position, and their first and second derivatives. The pose value is reported for a specified absolute point in time using prediction, typically corresponding to the time in the future that this frame’s image will be displayed on screen. To facilitate prediction, ovr_GetTrackingState takes absolute time, in seconds, as a second argument. The current value of absolute time can be obtained by calling ovr_GetTimeInSeconds. If the time passed into ovr_GetTrackingState is the current time or earlier, the tracking state returned will be based on the latest sensor readings with no prediction. In a production application, however, you should use the real-time computed value returned by GetPredictedDisplayTime. Prediction is covered in more detail in the section on Frame Timing.

As already discussed, the reported pose includes a 3D position vector and an orientation quaternion. The orientation is reported as a rotation in a right-handed coordinate system, as illustrated in the following figure.

Figure 1: Rift Coordinate System

The x-z plane is aligned with the ground regardless of camera orientation.

As seen from the diagram, the coordinate system uses the following axis definitions:

• Y is positive in the up direction.
• X is positive to the right.
• Z is positive heading backwards.

Rotation is maintained as a unit quaternion, but can also be reported in yaw-pitch-roll form. Positive rotation is counter-clockwise (CCW, direction of the rotation arrows in the diagram) when looking in the negative direction of each axis, and the component rotations are:

• Pitch is rotation around X, positive when pitching up.
• Yaw is rotation around Y, positive when turning left.
• Roll is rotation around Z, positive when tilting to the left in the XY plane.

The simplest way to extract yaw-pitch-roll from ovrPose is to use the C++ OVR Math helper classes that are included with the library. The following example uses direct conversion to assign ovrPosef to the equivalent C‍++ Posef class. You can then use the Quatf::GetEulerAngles<> to extract the Euler angles in the desired axis rotation order.

All simple C math types provided by OVR such as ovrVector3f and ovrQuatf have corresponding C++ types that provide constructors and operators for convenience. These types can be used interchangeably.

Position Tracking

The frustum is defined by the horizontal and vertical FOV, and the distance to the front and back frustum planes.

Approximate values for these parameters can be accessed through the ovrHmdDesc struct as follows:

ovrSession session;ovrGraphicsLuid luid;if(OVR_SUCCESS(ovr_Create(&session, &luid))){    // Extract tracking frustum parameters.    float frustomHorizontalFOV = session->CameraFrustumHFovInRadians; ...

The following figure shows the DK2 position tracker mounted on a PC monitor and a representation of the resulting tracking frustum.

Figure 2: Position Tracking Camera and Tracking Frustum

The relevant parameters and typical values are list below:

Field Type Typical Value CameraFrustumHFovInRadians float 1.292 radians (74 degrees) CameraFrustumVFovInRadians float 0.942 radians (54 degrees) CameraFrustumNearZInMeters float 0.4m CameraFrustumFarZInMeters float 2.5m

These parameters are provided to enable application developers to provide a visual representation of the tracking frustum. The previous figure also shows the default tracking origin and associated coordinate system.

Note: Although the tracker axis (and hence the tracking frustum) are shown tilted downwards slightly, the tracking coordinate system is always oriented horizontally such that the axes are parallel to the ground.

By default, the tracking origin is located one meter away from the tracker in the direction of the optical axis but with the same height as the tracker. The default origin orientation is level with the ground with the negative axis pointing towards the tracker. In other words, a headset yaw angle of zero corresponds to the user looking towards the tracker.

Note: This can be modified using the API call ovr_RecenterPose which resets the tracking origin to the headset’s current location, and sets the yaw origin to the current headset yaw value.Note: The tracking origin is set on a per application basis; switching focus between different VR apps also switches the tracking origin.

The head pose is returned by calling ovr_GetTrackingState. The returned ovrTrackingState struct contains several items relevant to position tracking:

• HeadPose—includes both head position and orientation.
• CameraPose—the pose of the tracker relative to the tracking origin.
• LeveledCameraPose— the pose of the tracker relative to the tracking origin but with roll and pitch zeroed out. You can use this as a reference point to render real-world objects in the correct place.

The StatusFlags variable contains three status bits relating to position tracking:

• ovrStatus_PositionConnected—set when the position tracker is connected and functioning properly.
• ovrStatus_PositionTracked—flag that is set only when the headset is being actively tracked.
• ovrStatus_CameraPoseTracked—set after the initial tracker calibration has taken place. Typically this requires the headset to be reasonably stationary within the view frustum for a second or so at the start of tracking. It may be necessary to communicate this to the user if the ovrStatus_CameraPoseTracked flag doesn’t become set quickly after entering VR.

There are several conditions that may cause position tracking to be interrupted and for the flag to become zero:

• The headset moved wholly or partially outside the tracking frustum.
• The headset adopts an orientation that is not easily trackable with the current hardware (for example facing directly away from the tracker).
• The exterior of the headset is partially or fully occluded from the tracker’s point of view (for example by hair or hands).
• The velocity of the headset exceeds the expected range.

Following an interruption, assuming the conditions above are no longer present, tracking normally resumes quickly and the ovrStatus_PositionTracked flag is set.

User Input Integration

To provide the most comfortable, intuitive, and usable interface for the player, head tracking should be integrated with an existing control scheme for most applications.

For example, in a first person shooter (FPS) game, the player generally moves forward, backward, left, and right using the left joystick, and looks left, right, up, and down using the right joystick. When using the Rift, the player can now look left, right, up, and down, using their head. However, players should not be required to frequently turn their heads 180 degrees since this creates a bad user experience. Generally, they need a way to reorient themselves so that they are always comfortable (the same way in which we turn our bodies if we want to look behind ourselves for more than a brief glance).

To summarize, developers should carefully consider their control schemes and how to integrate head-tracking when designing applications for VR. The OculusRoomTiny application provides a source code sample that shows how to integrate Oculus head tracking with the aforementioned standard FPS control scheme.

For more information about good and bad practices, refer to the Oculus Best Practices Guide.

Health and Safety Warning

All applications that use the Oculus Rift display a health and safety warning when the device is used.

This warning appears for a short amount of time when the Rift first displays a VR scene; it can be dismissed by pressing a key or tapping on the headset. Currently, the warning displays for at least 15 seconds the first time a new profile user puts on the headset and 3 seconds afterwards.

The warning displays automatically as a layer.

The Health and Safety Warning can be disabled through the Oculus Configuration Utility. Before suppressing the Health and Safety Warning, please note that by disabling the Health and Safety warning screen, you agree that you have read the warning, and that no other person will use the headset without reading this warning screen.

To use the Oculus Configuration Utility to suppress the Health and Safety Warning, a registry key setting must be added for Windows builds, while an environment variable must be added for non-Windows builds.

For Windows, the following key must be added:

HKEY LOCAL MACHINE\Software\Wow6432Node\Oculus VR, LLC\LibOVR\HSWToggleEnabled

Setting the value of HSWToggleEnabled to 1 enables the Disable Health and Safety Warning check box in the Advanced Configuration panel of the Oculus Configuration Utility. For non-Windows builds, you must create an environment variable named Oculus LibOVR HSWToggleEnabled with the value of ”1”.