Interfejs użytkownika woluminu z kanwą — MRTK3

Uwaga

Jest to koncepcyjny przegląd sposobu kompilowania hybrydowego interfejsu użytkownika opartego na kanwie. Aby uzyskać dokumentację dotyczącą poszczególnych prefabrykatów środowiska użytkownika, zobacz dokumentację składników środowiska użytkownika.

MRTK3 wprowadza interfejs użytkownika woluminu zintegrowany z systemem RectTransform i Canvas aparatu Unity. Chociaż ten system został historycznie używany głównie w przypadku płaskiego interfejsu użytkownika 2D, umożliwia renderowanie i układanie interfejsu użytkownika 3D woluminu. Może to przyspieszyć iterację projektu i zwiększyć wierność projektów, które można utworzyć za pomocą interfejsu użytkownika woluminu.

Uwaga

Biblioteka składników oparta na kanwie jest aktywna i szybko zmieni się przy użyciu nowych funkcji, wyglądu i działania, układu i architektury.

Systemy interfejsu użytkownika spoza kanwy zestawu NARZĘDZI MRTK 2.x były bardzo trudne do zaprojektowania, ponieważ brakowało im wielu podstawowych funkcji oczekiwanych w systemie projektowania interfejsu.

• ✘ Brak fizycznych jednostek projektowych
• ✘ Brak wyrównania
• ✘ Brak marginesu/wypełnienia
• ✘ Brak elastycznych lub dynamicznych układów
• ✘ Odrębne prefabrykaty dla każdej permutacji układu, rozmiaru i konfiguracji
• ✘ Bardzo ograniczona obsługa układu kolekcji (układy w poziomie/pionowym)
• ✘ Brak podstawowych funkcji projektowych, takich jak bezwzględnie wielkości zaokrąglone promienie rogu lub szerokości pociągnięcia
• ✘ Należy użyć skalowania , aby dostosować rozmiary elementów interfejsu użytkownika, destrukcyjnie zmieniając elementy podrzędne
• ✘ Ograniczona obsługa myszy i klawiatury
• ✘ Brak obsługi gamepadu

W wyniku tych ograniczeń interfejs użytkownika woluminu był historycznie bardziej pierwotny w swoim projekcie i wymagał dużej pracy ręcznej od projektantów technicznych do tworzenia pięknych układów.

MRTK3 wprowadza ujednolicone podejście. Piękne kontrolki interfejsu użytkownika woluminu, które obsługują wszystkie interakcje XR (takie jak artykułowane naciśnięcia śledzenia rąk i szczypta spojrzenia) mogą być tworzone w kontekście Canvas-RectTransform. Kontrolki można automatycznie układać przy użyciu odpowiedniego marginesu, dopełniania, elastycznej elastyczności i wszystkich funkcji, których oczekują projektanci. Ponadto możemy kierować zdarzenia UGUI w dół do XRI, aby dokładnie te same prefabryki interfejsu użytkownika działały równie dobrze w kontekstach 2D, a także 3D, w tym dostępne dane wejściowe, takie jak gamepad.

Korzyści:

• ✔ Elastyczne jednostki projektowe mapowane na różne konteksty fizyczne (rzeczywistość 3D, ekrany 2D, tv/desktop/mobile/web)
• ✔ Pełna obsługa wyrównania RectTransform dla układu dynamicznego z relacjami nadrzędnymi/podrzędnymi
• ✔ Pełna obsługa marginesu rectTransform i wypełniania za pośrednictwem grup AutoLayout aparatu UnityUI
• ✔ Obsługa układów elastycznych z priorytetem i marginesami za pośrednictwem grup AutoLayout aparatu UnityUI
• ✔ Pojedyncza prefab dla każdego typu kontrolki, którą można zmienić i dostosować do dowolnej zawartości lub kontekstu
• ✔ Układy poziome, pionowe i siatki z grup AutoLayout aparatu UnityUI. Układy niestandardowe są możliwe za pomocą rozszerzenia interfejsów układu aparatu Unity.
• ✔ Szeroką gamę zaawansowanych funkcji projektowania, takich jak bezwzględnie wielkości zaokrąglony róg promieni, szerokości pociągnięcia i marginesy, włączone przez zaawansowane funkcje cieniowania interfejsu użytkownika w pakiecie narzędzi graficznych Mixed Reality.
• ✔ Brak skalowania: wszystkie rozmiary i układ są osiągane za pomocą rozmiaru RectTransform i metryki przesunięcia. Rodzice nie skalują dzieci.
• ✔ Pełna obsługa myszy i klawiatury, natywnie za pośrednictwem zdarzeń UGUI i UGUIInputAdapter i CanvasProxyInteractor (zobacz dokumentację architektury interakcji, aby uzyskać więcej informacji)
• ✔ Obsługa gamepadu i nawigacji kierunkowej/względnej

