Controller di movimento in Unity

Esistono due modi chiave per intervenire sullo sguardo fisso in Unity, i movimenti delle mani e i controller di movimento in HoloLens e HMD immersive. È possibile accedere ai dati per entrambe le origini di input spaziale tramite le stesse API in Unity.

Unity offre due modi principali per accedere ai dati di input spaziali per Windows Realtà mista. Le API Input.GetButton/Input.GetAxis comuni funzionano in più SDK XR di Unity, mentre l'API InteractionManager/GestureRecognizer specifica di Windows Realtà mista espone il set completo di dati di input spaziali.

API di input XR di Unity

Per i nuovi progetti, è consigliabile usare le nuove API di input XR fin dall'inizio.

Altre informazioni sulle API XR sono disponibili qui.

Tabella di mapping del pulsante/asse di Unity

Gestione input di Unity per i controller di movimento di Windows Realtà mista supporta gli ID pulsante e asse elencati di seguito tramite le API Input.GetButton/GetAxis. La colonna "Windows MR-specific" si riferisce alle proprietà disponibili al di fuori del tipo InteractionSourceState . Ognuna di queste API è descritta in dettaglio nelle sezioni seguenti.

I mapping id pulsante/asse per Windows Realtà mista in genere corrispondono agli ID pulsante/asse Oculus.

I mapping degli ID pulsante/asse per Windows Realtà mista differiscono dai mapping di OpenVR in due modi:

1. Il mapping usa ID touchpad distinti dalle levette, per supportare i controller con levette e touchpad.
2. Il mapping evita l'overload degli ID pulsante A e X per i pulsanti menu per lasciarli disponibili per i pulsanti ABXY fisici.

OpenXR

Per informazioni sulle nozioni di base sulle interazioni di realtà mista in Unity, vedere Il manuale di Unity per l'input XR di Unity. Questa documentazione di Unity illustra i mapping da input specifici del controller a input più generalizzabili InputFeatureUsages, il modo in cui è possibile identificare e classificare gli input XR disponibili, come leggere i dati da questi input e altro ancora.

Il plug-in OpenXR Realtà mista fornisce profili di interazione di input aggiuntivi, mappati a InputFeatureUsagestandard, come descritto di seguito:

Posizione del grip rispetto alla posizione puntante

Windows Realtà mista supporta i controller del movimento in diversi fattori di forma. La progettazione di ogni controller differisce nella relazione tra la posizione della mano dell'utente e la direzione "avanti" naturale che le app devono usare per puntare durante il rendering del controller.

Per rappresentare meglio questi controller, esistono due tipi di pose che è possibile analizzare per ogni origine di interazione, la posizione del grip e la posizione del puntatore. Sia la posizione del grip che le coordinate della posizione del puntatore sono espresse da tutte le API Unity nelle coordinate globali di Unity.

Posa del grip

La posizione del grip rappresenta la posizione del palmo dell'utente, rilevata da un dispositivo HoloLens o tenendo premuto un controller di movimento.

Nei visori VR immersive, la posizione del grip viene usata meglio per eseguire il rendering della mano dell'utente o di un oggetto tenuto nella mano dell'utente. La posizione del grip viene usata anche per la visualizzazione di un controller di movimento. Il modello di cui è possibile eseguire il rendering fornito da Windows per un controller di movimento usa la posizione del grip come origine e centro di rotazione.

La posizione del grip viene definita in modo specifico come indicato di seguito:

• Posizione del grip: il centro del palmo quando si tiene il controller naturalmente, regolato da sinistra o da destra al centro della posizione all'interno del grip. Nel controller del movimento di Windows Realtà mista questa posizione è in genere allineata al pulsante Afferra.
• Asse destro dell'orientamento del grip: quando si apre completamente la mano per formare una posizione piatta a 5 dita, il raggio normale al palmo (avanti dal palmo sinistro, all'indietro dal palmo destro)
• Asse di avanzamento dell'orientamento del grip: quando si chiude la mano parzialmente (come se si tiene il controller), il raggio che punta "avanti" attraverso il tubo formato dalle dita non pollice.
• Asse Up dell'orientamento del grip: asse Su implicito dalle definizioni Destra e Avanti.

È possibile accedere alla posa del grip tramite l'API di input tra fornitori (XR) di Unity. InputTracking. GetLocalPosition/Rotation) o tramite l'API specifica di Windows MR (sourceState.sourcePose.TryGetPosition/Rotation, richiedendo dati di posa per il nodo Grip ).

Posizione del puntatore

La posizione del puntatore rappresenta la punta del controller che punta in avanti.

