Controladores de movimento no Unity

Existem duas formas fundamentais de tomar medidas no seu olhar no Unity, gestos de mão e controladores de movimento no HoloLens e HMD Envolvente. Pode aceder aos dados de ambas as origens de entrada espacial através das mesmas APIs no Unity.

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

APIs de entrada do Unity XR

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

Pode encontrar mais informações sobre as APIs XR aqui.

Tabela de mapeamento de botões/eixos do Unity

O Input Manager do Unity para controladores de movimento Windows Mixed Reality suporta os IDs de botão e eixo listados abaixo através das APIs Input.GetButton/GetAxis. A coluna "Windows MR-specific" refere-se às propriedades disponíveis fora do tipo InteractionSourceState . Cada uma destas APIs é descrita em detalhe nas secções abaixo.

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

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

1. O mapeamento utiliza IDs do touchpad que são distintos do thumbstick, para suportar controladores com thumbsticks e touchpads.
2. O mapeamento evita sobrecarregar os IDs dos botões A e X dos botões Menu para os deixar disponíveis para os botões físicos ABXY.

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 acionador premido	Eixo 9 = 1.0	Eixo 10 = 1.0	selectPressed
Selecionar valor analógico do acionador	Eixo 9	Eixo 10	selectPressedAmount
Selecionar acionador parcialmente premido	Botão 14 (compat do gamepad)	Botão 15 (gamepad compat)	selectPressedAmount > 0.0
Botão menu premido	Botão 6*	Botão 7*	menu Comprimido
Botão de aperto premido	Eixo 11 = 1,0 (sem valores analógicos) Botão 4 (compat de gamepad)	Eixo 12 = 1,0 (sem valores analógicos) Botão 5 (compat 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
Thumbstick premido	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 premido	Botão 16*	Botão 17*	touchpadPressed
Pose de aperto 6DoF ou pose de ponteiro	Pose de aperto apenas: XR. InputTracking.GetLocalPosition XR. InputTracking.GetLocalRotation		Pass Grip ou Pointer como um argumento: sourceState.sourcePose.TryGetPosition sourceState.sourcePose.TryGetRotation
Estado de controlo	A precisão da posição e o risco de perda de origem só estão disponíveis através da API específica do MR		sourceState.sourcePose.positionAccuracy sourceState.properties.sourceLossRisk

Nota

Estes IDs de botão/eixo diferem dos IDs que o Unity utiliza para o OpenVR devido a colisões nos mapeamentos utilizados pelos gamepads, Oculus Touch e OpenVR.

OpenXR

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

O Mixed Reality Plug-in OpenXR fornece perfis de interação de entrada adicionais, mapeados para InputFeatureUsagepadrão, conforme detalhado abaixo:

InputFeatureUsage	Controlador HP Reverb G2 (OpenXR)	Mão hololens (OpenXR)
primary2DAxis	Joystick
primary2DAxisClick	Joystick - Clique
acionador	Acionador
aderência	Aderência	Toque ou aperto de ar
botão principal	[X/A] - Premir	Toque no ar
secondaryButton	[Y/B] - Premir
gripButton	Aderência - Premir
triggerButton	Acionador - premir
menuButton	Menu

Pose de aderência vs. pose apontando

Windows Mixed Reality suporta comandos de movimento numa variedade de fatores de forma. A estrutura de cada controlador difere na sua relação entre a posição da mão do utilizador e a direção natural "para a frente" que as aplicações devem utilizar para apontar ao compor o controlador.

Para representar melhor estes controladores, existem dois tipos de poses que pode investigar para cada origem de interação, a pose de aderência e a pose do ponteiro. Tanto as coordenadas de pose de aderência como de ponteiro são expressas por todas as APIs do Unity nas coordenadas globais do mundo do Unity.

Pose de aderência

A postura de aderência representa a localização da palma da mão dos utilizadores, detetada por um HoloLens ou com um comando de movimento.

Nos auscultadores envolventes, a pose de aderência é melhor utilizada para compor a mão do utilizador ou um objeto na mão do utilizador. A pose de aderência também é utilizada ao visualizar um controlador de movimento. O modelo renderizável fornecido pelo Windows para um controlador de movimento utiliza a pose de aderência como a sua origem e centro de rotação.

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

• Posição de aderência: o centroide da palma da mão ao segurar o controlador naturalmente, ajustado à esquerda ou à direita para centrar a posição dentro da aderência. No comando de movimento Windows Mixed Reality, esta posição alinha-se geralmente com o botão Agarrar.
• Eixo direito da orientação da aderência: quando abre completamente a mão para formar uma pose plana de 5 dedos, o raio que é normal na palma da mão (para a frente a partir da palma da mão esquerda, para trás a partir da palma da mão direita)
• O eixo Reencaminhamento da orientação da aderência: quando fecha parcialmente a mão (como se estivesse a segurar o controlador), o raio que aponta "para a frente" através do tubo formado pelos seus dedos que não sejam polegares.
• A orientação da aderência é Eixo superior: o eixo Cima implícito pelas definições Direita e Reencaminhamento.

Pode aceder à postura de aderência através da API de entrada (XR) entre fornecedores do Unity. InputTracking. GetLocalPosition/Rotation) ou através da API específica do MR do Windows (sourceState.sourcePose.TryGetPosition/Rotation, solicitando dados de pose para o nó grip ).

