Model 3D na stronie internetowej: GLB, USDZ, podgląd AR i szybkość ładowania

GLB, glTF i USDZ: czym się różnią

Przygotowując plik 3D dla przeglądarki, spotkasz trzy rozszerzenia. Dwa to ten sam standard w różnym opakowaniu, trzecie służy tylko rozszerzonej rzeczywistości na iPhonie.

glTF 2.0 to otwarty standard konsorcjum Khronos Group, opisany w specyfikacji jako format dostarczania gotowych modeli do aplikacji. Pliku glTF się nie edytuje: pracujesz na pliku źródłowym, na przykład w Blenderze, a do przeglądarki eksportujesz wersję wynikową.

Wariant .gltf to opis sceny w JSON, który odwołuje się do osobnych plików z danymi i teksturami albo zawiera je zakodowane w base64; specyfikacja glTF podaje, że base64 zwiększa rozmiar tych danych o 33%. Wariant .glb to kontener binarny, w którym cały model mieści się razem z teksturami. Dlaczego na stronę zwykle trafia ten drugi i ile według Shopify powinien ważyć, opisuje przewodnik o konfiguratorze 3D.

Specyfikacja ustala też jednostki i orientację, a to widać wprost w AR. Metr jest w glTF jednostką długości, a oś Y wskazuje górę; dokumentacja Scene Viewera dodaje, że jedna jednostka to jeden metr, żeby obiekt stanął w pokoju w prawdziwej skali. Plik zapisany tak, że jedna jednostka oznacza centymetr, pokaże więc w AR sofę sto razy za dużą, a plik z inną osią pionową może ją położyć na boku. Materiały glTF opisuje model metaliczność–szorstkość (metallic-roughness), a Apple zaleca ten sam model materiału także przy plikach USD.

USDZ wywodzi się z Universal Scene Description, formatu opracowanego przez studio Pixar. Apple opisuje go jako archiwum zip, w którym plik USD leży razem z teksturami, dźwiękiem i innymi zależnościami; specyfikacja OpenUSD dodaje, że archiwum nie jest kompresowane. Apple podaje, że AR Quick Look, wbudowany w iOS podgląd rozszerzonej rzeczywistości, przyjmuje pliki .usdz i .reality. Do widoku 3D na stronie sam USDZ nie wystarczy, bo model-viewer, jak zaznacza jego dokumentacja, czyta wyłącznie pliki glTF i GLB.

Cenniki i przepisy się zmieniają. Linki do źródeł są na dole strony.

Pliki modelu 3D i do czego służą, według dokumentacji Khronos, Apple’a i model-viewera.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Trzy drogi: model-viewer, platforma sklepu, three.js

Wybór zależy od tego, co klient ma zrobić z produktem na ekranie: obejrzeć go i postawić u siebie w pokoju czy coś w nim zmienić.

<model-viewer> to otwarty komponent sieciowy Google na licencji Apache 2.0. Wystarczy dodać do strony jeden skrypt, z CDN albo z pakietu npm @google/model-viewer, i jeden znacznik z adresem pliku w atrybucie src. Atrybut poster wskazuje obraz podglądu, alt opisuje produkt dla czytników ekranu, camera-controls pozwala obracać produkt palcem i myszą, a ar dodaje przycisk rozszerzonej rzeczywistości. Cały znacznik może wyglądać tak: <model-viewer src="/3d/fotel.glb" poster="/3d/fotel.webp" alt="Fotel z zielonej tkaniny na dębowych nogach" camera-controls ar></model-viewer>. Google podaje, że widok 3D działa we wszystkich stale aktualizowanych przeglądarkach, a AR wymaga obsługi po stronie urządzenia i przeglądarki.

Druga droga to media produktu w platformie sklepu. Według pomocy Shopify platforma przyjmuje pliki GLB i USDZ jako media produktu, do 500 MB, a plik większy niż 15 MB sama optymalizuje. Wyświetli go jednak tylko motyw, który takie media obsługuje; motywy Online Store 2.0 od Shopify robią to od razu, przy motywie innej firmy trzeba to sprawdzić u autora. Nie piszesz kodu, za to pracujesz w granicach platformy i motywu; o samej platformie przeczytasz w przewodniku o sklepie Shopify w Polsce. Szerzej o grafice przestrzennej w całym sklepie, od renderów wariantów po AR i szybkość na telefonie, piszę w przewodniku wizualizacje 3D dla sklepu internetowego.

