Controladores de movimiento en Unity

Artículo
03/21/2023

Hay dos formas clave de tomar medidas en la mirada en Unity, gestos de mano y controladores de movimiento en HoloLens y HMD inmersivo. Puede acceder a los datos de ambos orígenes de entrada espacial a través de las mismas API de Unity.

Unity proporciona dos formas principales de acceder a los datos de entrada espaciales para Windows Mixed Reality. Las API de Input.GetButton/Input.GetAxis comunes funcionan en varios SDK de XR de Unity, mientras que la API InteractionManager/GestureRecognizer específica de Windows Mixed Reality expone el conjunto completo de datos de entrada espaciales.

API de entrada XR de Unity

En el caso de los nuevos proyectos, se recomienda usar las nuevas API de entrada XR desde el principio.

Puede encontrar más información sobre las API de XR aquí.

Tabla de asignación de ejes y botones de Unity

El Administrador de entrada de Unity para Windows Mixed Reality controladores de movimiento admite los identificadores de botón y eje que se enumeran a continuación a través de las API Input.GetButton/GetAxis. La columna "Específico de MR de Windows" hace referencia a las propiedades disponibles fuera del tipo InteractionSourceState . Cada una de estas API se describe con detalle en las secciones siguientes.

Las asignaciones de identificadores de botón o eje para Windows Mixed Reality generalmente coinciden con los identificadores de botón/eje de Windows Mixed Reality.

Las asignaciones de identificadores de botón o eje para Windows Mixed Reality difieren de las asignaciones de OpenVR de dos maneras:

La asignación usa identificadores de panel táctil que son distintos de la palanca de mandos, para admitir controladores con sticks de pulgar y paneles táctiles.
La asignación evita sobrecargar los identificadores de botón A y X para los botones Menú para dejarlos disponibles para los botones físicos ABXY.

Entrada	API comunes de Unity (Input.GetButton/GetAxis)		API de entrada específica de MR de Windows (XR. WSA. Entrada)
Entrada	Mano izquierda	Mano derecha
Selección del desencadenador presionado	Eje 9 = 1,0	Eje 10 = 1,0	selectPressed
Selección del valor analógico del desencadenador	Eje 9	Eje 10	selectPressedAmount
Seleccionar desencadenador presionado parcialmente	Botón 14 (compatibilidad con el controlador para juegos)	Botón 15 (compatibilidad con el controlador para juegos)	selectPressedAmount > 0.0
Botón de menú presionado	Botón 6*	Botón 7*	menuPressed
Botón de control presionado	Eje 11 = 1,0 (sin valores analógicos) Botón 4 (compatibilidad con el controlador para juegos)	Eje 12 = 1,0 (sin valores analógicos) Botón 5 (compatibilidad con el controlador para juegos)	Agarró
Stick X (izquierda: -1.0, derecha: 1.0)	Eje 1	Eje 4	thumbstickPosition.x
Stick pulgar Y (arriba: -1.0, inferior: 1.0)	Eje 2	Eje 5	thumbstickPosition.y
Stick pulgar presionado	Botón 8	Botón 9	thumbstickPressed
Touchpad X (izquierda: -1.0, derecha: 1.0)	Eje 17*	Eje 19*	touchpadPosition.x
Touchpad Y (superior: -1.0, inferior: 1.0)	Eje 18*	Eje 20*	touchpadPosition.y
Panel táctil táctil táctil	Botón 18*	Botón 19*	touchpadTouched
Panel táctil presionado	Botón 16*	Botón 17*	touchpadPressed
Posición de agarre 6DoF o posición de puntero	Posición de agarre solo: XR. InputTracking.GetLocalPosition XR. InputTracking.GetLocalRotation		Pase Grip o Puntero como argumento: sourceState.sourcePose.TryGetPosition sourceState.sourcePose.TryGetRotation
Estado de seguimiento	La precisión de la posición y el riesgo de pérdida de origen solo están disponibles a través de la API específica de MR		sourceState.sourcePose.positionAccuracy sourceState.properties.sourceLossRisk

