Controladores de movimento no Unity

Há duas maneiras principais de agir em seu foco no Unity, gestos com as mãos e controladores de movimento no HoloLens e HMD imersivo. Você acessa os dados de ambas as fontes de entrada espacial por meio das mesmas APIs no Unity.

O Unity fornece duas maneiras principais de acessar dados de entrada espaciais para Windows Mixed Reality. As APIs Input.GetButton/Input.GetAxis comuns funcionam em vários SDKs XR do Unity, enquanto a API InteractionManager/GestureRecognizer específica para Windows Mixed Reality expõe o conjunto completo de dados de entrada espaciais.

APIs de entrada XR do Unity

Para novos projetos, recomendamos usar as novas APIs de entrada XR desde o início.

Você pode encontrar mais informações sobre as APIs XR aqui.

Tabela de mapeamento de botão/eixo do Unity

O Gerenciador de Entradas do Unity para controladores de movimento Windows Mixed Reality dá suporte às IDs de botão e eixo listadas abaixo por meio das APIs Input.GetButton/GetAxis. A coluna "Específica de MR do Windows" refere-se às propriedades disponíveis fora do tipo InteractionSourceState . Cada uma dessas APIs é descrita em detalhes nas seções abaixo.

Os mapeamentos de ID de botão/eixo para Windows Mixed Reality geralmente correspondem às IDs de botão/eixo do Oculus.

Os mapeamentos de ID de botão/eixo para Windows Mixed Reality diferem dos mapeamentos do OpenVR de duas maneiras:

1. O mapeamento usa IDs de touchpad que são distintas do thumbstick, para dar suporte a controladores com thumbsticks e touchpads.
2. O mapeamento evita sobrecarregar as IDs de botão A e X para os botões menu para deixá-las disponíveis para os botões ABXY físicos.

Entrada	APIs comuns do Unity (Input.GetButton/GetAxis)		API de Entrada específica do Mr do Windows (XR. WSA. Entrada)
	Mão esquerda	Mão direita
Selecionar gatilho pressionado	Eixo 9 = 1,0	Eixo 10 = 1,0	selectPressed
Selecionar o valor analógico do gatilho	Eixo 9	Eixo 10	selectPressedAmount
Selecionar gatilho parcialmente pressionado	Botão 14 (compatibilidade de gamepad)	Botão 15 (compatibilidade de gamepad)	selectPressedAmount > 0.0
Botão de menu pressionado	Botão 6*	Botão 7*	menuPressed
Botão De aderência pressionado	Eixo 11 = 1,0 (sem valores analógicos) Botão 4 (compatibilidade de gamepad)	Eixo 12 = 1,0 (sem valores analógicos) Botão 5 (compatibilidade de gamepad)	Agarrou
Thumbstick X (esquerda: -1.0, direita: 1.0)	Eixo 1	Eixo 4	thumbstickPosition.x
Thumbstick Y (superior: -1.0, inferior: 1.0)	Eixo 2	Eixo 5	thumbstickPosition.y
Polegar pressionado	Botão 8	Botão 9	thumbstickPressed
Touchpad X (esquerda: -1.0, direita: 1.0)	Eixo 17*	Eixo 19*	touchpadPosition.x
Touchpad Y (superior: -1.0, inferior: 1.0)	Eixo 18*	Eixo 20*	touchpadPosition.y
Touchpad tocado	Botão 18*	Botão 19*	touchpadTouched
Touchpad pressionado	Botão 16*	Botão 17*	touchpadPressed
Pose de alça 6DoF ou pose de ponteiro	Somente pose de aderência : XR. InputTracking.GetLocalPosition XR. InputTracking.GetLocalRotation		Passe Grip ou Pointer como um argumento: sourceState.sourcePose.TryGetPosition sourceState.sourcePose.TryGetRotation
Estado de acompanhamento	Precisão da posição e risco de perda de origem disponíveis somente por meio da API específica do MR		sourceState.sourcePose.positionAccuracy sourceState.properties.sourceLossRisk

Observação

Essas IDs de botão/eixo diferem das IDs que o Unity usa para OpenVR devido a colisões nos mapeamentos usados por gamepads, Oculus Touch e OpenVR.

OpenXR

Para saber mais sobre as interações de realidade misturada no Unity, visite o Manual do Unity para Entrada XR do Unity. Esta documentação do Unity aborda os mapeamentos de entradas específicas do controlador para InputFeatureUsages mais generalizáveis, como as entradas XR disponíveis podem ser identificadas e categorizadas, como ler dados dessas entradas e muito mais.