Pose de ponteiro

A posição do ponteiro representa a ponta do controlador que aponta para a frente.

A pose de ponteiro fornecida pelo sistema é melhor utilizada para raycast quando estiver a compor o próprio modelo de controlador. Se estiver a compor outro objeto virtual em vez do controlador, como uma arma virtual, deve apontar com um raio mais natural para esse objeto virtual, como um raio que viaja ao longo do cano do modelo de arma definido pela aplicação. Uma vez que os utilizadores podem ver o objeto virtual e não o controlador físico, apontar com o objeto virtual será provavelmente mais natural para aqueles que utilizam a sua aplicação.

Atualmente, a pose do ponteiro está disponível no Unity apenas através da API específica do MR do Windows, sourceState.sourcePose.TryGetPosition/Rotation, transmitindo InteractionSourceNode.Pointer como argumento.

OpenXR

Tem acesso a dois conjuntos de poses através de interações de entrada OpenXR:

• A aderência posa para compor objetos na mão
• O objectivo representa apontar para o mundo.

Pode encontrar mais informações sobre este design e as diferenças entre as duas poses na Especificação OpenXR – Subpaths de Entrada.

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

As poses fornecidas pela InputFeatureUsages PointerPosition, PointerRotation, PointerVelocity e PointerAngularVelocity representam a pose de objetivo OpenXR. Estas InputFeatureUsages não estão definidas em nenhum ficheiro C# incluído, pelo que terá de definir as suas próprias InputFeatureUsages da seguinte forma:

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

Hápticos

Para obter informações sobre a utilização de hápticas no sistema de Entrada XR do Unity, a documentação pode ser encontrada no Manual do Unity para Entrada XR do Unity – Háptica.

Estado de controlo do controlador

Tal como os auscultadores, o comando de movimento Windows Mixed Reality não necessita de configuração de sensores de controlo externos. Em vez disso, os controladores são controlados por sensores nos próprios auscultadores.

Se o utilizador mover os controladores para fora do campo de vista do headset, o Windows continua a inferir posições de controlador na maioria dos casos. Quando o controlador perder o controlo visual durante tempo suficiente, as posições do controlador serão baixadas para posições de precisão aproximada.

Neste momento, o sistema irá bloquear o corpo do controlador para o utilizador, seguindo a posição do utilizador à medida que se deslocam, ao mesmo tempo que expõe a verdadeira orientação do controlador com os sensores de orientação internos. Muitas aplicações que utilizam controladores para apontar e ativar elementos de IU podem funcionar normalmente com precisão aproximada sem que o utilizador se aperpere.

Raciocínio sobre o estado de controlo explicitamente

As aplicações que pretendem tratar posições de forma diferente com base no estado de controlo podem ir mais longe e inspecionar as propriedades no estado do controlador, como SourceLossRisk e PositionAccuracy:

Estado de controlo	SourceLossRisk	PositionAccuracy	TryGetPosition
Precisão elevada	< 1.0	Alto	true
Elevada precisão (em risco de perda)	== 1,0	Alto	true
Precisão aproximada	== 1,0	Aproximado	true
Sem posição	== 1,0	Aproximado	false

Estes estados de controlo do controlador de movimento são definidos da seguinte forma:

