Controladores de movimento em Unity

Há duas maneiras principais de agir em seu olhar no Unity: gestos com as mãos e controladores de movimento no HoloLens e no 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 espacial para o Windows Mixed Reality. As APIs comuns Input.GetButton/Input.GetAxis funcionam em vários SDKs Unity XR, enquanto a API InteractionManager/GestureRecognizer específica do Windows Mixed Reality expõe o conjunto completo de dados de entrada espacial.

APIs de entrada Unity XR

Para novos projetos, recomendamos o uso das 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 Unity

O Gerenciador de entrada para controladores de movimento Windows Mixed Reality do Unity suporta as IDs de botão e eixo listadas abaixo por meio das APIs Input.GetButton/GetAxis . A coluna "Específico do Windows MR" 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 o Windows Mixed Reality geralmente correspondem aos IDs de botão/eixo do Oculus.

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

1. O mapeamento usa IDs de 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 para os botões Menu para deixá-los disponíveis para os botões ABXY físicos.

OpenXR

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

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

Postura de aderência vs. pose de apontar

O Windows Mixed Reality suporta controladores de movimento numa 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 natural "para frente" que os aplicativos devem usar para apontar ao renderizar o controle.

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 de ponteiro. Tanto a pose de aderência quanto as coordenadas de pose de ponteiro são expressas por todas as APIs Unity em coordenadas mundiais globais de Unity.

Pose de aderência

A postura de aderência representa a localização da palma da mão do usuário, detetada por um HoloLens ou segurando um controlador de movimento.

Em fones de ouvido imersivos, a pose de aderência é melhor usada para renderizar a mão do usuário ou um objeto segurado na mão do usuário. A postura 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 postura de aderência é definida especificamente da seguinte forma:

• A posição de preensão: O centróide da palma da mão ao segurar o controlador naturalmente, ajustado para a esquerda ou para a direita para centrar a posição dentro da pega. No controlador de movimento Windows Mixed Reality, essa posição geralmente se alinha com o botão Grasp.
• Eixo direito da orientação da pega: 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 frente a partir da palma esquerda, para trás a partir da palma direita)
• O eixo de orientação da aderência para a frente: Quando fecha parcialmente a mão (como se estivesse a segurar o comando), o raio que aponta "para a frente" através do tubo formado pelos seus dedos que não são polegares.
• O eixo ascendente da orientação da aderência: O eixo para cima implicado pelas definições Direita e Frente.

Você pode acessar a pose de pega por meio da API de entrada entre fornecedores (XR. InputTracking. GetLocalPosition/Rotation) ou através da API específica do Windows MR (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 a 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, você deve apontar com um raio que é mais natural para esse objeto virtual, como um raio que viaja ao longo do cano 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 de ponteiro está disponível no Unity somente por meio da API específica do Windows MR, sourceState.sourcePose.TryGetPosition/Rotation, passando InteractionSourceNode.Pointer como argumento.

OpenXR

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

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

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

As poses fornecidas pelo 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 pelo PointerPosition de InputFeatureUsages, PointerRotation, PointerVelocity e PointerAngularVelocity representam a pose de objetivo do 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áptica

Para obter informações sobre o uso de hápticas no sistema de entrada XR da Unity, a documentação pode ser encontrada no Manual Unity para entrada XR Unity - háptica.

Estado de rastreamento do controlador

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 controles são rastreados por sensores no próprio fone de ouvido.

Se o usuário mover os controles para fora do campo de visão do fone de ouvido, o Windows continuará a inferir as posições do controle 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 irá bloquear o controlador para o usuário, rastreando a posição do usuário enquanto ele se move, enquanto ainda expõe a verdadeira orientação do controlador usando seus sensores de orientação internos. 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 rastreamento explicitamente

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

Esses estados de rastreamento do controlador de movimento são definidos da seguinte forma:

• Alta precisão: Embora o controlador de movimento esteja dentro do campo de visão do fone de ouvido, ele geralmente fornecerá posições de alta precisão, com base no rastreamento visual. Um controlador em movimento que sai momentaneamente do campo de visão ou é momentaneamente obscurecido dos sensores do fone de ouvido (por exemplo, pela outra mão do usuário) continuará a retornar poses de alta precisão por um curto período de tempo, com base no rastreamento inercial do próprio controle.
• Alta precisão (em risco de perda): Quando o usuário move o controle de movimento além da borda do campo de visão do fone de ouvido, o fone de ouvido logo será incapaz de rastrear visualmente a posição do controle. O aplicativo sabe quando o controlador atingiu esse limite FOV vendo o SourceLossRisk atingir 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 irá bloquear o controlador para o usuário, rastreando a posição do usuário enquanto ele se move, enquanto ainda expõe a verdadeira orientação do controlador usando seus sensores de orientação internos. 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. Aplicativos com requisitos de entrada mais pesados podem optar por detetar essa queda de Alta precisão para Precisão aproximada inspecionando a propriedade PositionAccuracy, por exemplo, para dar ao usuário uma caixa de visitas mais generosa em alvos fora da tela durante esse tempo.
• Nenhuma posição: Embora o controlador possa operar com precisão aproximada por um longo tempo, às vezes o sistema sabe que mesmo uma posição bloqueada pelo corpo não é significativa no momento. Por exemplo, um controlador que foi ligado pode nunca ter sido observado visualmente, ou um usuário pode colocar um controlador que é então pego 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)

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