Nota

Estos identificadores de botón o eje difieren de los identificadores que Unity usa para OpenVR debido a colisiones en las asignaciones usadas por los controladores para juegos, El Touch y OpenVR de Azure.

OpenXR

Para obtener información sobre los conceptos básicos sobre las interacciones de realidad mixta en Unity, visite el Manual de Unity para la entrada XR de Unity. En esta documentación de Unity se tratan las asignaciones de entradas específicas del controlador a entradas más generalizables InputFeatureUsages, cómo se pueden identificar y clasificar las entradas XR disponibles, cómo leer datos de estas entradas, etc.

El complemento de Mixed Reality OpenXR proporciona perfiles de interacción de entrada adicionales, asignados a inputFeatureUsageestándar, como se detalla a continuación:

InputFeatureUsage	Controlador HP Reverb G2 (OpenXR)	Mano de HoloLens (OpenXR)
primary2DAxis	Joystick
primary2DAxisClick	Joystick - Click
desencadenador	Desencadenador
Agarre	Agarre	Pulsación o compresión del aire
primaryButton	[X/A] - Presionar	Pulsar en el aire
secondaryButton	[Y/B] - Presionar
gripButton	Agarre : presione
triggerButton	Desencadenador: presione
menuButton	Menú

Posición de agarre frente a posición apuntada

Windows Mixed Reality admite controladores de movimiento en diversos factores de forma. El diseño de cada controlador difiere en su relación entre la posición de la mano del usuario y la dirección "hacia delante" natural que las aplicaciones deben usar para apuntar al representar el controlador.

Para representar mejor estos controladores, hay dos tipos de posturas que puede investigar para cada origen de interacción, la posición de agarre y la posición del puntero. Tanto la posición de agarre como las coordenadas de posición de puntero se expresan mediante todas las API de Unity en las coordenadas globales del mundo de Unity.

Posición de agarre

La posición de agarre representa la ubicación de la palma de los usuarios, ya sea detectada por un HoloLens o manteniendo un controlador de movimiento.

En cascos envolventes, la posición de agarre se usa mejor para representar la mano del usuario o un objeto que se mantiene en la mano del usuario. La posición de agarre también se usa al visualizar un controlador de movimiento. El modelo representable proporcionado por Windows para un controlador de movimiento usa la posición de agarre como su origen y centro de rotación.

La posición de agarre se define específicamente de la siguiente manera:

Posición de agarre: el centroide de la palma cuando mantiene el controlador naturalmente, ajustado a la izquierda o derecha para centrar la posición dentro del agarre. En el controlador de movimiento Windows Mixed Reality, esta posición generalmente se alinea con el botón Agarrar.
Eje derecho de la orientación de agarre: cuando abres completamente la mano para formar una posición plana de 5 dedos, el rayo normal a la palma (hacia delante de la palma izquierda, hacia atrás de la palma derecha)
Eje hacia delante de la orientación de agarre: al cerrar la mano parcialmente (como si sostenía el controlador), el rayo que apunta "hacia delante" a través del tubo formado por los dedos no pulgares.
Eje hacia arriba de la orientación de agarre: eje Hacia arriba implícito en las definiciones Derecha y Adelante.

Puede acceder a la posición de agarre a través de la API de entrada entre proveedores (XR) de Unity. InputTracking. GetLocalPosition/Rotation) o a través de la API específica de MR de Windows (sourceState.sourcePose.TryGetPosition/Rotation, solicitando datos de posición para el nodo Grip ).

Posición del puntero

La posición del puntero representa la punta del controlador que apunta hacia delante.

La posición de puntero proporcionada por el sistema se usa mejor para raycast cuando se representa el propio modelo de controlador. Si estás representando algún otro objeto virtual en lugar del controlador, como una pistola virtual, debes apuntar con un rayo más natural para ese objeto virtual, como un rayo que viaja a lo largo del cañón del modelo de pistola definido por la aplicación. Dado que los usuarios pueden ver el objeto virtual y no el controlador físico, apuntar con el objeto virtual probablemente será más natural para aquellos que usan la aplicación.

