- 1 Overview
- 2 Usage
- 3 Development
- 4 True First Person Viewpoint
- 5 Bugs / Issues
- 6 See also
Unreal Engine 4 supports the Oculus Rift through the use of a plugin.
This plugin is included as part of the initial UE4 download.
Originally, the Rift was only supported in UE4 on Windows. OSX support was added as well starting in 4.4.1.
Unreal Engine 4 will automatically use an Oculus Rift if it is plugged in and the plugin is enabled.
To see if the plugin is active and your Rift has been detected:
- Run a standalone game.
- Bring the console (default: ~ / tilde).
- Type in "showlog".
- Type in "ovrversion".
- The LibOVR version & built date should be printed to the log window.
If the message "Command not recognised: ovrversion" is displayed instead, check that:
- the plugin is enabled.
- you are running UE4 on the Windows platform.
- your Oculus Rift is plugged in.
- Also check if you have installed the lastest runtime driver! (U4 uses this to activate the plugin: https://developer.oculusvr.com/?action=dl)
- your Oculus Rift is functioning correctly.
For any hardware related issues, contact Oculus VR Support.
Prior to release 4.7, the Rift did not work in the editor view port or any Play in Editor (PIE) game mode; i.e. Right-Clicking and selecting 'Play From Here' didn't work.
Release 4.7 introduced a VR Preview Play in Editor mode. Select Options for Play in Editor (PIE), and select VR Preview to preview in the Rift.
To use in-game:
- Create a non-PIE game mode, such as a Standalone Game.
- If not full screen, press Alt-Enter.
- Bring up the console (~ / tilde). and type "stereo on".
If you have any issues, go through the sanity check.
Useful Console Commands
To see a full list, check out the OculusRiftHMD.cpp (full UE4 source required).
Print list of settings to log.
Enabled/disable stereo rendering for HMD device.
Resets IPD & clears IPD/stereo overrides.
stereo HEADX=, HEADY= or HEADZ=<value>
Sets X, Y or Z component of head model.
Override and set IPD.
Enable/disable HMD device.
hmd vsync on/off/reset
Control or reset vsync.
Print LibOVR version build date to log.
Oculus Rift settings go in DefaultEngine.ini under the section Oculus.Settings.
DefaultEngine.ini is located at "<Path to YourGame>\Config\DefaultEngine.ini".
The list and values were taken from the source of the plugin.
[Oculus.Settings] ; In meters, not Unreal Units (cm) ; Recommended for true first person viewpoint ; since you are simulating the head. ;HeadModel_v2=(X=0.0,Y=0,Z=0.0) ; Default values HeadModel_v2=(X=0.12,Y=0,Z=0.17) bChromaAbCorrectionEnabled=true bMagEnabled=true bDevSettingsEnabled=false bMotionPredictionEnabled=true bTiltCorrectionEnabled=true AccelGain=0.0 MotionPrediction=0.04 bOverrideIPD=false IPD=0.064 bOverrideStereo=false ProjectionCenterOffset=0.0 LensCenterOffset=0.0 FOV=90.0 bOverrideVSync=false bVSync=true bOverrideScreenPercentage=false ; Value is out of range [30..300] ScreenPercentage=100.0 bAllowFinishCurrentFrame=false PositionScaleFactor=1.0 ; Defaults to true if DLL built with OVR_VISION_ENABLED defined. ; Positional tracking for DK2 onwards perhaps? bHmdPosTracking=false bLowPersistenceMode=false ; Defaults to true. ; If enabled, viewpoint rotation is updated during the render thread. ; Depending on how you control a players view rotation, you may need to disable this. bUpdateOnRT=true
By default, 1uu (Unreal Unit) is equal to 1cm.
There is a World to Meters variable, under World Settings, that can be changed to affect how the Rift and other devices behave.
You can find settings relating to a players speed, size and more under the Defaults tab of your characters Blueprint. They are also located under the particular component related to each setting, which you can find under the Components tab.
Height & Width
Height is based off the Capsule Half Height.
Width is based off the Capsule Radius.
By default, the player is 192cm tall and 84cm wide.
In the Virtual Reality Demo, the player is 176cm tall and 68cm wide.
MaxWalkSpeed governs a characters speed while on the ground, in cm/s.
By default, the player moves at 600cm/s or 6m/s.
The location of the camera is usually based off the BaseEyeHeight variable.
In the First Person Template and Virtual Reality Demo, the camera is 160cm off the ground.
True First Person Viewpoint
One of the best ways to help with presence is to use a true first person viewpoint.
Basically speaking, you bolt the camera to the players eyes.
This can be done in the following manner:
- Create blueprint based on your character of choice.
- Under components tab, add a camera component.
- Drag the camera component over your characters mesh to attach it there.
- Select the camera component and change its Parent Socket to the bone/socket of your choice.
- Adjust the relative location & rotation if required (its under Transform).
- Make sure Camera Settings => Use Controller View Rotation is enabled.
- Compile the Blueprint.
- Set the Default Pawn Class of your game mode to your TFP character.
- Zero out the Virtual Head Model.
Default Head Tracking Behaviour
By default, head tracking will affect the player's view, rotation and movement direction.
This behaviour can be altered via C++ or Blueprints.
Virtual Head Model
By default, a virtual head model will be used to offset the players viewpoint.
For a traditional first person viewpoint that rotates on a central axis, this is fine.
For a true first person viewpoint that is already positioned at the location of the players eyes, this extra offset is unnecessary.
Similarly so for most third person viewpoints.
The dimensions of this virtual head model are determined by the HeadModel_v2 config setting.
There are two main functions, outside of the actual plugin, that are responsible for controlling how the players viewpoint is modified by input from the Oculus Rift:
Bugs / Issues
Texture Blurring / Vibrating
This is caused by the TemporalAA.
The current work around is disable TemporalAA by switching the AA method to FXAA or None.
It is located in your global post processing volume settings, under Misc.
- Currently, screen space reflections are not supported. Source
Simulation Sickness is a form of motion sickness that occurs when using the Oculus Rift or other VR screen technology. To help reduce the likelihood of your user having a bad experience because of this, please follow best practices closely.
- Oculus VR Best Practices Guide - PDF
- Developing Virtual Reality Games and Experiences - video of GDC 2014 talk by Tom Forsyth
Some specific suggestions, not intended to be exhaustive:
- Avoid cinematic cameras or anything that takes control of the camera movements. This tends to be the worst offender for causing sim sickness.
- Don't override the field of view angle (FOV) manually, and don't expose it as a user preference. The value needs to match the physical geometry of the headset and lenses and should be set automatically through the device's SDK and internal configuration. If there's a mismatch, the world will appear to warp when you turn your head, leading to discomfort or nausea.
- Do not have "Walking Bob" for first person games. This refers to the screen moving to mimic the human body moving up and down as it walks.
- Do not "shake" the camera. If a grenade goes off next to a player, a camera shake may make sense in games, but on the Oculus, it can trigger sim sickness quickly.
- Design dimmer areas. Strong/vibrant lighting in games can cause sim sickness to occur more quickly. Avoid this by using cooler shades and dimmer lights than you normally would.
- Keep your framerate high. Low framerates are another trigger for a lot of gamers, so make sure to optimize your game as much as possible. Try to keep over 60fps if possible, so that if there is lag it is less likely to be a problem. Future devices will require higher framerates, i.e. 75fps for Oculus Rift DK2, and (rumored) 90fps for the consumer release.
- Keep height in mind. Some players become nauseated when looking at things that are very far up or down. This may be more caused by height phobias.
Please note that simulation and motion sickness are still not fully understood by doctors, so this advice is based off of various user experiences along with some limited knowledge of disorientation.