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

Artigo
05/21/2024

Este guia é adaptado para ajudar os desenvolvedores com um aplicativo Unity existente para HoloLens (1ª geração) a portar seu aplicativo para o dispositivo HoloLens 2. Há quatro etapas principais para portar um aplicativo Unity HoloLens (1ª geração) para o HoloLens 2.

As seções abaixo detalham informações para cada etapa:

Passo 1	Passo 2	Passo 3	Passo 4

Transferir as ferramentas mais recentes	Atualizar projeto Unity	Compilar para ARM	Migrar para MRTK v2

Pré-requisitos

É altamente recomendável que você use o controle do código-fonte para salvar um instantâneo do estado original do seu aplicativo antes de iniciar o processo de portabilidade. Também recomendamos que você salve os estados do 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 que você possa comparar lado a lado durante o processo de portabilidade.

Nota

Antes de portar, verifique se você tem as ferramentas mais recentes instaladas para o desenvolvimento do Windows Mixed Reality. Para a maioria dos desenvolvedores HoloLens existentes, isso envolve a atualização para a versão mais recente do Visual Studio 2019 e a instalação do SDK do Windows apropriado. O conteúdo a seguir mergulha ainda mais em diferentes versões do Unity e no Mixed Reality Toolkit (MRTK) Versão 2.

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

Migre seu projeto para a versão mais recente do Unity

Se você estiver usando o MRTK v2, recomendamos que atualize para o MRTK 2.7 antes de atualizar seu projeto para o Unity 2020.3 LTS. O MRTK 2.7 suporta Unity 2018, 2019 e 2020, permitindo que você garanta que seu projeto esteja pronto para Unity 2020 antes mesmo de atualizar o Unity. Avalie todas as dependências de plug-in que existem atualmente em seu projeto e determine se essas DLLs podem ser criadas para ARM64. Para projetos com um plug-in dependente de ARM, talvez seja necessário continuar criando seu aplicativo para ARM.

Atualizar configurações de cena/projeto no Unity

Depois de atualizar para o Unity 2020.3 LTS, recomendamos que você atualize configurações específicas no Unity para obter os melhores resultados no dispositivo. Essas configurações são descritas em detalhes nas configurações recomendadas para Unity.

Para reiterar, o back-end de script .NET está sendo preterido no Unity 2018 e removido a partir do Unity 2019. Você deve considerar fortemente mudar seu projeto para IL2CPP.

Nota

O back-end de script IL2CPP pode causar tempos de compilação mais longos do Unity para o Visual Studio. Os desenvolvedores devem configurar sua máquina de desenvolvedor para otimizar os tempos de compilação IL2CPP. Você também pode se beneficiar da configuração de um servidor de cache, especialmente para projetos Unity com uma grande quantidade de ativos (excluindo arquivos de script) ou cenas e ativos em constante mudança. Ao abrir um projeto, o Unity armazena ativos qualificados em um formato de cache interno na máquina do desenvolvedor. Os itens devem ser reimportados e reprocessados quando modificados. Esse processo pode ser feito uma vez, salvo em um servidor de cache e, em seguida, compartilhado com outros desenvolvedores para economizar tempo, ao contrário de cada desenvolvedor que processa a reimportação de novas alterações localmente.

Depois de abordar quaisquer alterações significativas resultantes da mudança para a versão atualizada do Unity, crie e teste seus aplicativos atuais no HoloLens (1ª geração). Este é um bom momento para criar e salvar uma confirmação no controle do código-fonte.

Compilar dependências/plugins para o processador ARM

HoloLens (1ª geração) executa aplicações num processador x86; o HoloLens 2 usa um processador ARM. Os aplicativos HoloLens existentes precisam ser portados para suportar ARM. Como observado anteriormente, o Unity 2018 LTS suporta a compilação de aplicativos ARM32, enquanto o Unity 2019 e posterior suporta a compilação de aplicativos ARM32 e ARM64. O desenvolvimento para aplicativos ARM64 é preferido porque há uma diferença material no desempenho. No entanto, isso requer que todas as dependências do plugin também sejam criadas para ARM64.