Actualmente, la posición del puntero solo está disponible en Unity a través de la API específica de MR de Windows, sourceState.sourcePose.TryGetPosition/Rotation, pasando InteractionSourceNode.Pointer como argumento.

OpenXR

Tiene acceso a dos conjuntos de poses a través de interacciones de entrada de OpenXR:

Las posturas de agarre para representar objetos en la mano
El objetivo es apuntar al mundo.

Puede encontrar más información sobre este diseño y las diferencias entre las dos posturas en las subrutas de especificación de OpenXR: subrutas de entrada.

Las poses proporcionadas por InputFeatureUsages DevicePosition, DeviceRotation, DeviceVelocity y DeviceAngularVelocity representan la posición de agarre de OpenXR. InputFeatureUsages relacionados con las posturas de agarre se definen en CommonUsages de Unity.

Las poses proporcionadas por InputFeatureUsages PointerPosition, PointerRotation, PointerVelocity y PointerAngularVelocity representan la posición de objetivo de OpenXR. Estos InputFeatureUsages no se definen en ningún archivo de C# incluido, por lo que deberá definir sus propios InputFeatureUsages de la siguiente manera:

public static readonly InputFeatureUsage<Vector3> PointerPosition = new InputFeatureUsage<Vector3>("PointerPosition");

Haptics

Para obtener información sobre el uso de hápticos en el sistema de entrada XR de Unity, puede encontrar documentación en el Manual de Unity para entrada XR de Unity: hápticos.

Estado de seguimiento del controlador

Al igual que los auriculares, el controlador de movimiento Windows Mixed Reality no requiere ninguna configuración de sensores de seguimiento externos. En su lugar, los sensores de los propios auriculares realizan un seguimiento de los controladores.

Si el usuario mueve los controladores fuera del campo de vista de los auriculares, Windows continúa inferiendo las posiciones del controlador en la mayoría de los casos. Cuando el controlador ha perdido el seguimiento visual durante bastante tiempo, las posiciones del controlador caerán en posiciones de precisión aproximada.

En este momento, el sistema bloqueará el cuerpo del controlador al usuario, realizando el seguimiento de la posición del usuario a medida que se mueve, a la vez que expone la verdadera orientación del controlador mediante sus sensores de orientación interna. Muchas aplicaciones que usan controladores para apuntar y activar elementos de la interfaz de usuario pueden funcionar normalmente, mientras que en precisión aproximada sin que el usuario se observe.

Razonamiento sobre el estado de seguimiento explícitamente

Las aplicaciones que deseen tratar las posiciones de forma diferente en función del estado de seguimiento pueden ir más allá e inspeccionar las propiedades en el estado del controlador, como SourceLossRisk y PositionAccuracy:

Estado de seguimiento	SourceLossRisk	PositionAccuracy	TryGetPosition
Alta precisión	< 1.0	Alto	true
Alta precisión (en riesgo de pérdida)	== 1.0	Alto	true
Precisión aproximada	== 1.0	Aproximado	true
Sin posición	== 1.0	Aproximado	false

Estos estados de seguimiento del controlador de movimiento se definen de la siguiente manera:

