OSG.js (link) to intensywnie rozwijany projekt, bazujący na koncepcji OpenSceneGraph (link) – uznanego interfejsu programistycznego, wykorzystującego OpenGL, który implementuje metaforę grafu sceny. OSG.js pozwala przenieść mechanizmy stworzone dla potrzeb OpenSceneGraph do środowiska WebGL. CubicVR.js (link) jest konwersja popularnego silnika działającego dotychczas pod kontrola C++. Projekt ten wygląda jednak na dość hermetyczny i przeznaczony dla ludzi znających już dobrze OpenGL – nie mniej, jego możliwości techniczne są bardzo ciekawe. Kolejnym projektem, który sprawia niestety wrażenie zaniedbanego, jest O3D (link) od Google. Poczałkowo był to plugin, który został następnie przetłumaczony na WebGL. Jako taki działa i jest to kompletne, dojrzale API – jednak od dłuższego czasu nie jest już rozwijane. Google porzucił prace nad O3D jak samodzielnym pluginem, na rzecz popularyzacji WebGL (link).

• SpiderGL: http://spidergl.org/
• JS3D: http://www.wxs.ca/js3d/
• Pre3d: http://deanm.github.com/pre3d/
• osg.js: http://osgjs.org/
• OpenSceneGraph: http://www.openscenegraph.org/projects/osg
• CubicVR 3D engine: http://www.cubicvr.org/
• o3d: http://code.google.com/p/o3d/

Istnieje wielu specjalistów znających język OpenGL, także wiele zasobów i szkoleń, wyjaśniających jego tajniki – jak wiadomo, jest to standard zupełnie otwarty, a za korzystanie z niego nie są pobierane żadne opłaty. Wszystko to stanowi bazę niezbędną do rozwoju technologii i stanowić może o jego sukcesie lub porażce. Gdyż, o ile jest to rozwiązanie niezwykle elastyczne i dający ogromne możliwości, to cechuje je wysoki stopień skomplikowania – nie sposób efektywnie wykorzystać możliwości danych przez OpenGL, jeśli nie posiada się odpowiednich umiejętności programistycznych lub nie zna się podstaw przekształceń matematycznych wykorzystywanych do generowania trójwymiarowej grafiki (link). Nawet wtedy, stworzenie nawet najprostszego obrazu, wymaga napisania sporej ilości linii kodu i może nie być bardzo intuicyjne, szczególnie, że jest to język stanowy (link) i nie korzysta z abstrakcji wyższego rzędu, jak na przykład metafora grafu sceny, często spotykana w innych rozwiązaniach.

Zbudowanie najprostszego sześcianu, wymaga zdefiniowania 24 trójwymiarowych współrzędnych, osobno dla każdego wierzchołka Do tego dodać należy kod niezbędny do wywołania biblioteki WebGL, otrzymania kontekstu płótna w przeglądarce, zainicjowanie programów cieniujących, zdefiniowanie kolorów wierzchołków, zaaplikowania odpowiednich transformacji w przestrzeni, ustawienia kamery, a ostatecznie wygenerowania obrazu (link). Wraz ze zwiększeniem ilości zarządzanych elementów, z których składa się model – stopień skomplikowania rośnie bardzo szybko. Na szczęście, WebGL kontrolowany jest z poziomu języka JavaScript i istnieje wiele bibliotek, które zapewnia kontrole nad projektowaniem grafika, podczas gdy interfejs programistyczny zapewni wydajna i sprzętowo wspomagana jej generacje.

Jedna z niewątpliwych zalet WebGL, jest jego pełną integracja z HTMLem – zarówno programy cieniujące, jak i pozostałe elementy standardu programowane są przy pomocy skryptów JavaScript. Generowanie obrazów w kontekście elementu składowego HTML5, jakim jest canvas3D, zapewnia zgodność z modelem dostępu do obiektów w obrębie dokumentu HTML – DOM (document object model). Zagwarantowana została dzięki temu możliwość pełnej, dwukierunkowej komunikacji miedzy elementami na stronie, a tymi odpowiedzialnymi za obsługę grafiki wewnątrz kontekstu płótna. Użycie JavaScript, otworzyło także WebGL na wykorzystanie bogatego zestawu oprogramowania JS napisanego nie tylko z myślą o grafice trójwymiarowej. Jedna z bibliotek niezwykle pomocnych przy tworzeniu obrazów 3D jest Sylvester – ułatwia ona wykonywanie działań na wektorach i macierzach (link).

Scena silników korzystających z WebGL nie jest jeszcze tak rozwinięta, jak tych, które współpracują z Flashem. Jest to wszak technologia dużo młodszą – pierwsza oficjalna wersja standardu została ogłoszona w marcu 2011 roku (link). Jednak jeszcze zanim to nastąpiło, zaczęły pojawiać się biblioteki wspomagające tworzenie przy użyciu WebGL. Pomoc ta oznacza rożne rzeczy – od zmniejszenia ilości kodu, po ułatwienie zapanowania nad logika sceny, na przykład poprzez zorganizowanie jej w graf. Jak dotąd, ciężko wskazać jeden engine który byłby najlepszy do wszelkich zastosowań – wszystkie one są wciąż w fazie rozwoju i optymalizacji. Istnieje jednak pewna grupa bibliotek, które wyróżniają się spośród reszty – bądź to stopniem zaawansowania lub obszerna dokumentacja. Niektóre z nich przedstawiono w kategorii WebGL.

