Conversione di app HoloLens (prima generazione) in HoloLens 2

Articolo
07/12/2023

Questa guida è personalizzata per aiutare gli sviluppatori con un'applicazione Unity esistente per HoloLens (prima generazione) convertire l'applicazione nel dispositivo HoloLens 2. Per la conversione di un'applicazione Unity da HoloLens (prima generazione) a HoloLens 2, è necessario completare quattro passaggi.

Le sezioni seguenti forniscono informazioni dettagliate per ogni fase:

Passaggio 1	Passaggio 2	Passaggio 3	Passaggio 4

Scaricare gli strumenti più recenti	Aggiornare un progetto Unity	Eseguire la compilazione per ARM	Eseguire la migrazione a MRTK v2

Prerequisiti

È consigliabile usare il controllo del codice sorgente per salvare lo stato originale dell'applicazione prima di avviare il processo di conversione. È anche consigliabile salvare gli stati del checkpoint in vari momenti durante il processo. Può risultare utile avere un'altra istanza dell'applicazione originale aperta in Unity in modo da poter confrontare side-by-side durante il processo di conversione.

Nota

Prima della conversione, assicurarsi di avere installato gli strumenti più recenti per lo sviluppo di Windows Mixed Reality. Per la maggior parte degli attuali sviluppatori HoloLens, questo passaggio comporta l'aggiornamento all'ultima versione di Visual Studio 2019 e l'installazione dell'istanza appropriata di Windows SDK. Di seguito verranno analizzate in dettaglio diverse versioni di Unity e Mixed Reality Toolkit (MRTK) versione 2.

Per altre informazioni, vedere Installare gli strumenti.

Eseguire la migrazione del progetto alla versione più recente di Unity

Se si usa MRTK v2, è consigliabile eseguire l'aggiornamento a MRTK 2.7 prima di aggiornare il progetto a Unity 2020.3 LTS. MRTK 2.7 supporta Unity 2018, 2019 e 2020, consentendo di assicurarsi che il progetto sia pronto per Unity 2020 anche prima di aggiornare Unity. Valutare eventuali dipendenze del plug-in attualmente presenti nel progetto e determinare se queste DLL possono essere compilate per ARM64. Per i progetti con un plug-in dipendente arm rigido, potrebbe essere necessario continuare a compilare l'app per ARM.

Aggiornare le impostazioni di scena o progetto in Unity

Dopo l'aggiornamento a Unity 2020.3 LTS, è consigliabile aggiornare impostazioni specifiche in Unity per ottenere risultati ottimali nel dispositivo. Queste impostazioni sono descritte in dettaglio nella sezione Impostazioni consigliate per Unity.

Per ripetere, il back-end di scripting .NET è deprecato in Unity 2018 e rimosso a partire da Unity 2019. È consigliabile impostare il progetto su IL2CPP.

Nota

Il back-end di scriptING IL2CPP può causare tempi di compilazione più lunghi da Unity a Visual Studio. Gli sviluppatori devono configurare il computer per sviluppatori per ottimizzare i tempi di compilazione IL2CPP. È anche possibile configurare un server di cache, in particolare per i progetti Unity con una grande quantità di asset (esclusi i file di script) o modificare costantemente scene e asset. All'apertura di un progetto, Unity archivia gli asset validi in un formato della cache interna nel computer di sviluppo. Gli elementi devono essere reimportati e rielaborati in caso di modifica. Questo processo può essere eseguito una sola volta, salvato in un server della cache e quindi condiviso con altri sviluppatori per risparmiare tempo, anziché ogni sviluppatore che elabora l'importazione di nuove modifiche in locale.

Dopo aver indirizzato le modifiche di rilievo risultanti dal passaggio alla versione aggiornata di Unity, compilare e testare le applicazioni correnti in HoloLens (prima generazione). In questa fase è anche opportuno creare e salvare un commit per il controllo del codice sorgente.

Compilare dipendenze/plug-in per il processore ARM

HoloLens (prima generazione) esegue applicazioni su un processore x86; il HoloLens 2 usa un processore ARM. Le applicazioni HoloLens esistenti devono essere convertite per supportare ARM. Come indicato in precedenza, Unity 2018 LTS supporta la compilazione di app ARM32 mentre Unity 2019 e versioni successive supporta la compilazione di app ARM32 e ARM64. Lo sviluppo per le applicazioni ARM64 è preferibile perché esiste una differenza sostanziale nelle prestazioni. Tuttavia, in questo modo è necessario creare tutte le dipendenze da plug-in anche per ARM64.

Esamina tutte le dipendenze da DLL dell'applicazione. È consigliabile rimuovere le dipendenze che non sono più necessarie per il progetto. Per i plug-in rimanenti che sono necessari, inserisci i rispettivi file binari ARM32 o ARM64 nel progetto Unity.