O plug-in Realidade Misturada OpenXR fornece perfis de interação de entrada adicionais, mapeados para InputFeatureUsages padrão, conforme detalhado abaixo:

InputFeatureUsage	Controlador HP Reverb G2 (OpenXR)	Mão do HoloLens (OpenXR)
primary2DAxis	Joystick
primary2DAxisClick	Joystick – Clique em
gatilho	Gatilho
Aperto	Aperto	Toque de ar ou aperto
primaryButton	[X/A] - Pressione	Fechar e abrir dedos indicador e polegar
secondaryButton	[Y/B] - Pressione
gripButton	Alça - Pressione
triggerButton	Gatilho – Pressionar
menuButton	Menu

Pose de aderência vs. pose apontando

Windows Mixed Reality dá suporte a controladores de movimento em uma variedade de fatores forma. O design de cada controlador difere em sua relação entre a posição da mão do usuário e a direção "forward" natural que os aplicativos devem usar para apontar ao renderizar o controlador.

Para representar melhor esses controladores, há dois tipos de poses que você pode investigar para cada fonte de interação, a pose de aderência e a pose do ponteiro. As coordenadas de pose de alça e pose de ponteiro são expressas por todas as APIs do Unity nas coordenadas globais do mundo do Unity.

Pose de aderência

A pose de aderência representa a localização da palma da mão dos usuários, detectada por um HoloLens ou mantendo um controlador de movimento.

Em headsets imersivos, a pose de aderência é melhor usada para renderizar a mão do usuário ou um objeto mantido na mão do usuário. A pose de aderência também é usada ao visualizar um controlador de movimento. O modelo renderizável fornecido pelo Windows para um controlador de movimento usa a pose de aderência como sua origem e centro de rotação.

A pose de aderência é definida especificamente da seguinte maneira:

• A posição da aderência: o centroide da palma da mão ao segurar o controlador naturalmente, ajustado para a esquerda ou direita para centralizar a posição dentro da alça. No controlador de movimento Windows Mixed Reality, essa posição geralmente se alinha com o botão Agarrar.
• Eixo direito da orientação de aderência: quando você abre completamente a mão para formar uma pose plana de 5 dedos, o raio que é normal para a palma da mão (para a frente da palma da esquerda, para trás da palma da direita)
• Eixo de avanço da orientação de aderência: quando você fecha a mão parcialmente (como se estivesse segurando o controlador), o raio que aponta "para a frente" através do tubo formado por seus dedos não polegares.
• O eixo Para Cima da orientação de aderência: o eixo Para cima implícito pelas definições Right e Forward.

Você pode acessar a pose de aderência por meio da XR (API de entrada entre fornecedores) do Unity. InputTracking. GetLocalPosition/Rotation) ou por meio da API específica de MR do Windows (sourceState.sourcePose.TryGetPosition/Rotation, solicitando dados de pose para o nó Grip ).

Pose de ponteiro

A pose do ponteiro representa a ponta do controlador apontando para frente.

A pose de ponteiro fornecida pelo sistema é melhor usada para raycast quando você está renderizando o próprio modelo do controlador. Se você estiver renderizando algum outro objeto virtual no lugar do controlador, como uma arma virtual, deverá apontar com um raio mais natural para esse objeto virtual, como um raio que viaja ao longo do barril do modelo de arma definido pelo aplicativo. Como os usuários podem ver o objeto virtual e não o controlador físico, apontar com o objeto virtual provavelmente será mais natural para aqueles que usam seu aplicativo.

Atualmente, a pose do ponteiro está disponível no Unity somente por meio da API específica do MR do Windows, sourceState.sourcePose.TryGetPosition/Rotation, passando InteractionSourceNode.Pointer como o argumento.

OpenXR

Você tem acesso a dois conjuntos de poses por meio de interações de entrada do OpenXR:

• A alça representa para renderizar objetos na mão
• O objetivo é apontar para o mundo.

Mais informações sobre esse design e as diferenças entre as duas poses podem ser encontradas na Especificação OpenXR – Subcaminhos de Entrada.

As poses fornecidas por InputFeatureUsages DevicePosition, DeviceRotation, DeviceVelocity e DeviceAngularVelocity representam a pose de aderência OpenXR. InputFeatureUsages relacionados a poses de aderência são definidos em CommonUsages do Unity.

