Triky trvalosti
Trvalost je dostupná v případě, že je podporována základní platformou. V současné době je to omezené na řadu zařízení HoloLens pomocí integrované podpory VR Unity (Starší verze XR).
Základní trvalost
Základní trvalost nástrojů World Locking Tools je ve výchozím nastavení povolená. Povolení se skládá ze dvou částí.
Příslušná zaškrtávací políčka jsou zaškrtnutá políčka Automatické načtení a Automatické ukládání. Možná si všimnete, že jsou šedě. Je to proto, že jsou součástí volby Použít výchozí hodnoty. Zakázáním možnosti Použít výchozí hodnoty povolíte výběr libovolných kombinací možností automatizace.
Další čtení je k dispozici v těchto nastaveních a manipulaci s nimi ze skriptu.
AutoSave
Možnost automatického ukládání směruje WLT, aby se při spouštění aplikace často a pravidelně ukládal. Kdykoli může být aplikace ukončena s minimální ztrátou stavu.
Automatické načítání
Možnost Automatické načtení směruje WLT k načtení jakéhokoli dříve uloženého stavu při spuštění. To umožňuje aplikaci obnovit novou relaci, ve které přestala (w.r.t. WLT) z poslední relace.
Úplná trvalost
S povoleným automatickým ukládáním i automatickým načítáním funguje WLT bezproblémově napříč relacemi. Zatímco pozice a orientace globálního prostoru jsou při prvním spuštění libovolné (protože se neukládá žádný předchozí stav, používá hlavní pozici při spuštění jako zdroj), následná spuštění budou sdílet stejný souřadnicový rámec.
To vede k zajímavému chování při spuštění nové relace v prostoru odpojeném od prostoru předchozí relace. Podrobnosti najdete v části Trvalost podle umístění níže.
Poznámka:
Nastavení automatického ukládání a automatického načítání platí také pro globální mezerník. Podrobnosti najdete níže .
Řízení aplikace nad trvalostí
Výchozí úplná trvalost je vhodná pro širokou škálu aplikací.
Některé aplikace ale můžou chtít jemně řídit proces.
Může se zdát divné, že povolení automatické trvalosti WLT je rozdělené na dvě vlastnosti, automatické ukládání a automatické načítání. Zkoumání případů, kdy se oba používají nezávisle, mohou poskytnout přehled o celkové trvalosti systému.
Automatické ukládání, ale ne automatické načítání
Při této konfiguraci je WLT nastavený tak, aby pravidelně ukládal svůj stav. Při spuštění se ale automaticky nenačte žádný trvalý stav.
Systém se místo toho spustí v novém stavu, jako by se na tomto zařízení poprvé spustil. Až po explicitním požadavku na Load() obnoví stav předchozí relace.
Aplikace tak může rozhodnout, zda by bylo vhodné obnovit předchozí stav relace, a dokonce i upravit data, která se obnovují v případě potřeby.
Obecný stav ukládání WLT je v souboru LocalState/frozenWorldState.hkfw. Po vytvoření WLT lze tento soubor zkopírovat do jiného umístění a obnovit zpět podle vlastního uvážení aplikace.
V souboru pro zarovnání (SpacePin) se ve výchozím nastavení nastaví hodnota LocalState/Persistence/Alignment.fwb. To však může aplikace přepsat prostřednictvím správce zarovnání SaveFileName.
Při spuštění se musí provést rozhodnutí načíst stav předchozí relace s touto konfigurací. Po spuštění uloženého stavu předchozí relace se přepíše stav této relace. Flexibilnější nastavení najdete v části Ruční uložení a načtení níže.
Ruční uložení, ale automatické načítání
V této konfiguraci načte WLT libovolný dostupný stav z předchozí relace při spuštění. Stav se ale automaticky neuloží. To umožňuje aplikaci rozhodnout, jestli a kdy stojí za uložení stavu, s voláním Save().
Automatické načítání říká WLT, aby při spuštění načetl libovolný dostupný stav. Aplikace je zdarma obnovit libovolný uložený stav kdykoli s explicitním voláním Load().
Ruční uložení a načtení
Aplikace se může rozhodnout zachovat úplnou kontrolu nad procesem ukládání a načítání.
Stav se pak uloží pouze s explicitním voláním z aplikace na Save() a načte se pouze explicitním voláním Load().
Stav načtený voláním load() mohl být uložen dříve v této relaci nebo v předchozí relaci.
Zakázání trvalosti
Jak je vysvětleno výše, trvalost je vždy k dispozici pro aplikaci ze skriptu. Automatická trvalost může být povolena a zakázána ze skriptu nebo prostřednictvím WorldLockingContext v inspektoru. Pokud je automatizovaná trvalost zakázaná, WLT se nebude pokoušet o uložení nebo načtení stavu bez explicitních požadavků z aplikace.
Vzhledem k tomu, že direktiva Automatické načítání má vliv pouze na to, zda se má načíst nebo ne při spuštění, změna hodnoty skriptu po spuštění nemá žádný vliv.
Upozornění při vývoji
Jak je uvedeno výše, umístění souborů ukládání pro globální WLT a zarovnání jsou globální pro aplikaci. Zejména uzly zarovnání, označované také jako SpacePins, se uchovávají podle názvu (viz níže). Pokud aplikace uloží stav se sadou SpacePins z jedné scény a pak načte stav se sadou SpacePins z jiné scény a obě sady SpacePins sdílejí společné názvy, chování není definováno.
Tento problém se dá obejít několika způsoby. Pokud je to možné, nejlepší je jednoduše se vyhnout opakovanému nasazení názvů SpacePin v rámci projektu. Pokud se po opětovném nasazení zobrazí neočekávané chování při posuvné scéně, zkuste odstranit stav uložení WLT. Stejně tak při zásadní změně aplikace může příliš opatrný chtít buď odstranit své soubory WLT uložit ze zařízení, nebo jednoduše odinstalovat aplikaci před instalací nové verze.
Trvalost podle umístění
Scénář
Existuje zajímavá třída aplikací, které se spouští v několika fyzických umístěních. Aplikace může běžet v místnosti A, zařízení je zavřené, přemísťované a potom se aplikace restartuje v místnosti B. Místnost B může být mimo chodbu z místnosti A nebo může být na jiném kontinentu. Aplikace a zařízení nemají žádný způsob, jak vědět.
Pro zjednodušení řekněme, že aplikace je nakonfigurovaná pro ruční trvalost WLT.
Názorný postup
Zvažte tyto nepřipojené místnosti A a B.
Aplikace se spustí v místnosti A. Po vytvoření souvislého ukotveného souřadnicového prostoru v místnosti se celá místnost mapuje na fragment 1. Trvalý hologram Objekt X je umístěn v místnosti. Aplikace pak uloží stav a ukončí se.
Zařízení je vypnuté, převezné do místnosti B a znovu se spustilo.
Zařízení rozpozná, že to není místnost A, takže WLT přiřadí k jeho obsahu nové ID fragmentu, například ID == 29. Proč 29? Protože to není 1. ID fragmentů jsou libovolná v hodnotě, jiné než ID jednoho fragmentu nebude FragmentId.Invalid nebo FragmentId.Unknown nebo stejné jako jakýkoli jiný známý fragment.
Teď existují dva fragmenty a není možné je sloučit (protože v jejich relativních umístěních nejsou k dispozici žádné informace).
Vývojář aplikace, který vás zajímá, se může zeptat: Umístil(a) jsem trvalý objekt X do místnosti A, co se stane, když se při spuštění aplikace v místnosti B načte objekt X?
Odpovědí je, že chování zůstává vývojáři aplikace, aby ho určil. Aktuální ID fragmentu, když je objekt X umístěn v místnosti A je k dispozici a lze jej zachovat. Aplikace se pak může rozhodnout při spuštění, zda se má objekt X zobrazit, nebo ne na základě toho, jestli je aktuální fragment stejný jako při jeho vytvoření nebo ne.
V této části se vývojář rozhodne (a implementuje), že objekt X se načte pouze v případě, že aktuální ID fragmentu je jedno a objekt Y z místnosti B bude načten pouze v případě, že aktuální fragment je 29.
Trvalost ID fragmentu přidruženého k prostoru se uloží jako součást trvalosti nástrojů World Locking Tools. Trvalost ID fragmentu přidruženého k objektu a akce, které se na něm mají provést, však zůstanou v aplikaci.
Spolu s PŘIDRUŽENÝm ID fragmentu objektu je možné uložit jeho pozici v globálním prostoru. Pokud se ID fragmentu shoduje, po načtení objektu může být obnovena jeho pozice ve fyzickém světě během poslední relace. Díky trvalosti nástrojů World Locking Tools zůstává pozice pevná napříč relacemi vzhledem k fyzickým prvkům světa kolem ní.
Trvalost mezerníků
SpacePins lze považovat za obálky na straně aplikace pro AlignmentAnchors. vzhledem k tomu, že SpacePins (a odvozené třídy) jsou součásti Unity, AlignmentAnchors jsou čistě koncepční; neexistuje žádná třída nebo typ odpovídající AlignmentAnchor. Proto v této diskuzi se SpacePins a AlignmentAnchors budou používat zaměnitelně s obecnou předvolbou Pro SpacePins.
Jinak ale může být matoucí, že Objekt AlignmentManager může zachovat Mezerník, pokud nemá žádný pojem SpacePins. Důvodem je to, že AlignmentManager spravuje koncepční AlignmentAnchor, který vtělí podstatu SpacePin, a ze kterého lze SpacePin rekonstituovat.
Existuje více ovládacích prvků na úrovni aplikace pro trvalost SpacePins než u obecného systému trvalosti WLT, protože SpacePins jsou ze své podstaty řízeny vstupem aplikace než zbytek nástrojů World Locking Tools.
Je důležité si uvědomit, že SpacePins (a AlignmentAnchors) jsou trvalé podle názvu. Jedná se o mírně silnější požadavek než obecný požadavek, že žádné dva aktivní SpacePins ve stejné IAlignmentManager mají stejný název. Pokud se funkce SpacePins zachovají, žádné dva spacepiny ve stejné databázi můžou mít stejný název, ať už aktivní, nebo ne.
Databáze Správce zarovnání
Každý IAlignmentManager má databázi SpacePins podle názvu, jak vyplývá z jeho implementace RestoreAlignmentAnchor(string uniqueName, Pose virtualPose).
Globální databáze zarovnání
Existuje jeden globální IAlignmentManager vlastněný WorldLockingManager.GetInstance(). Jak už bylo zmíněno, výchozí umístění souboru pro ukládání je určeno vlastností SaveFileName. Všimněte si, že SaveFileName je vlastnost třídy AlignmentManager, nikoli rozhraní IAlignmentManager. Implementace IAlignmentManager může implementovat trvalost bez jakéhokoli konceptu souborů nebo názvů souborů. SaveFileName je artefaktem způsobu, jakým AlignmentManager implementuje trvalost, a proto je omezena na AlignmentManager.
Místní databáze zarovnání
Může existovat libovolný počet správců zarovnání dílčích mezer, jeden pro každý AlignSubtree, který se zobrazí jako pole AlignSubtree.alignmentManager. Kromě toho může aplikace vytvořit své vlastní AlignmentManager instance, nebo dokonce své vlastní třídy odvozené z IAlignmentManager.
Objekt AlignSubtree komponenty AlignmentManager má vlastní umístění souboru pro ukládání, které má výchozí název GameObjectu s příponou .fwb. Pokud je například komponenta AlignSubtree na Objektu GameObject s názvem "MyRoot", bude soubor pro uložení pojmenován "MyRoot.fwb". Lomítko /lze použít k jeho umístění do podsložky. Pravděpodobně by bylo špatné, aby dvě komponenty AlignSubtree používaly stejné umístění souboru pro ukládání.
Ale opravdu
Důrazně se doporučuje, aby v dlouhodobém horizontu bylo jednodušší a robustnější dát SpacePins/AlignmentAnchors globálně jedinečné názvy, než se pokusit spravovat světlejší místně jedinečný požadavek. Ale udělej to, co se ti líbí.