• Precisão elevada: Embora o controlador de movimento esteja no campo de vista do headset, geralmente fornecerá posições de alta precisão, com base no controlo visual. Um controlador móvel que sai momentaneamente do campo de vista ou está momentaneamente obscurecido dos sensores dos auscultadores (por exemplo, por outra mão do utilizador) continuará a devolver poses de alta precisão durante um curto período de tempo, com base no controlo inercial do próprio controlador.
• Elevada precisão (em risco de perda): Quando o utilizador move o controlador de movimento para além da extremidade do campo de vista do headset, o headset não conseguirá controlar visualmente a posição do controlador. A aplicação sabe quando o controlador atingiu este limite FOV ao ver o SourceLossRisk chegar à 1.0. Nessa altura, a aplicação pode optar por colocar em pausa os gestos do controlador que requerem um fluxo constante de poses de alta qualidade.
• Precisão aproximada: Quando o controlador perder o controlo visual durante tempo suficiente, as posições do controlador serão baixadas para posições de precisão aproximada. Neste momento, o sistema irá bloquear o corpo do controlador para o utilizador, seguindo a posição do utilizador à medida que se deslocam, ao mesmo tempo que expõe a verdadeira orientação do controlador com os sensores de orientação internos. Muitas aplicações que utilizam controladores para apontar e ativar elementos de IU podem funcionar normalmente enquanto estão em precisão aproximada sem que o utilizador se aperpere. As aplicações com requisitos de entrada mais pesados podem optar por detetar esta queda de Alta precisão para Precisão aproximada ao inspecionar a propriedade PositionAccuracy , por exemplo, para dar ao utilizador uma caixa de acesso mais generosa em destinos fora do ecrã durante este período.
• Sem posição: Embora o controlador possa operar com precisão aproximada durante muito tempo, por vezes o sistema sabe que mesmo uma posição bloqueada pelo corpo não é significativa neste momento. Por exemplo, um controlador que foi ativado pode nunca ter sido observado visualmente ou um utilizador pode colocar um controlador que é depois recolhido por outra pessoa. Nessas alturas, o sistema não fornecerá qualquer posição à aplicação e TryGetPosition devolverá false.

APIs comuns do Unity (Input.GetButton/GetAxis)

Espaço de nomes:UnityEngine, UnityEngine.XR
Tipos: Entrada, XR. InputTracking

Atualmente, o Unity utiliza as apIs Input.GetButton/Input.GetAxis gerais para expor entradas para o SDK Oculus, o SDK OpenVR e Windows Mixed Reality, incluindo comandos de mãos e movimentos. Se a sua aplicação utilizar estas APIs para entrada, pode suportar facilmente controladores de movimento em vários SDKs XR, incluindo Windows Mixed Reality.

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

Para utilizar as APIs de entrada gerais do Unity, normalmente, começa por ligar botões e eixos a nomes lógicos no Gestor de Entradas do Unity, vinculando um botão ou IDs de eixo a cada nome. Em seguida, pode escrever código que se refira a esse nome de eixo/botão lógico.

Por exemplo, para mapear o botão de acionador do comando de movimento esquerdo para a ação Submeter, aceda a Editar > Entrada de Definições > do Projeto no Unity e expanda as propriedades da secção Submeter em Eixos. Altere a propriedade Botão Positivo ou Botão Positivo Alternativo para ler o botão joystick 14, da seguinte forma:

Unity InputManager

Em seguida, o script pode verificar a ação Submeter com Input.GetButton:

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

Pode adicionar mais botões lógicos ao alterar a propriedade Tamanho em Eixos.

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

Também pode aceder manualmente aos botões com o respetivo nome completamente qualificado, utilizando Input.GetKey:

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

Obter uma pose de mão ou controlador de movimento

Pode aceder à posição e rotação do controlador com XR. InputTracking:

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

Nota

O código acima representa a pose de aperto do controlador (onde o utilizador segura o controlador), o que é útil para compor uma espada ou arma na mão do utilizador, ou um modelo do próprio controlador.

A relação entre esta pose de aperto e a pose do ponteiro (onde a ponta do controlador está a apontar) pode ser diferente entre os controladores. Neste momento, o acesso à pose do ponteiro do controlador só é possível através da API de entrada específica do MR, descrita nas secções abaixo.

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

Atenção

Se o seu projeto estiver a utilizar algum dos XRs. APIs WSA, estas estão a ser eliminadas gradualmente a favor do SDK XR em futuras versões do Unity. Para novos projetos, recomendamos que utilize o SDK XR desde o início. Pode encontrar mais informações sobre o sistema de Entrada XR e as APIs aqui.

Espaço de Nomes: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, pode optar por utilizar as APIs de entrada espacial específicas do Windows no espaço de nomes UnityEngine.XR.WSA.Input. Isto permite-lhe aceder a informações adicionais, como a precisão da posição ou o tipo de origem, permitindo-lhe distinguir as mãos e os controladores.

Consultar o estado das mãos e dos controladores de movimento

Pode consultar o estado deste fotograma para cada origem de interação (controlador de movimento ou mão) com o método GetCurrentReading .

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

Cada InteractionSourceState que obtém representa uma origem de interação no momento atual no tempo. O InteractionSourceState expõe informações como:

• Que tipos de pressões estão a ocorrer (Select/Menu/Grasp/Touchpad/Thumbstick)

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

• Outros dados específicos dos controladores de movimento, tais como as coordenadas XY do touchpad e/ou thumbstick e o estado tátil

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

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

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