Dopo l'inserimento delle DLL pertinenti, compilare una soluzione di Visual Studio da Unity e compilare un'istanza di AppX per ARM in Visual Studio per verificare che l'applicazione possa essere compilata per i processori ARM. È consigliabile salvare l'applicazione come commit nella soluzione di controllo del codice sorgente.

Importante

Le applicazioni che usano MRTK v1 possono essere eseguite in HoloLens 2 dopo aver modificato la destinazione di compilazione in ARM, presupponendo che siano soddisfatti tutti gli altri requisiti. inclusa la presenza di versioni ARM di tutti i plug-in. Tuttavia, l'app non avrà accesso a funzioni specifiche di HoloLens 2, ad esempio la mano articolata e il tracciamento oculare. MRTK v1 e MRTK v2 hanno spazi dei nomi diversi che consentono di mantenere entrambe le versioni nello stesso progetto, meccanismo utile per la transizione da una versione all'altra.

Eseguire l'aggiornamento a MRTK versione 2

MRTK versione 2 è il nuovo toolkit che controlla Unity e che supporta sia HoloLens (prima generazione) che HoloLens 2. In questo toolkit sono state aggiunte tutte le nuove funzionalità di HoloLens 2, ad esempio le interazioni con le mani e il tracciamento oculare.

Per altre informazioni sull'uso di MRTK versione 2, vedere le risorse seguenti:

Preparare la migrazione

Prima di inserire i nuovi file *.unitypackage per MRTK v2, è consigliabile eseguire un inventario di (1) qualsiasi codice personalizzato integrato con MRTK v1 e (2) qualsiasi codice personalizzato per le interazioni di input o i componenti dell'esperienza utente. L'impegno maggiore per uno sviluppatore di realtà mista che inserisce il toolkit MRTK v2 è relativo all'input e alle interazioni. È consigliabile esaminare il modello di input MRTK v2.

Infine, il nuovo toolkit MRTK v2 è passato da un modello di script e di oggetti di gestione in scena a un'architettura di provider di servizi e configurazione. Ne deriva un modello di architettura e gerarchia di scene più chiaro, ma anche l'esigenza di una curva di apprendimento per comprendere i nuovi profili di configurazione. Leggere la guida alla configurazione di Realtà mista Toolkit per iniziare a acquisire familiarità con le impostazioni e i profili importanti che è necessario modificare in base alle esigenze dell'applicazione.

Migrazione del progetto

Dopo l'importazione di MRTK v2, il progetto Unity conterrà probabilmente molti errori relativi al compilatore. Questi sono comuni a causa della nuova struttura dello spazio dei nomi e dei nomi dei componenti. Continuare a risolvere questi errori modificando gli script nei nuovi spazi dei nomi e componenti.

Per informazioni sulle differenze di API specifiche tra HTK/MRTK e MRTK v2, vedi la guida di conversione nella wiki di MRTK versione 2.

Procedure consigliate

Assegnare priorità allo shader standard MRTK.
Lavorare su un tipo di modifica che causa un'interruzione alla volta ,ad esempio IFocusable to IMixedRealityFocusHandler.
Esegui il test dopo ogni modifica e usa il controllo del codice sorgente.
Quando possibile, usare l'esperienza utente MRTK predefinita (pulsanti, slate e così via).
Evita di modificare direttamente i file MRTK e crea invece wrapper intorno ai componenti MRTK.
- Questa azione semplifica l'inserimento e gli aggiornamenti futuri di MRTK.
Esamina ed esplora le scene di esempio fornite in MRTK (soprattutto HandInteractionExamples.scene).
Ricrea l'interfaccia utente basata su aree di disegno con quadrilateri, collisori e testo TextMeshPro.
Abilita condivisione buffer di profondità o imposta il punto di messa a fuoco; per prestazioni migliori, usare un buffer di profondità a 16 bit. Assicurarsi che quando si esegue il rendering del colore, viene eseguito anche il rendering della profondità. Unity in genere non scrive la profondità per oggetti gioco trasparenti e di testo.
Selezionare Rendering a istanza singola.
Usare il profilo di configurazione di HoloLens 2 per MRTK.

Controllo dell'applicazione

In MRTK versione 2 è possibile simulare le interazioni con le mani direttamente in Unity e sviluppare con le nuove API le interazioni con le mani e il tracciamento oculare. Il dispositivo HoloLens 2 è necessario per creare un'esperienza utente soddisfacente. È consigliabile studiare la documentazione e gli strumenti per una maggiore comprensione. MRTK v2 supporta lo sviluppo in HoloLens (prima generazione) e i modelli di input tradizionali come "select via air-tap" possono essere testati in HoloLens (prima generazione).

