Migrar aplicações holoLens (1.ª geração) para HoloLens 2

Artigo
07/12/2023

Este guia é adaptado para ajudar os programadores com uma aplicação do Unity existente para o HoloLens (1.ª geração) a migrar a sua aplicação para o dispositivo HoloLens 2. Existem quatro passos fundamentais para migrar uma aplicação do Unity do HoloLens (1.ª geração) para HoloLens 2.

As secções abaixo informações detalhadas para cada fase:

Passo 1	Passo 2	Passo 3	Passo 4

Transferir as ferramentas mais recentes	Atualizar Projeto do Unity	Compilar para o ARM	Migrar para MRTK v2

Pré-requisitos

Recomendamos vivamente que utilize o controlo de origem para guardar um instantâneo do estado original da sua aplicação antes de iniciar o processo de migração. Também recomendamos que guarde estados de ponto de verificação em vários momentos durante o processo. Poderá considerar útil ter outra instância da aplicação original aberta no Unity para que possa comparar lado a lado durante o processo de migração.

Nota

Antes de migrar, certifique-se de que tem as ferramentas mais recentes instaladas para Windows Mixed Reality desenvolvimento. Para a maioria dos programadores existentes do HoloLens, isto envolve atualizar para a versão mais recente do Visual Studio 2019 e instalar o SDK do Windows adequado. O conteúdo que se segue mergulha ainda mais em diferentes versões do Unity e na Versão 2 do Mixed Reality Toolkit (MRTK).

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

Migrar o projeto para a versão mais recente do Unity

Se estiver a utilizar o MRTK v2, recomendamos que atualize para o MRTK 2.7 antes de atualizar o projeto para o Unity 2020.3 LTS. O MRTK 2.7 suporta o Unity 2018, 2019 e 2020, permitindo-lhe garantir que o seu projeto está pronto para o Unity 2020 mesmo antes de atualizar o Unity. Avalie quaisquer dependências de plug-in que existam atualmente no projeto e determine se estes DLLs podem ser criados para o ARM64. Para projetos com um plug-in dependente do ARM rígido, poderá ter de continuar a criar a sua aplicação para o ARM.

Atualizar definições de cenário/projeto no Unity

Depois de atualizar para o Unity 2020.3 LTS, recomendamos que atualize definições específicas no Unity para obter resultados ideais no dispositivo. Estas definições são descritas em detalhe nas definições recomendadas para o Unity.

Para reiterar, o back-end de scripting do .NET está a ser preterido no Unity 2018 e removido a partir do Unity 2019. Deve considerar a possibilidade de mudar o seu projeto para IL2CPP.

Nota

O back-end de scripting IL2CPP pode causar tempos de compilação mais longos do Unity para o Visual Studio. Os programadores devem configurar o seu computador programador para otimizar os tempos de compilação il2CPP. Também pode beneficiar da configuração de um servidor de cache, especialmente para projetos do Unity com uma grande quantidade de recursos (excluindo ficheiros de script) ou em constante alteração de cenas e recursos. Ao abrir um projeto, o Unity armazena recursos elegíveis num formato de cache interna no computador programador. Os itens têm de ser importados novamente e processados novamente quando modificados. Este processo pode ser feito uma vez, guardado num servidor de cache e, em seguida, partilhado com outros programadores para poupar tempo, ao contrário de todos os programadores que processam a importação de novas alterações localmente.

Depois de abordar quaisquer alterações interruptivas que resultem da mudança para a versão atualizada do Unity, crie e teste as suas aplicações atuais no HoloLens (1.ª geração). Esta é uma boa altura para criar e guardar uma consolidação no controlo de origem.

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

O HoloLens (1.ª geração) executa aplicações num processador x86; o HoloLens 2 utiliza um processador ARM. As aplicações HoloLens existentes têm de ser transferidas para suportar o ARM. Conforme indicado anteriormente, o Unity 2018 LTS suporta a compilação de aplicações ARM32, enquanto o Unity 2019 e posteriores suportam a compilação de aplicações ARM32 e ARM64. O desenvolvimento de aplicações ARM64 é preferido porque existe uma diferença material no desempenho. No entanto, isto requer que todas as dependências de plug-in também sejam criadas para o ARM64.