Trzecia droga to własna scena napisana w three.js albo innej bibliotece WebGL. Wybierasz ją wtedy, gdy klient ma w modelu coś zmienić, na przykład kolor, wymiar albo układ części, a jego wybór ma trafić do koszyka z właściwą ceną. To już jest konfigurator 3D produktu, a nie sam podgląd: kod zostaje po Twojej stronie i trzeba go utrzymywać, a rozszerzoną rzeczywistość składasz sam z dodatków biblioteki, takich jak przycisk sesji WebXR i eksporter USDZ.

Trzy sposoby pokazania modelu 3D na stronie produktu.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Kiedy wystarczą zdjęcia albo rendery

Model do obracania nie jest obowiązkowym elementem karty produktu. Zanim go zamówisz, sprawdź, czy klient w ogóle skorzysta z tego, co model daje ponad dobre zdjęcia.

Jeśli w tej liście rozpoznajesz swój sklep, sprawdź najpierw tańszą drogę: rendery wariantów albo dobrą sesję. Porównanie kosztów i tego, co każda z nich pokazuje, opisuję w przewodniku render 3D czy sesja zdjęciowa.

• Produktu nie ma po co obracaćGrafika, papier albo tkanina sprzedawana z metra wyglądają z każdej strony tak samo, więc obracanie nic klientowi nie mówi. Jeśli o zakupie decyduje faktura oglądana z bliska, pamiętaj, że tekstury modelu Google radzi trzymać w 2048 × 2048 pikseli, a zdjęcie makro takiego limitu nie ma.
• Klienci kupują głównie na komputerzePrzycisk AR pojawia się tylko na urządzeniach, które AR obsługują, czyli w praktyce na zgodnych telefonach i tabletach. Na komputerze zostaje obracanie w 3D, więc policz, ile wizyt na kartach produktu przychodzi z telefonów.
• Asortyment zmienia się co sezonKażdy model to plik GLB do przygotowania i sprawdzenia, a przy animacji jeszcze osobny USDZ. Jeśli produkt zniknie z oferty po kilku miesiącach, porównaj ten koszt z renderami albo zdjęciami wariantów, które nie wymagają pilnowania dwóch plików.
• Platforma albo motyw nie wyświetla 3DWtedy zostaje własny kod w szablonie strony: jeden skrypt i jeden znacznik z adresem modelu. Ktoś musi jednak pilnować, żeby przetrwały każdą aktualizację motywu.

AR na iPhonie: AR Quick Look i plik USDZ

Na iPhonie rozszerzona rzeczywistość nie wymaga żadnej aplikacji. Obsługuje ją AR Quick Look, wbudowany w system, a strona musi tylko podać plik we właściwej formie.

AR Quick Look ustawia obiekt na powierzchni, którą ARKit znajdzie w otoczeniu, a klient przesuwa go i skaluje gestami. Dokumentacja Apple’a pokazuje, że na stronie wystarczy link z atrybutem rel="ar", który prowadzi do pliku .usdz i zawiera obrazek, na przykład <a rel="ar" href="/modele/fotel.usdz"> z elementem <img> w środku. Po stuknięciu linku w Safari albo w widoku strony osadzonym w aplikacji iOS sam otwiera go w AR Quick Look.

Komponent model-viewer robi to za Ciebie. Bez atrybutu ios-src generuje USDZ z pliku GLB w chwili stuknięcia przycisku AR i uwzględnia zmiany wprowadzone w scenie przez skrypt, na przykład podmieniony kolor. Dokumentacja zaznacza jednak, że generowanie nie obsługuje jeszcze animacji. Produkt z animacją, na przykład z otwierającymi się drzwiczkami, potrzebuje więc osobnego pliku .usdz albo .reality w ios-src, aktualizowanego razem z GLB przy każdej zmianie produktu.

Plik USDZ wyeksportujesz z programu 3D obsługującego format USD; w Blenderze wystarczy przy eksporcie do USD nadać plikowi rozszerzenie .usdz. Apple zaleca sprawdzić gotowy plik narzędziem usdchecker z pakietu OpenUSD, a potem otworzyć go tam, gdzie będzie oglądany, przy AR Quick Look po prostu na iPhonie, bo sprawdzenie struktury nie wyłapie brakujących materiałów ani złego oświetlenia. Bez względu na to, skąd pochodzi plik, link do niego musi spełnić warunki opisane przez zespół WebKit, silnika Safari:

• Jeden obrazek w linkuLink musi zawierać dokładnie jeden element potomny: <img> albo <picture>. Safari oznacza taki link ikoną sześcianu w rogu obrazka.
• Właściwy typ plikuSerwer musi wysyłać plik z typem model/vnd.usdz+zip, bo inaczej Safari nie rozpozna treści AR.
• Atrybut rel="ar"Bez niego link też zadziała, ale Safari przejdzie na osobną stronę z miniaturą, zamiast od razu otworzyć model i po jego zamknięciu wrócić na Twoją stronę.

AR na Androidzie: WebXR albo Scene Viewer

Na Androidzie rozszerzoną rzeczywistość uruchomisz na dwa sposoby: w przeglądarce, przez WebXR, albo w Scene Viewerze, osobnej aplikacji Google do oglądania obiektów 3D. Komponent model-viewer obsługuje oba i próbuje ich po kolei.

W obu przypadkach telefon musi być na liście urządzeń obsługujących ARCore, którą publikuje Google, i mieć zainstalowane Usługi Google Play dla AR. Scene Viewer wymaga do tego Androida 7.0 lub nowszego i aktualnej aplikacji Google. WebXR działa tylko na stronie otwartej przez HTTPS, w przeglądarce, która obsługuje WebXR. Jeśli model osadzasz w ramce iframe, ramka musi pozwalać Twojej domenie na xr-spatial-tracking, inaczej tryb WebXR nie zadziała.

Domyślnie model-viewer próbuje trybów w kolejności webxr, scene-viewer, quick-look, więc na Androidzie zaczyna od WebXR. Dokumentacja komponentu wyjaśnia, dlaczego: tylko w WebXR sesja AR zostaje w przeglądarce, więc możesz nałożyć na nią własny HTML, na przykład podpowiedź, żeby poruszyć telefonem, dopóki model nie stanie na podłodze. Scene Viewer i AR Quick Look to osobne aplikacje i Twojej treści nie pokażą. WebXR ma też tę zaletę, że nie pobiera pliku drugi raz.

Atrybut ar-scale="fixed" blokuje skalowanie we wszystkich trzech trybach AR, więc sofa ma w pokoju zawsze rozmiar zapisany w pliku, a ar-placement="wall" wiesza obiekt na ścianie, co przydaje się przy lustrach i lampach ściennych. Przycisk AR pojawia się tylko na urządzeniach, które AR obsługują, więc nie obiecuj każdemu klientowi, że zobaczy produkt u siebie.

Uważaj na kompresję. W wymaganiach Scene Viewera Google wymienia tylko dwa rozszerzenia glTF, KHR_materials_unlit i KHR_texture_transform, a jego walidator dopuszcza jeszcze KHR_materials_pbrSpecularGlossiness. Błąd zgłasza wtedy, gdy plik używa innego rozszerzenia, odkształceń siatki (morph targets) albo kolorów wierzchołków. Draco i KTX 2.0, o których piszę niżej, są właśnie spoza tej listy. Jeśli z nich korzystasz, sprawdź plik w podglądzie Google albo usuń scene-viewer z atrybutu ar-modes i zostaw Androidowi samo WebXR.

Jeśli nie używasz model-viewera, Scene Viewer otwierasz sam. Służy do tego link w formacie intencji Androida, zaczynający się od intent://arvr.google.com/scene-viewer/1.0. Adres modelu podajesz w parametrze file, a w S.browser_fallback_url stronę, na którą Chrome przejdzie, gdy na telefonie brakuje aplikacji Google; w linku osadzonym w HTML ten parametr jest wymagany. Parametr mode ustala, od czego zaczyna się pokaz: domyślne 3d_preferred otwiera widok 3D z przyciskiem przejścia do AR, ar_preferred startuje od razu w AR, a 3d_only pokazuje sam widok 3D, bez AR.

Wydajność: budżet pliku i ładowanie bez szkody dla LCP

Plik 3D może spowolnić stronę na dwa sposoby: gdy pobiera się razem z nią i gdy jest za ciężki dla telefonu. Przed pierwszym chroni kolejność ładowania, przed drugim budżet ustalony, zanim ktoś zacznie modelować.

Tabela poniżej pokazuje limity, które Google podaje dla Scene Viewera. Ponieważ model-viewer wyświetla na stronie ten sam plik GLB, który w trybie AR przekazuje Scene Viewerowi, najprościej traktować je jako budżet całego wdrożenia.