Alta precisión: Aunque el controlador de movimiento está dentro del campo de vista del casco, generalmente proporcionará posiciones de alta precisión, en función del seguimiento visual. Un controlador móvil que deja momentáneamente el campo de vista o se oscurece momentáneamente de los sensores de auriculares (por ejemplo, por la otra mano del usuario) seguirá devolviendo posturas de alta precisión durante un breve tiempo, en función del seguimiento inercial del propio controlador.
Alta precisión (en riesgo de pérdida): Cuando el usuario mueve el controlador de movimiento más allá del borde del campo de vista del casco, el casco pronto no podrá realizar un seguimiento visual de la posición del controlador. La aplicación sabe cuándo el controlador ha alcanzado este límite de FOV viendo que SourceLossRisk alcanza la versión 1.0. En ese momento, la aplicación puede optar por pausar los gestos del controlador que requieren una secuencia estable de posturas de alta calidad.
Precisión aproximada: Cuando el controlador ha perdido el seguimiento visual durante bastante tiempo, las posiciones del controlador caerán en posiciones de precisión aproximada. En este momento, el sistema bloqueará el cuerpo del controlador al usuario, realizando el seguimiento de la posición del usuario a medida que se mueve, a la vez que expone la verdadera orientación del controlador mediante sus sensores de orientación interna. Muchas aplicaciones que usan controladores para apuntar y activar elementos de la interfaz de usuario pueden funcionar de forma normal mientras se encuentra en precisión aproximada sin que el usuario se observe. Las aplicaciones con requisitos de entrada más pesados pueden optar por detectar esta caída de Alta precisión a Precisión aproximada inspeccionando la propiedad PositionAccuracy , por ejemplo, para dar al usuario una bandeja de acceso más generosa en los destinos fuera de la pantalla durante este tiempo.
Sin posición: Aunque el controlador puede funcionar con una precisión aproximada durante mucho tiempo, a veces el sistema sabe que incluso una posición bloqueada por el cuerpo no es significativa en este momento. Por ejemplo, es posible que un controlador que se haya activado nunca se haya observado visualmente, o un usuario puede colocar un controlador que luego lo recoge otra persona. En esos momentos, el sistema no proporcionará ninguna posición a la aplicación y TryGetPosition devolverá false.

API comunes de Unity (Input.GetButton/GetAxis)

Espacio de nombres:UnityEngine, UnityEngine.XR
Tipos: Entrada, XR. InputTracking

Unity usa actualmente sus API de Input.GetButton/Input.GetAxis generales para exponer la entrada para el SDK de Azure,el SDK de OpenVR y Windows Mixed Reality, incluidos los controladores de manos y movimiento. Si la aplicación usa estas API para la entrada, puede admitir fácilmente controladores de movimiento en varios SDK XR, incluida Windows Mixed Reality.

Obtención del estado presionado de un botón lógico

Para usar las API de entrada generales de Unity, normalmente comenzará por conectar botones y ejes a nombres lógicos en el Administrador de entrada de Unity, enlazar un botón o identificadores de eje a cada nombre. A continuación, puede escribir código que haga referencia a ese nombre de eje o botón lógico.

Por ejemplo, para asignar el botón de desencadenador del controlador de movimiento izquierdo a la acción Enviar, vaya a Editar > entrada de configuración > del proyecto en Unity y expanda las propiedades de la sección Enviar en ejes. Cambie la propiedad Botón positivo o Botón positivo alternativo para leer el botón de joystick 14, de la siguiente manera:

InputManager de Unity
Unity InputManager

Después, el script puede comprobar la acción Enviar mediante Input.GetButton:

if (Input.GetButton("Submit"))
{
  // ...
}

Puede agregar más botones lógicos cambiando la propiedad Size en ejes.

Obtener el estado presionado de un botón físico directamente

También puede acceder a los botones manualmente por su nombre completo mediante Input.GetKey:

if (Input.GetKey("joystick button 8"))
{
  // ...
}

Obtener la posición de un controlador de mano o movimiento

Puede acceder a la posición y rotación del controlador mediante XR. InputTracking:

Vector3 leftPosition = InputTracking.GetLocalPosition(XRNode.LeftHand);
Quaternion leftRotation = InputTracking.GetLocalRotation(XRNode.LeftHand);

Nota

El código anterior representa la posición de agarre del controlador (donde el usuario mantiene el controlador), que es útil para representar una espada o un arma en la mano del usuario, o un modelo del propio controlador.

La relación entre esta posición de agarre y la posición del puntero (donde la punta del controlador apunta) puede diferir entre los controladores. En este momento, el acceso a la posición del puntero del controlador solo es posible a través de la API de entrada específica de MR, que se describe en las secciones siguientes.

