Namespace VIVE.OpenXR

Classes

This component acts as a world space refernce point of the tracking space origin. Add this component to the root of your VR camera rig in order to let other features to find the tracking space origin and apply positional and rotational offset when needed.

VIVECosmosProfile

This UnityEngine.XR.OpenXR.Features.OpenXRInteractionFeature enables the use of HTC Vive Cosmos interaction profiles in OpenXR.

VIVECosmosProfile.ViveCosmosController

An Input System device based on the HTC Vive Cosmos Controller.

VIVEFocus3Feature

VIVEFocus3Profile

This UnityEngine.XR.OpenXR.Features.OpenXRInteractionFeature enables the use of HTC VIVE Focus 3 interaction profiles in OpenXR.

VIVEFocus3Profile.VIVEFocus3Controller

An Input System device based on the hand interaction profile in the Interaction Profile.

VIVERig

VisibilityMaskDisabler

ViveFoveation

VivePathEnumeration

VivePathEnumerationHelper

XR_EXT_hand_tracking

XR_EXT_hand_tracking_defs

XR_EXT_hand_tracking_impls

XR_FB_display_refresh_rate

XR_FB_display_refresh_rate_defs

XR_FB_display_refresh_rate_impls

XR_HTC_facial_tracking

XR_HTC_facial_tracking_defs

XR_HTC_facial_tracking_impls

XR_HTC_path_enumeration

XR_HTC_path_enumeration_defs

XR_HTC_path_enumeration_impls

Structs

XrAction

Action handles are used to refer to individual actions when retrieving action data, creating action spaces, or sending haptic events.

XrActionCreateInfo

XrActionSet

Action sets are application-defined collections of actions. They are attached to a given XrSession with a xrAttachSessionActionSets call. They are enabled or disabled by the application via xrSyncActions depending on the current application context. For example, a game may have one set of actions that apply to controlling a character and another set for navigating a menu system. When these actions are grouped into two XrActionSet handles they can be selectively enabled and disabled using a single function call.

XrActionStateGetInfo

XrActionStatePose

XrBool32

Boolean values used by OpenXR are of type XrBool32 and are 32-bits wide as suggested by the name.

XrColor4f

Unless otherwise specified, colors are encoded as linear (not with sRGB nor other gamma compression) values with individual components being in the range of 0.0 through 1.0, and without the RGB components being premultiplied by the alpha component.

If color encoding is specified as being premultiplied by the alpha component, the RGB components are set to zero if the alpha component is zero.

XrDuration

The difference between two timepoints is a duration, and thus the difference between two XrTime values is an XrDuration value.

Functions that refer to durations use XrDuration as opposed to XrTime.

XrExtensionProperties

XrExtent2Df

A two-dimensional floating-point extent is defined by XrExtent2Df.

XrExtent2Di

A two-dimensional integer extent is defined by the XrExtent2Di.

XrFlags64

Bitmasks are passed to many functions and structures to compactly represent options and are stored in memory defined by the XrFlags64 type. But the API does not use the XrFlags64 type directly. Instead, a Xr*Flags type is used which is an alias of the XrFlags64 type. The API also defines a set of constant bit definitions used to set the bitmasks.

XrFoveationConfigurationHTC

XrFovf

Field of view (FoV) is defined by the XrFovf structure.

XrFrameState

A structure indicates the frameState.

XrFrameWaitInfo

A structure indicates the frameWaitInfo.

XrInputSourceLocalizedNameGetInfo

XrInstance

An OpenXR instance is an object that allows an OpenXR application to communicate with an OpenXR runtime. The application accomplishes this communication by calling xrCreateInstance and receiving a handle to the resulting XrInstance object.

The XrInstance object stores and tracks OpenXR-related application state, without storing any such state in the application’s global address space. This allows the application to create multiple instances as well as safely encapsulate the application’s OpenXR state since this object is opaque to the application. OpenXR runtimes may limit the number of simultaneous XrInstance objects that may be created and used, but they must support the creation and usage of at least one XrInstance object per process.

XrOffset2Di

An integer offset is defined by the XrOffset2Di.

XrPath

The XrPath is an atom that connects an application with a single path, within the context of a single instance. There is a bijective mapping between well-formed path strings and atoms in use. This atom is used — in place of the path name string it corresponds to — to retrieve state and perform other operations.

As an XrPath is only shorthand for a well-formed path string, they have no explicit life cycle.

Lifetime is implicitly managed by the XrInstance.An XrPath must not be used unless it is received at execution time from the runtime in the context of a particular XrInstance. Therefore, with the exception of XR_NULL_PATH, XrPath values must not be specified as constant values in applications: the corresponding path string should be used instead.During the lifetime of a given XrInstance, the XrPath associated with that instance with any given well-formed path must not vary, and similarly the well-formed path string that corresponds to a given XrPath in that instance must not vary.An XrPath that is received from one XrInstance may not be used with another. Such an invalid use may be detected and result in an error being returned, or it may result in undefined behavior.