Revise todas as dependências de DLL em seu aplicativo. Recomendamos remover dependências que não são mais necessárias para seu projeto. Para os plugins restantes necessários, ingira os respetivos binários ARM32 ou ARM64 em seu projeto Unity.

Depois de ingerir as DLLs relevantes, crie uma solução do Visual Studio a partir do Unity e compile um AppX para ARM no Visual Studio para verificar se seu aplicativo pode ser criado para processadores ARM. Recomendamos que você salve o aplicativo como uma confirmação em sua solução de controle do código-fonte.

Importante

Os aplicativos que usam MRTK v1 podem ser executados no HoloLens 2 depois de alterar o destino de compilação para ARM, supondo que todos os outros requisitos sejam atendidos. Isso inclui certificar-se de que você tem versões ARM de todos os seus plugins. No entanto, seu aplicativo não terá acesso a funções específicas do HoloLens 2, como rastreamento articulado de mãos e olhos. MRTK v1 e MRTK v2 têm namespaces diferentes que permitem que ambas as versões estejam no mesmo projeto, o que é útil para a transição de uma para a outra.

Atualização para MRTK versão 2

MRTK Versão 2 é o novo kit de ferramentas no topo do Unity que suporta HoloLens (1ª geração) e HoloLens 2. É também onde todos os novos recursos do HoloLens 2 foram adicionados, como interações manuais e rastreamento ocular.

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

Preparar para a migração

Antes de ingerir os novos arquivos *.unitypackage para MRTK v2, recomendamos que você faça um inventário de (1) qualquer código personalizado que se integre ao MRTK v1 e (2) qualquer código personalizado para interações de entrada ou componentes UX. O conflito mais comum e prevalente para um desenvolvedor de realidade mista que ingere MRTK v2 envolve entrada e interações. Recomendamos que você revise o modelo de entrada MRTK v2.

Finalmente, o novo MRTK v2 passou de um modelo de scripts e objetos de gerenciamento em cena para uma arquitetura de provedor de configuração e serviços. Isso resulta em uma hierarquia de cena e um modelo de arquitetura mais limpos, mas requer uma curva de aprendizado para entender os novos perfis de configuração. Leia o Guia de Configuração do Kit de Ferramentas de Realidade Mista para começar a se familiarizar com as configurações e perfis importantes que você deve ajustar às necessidades do seu aplicativo.

Migrando o projeto

Depois de importar o MRTK v2, seu projeto Unity provavelmente tem muitos erros relacionados ao compilador. Eles são comuns devido à nova estrutura de namespace e nomes de componentes. Continue a resolver esses erros modificando seus scripts para os novos namespaces e componentes.

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

Melhores práticas

Dê prioridade ao sombreador padrão MRTK.
Trabalhe em um tipo de alteração de quebra de cada vez (exemplo: IFocusable para IMixedRealityFocusHandler).
Teste após cada alteração e use o controle do código-fonte.
Use o MRTK UX padrão (botões, ardósias e assim por diante), quando possível.
Abster-se de modificar arquivos MRTK diretamente; criar wrappers em torno de componentes MRTK.
- Esta ação facilita futuras ingestões e atualizações de MRTK.
Analise e explore exemplos de cenas fornecidos no MRTK, especialmente HandInteractionExamples.scene.
Reconstrua a interface do usuário baseada em tela com quads, colisores e texto TextMeshPro.
Habilite o compartilhamento de buffer de profundidade ou defina o ponto de foco; para um melhor desempenho, use um buffer de profundidade de 16 bits. Certifique-se de que, ao renderizar cores, você também renderize profundidade. Unity geralmente não escreve profundidade para objetos de jogo transparentes e de texto.
Selecione Renderização com instância de passagem única.
Use o perfil de configuração do HoloLens 2 para MRTK

