Suggerimenti per la persistenza
La persistenza è disponibile in cui è supportato dalla piattaforma sottostante. Attualmente, questo è limitato alla famiglia di dispositivi HoloLens, usando il supporto VR predefinito di Unity (Legacy XR).
Persistenza di base
La persistenza di base per Gli strumenti di blocco mondiale è abilitata per impostazione predefinita. Questa abilitazione viene fornita in due parti.
Le caselle di controllo pertinenti sono la casella di controllo "Caricamento automatico" e "Salvataggio automatico", selezionata. Potresti notare che sono disattivati. Ciò è dovuto al fatto che fanno parte della scelta "Usa impostazioni predefinite". La disabilitazione di "Usa impostazioni predefinite" consente la selezione di combinazioni arbitrarie delle opzioni di Automazione.
Altre letture sono disponibili su queste impostazioni e sulla modifica dello script.
AutoSave
L'opzione AutoSave indirizza WLT per salvare lo stato frequente e regolare durante l'esecuzione dell'applicazione. In qualsiasi momento, l'applicazione può essere terminata con una perdita minima di stato.
AutoLoad
L'opzione Caricamento automatico indirizza WLT al caricamento di qualsiasi stato salvato in precedenza all'avvio. In questo modo l'applicazione può riprendere una nuova sessione in cui è stata interrotta (w.r.t. WLT) dall'ultima sessione.
Persistenza completa
Con AutoSave e AutoLoad abilitato, WLT funziona perfettamente tra le sessioni. Mentre la posizione e l'orientamento dello spazio globale sono arbitrarie nella prima esecuzione (poiché non è stato salvato alcun stato precedente, usa la posizione head all'avvio come origine), le esecuzioni successive condivideranno lo stesso frame di coordinate.
Ciò comporta un comportamento interessante quando l'applicazione avvia una nuova sessione in uno spazio disconnesso dallo spazio della sessione precedente. Per informazioni dettagliate, vedere la sezione relativa alla persistenza in base alla posizione .
Nota
Le impostazioni AutoSave e AutoLoad si applicano anche a SpacePins globali. Per informazioni dettagliate, vedere di seguito .
Controllo dell'applicazione sulla persistenza
La persistenza completa predefinita è adatta a un'ampia gamma di applicazioni.
Alcune applicazioni, tuttavia, potrebbero voler controllare in modo più corretto il processo.
Potrebbe sembrare strano che l'abilitazione della persistenza automatica WLT sia suddivisa in due proprietà, l'autoSave e il caricamento automatico. Esaminando i casi in cui i due vengono usati in modo indipendente potrebbero fornire informazioni dettagliate sul sistema di persistenza generale.
Salvataggio automatico ma non caricamento automatico
Con questa configurazione, WLT è impostato per salvare periodicamente lo stato. Tuttavia, non caricherà automaticamente alcun stato persistente all'avvio.
Invece, il sistema inizierà in uno stato nuovo, come se fosse la prima volta che viene eseguito in questo dispositivo. Solo dopo una richiesta esplicita a Load() ripristina lo stato della sessione precedente.
Ciò consente all'applicazione di decidere se ripristinare lo stato della sessione precedente sarebbe appropriato e anche per modificare i dati ripristinati, se necessario.
Lo stato di salvataggio WLT generale è nel file "LocalState/frozenWorldState.hkfw". Una volta creato da WLT, tale file può essere copiato in un'altra posizione e ripristinato a discrezione dell'applicazione.
Il file di salvataggio per i dati di allineamento (SpacePin) è predefinito "LocalState/Persistence/Alignment.fwb". Tuttavia, può essere sottoposto a override dall'applicazione tramite SaveFileName di Gestione allineamento.
La decisione di caricare lo stato della sessione precedente con questa configurazione deve essere effettuata all'avvio. Dopo aver eseguito lo stato salvato della sessione precedente, verrà sovrascritto con lo stato di questa sessione. Per una configurazione più flessibile, vedere Salvataggio manuale e caricamento seguente.
Salvataggio manuale ma Caricamento automatico
In questa configurazione, WLT caricherà qualsiasi stato disponibile da una sessione precedente all'avvio. Non verrà tuttavia salvato automaticamente lo stato. Ciò consente all'applicazione di decidere se e quando lo stato vale la pena salvare, con una chiamata a Save().
Il caricamento automatico indica solo a WLT di caricare qualsiasi stato disponibile all'avvio. L'applicazione è gratuita per ripristinare qualsiasi stato salvato in qualsiasi momento con una chiamata esplicita a Load().
Salvataggio manuale e caricamento
L'applicazione può scegliere di mantenere il controllo totale sul processo di salvataggio e caricamento.
Lo stato verrà quindi salvato solo con una chiamata esplicita dall'applicazione a Save() e caricata solo con una chiamata esplicita a Load().
Lo stato caricato dalla chiamata a Load() potrebbe essere stato salvato in precedenza in questa sessione o in una sessione precedente.
Disabilitazione della persistenza
Come illustrato in precedenza, la persistenza è sempre disponibile per l'applicazione dallo script. La persistenza automatizzata può essere abilitata e disabilitata dallo script o tramite WorldLockingContext nel controllo. Se la persistenza automatica è disabilitata, WLT non tenterà di salvare o caricare lo stato senza richieste esplicite dall'applicazione.
Naturalmente, poiché la direttiva AutoLoad influisce solo sul caricamento o meno all'avvio, la modifica del valore da script dopo l'avvio non ha alcun effetto.
Attenzione durante lo sviluppo
Come indicato in precedenza, il percorso dei file di salvataggio per WLT globale e l'allineamento sono globali per l'applicazione. In particolare, i nodi di allineamento, noti anche come SpacePins, sono persistenti in base al nome (vedere di seguito). Se un'applicazione salva lo stato con un set di SpacePins da una scena e quindi carica lo stato con un set di SpacePins da un'altra scena e entrambi i set di SpacePins condividono nomi comuni, il comportamento non è definito.
Esistono diversi modi per risolvere questo problema. Se possibile, è consigliabile evitare semplicemente di riutilizzare i nomi di SpacePin all'interno di un progetto. Se dopo la ri-distribuzione, viene visualizzato un comportamento imprevisto di scorrimento della scena, provare a eliminare lo stato di salvataggio WLT. Analogamente, quando si modifica radicalmente l'applicazione, la cautela eccessivamente cauta potrebbe voler eliminare i file WLT dal dispositivo o semplicemente disinstallare l'applicazione prima di installare la nuova versione.
Persistenza in base alla posizione
Scenario
Esiste una classe interessante di applicazioni eseguite in più posizioni fisiche. L'applicazione potrebbe essere eseguita in Room A, il dispositivo chiuso, spostato e quindi l'applicazione riavviata in Room B. Room B potrebbe essere giù dalla sala A o potrebbe essere in un altro continente. L'applicazione e il dispositivo non hanno modo di sapere.
Per semplicità, si supponga che l'applicazione sia configurata per la persistenza manuale WLT.
Procedura dettagliata
Prendere in considerazione queste camere non connesse A e B.
L'applicazione viene avviata in Room A. Dopo aver stabilito uno spazio di coordinate congelato contiguo all'interno della stanza, l'intera stanza mappa al frammento 1. Un ologramma persistente Object X viene posizionato nella stanza. L'applicazione salva quindi lo stato e viene interrotto.
Il dispositivo viene spento, portato in Room B e avviato di nuovo.
Il dispositivo riconosce che non è Room A, quindi WLT assegna un nuovo ID frammento al relativo contenuto, ad esempio ID == 29. Perché 29? Perché non è 1. Gli ID frammento sono arbitrari in valore, diverso dall'ID di un frammento non sarà FragmentId.Invalid o FragmentId.Unknown o uguale a qualsiasi altro frammento noto.
Ora sono presenti due frammenti e non è possibile unire tali frammenti (poiché non sono disponibili informazioni sulle posizioni relative).
Lo sviluppatore di applicazioni interessate potrebbe chiedere: ho inserito un oggetto X persistente in Room A, cosa accade quando l'oggetto X viene caricato quando l'applicazione viene avviata in Room B?
La risposta è che il comportamento viene lasciato allo sviluppatore dell'applicazione per determinare. L'ID frammento corrente quando l'oggetto X viene posizionato in Room A è disponibile e può essere mantenuto. L'applicazione può quindi decidere all'avvio se visualizzare Object X o meno in base al fatto che il frammento corrente sia uguale a quando è stato creato o meno.
In questo caso, lo sviluppatore decide (e implementa) che Object X verrà caricato solo se l'ID frammento corrente è uno e Object Y, da Room B, verrà caricato solo se il frammento corrente è 29.
La persistenza dell'ID frammento associato a uno spazio viene salvata come parte della persistenza degli strumenti di blocco mondiale. Tuttavia, la persistenza dell'ID frammento associato a un oggetto, nonché le azioni da eseguire in base a essa, vengono lasciate all'applicazione.
Insieme all'ID frammento associato dell'oggetto, è possibile salvare la relativa posizione nello spazio globale. Se l'ID frammento corrisponde, dopo che l'oggetto viene caricato può essere ripristinato, tornare alla sua posizione nel mondo fisico durante l'ultima sessione. Con la persistenza degli strumenti di blocco mondiale, una posa rimane fissa tra le sessioni rispetto alle funzionalità fisiche intorno a esso.
Persistenza di SpacePins
SpacePins può essere considerato come wrapper lato applicazione per AlignmentAnchors. Mentre SpacePins (e classi derivate) sono componenti Unity, AlignmentAnchors sono puramente concettuali; non esiste una classe o un tipo corrispondente a un AlignmentAnchor. Pertanto, in questa discussione, SpacePins e AlignmentAnchors verranno usati in modo intercambiabile, con una preferenza generale per SpacePins.
Tuttavia, potrebbe in caso contrario essere confuso che un AlignmentManager può rendere persistenti SpacePins, quando non ha alcuna nozione di SpacePins. Questo è dovuto al fatto che AlignmentManager gestisce l'elemento concettuale AlignmentAnchor, che rappresenta l'essenza di uno SpacePin e da cui è possibile ricostituire un Oggetto SpacePin.
Esistono più controlli a livello di applicazione per la persistenza di SpacePins rispetto al sistema di persistenza WLT generale, perché SpacePins è intrinsecamente più guidato dall'input dell'applicazione rispetto al resto degli strumenti di blocco mondiale.
È importante ricordare che SpacePins (e AlignmentAnchors) sono persistenti in base al nome. Si tratta di un requisito leggermente più forte rispetto a quello generale che nessuna di due Puntini spaziali attivi nello stesso IAlignmentManager ha lo stesso nome. Se si mantiene SpacePins, non è possibile che due Puntini di spazio nello stesso database abbiano lo stesso nome, indipendentemente dal fatto che sia attivo o meno.
Database di gestione allineamento
Ogni IAlignmentManager ha un database di SpacePins in base al nome, come implicito nell'implementazione di RestoreAlignmentAnchor(string uniqueName, Pose virtualPose).
Database di allineamento globale
Esiste un IAlignmentManager globale, di proprietà di WorldLockingManager.GetInstance(). Come accennato, il percorso predefinito del file di salvataggio è determinato dalla proprietà SaveFileName. Si noti che SaveFileName è una proprietà sulla classe AlignmentManager, non sull'interfaccia IAlignmentManager. Un'implementazione di IAlignmentManager può implementare la persistenza senza alcun concetto di file o file. SaveFileName è un artefatto del modo in cui AlignmentManager implementa la persistenza e quindi è limitato a AlignmentManager.
Database di allineamento locale
Può essere presente un numero qualsiasi di gestori di allineamento dello spazio secondario, uno per ogni AlignSubtree, visualizzato come campo AlignSubtree.alignManager. Inoltre, l'applicazione può creare le proprie istanze di AlignmentManager o anche le proprie classi derivate da IAlignmentManager.
Ogni componente AlignSubtree ha il proprio percorso di salvataggio del file, che viene predefinito per il nome di GameObject, con l'estensione ".fwb". Ad esempio, se il componente AlignSubtree si trova in un GameObject denominato "MyRoot", il file di salvataggio sarà denominato "MyRoot.fwb". Una barra in avanti '/' può essere usata per inserirla in una sottocartella. Probabilmente sarebbe male per due componenti AlignSubtree per usare la stessa posizione del file di salvataggio.
Ma davvero
È fortemente consigliabile che, a lungo termine, è più semplice e più affidabile fornire nomi univoci spacePins/AlignmentAnchors a livello globale, che per provare a gestire il requisito univoco locale più chiaro. Ma fai quello che ti piace.