Portabilidade dos aplicativos HoloLens (1ª geração) para o HoloLens 2

Artigo
07/12/2023

Este guia foi projetado para ajudar os desenvolvedores com um aplicativo do Unity para HoloLens (1ª geração) a portá-lo para o dispositivo HoloLens 2. Há quatro etapas principais para portar um aplicativo do Unity do HoloLens (1ª geração) para o HoloLens 2.

As seções abaixo fornecem informações detalhadas para cada estágio:

Etapa 1	Etapa 2	Etapa 3	Etapa 4

Baixar as ferramentas mais recentes	Atualizar o projeto do Unity	Compilar para o ARM	Migrar para o MRTK v2

Pré-requisitos

Recomendamos expressamente que você use o controle do código-fonte para salvar um instantâneo do estado original dos seus aplicativos antes de iniciar o processo de portabilidade. Também recomendamos que você salve os estados de ponto de verificação em vários momentos durante o processo. Você pode achar útil ter outra instância do aplicativo original aberta no Unity para compará-las lado a lado durante o processo de portabilidade.

Observação

Antes da portabilidade, verifique se você tem as ferramentas mais recentes instaladas para o desenvolvimento no Windows Mixed Reality. Para a maioria dos desenvolvedores existentes do HoloLens, isso envolve a atualização para a última versão do Visual Studio 2019 e a instalação do SDK apropriado do Windows. O conteúdo abaixo se aprofunda ainda mais em diferentes versões do Unity e no MRTK (Kit de ferramentas de realidade misturada) versão 2.

Para obter mais informações, confira Instalar as ferramentas.

Migrar seu projeto para a última versão do Unity

Se você estiver usando o MRTK v2, recomendamos atualizá-lo para o MRTK 2.7 antes de atualizar seu projeto para o Unity 2020.3 LTS. O MRTK 2.7 é compatível com Unity 2018, 2019 e 2020, o que garante que seu projeto está pronto para o Unity 2020, mesmo antes de atualizar o Unity. Avalie as dependências de plug-in atualmente existentes no projeto e determine se essas DLLs podem ser criadas para o ARM64. Para projetos com um plug-in altamente dependente do ARM, pode ser necessário continuar a criação do aplicativo para o ARM.

Atualizar as configurações de cena/projeto no Unity

Após a atualização para o Unity 2020.3 LTS, recomendamos atualizar as configurações específicas no Unity para obter melhores resultados no dispositivo. Essas configurações são descritas detalhadamente em Configurações recomendadas para o Unity.

Reiteramos que o back-end de script do .NET está sendo preterido no Unity 2018 e removido no Unity 2019. Você deve considerar a possibilidade de mudar seu projeto para o IL2CPP.

Observação

O back-end de script IL2CPP pode causar tempos de build mais longos do Unity para o Visual Studio. Os desenvolvedores devem configurar o computador de desenvolvedor para otimizar os tempos de build do IL2CPP. Além disso, você também pode se beneficiar com a configuração de um servidor de cache, especialmente para projetos do Unity com uma grande quantidade de ativos (excluindo arquivos de script) ou que estejam constantemente alterando cenas e ativos. Ao abrir um projeto, o Unity armazena os ativos qualificados em um formato de cache interno no computador do desenvolvedor. Os itens precisam ser importados novamente e processados novamente quando modificados. Esse processo pode ser feito uma vez, salvo em um servidor de cache e compartilhado com outros desenvolvedores para economizar tempo, em vez de todos os desenvolvedores processarem a nova importação de novas alterações localmente.

Depois de resolver as alterações interruptivas que resultam da migração para a versão atualizada do Unity, compile e teste seus aplicativos atuais no HoloLens (1ª geração). Esse é um bom momento para criar e salvar uma confirmação no controle do código-fonte.

Compilar dependências/plug-ins para o processador ARM

O HoloLens (1ª geração) executa aplicativos em um processador x86, enquanto o HoloLens 2 usa um processador ARM. Portanto, é necessário portar os aplicativos HoloLens existentes para que eles deem suporte ao ARM. Conforme indicado anteriormente, o Unity 2018 LTS é compatível com a compilação de aplicativos ARM32, enquanto o Unity 2019.x é compatível com a compilação de aplicativos ARM32 e ARM64. O desenvolvimento para aplicativos ARM64 é preferível, pois há uma diferença substancial de desempenho. No entanto, isso exige que todas as dependências de plug-in também sejam compiladas para o ARM64.