Siatkę zmniejszysz kompresją Draco, otwartą biblioteką Google. W glTF zapisuje się ją jako rozszerzenie KHR_draco_mesh_compression, a eksporter glTF w Blenderze ma ją wbudowaną. Draco zaokrągla współrzędne do mniejszej liczby bitów, więc traci odrobinę dokładności; jego dokumentacja podaje, że w większości projektów 11 bitów nie daje widocznej różnicy. Dekoder pobiera się z CDN Google dopiero przy skompresowanym pliku, ale waży ponad 100 KB, więc kompresja opłaca się wtedy, gdy oszczędza więcej.

Tekstury zmniejszysz formatem KTX 2.0 z kompresją Basis Universal. Według Khronos takie tekstury zamieniają się w trakcie działania strony na format, który rozumie karta graficzna telefonu, więc mniej ważą zarówno przy pobieraniu, jak i w pamięci karty. W glTF zapisuje się je przez rozszerzenie KHR_texture_basisu. Transkoder, który to umożliwia, model-viewer pobiera z CDN Google tak samo jak dekoder Draco: dopiero wtedy, gdy plik go wymaga.

Najważniejsza decyzja dotyczy kolejności. LCP to czas wyświetlenia największego elementu w pierwszym widoku, a web.dev uznaje za dobry wynik najwyżej 2,5 sekundy na 75. percentylu wizyt. Według web.dev elementem LCP mogą być tylko obrazy, obraz podglądu albo pierwsza klatka wideo, obrazy tła i bloki tekstu, a przeglądarki oparte na Chromium pomijają między innymi obrazy zastępcze o niskiej szczegółowości. Elementu canvas, na którym rysuje się scena, na tej liście nie ma. Jeśli więc model stoi w pierwszym ekranie, wynik wyznaczy inny element, na przykład obraz podglądu modelu, zdjęcie obok albo nagłówek.

Dlatego podgląd przygotuj jak zdjęcie produktu, a nie jak rozmytą zaślepkę. Komponent model-viewer pozwala wstawić w miejsce domyślnego podglądu własny element przez slot="poster", na przykład zwykły <img> z właściwymi wymiarami. web.dev ostrzega, żeby obrazu, który jest elementem LCP, nigdy nie ładować leniwie, i radzi dać mu fetchpriority="high".

Plik GLB ładujesz osobno. Domyślne loading="auto" działa w model-viewerze jak lazy: przy reveal="auto" plik pobiera się, gdy element zbliża się do ekranu, a przy reveal="manual" dopiero po wywołaniu dismissPoster(), na przykład po kliknięciu przycisku „Obróć w 3D”. Wartość eager pobiera go od razu. Na karcie produktu daje to wzorzec „zdjęcie najpierw, model po geście klienta”, w którym LCP liczy się z samego zdjęcia.

Na telefonie liczy się też przewijanie. Domyślne touch-action="pan-y" sprawia, że pionowy ruch palcem po modelu dalej przewija stronę, a obrót zaczyna się od gestu poziomego; wartość none blokuje przewijanie całkowicie. Komponent sam obniża rozdzielczość, gdy scena się porusza, żeby utrzymać płynność, i wraca do pełnej, gdy ruch ustaje. Dlatego przy bardzo złożonych modelach jego dokumentacja radzi wyłączyć automatyczny obrót, który nie pozwala scenie się zatrzymać.

Zalecane limity modelu według dokumentacji Scene Viewera (Google). Część limitów Google oznacza jako twarde.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Dostępność: opis, sterowanie i ruch

Widok 3D jest dodatkiem do karty produktu, a nie jej zamiennikiem. Osoba, która go nie zobaczy albo nie obróci, musi dostać te same informacje inną drogą.

Atrybut alt model-viewera to tekst dla czytników ekranu. Opisz w nim produkt, a nie technologię: „Fotel z zielonej tkaniny na dębowych nogach” mówi więcej niż „Model 3D fotela”. Wymiary, materiały i warianty zostają w treści strony, bo nie każdy klient produkt obróci, a na części urządzeń AR się nie uruchomi.

Atrybut a11y przyjmuje obiekt JSON z opisami kolejnych widoków modelu: przodu, tyłu i obu boków, tych samych stron widzianych z góry i z dołu, oraz z tekstem podpowiedzi o sterowaniu. Dokumentacja model-viewera przedstawia go jako miejsce na tłumaczenia dla czytników ekranu, więc na polskiej stronie wpisujesz tam polskie opisy, na przykład „Tył fotela, widać przeszycia oparcia”.

