Beständighetstricks
Beständighet är tillgängligt där det stöds av den underliggande plattformen. För närvarande är detta begränsat till HoloLens-serien med enheter med hjälp av Unitys inbyggda VR-stöd (Legacy XR).
Grundläggande beständighet
Grundläggande beständighet för World Locking Tools är aktiverat som standard. Den här aktiveringen finns i två delar.
De relevanta kryssrutorna här är "Automatisk inläsning" och "Spara automatiskt", som är markerade. Du kanske märker att de är nedtonade. Det beror på att de ingår i valet "Använd standardvärden". Om du inaktiverar "Använd standardvärden" kan du välja godtyckliga kombinationer av Automation-alternativen.
Ytterligare läsning finns i de här inställningarna och om hur du manipulerar dem från skript.
AutoSave
Alternativet Spara automatiskt dirigerar WLT till att göra frekventa och regelbundna tillståndssparningar när programmet körs. Programmet kan när som helst avslutas med minimal tillståndsförlust.
Ladda automatiskt
Alternativet Automatisk inläsning uppmanar WLT att läsa in alla tidigare sparade tillstånd vid start. På så sätt kan programmet återuppta en ny session där den slutade (w.r.t. WLT) från den senaste sessionen.
Fullständig beständighet
Med både AutoSpara och Autoload aktiverat fungerar WLT sömlöst mellan sessioner. Även om positionen och orienteringen för det globala utrymmet är godtyckliga vid den första körningen (eftersom det inte finns något tidigare tillstånd sparat använder det huvudpositionen vid start som ursprung), men efterföljande körningar delar samma koordinatram.
Detta leder till intressant beteende när programmet startar en ny session i ett utrymme som är frånkopplat från föregående session. Mer information finns i avsnittet beständighet efter plats nedan.
Kommentar
Inställningarna Spara automatiskt och läs in automatiskt gäller även för globala SpacePins. Mer information finns nedan .
Programkontroll över beständighet
Den fullständiga standardpersistenceen är lämplig för ett brett spektrum av program.
Vissa program kanske dock vill ha bättre kontroll över processen.
Det kan verka konstigt att aktivera automatisk beständighet för WLT delas in i två egenskaper, AutoSpara och Autoload. Att undersöka fall där de två används oberoende av varandra kan ge insikter om det övergripande beständighetssystemet.
Spara automatiskt men inte ladda automatiskt
Med den här konfigurationen är WLT inställt på att regelbundet spara sitt tillstånd. Den läser dock inte in något beständiga tillstånd automatiskt vid start.
Systemet startar i stället i ett nytt tillstånd, som om det är första gången som det körs på den här enheten. Först efter en explicit begäran till Load() återställs den föregående sessionens tillstånd.
Detta gör det möjligt för programmet att avgöra om det är lämpligt att återställa föregående sessionstillstånd eller inte, och till och med att ändra de data som återställs om det behövs.
Det allmänna WLT-sparandetillståndet finns i filen "LocalState/frozenWorldState.hkfw". När filen har skapats av WLT kan den kopieras till en annan plats och återställas efter programmets gottfinnande.
Spara-filen för justeringsdata (SpacePin) är som standard "LocalState/Persistence/Alignment.fwb". Det kan dock åsidosättas av programmet via justeringshanterarens SaveFileName.
Beslutet att läsa in den föregående sessionens tillstånd med den här konfigurationen måste fattas vid start. När du kör den tidigare sessionens sparade tillstånd skrivs det över med den här sessionens tillstånd. En mer flexibel konfiguration finns i Manuell spara och läsa in nedan.
Spara manuellt men läs in automatiskt
I den här konfigurationen läser WLT in alla tillgängliga tillstånd från en tidigare session vid start. Det sparar dock inte automatiskt tillstånd. På så sätt kan programmet avgöra om och när tillståndet är värt att spara, med ett anrop till Save().
Autoload säger bara till WLT att läsa in alla tillgängliga tillstånd vid start. Programmet kan när som helst återställa alla sparade tillstånd med ett explicit anrop till Load().
Spara och läs in manuellt
Programmet kan välja att behålla total kontroll över spara och läsa in processen.
Tillståndet sparas sedan endast med ett explicit anrop från programmet till Save(), och läses bara in med ett explicit anrop till Load().
Tillståndet som lästes in av anropet till Load() kan ha sparats tidigare i den här sessionen eller i en tidigare session.
Inaktivera beständighet
Som beskrivs ovan är beständighet alltid tillgängligt för programmet från skriptet. Automatisk beständighet kan aktiveras och inaktiveras från skript eller via WorldLockingContext i Inspector. Om automatiserad beständighet är inaktiverad gör WLT inga försök att spara eller läsa in tillstånd utan explicita begäranden från programmet.
Eftersom AutoLoad-direktivet bara påverkar om du vill läsa in eller inte vid start har det naturligtvis ingen effekt att ändra värdet från skriptet efter start.
En varning under utvecklingen
Som nämnts ovan är platsen för spara filer för global WLT och justering global för programmet. I synnerhet sparas justeringsnoderna, även kallade SpacePins, efter namn (se nedan). Om ett program sparar tillstånd med en uppsättning SpacePins från en scen och sedan läser in tillstånd med en uppsättning SpacePins från en annan scen, och båda uppsättningarna SpacePins delar gemensamma namn, är beteendet odefinierat.
Det finns flera sätt att kringgå det här problemet. Om möjligt är det bästa att helt enkelt undvika att återanvända SpacePin-namn i ett projekt. Om du efter omdistributionen ser ett oväntat scenförskjutningsbeteende kan du prova att ta bort WLT-sparandetillståndet. På samma sätt kanske de alltför försiktiga när de ändrar programmet radikalt antingen vill ta bort sina WLT-spara filer från enheten eller helt enkelt avinstallera programmet innan du installerar den nya versionen.
Beständighet efter plats
Scenariot
Det finns en intressant klass med program som körs på flera fysiska platser. Programmet kan köras i rum A, enheten stängdes, flyttades och sedan startades programmet om i rum B. Rum B kan vara nere i hallen från rum A eller vara på en annan kontinent. Programmet och enheten har inget sätt att veta.
För enkelhetens skull ska vi säga att programmet har konfigurerats för manuell WLT-beständighet.
En genomgång
Överväg dessa oanslutna rum A och B.
Programmet startas i rum A. När du har upprättat ett sammanhängande fruset koordinatutrymme i rummet mappar hela rummet till fragment 1. Ett beständigt hologram objekt X placeras i rummet. Sedan sparar programmet tillståndet och avslutas.
Enheten är avstängd, förs till rum B och startas igen.
Enheten känner igen detta som inte rum A, så WLT tilldelar ett nytt fragment-ID till innehållet, till exempel ID == 29. Varför 29? Eftersom det inte är 1. Fragment-ID :t är godtyckliga i värde, andra än ett fragments ID är inte FragmentId.Invalid eller FragmentId.Unknown eller samma som andra kända fragment.
Nu finns det två fragment och inget sätt att sammanfoga dem (eftersom det inte finns någon tillgänglig information på deras relativa platser).
Den intresserade programutvecklaren kan fråga: Jag har placerat ett beständigt Objekt X i rum A, vad händer när Objekt X läses in när programmet startar i rum B?
Svaret är att beteendet är upp till programutvecklaren att avgöra. Det aktuella fragment-ID:t när objekt X placeras i rum A är tillgängligt och kan sparas. Programmet kan sedan vid start bestämma om objekt X ska visas eller inte baserat på om det aktuella fragmentet är detsamma som när det skapades eller inte.
Här bestämmer utvecklaren (och implementerar) att Objekt X bara läses in om det aktuella fragment-ID:t är ett och Objekt Y från rum B endast läses in om det aktuella fragmentet är 29.
Beständigheten i fragment-ID:t som är associerat med ett utrymme sparas som en del av beständigheten i World Locking Tools. Beständigheten för fragment-ID:t som är associerat med ett objekt, samt åtgärder som ska utföras baserat på det, lämnas dock till programmet.
Tillsammans med objektets associerade fragment-ID kan dess pose i globalt utrymme sparas. Om fragment-ID:t matchar efter att objektet har lästs in kan dess Pose återställas och returnera det till sin position i den fysiska världen under den senaste sessionen. Med beständighet i World Locking Tools förblir en pose fast mellan sessioner i förhållande till de fysiska världsfunktionerna runt den.
Beständighet för SpacePins
SpacePins kan betraktas som omslutningar på programsidan för AlignmentAnchors. SpacePins (och härledda klasser) är Unity-komponenter, och AlignmentAnchors är helt konceptuella. det finns ingen klass eller typ som motsvarar en AlignmentAnchor. I den här diskussionen används därför SpacePins och AlignmentAnchors omväxlande, med en allmän preferens för SpacePins.
Det kan dock vara förvirrande att en AlignmentManager kan bevara SpacePins när den inte har någon uppfattning om SpacePins. Det beror på att AlignmentManager hanterar den konceptuella AlignmentAnchor, som förkroppsligar kärnan i en SpacePin och från vilken en SpacePin kan återskapas.
Det finns fler kontroller på programnivå för beständigheten hos SpacePins än med det allmänna WLT-beständighetssystemet, eftersom SpacePins i sig är mer drivna av programindata än resten av World Locking Tools.
Det är viktigt att komma ihåg att SpacePins (och AlignmentAnchors) bevaras med namn. Detta är ett något starkare krav än det allmänna kravet att inga två aktiva SpacePins i samma IAlignmentManager har samma namn. Om du sparar SpacePins kan inga två SpacePins i samma databas ha samma namn, oavsett om de är aktiva eller inte.
Alignment Manager-databaser
Varje IAlignmentManager har en databas med SpacePins efter namn, enligt implementeringen av RestoreAlignmentAnchor(string uniqueName, Pose virtualPose).
Den globala justeringsdatabasen
Det finns en global IAlignmentManager som ägs av WorldLockingManager.GetInstance(). Som tidigare nämnts bestäms dess standardplats för sparande av egenskapen SaveFileName. Observera att SaveFileName är en egenskap för klassen AlignmentManager, inte gränssnittet IAlignmentManager. En IAlignmentManager-implementering kan implementera beständighet utan något begrepp om filer eller filnamn. SaveFileName är en artefakt av hur AlignmentManager implementerar beständighet och är därför begränsad till AlignmentManager.
Lokala justeringsdatabaser
Det kan finnas valfritt antal justeringshanterare för underutrymmet, ett för varje AlignSubtree, som visas som fältet AlignSubtree.alignmentManager. Dessutom kan programmet skapa sina egna AlignmentManager-instanser, eller till och med sina egna klasser som härletts från IAlignmentManager.
Varje AlignSubtree-komponents AlignmentManager har en egen filplats för sparande, som standard är GameObjects namn, med tillägget ".fwb". Om komponenten AlignSubtree till exempel finns på en GameObject med namnet "MyRoot" skulle spara-filen ha namnet "MyRoot.fwb". Ett snedstreck för vidarebefordran kan användas för att placera det i en undermapp. Det skulle förmodligen vara dåligt för två AlignSubtree-komponenter att använda samma plats för att spara filen.
Men egentligen
Vi rekommenderar starkt att det på lång sikt är enklare och mer robust att ge SpacePins/AlignmentAnchors globalt unika namn, än att försöka hantera det lättare lokalt unika kravet. Men gör vad du vill.