API específicas de Windows (XR). WSA. Entrada)

Precaución

Si el proyecto usa cualquiera de las XR. Las API de WSA, estas se están eliminando gradualmente en favor del SDK de XR en futuras versiones de Unity. En el caso de los nuevos proyectos, se recomienda usar el SDK de XR desde el principio. Puede encontrar más información sobre el sistema de entrada XR y las API aquí.

Espacio de nombres:UnityEngine.XR.WSA.Input
Tipos: InteractionManager, InteractionSourceState, InteractionSource, InteractionSourceProperties, InteractionSourceKind, InteractionSourceLocation

Para obtener información más detallada sobre Windows Mixed Reality entrada a mano (para HoloLens) y controladores de movimiento, puedes elegir usar las API de entrada espacial específicas de Windows en el espacio de nombres UnityEngine.XR.WSA.Input. Esto le permite acceder a información adicional, como la precisión de la posición o el tipo de origen, lo que le permite separar las manos y los controladores.

Sondear el estado de las manos y los controladores de movimiento

Puede sondear el estado de este fotograma para cada origen de interacción (controlador de mano o movimiento) mediante el método GetCurrentReading .

var interactionSourceStates = InteractionManager.GetCurrentReading();
foreach (var interactionSourceState in interactionSourceStates) {
    // ...
}

Cada InteractionSourceState que se obtiene representa un origen de interacción en el momento actual en el tiempo. InteractionSourceState expone información como:

Qué tipos de prensa se producen (Select/Menu/Grasp/Touchpad/Thumbstick)
```
if (interactionSourceState.selectPressed) {
     // ...
}
```
Otros datos específicos de los controladores de movimiento, como las coordenadas XY del panel táctil o del stick analógico y el estado táctil
```
if (interactionSourceState.touchpadTouched && interactionSourceState.touchpadPosition.x > 0.5) {
     // ...
}
```
InteractionSourceKind para saber si el origen es una mano o un controlador de movimiento
```
if (interactionSourceState.source.kind == InteractionSourceKind.Hand) {
     // ...
}
```

Sondeo de las posturas de representación previstas hacia delante

Al sondear los datos de origen de interacción de manos y controladores, las posturas que obtiene son posturas predichos hacia delante durante el momento en que los fotones de este fotograma llegarán a los ojos del usuario. Las posturas predichos hacia delante se usan mejor para representar el controlador o un objeto retenido cada fotograma. Si el destino es una prensa o versión determinada con el controlador, será más preciso si usa las API de eventos históricos que se describen a continuación.
```
var sourcePose = interactionSourceState.sourcePose;
Vector3 sourceGripPosition;
Quaternion sourceGripRotation;
if ((sourcePose.TryGetPosition(out sourceGripPosition, InteractionSourceNode.Grip)) &&
     (sourcePose.TryGetRotation(out sourceGripRotation, InteractionSourceNode.Grip))) {
     // ...
}
```
También puede obtener la posición de cabeza prevista hacia delante para este fotograma actual. Al igual que con la posición de origen, esto resulta útil para representar un cursor, aunque el destino de una determinada prensa o versión será más preciso si usa las API de eventos históricos que se describen a continuación.
```
var headPose = interactionSourceState.headPose;
var headRay = new Ray(headPose.position, headPose.forward);
RaycastHit raycastHit;
if (Physics.Raycast(headPose.position, headPose.forward, out raycastHit, 10)) {
     var cursorPos = raycastHit.point;
     // ...
}
```

Control de eventos de origen de interacción

Para controlar los eventos de entrada a medida que se producen con sus datos de posición históricos precisos, puede controlar los eventos de origen de interacción en lugar de sondear.

Para controlar los eventos de origen de interacción:

Regístrese para un evento de entrada interactionManager . Para cada tipo de evento de interacción que le interese, debe suscribirse a él.
```
InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
```

