Conversione di app HoloLens (prima generazione) in HoloLens 2

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	Step 2	Step 3	Step 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 uno snapshot dello stato originale dell'applicazione prima di avviare il processo di conversione. È anche consigliabile salvare gli stati del checkpoint in diversi 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.

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 esistenti 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 ribadire, il back-end di scripting .NET è deprecato in Unity 2018 e rimosso a partire da Unity 2019. È consigliabile impostare il progetto su IL2CPP.

Dopo aver indirizzato le modifiche che causano il 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; 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 aver inserito le 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.

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:

• MRTK - Home della documentazione
• Guida all'installazione
• MRTK - Tracciamento manuale
• MRTK - Tracciamento oculare

Prepararsi per 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 interazioni di input o componenti UX. 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 a 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.
• Abilitare la condivisione del buffer di profondità o impostare il punto di attivazione. Per ottenere prestazioni migliori, usare un buffer di profondità a 16 bit. Assicurarsi che quando si esegue il rendering del colore, si esegue 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.

Test 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

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 per HoloLens 2:

1. Componenti MRTK: per il pre-lavoro, se è stato aggiunto MRTK v2, sono disponibili vari componenti/script da sfruttare che sono stati progettati e ottimizzati per HoloLens 2.
2. Modello di interazione: valutare la possibilità di aggiornare il modello di interazione. Per la maggior parte degli scenari, è consigliabile passare dallo sguardo fisso e dal commit alle mani. Alcuni ologrammi potrebbero essere fuori dalla portata del braccio e passare alle mani comportano raggi di interazione lontani e movimenti di afferramento.
3. Posizionamento dell'ologramma: dopo aver eseguito il passaggio a un modello di interazione delle mani, è consigliabile spostare alcuni ologrammi più vicini in modo che gli utenti possano interagire direttamente con loro usando i movimenti di afferramento near-interaction con le mani. I tipi di ologrammi da avvicinare direttamente o interagire con sono:

• menu di destinazione piccoli
• controlli
• pulsanti
• ologrammi più piccoli che, quando afferrati e controllati, rientrano nel campo della visualizzazione holoLens 2.

Le applicazioni e gli scenari variano; continueremo a perfezionare e pubblicare le linee guida per la progettazione in base al feedback e agli apprendimento continui.

Suggerimenti aggiuntivi sullo spostamento di applicazioni da x86 ad ARM

• Le applicazioni Unity semplici sono semplici perché è possibile compilare 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 usa il plug-in Unity AudioKinetic Wwise. La versione di Unity in uso non ha 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 inferiore in 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 il modo in cui gli shader devono essere gestiti, inseriti in un pacchetto e aggiornati in modo diverso in HoloLens 2 e HoloLens (prima generazione).

Vedi anche

• Installa gli strumenti
• MRTK - Guida all'installazione
• MRTK - Home della documentazione
• Conversione da HoloToolkit/MRTK a MRTK versione 2
• Impostazioni consigliate per Unity
• Informazioni sulle prestazioni per la realtà mista