Controller di movimento in Unity

Esistono due modi principali per intervenire sullo sguardo fisso in Unity, i movimenti della mano e i controller di movimento in HoloLens e immersive HMD. È 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 Mixed Reality. Le API Input.GetButton/Input.GetAxis comuni funzionano in più SDK XR Unity, mentre l'API InteractionManager/GestureRecognizer specifica per Windows Mixed Reality espone il set completo di dati di input spaziali.

API di input XR unity

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

Altre informazioni sulle API XR sono disponibili qui.

Tabella di mapping dei pulsanti/assi di Unity

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

I mapping di ID pulsante/asse per Windows Mixed Reality in genere corrispondono agli ID pulsante/asse di Oculus.

I mapping di ID pulsante/asse per Windows Mixed Reality differiscono dai mapping di OpenVR in due modi:

Il mapping usa ID touchpad distinti dalla levetta per supportare controller con levette e touchpad.
Il mapping evita di sovraccaricare gli ID pulsante A e X per i pulsanti Menu per lasciarli disponibili per i pulsanti ABXY fisici.

Input	API Unity comuni (Input.GetButton/GetAxis)		API di input specifica di Windows MR (XR. WSA. Input)
Input	Mano sinistra	Mano destra	API di input specifica di Windows MR (XR. WSA. Input)
Selezionare il trigger premuto	Asse 9 = 1,0	Asse 10 = 1,0	selectPressed
Selezionare il valore analogico del trigger	Asse 9	Asse 10	selectPressedAmount
Selezionare il trigger parzialmente premuto	Pulsante 14 (game pad compat)	Pulsante 15 (game pad compat)	selectPressedAmount > 0.0
Pulsante di menu premuto	Pulsante 6*	Pulsante 7*	menuPressed
Pulsante grip premuto	Asse 11 = 1,0 (nessun valore analogico) Pulsante 4 (game pad compat)	Asse 12 = 1,0 (nessun valore analogico) Pulsante 5 (game pad compat)	Afferrato
Levetta X (sinistra: -1.0, destra: 1.0)	Asse 1	Asse 4	thumbstickPosition.x
Levetta Y (in alto: -1.0, inferiore: 1.0)	Asse 2	Asse 5	thumbstickPosition.y
Levetta premuta	Pulsante 8	Pulsante 9	levettaPressed
Touchpad X (a sinistra: -1.0, a destra: 1.0)	Asse 17*	Asse 19*	touchpadPosition.x
Touchpad Y (in alto: -1.0, inferiore: 1.0)	Asse 18*	Asse 20*	touchpadPosition.y
Touchpad toccato	Pulsante 18*	Pulsante 19*	touchpadTouched
Touchpad premuto	Pulsante 16*	Pulsante 17*	touchpadPressed
6 Posa o posizione del puntatore del grip 6DoF	Solo presa: XR. InputTracking.GetLocalPosition XR. InputTracking.GetLocalRotation		Passare grip o puntatore come argomento: sourceState.sourcePose.TryGetPosition sourceState.sourcePose.TryGetRotation
Stato di rilevamento	Accuratezza della posizione e rischio di perdita di origine disponibili solo tramite l'API specifica di MR		sourceState.sourcePose.positionAccuracy sourceState.properties.sourceLossRisk

Nota

Questi ID pulsante/asse differiscono dagli ID usati da Unity per OpenVR a causa di collisioni nei mapping usati dai game pad, Oculus Touch e OpenVR.

OpenXR

Per informazioni di base sulle interazioni con 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 InputFeatureUsagepiù generalizzabili, il modo in cui gli input XR disponibili possono essere identificati e categorizzati, 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:

InputFeatureUsage	Controller HP Reverb G2 (OpenXR)	HoloLens Hand (OpenXR)
primary2DAxis	Joystick
primary2DAxisClick	Joystick - Fare clic
Grilletto	Attivazione
Presa	Presa	Tocco o compressione dell'aria
primaryButton	[X/A] - Premere	Tocco ad aria
secondaryButton	[Y/B] - Premere
gripButton	Grip - Premere
triggerButton	Trigger - Premere
menuButton	Menu