Reveja todas as dependências de DLL na sua aplicação. Recomendamos que remova as dependências que já não são necessárias para o seu projeto. Para os plug-ins restantes que são necessários, ingera os respetivos binários ARM32 ou ARM64 no seu projeto do Unity.

Depois de ingerir os 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 a sua aplicação pode ser criada para processadores ARM. Recomendamos que guarde a aplicação como consolidação na sua solução de controlo de origem.

Importante

As aplicações que utilizam MRTK v1 podem ser executadas no HoloLens 2 depois de alterar o destino de compilação para ARM, assumindo que todos os outros requisitos são cumpridos. Isto inclui certificar-se de que tem versões arm de todos os plug-ins. No entanto, a sua aplicação não terá acesso a funções específicas de HoloLens 2, como controlo visual e manual articulado. O MRTK v1 e o MRTK v2 têm espaços de nomes diferentes que permitem que ambas as versões estejam no mesmo projeto, o que é útil para a transição de uma para a outra.

Atualizar para o MRTK versão 2

O MRTK Versão 2 é o novo toolkit que suporta o HoloLens (1.ª geração) e HoloLens 2. É também onde todas as novas capacidades de HoloLens 2 foram adicionadas, tais como interações com as mãos e controlo ocular.

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

Preparar a migração

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

Por fim, o novo MRTK v2 passou de um modelo de scripts e objetos do gestor no local para uma arquitetura de fornecedor de configuração e serviços. Isto resulta numa hierarquia de cenários mais limpa e num modelo de arquitetura, mas requer uma curva de aprendizagem para compreender os novos perfis de configuração. Leia o Guia de Configuração do Mixed Reality Toolkit para começar a familiarizar-se com as definições e perfis importantes que tem de ajustar às necessidades da sua aplicação.

Migrar o projeto

Depois de importar o MRTK v2, é provável que o projeto unity tenha muitos erros relacionados com o compilador. Estes são comuns devido à nova estrutura do espaço de nomes e nomes de componentes. Continue a resolver estes erros ao modificar os scripts para os novos espaços de nomes e componentes.

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

Melhores práticas

Dê o priorizador ao sombreado padrão do MRTK.
Trabalhe num tipo de alteração interruptiva de cada vez (exemplo: IFocusable to IMixedRealityFocusHandler).
Teste após cada alteração e utilize o controlo de origem.
Utilize o UX MRTK predefinido (botões, ardósias, etc.), sempre que possível.
Evite modificar ficheiros MRTK diretamente; criar wrappers em torno de componentes MRTK.
- Esta ação facilita a ingestão e atualizações futuras do MRTK.
Reveja e explore as cenas de exemplo fornecidas no MRTK, especialmente HandInteractionExamples.scene.
Reconstrua a IU baseada em telas com quads, colisores e texto TextMeshPro.
Ativar a Partilha intermédia de Profundidade ou definir o ponto de foco; para um melhor desempenho, utilize uma memória intermédia de profundidade de 16 bits. Certifique-se de que, ao compor cor, também irá compor profundidade. Geralmente, o Unity não escreve profundidade para gameobjects transparentes e de texto.
Selecione Composição de Instâncias de Passe Único.
Utilizar o perfil de configuração do HoloLens 2 para MRTK

Testar a sua aplicação

Na Versão 2 do MRTK, pode simular interações manufacionais diretamente no Unity e desenvolver com as novas APIs para interações mano e controlo ocular. O dispositivo HoloLens 2 é necessário para criar uma experiência de utilizador satisfatória. Recomendamos que 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 "select via air-tap" podem ser testados no HoloLens (1.ª geração).

Atualizar o modelo de interação para HoloLens 2

Atenção

