Three.js. Czym to się je?
Projekt, o którym pisałem ostatnio, musi trochę poczekać, bo w międzyczasie wpadłem na pomysł zrobienia gry w Three.js. Wzięło się to z tego, że ostatnio prowadzę rozmowy w sprawie współpracy z firmą, która robi projekt w WebGL i chciałem sobie przypomnieć temat robienia grafiki 3D w JavaScript. I z rozpędu zacząłem grę robić.
O grze napiszę później, jednak teraz trochę o samej bibliotece. Ale nie będzie to tutorial, tylko rzut okiem z lotu ptaka.
Jaki problem rozwiązuje ta biblioteka? Czy jeśli jest natywne api do robienia 3D w przeglądarce (WebGL), to czy warto w ogóle osobnej biblioteki używać? Czy to taki kaprys, podobny do używania jQuery w 2019 roku? Przecież można pisać w WebGL. Wyrzućmy biblioteki w kosmos!
Cóż, z używaniem suchego WebGLa jest taki problem, że tam proste rzeczy robi się w złożony niskopoziomowy sposób. Zróbcie sobie jakiś tutorial, to zobaczycie, że nawet, żeby wyrenderować obracającą się kostkę, trzeba się namęczyć.
Więc o ile warto poznać suchego WebGLa, zrobić, co to są bufory, shadery itp. jak to działa pod spodem... to na dłuższą metę zrobienie czegoś większego na czystym WebGL sprawiłoby, że trzeba byłoby albo do każdej pierdółki pisać masę niskopoziomowego kodu, albo poświęcić czas na napisanie "wrappera na WebGL" (czyli w zasadzie napisać "swoje Three.js", tzn. zestaw rutyn, który robi mniej więcej to, co robi już z automatu Three.js).
Dlatego warto użyć Three.js albo innej podobnej biblioteki, a pisanie w czystym WebGLu należałoby traktować jako zaawansowaną opcję.
Jak więc działa Three.js?
Masz scenę, i do niej wkładasz obiekty. Więc jest to tzw. "retained mode", bo scena będzie pamiętać, które obiekty zawiera. Scena jednak nie renderuje się sama. Żeby ją wyrenderować, musisz stworzyć obiekt renderera i kamerę.
Bardziej szczegółowo:
Tworzysz obiekt sceny, dodajesz do niej swoje obiekty w 3D, reprezentowane przez obiekty Mesh, czyli po polsku siatka. Żeby utworzyć siatkę musisz stworzyć geometrię (czyli w których miejscach mają być wierzchołki - możesz utworzyć np. gotową geometrię, która tworzy ci prostopadłościan czy kulę) oraz materiał (czyli jak się ma światło odbijać, jaka tekstura ma być itp.). I dodajesz tę siatkę do sceny. Dodajesz też jakieś światła, wiadomo. No i to jest twoja scena.
Jednak nic się nie pojawi na ekranie, dopóki jej nie wyrenderujesz. W tym celu tworzysz obiekt renderera, a potem wywołujesz metodę render i podajesz w niej obiekt sceny (żeby renderer wiedział, co ma renderować), oraz obiekt kamery (żeby renderer wiedział, jak przeliczać współrzędne świata na współrzędne ekranu). Aha, tę kamerę też musisz utworzyć wcześniej. No a potem po prostu ustawiasz parametry (współrzędne, rotacja itp.) siatek w kolejnych klatkach i renderujesz od nowa. I się animuje.
Cały ten proces bardziej szczegółowo i z przykładami kodu jest opisany w dokumentacji Three.js: Creating a scene
Co ciekawe - nie musisz tworzyć perspektywistycznej kamery (PerspectiveCamera), bo możesz utworzyć obiekt OrthographicCamera i będziesz mieć kamerę, która da ci izometryczny widok. Czyli możesz robić również gry izometryczne/2.5D używając Three.js.
Mało tego, możesz odjechać dalej i stworzyć obiekt StereoCamera, które może ci zrobić efekty 3D widoczne po założeniu okularów czy po zrobieniu zeza.
Ale nie musisz.
Anyway, po długiej przerwie postanowiłem wrócić do tej biblioteki, sam sobie muszę dużo przypominać. Pownie pojawi się coś jeszcze tutaj o Three.js, czy o grze, którą tworzę.
Na koniec chciałbym jeszcze powiedzieć, że nie jest to jedyna tego rodzaju biblioteka. Popularny jest też Babylon.js, z którego jeszcze nie korzystałem (jak skorzystam to pewnie też coś o nim napiszę).
O grze napiszę później, jednak teraz trochę o samej bibliotece. Ale nie będzie to tutorial, tylko rzut okiem z lotu ptaka.
Jaki problem rozwiązuje ta biblioteka? Czy jeśli jest natywne api do robienia 3D w przeglądarce (WebGL), to czy warto w ogóle osobnej biblioteki używać? Czy to taki kaprys, podobny do używania jQuery w 2019 roku? Przecież można pisać w WebGL. Wyrzućmy biblioteki w kosmos!
Cóż, z używaniem suchego WebGLa jest taki problem, że tam proste rzeczy robi się w złożony niskopoziomowy sposób. Zróbcie sobie jakiś tutorial, to zobaczycie, że nawet, żeby wyrenderować obracającą się kostkę, trzeba się namęczyć.
Więc o ile warto poznać suchego WebGLa, zrobić, co to są bufory, shadery itp. jak to działa pod spodem... to na dłuższą metę zrobienie czegoś większego na czystym WebGL sprawiłoby, że trzeba byłoby albo do każdej pierdółki pisać masę niskopoziomowego kodu, albo poświęcić czas na napisanie "wrappera na WebGL" (czyli w zasadzie napisać "swoje Three.js", tzn. zestaw rutyn, który robi mniej więcej to, co robi już z automatu Three.js).
Dlatego warto użyć Three.js albo innej podobnej biblioteki, a pisanie w czystym WebGLu należałoby traktować jako zaawansowaną opcję.
Jak więc działa Three.js?
Masz scenę, i do niej wkładasz obiekty. Więc jest to tzw. "retained mode", bo scena będzie pamiętać, które obiekty zawiera. Scena jednak nie renderuje się sama. Żeby ją wyrenderować, musisz stworzyć obiekt renderera i kamerę.
Bardziej szczegółowo:
Tworzysz obiekt sceny, dodajesz do niej swoje obiekty w 3D, reprezentowane przez obiekty Mesh, czyli po polsku siatka. Żeby utworzyć siatkę musisz stworzyć geometrię (czyli w których miejscach mają być wierzchołki - możesz utworzyć np. gotową geometrię, która tworzy ci prostopadłościan czy kulę) oraz materiał (czyli jak się ma światło odbijać, jaka tekstura ma być itp.). I dodajesz tę siatkę do sceny. Dodajesz też jakieś światła, wiadomo. No i to jest twoja scena.
Jednak nic się nie pojawi na ekranie, dopóki jej nie wyrenderujesz. W tym celu tworzysz obiekt renderera, a potem wywołujesz metodę render i podajesz w niej obiekt sceny (żeby renderer wiedział, co ma renderować), oraz obiekt kamery (żeby renderer wiedział, jak przeliczać współrzędne świata na współrzędne ekranu). Aha, tę kamerę też musisz utworzyć wcześniej. No a potem po prostu ustawiasz parametry (współrzędne, rotacja itp.) siatek w kolejnych klatkach i renderujesz od nowa. I się animuje.
Cały ten proces bardziej szczegółowo i z przykładami kodu jest opisany w dokumentacji Three.js: Creating a scene
Co ciekawe - nie musisz tworzyć perspektywistycznej kamery (PerspectiveCamera), bo możesz utworzyć obiekt OrthographicCamera i będziesz mieć kamerę, która da ci izometryczny widok. Czyli możesz robić również gry izometryczne/2.5D używając Three.js.
Mało tego, możesz odjechać dalej i stworzyć obiekt StereoCamera, które może ci zrobić efekty 3D widoczne po założeniu okularów czy po zrobieniu zeza.
Ale nie musisz.
Anyway, po długiej przerwie postanowiłem wrócić do tej biblioteki, sam sobie muszę dużo przypominać. Pownie pojawi się coś jeszcze tutaj o Three.js, czy o grze, którą tworzę.
Na koniec chciałbym jeszcze powiedzieć, że nie jest to jedyna tego rodzaju biblioteka. Popularny jest też Babylon.js, z którego jeszcze nie korzystałem (jak skorzystam to pewnie też coś o nim napiszę).
Komentarze
Prześlij komentarz