Portabilidad de aplicaciones de HoloLens (1.ª generación) a HoloLens 2

Artículo
07/12/2023

Esta guía está diseñada específicamente para ayudar a los desarrolladores que tienen una aplicación existente de Unity para HoloLens (1.ª generación) a realizar la portabilidad de su aplicación al dispositivo HoloLens 2. Hay cuatro pasos clave para portar una aplicación de Unity de HoloLens (1.ª generación) a HoloLens 2.

En las secciones siguientes se detalla la información de cada fase:

Paso 1	Paso 2	Paso 3	Paso 4

Descarga de las herramientas más recientes	Actualización del proyecto de Unity	Compilación para ARM	Migración a versión 2 de MRTK

Requisitos previos

Se recomienda encarecidamente usar el control de origen para guardar una instantánea del estado original de la aplicación antes de iniciar el proceso de portabilidad. También se recomienda guardar los estados del punto de control en varias ocasiones durante el proceso. Puede resultar útil tener otra instancia de la aplicación original abierta en Unity para poder compararla en paralelo durante el proceso de porte.

Nota

Antes de realizar la portabilidad, asegúrese de que tiene instaladas las herramientas más recientes para el desarrollo de Windows Mixed Reality. Para la mayoría de los desarrolladores de HoloLens existentes, esto implica actualizar a la versión más reciente de Visual Studio 2019 e instalar el Windows SDK adecuado. El contenido siguiente profundiza más en las diferentes versiones de Unity y la versión 2 de Mixed Reality Toolkit (MRTK).

Para obtener más información, consulte Instalar las herramientas.

Migración del proyecto a la última versión de Unity

Si usa MRTK v2, se recomienda actualizar a MRTK 2.7 antes de actualizar el proyecto a Unity 2020.3 LTS. MRTK 2.7 admite Unity 2018, 2019 y 2020, lo que le permite asegurarse de que el proyecto esté listo para Unity 2020 incluso antes de actualizar Unity. Debe evaluar cualquier dependencia de complemento que exista actualmente en el proyecto, y determinar si estos archivos DLL pueden compilarse para ARM64. En el caso de los proyectos con un complemento dependiente de ARM64, es posible que deba seguir compilando la aplicación para ARM.

Actualización de la configuración de la escena o proyecto en Unity

Después de actualizar a Unity 2020.3 LTS, se recomienda actualizar valores concretos en Unity para obtener los mejores resultados en el dispositivo. Estos valores se describen en detalle en Configuración recomendada para Unity.

Recuerde que el back-end de scripting de .NET estará en desuso en Unity 2018 y se habrá eliminado a partir de Unity 2019. Es muy recomendable que considere la posibilidad de cambiar su proyecto a IL2CPP.

Nota

El back-end de scripting IL2CPP puede provocar tiempos de compilación más largos de Unity a Visual Studio. Los desarrolladores deben configurar su máquina de desarrolladores para optimizar los tiempos de compilación de IL2CPP. También puede resultarle útil configurar un servidor de caché, especialmente para los proyectos de Unity que tengan una gran cantidad de recursos (sin contar con los archivos de script), o que cambien constantemente de escenas y recursos. Al abrir un proyecto, Unity almacena los activos aplicables en un formato de la memoria caché interna en la máquina del desarrollador. Los elementos se tienen que volver a importar y a procesar cuando se modifican. Este proceso se puede realizar una vez y guardar en un servidor de caché; de esta forma se comparte con otros desarrolladores para ahorrar tiempo, en lugar de que cada desarrollador tenga que procesar localmente la reimportación de los nuevos cambios.

Después de solucionar los cambios importantes que hayan surgido tras el cambio a la versión actualizada de Unity, debe compilar y probar sus aplicaciones actuales en HoloLens (1.ª generación). Este es un buen momento para crear y guardar una confirmación en el control de código fuente.

Compilación de dependencias/complementos para procesadores ARM

HoloLens (1.ª generación) ejecuta las aplicaciones en un procesador x86, mientras que el dispositivo HoloLens 2 usa un procesador ARM. Por lo tanto, las aplicaciones de HoloLens existentes se tienen que portar para admitir ARM. Como se indicó anteriormente, Unity 2018 LTS admite la compilación para las aplicaciones de ARM32, mientras que Unity 2019 y versiones posteriores admiten la compilación para las aplicaciones de ARM32 y ARM64. Es preferible desarrollar para aplicaciones de ARM64, ya que existe una diferencia sustancial en el rendimiento. Sin embargo, esto requiere que todas las dependencias de complemento se compilen también para ARM64.

Revisa todas las dependencias DLL en la aplicación. Se recomienda quitar las dependencias que ya no sean necesarias para el proyecto. Para el resto de complementos que son necesarios, se deben ingerir los respectivos archivos binarios de ARM32 o ARM64 en el proyecto de Unity.