Sondagens para poses de composição previstas para o futuro

• Quando consulta dados de origem de interação de mãos e controladores, as poses que obtém são poses previstas para o futuro no momento em que os fotões deste fotograma chegarão aos olhos do utilizador. As poses previstas para a frente são mais utilizadas para compor o controlador ou um objeto mantido em cada moldura. Se estiver a direcionar uma determinada imprensa ou versão com o controlador, isso será mais preciso se utilizar as APIs de eventos históricos descritas abaixo.

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

• Também pode obter a pose de cabeça prevista para esta moldura atual. Tal como acontece com a pose de origem, isto é útil para compor um cursor, embora a segmentação de uma determinada imprensa ou versão seja mais precisa se utilizar as APIs de eventos históricos 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;
       // ...
  }
  

Processar eventos de origem de interação

Para lidar com os eventos de entrada à medida que acontecem com os respetivos dados de pose histórica precisos, pode lidar com eventos de origem de interação em vez de consultar.

Para processar eventos de origem de interação:

• Registe-se num evento de entrada InteractionManager . Para cada tipo de evento de interação em que está interessado, tem de subscrever o mesmo.

  InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
  

• Processe o evento. Depois de subscrever um evento de interação, receberá a chamada de retorno quando apropriado. No exemplo SourcePressed , isto será depois de a origem ter sido detetada e antes de ser libertada 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 processar um evento

Tem de parar de processar um evento quando já não estiver interessado no evento ou estiver a destruir o objeto que subscreveu no evento. Para parar de processar o evento, anule a subscrição 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 fica ativa)
• InteractionSourceLost (torna-se inativo)
• InteractionSourcePressed (toque, premir botão ou "Selecionar" expresso)
• InteractionSourceReleased (fim de um toque, botão libertado ou fim de "Selecionar" expressado)
• InteractionSourceUpdated (move ou altera algum estado)

Eventos para poses de destino histórico que correspondem com maior precisão a uma imprensa ou lançamento

As APIs de consulta descritas anteriormente dão às suas poses previstas para a aplicação. Embora essas poses previstas sejam as melhores para compor o controlador ou um objeto portátil virtual, as poses futuras não são ideais para segmentação, por duas razões fundamentais:

• Quando o utilizador prime um botão num controlador, pode haver cerca de 20 ms de latência sem fios através de Bluetooth antes de o sistema receber a imprensa.
• Em seguida, se estiver a utilizar uma pose prevista para a frente, haverá outra predição de 10 a 20 ms de reencaminhamento aplicada para direcionar o momento em que os fotões da moldura atual chegarão aos olhos do utilizador.

Isto significa que as sondagens dão-lhe 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 utilizador estavam realmente de volta quando a imprensa ou o comunicado aconteceu. Para a entrada manual do HoloLens, embora não exista nenhum atraso na transmissão sem fios, existe um atraso de processamento semelhante para detetar a imprensa.

Para direcionar com precisão com base na intenção original do utilizador para uma mão ou comando premir, deve utilizar a pose de origem histórica ou a pose de cabeça desse evento de entrada InteractionSourcePressed ou InteractionSourceReleased .

Pode direcionar uma imprensa ou uma versão com dados de pose histórica da cabeça do utilizador ou do controlador:

• A pose da cabeça no momento em que ocorreu um gesto ou a imprensa do controlador, que pode ser utilizada para direcionar para determinar o que o utilizador estava a observar :

  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 premição do controlador de movimento, que pode ser utilizada para direcionar para determinar o que o utilizador estava a apontar para o controlador. Este será o estado do controlador que experimentou a imprensa. Se estiver a compor o controlador em si, pode pedir a pose do ponteiro em vez da pose de aperto, para disparar o raio de destino do que o utilizador considerará a ponta natural desse controlador composto:

  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 processadores 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

Pode aceder ao gesto e ao controlador de movimento a partir do Gestor de entrada.

Acompanhe os tutoriais

Os tutoriais passo a passo, com exemplos de personalização mais detalhados, estão disponíveis no Mixed Reality Academy:

• Mr Input 211: Gesto
• Mr Input 213: Controladores de movimento

Mr Input 213 - Motion controller

Próximo Ponto de Verificação de Desenvolvimento

Se estás a seguir a jornada de desenvolvimento do Unity que demos, estás no meio de explorar os blocos modulares principais do MRTK. A partir daqui, pode continuar para o bloco modular seguinte:

Controlo de mãos e olhos

Em alternativa, avance para Mixed Reality capacidades e APIs da plataforma:

Experiências partilhadas

Pode sempre voltar aos pontos de verificação de desenvolvimento do Unity em qualquer altura.

Ver também

• Olhar de cabeça e consolidação
• Comandos de movimento