Examine todas as dependências de DLL em seu aplicativo. Recomendamos a remoção de dependências que não são mais necessárias para seu projeto. Para os plug-ins restantes que são necessários, ingira os respectivos binários do ARM32 ou do ARM64 no projeto do Unity.

Após a ingestão das DLLs relevantes, compile uma solução do Visual Studio por meio do Unity e compile um AppX para ARM no Visual Studio a fim de verificar se o aplicativo pode ser compilado para processadores ARM. Recomendamos salvar o aplicativo como um commit na solução de controle do código-fonte.

Importante

Os aplicativos que usam o MRTK v1 podem ser executados no HoloLens 2 após a alteração do destino de build para o ARM, supondo que todos os outros requisitos sejam atendidos. Isso inclui verificar se todos os plug-ins têm versões do ARM. No entanto, seu aplicativo não terá acesso a funções específicas do HoloLens 2, como acompanhamento ocular e de mão articulada. O MRTK v1 e o MRTK v2 têm namespaces diferentes que permitem que ambas as versões estejam no mesmo projeto, o que é útil para fazer a transição de uma para a outra.

Atualizar para o MRTK versão 2

A versão 2 do MRTK é o novo kit de ferramentas baseado no Unity que dá suporte ao HoloLens (1ª geração) e ao HoloLens 2. É nela também em que todas as funcionalidades do HoloLens 2 foram adicionadas, como interações com as mãos e acompanhamento ocular.

Confira os seguintes recursos para obter mais informações sobre como usar o MRTK versão 2:

Preparar a migração

Antes da ingestão dos novos arquivos *.unitypackage para o MRTK v2, recomendamos fazer um inventário de (1) qualquer código personalizado integrado ao MRTK v1 e (2) qualquer código personalizado para interações de entrada ou componentes de experiência do usuário. O conflito mais comum e predominante para um desenvolvedor de realidade misturada que ingere o MRTK v2 envolve a entrada e as interações. Recomendamos que você examine o modelo de entrada do MRTK v2.

Por fim, o novo MRTK v2 fez a transição de um modelo de scripts e objetos de gerenciador na cena para uma configuração e uma arquitetura de provedor de serviços. Isso resulta em um modelo de arquitetura e hierarquia de cena mais limpo, mas exige uma curva de aprendizado para entender os novos perfis de configuração. Leia o Guia de Configuração do Kit de Ferramentas de Realidade Misturada para começar a se familiarizar com as configurações e os perfis importantes que você precisa ajustar às necessidades do seu aplicativo.

Migrar o projeto

Após a importação do MRTK v2, provavelmente, seu projeto do Unity terá muitos erros relacionados ao compilador. Eles são comuns devido à nova estrutura de namespace e aos nomes de componentes. Continue resolvendo esses erros por meio da modificação dos scripts para os novos namespaces e componentes.

Para obter informações sobre as diferenças de API específicas entre o HTK/MRTK e o MRTK v2, confira o guia de portabilidade no wiki do MRTK versão 2.

Práticas recomendadas

Dê prioridade ao sombreador padrão do MRTK.
Trabalhe em um tipo de alteração interruptiva por vez (exemplo: IFocusable para IMixedRealityFocusHandler).
Faça um teste após cada alteração e use o controle do código-fonte.
Use a experiência do usuário padrão do MRTK (botões, imagens fixas e assim por diante), quando possível.
Evite modificar os arquivos do MRTK diretamente; em vez disso, crie wrappers em torno de componentes do MRTK.
- Essa ação facilita futuras ingestões e atualizações do MRTK.
Examine e explore cenas de exemplo fornecidas no MRTK, especialmente HandInteractionExamples.scene.
Recompile a interface do usuário baseada em tela com quadrantes, colisores e texto do TextMeshPro.
Habilite Compartilhamento de Buffer de Profundidade ou defina o ponto de foco; para obter um melhor desempenho, use um buffer de profundidade de 16 bits. Quando renderizar a cor, renderize também a profundidade. O Unity geralmente não grava profundidade para gameobjects de texto e transparentes.
Selecione Renderização com uma Instância de Passagem Única.
Usar o perfil de configuração do HoloLens 2 para MRTK

Testando seu aplicativo

No MRTK Versão 2, você pode simular as interações com as mãos diretamente no Unity e desenvolver novas APIs para interações com as mãos e acompanhamento ocular. O dispositivo HoloLens 2 é necessário para criar uma experiência de usuário satisfatória. Recomendamos que você estude a documentação e as ferramentas para obter maior compreensão. O MRTK v2 dá suporte ao desenvolvimento no HoloLens (1ª geração). Portanto, os modelos de entrada tradicionais, como a "seleção por meio do gesto de fechar e abrir dedos indicador e polegar", podem ser testados no HoloLens (1ª geração).