Well-written applications should typically use a small, bounded set of paths in practice.However, the runtime should support looking up the XrPath for a large number of path strings for maximum compatibility. Runtime implementers should keep in mind that applications supporting diverse systems may look up path strings in a quantity exceeding the number of non-empty entities predicted or provided by any one runtime’s own path tree model, and this is not inherently an error. However, system resources are finite and thus runtimes may signal exhaustion of resources dedicated to these associations under certain conditions.

When discussing the behavior of runtimes at these limits, a new XrPath refers to an XrPath value that, as of some point in time, has neither been received by the application nor tracked internally by the runtime.In this case, since an application has not yet received the value of such an XrPath, the runtime has not yet made any assertions about its association with any path string. In this context, new only refers to the fact that the mapping has not necessarily been made constant for a given value/path string pair for the remaining life of the associated instance by being revealed to the application.It does not necessarily imply creation of the entity, if any, referred to by such a path.Similarly, it does not imply the absence of such an entity prior to that point. Entities in the path tree have varied lifetime that is independent from the duration of the mapping from path string to XrPath.

For flexibility, the runtime may internally track or otherwise make constant, in instance or larger scope, any mapping of a path string to an XrPath value even before an application would otherwise receive that value, thus making it no longer new by the above definition.

When the runtime’s resources to track the path string-XrPath mapping are exhausted, and the application makes an API call that would have otherwise retrieved a new XrPath as defined above, the runtime must return XR_ERROR_PATH_COUNT_EXCEEDED.This includes both explicit calls to xrStringToPath as well as other calls that retrieve an XrPath in any other way.

XrPathsForInteractionProfileEnumerateInfoHTC

When developers would like to retrieve the supported user paths from the interactionProfile, userPath should be XR_NULL_PATH. If the interaction profile for any of the suggested bindings does not exist in the allowlist defined in Interaction Profile Paths, the runtime must return XR_ERROR_PATH_UNSUPPORTED.

If developers would like to retrieve the input/output paths related to the interactionProfile, userPath should be a valid user path.If userPath is not one of the device input subpaths described in section /user paths, the runtime must return XR_ERROR_PATH_UNSUPPORTED.

XrPosef

A pose is defined by the XrPosef structure.

XrQuaternionf

Rotation is represented by a unit quaternion defined by the XrQuaternionf structure.

XrRect2Di

A rectangle with integer values is defined by the XrRect2Di.

XrReferenceSpaceCreateInfo

A structure indicates the space.

XrSession

A session represents an application’s intention to display XR content to the user.

Refer to Session Lifecycle for more details.

XrSessionCreateFlags

There are currently no session creation flags. This is reserved for future use.

XrSessionCreateInfo

A structure contains information about how to create the session.

XrSpace

Across both virtual reality and augmented reality, XR applications have a core need to map the location of virtual objects to the corresponding real-world locations where they will be rendered. Spaces allow applications to explicitly create and specify the frames of reference in which they choose to track the real world, and then determine how those frames of reference move relative to one another over time.

Spaces are represented by XrSpace handles, which the application creates and then uses in API calls. Whenever an application calls a function that returns coordinates, it provides an XrSpace to specify the frame of reference in which those coordinates will be expressed. Similarly, when providing coordinates to a function, the application specifies which XrSpace the runtime should use to interpret those coordinates.

OpenXR defines a set of well-known reference spaces that applications use to bootstrap their spatial reasoning. These reference spaces are: VIEW, LOCAL and STAGE. Each reference space has a well-defined meaning, which establishes where its origin is positioned and how its axes are oriented.

Runtimes whose tracking systems improve their understanding of the world over time may track spaces independently. For example, even though a LOCAL space and a STAGE space each map their origin to a static position in the world, a runtime with an inside-out tracking system may introduce slight adjustments to the origin of each space on a continuous basis to keep each origin in place.

Beyond well-known reference spaces, runtimes expose other independently-tracked spaces, such as a pose action space that tracks the pose of a motion controller over time.

When one or both spaces are tracking a dynamic object, passing in an updated time to xrLocateSpace each frame will result in an updated relative pose. For example, the location of the left hand’s pose action space in the STAGE reference space will change each frame as the user’s hand moves relative to the stage’s predefined origin on the floor. In other XR APIs, it is common to report the "pose" of an object relative to some presumed underlying global space. This API is careful to not explicitly define such an underlying global space, because it does not apply to all systems. Some systems will support no STAGE space, while others may support a STAGE space that switches between various physical stages with dynamic availability. To satisfy this wide variability, "poses" are always described as the relationship between two spaces.