Atualmente, a Unity usa suas APIs gerais Input.GetButton/Input.GetAxis para expor a entrada para o Oculus SDK, o OpenVR SDK e o Windows Mixed Reality, incluindo controladores de mãos e movimento. Se seu aplicativo usa essas APIs para entrada, ele pode facilmente oferecer suporte a controladores de movimento em vários SDKs XR, incluindo o 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 Unity Input Manager, vinculando um botão ou IDs de eixo a cada nome. Em seguida, você pode escrever um código que se refira 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 Positive Button ou Alt Positive Button para ler o botão do joystick 14, desta forma:

Unity InputManager

Seu script pode então verificar a ação Enviar usando Input.GetButton:

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

Você pode adicionar mais botões 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 por seu nome totalmente qualificado, usando Input.GetKey:

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

Obter uma pose de mão ou controlador de movimento

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

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

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

Espaço de nomes: UnityEngine.XR.WSA.Input
Tipos: InteractionManager, InteractionSourceState, InteractionSource, InteractionSourceProperties, InteractionSourceKind, InteractionSourceLocation

Para obter informações mais detalhadas sobre a entrada manual do Windows Mixed Reality (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 fonte, permitindo que você distinga mãos e controladores.

Sondagem para o estado dos ponteiros e controladores de movimento

Você pode pesquisar o estado desse quadro para cada fonte de interação (manual ou controlador de movimento) usando o método GetCurrentReading .

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

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

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

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

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

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

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

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

Sondagem para poses de renderização previstas para o futuro

• 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 chegarão aos olhos do usuário. As poses previstas para o futuro são melhor usadas para renderizar o controlador ou um objeto retido em cada quadro. Se você estiver direcionando uma determinada imprensa ou comunicado com o controlador, isso será mais preciso se você usar 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))) {
       // ...
  }
  

• Você também pode obter a pose de cabeça prevista para frente para este quadro atual. Assim como acontece com a pose de origem, isso é útil para renderizar um cursor, embora o direcionamento de uma determinada imprensa ou comunicado seja mais preciso se você usar 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;
       // ...
  }
  

Manipulando eventos de origem de interação

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

Para manipular eventos de origem de interação:

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

  InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
  

• Manipule o evento. Depois de se inscrever em um evento de interação, você receberá o retorno de chamada quando apropriado. No exemplo SourcePressed, isso será depois que a fonte foi detetada 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 estiver destruindo o objeto que se inscreveu no evento. Para parar de manipular o evento, cancele a inscrição no 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 fonte torna-se ativa)
• InteractionSourceLost (torna-se inativo)
• InteractionSourcePressed (toque, pressionamento de botão ou "Selecionar" pronunciado)
• InteractionSourceReleased (fim de um toque, botão liberado ou final de "Selecionar" pronunciado)
• InteractionSourceUpdated (move ou altera algum estado)

Eventos para poses de segmentação histórica que correspondem com mais precisão a uma imprensa ou comunicado

As APIs de sondagem descritas anteriormente fornecem ao seu aplicativo poses previstas para o futuro. 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 segmentação, por dois motivos principais:

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

Isto significa que a sondagem lhe dá uma pose de origem ou de cabeça que está 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 HoloLens, embora não haja atraso na transmissão sem fio, há um atraso de processamento semelhante para detetar a imprensa.

Para direcionar com precisão com base na intenção original do usuário para uma prensa manual ou controladora, 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 comunicado com dados históricos de pose da cabeça do usuário ou de seu controlador:

• A pose da cabeça no momento em que ocorreu um gesto ou pressão do controlador, que pode ser usada para segmentação 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 segmentação para determinar para que o usuário estava apontando o controle. Este será o estado do controlador que experimentou a imprensa. Se você estiver renderizando o controle em si, você pode solicitar a pose de ponteiro em vez da pose de aderência, para disparar o raio de mira a partir do que o usuário considerará a ponta 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 em MRTK

Pode aceder ao controlador de gestos e movimentos a partir do gestor de entradas.

Acompanhe os tutoriais

Tutoriais passo a passo, com exemplos de personalização mais detalhados, estão disponíveis na Academia de Realidade Mista:

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

MR Input 213 - Controlador de movimento

Próximo ponto de verificação de desenvolvimento

Se você está seguindo a jornada de desenvolvimento Unity que estabelecemos, você está no meio da exploração dos blocos de construção principais do MRTK. A partir daqui, você pode continuar para o próximo bloco de construção:

Ou pule para os recursos e APIs da plataforma de Realidade Mista:

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

Consulte também

• Olhar para a cabeça e comprometer-se
• Controladores de movimento