La posizione del puntatore fornita dal sistema viene usata meglio per il raycast quando si esegue il rendering del modello controller stesso. Se si esegue il rendering di altri oggetti virtuali al posto del controller, ad esempio una pistola virtuale, è consigliabile puntare con un raggio più naturale per quell'oggetto virtuale, ad esempio un raggio che viaggia lungo il barile del modello di pistola definito dall'app. Poiché gli utenti possono visualizzare l'oggetto virtuale e non il controller fisico, il punto con l'oggetto virtuale sarà probabilmente più naturale per quelli che usano l'app.

Attualmente, la posizione del puntatore è disponibile in Unity solo tramite l'API specifica di Windows MR, sourceState.sourcePose.TryGetPosition/Rotation, passando InteractionSourceNode.Pointer come argomento.

OpenXR

È possibile accedere a due set di pose tramite interazioni di input OpenXR:

• La posizione del grip per il rendering degli oggetti nella mano
• L'obiettivo è puntare al mondo.

Altre informazioni su questa progettazione e sulle differenze tra le due posizioni sono disponibili in OpenXR Specification - Input Subpaths( Specifica OpenXR - Input).

Le pose fornite da InputFeatureUsages DevicePosition, DeviceRotation, DeviceVelocity e DeviceAngularVelocity rappresentano tutti la posizione del grip OpenXR. InputFeatureUsages correlato alle pose del grip sono definiti in CommonUsages di Unity.

Le pose fornite da InputFeatureUsages PointerPosition, PointerRotation, PointerVelocity e PointerAngularVelocity rappresentano tutti la posizione dell'obiettivo OpenXR. Questi InputFeatureUsages non sono definiti in alcun file C# incluso, quindi è necessario definire i propri InputFeatureUsages come indicato di seguito:

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

Aptici

Per informazioni sull'uso di aptici nel sistema di input XR di Unity, la documentazione è disponibile in Unity Manual for Unity XR Input - Haptics (Manuale di Unity per input XR - Haptics).

Stato di rilevamento del controller

Come i visori VR, il controller di movimento di Windows Realtà mista non richiede alcuna configurazione di sensori di rilevamento esterni. I controller vengono invece rilevati dai sensori nel visore VR stesso.

Se l'utente sposta i controller fuori dal campo visivo del visore VR, Windows continua a dedurre le posizioni del controller nella maggior parte dei casi. Quando il controller ha perso il rilevamento visivo per un periodo di tempo sufficiente, le posizioni del controller scenderanno a posizioni approssimative di accuratezza.

A questo punto, il sistema blocca il controller all'utente, tenendo traccia della posizione dell'utente mentre si sposta, pur esponendo il vero orientamento del controller usando i sensori di orientamento interni. Molte app che usano controller per puntare e attivare gli elementi dell'interfaccia utente possono funzionare normalmente in modo approssimativo senza che l'utente noti.

Ragionamento sullo stato di rilevamento in modo esplicito

Le app che desiderano gestire le posizioni in modo diverso in base allo stato di rilevamento possono andare oltre e controllare le proprietà sullo stato del controller, ad esempio SourceLossRisk e PositionAccuracy:

Questi stati di rilevamento del controller del movimento sono definiti come segue:

• Accuratezza elevata: mentre il controller del movimento si trova all'interno del campo visivo del visore VR, in genere fornirà posizioni ad alta precisione, in base al tracciamento visivo. Un controller in movimento che lascia momentaneamente il campo di visualizzazione o è momentaneamente nascosto dai sensori visori VR (ad esempio, dall'altra parte dell'utente) continuerà a restituire pose ad alta precisione per un breve periodo di tempo, in base al tracciamento inerziale del controller stesso.
• Accuratezza elevata (a rischio di perdita): quando l'utente sposta il controller del movimento oltre il bordo del campo visivo del visore VR, il visore VR non sarà presto in grado di tenere traccia visivamente della posizione del controller. L'app sa quando il controller ha raggiunto questo limite FOV visualizzando SourceLossRisk raggiungere la versione 1.0. A questo punto, l'app può scegliere di sospendere i movimenti del controller che richiedono un flusso costante di pose di alta qualità.
• Accuratezza approssimativa: quando il controller ha perso il rilevamento visivo per un tempo sufficiente, le posizioni del controller scenderanno a posizioni approssimative di accuratezza. A questo punto, il sistema blocca il controller all'utente, tenendo traccia della posizione dell'utente mentre si sposta, pur esponendo il vero orientamento del controller usando i sensori di orientamento interni. Molte app che usano i controller per puntare e attivare gli elementi dell'interfaccia utente possono funzionare come di consueto, pur con precisione approssimativa senza che l'utente noti. Le app con requisiti di input più pesanti possono scegliere di percepire questo calo da Accuratezza elevata a Accuratezza approssimativa controllando la proprietà PositionAccuracy , ad esempio per offrire all'utente un hitbox più generoso sulle destinazioni fuori schermo durante questo periodo.
• Nessuna posizione: mentre il controller può operare con precisione approssimativa per molto tempo, a volte il sistema sa che anche una posizione bloccata dal corpo non è significativa al momento. Ad esempio, un controller che è stato attivato potrebbe non essere mai stato osservato visivamente o un utente potrebbe mettere giù un controller che viene quindi prelevato da un altro utente. In questi casi, il sistema non fornirà alcuna posizione all'app e TryGetPosition restituirà false.

