Kalıcılık püf noktaları
Kalıcılık, temel alınan platform tarafından desteklenen durumlarda kullanılabilir. Şu anda bu, Unity'nin yerleşik VR desteği (Eski XR) kullanılarak HoloLens cihaz ailesi ile sınırlıdır.
Temel kalıcılık
Dünya Kilitleme Araçları için temel kalıcılık varsayılan olarak etkindir. Bu etkinleştirme iki bölümden oluşur.
Buradaki ilgili onay kutuları, denetlenen "Otomatik Yükleme" ve "Otomatik Kaydetme" kutularıdır. Gri olduğunu fark edebilirsiniz. Bunun nedeni, "Varsayılanları Kullan" seçeneğinin bir parçası olmalarıdır. "Varsayılanları Kullan"ın devre dışı bırakılması, Otomasyon seçeneklerinin rastgele birleşimlerinin seçilmesini sağlar.
Bu ayarlarda ve bunları betikten düzenleme konusunda daha fazla bilgi bulabilirsiniz.
Otomatik Kaydet
Otomatik Kaydet seçeneği, WLT'yi uygulamayı çalıştırırken sık ve normal durum kaydetmeleri yapmaya yönlendirir. Herhangi bir zamanda, uygulama en az durum kaybıyla sonlandırılabilir.
Autoload
Otomatik Yükle seçeneği WLT'yi başlangıçta daha önce kaydedilmiş herhangi bir durumu yüklemeye yönlendirir. Bu, uygulamanın son oturumdan kalan yeni bir oturumu (w.r.t. WLT) sürdürmesini etkili bir şekilde sağlar.
Tam kalıcılık
Hem Otomatik Kaydetme hem de Otomatik Yükleme etkinleştirildiğinde WLT, oturumlar arasında sorunsuz bir şekilde çalışır. Genel alanın konumu ve yönlendirmesi ilk çalıştırmada rastgele olsa da (daha önce kaydedilmiş bir durum olmadığından, başlangıçta çıkış noktası olarak baş pozunu kullanır), sonraki çalıştırmalar aynı koordinat çerçevesini paylaşır.
Bu, uygulama önceki oturumun alanıyla bağlantısı kesilmiş bir alanda yeni bir oturum başlattığında ilginç davranışlara yol açar. Ayrıntılar için aşağıdaki konuma göre kalıcılık bölümüne bakın.
Not
Otomatik Kaydet ve Otomatik Yükle ayarları genel SpacePin'ler için de geçerlidir. Ayrıntılar için aşağıya bakın.
Kalıcılık üzerinde uygulama denetimi
Varsayılan tam kalıcılık, çok çeşitli uygulamalar için uygundur.
Ancak bazı uygulamalar işlem üzerinde daha ayrıntılı denetim sahibi olmak isteyebilir.
WLT otomatik kalıcılığını etkinleştirmenin otomatik kaydetme ve Otomatik Yükleme olarak iki özelliğe bölünmesi garip görünebilir. İkisinin bağımsız olarak kullanıldığı durumları incelemek, genel kalıcılık sistemiyle ilgili içgörüler sağlayabilir.
Otomatik Kaydet ama Otomatik Yükle'ye değil
Bu yapılandırmayla WLT, durumunu düzenli aralıklarla kaydedecek şekilde ayarlanır. Ancak, başlangıçta kalıcı bir durumu otomatik olarak yüklemez.
Bunun yerine, sistem bu cihazda ilk kez çalıştırılıyor gibi yeni bir durumda başlar. Yalnızca Load() için açık bir istek sonrasında önceki oturumun durumunu geri yükler.
Bu, uygulamanın önceki oturum durumunu geri yüklemenin uygun olup olmadığına karar vermesine ve hatta gerekirse geri yüklenen verileri değiştirmesine olanak tanır.
Genel WLT kaydetme durumu "LocalState/frozenWorldState.hkfw" dosyasındadır. WLT tarafından oluşturulduktan sonra bu dosya başka bir konuma kopyalanabilir ve uygulamanın takdirine bağlı olarak geri yüklenebilir.
Hizalama (SpacePin) verileri için kaydetme dosyası varsayılan olarak "LocalState/Persistence/Alignment.fwb" olur. Ancak bu, hizalama yöneticisinin SaveFileName dosyası aracılığıyla uygulama tarafından geçersiz kılınabilir.
Bu yapılandırmayla önceki oturumun durumunu yükleme kararının başlangıçta alınması gerekir. Önceki oturumun kayıtlı durumu çalıştırıldıktan sonra bu oturumun durumuyla birlikte üzerine yazılır. Daha esnek bir kurulum için aşağıdaki El ile kaydetme ve yükleme bölümüne bakın.
El ile kaydetme ama Otomatik Yükleme
Bu yapılandırmada, WLT başlangıçta önceki bir oturumdan kullanılabilir durumdaki tüm durumları yükler. Ancak, durumu otomatik olarak kaydetmez. Bu, uygulamanın Kaydet() çağrısıyla durumun kaydedilmeye değer olup olmadığını ve ne zaman kaydedileceğine karar vermesine olanak tanır.
Otomatik Yükle yalnızca WLT'ye başlangıçta kullanılabilir herhangi bir durumu yüklemesini söyler. Uygulama, load() için açık bir çağrı ile herhangi bir zamanda kaydedilmiş herhangi bir durumu geri yükleyebilir.
El ile kaydetme ve yükleme
Uygulama, kaydetme ve yükleme işlemi üzerinde tam denetimi tutmayı seçebilir.
Bundan sonra durum yalnızca uygulamadan Save() için açık bir çağrıyla kaydedilir ve yalnızca Load() için açık bir çağrıyla yüklenir.
Load() çağrısı tarafından yüklenen durum bu oturumda veya önceki bir oturumda kaydedilmiş olabilir.
Kalıcılığı devre dışı bırakma
Yukarıda açıklandığı gibi, kalıcılık her zaman betikten uygulama tarafından kullanılabilir. Otomatik kalıcılık, betikten veya Denetçideki WorldLockingContext aracılığıyla etkinleştirilebilir ve devre dışı bırakılabilir. Otomatik kalıcılık devre dışı bırakılırsa WLT, uygulamadan gelen açık istekler olmadan kaydetme veya yükleme durumu girişiminde bulunmaz.
Elbette, Otomatik Yükleme yönergesi yalnızca başlangıçta yüklenip yüklenmeyeceğini etkilediğinden, başlatmadan sonra betikten değerin değiştirilmesinin hiçbir etkisi yoktur.
Geliştirme sırasında bir uyarı
Yukarıda belirtildiği gibi, genel WLT ve hizalama için kaydetme dosyalarının konumu uygulamaya geneldir. Özellikle, SpacePins olarak da bilinen hizalama düğümleri ada göre kalıcıdır (aşağıya bakın). Bir uygulama bir sahneden bir dizi SpacePin ile durum kaydederse ve sonra başka bir sahneden bir dizi SpacePin ile durumu yüklerse ve her iki SpacePin kümesi de ortak adları paylaşırsa, davranış tanımlanmamış olur.
Bu sorunun çeşitli yolları vardır. Mümkünse, en iyisi bir proje içinde SpacePin adlarını yeniden kullanmaktan kaçınmaktır. Yeniden dağıtımdan sonra beklenmeyen sahne kayan davranışı görürseniz WLT kaydetme durumunu silmeyi deneyin. Benzer şekilde, uygulamayı kökten değiştirirken, aşırı dikkatli olan kişi WLT kaydetme dosyalarını cihazdan silmek veya yeni sürümü yüklemeden önce uygulamayı kaldırmak isteyebilir.
Konuma göre kalıcılık
Senaryo
Birden çok fiziksel konumda çalıştırılan ilginç bir uygulama sınıfı vardır. Uygulama A Odası'nda çalıştırılabilir, cihaz kapatılmış, yeniden konumlandırılmış ve ardından B Odası'nda yeniden başlatılmış olabilir. B Odası A Odasının alt kısmında veya başka bir kıtada olabilir. Uygulamanın ve cihazın bilmesi mümkün değildir.
Kolaylık olması için uygulamanın el ile WLT kalıcılığı için yapılandırıldığını düşünelim.
İzlenecek yol
A ve B'ye bağlı olmayan bu odaları göz önünde bulundurun.
Uygulama A Odasında başlatılır. Odanın içinde bitişik bir donmuş koordinat alanı oluşturduktan sonra tüm oda 1. parçaya eşleniyor. Odaya kalıcı bir hologram Object X yerleştirilir. Ardından uygulama durumu kaydeder ve çıkar.
Cihaz kapatılır, B Odası'na alınır ve yeniden başlatılır.
Cihaz bunun A Odası olmadığını algılar, bu nedenle WLT içeriğine id == 29 gibi yeni bir parça kimliği atar. Neden 29? Çünkü 1 değil. Parça kimlikleri değerde rastgeledir; bir parçanın kimliği dışında FragmentId.Invalid veya FragmentId.Unknown ya da bilinen diğer parçalarla aynı olmaz.
Artık iki parça vardır ve bunları birleştirmenin bir yolu yoktur (göreli konumlarında kullanılabilir bilgi olmadığından).
İlgili uygulama geliştirici şunu sorabilir: A Odasına kalıcı bir X Nesnesi yerleştirdim, uygulama B Odasında başlatıldığında X Nesnesi yüklendiğinde ne olur?
Yanıt, davranışın belirlemek için uygulama geliştiricisine bırakılmasıdır. X Nesnesi A Odasına yerleştirildiğinde geçerli parça kimliği kullanılabilir ve kalıcı hale gelebilir. Uygulama daha sonra başlangıçta Nesne X'in gösterilip gösterilmeyeceğine, geçerli parçanın oluşturulduğu zaman ile aynı olup olmadığına karar verebilir.
Burada geliştirici, Nesne X'in yalnızca geçerli parça kimliği bir ise yüklendiğine ve B Odasından Nesne Y'nin yalnızca geçerli parça 29 olduğunda yüklendiğine karar verir (ve uygular).
Bir alanla ilişkili parça kimliğinin kalıcılığı, World Locking Tools'un kalıcılığının bir parçası olarak kaydedilir. Ancak, bir nesneyle ilişkili parça kimliğinin kalıcılığı ve buna bağlı olarak yapılması gereken eylemler uygulamaya bırakılır.
Nesnenin ilişkili parça kimliğiyle birlikte, genel alanda pozu kaydedilebilir. Ardından parça kimliği eşleşirse, nesne yüklendikten sonra Pose geri yüklenebilir ve son oturum sırasında fiziksel dünyadaki konumuna döndürülebilir. Dünya Kilitleme Araçları kalıcılığı sayesinde, bir Poz, çevresindeki fiziksel dünya özelliklerine göre oturumlar arasında sabit kalır.
SpacePin'lerin kalıcılığı
SpacePin'ler AlignmentAnchors için uygulama tarafı sarmalayıcıları olarak düşünülebilir. SpacePin'ler (ve türetilmiş sınıflar) Unity bileşenleriyken, AlignmentAnchors yalnızca kavramsaldır; Bir AlignmentAnchor'a karşılık gelen bir sınıf veya tür yok. Bu nedenle, bu tartışmada SpacePin'ler ve AlignmentAnchor'lar ara sıra, SpacePins için genel bir tercihle kullanılacaktır.
Ancak, bir AlignmentManager'ın SpacePin'ler ile ilgili bir not olmadığında SpacePin'leri kalıcı hale getirmesi kafa karıştırıcı olabilir. Bunun nedeni, AlignmentManager'ın bir SpacePin'in özünü barındıran ve bir SpacePin'in yeniden oluşturulabileceği kavramsal AlignmentAnchor'u yönetmesidir.
SpacePin'lerin kalıcılığı için genel WLT kalıcılık sistemine göre daha fazla uygulama düzeyi denetimi vardır, çünkü SpacePin'ler dünya kilitleme araçlarının geri kalanından daha fazla uygulama girişi tarafından yönlendirilir.
SpacePin'lerin (ve AlignmentAnchor'ların) ada göre kalıcı olduğunu unutmamak önemlidir. Bu, aynı IAlignmentManager'daki iki etkin SpacePin'in aynı ada sahip olmamasından biraz daha güçlü bir gereksinimdir. SpacePins kalıcı hale gelirse, etkin olsun veya olmasın, aynı veritabanındaki iki SpacePin aynı ada sahip olamaz.
Hizalama yöneticisi veritabanları
Her IAlignmentManager, RestoreAlignmentAnchor(string uniqueName, Pose virtualPose) uygulamasıyla ima edilen ada göre Bir SpacePins veritabanına sahiptir.
Genel hizalama veritabanı
WorldLockingManager.GetInstance() tarafından sahip olunan bir genel IAlignmentManager vardır. Belirtildiği gibi, varsayılan kaydetme dosyası konumu SaveFileName özelliği tarafından belirlenir. SaveFileName öğesinin IAlignmentManager arabiriminde değil, AlignmentManager sınıfında bir özellik olduğuna dikkat edin. IAlignmentManager uygulaması, dosya veya dosya adı kavramı olmadan kalıcılık uygulayabilir. SaveFileName, AlignmentManager'ın kalıcılık uygulama biçiminin bir yapıtıdır ve bu nedenle AlignmentManager ile sınırlıdır.
Yerel hizalama veritabanları
AlignSubtree.alignmentManager alanı olarak görünen her AlignSubtree için bir tane olmak üzere herhangi bir sayıda alt alan hizalama yöneticisi olabilir. Ayrıca, uygulama kendi AlignmentManager örneklerini, hatta IAlignmentManager'dan türetilmiş kendi sınıflarını oluşturabilir.
Her AlignSubtree bileşeninin AlignmentManager'ı, varsayılan olarak GameObject'in adını ".fwb" uzantısıyla gösteren kendi kaydetme dosyası konumuna sahiptir. Örneğin AlignSubtree bileşeni "MyRoot" adlı bir GameObject üzerindeyse, kaydetme dosyası "MyRoot.fwb" olarak adlandırılır. Bir alt klasöre yerleştirmek için eğik çizgi '/' kullanılabilir. İki AlignSubtree bileşeninin aynı kaydetme dosyası konumunu kullanması büyük olasılıkla kötü olabilir.
Ama gerçekten
Uzun vadede, SpacePins/AlignmentAnchors'a genel olarak benzersiz adlar vermenin daha basit ve daha sağlam olması, daha hafif yerel olarak benzersiz gereksinimi yönetmeye çalışmaktan çok daha sağlam olması önerilir. Ama ne istersen yap.