Testando seu aplicativo

No MRTK Versão 2, você pode simular interações manuais diretamente no Unity e desenvolver com as novas APIs para interações manuais e rastreamento 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 uma maior compreensão. O MRTK v2 suporta o desenvolvimento no HoloLens (1ª geração) e os modelos de entrada tradicionais, como "selecionar via torneira aérea", podem ser testados no HoloLens (1ª geração).

Atualizando seu modelo de interação para o HoloLens 2

Atenção

Se o seu projeto estiver usando qualquer um dos XR. As APIs WSA, observe que elas estão sendo eliminadas em favor das novas APIs de entrada XR do Unity em versões futuras do Unity. Você pode encontrar mais informações sobre as APIs de entrada XR aqui.

Assim que seu 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 do design do holograma. No HoloLens (1ª geração), seu aplicativo provavelmente tem um modelo de interação de olhar e confirmar com hologramas relativamente distantes para caber no campo de visão.

Para atualizar o design do seu aplicativo para ser mais adequado para o HoloLens 2:

Componentes MRTK: De acordo com o pré-trabalho, se você adicionou o MRTK v2, há vários componentes/scripts para aproveitar que foram projetados e otimizados para o HoloLens 2.
Modelo de interação: considere atualizar seu modelo de interação. Para a maioria dos cenários, recomendamos que você mude do olhar e se comprometa com as mãos. Alguns dos seus hologramas podem estar fora do alcance do braço, e mudar para as mãos resulta em interação distante apontando raios e gestos de agarrar.
Colocação de hologramas: Depois de mudar para um modelo de interação com as mãos, considere aproximar alguns hologramas para que os usuários possam interagir diretamente com eles usando gestos de agarrar de quase interação com as mãos. Os tipos de hologramas com os quais se aproximar para agarrar ou interagir diretamente são:

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

As aplicações e os cenários variam; Continuaremos a refinar e postar orientações de design com base em feedback e aprendizados contínuos.

Dicas adicionais sobre como mover aplicativos de x86 para ARM

Os aplicativos Unity simples são simples porque você pode criar um pacote de aplicativos ARM ou implantar diretamente no dispositivo para que o pacote seja executado. Alguns plugins 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, reconstruir para ARM.
Um aplicativo usou o plugin Unity AudioKinetic Wwise. A versão Unity em uso não tinha um plug-in UWP ARM, e houve um esforço considerável para retrabalhar recursos de som no aplicativo em questão para ser executado em ARM. Certifique-se de que todos os plugins necessários para seus planos de desenvolvimento estejam instalados e disponíveis no Unity.
Em alguns casos, um plug-in UWP/ARM pode não existir para plug-ins necessários ao aplicativo, o que bloqueia a capacidade de portar o aplicativo e executá-lo no HoloLens 2. Entre em contato com seu provedor de plug-ins para resolver o problema e fornecer suporte para ARM.
O minfloat (e variantes como min16float, minint, e assim por diante) em shaders pode se comportar de forma diferente no HoloLens 2 do que no HoloLens (1ª geração). Especificamente, eles garantem que pelo menos o número especificado de bits será usado. Nas GPUs Intel/Nvidia, os minfloats são amplamente 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 no HoloLens (1ª geração).
As instruções _asm não parecem funcionar em ARM, o que significa que qualquer código usando _asm instruções deve ser reescrito.
O ARM não suporta o conjunto de instruções SIMD 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 foi carregado ou algo em que o sombreador confia foi alterado, não no tempo de carregamento do sombreador. O impacto na taxa de quadros pode ser percetível, dependendo de quantos sombreadores precisam ser compilados, com implicações sobre como os sombreadores devem ser manipulados, empacotados e atualizados de forma diferente no HoloLens 2 vs HoloLens (1ª geração).

Share via