As poses fornecidas por InputFeatureUsages PointerPosition, PointerRotation, PointerVelocity e PointerAngularVelocity representam a pose de objetivo openXR. Esses InputFeatureUsages não são definidos em nenhum arquivo C# incluído, portanto, você precisará definir seu próprio InputFeatureUsages da seguinte maneira:

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

Hápticos

Para obter informações sobre como usar hápticos no sistema de entrada XR do Unity, a documentação pode ser encontrada no Manual do Unity para Entrada XR do Unity – Haptics.

Estado de acompanhamento do controlador

Assim como os fones de ouvido, o controlador de movimento Windows Mixed Reality não requer nenhuma configuração de sensores de rastreamento externos. Em vez disso, os controladores são rastreados por sensores no próprio fone de ouvido.

Se o usuário mover os controladores para fora do campo de exibição do headset, o Windows continuará a inferir as posições do controlador na maioria dos casos. Quando o controlador tiver perdido o rastreamento visual por tempo suficiente, as posições do controlador cairão para posições de precisão aproximada.

Neste ponto, o sistema bloqueará o controlador para o usuário, acompanhando a posição do usuário à medida que ele se move, enquanto ainda expõe a verdadeira orientação do controlador usando seus sensores de orientação interna. Muitos aplicativos que usam controladores para apontar e ativar elementos da interface do usuário podem operar normalmente com precisão aproximada sem que o usuário perceba.

Raciocínio sobre o estado de acompanhamento explicitamente

Os aplicativos que desejam tratar posições de forma diferente com base no estado de acompanhamento podem ir além e inspecionar propriedades no estado do controlador, como SourceLossRisk e PositionAccuracy:

Estado de acompanhamento	SourceLossRisk	PositionAccuracy	TryGetPosition
Alta precisão	< 1.0	Alto	true
Alta precisão (em risco de perda)	== 1,0	Alto	true
Precisão aproximada	== 1,0	Aproximado	true
Nenhuma posição	== 1,0	Aproximado	false

Esses estados de acompanhamento do controlador de movimento são definidos da seguinte maneira:

• Alta precisão: Embora o controlador de movimento esteja dentro do campo de exibição do headset, ele geralmente fornecerá posições de alta precisão, com base no acompanhamento visual. Um controlador móvel que momentaneamente deixa o campo de exibição ou é momentaneamente obscurecido dos sensores do fone de ouvido (por exemplo, por outra mão do usuário) continuará a retornar poses de alta precisão por um curto período de tempo, com base no acompanhamento inercial do próprio controlador.
• Alta precisão (correndo o risco de perder): Quando o usuário move o controlador de movimento para além da borda do campo de exibição do fone de ouvido, o headset em breve não poderá acompanhar visualmente a posição do controlador. O aplicativo sabe quando o controlador atingiu esse limite FOV vendo o SourceLossRisk chegar a 1,0. Nesse ponto, o aplicativo pode optar por pausar gestos do controlador que exigem um fluxo constante de poses de alta qualidade.
• Precisão aproximada: Quando o controlador tiver perdido o rastreamento visual por tempo suficiente, as posições do controlador cairão para posições de precisão aproximada. Neste ponto, o sistema bloqueará o controlador para o usuário, acompanhando a posição do usuário à medida que ele se move, enquanto ainda expõe a verdadeira orientação do controlador usando seus sensores de orientação interna. Muitos aplicativos que usam controladores para apontar e ativar elementos da interface do usuário podem operar normalmente enquanto estão em precisão aproximada sem que o usuário perceba. Aplicativos com requisitos de entrada mais pesados podem optar por detectar essa queda de Alta precisão para Precisão aproximada inspecionando a propriedade PositionAccuracy , por exemplo, para dar ao usuário uma caixa de ocorrência mais generosa em destinos fora da tela durante esse tempo.
• Sem posição: Embora o controlador possa operar com precisão aproximada por um longo tempo, às vezes o sistema sabe que até mesmo uma posição bloqueada pelo corpo não é significativa no momento. Por exemplo, um controlador que foi ativado pode nunca ter sido observado visualmente ou um usuário pode colocar um controlador que, em seguida, é captado por outra pessoa. Nesses momentos, o sistema não fornecerá nenhuma posição para o aplicativo e TryGetPosition retornará false.

APIs comuns do Unity (Input.GetButton/GetAxis)

