Jak zbudować konfigurator 3D produktu w Babylon.js, który ładuje się szybko i przekazuje konfigurację do koszyka?

Źródła sprawdzone 13 listopada 2026.

Ten poradnik jest dla osoby, która planuje konfigurator 3D produktu w sklepie internetowym albo na stronie producenta i chce zrozumieć, z czego składa się warstwa 3D, zanim zamówi projekt. Opisuje przygotowanie modeli, wydajność, przeglądarki i połączenie z koszykiem.

Odpowiedź w skrócie: o jakości konfiguratora decydują modele i ich przygotowanie, a nie sam silnik. Babylon.js daje gotowy loader glTF, obsługę wariantów materiałów i narzędzia optymalizacji sceny, ale reguły konfiguracji i ceny muszą być przechowywane poza sceną, w systemie, który obsługuje zamówienie.

Konfigurator to więcej niż obracany model. Zanim powstanie wycena, rozdziel odpowiedzialność między elementy:

Taki podział pozwala zmieniać modele bez ruszania reguł cenowych i odwrotnie. Gdy reguły są zapisane tylko w kodzie sceny, każda zmiana oferty wymaga pracy programisty 3D.

Pliki z programów CAD opisują produkt do produkcji, z dokładnością i liczbą detali, których przeglądarka nie potrzebuje. Do konfiguratora model trzeba uprościć i wyeksportować do formatu przeznaczonego do wyświetlania.

Takim formatem jest glTF 2.0, opisany w specyfikacji glTF 2.0 organizacji Khronos. Plik zawiera geometrię, materiały oparte na fizycznym modelu oświetlenia (PBR), tekstury i hierarchię elementów, a wersja binarna GLB mieści to w jednym pliku.

Przy przygotowaniu modeli ustal z grafikiem 3D: nazwy elementów, które konfigurator będzie podmieniać lub ukrywać, punkt odniesienia (origin) i skalę (glTF używa metrów), oraz budżet wielkości pliku dla wersji mobilnej.

Jeśli produkt ma kilkanaście kolorów lub wykończeń, osobny plik dla każdego wariantu wydłuża ładowanie przy każdej zmianie.

Rozszerzenie KHR_materials_variants pozwala zapisać wiele wariantów materiałów dla tej samej geometrii w jednym pliku glTF i przełączać je w czasie działania bez ponownego ładowania modelu. Specyfikacja podaje jako typowe zastosowanie handel internetowy, na przykład zmianę koloru butów. Rozszerzenie zostało ratyfikowane przez Khronos Group. Specyfikacja zaznacza, że rozszerzenie jest przeznaczone dla skończonej listy wariantów przygotowanych z góry, a nie dla konfiguratorów z dynamicznymi regułami składania produktu.

Loader glTF w Babylon.js zawiera implementację tego rozszerzenia (kod źródłowy rozszerzenia KHR_materials_variants w repozytorium Babylon.js), więc nazwy wariantów zapisane w pliku mogą odpowiadać opcjom w interfejsie konfiguratora.

Na telefonie każdy megabajt modelu wydłuża czas do pierwszego obrazu. glTF ma rozszerzenia, które zmniejszają rozmiar danych:

• KHR_draco_mesh_compression: kompresja geometrii biblioteką Draco.
• EXT_meshopt_compression: kompresja geometrii metodą Meshopt.
• KHR_texture_basisu: tekstury KTX2 z kompresją Basis Universal, które zajmują mniej miejsca w pobieraniu i w pamięci karty graficznej.

Według dokumentacji loadera glTF w Babylon.js silnik przy takich plikach domyślnie pobiera dekodery z CDN Babylon i uruchamia je w web workerach. Dokumentacja wskazuje, że może to rodzić problemy z ochroną danych (RODO) lub z polityką Content Security Policy, i zaleca hostowanie dekoderów na własnym serwerze.

Kompresja przenosi część pracy na urządzenie, które musi dane rozpakować. Wybór metody sprawdź na docelowych telefonach, mierząc czas od otwarcia strony do pokazania modelu.

Babylon.js renderuje przez WebGL albo WebGPU. Według dokumentacji Babylon.js o WebGPU obsługa tego API jest dostępna od wersji 5.0 z maja 2022 i jest kompatybilna wstecz z implementacją WebGL. Różnica w kodzie aplikacji to asynchroniczne uruchomienie silnika.

Według strony MDN o WebGPU API to API nie ma statusu Baseline, bo nie działa w części powszechnie używanych przeglądarek, i jest dostępne tylko w bezpiecznym kontekście (HTTPS).

Dla konfiguratora w sklepie oznacza to, że WebGL powinien zostać ścieżką działającą u wszystkich klientów. WebGPU można włączać tam, gdzie przeglądarka je obsługuje, po sprawdzeniu, że daje mierzalną różnicę dla Twojej sceny.

Wydajność konfiguratora ma dwie strony: płynność samej sceny i szybkość wczytania strony produktu. Dla sceny dokumentacja Babylon.js o optymalizacji sceny opisuje między innymi te techniki:

• Instancje: powtarzalne elementy rysowane jednym wywołaniem rysowania.
• Zamrożenie materiałów i macierzy świata: mniej przeliczeń dla elementów, które się nie zmieniają.
• Zamrożenie listy aktywnych siatek: oszczędność czasu procesora, gdy scena jest statyczna.

Dla strony ważne jest, co klient zobaczy, zanim scena się wczyta. Według opisu metryki LCP na web.dev dobry wynik to 2,5 sekundy lub mniej, a lista elementów branych pod uwagę obejmuje obrazy, wideo, tła z obrazem i bloki tekstu; lista nie wymienia elementu canvas. Statyczny obraz produktu wyświetlony od razu, a scena 3D ładowana po nim, pomaga utrzymać ten wynik.

Testuj na słabszych telefonach, a nie tylko na komputerze zespołu. Ustal budżet: maksymalny rozmiar modeli, liczbę wywołań rysowania i czas do pierwszej interakcji.

Konfiguracja wybrana w scenie musi trafić do koszyka jako dane, które zrozumie sklep, ERP i produkcja. Ustal format zapisu przed budową sceny:

Jeśli konfigurator obsługuje produkty z regułami technicznymi, cenami zależnymi od opcji i akceptacją ofert, warstwa 3D jest tylko częścią systemu CPQ. Reguły, ceny i połączenie z ERP opisujemy w poradniku o CPQ dla producentów i e-commerce B2B.

1. Identyfikator konfiguracji zapisany po stronie serwera, a nie tylko w adresie strony.
2. Lista wybranych opcji z kodami, które zna ERP lub system produkcyjny.
3. Cena obliczona po stronie serwera według tych samych reguł co w koszyku.
4. Obraz konfiguracji do koszyka, potwierdzenia zamówienia i oferty.
5. Wersja modelu i reguł, żeby dało się odtworzyć konfigurację po zmianie oferty.

Nie da się rzetelnie wycenić konfiguratora bez znajomości produktu i stanu modeli. Na zakres wpływają: liczba produktów i opcji, stan plików CAD lub modeli 3D, liczba reguł wykluczających opcje, sposób liczenia ceny i integracje ze sklepem oraz ERP.

Na pierwszą rozmowę przygotuj jeden produkt z pełną listą opcji, dostępne pliki modeli, opis tego, jak dziś powstaje wycena, oraz listę urządzeń, na których klienci przeglądają ofertę.

Rozsądnym pierwszym krokiem jest konfigurator jednego produktu z prawdziwymi danymi i pomiarem czasu ładowania na telefonach. Dopiero potem warto skalować go na cały katalog.