Grip pose vs. pose di puntamento

Windows Mixed Reality supporta i controller di movimento in un'ampia gamma di fattori di forma. Il design di ogni controller differisce nella relazione tra la posizione della mano dell'utente e la direzione "in 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 di posizione del puntatore sono espresse da tutte le API Unity nelle coordinate globali di Unity.

Grip pose

La posizione del grip rappresenta la posizione del palmo degli utenti, rilevata da un HoloLens o che contiene un controller di movimento.

Nei visori vr immersivi, la posizione della presa viene usata al 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 quando si visualizza 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 è definita in modo specifico come segue:

La posizione di presa: il centroide palmo quando si tiene il controller naturalmente, regolato a sinistra o a destra per centrare la posizione all'interno della presa. Nel controller di movimento Windows Mixed Reality questa posizione è in genere allineata al pulsante Afferra.
Asse destro dell'orientamento della presa: quando apri completamente la mano per formare una posa piatta a 5 dita, il raggio normale per il palmo (in avanti dal palmo sinistro, indietro dal palmo destro)
Asse in avanti dell'orientamento della presa: quando si chiude parzialmente la mano (come se si tiene il controller), il raggio che punta "in avanti" attraverso il tubo formato dalle dita non pollice.
Asse su dell'orientamento del grip: l'asse su implicito nelle definizioni Destra e Avanti.