Como atualizar o modelo de interação para o HoloLens 2

Cuidado

Se o seu projeto está usando uma das APIs do XR.WSA, observe que elas estão sendo desativadas em favor das novas APIs de entrada de XR do Unity nas versões futuras do Unity. Encontre mais informações sobre as APIs de entrada de XR aqui.

Depois que o aplicativo for portado e preparado para o HoloLens 2, você estará pronto para considerar a atualização do modelo de interação e dos posicionamentos de design dos hologramas. No HoloLens (1ª geração), o aplicativo provavelmente tem um modelo de interação de foco e confirmação com hologramas relativamente distantes para se ajustarem ao campo de visão.

Para atualizar o design do seu aplicativo a fim de torná-lo mais adequado para o HoloLens 2:

Componentes do MRTK: De acordo com o trabalho prévio, se você tiver adicionado o MRTK v2, haverá vários componentes/scripts a serem aproveitados que foram projetados e otimizados para o HoloLens 2.
Modelo de interação: Considere a atualização do modelo de interação. Para a maioria dos cenários, recomendamos que você alterne o foco e a confirmação para a interação com as mãos. Alguns dos hologramas podem ficar fora do alcance dos braços, e a alternância para a interação com as mãos resulta em raios de apontador de interação distante e em gestos de segurar.
Posicionamento de hologramas: depois de alternar para um modelo de interação com as mãos, considere a possibilidade de aproximar alguns hologramas, de modo que os usuários possam interagir diretamente com eles usando gestos de segurar de interação próxima com as mãos. Os tipos de hologramas que devem ser aproximados para segurá-los ou interagir com eles diretamente são:

menus de destino pequenos
controls
botões
hologramas menores que, quando segurados e inspecionados, se encaixam no campo de visão do HoloLens 2.

Os aplicativos e os cenários podem variar. Continuaremos refinando e postando diretrizes de design com base nos comentários e em aprendizados contínuos.

Dicas adicionais sobre como mover aplicativos do x86 para o ARM

Os aplicativos básicos do Unity são simples porque você pode criar um pacote de aplicativo ARM ou implantá-lo diretamente no dispositivo para que o pacote seja executado. Alguns plug-ins nativos do Unity podem apresentar certos desafios de desenvolvimento. Por isso, você deve atualizar todos os plug-ins nativos do Unity para o Visual Studio 2019 e, em seguida, recompilar para o ARM.
Um aplicativo usava o plug-in Wwise do Unity AudioKinetic. A versão do Unity em uso não tinha um plug-in do ARM para UWP, e houve um esforço considerável para retrabalho das funcionalidades de som no aplicativo em questão para execução no ARM. Verifique se todos os plug-ins necessários para os planos de desenvolvimento estão instalados e disponíveis no Unity.
Em alguns casos, um plug-in do UWP/ARM pode não existir para os plug-ins requeridos pelo aplicativo, o que bloqueia a capacidade de portar o aplicativo e executá-lo no HoloLens 2. Entre em contato com seu provedor de plug-in para resolver o problema e fornecer suporte para o ARM.
O minfloat (e variantes como min16float, minint e assim por diante) em sombreadores pode se comportar de modo diferente no HoloLens 2 comparado ao HoloLens (1ª geração). Especificamente, eles garantem que pelo menos o número especificado de bits seja usado. Em GPUs da Intel/da NVIDIA, os minfloats são basicamente tratados como 32 bits. No ARM, o número de bits especificado é realmente respeitado. Na prática, esses números podem ter menos precisão ou alcance no HoloLens 2 do que tinham no HoloLens (1ª geração).
As instruções de _asm não parecem funcionar no ARM, o que significa que qualquer código que use as instruções de _asm precisa ser reescrito.
O ARM não dá suporte à instrução SIMD definida porque vários cabeçalhos, como xmmintrin.h, emmintrin.h, tmmintrin.h e immintrin.h, não estão disponíveis no ARM.
O compilador de sombreador no ARM é executado durante a primeira chamada de desenho depois que o sombreador é carregado ou algo do qual o sombreador depende é alterado, não no tempo de carregamento do sombreador. O impacto na taxa de quadros pode ser perceptível, dependendo de quantos sombreadores precisam ser compilados, com implicações em como os sombreadores devem ser tratados, empacotados e atualizados de maneira diferente no HoloLens 2 em comparação ao HoloLens (1ª geração).