Después de la ingesta de las DLL pertinentes, compile una solución de Visual Studio desde Unity y, a continuación, compile un paquete AppX para ARM en Visual Studio para comprobar que la aplicación se puede compilar para procesadores ARM. Se recomienda guardar la aplicación como una confirmación en la solución de control de origen.

Importante

La aplicación que usa MRTK v1 puede ejecutarse en HoloLens 2 después de cambiar el destino de compilación a ARM, suponiendo que se cumplen todos los demás requisitos. Esto incluye asegurarse de que tiene versiones ARM de todos los complementos. Sin embargo, la aplicación no tendrá acceso a funciones específicas de HoloLens 2, como el seguimiento de la mano articulada y el ojo. MRTK v1 y MRTK v2 tienen distintos espacios de nombres que permiten que ambas versiones estén en el mismo proyecto, lo que resulta útil para realizar la transición de una a otra.

Actualización a la versión 2 de MRTK

MRTK versión 2 es el nuevo kit de herramientas además de Unity que admite tanto HoloLens (1.ª generación) como HoloLens 2. También es donde se agregan todas las nuevas funcionalidades de HoloLens 2, como las interacciones con la mano y el seguimiento de los ojos.

Consulte los recursos siguientes para obtener más información sobre el uso de la versión 2 de MRTK:

Preparación para la migración

Antes de realizar la ingesta de los nuevos archivos *.unitypackage para la versión 2 de MRTK, se recomienda realizar un inventario de (1) cualquier código personalizado que se integre con la versión 1 de MRTK y (2) cualquier código personalizado para las interacciones de entrada o los componentes de la experiencia de usuario. El conflicto más común y que se da con más frecuencia para un desarrollador de realidad mixta en relación con la ingesta de la versión 2 de MRTK tiene que ver con las entradas y las interacciones. Se recomienda revisar el modelo de entrada de MRTK v2.

Por último, la nueva versión 2 de MRTK ha pasado de un modelo de scripts y objetos de administrador en la escena a una arquitectura de configuración y proveedor de servicios. Esto da como resultado un modelo de arquitectura y jerarquía de escena más limpio, pero requiere una curva de aprendizaje para comprender los nuevos perfiles de configuración. Por ello, le recomendamos que lea Guía de configuración del kit de herramientas de Mixed Reality para familiarizarse con los perfiles y opciones más importantes con los que podrá ajustarse a las necesidades de la aplicación.

Migración del proyecto

Después de importar MRTK v2, el proyecto de Unity probablemente tenga muchos errores relacionados con el compilador. Generalmente, estos errores se deben a la nueva estructura del espacio de nombres y de los nuevos nombres de componente. Puede resolver estos errores mediante la modificación de los scripts con los espacios de nombres y componentes nuevos.

Para más información sobre las diferencias de API específicas entre HTK/MRTK y MRTK v2, consulta la guía de migración en la wiki de la versión 2 de MRTK.

Procedimientos recomendados

De preferencia al uso del sombreador MRTK Standard.
Trabaje en un tipo de cambio importante a la vez (por ejemplo: de IFocusable a IMixedRealityFocusHandler).
Haz una prueba después de cada cambio y usa el control de código fuente.
Use experiencias de usuario de MRTK predeterminadas (botones, tabletas táctiles, etc.) cuando sea posible.
Intenta evitar la modificación de los archivos de MRTK directamente; en su lugar, crea contenedores en torno a los componentes de MRTK.
- Esta acción facilita las futuras ingestas y actualizaciones de MRTK.
Revisa y explora escenas de ejemplo proporcionadas en MRTK (especialmente HandInteractionExamples.scene).
Vuelve a generar la interfaz de usuario basada en lienzo con cuadrángulos, colisionadores y texto TextMeshPro.
Habilite el uso compartido del búfer de profundidad o establezca el punto de enfoque; para mejorar el rendimiento, use un búfer de profundidad de 16 bits. Asegúrese de que, al representar el color, también represente la profundidad. Por lo general, Unity no escribe la profundidad de objetos GameObject de texto y transparentes.
Seleccione Representación con instancia de un solo paso.
Use el perfil de configuración de HoloLens 2 para MRTK.

Prueba de la aplicación

En la versión 2 de MRTK, puede simular las interacciones con las manos directamente en Unity, así como desarrollar elementos con las nuevas API para las interacciones con las manos y el seguimiento de los ojos. El dispositivo HoloLens 2 es necesario para crear una experiencia de usuario satisfactoria. Se recomienda estudiar la documentación y las herramientas para una conocer mejor este tema. La versión 2 de MRTK admite el desarrollo en HoloLens (1.ª generación) y los modelos de entrada tradicionales, como la selección mediante pulsación en el aire, se pueden probar en los dispositivos HoloLens (1.ª generación).