API Unity comuni (Input.GetButton/GetAxis)

Spazio dei nomi: UnityEngine, UnityEngine.XR
Tipi: input, XR. InputTracking

Unity usa attualmente le api generali Input.GetButton/Input.GetAxis per esporre l'input per Oculus SDK, OpenVR SDK e Windows Realtà mista, inclusi i controller di movimento e le mani. Se l'app usa queste API per l'input, può supportare facilmente i controller di movimento tra più SDK XR, tra cui Windows Realtà mista.

Ottenere lo stato premuto di un pulsante logico

Per usare le API di input di Unity generali, in genere si inizierà associando pulsanti e assi ai nomi logici in Unity Input Manager, associando un pulsante o id asse a ogni nome. È quindi possibile scrivere codice che fa riferimento al nome del pulsante o dell'asse logico.

Ad esempio, per eseguire il mapping del pulsante trigger del controller del movimento sinistro all'azione Invia, passare a Modifica > input impostazioni > progetto in Unity ed espandere le proprietà della sezione Invia in Assi. Modificare la proprietà Pulsante positivo o Alt pulsante positivo per leggere il pulsante joystick 14, come illustrato di seguito:

Unity InputManager

Lo script può quindi verificare la presenza dell'azione Submit usando Input.GetButton:

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

È possibile aggiungere altri pulsanti logici modificando la proprietà Size in Assi.

Ottenere direttamente lo stato premuto di un pulsante fisico

È anche possibile accedere manualmente ai pulsanti in base al nome completo, usando Input.GetKey:

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

Posa di una mano o di un controller del movimento

È possibile accedere alla posizione e alla rotazione del controller usando XR. InputTracking:

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

API specifiche di Windows (XR. WSA. Input)

Spazio dei nomi: UnityEngine.XR.WSA.Input
Tipi: InteractionManager, InteractionSourceState, InteractionSource, InteractionSourceProperties, InteractionSourceKind, InteractionSourceLocation

Per ottenere informazioni più dettagliate sull'input manuale di Windows Realtà mista (per HoloLens) e sui controller di movimento, è possibile scegliere di usare le API di input spaziale specifiche di Windows nello spazio dei nomi UnityEngine.XR.WSA.Input. In questo modo è possibile accedere a informazioni aggiuntive, ad esempio l'accuratezza della posizione o il tipo di origine, consentendo di distinguere le mani e i controller.

Polling per lo stato delle mani e dei controller del movimento

È possibile eseguire il polling dello stato di questo fotogramma per ogni origine di interazione (controller di movimento o mano) usando il metodo GetCurrentReading .

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

Ogni InteractionSourceState che si ottiene rappresenta un'origine di interazione nel momento corrente. InteractionSourceState espone informazioni come:

• Quali tipi di presse si verificano (Select/Menu/Grasp/Touchpad/Thumbstick)

  if (interactionSourceState.selectPressed) {
       // ...
  }
  

• Altri dati specifici per i controller del movimento, ad esempio le coordinate XY del touchpad e/o della levetta e lo stato toccato

  if (interactionSourceState.touchpadTouched && interactionSourceState.touchpadPosition.x > 0.5) {
       // ...
  }
  

• InteractionSourceKind per sapere se l'origine è una mano o un controller del movimento

  if (interactionSourceState.source.kind == InteractionSourceKind.Hand) {
       // ...
  }
  

Polling per le posizioni di rendering predite in avanti

• Quando si esegue il polling dei dati delle origini di interazione da mani e controller, le pose che si ottengono sono pose predisse in avanti per il momento in cui i fotoni di questo fotogramma raggiungeranno gli occhi dell'utente. Le pose stimate in avanti sono usate meglio per il rendering del controller o di un oggetto mantenuto ogni cornice. Se si ha come destinazione un determinato comunicato stampa o rilascio con il controller, sarà più accurato se si usano le API degli eventi cronologici descritte di seguito.

  var sourcePose = interactionSourceState.sourcePose;
  Vector3 sourceGripPosition;
  Quaternion sourceGripRotation;
  if ((sourcePose.TryGetPosition(out sourceGripPosition, InteractionSourceNode.Grip)) &&
       (sourcePose.TryGetRotation(out sourceGripRotation, InteractionSourceNode.Grip))) {
       // ...
  }
  