Ruch to osobna sprawa. Atrybut auto-rotate obraca model sam, domyślnie po trzech sekundach opóźnienia, a podpowiedź interakcji to ikona dłoni kołysząca się razem z modelem, dopóki klient go nie dotknie. Część osób ustawia w systemie ograniczenie animacji, a strona odczyta tę preferencję przez zapytanie medialne prefers-reduced-motion. Gdy zwraca ono reduce, nie włączaj automatycznego obrotu, a podpowiedź wyłącz atrybutem interaction-prompt="none". W skrypcie sprawdzisz to przez matchMedia("(prefers-reduced-motion: reduce)").

Jak sprawdzić pliki przed publikacją

Walidator glTF, podgląd Google, narzędzie usdchecker i test na telefonach wyłapują różne błędy, więc żaden z tych kroków nie zastępuje pozostałych.

1. Walidator glTFOficjalny walidator Khronos sprawdza plik GLB albo glTF ze specyfikacją. Wersja w przeglądarce działa lokalnie i nie wysyła modelu na serwer; są też wersje dla wiersza poleceń i npm.
2. Podgląd Scene VieweraNarzędzie podglądu Google wczytuje GLB albo glTF razem z teksturami i wypisuje ostrzeżenia oraz błędy względem wymagań Scene Viewera, w tym wagi pliku, liczby trójkątów i nieobsługiwanych rozszerzeń.
3. Plik USDZStrukturę sprawdzasz narzędziem usdchecker, a wygląd dopiero na iPhonie, bo według Apple’a walidacja struktury nie wyłapie brakujących materiałów ani złego oświetlenia.
4. Typy plików na serwerzePlik .glb z typem model/gltf-binary, zapisanym w specyfikacji glTF, a plik .usdz z typem model/vnd.usdz+zip, którego oczekuje Safari.
5. Test na trzech urządzeniachSprawdź stronę na iPhonie w Safari, na telefonie z Androidem z listy ARCore i na urządzeniu bez AR, na przykład na laptopie. Na tym ostatnim przycisk AR nie powinien się pojawić, a klient ma zobaczyć obracany model albo przynajmniej zdjęcie.
6. Pomiar przed wdrożeniem i po nimLCP i płynność przewijania na telefonie z modelem i bez niego. Gdy wynik się pogorszy, sprawdź najpierw, czy model albo podgląd nie ładują się wcześniej, niż zakładałeś.

Co przygotować przed zamówieniem modelu

Każda informacja, której wykonawca nie dostanie, zamienia się w zgadywanie, a potem w poprawki. Te materiały warto mieć pod ręką przed pierwszą rozmową.

Zakres usługi wizualizacje 3D obejmuje model produktu, interaktywny widok z obrotem i przybliżeniem, kontrolę wagi plików i sterowanie dotykiem, a przy nowej stronie albo sklepie łączy się z projektem strony internetowej. Wystarczy, że napiszesz, jaki to produkt i na jakiej platformie stoi sklep, a do wiadomości dołączysz to, co masz z listy poniżej.

1. WymiarySzerokość, wysokość i głębokość, najlepiej z rysunku technicznego. glTF liczy w metrach, a model w AR ma stanąć w pokoju w prawdziwej skali, więc wymiary muszą się zgadzać z produktem co do centymetra.
2. Zdjęcia z kilku stronPrzód, tył, boki, góra i zbliżenia detali: łączeń, przeszyć, uchwytów. Przynajmniej jedno zdjęcie w świetle dziennym z próbką materiału albo wzornikiem koloru obok, żeby kolor dało się odtworzyć.
3. Materiały i wykończeniaZ czego jest każda część, czy powierzchnia jest matowa, satynowa czy z połyskiem i czy jest metalowa. Model materiału w glTF opiera się na kolorze bazowym, metaliczności i szorstkości, więc te informacje przekładają się na model wprost.
4. Lista wariantówKolory, tkaniny i rozmiary, które mają dostać własny model albo własną teksturę. Jeśli klient ma je łączyć dowolnie, a cena zależy od wyboru, potrzebujesz konfiguratora, a nie pojedynczego modelu.
5. Gdzie model się pojawiNapisz, na jakiej platformie stoi sklep, na których stronach ma być model i czy klient ma go oglądać w AR na iPhonie i Androidzie. Animację, na przykład otwieranie drzwiczek, zgłoś od razu, bo plik USDZ, który model-viewer tworzy automatycznie, jej nie obsługuje.

Pytania i odpowiedzi