Controle el evento. Una vez que se haya suscrito a un evento de interacción, obtendrá la devolución de llamada cuando corresponda. En el ejemplo SourcePressed , esto será después de que se detectó el origen y antes de que se libere o pierda.

void InteractionManager_InteractionSourceDetected(InteractionSourceDetectedEventArgs args)
     var interactionSourceState = args.state;

     // args.state has information about:
        // targeting head ray at the time when the event was triggered
        // whether the source is pressed or not
        // properties like position, velocity, source loss risk
        // source id (which hand id for example) and source kind like hand, voice, controller or other
}

Cómo detener el control de un evento

Debe dejar de controlar un evento cuando ya no le interese el evento o está destruyendo el objeto que se ha suscrito al evento. Para dejar de controlar el evento, cancela la suscripción del evento.

InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;

Lista de eventos de origen de interacción

Los eventos de origen de interacción disponibles son:

InteractionSourceDetected (el origen se activa)
InteractionSourceLost (se vuelve inactivo)
InteractionSourcePressed (pulsación, pulsación de botón o expresión "Seleccionar")
InteractionSourceReleased (final de una pulsación, un botón liberado o el final de la expresión "Select")
InteractionSourceUpdated (mueve o cambia algún estado)

Los eventos para la segmentación histórica suponen que coinciden con más precisión con una prensa o un comunicado

Las API de sondeo descritas anteriormente proporcionan las posturas previstas para la aplicación. Aunque esas posturas previstas son las mejores para representar el controlador o un objeto de mano virtual, las posturas futuras no son óptimas para el destino, por dos razones clave:

Cuando el usuario presiona un botón en un controlador, puede haber aproximadamente 20 ms de latencia inalámbrica sobre Bluetooth antes de que el sistema reciba la prensa.
Después, si usa una posición de predicción hacia delante, habría otra predicción de 10 a 20 ms aplicada para dirigirse a la hora en que los fotones del fotograma actual llegarán a los ojos del usuario.

Esto significa que el sondeo le da una posición de origen o una posición de cabeza que es de 30-40 ms hacia adelante desde donde la cabeza y las manos del usuario realmente estaban atrás cuando se produjo la prensa o el comunicado. Para la entrada de la mano de HoloLens, aunque no hay ningún retraso de transmisión inalámbrica, hay un retraso de procesamiento similar para detectar la presión.

Para dirigirse con precisión en función de la intención original del usuario para una pulsación de mano o controlador, debe usar la posición del origen histórico o la posición principal de ese evento de entrada InteractionSourcePressed o InteractionSourceReleased .

Puede dirigirse a una prensa o un comunicado con datos históricos de la posición desde la cabeza del usuario o su controlador:

La posición de la cabeza en el momento en que se produjo una pulsación de gesto o controlador, que se puede usar para seleccionar el destino para determinar en qué estaba mirando el usuario:

void InteractionManager_InteractionSourcePressed(InteractionSourcePressedEventArgs args) {
     var interactionSourceState = args.state;
     var headPose = interactionSourceState.headPose;
     RaycastHit raycastHit;
     if (Physics.Raycast(headPose.position, headPose.forward, out raycastHit, 10)) {
         var targetObject = raycastHit.collider.gameObject;
         // ...
     }
}

Posición de origen en el momento en que se produjo una presión del controlador de movimiento, que se puede usar para seleccionar como destino para determinar a qué apuntaba el usuario el controlador. Este será el estado del controlador que experimentó la prensa. Si va a representar el propio controlador, puede solicitar la posición del puntero en lugar de la posición de agarre, para disparar el rayo de selección desde lo que el usuario considerará la punta natural de ese controlador representado:

void InteractionManager_InteractionSourcePressed(InteractionSourcePressedEventArgs args)
{
     var interactionSourceState = args.state;
     var sourcePose = interactionSourceState.sourcePose;
     Vector3 sourceGripPosition;
     Quaternion sourceGripRotation;
     if ((sourcePose.TryGetPosition(out sourceGripPosition, InteractionSourceNode.Pointer)) &&
         (sourcePose.TryGetRotation(out sourceGripRotation, InteractionSourceNode.Pointer))) {
         RaycastHit raycastHit;
         if (Physics.Raycast(sourceGripPosition, sourceGripRotation * Vector3.forward, out raycastHit, 10)) {
             var targetObject = raycastHit.collider.gameObject;
             // ...
         }
     }
}