• È anche possibile ottenere la posizione della testa stimata in avanti per questo fotogramma corrente. Come per la posizione di origine, questo è utile per il rendering di un cursore, anche se la destinazione di una determinata stampa o rilascio sarà più accurata se si usano le API degli eventi cronologici descritte di seguito.

  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;
       // ...
  }
  

Gestione degli eventi dell'origine di interazione

Per gestire gli eventi di input man mano che si verificano con i dati di posizione cronologica accurati, è possibile gestire gli eventi dell'origine di interazione anziché il polling.

Per gestire gli eventi dell'origine di interazione:

• Registrarsi per un evento di input InteractionManager . Per ogni tipo di evento di interazione a cui si è interessati, è necessario sottoscriverlo.

  InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
  

• Gestire l'evento. Dopo aver sottoscritto un evento di interazione, si otterrà il callback quando appropriato. Nell'esempio SourcePressed , questo sarà dopo che l'origine è stata rilevata e prima che venga rilasciata o persa.

  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
  }
  

Come interrompere la gestione di un evento

È necessario interrompere la gestione di un evento quando non si è più interessati all'evento o si sta eliminando l'oggetto che ha sottoscritto l'evento. Per interrompere la gestione dell'evento, annullare la sottoscrizione all'evento.

InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;

Elenco degli eventi dell'origine di interazione

Gli eventi dell'origine di interazione disponibili sono:

• InteractionSourceDetected (l'origine diventa attiva)
• InteractionSourceLost (diventa inattivo)
• InteractionSourcePressed (tocco, pressione del pulsante o "Seleziona" espressione)
• InteractionSourceReleased (fine di un tocco, pulsante rilasciato o fine dell'espressione "Seleziona")
• InteractionSourceUpdated (sposta o modifica in altro modo uno stato)

Gli eventi per la destinazione cronologica rappresentano una corrispondenza più accurata con una stampa o un comunicato stampa

Le API di polling descritte in precedenza forniscono all'app pose forward-predicted. Sebbene queste pose stimate siano ottimali per il rendering del controller o di un oggetto palmare virtuale, le pose future non sono ottimali per la destinazione, per due motivi chiave:

• Quando l'utente preme un pulsante su un controller, può esserci circa 20 ms di latenza wireless su Bluetooth prima che il sistema riceva la pressione.
• Quindi, se si usa una posizione stimata in avanti, ci sarebbero altri 10-20 ms di stima in avanti applicati per impostare come destinazione l'ora in cui i fotoni della cornice corrente raggiungeranno gli occhi dell'utente.

Questo significa che il polling fornisce una posizione o una posizione della testa di origine che è di 30-40 ms in avanti da dove la testa e le mani dell'utente erano effettivamente indietro quando la stampa o il rilascio è successo. Per l'input manuale di HoloLens, mentre non è presente alcun ritardo di trasmissione wireless, c'è un ritardo di elaborazione simile per rilevare la pressione.

Per impostare con precisione la destinazione in base alla finalità originale dell'utente per una pressione della mano o del controller, è necessario usare la posizione cronologica dell'origine o della testa dall'evento di input InteractionSourcePressed o InteractionSourceReleased .

È possibile specificare come destinazione una stampa o un rilascio con dati cronologici sulla posizione dall'utente o dal relativo controller:

• La posizione della testa nel momento in cui si è verificata una pressione del movimento o del controller, che può essere usata per la destinazione per determinare a cosa stava guardando l'utente:

  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;
           // ...
       }
  }
  

• La posizione di origine nel momento in cui si è verificata una pressione del controller di movimento, che può essere usata per la destinazione per determinare a quale utente puntava il controller. Questo sarà lo stato del controller che ha sperimentato la stampa. Se si esegue il rendering del controller stesso, è possibile richiedere la posizione del puntatore anziché la posizione del grip, per sparare il raggio di destinazione da ciò che l'utente considererà la punta naturale del controller di cui è stato eseguito il rendering:

  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;
               // ...
           }
       }
  }
  

Esempio di gestori eventi

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

Controller di movimento in MRTK

È possibile accedere al controller movimento e movimento da Gestione input.

Seguire le esercitazioni

Le esercitazioni dettagliate, con esempi di personalizzazione più dettagliati, sono disponibili in Realtà mista Academy:

• Input MR 211: movimento
• Input MR 213: controller movimento

Input MR 213 - Controller movimento

Successivo checkpoint di sviluppo

Se si sta seguendo il percorso di sviluppo di Unity, si sta esplorando i blocchi predefiniti principali di MRTK. Da qui, è possibile passare al blocco predefinito successivo:

In alternativa, passare alle API e alle funzionalità della piattaforma di realtà mista:

È sempre possibile tornare ai checkpoint per lo sviluppo con Unity in qualsiasi momento.

Vedi anche

• Puntamento con la testa e commit
• Controller del movimento