Aggiornamento del modello di interazione per HoloLens 2

Attenzione

Se il progetto usa una delle XR. Le API WSA, si noti che queste vengono eliminate gradualmente a favore delle nuove API di input XR di Unity nelle versioni future di Unity. Altre informazioni sulle API di input XR sono disponibili qui.

Dopo aver convertito e preparato l'applicazione per HoloLens 2, puoi iniziare a prendere in considerazione l'aggiornamento del modello di interazione del posizionamento degli ologrammi. In HoloLens (prima generazione) è probabile che l'applicazione abbia un modello di interazione basato sullo sguardo fisso e il commit, con ologrammi relativamente lontani per rientrare nel campo di visualizzazione.

Per aggiornare la progettazione dell'applicazione in modo che sia più adatta alle HoloLens 2:

Componenti MRTK: per le operazioni preliminari, se hai aggiunto MRTK v2, sono disponibili diversi componenti/script progettati e ottimizzati per HoloLens 2.
Modello di interazione: valuta l'opportunità di aggiornare il modello di interazione. Per la maggior parte degli scenari, è consigliabile passare dallo sguardo fisso e dal commit alle mani. Alcuni degli ologrammi potrebbero essere fuori portata del braccio e passare alle mani comportano un'interazione molto più lunga puntando i raggi e afferrando i movimenti.
Posizionamento dell'ologramma: dopo aver eseguito il passaggio a un modello di interazione con le mani, è consigliabile spostare alcuni ologrammi più vicini in modo che gli utenti possano interagire direttamente con loro usando movimenti di afferramento di interazione quasi con le mani. I tipi di ologrammi da avvicinare direttamente all'afferramento o all'interazione con sono:

menu di destinazione piccoli
controls
pulsanti
ologrammi più piccoli che, quando afferrati e controllati, si adattano all'interno del HoloLens 2 campo di visualizzazione.

Le applicazioni e gli scenari variano; continueremo a perfezionare e pubblicare le linee guida per la progettazione in base al feedback e alle formazione continue.

Suggerimenti aggiuntivi sullo spostamento di applicazioni da x86 ad ARM

Le applicazioni Unity semplici sono semplici perché è possibile creare un bundle di applicazioni ARM o distribuirlo direttamente nel dispositivo per l'esecuzione del bundle. Alcuni plug-in nativi di Unity possono presentare specifici problemi di sviluppo. Per questo motivo, è necessario aggiornare tutti i plug-in nativi di Unity a Visual Studio 2019 e quindi rieseguire la compilazione per ARM.
Un'applicazione ha usato il plug-in Unity AudioKinetic Wwise. La versione di Unity in uso non ha avuto un plug-in ARM UWP e c'è stato un notevole sforzo per rielaborare le funzionalità audio nell'applicazione in questione per l'esecuzione su ARM. Assicurati che tutti i plug-in necessari per i tuoi piani di sviluppo siano installati e disponibili in Unity.
In alcuni casi, tra i plug-in richiesti dall'applicazione potrebbe non esistere un plug-in ARM/UWP, il che impedisce la possibilità di convertirla ed eseguirla in HoloLens 2. Contatta il provider di plug-in per risolvere il problema e fornire il supporto per ARM.
I valori minfloat (e varianti come min16float, minint e così via) negli shader possono avere un comportamento diverso in HoloLens 2 rispetto a HoloLens (prima generazione). In particolare, garantiscono che venga usato almeno il numero specificato di bit. Nelle GPU Intel/Nvidia i valori minfloat vengono considerati per lo più come 32 bit. In ARM il numero di bit specificato viene effettivamente rispettato. In pratica, questi numeri potrebbero avere una precisione o un intervallo minore su HoloLens 2 rispetto a quanto fatto in HoloLens (prima generazione).
Le istruzioni _asm non sembrano funzionare in ARM, pertanto il codice con istruzioni _asm deve essere riscritto.
ARM non supporta il set di istruzioni SIMD perché varie intestazioni, ad esempio xmmintrin.h, emmintrin.h, tmmintrin.h e immintrin.h, non sono disponibili in ARM.
Il compilatore dello shader in ARM viene eseguito durante la prima chiamata di disegno dopo il caricamento dello shader o dopo che è cambiato qualcosa su cui si basa lo shader, non in fase di caricamento dello shader. L'impatto sulla frequenza dei fotogrammi può essere evidente, a seconda del numero di shader da compilare, con implicazioni per la gestione, il pacchetto e l'aggiornamento degli shader in modo diverso in HoloLens 2 vs HoloLens (prima generazione).