Ejemplo de controladores de eventos

using UnityEngine.XR.WSA.Input;

void Start()
{
    InteractionManager.InteractionSourceDetected += InteractionManager_InteractionSourceDetected;
    InteractionManager.InteractionSourceLost += InteractionManager_InteractionSourceLost;
    InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
    InteractionManager.InteractionSourceReleased += InteractionManager_InteractionSourceReleased;
    InteractionManager.InteractionSourceUpdated += InteractionManager_InteractionSourceUpdated;
}

void OnDestroy()
{
    InteractionManager.InteractionSourceDetected -= InteractionManager_InteractionSourceDetected;
    InteractionManager.InteractionSourceLost -= InteractionManager_InteractionSourceLost;
    InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;
    InteractionManager.InteractionSourceReleased -= InteractionManager_InteractionSourceReleased;
    InteractionManager.InteractionSourceUpdated -= InteractionManager_InteractionSourceUpdated;
}

void InteractionManager_InteractionSourceDetected(InteractionSourceDetectedEventArgs args)
{
    // Source was detected
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourceLost(InteractionSourceLostEventArgs state)
{
    // Source was lost. This will be after a SourceDetected event and no other events for this
    // source id will occur until it is Detected again
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourcePressed(InteractionSourcePressedEventArgs state)
{
    // Source was pressed. This will be after the source was detected and before it is
    // released or lost
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourceReleased(InteractionSourceReleasedEventArgs state)
{
    // Source was released. The source would have been detected and pressed before this point.
    // This event will not fire if the source is lost
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourceUpdated(InteractionSourceUpdatedEventArgs state)
{
    // Source was updated. The source would have been detected before this point
    // args.state has the current state of the source including id, position, kind, etc.
}

Controladores de movimiento en MRTK

Puede acceder al gesto y al controlador de movimiento desde el Administrador de entrada.

Seguimiento de tutoriales

Los tutoriales paso a paso, con ejemplos de personalización más detallados, están disponibles en la academia de Mixed Reality:

Entrada de MR 213: controlador de movimiento

Siguiente punto de control de desarrollo

Si sigue el recorrido de desarrollo de Unity que hemos diseñado, está en medio de explorar los bloques de creación principales de MRTK. Desde aquí, puede continuar con el siguiente bloque de compilación:

Seguimiento de manos y ocular

O bien puede saltar a las funcionalidades y las API de la plataforma de realidad mixta:

Experiencias compartidas

Puede volver a los puntos de control de desarrollo de Unity en cualquier momento.

Controladores de movimiento en Unity

API de entrada XR de Unity

Tabla de asignación de ejes y botones de Unity

OpenXR

Posición de agarre frente a posición apuntada

Posición de agarre

Posición del puntero

OpenXR

Haptics

Estado de seguimiento del controlador

Razonamiento sobre el estado de seguimiento explícitamente

API comunes de Unity (Input.GetButton/GetAxis)

Obtención del estado presionado de un botón lógico

Obtener el estado presionado de un botón físico directamente

Obtener la posición de un controlador de mano o movimiento

API específicas de Windows (XR). WSA. Entrada)

Sondear el estado de las manos y los controladores de movimiento

Sondeo de las posturas de representación previstas hacia delante

Control de eventos de origen de interacción

Cómo detener el control de un evento

Lista de eventos de origen de interacción

Los eventos para la segmentación histórica suponen que coinciden con más precisión con una prensa o un comunicado

Ejemplo de controladores de eventos

Controladores de movimiento en MRTK

Seguimiento de tutoriales

Siguiente punto de control de desarrollo

Consulta también

Recursos adicionales