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_EXT_user_presence

XR_EXT_user_presence_defs

XR_EXT_user_presence_impls

XR_FB_display_refresh_rate

XR_FB_display_refresh_rate_defs

XR_FB_display_refresh_rate_impls

XR_HTC_composition_layer_extra_settings

XR_HTC_composition_layer_extra_settings_defs

XR_HTC_composition_layer_extra_settings_impls

XR_HTC_eye_tracker

XR_HTC_eye_tracker_defs

XR_HTC_eye_tracker_impls

XR_HTC_facial_tracking

XR_HTC_facial_tracking_defs

XR_HTC_facial_tracking_impls

XR_HTC_passthrough

XR_HTC_passthrough_configuration

XR_HTC_passthrough_configuration_defs

XR_HTC_passthrough_configuration_impls

XR_HTC_passthrough_defs

XR_HTC_passthrough_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

See XrActionCreateInfo for more detail.

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

The XrActionStateGetInfo structure is used to provide action and subaction paths when calling xrGetActionState* function.

XrActionStatePose

See XrActionStatePose for more detail.

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.

XrCompositionLayerBaseHeader

The XrCompositionLayerBaseHeader structure is not intended to be directly used, but forms a basis for defining current and future structures containing composition layer information. The XrFrameEndInfo structure contains an array of pointers to these polymorphic header structures.

XrCompositionLayerFlags

Specifies options for individual composition layers, and contains a bitwise-OR of zero or more of the bits defined in XrCompositionLayerFlagBits.

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.

XrEventDataBuffer

The XrEventDataBuffer is a structure passed to xrPollEvent large enough to contain any returned event data element. The maximum size is specified by XR_MAX_EVENT_DATA_SIZE.
An application can set(or reset) only the type member and clear the next member of an XrEventDataBuffer before passing it as an input to xrPollEvent.The runtime must ignore the contents of the varying field and overwrite it without reading it.
A pointer to an XrEventDataBuffer may be type-cast to an XrEventDataBaseHeader pointer, or a pointer to any other appropriate event data based on the type parameter.

XrEventDataSessionStateChanged

See XrEventDataSessionStateChanged for more detail.

XrExtensionProperties

See XrExtensionProperties for more detail.

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.

XrFovf

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

XrFrameEndInfo

A structure indicates the XrFrameEndInfo .

XrFrameState

A structure indicates the frameState.

XrFrameWaitInfo

A structure indicates the frameWaitInfo.

XrInputSourceLocalizedNameGetInfo

See XrInputSourceLocalizedNameGetInfo for more detail.

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.

XrSessionBeginInfo

See XrSessionBeginInfo for more detail.

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

See XrSpaceLocation for more detail.

XrSwapchain

Normal XR applications will want to present rendered images to the user. To allow this, the runtime provides images organized in swapchains for the application to render into. The runtime must allow applications to create multiple swapchains.
Swapchain image format support by the runtime is specified by the xrEnumerateSwapchainFormats function.Runtimes should support R8G8B8A8 and R8G8B8A8 sRGB formats if possible.
Swapchain images can be 2D or 2D Array.
Rendering operations involving composition of submitted layers are assumed to be internally performed by the runtime in linear color space.Images submitted in sRGB color space must be created using an API-specific sRGB format(e.g.DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, GL_SRGB8_ALPHA8, VK_FORMAT_R8G8B8A8_SRGB) to apply automatic sRGB-to-linear conversion when read by the runtime.All other formats will be treated as linear values.

XrSwapchainCreateInfo

See XrSwapchainCreateInfo for more detail.

XrSwapchainImageAcquireInfo

XrSwapchainImageBaseHeader

XrSwapchainImageD3D11KHR

XrSwapchainImageD3D12KHR

XrSwapchainImageOpenGLESKHR

XrSwapchainImageOpenGLKHR

XrSwapchainImageReleaseInfo

XrSwapchainImageUnion

XrSwapchainImageVulkanKHR

XrSwapchainImageWaitInfo

XrSwapchainSubImage

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

A two-dimensional vector is defined by the XrVector2f structure.

XrVector3f

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

Enums

XrActionType

See XrActionType for more detail.

XrCompositionLayerFlagBits

Specifies options for individual composition layers, and contains a bitwise-OR of zero or more of the bits.

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.

XrInputSourceLocalizedNameFlags

Flag bits for 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.

XrSpaceVelocityFlags

Flag bits for XrSpaceVelocityFlags.

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.

XrSwapchainCreateFlags

Flags bit for XrSwapchainCreateFlags

XrSwapchainUsageFlags

Flags bit for XrSwapchainUsageFlags

XrViewConfigurationType

The application selects its primary view configuration type when calling xrBeginSession, and that configuration remains constant for the lifetime of the session, until xrEndSession is called. The number of views and the semantic meaning of each view index within a given view configuration is well-defined, specified below for all core view configurations.

Delegates

OpenXRHelper.xrAcquireSwapchainImageDelegate

OpenXRHelper.xrCreateActionDelegate

The function delegate declaration of xrCreateAction.

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.xrCreateSwapchainDelegate

OpenXRHelper.xrDestroySpaceDelegate

The function delegate declaration of xrDestroySpace.

OpenXRHelper.xrDestroySwapchainDelegate

OpenXRHelper.xrEndFrameDelegate

The function delegate declaration of xrEndFrame.

OpenXRHelper.xrEnumerateDisplayRefreshRatesFBDelegate

The function delegate declaration of xrEnumerateDisplayRefreshRatesFB.

OpenXRHelper.xrEnumerateInstanceExtensionPropertiesDelegate

The function delegate declaration of xrEnumerateInstanceExtensionProperties.

OpenXRHelper.xrEnumerateReferenceSpacesDelegate

The function delegate declaration of xrEnumerateReferenceSpaces.

OpenXRHelper.xrEnumerateSwapchainFormatsDelegate

OpenXRHelper.xrEnumerateSwapchainImagesDelegate

OpenXRHelper.xrGetActionStatePoseDelegate

The function delegate declaration of xrGetActionStatePose.

OpenXRHelper.xrGetDisplayRefreshRateFBDelegate

OpenXRHelper.xrGetInputSourceLocalizedNameDelegate

The function delegate declaration of xrGetInputSourceLocalizedName.

OpenXRHelper.xrGetInstanceProcAddrDelegate

The function delegate declaration of xrGetInstanceProcAddr.

OpenXRHelper.xrGetSystemPropertiesDelegate

The function delegate declaration of xrGetSystemProperties.

OpenXRHelper.xrReleaseSwapchainImageDelegate

OpenXRHelper.xrRequestDisplayRefreshRateFBDelegate

The function delegate declaration of xrRequestDisplayRefreshRateFB.

OpenXRHelper.xrWaitFrameDelegate

The function delegate declaration of xrWaitFrame.

OpenXRHelper.xrWaitSwapchainImageDelegate

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.