Namespace Wave.OpenXR

Classes

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.

Structs

XrBool32

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

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.

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

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.

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.

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.

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.

Namespace Wave.OpenXR

Classes

Structs

Enums

Delegates