Nie wszyscy producenci oprogramowania wspierają rozwój otwartych standardów. Chociaż Microsoft nie stwierdził definitywnie, że nie zamierza wspierać WebGL w kolejnych wydaniach Internet Explorera, to jednak ani IE9 (link) (wydany w podobnym czasie co pierwsza kompletna specyfikacja WebGL 1.0), ani zapowiadany dopiero IE10 (link), standardu tego nie obsługują. W zamian, proponuje sprzętowe wspomaganie dla elementu Canvas2D (link). Ocena strategii Microsoft odnośnie kierunku rozwoju przeglądarki Internet Explorer, a także podejścia firmy do „otwartych” standardów, nie nalezą do obszarów tej publikacji – o reakcji internautów może się jednak przekonać, na przykład czytając komentarze pod oficjalna notka zapowiadająca najnowsza wersje IE (link). Nie sposób wszak zignorować faktu, że niechęć twórców jednej z wiodących przeglądarek, względem WebGL, znacząco hamuje rozwój i ogranicza ogólnodostępny tej technologii.

Upowszechnianie tej technologii wydaje się być nieuniknione i jest tylko kwestia czasu. Twórcy standardu zaproponowali bezprecedensowe podejście w kwestii dostępu do sprzętowych zasobów domowych komputerów, które dotąd wykorzystywane były głownie przez gry i programy do modelowania. Umożliwia to nie tylko tworzenia bogatych interfejsów oraz efektownych wizualizacji na stronach www, ale otwiera drogę do aplikacji webowych niespotykanej jak dotąd jakości wizualnej. Jedna z niewątpliwych zalet formatu, jest to, że oparty jest na technologii OpenGL ES, która obsługiwana jest nie tylko w komputerach stacjonarnych i laptopach, ale także we wszelkiego rodzaju urządzaniach mobilnych, smartphone’ach i tabletach (link) (w przeciwieństwie do rozwiązań proponowanych przez Adobe, czy Microsoft).

• WebGL: http://www.khronos.org/webgl/
• Sylvester: http://sylvester.jcoglan.com/

Najpopularniejszymi rozwiązaniami pozwalającymi na zunifikowany kontakt oprogramowania ze sprzętem, są Direct3D (link) oraz OpenGL (link). Pierwsze z nich jest częścią zestawu bibliotek DirectX firmy Microsoft, który należy pobrać z internetu (niemal zawsze jest też dostarczany z programem który go wykorzystuje) i zainstalować na komputerze. OpenGL korzysta z innego podejścia – nie istnieje jako niezależny program lub biblioteka, która można pobrać, ale polega na implementacjach producentów sprzętu, które dostarczane są razem ze sterownikami kart graficznych. Odmienność obydwu API nie wynika dziś z istotnych różnic w sferze ich możliwości technicznych – od początku istnienia obu, nowe możliwości pojawiające się w jednym ze standardów, były wkrótce implementowane w drugim – widać ja natomiast wyraźnie w kwestii dostępności i wykorzystania.

Przede wszystkim, Direct3D jest własnościowym rozwiązaniem i Microsoft dostarcza je tylko dla systemów z rodziny Windows (w tym Windows Mobile). Co więcej, najnowsze wersje DirectX 10 oraz 11 dostępne są jedynie dla Windows Vista oraz Windows 7 – podczas gdy jedynie ok. 50% użytkowników korzysta z tych dwóch systemów (reszta rynku wciąż należy do Windows XP) (link). Interfejs jest także wykorzystywany w konsolach spod znaku Xbox. OpenGL to API niezależne, nad którym opiekę sprawuje Khronos Group. Posiada implementacje na niemal każdą platformę sprzętową – nie tylko Windows, ale Mac OS i Unix/Linux również (zastosowania mobilne obsługiwane są przy pomocy OpenGL ES).

Od strony programistycznej, należy zwrócić uwagę na to, że DirectX jest kompletna biblioteka, przeznaczona przede wszystkim do tworzenia gier. Posiada mechanizmy obsługi dźwięku oraz urządzeń wejściowych. Jej architektura jest obiektowa. OpenGL jest natomiast API przystosowanym wyłącznie do generowania grafiki, a do obsługi pobocznych zadań dostępne są oddzielne biblioteki. Rozwiązanie Microsoftu miało w przeszłości dużo bardziej skomplikowana strukturę i postrzegane było jako znacznie trudniejsze do nauczenia się. Szerokim echem odbił się szczególnie list otwarty Johna Carmacka, prekursora i twórcy gier z serii Doom oraz Quake (link), w którym wytykał on wady Direct3D i nie szczędził pochwal dla OpenGL – wyrażając prawdopodobnie zdanie wielu programistów 3D.

W ciągu paręnastu lat od czasu kiedy list ten został opublikowany, oba interfejsy ewoluowały, wraz z rozwojem możliwości sprzętowych komputerów osobistych. Współczesny rynek komputerowej rozrywki jest zdominowany przez programy korzystające z DirectX (link), natomiast OpenGL jest wykorzystywany głownie w profesjonalnych aplikacjach do tworzenia trójwymiarowej grafiki (link). Zdążają się też gry korzystające z tego API, natywnie lub konwersjach z Windows na inne platformy. OpenGL jest niezastąpiony, jeśli program wydawany jest na rożne platformy (w tym również mobilne). Pomijając wszelkie „święte wojny” (link) oraz doniesienia o nieczystych praktykach Microsoftu w celu zdeklasowania konkurenta (link), OpenGL idealnym rozwiązaniem do zastosowań internetowych, opisywanych w tej pracy.

• OpenGL: http://www.opengl.org/

• LWJGL – Lightweight Java Game Library: http://www.lwjgl.org/

• Jogamp: http://jogamp.org/
• JSR 231: Java Binding for the OpenGL API: http://jcp.org/en/jsr/detail?id=231
• Gluegen: http://jogamp.org/gluegen/www/