The site has a new content architecture. We've added the ability to select your development device to show device-specific content. Please read our blog post Oculus Developer Center Update: Device-centric Documentation Architecture for more information.
All Oculus Quest developers MUST PASS the concept review prior to gaining publishing access to the Quest Store and additional resources. Submit a concept document for review as early in your Quest application development cycle as possible. For additional information and context, please see Submitting Your App to the Oculus Quest Store.
The Unity Locomotion sample scene demonstrates various movement schemes as examples of how you can implement locomotion in your own applications.
This scene puts you in a large area with static structures and buildings. There are several movement schemes available to allow you to explore this environment. These movement schemes focus on teleportation, which reduces the risk of user discomfort, and several use the thumbsticks to walk and turn.
When the sample scene starts, the B, Y, and Menu buttons bring up (and then dismiss) a menu where you choose a control scheme with the A or X button. Note that you must dismiss the menu once you make your selection for your chosen scheme to work properly. The control schemes are as follows:
The goal of this topic is to help you understand the prefabs, Game Objects, components, and properties that make this functionality work. You can also use this sample scene as a starting point for your own application.
This section describes the key prefabs and Game Objects that make the core functionality of this scene work. In this topic, the following are covered:
OVRPlayerControllerprefab modified to work with the
LocalAvatarprefab. Developers can use this as a guide if they want to use Avatars with
PlayerControllerthat controls and centralizes functionality for the various types of teleports.
TeleportPointscript instance and a collider, with the collider in the layer specified by
TeleportTargetHandler.AimCollisionLayerMask. That layer should also be ignored by player collision.
PlayerController object includes components and has child objects necessary for 3D control in a VR environment. It also contains a child
OVRCameraRig to serve as the user’s VR camera and provide access to
OVRCameraRig object also includes a
LocalAvatar under its child
TrackingSpace. For more information about the
LocalAvatar prefab (and Oculus Avatars in general), see the Oculus Avatar documentation.
PlayerController in the Hierarchy and look at it in the Inspector window. Components important to this scene include the following:
This standard Unity component is a capsule-shaped collider that can move around while being affected by collisions. Combined with the
OVRPlayerController component, it provides for first-person 3D movement with a decent variety of options.
Implements a basic first-person controller for VR. The controller will interact properly with a Unity scene, provided the scene has collision detection assigned to it.
OVRPlayerController contains a few variables attached to sliders that change the physics properties of the controller. For more information on OVR Player Controller, see Oculus Utilities for Unity.
Allows you to experiment with certain sample scene settings, including Speed Rotation Increment, which controls how quickly speed and rotation change based on input, and Quit Key, in case you get stuck while teleporting.
Component that shows debug information in a HUD when the Space Bar is pressed while the scene is running.
Responsible for moving the character capsule to match the HMD, fading out the camera or blocking movement when collisions occur, and adjusting the character capsule height to match the HMD’s offset from the ground.
LocomotionController is a child object of
PlayerController comprised of components that control and centralize functionality for different types of teleportation.
First, here are general
LocomotionController components that are relevant to all types of locomotion presented in the sample:
OVRPlayerController, and the Unity Character Controller. In this sample, the first is a child of
PlayerController, and the other two are components on
TeleportDestinationscript (such as our
TeleportDestinationprefab) that is activated when aiming. For more information, see the
TeleportDestinationprefab section of this topic.
An extendable set of input, aim, targeting, orientation, and transition components work together to provide a broad set of locomotion configurations. These components provide logic for each of the stages of the teleport sequence, including target selection, landing orientation, and teleport effects. This makes it possible for different kinds of teleport behaviors to occur by simply enabling different combinations of components. The different types of components do the following:
Now we’ll briefly look at each individual component. It is recommended that you look at each of them in the Inspector in Unity Editor. Many of them present options that can be experimented with.
Input handlers are responsible for handling the physical controls of the aiming and teleportation. Options for input handlers include configuring the specific inputs for aiming and teleporting. The input handlers are as follows:
Aim handlers are responsible for handling how aiming works. Aiming can be done in a straight, direct line, or in a parabolic curve, similar to a throw. Options for aim handlers include range and aspects of the parabolic curve. The aim handlers are as follows:
Target handlers determine whether the current aim target is valid, and update the teleport destination as required. Options include selecting which Game Object layers will be included in the targeting collision tests. The target handlers are as follows:
Orientation handlers determine how the post-teleportation facing direction of the player is controlled:
Teleport transitions manage the actual relocation of the player from their current position and rotation to the teleport destination, as well as the style and manner of relocation:
On this Game Object, you can get different types of locomotion by enabling and disabling these various components. As an example, open the
LocomotionSampleSupport script on the
SampleSupport Game Object and search for ActivateHandlers. You’ll come across lines like this, where the default control schemes’ individual handlers are declared:
ActivateHandlers<TeleportInputHandlerAvatarTouch, TeleportAimHandlerLaser, TeleportTargetHandlerNode, TeleportOrientationHandlerThumbstick, TeleportTransitionBlink>();
You can similarly modify these schemes, or create your own. Just make sure you use one of each type of component.
TeleportPoint prefabs are used in node-based (
TeleportTargetHandlerNode) teleportation, where static nodes are targeted as teleportation destinations. There can be many
TeleportPoints in a given scene.
TeleportDestination is instantiated as needed when the player is actively aiming to match the current aim target.
TeleportDestination begins as uninstantiated and becomes instantiated when an aim handler provides an aim position, at which point its Position Indicator transform component will be updated to that position. A target position being provided does not mean the position is valid; only that the aim handler found something to test as a destination.
The Orientation Indicator transform component is rotated to match the rotation of the aiming target. Simple teleport destinations should assign this to the object containing this component. More complex teleport destinations might assign this to a sub-object that is used to indicate the landing orientation independently from the rest of the destination indicator, such as when world space effects are required. This will typically be a child of the Position Indicator.
Using the modular handler and transition components, you can construct your own
LocomotionController that fits your own needs while excluding the components you won’t be using.
In this sample, you can also experiment with the
SampleSupport Game Object, which contains the
LocomotionSampleSupport.cs script. In this script, you can alter the modular handler and transition components and the names for the four predefined control schemes, thus opening up further experimentation.