Actualización del modelo de interacción para HoloLens 2

Precaución

Si el proyecto usa cualquiera de las API XR.WSA, tenga en cuenta que se van a retirar gradualmente en favor de las nuevas API de entrada de XR de Unity en futuras versiones de Unity. Puede encontrar más información sobre estas las API de entrada de XR aquí.

Una vez que la aplicación está portada y preparada para HoloLens 2, ya estás listo para considerar la actualización de las ubicaciones del diseño del holograma y del modelo. En HoloLens (1ª generación), es muy posible que tu aplicación tenga un modelo de interacción de mirada y confirmación con hologramas relativamente lejanos para encajar en el campo de visión.

Actualizar el diseño de la aplicación al diseño más adecuado para HoloLens 2:

Componentes de MRTK: por el trabajo previo, si agregas la versión 2 de MRTK, hay varios componentes o scripts para aprovechar que se han diseñado y optimizado para HoloLens 2.
Modelo de interacción: Plantéate la posibilidad de actualizar el modelo de interacción. En la mayoría de los escenarios, se recomienda cambiar de la opción "mirada y confirmación" a las interacciones con las manos. Algunos de los hologramas pueden estar fuera de su alcance, por lo que cambiar a las manos da como resultado una interacción lejana que produce gestos de agarre y haces apuntadores.
Ubicación de los hologramas: después de cambiar a un modelo de interacción con las manos, puede acercar algunos hologramas para interactuar directamente con ellos, utilizando gestos de agarre de interacción cercana con las manos. Los tipos de hologramas que se pueden acercar para agarrarlos directamente o interactuar con ellos son:

menús de destino pequeños
controls
botones
hologramas más pequeños que, cuando se capturan e inspeccionan, caben dentro del campo de vista de HoloLens 2.

Las aplicaciones y escenarios son diferentes, por lo que seguiremos mejorando y publicando instrucciones para el diseño basadas en comentarios y en lo que vamos aprendiendo cada día.

Sugerencias adicionales sobre cómo mover aplicaciones de x86 a ARM

Las aplicaciones directas de Unity son sencillas porque puede compilar un paquete de aplicaciones de ARM o realizar la implementación directamente en el dispositivo para que se ejecute la agrupación. Algunos complementos nativos de Unity pueden presentar ciertos desafíos de desarrollo. Por este motivo, debes actualizar todos los complementos nativos de Unity a Visual Studio 2019 y, a continuación, volver a generarlos para ARM.
Una aplicación usó el complemento Unity AudioKinetic Wwise. La versión de Unity en uso no tenía un complemento de ARM para UWP y se realizó un esfuerzo considerable para rehacer las funcionalidades de sonido de la aplicación en cuestión para que pudieran ejecutarse en ARM. Asegúrate de que todos los complementos necesarios para tus planes de desarrollo están instalados y disponibles en Unity.
En algunos casos, puede que no exista un complemento de UWP/ARM para los complementos necesarios para la aplicación, lo que bloquea la capacidad de portar la aplicación y ejecutarla en HoloLens 2. Ponte en contacto con tu proveedor de complementos para resolver el problema y obtener compatibilidad con ARM.
El comando minfloat (y sus variantes, como min16float, minint, etc.) puede comportarse en los sombreadores de manera diferente en HoloLens 2 a como lo hacía en HoloLens (1.ª generación). En concreto, estos garantizan que se utilizará al menos el número especificado de bits. En las GPU de Nvidia o Intel, estos comandos minfloat se tratan generalmente como de 32 bits. En ARM, el número de bits especificado se respeta. En la práctica, esto significa que estos números pueden tener menos precisión o rango en HoloLens 2 del que tenían en HoloLens (1.ª generación).
Las instrucciones _asm no parecen funcionar en ARM, lo que significa que cualquier código con instrucciones _asm tiene que volverse a escribir.
ARM no admite el conjunto de instrucciones SIMD, ya que varios encabezados, como xmmintrin.h, emmintrin.h, tmmintrin.h e immintrin.h, no están disponibles en ARM.
El compilador del sombreador en ARM se ejecuta durante la primera llamada draw, después de que el sombreador se haya cargado, o algo en lo que se basa sombreador haya cambiado, no en el tiempo de carga de sombreador. El impacto en la velocidad de fotogramas puede ser apreciable, en función de cuántos sombreadores deban compilarse; asimismo, hay que tener en cuenta que los sombreadores se deben controlar, empaquetar y actualizar de forma diferente en HoloLens 2, en comparación con HoloLens (1.ª generación).