Some devices improve their understanding of the world as the device is used. The location returned by xrLocateSpace in later frames may change over time, even for spaces that track static objects, as either the target space or base space adjusts its origin.

Composition layers submitted by the application include an XrSpace for the runtime to use to position that layer over time. Composition layers whose XrSpace is relative to the VIEW reference space are implicitly "head-locked", even if they may not be "display-locked" for non-head-mounted form factors.

XrSpaceLocation

XrSpaceVelocityFlags

Flag bits for XrSpaceVelocityFlags:

XR_SPACE_VELOCITY_LINEAR_VALID_BIT indicates that the linearVelocity member contains valid data. Applications must not read the linearVelocity field if this flag is unset.

XR_SPACE_VELOCITY_ANGULAR_VALID_BIT indicates that the angularVelocity member contains valid data. Applications must not read the angularVelocity field if this flag is unset.

XrSwapchain

XrSwapchainCreateFlags

XrSwapchainCreateInfo

XrSwapchainUsageFlags

XrSystemGraphicsProperties

A structure indicates the system graphics properties.

XrSystemId

An XrSystemId is an opaque atom used by the runtime to identify a system. The value XR_NULL_SYSTEM_ID is considered an invalid system.

XrSystemProperties

A structure indicates the system properties.

XrSystemTrackingProperties

A structure indicates the system tracking properties.

XrTime

XrTime is a base value type that represents time as a signed 64-bit integer, representing the monotonically-increasing count of nanoseconds that have elapsed since a runtime-chosen epoch. XrTime always represents the time elasped since that constant epoch, rather than a duration or a time point relative to some moving epoch such as vsync time, etc.

XrVector2f

XrVector3f

A three-dimensional vector is defined by the XrVector3f structure.

Enums

XrActionType

XrEnvironmentBlendMode

The possible blend modes are specified by the XrEnvironmentBlendMode enumeration.

XrEyeVisibility

The XrEyeVisibility enum selects which of the viewer’s eyes to display a layer.

XrFoveationLevelHTC

XrFoveationModeHTC

XrInputSourceLocalizedNameFlags

XrObjectType

Defines values, each of which corresponds to a specific OpenXR handle type. These values can be used to associate debug information with a particular type of object through one or more extensions.

XrReferenceSpaceType

Runtimes implement well-known reference spaces from XrReferenceSpaceType if they support tracking of that kind.

XrResult

All return codes in the OpenXR Core API are reported via XrResult return values.

XrSessionState

The XrSessionState enumerates the possible session lifecycle states.

XrSpaceLocationFlags

Flag bits for XrSpaceLocationFlags.

XrStructureType

Any parameter that is a structure containing a type member must have a value of type which is a valid XrStructureType value matching the type of the structure.

Delegates

OpenXRHelper.xrCreateActionDelegate

OpenXRHelper.xrCreateReferenceSpaceDelegate

The function delegate declaration of xrCreateReferenceSpace.

OpenXRHelper.xrCreateSessionDelegate

The function delegate declaration of xrCreateSession.

OpenXRHelper.xrCreateSwapchainAndroidSurfaceKHRDelegate

The function delegate declaration of xrCreateSwapchainAndroidSurfaceKHR.

OpenXRHelper.xrDestroySpaceDelegate

The function delegate declaration of xrDestroySpace.

OpenXRHelper.xrEnumerateDisplayRefreshRatesFBDelegate

OpenXRHelper.xrEnumerateInstanceExtensionPropertiesDelegate

OpenXRHelper.xrEnumerateReferenceSpacesDelegate

The function delegate declaration of xrEnumerateReferenceSpaces.

OpenXRHelper.xrGetActionStatePoseDelegate

OpenXRHelper.xrGetDisplayRefreshRateFBDelegate

OpenXRHelper.xrGetInputSourceLocalizedNameDelegate

OpenXRHelper.xrGetInstanceProcAddrDelegate

The function delegate declaration of xrGetInstanceProcAddr.

OpenXRHelper.xrGetSystemPropertiesDelegate

The function delegate declaration of xrGetSystemProperties.

OpenXRHelper.xrRequestDisplayRefreshRateFBDelegate

OpenXRHelper.xrWaitFrameDelegate

The function delegate declaration of xrWaitFrame.

VivePathEnumerationHelper.xrEnumeratePathsForInteractionProfileHTCDelegate

Provided by XR_HTC_path_enumerate. Developers should call this API with the value of pathCapacityInput equals to 0 to retrieve the size of paths from pathCountOutput. Then developers allocate the array of XrPath data and assign the pathCapacityInput and call the API in the second time.

If the input pathCapacityInput is not sufficient to contain all output indices, the runtime must return XR_ERROR_SIZE_INSUFFICIENT on calls to xrEnumeratePathsForInteractionProfileHTC and not change the content in paths.