È possibile accedere alla posizione di grip tramite l'API di input tra fornitori (XR) di Unity. InputTracking. GetLocalPosition/Rotation) o tramite l'API specifica di Mr di Windows (sourceState.sourcePose.TryGetPosition/Rotation, che richiede 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 è meglio usare per il raycast quando si esegue il rendering del modello di controller stesso. Se si esegue il rendering di un altro oggetto virtuale al posto del controller, ad esempio una pistola virtuale, è consigliabile puntare a un raggio più naturale per l'oggetto virtuale, ad esempio un raggio che viaggia lungo la canna del modello di pistola definito dall'app. Poiché gli utenti possono visualizzare l'oggetto virtuale e non il controller fisico, il puntamento con l'oggetto virtuale sarà probabilmente più naturale per coloro che usano l'app.

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

OpenXR

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

Il grip pone per il rendering di oggetti nella mano
L'obiettivo è puntare al mondo.

Altre informazioni su questa progettazione e sulle differenze tra le due pose sono disponibili in OpenXR Specification - Input Subpaths (Specifica OpenXR - Percorsi secondari di input).

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

Le pose fornite da InputFeatureUsages PointerPosition, PointerRotation, PointerVelocity e PointerAngularVelocity rappresentano tutte la posizione dell'obiettivo OpenXR. Questi inputFeatureUsages non sono definiti in alcun file C# incluso, quindi dovrai definire il tuo InputFeatureUsages come indicato di seguito:

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

Aptici

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

Stato di rilevamento del controller

Come le cuffie, il controller di movimento Windows Mixed Reality non richiede alcuna configurazione di sensori di rilevamento esterni. I controller vengono invece monitorati dai sensori nell'auricolare stesso.

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

A questo punto, il sistema bloccherà il controller all'utente, monitorando la posizione dell'utente mentre si sposta, esponendo al tempo stesso l'orientamento reale 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 con accuratezza approssimativa senza che l'utente se ne accorta.

Ragionamento sullo stato di rilevamento esplicito

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

Stato di rilevamento	SourceLossRisk	PositionAccuracy	TryGetPosition
Accuratezza elevata	< 1.0	Alto	true
Accuratezza elevata (a rischio di perdita)	== 1.0	Alto	true
Accuratezza approssimativa	== 1.0	Approssimativo	true
Nessuna posizione	== 1.0	Approssimativo	False

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

Accuratezza elevata: Anche se il controller di movimento si trova all'interno del campo visivo dell'auricolare, in genere fornisce posizioni ad alta precisione, in base al rilevamento visivo. Un controller mobile che lascia momentaneamente il campo visivo o viene momentaneamente oscurato dai sensori delle cuffie (ad esempio dall'altra mano dell'utente) continuerà a restituire pose ad alta precisione per un breve periodo, in base al rilevamento inerziale del controller stesso.
Accuratezza elevata (a rischio di perdita): Quando l'utente sposta il controller di movimento oltre il bordo del campo visivo dell'auricolare, l'auricolare non sarà presto in grado di tenere traccia visivamente della posizione del controller. L'app sa quando il controller ha raggiunto questo limite FOV vedendo SourceLossRisk raggiungere 1.0. A quel 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 di accuratezza approssimativa. A questo punto, il sistema bloccherà il controller all'utente, monitorando la posizione dell'utente mentre si sposta, esponendo al tempo stesso l'orientamento reale del controller usando i sensori di orientamento interni. Molte app che usano controller per puntare e attivare gli elementi dell'interfaccia utente possono funzionare come di consueto, con accuratezza approssimativa senza che l'utente se ne accorta. 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: Anche se il controller può operare con precisione approssimativa per lungo tempo, a volte il sistema sa che anche una posizione bloccata dal corpo non è significativa al momento. Ad esempio, un controller 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 momenti, il sistema non fornirà alcuna posizione all'app e TryGetPosition restituirà false.

API Unity comuni (Input.GetButton/GetAxis)

Namespace:UnityEngine, UnityEngine.XR
Tipi: input, XR. InputTracking

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

Recupero dello stato premuto di un pulsante logico

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

Ad esempio, per eseguire il mapping del pulsante trigger del controller di 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 Pulsante positivo Alt per leggere il pulsante del joystick 14, come indicato di seguito:

InputManager di Unity
Unity InputManager

Lo script può quindi controllare l'azione Invia usando Input.GetButton:

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

È possibile aggiungere altri pulsanti logici modificando la proprietà Size in Axes (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"))
{
  // ...
}

Ottenere la posa di una mano o di un controller di 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);

Nota

Il codice precedente rappresenta la posizione di grip del controller (in cui l'utente contiene il controller), utile per il rendering di una spada o di una pistola nella mano dell'utente o di un modello del controller stesso.

La relazione tra questa posizione del grip e la posizione del puntatore (in cui punta la punta del controller) può differire tra i controller. In questo momento, l'accesso alla posizione del puntatore del controller è possibile solo tramite l'API di input specifica di MR, descritta nelle sezioni seguenti.

API specifiche di Windows (XR. WSA. Input)

Attenzione

Se il progetto usa una qualsiasi delle richieste XR. API WSA, queste vengono eliminate gradualmente a favore di XR SDK nelle versioni future di Unity. Per i nuovi progetti, è consigliabile usare XR SDK dall'inizio. Altre informazioni sul sistema di input XR e sulle API sono disponibili qui.

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

Per ottenere informazioni più dettagliate su Windows Mixed Reality input manuale (per HoloLens) e i controller di movimento, puoi 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 mani e controller.

Polling per lo stato delle mani e dei controller di movimento

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

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

Ogni InteractionSourceState ottenuto 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 dei controller del movimento, ad esempio le coordinate XY del touchpad e/o della levetta e lo stato di tocco
```
if (interactionSourceState.touchpadTouched && interactionSourceState.touchpadPosition.x > 0.5) {
     // ...
}
```

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

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

Polling per pose di rendering stimate in avanti

Quando si esegue il polling dei dati di origine dell'interazione da mani e controller, le pose che si ottengono vengono previste in avanti per il momento in cui i fotoni di questo fotogramma raggiungeranno gli occhi dell'utente. Le pose previste in avanti vengono usate al meglio per il rendering del controller o di un oggetto mantenuto ogni fotogramma. Se si intende usare un determinato comunicato stampa o rilascio con il controller, sarà più accurato se si usano le API evento cronologico 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 posa della testa stimata in avanti per questo fotogramma corrente. Come per la posa di origine, questa operazione è 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 evento cronologiche 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 di origine dell'interazione

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

Per gestire gli eventi di origine dell'interazione:

Eseguire la registrazione 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 effettuato la sottoscrizione a un evento di interazione, si otterrà il callback quando appropriato. Nell'esempio SourcePressed questa operazione verrà eseguita 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 distruggendo l'oggetto che ha sottoscritto l'evento. Per interrompere la gestione dell'evento, annullare la sottoscrizione all'evento.

InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;

Elenco di eventi di origine dell'interazione

Gli eventi di origine dell'interazione disponibili sono:

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

Eventi per le pose di targeting cronologico che corrispondono più accuratamente a una stampa o a un comunicato

Le API di polling descritte in precedenza offrono all'app pose previste in avanti. Anche se le pose previste sono ottimali per il rendering del controller o di un oggetto portatile virtuale, le pose future non sono ottimali per la destinazione, per due motivi principali:

Quando l'utente preme un pulsante su un controller, possono esserci circa 20 ms di latenza wireless sul Bluetooth prima che il sistema riceva la pressione.
Quindi, se si usa una posa stimata in avanti, ci sarebbero altri 10-20 ms di stima in avanti applicati per indirizzare il momento in cui i fotoni del fotogramma corrente raggiungeranno gli occhi dell'utente.

Ciò significa che il polling offre una posa di origine o una posa head di 30-40 ms in avanti da dove la testa e le mani dell'utente erano effettivamente tornati quando si è verificata la stampa o il rilascio. Per l'input della mano di HoloLens, anche se non c'è alcun ritardo di trasmissione wireless, c'è un ritardo di elaborazione simile per rilevare la pressione.

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

È possibile scegliere come destinazione una stampa o un comunicato con i dati cronologici della posa della testa dell'utente o del titolare del trattamento:

La posa della testa nel momento in cui si è verificato un movimento o una pressione del controller, che può essere usata per la destinazione per determinare ciò che l'utente stava guardando :

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 posa di origine nel momento in cui si è verificata una pressione del controller del movimento, che può essere usata per la destinazione per determinare a cosa 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 al raggio di destinazione da ciò che l'utente considererà la punta naturale del controller sottoposto a 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:

Mr Input 213 - Controller di movimento

Checkpoint di sviluppo successivo

Se si segue il percorso di sviluppo di Unity definito, si sta esplorando i blocchi predefiniti principali di MRTK. Da qui è possibile continuare con il blocco predefinito successivo:

Tracciamento della mano e degli occhi

In alternativa, passare a Realtà mista funzionalità e API della piattaforma:

Esperienze condivise

È sempre possibile tornare ai checkpoint di sviluppo di Unity in qualsiasi momento.

Vedere anche

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-12-17

Condividi tramite

Controller di movimento in Unity

API di input XR unity

Tabella di mapping dei pulsanti/assi di Unity

OpenXR

Grip pose vs. pose di puntamento

Grip pose

Posizione del puntatore

OpenXR

Aptici

Stato di rilevamento del controller

Ragionamento sullo stato di rilevamento esplicito

API Unity comuni (Input.GetButton/GetAxis)

Recupero dello stato premuto di un pulsante logico

Ottenere direttamente lo stato premuto di un pulsante fisico

Ottenere la posa di una mano o di un controller di movimento

API specifiche di Windows (XR. WSA. Input)

Polling per lo stato delle mani e dei controller di movimento

Polling per pose di rendering stimate in avanti

Gestione degli eventi di origine dell'interazione

Come interrompere la gestione di un evento

Elenco di eventi di origine dell'interazione

Eventi per le pose di targeting cronologico che corrispondono più accuratamente a una stampa o a un comunicato

Esempio di gestori eventi

Controller di movimento in MRTK

Seguire le esercitazioni

Checkpoint di sviluppo successivo

Vedere anche

Commenti e suggerimenti

Risorse aggiuntive