Se o seu projeto estiver a utilizar algum dos XRs. APIs WSA, tenha em atenção que estas estão a ser eliminadas gradualmente a favor das novas APIs de entrada XR do Unity em futuras versões do Unity. Pode encontrar mais informações sobre as APIs de entrada XR aqui.

Assim que a sua aplicação for fechada e preparada para HoloLens 2, está pronto para considerar atualizar o modelo de interação e as colocações de design de hologramas. No HoloLens (1.ª geração), a sua aplicação provavelmente tem um modelo de interação de olhar e consolidação com hologramas relativamente distantes para caber no campo de vista.

Para atualizar a estrutura da aplicação para ser mais adequado para HoloLens 2:

Componentes mrtk: de acordo com o pré-trabalho, se adicionou MRTK v2, existem vários componentes/scripts a tirar partido que foram concebidos e otimizados para HoloLens 2.
Modelo de interação: considere atualizar o modelo de interação. Para a maioria dos cenários, recomendamos que mude de olhar e consolidação para mãos. Alguns dos seus hologramas podem estar fora do alcance do braço, e mudar para as mãos resulta em raios de interação distantes que apontam raios e agarram gestos.
Colocação do holograma: depois de mudar para um modelo de interação de mãos, considere aproximar alguns hologramas para que os utilizadores possam interagir diretamente com os mesmos através de gestos de interação quase interação com as mãos. Os tipos de hologramas a aproximar-se de agarrar ou interagir diretamente são:

menus de destino pequenos
controlos
botões
hologramas mais pequenos que, quando agarrados e inspecionados, cabem no HoloLens 2 campo de vista.

As aplicações e os cenários variam; Vamos continuar a refinar e publicar orientações de design com base em comentários e aprendizagens contínuas.

Sugestões adicionais sobre como mover aplicações do x86 para o ARM

As aplicações do Unity simples são simples porque pode criar um pacote de aplicações arm ou implementar diretamente no dispositivo para que o pacote seja executado. Alguns plug-ins nativos do Unity podem apresentar determinados desafios de desenvolvimento. Por este motivo, tem de atualizar todos os plug-ins nativos do Unity para o Visual Studio 2019 e, em seguida, reconstruir para o ARM.
Uma aplicação utilizou o plug-in Unity AudioKinetic Wwise. A versão do Unity em utilização não tinha um plug-in arm UWP e houve um esforço considerável para reformular as capacidades de som na aplicação em questão para ser executada no ARM. Certifique-se de que todos os plug-ins necessários para os seus planos de desenvolvimento estão instalados e disponíveis no Unity.
Em alguns casos, um plug-in UWP/ARM pode não existir para plug-ins necessários para a aplicação, o que bloqueia a capacidade de portar a aplicação e executá-la no HoloLens 2. Contacte o fornecedor de plug-in para resolver o problema e fornecer suporte para o ARM.
O minfloat (e variantes como min16float, minint, etc.) em sombreados podem comportar-se de forma diferente no HoloLens 2 do que no HoloLens (1.ª geração). Especificamente, estas garantias garantem que, pelo menos, será utilizado o número especificado de bits. Nas GPUs Intel/Nvidia, as minfloats são em grande parte tratadas como 32 bits. No ARM, o número de bits especificado é efetivamente cumprido. Na prática, estes números podem ter menos precisão ou intervalo no HoloLens 2 do que no HoloLens (1.ª geração).
As instruções de _asm não parecem funcionar no ARM, o que significa que qualquer código que utilize _asm instruções tem de ser reescrito.
O ARM não suporta o conjunto de instruções do 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 sombreado no ARM é executado durante a primeira chamada de desenho após o sombreador ter sido carregado ou algo em que o sombreador se baseie mudou e não no tempo de carregamento do shader. O impacto na taxa de frames pode ser percetível, dependendo do número de sombreados que têm de ser compilados, com implicações na forma como os sombreados devem ser processados, empacotados e atualizados de forma diferente no HoloLens 2 vs HoloLens (1.ª geração).