Namespace:UnityEngine, UnityEngine.XR
Tipos: Entrada, XR. InputTracking

Atualmente, o Unity usa suas APIs gerais Input.GetButton/Input.GetAxis para expor a entrada para o SDK do Oculus, o SDK do OpenVR e Windows Mixed Reality, incluindo controladores de mãos e movimentos. Se seu aplicativo usa essas APIs para entrada, ele pode facilmente dar suporte a controladores de movimento em vários SDKs XR, incluindo Windows Mixed Reality.

Obter o estado pressionado de um botão lógico

Para usar as APIs de entrada gerais do Unity, você normalmente começará conectando botões e eixos a nomes lógicos no Gerenciador de Entrada do Unity, associando um botão ou IDs de eixo a cada nome. Em seguida, você pode escrever um código que se refere a esse nome de botão/eixo lógico.

Por exemplo, para mapear o botão de gatilho do controlador de movimento esquerdo para a ação Enviar, vá para Editar > Entrada de Configurações > do Projeto no Unity e expanda as propriedades da seção Enviar em Eixos. Altere a propriedade Botão Positivo ou Botão Alt Positivo para ler o botão de joystick 14, desta forma:

Unity InputManager

Em seguida, o script pode marcar para a ação Enviar usando Input.GetButton:

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

Você pode adicionar botões mais lógicos alterando a propriedade Size em Eixos.

Obter o estado pressionado de um botão físico diretamente

Você também pode acessar botões manualmente pelo nome totalmente qualificado usando Input.GetKey:

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

Obtendo uma pose de mão ou controlador de movimento

Você pode acessar a posição e a rotação do controlador usando XR. InputTracking:

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

Observação

O código acima representa a pose de aderência do controlador (em que o usuário mantém o controlador), que é útil para renderizar uma espada ou uma arma na mão do usuário ou um modelo do próprio controlador.

A relação entre essa pose de aderência e a pose do ponteiro (em que a ponta do controlador está apontando) pode ser diferente entre os controladores. Neste momento, o acesso à pose do ponteiro do controlador só é possível por meio da API de entrada específica do MR, descrita nas seções abaixo.

APIs específicas do Windows (XR). WSA. Entrada)

Cuidado

Se o projeto estiver usando qualquer um dos XR. APIs do WSA, elas estão sendo eliminadas em favor do SDK do XR em versões futuras do Unity. Para novos projetos, recomendamos usar o SDK do XR desde o início. Você pode encontrar mais informações sobre o sistema de entrada XR e APIs aqui.

Namespace:UnityEngine.XR.WSA.Input
Tipos: InteractionManager, InteractionSourceState, InteractionSource, InteractionSourceProperties, InteractionSourceKind, InteractionSourceLocation

Para obter informações mais detalhadas sobre Windows Mixed Reality entrada manual (para HoloLens) e controladores de movimento, você pode optar por usar as APIs de entrada espacial específicas do Windows no namespace UnityEngine.XR.WSA.Input. Isso permite que você acesse informações adicionais, como precisão de posição ou o tipo de origem, permitindo diferenciar mãos e controladores.

Sondagem para o estado dos controladores de mãos e movimentos

Você pode sondar o estado desse quadro para cada origem de interação (controle de movimento ou mão) usando o método GetCurrentReading .

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

Cada InteractionSourceState que você recebe representa uma fonte de interação no momento atual. O InteractionSourceState expõe informações como:

• Quais tipos de pressionamentos estão ocorrendo (Select/Menu/Grasp/Touchpad/Thumbstick)

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

• Outros dados específicos para controladores de movimento, como as coordenadas XY do touchpad e/ou do thumbstick e o estado tocado

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

• O InteractionSourceKind para saber se a origem é uma mão ou um controlador de movimento

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

Sondagem para poses de renderização previstas para frente

• Ao sondar dados de origem de interação de mãos e controladores, as poses que você obtém são poses previstas para o momento em que os fótons desse quadro atingirão os olhos do usuário. As poses previstas para frente são mais bem usadas para renderizar o controlador ou um objeto mantido em cada quadro. Se você estiver direcionando uma determinada imprensa ou versão com o controlador, isso será mais preciso se você usar as APIs de evento histórico descritas abaixo.

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

• Você também pode obter a pose de cabeça prevista para este quadro atual. Assim como acontece com a pose de origem, isso é útil para renderizar um cursor, embora direcionar uma determinada imprensa ou versão seja mais preciso se você usar as APIs de evento histórico descritas abaixo.

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

