Modułowość zestawu danych MRTK

Jedną z doskonałych nowych funkcji zestawu Mixed Reality Toolkit v2 jest ulepszona componentization. Tam, gdzie to możliwe, poszczególne składniki są odizolowane od wszystkich elementów oprócz podstawowej warstwy fundamentu.

Zminimalizowane zależności

Zestaw MRTK w wersji 2 został celowo opracowany jako modularny i aby zminimalizować zależności między usługami systemowym (np. świadomość przestrzenna).

Ze względu na charakter niektórych usług systemowych (np. danych wejściowych i teleportacji) istnieje niewielka liczba zależności.

Chociaż oczekuje się, że usługi będą potrzebować co najmniej jednego składników dostawcy danych, nie ma między nimi bezpośrednich połączeń. To samo dotyczy funkcji zestawu SDK (np. Interfejs użytkownika składników).

Komunikacja składników

Aby upewnić się, że nie ma bezpośrednich połączeń między składnikami, mrTK v2 wykorzystuje interfejsy do komunikacji między usługami, dostawcami danych i kodem aplikacji. Te interfejsy są zdefiniowane w programie i cała komunikacja jest przekierowyowana za pośrednictwem Mixed Reality Toolkit Core.

Korzystanie z systemu świadomości przestrzennej za pośrednictwem interfejsów

Minimalizowanie wpływu na importowanie biblioteki MRTK

W tej chwili zestaw MRTK jest importowany jako pojedynczy pakiet foundation (ignorując przez chwilę istnienie pakietu przykładów, który jest całkowicie opcjonalnym pakietem). Można to zrobić, ręcznie obcięcie importowanych plików, chociaż jest to proces wysoce ręczny, który nie ma dobrze zdefiniowanego przewodnika.

Podczas importowania pakietu Foundation można usunąć zaznaczenie dowolnych elementów. Nie zaleca się jednak tego robić na wczesnym etapie opracowywania, ponieważ może to spowodować przerwy w funkcjonalności. Po ostatecznej ilustracji zestawu funkcji aplikacji można w następujących folderach wykonać przycinanie niepotrzebnych dostawców i usług:

  • MRTK/Services
  • MrTK/Providers
  • Zestaw MRTK/zestaw SDK/funkcje

Uwaga

MrTK v2.x wymaga zawartości folderu Assets/MRTK/Core.

Nadchodzące funkcje

Architektura aplikacji

MrTK będzie miał obsługę, aby umożliwić budowaną obsługę aplikacji z różnymi architekturami, w tym:

Podczas wybierania architektury aplikacji należy wziąć pod uwagę elastyczność projektowania i wydajność aplikacji. Opisane tutaj architektury nie powinny być odpowiednie dla każdej aplikacji.

Lokalizator usługi MixedRealityToolkit

MrTK umożliwia (i automatycznie konfiguruje) scenom aplikacji używanie MixedRealityToolkit domyślnego składnika lokalizatora usługi. Ten składnik obejmuje obsługę konfigurowania systemów mrTK i dostawców danych za pośrednictwem inspektorów konfiguracji oraz zarządza cyklami życia składników i podstawowymi zachowaniami (np. kiedy należy je aktualizować).

Wszystkie systemy są reprezentowane w podstawowym inspektorze konfiguracji, niezależnie od tego, czy są obecne lub włączone w projekcie. Aby uzyskać więcej informacji, zobacz Mixed Reality Przewodnik konfiguracji aplikacji.

Poszczególne składniki usługi

Niektórzy deweloperzy wyrazili chęć uwzględnienia poszczególnych składników usługi w hierarchii sceny aplikacji. Aby włączyć to użycie, usługi muszą być hermetyzowane w niestandardowym rejestratorze lub samodzielnie się zarejestrować/samodzielnie zarządzać.

Usługa samorejestrowania zaimportuje samą usługę i zarejestruje się, aby kod aplikacji mógł odnaleźć wystąpienie usługi IMixedRealityServiceRegistrar za pośrednictwem rejestru.

Usługę samodzielnego zarządzania można zaimplementować jako pojedynczy obiekt w hierarchii sceny. Ten obiekt będzie dostarczać właściwość wystąpienia i właściwość wystąpienia, której kod aplikacji może używać do bezpośredniego uzyskiwania dostępu do funkcji usługi.

Lokalizator usługi niestandardowej

Niektórzy deweloperzy zażądali możliwości utworzenia niestandardowego składnika lokalizatora usług. Lokalizatory usług niestandardowych implementują interfejs i zarządzają cyklem życia i IMixedRealityServiceRegistrar podstawowymi zachowaniami aktywnych usług.

Architektura hybrydowa

MrTK będzie obsługiwać architekturę hybrydową, w której deweloperzy mogą łączyć poprzednie podejścia zgodnie z potrzebami lub potrzebami. Na przykład deweloper może zacząć od lokalizatora usługi i dodać usługę MixedRealityToolkit samorejestrowania.

Uwaga

Wybierając architekturę hybrydową, należy pamiętać o duplikowaniu pracy (np. uzyskiwaniu danych kontrolera z wielu składników).