Controladores de movimiento en Unity

Artículo
03/21/2023

Hay dos maneras 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 espacial 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 espacial.

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 controladores de movimiento de Windows Mixed Reality 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ífica de MR de Windows" hace referencia a las propiedades disponibles fuera del tipo InteractionSourceState . Cada una de estas API se describe en detalle en las secciones siguientes.

Las asignaciones de identificadores de botón o eje para Windows Mixed Reality suelen coincidir con los identificadores de eje o botón de Contosos.

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 barra 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	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
Selección del 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 (superior: -1.0, inferior: 1.0)	Eje 2	Eje 5	thumbstickPosition.y
Palanca de pulgar presionada	Botón 8	Botón 9	thumbstickPressed
Panel táctil X (izquierda: -1.0, derecha: 1.0)	Eje 17*	Eje 19*	touchpadPosition.x
Panel táctil Y (superior: -1.0, inferior: 1.0)	Eje 18*	Eje 20*	touchpadPosition.y
Panel táctil	Botón 18*	Botón 19*	panel táctilTouched
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	Precisión de la posición y riesgo de pérdida de origen solo disponible 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.

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 para entradas más generalizables InputFeatureUsage, cómo se pueden identificar y clasificar las entradas XR disponibles, cómo leer datos de estas entradas, etc.

El complemento OpenXR de Mixed Reality 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 - Clic
desencadenador	Desencadenador
agarrar	Agarrar	Pulsación o compresión del aire
primaryButton	[X/A] - Presione	Pulsar en el aire
secondaryButton	[Y/B] - Presione
gripButton	Agarre - Presione
triggerButton	Desencadenador: presione
menuButton	Menu

Posición de agarre frente a posición apuntada

Windows Mixed Reality admite controladores de movimiento en una variedad de 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 del puntero se expresan mediante todas las API de Unity en 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 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 mantenido 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 al mantener el controlador naturalmente, ajustado a la izquierda o derecha para centrar la posición dentro del agarre. En el controlador de movimiento de 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 desde la palma derecha)
Eje hacia delante de la orientación del 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: el eje Hacia arriba implícito en las definiciones derecha y hacia delante.

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 representa algún otro objeto virtual en lugar del controlador, como una pistola virtual, debe 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 posturas 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 openXR Specification - Input Subpaths.

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");

Háptica

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 de Windows Mixed Reality no requiere ninguna configuración de sensores de seguimiento externos. En su lugar, los sensores realizan un seguimiento de los controladores en el propio casco.

Si el usuario mueve los controladores fuera del campo de vista del casco, 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 un seguimiento de la posición del usuario mientras se mueven, mientras se sigue exponiendo la orientación verdadera 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 note.

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 oculta momentáneamente de los sensores de auriculares (por ejemplo, por la otra parte 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 perder): 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 un flujo 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 un seguimiento de la posición del usuario mientras se mueven, mientras se sigue exponiendo la orientación verdadera del controlador mediante sus sensores de orientación interna. Muchas aplicaciones que usan controladores para apuntar a los elementos de la interfaz de usuario y activar pueden funcionar como normales, mientras que en precisión aproximada sin que el usuario se note. Las aplicaciones con requisitos de entrada más pesados pueden optar por detectar esta caída de Alta precisión a Precisión aproximada mediante la inspección de la propiedad PositionAccuracy, por ejemplo, para dar al usuario una caja de acceso más generosa en 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 sea recogido por 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 Graphs, 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 empezará por conectar botones y ejes a nombres lógicos en el Administrador de entrada de Unity, enlazar un identificador de botón o 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 manualmente a los botones por su nombre completo mediante Input.GetKey:

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

Obtención de 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 contiene el controlador), que es útil para representar una espada o 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 la entrada manual de Windows Mixed Reality (para HoloLens) y los controladores de movimiento, puede 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 devuelve 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, tales como las coordenadas XY y/o las coordenadas XY del stick táctil 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) {
     // ...
}
```

Sondear las posturas de representación predichos 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 mantenido cada fotograma. Si tiene como destino una versión o prensa determinada con el controlador, será más precisa 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 principal predicho hacia delante para este fotograma actual. Al igual que con la posición de origen, esto es ú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órico 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 detener el control de 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 "Seleccionar")
InteractionSourceUpdated (mueve o cambia algún estado)

Los eventos para los objetivos históricos suponen que coinciden con más precisión con una prensa o versión

Las API de sondeo descritas anteriormente proporcionan las posturas predichos de la aplicación. Aunque esas posturas previstas son las mejores para representar el controlador o un objeto portátil virtual, las futuras posturas 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 presión.
A continuación, si usa una posición predicho hacia delante, habría otra predicción de 10 a 20 ms de avance aplicada para tener como destino la hora en que los fotones del fotograma actual llegarán a los ojos del usuario.

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

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 de origen histórica o la posición principal de ese evento de entrada InteractionSourcePressed o InteractionSourceReleased .

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

Posición de la cabeza en el momento en que se produjo un gesto o una pulsación del controlador, que se puede usar para dirigirse para determinar lo que el usuario estaba mirando en:

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 dirigirse para determinar en qué apuntaba el usuario el controlador. Este será el estado del controlador que experimentó la presión. Si está representando el propio controlador, puede solicitar la posición del puntero en lugar de la posición de agarre, para disparar el rayo de destino 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 controlador de movimiento y gestos 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 mixed Reality Academy:

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 la exploración de 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.

Compartir a través de

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

Háptica

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

Obtención de 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

Sondear las posturas de representación predichos 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 los objetivos históricos suponen que coinciden con más precisión con una prensa o versión

Ejemplo de controladores de eventos

Controladores de movimiento en MRTK

Seguimiento de tutoriales

Siguiente punto de control de desarrollo

Consulte también

Recursos adicionales