Manipulando eventos de origem de interação

Para lidar com eventos de entrada conforme eles acontecem com seus dados de pose históricos precisos, você pode lidar com eventos de origem de interação em vez de sondagem.

Para lidar com eventos de origem de interação:

• Registre-se para um evento de entrada InteractionManager . Para cada tipo de evento de interação em que você está interessado, você precisa assinar.

  InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
  

• Manipule o evento. Depois de assinar um evento de interação, você receberá o retorno de chamada quando apropriado. No exemplo SourcePressed , isso ocorrerá depois que a origem for detectada e antes de ser liberada ou perdida.

  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
  }
  

Como parar de manipular um evento

Você precisa parar de manipular um evento quando não estiver mais interessado no evento ou está destruindo o objeto que assinou o evento. Para parar de manipular o evento, cancele a assinatura do evento.

InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;

Lista de eventos de origem de interação

Os eventos de origem de interação disponíveis são:

• InteractionSourceDetected (a origem se torna ativa)
• InteractionSourceLost (torna-se inativo)
• InteractionSourcePressed (toque, pressionamento de botão ou "Selecionar" enunciado)
• InteractionSourceReleased (fim de um toque, botão liberado ou fim de "Selecionar" enunciado)
• InteractionSourceUpdated (move ou altera algum estado)

Eventos de direcionamento históricos que correspondem com mais precisão a uma imprensa ou comunicado

As APIs de sondagem descritas anteriormente fornecem poses previstas para o seu aplicativo. Embora essas poses previstas sejam melhores para renderizar o controlador ou um objeto portátil virtual, as poses futuras não são ideais para direcionamento, por dois motivos principais:

• Quando o usuário pressiona um botão em um controlador, pode haver cerca de 20 ms de latência sem fio por Bluetooth antes que o sistema receba a pressão.
• Em seguida, se você estiver usando uma pose prevista para frente, haverá outra previsão de avanço de 10 a 20 ms aplicada para direcionar o tempo em que os fótons do quadro atual atingirão os olhos do usuário.

Isso significa que a sondagem oferece uma pose de origem ou pose de cabeça que é 30-40 ms para a frente de onde a cabeça e as mãos do usuário realmente estavam de volta quando a imprensa ou o comunicado aconteceu. Para a entrada manual do HoloLens, embora não haja nenhum atraso de transmissão sem fio, há um atraso de processamento semelhante para detectar a imprensa.

Para direcionar com precisão com base na intenção original do usuário para uma pressão de mão ou controlador, você deve usar a pose de origem histórica ou a pose de cabeça desse evento de entrada InteractionSourcePressed ou InteractionSourceReleased .

Você pode direcionar uma imprensa ou uma versão com dados de pose históricos da cabeça do usuário ou do controlador:

• A pose da cabeça no momento em que ocorreu um gesto ou pressionamento do controlador, que pode ser usado para direcionamento para determinar o que o usuário estava olhando :

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

• A pose de origem no momento em que ocorreu uma pressão do controlador de movimento, que pode ser usada para direcionamento para determinar para que o usuário estava apontando o controlador. Esse será o estado do controlador que experimentou a imprensa. Se você estiver renderizando o próprio controlador, poderá solicitar a pose do ponteiro em vez da pose de aderência, para disparar o raio de direcionamento do que o usuário considerará a dica natural desse controlador renderizado:

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

Exemplo de manipuladores 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 movimento no MRTK

Você pode acessar o gesto e o controlador de movimento do Gerenciador de entrada.

Acompanhe com tutoriais

Tutoriais passo a passo, com exemplos de personalização mais detalhados, estão disponíveis no Realidade Misturada Academy:

• Entrada do MR 211: gesto
• Entrada do MR 213: controladores de movimentos

Entrada do MR 213 – Controlador de movimento

Próximo ponto de verificação de desenvolvimento

Se você estiver seguindo o percurso de desenvolvimento do Unity que apresentamos, você está no meio da exploração dos principais blocos de construção do MRTK. Deste ponto, você pode prosseguir para o próximo bloco de construção:

Acompanhamento de mãos e olhos

Ou vá diretamente para as funcionalidades e APIs da plataforma de Realidade Misturada:

Experiências compartilhadas

Você sempre pode voltar para os pontos de verificação de desenvolvimento do Unity a qualquer momento.

Veja também

• Focar com a cabeça e confirmar
• Controladores de movimentos