Ta moc i elastyczność mogą być kosztowne, a interfejs użytkownika oparty na kanwie wymaga starannego zarządzania, aby uniknąć typowych pułapek wydajności.

• Każdy "ruchomy element" interfejsu użytkownika powinien być odrębnym węzłem Kanwy. Istnieją O(tree_height) koszty związane z mutacją hierarchii kanwy; użycie wielu kanwy dla wielu ruchomych części/składników wielokrotnego użytku jest zdecydowanie zalecane.
• Unikaj używania pojedynczej kanwy globalnej dla całej sceny.
• Przenoszenie i obracanie kanwy i rectTransforms może mieć wpływ na wydajność. Zdecydowanie zalecamy zagnieżdżanie kanwy pod transformacją "holster" inną niż RectTransform, która zostanie przeniesiona, zamiast bezpośrednio przenieść kanwę.
• Nasza historia do maskowania i przycinania interfejsów użytkownika opartych na zderzaczach jest nadal rozwijana. Rozważ uniknięcie widoków przewijania, które zawierają zawartość z możliwością kliknięcia.
• Domyślny system nawigacji kierunkowej aparatu Unity może zachowywać się dziwnie w niektórych kontekstach 3D. Badamy niestandardowe systemy nawigacji, które będą zachowywać się bardziej niezawodnie w nietypowych układach 3D.

Udostępnimy bardziej szczegółowe wskazówki dotyczące optymalizowania układów opartych na kanwie, ponieważ przeprowadzamy bardziej szczegółowe testy wydajnościowe na różnych urządzeniach.

Konfigurowanie

Nasze składniki są tworzone z 1 jednostką projektową: współczynnik 1mm dla kontekstów fizycznych. Podczas konfigurowania kanwy do użycia z interfejsem użytkownika woluminu przeznaczonego do wyświetlania w immersyjnych aplikacjach 3D:

• Upewnij się, że kanwa jest przestrzenią światową
• Upewnij się, że skala kanwy jest globalnie 0,001 na wszystkich osiach

W przypadku aplikacji renderowanych na ekranie 2D skalowanie można swobodnie dostosować, aby dopasować określone metryki użyteczności i minimalne rozmiary obiektów docelowych dotyku.

W przypadku korzystania z funkcji interakcji z UGUIInputAdapter (podobnie jak w przypadku naszego środowiska użytkownika opartego na kanwie) upewnij się, że w scenie masz obiekt CanvasProxyInteractor GameObject (najlepiej pusty). Spowoduje to przekazanie zdarzeń interfejsu UGUI za pośrednictwem XRI, zapewniając, że interakcje działają prawidłowo.

Jeśli chcesz eksperymentować z danymi wejściowymi interfejsu UGUI w składnikach innych niż UX, dodaj UGUIInputAdapter go do interakcji z interfejsem XRI. Dane wejściowe interfejsu UGUI dotyczące elementów niezwiązanych z środowiskiem użytkownika są eksperymentalne i podlegają kilku otwartym usterkom.

Ciągły rozwój

Nadal kształtujemy historię programowania na potrzeby tworzenia pięknego interfejsu użytkownika na naszych różnych obsługiwanych platformach. Obecnie nadal dostarczamy dwie wersje większości składników środowiska użytkownika: jedną, która nie używa kanwy, ze statycznym, nieodpowiadczym układem (jak poprzednio podano w zestawie MRTK 2.x) i inną wersją utworzoną przy użyciu ujednoliconego podejścia opartego na kanwie. W miarę tworzenia większej liczby składników i opracowywania implementacji biblioteki projektowej oczekujemy, że przestaną być składnikiem kanwy w interesie spójności i konserwacji.

Ujednolicone zarządzanie stanem

Ze względu na ścisłe rozdzielenie stanu/interakcji i wizualizacji zauważysz, że te same skrypty stanu i interakcji są współużytkowane w kontekstach kanwy i nienależących do kanwy. Jest to zgodnie z projektem; te same skrypty interakcji mogą być ponownie używane w dowolnych kontekstach wizualizacji lub układu, zmniejszając powierzchnię interfejsu API i zwiększając spójność naszych interakcji. Na przykład Slider jest składnikiem interakcji suwaka zarówno dla suwaków Kanwy, jak i nienależących do kanwy, i PressableButton jest to ten sam skrypt na przyciskach Kanwy i nienależących do kanwy. W przyszłości, jeśli zostanie przyjęta nowa struktura układu lub prezentacji, możemy przejąć tę samą logikę interakcji i systemy, aby zapewnić spójność i konserwację.

Na poniższym diagramie architektury przedstawiono sposób współdziałania różnych zdarzeń wejściowych i typów interakcji w celu zapewnienia ujednoliconego stanu interakcji. Kliknij diagram, aby wyświetlić większą wersję.