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/

• GammaJS: http://gammajs.org/
• J3D: http://www.everyday3d.com/j3d/
• Jax3D: http://blog.jaxgl.com/

• X3DOM: http://www.x3dom.org/

• Canvas 3D JS Library: http://www.c3dl.org/

• SceneJS: http://scenejs.org/

• GLGE :WebGL for the lazy: http://www.glge.org/

• three.js: https://github.com/mrdoob/three.js
• Getting started with three.js: http://www.aerotwist.com/lab/getting-started-with-three-js/

• Ambiera Copper Licht:  http://www.ambiera.com/copperlicht/

Jednym z poważnych zastrzeżeń odnośnie bezpieczeństwa przeglądarek wyposażonych w obsługę WebGL było to, że technologia ta może dawać możliwość ataku typu DoS oraz kradzieży grafiki miedzy domenami – jak ostrzega raport firmy Context (link) z maja 2011. Pierwszy wymieniony problem umożliwia zawieszenie komputera, co nie jest bardzo groźne w przypadku komputerów osobistych – co najwyżej spowoduje, że użytkownik nie będzie odwiedzał strony na której umieszczono szkodliwy kod. Jednak luka umożliwiająca dostęp do zasobów graficznych między rożnymi domenami, otwiera drogę do poważnych nadużyć (link). Autorzy specyfikacji odpowiedzieli na zarzuty opublikowane w raporcie, podając pewne rozwiązania na unikniecie niebezpieczeństwa i obiecując zająć się tymi kwestiami (link).

Jednym z założeń nowego standardu jest zwiększenie semantycznosci generowanych stron – do dotychczasowych tagów dodano takie jak nav, article, aside, footer (link). Pomogą one w lepszym rozumieniu treści przez roboty przeszukujące, a w rezultacie na łatwiejszą ich agregacje i wyszukiwanie (link). HTML5 de facto nie wprowadza jednak nowych funkcji do dokumentów WWW – jest to technologia która ułatwiać ma używanie mechanizmów już spotykanych na stronach. Można tu raczej mówić o zaakceptowaniu istniejącego stanu rzeczy i ujednoliceniu sposobów jego osiągania (link).

Zapewnia zatem HTML5 prosta obsługę i weryfikacje formularzy oraz zunifikowany interfejs do zaimplementowania metody przeciągnij i upuść (drag & drop) – czyli rzeczy, które były już obecne, ale dotychczas wymagały wykorzystania skryptów JavaScript. Podobnie osadzanie na stronie plików dźwiękowych oraz video, a także interaktywnej grafiki było możliwe – z użyciem zewnętrznych pluginów (najczęściej w formacie Flash). Specyfikacja HTML5 definiuje, w jaki sposób te media powinny być obsługiwane bezpośrednio przez przeglądarkę, bez potrzeby instalowania dodatkowych wtyczek (link).

Oprócz mechanizmów do odtwarzania dźwięku, oraz kontekstu do wyświetlania wideo wraz z określonym zestawem kodeków, jednym z interfejsów zaproponowanych do zintegrowania w HTML5 jest WebGL, realizowany wewnątrz elementu Canvas – czyli płótna o zdefiniowanych rozmiarach, po którym, przy pomocy odpowiednich procedur i poleceń, można rysować. Idea tego rozwiązania, polega na tym, że przeglądarka ma zapewnić interfejs programistyczny do sprzętowo wspomaganego generowania grafiki 3D. Integracja API z modelem DOM odbywa się przy pomocy języka JavaScript. WebGL bazuje na OpenGL ES 2.0 – jest to otwarty standard zarządzany przez organizację Khronos Group (link), przeznaczony dla systemów zintegrowanych (ang. Embedded System). Systemy zintegrowane lub wbudowane, to takie, w których sprzęt i oprogramowanie zostały zaprojektowane specjalnie dla siebie, w konkretnym celu (jak na przykład telefony komórkowe, palmtopy, konsole do gier). Za przykład przeciwny, podać można komputery PC, które uważa się za systemy wszechstronne (wiele różnych konfiguracji sprzętu może obsłużyć wiele programów przeznaczonych do różnych celów).

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/

Zaangażowanie się komercyjnych firm, które są w stanie zainwestować środki finansowe w stworzenie zawartości (ang. content) na daną platformę, daje dwie podstawowe korzyści. Po pierwsze powstaje coś zazwyczaj ciekawego, co ludzie chcą oglądać i dla czego są w stanie ponieść trud instalacji wtyczki na swoim komputerze. A po wtóre, rodzi się rzesza autorów, którzy specjalizują się w danej technologii (także dlatego, że wiedzą, iż będą za to wynagradzani). Tym tropem dochodzimy do sedna tego podrozdziału: jeśli autor stworzy treść na tyle dobrą, że użytkownicy są chętni za nią zapłacić, to prawdopodobnie będzie chciał ją zabezpieczyć – zarówno przed użytkownikami mniej skorymi do zapłaty, jak i przed innymi twórcami, którzy mogliby przywłaszczyć sobie pewne elementy jego dzieła.

Często zatem zdarza się, że firmy wybierają takie oprogramowanie, którego podstawową formą dystrybucji jest skompilowany plik wynikowy (jak na przykład plik swf w przypadku Adobe Flash), unikają natomiast rozwiązań, które dostarczane są pod postacią tekstowego kodu źródłowego (na przykład WebGL lub VRML). Naturalnie, żaden sposób nie zapewnia stuprocentowej ochrony, jednak kod maszynowy jest dużo trudniejszy do rozpracowania, podczas gdy w drugim przypadku jak na dłoni widać od razu wszystkie zastosowane rozwiązania. Jest na to rada w postaci programów szyfrujących kod źródłowy (ang. obfuscators lub scramblers), mogą one jednak obniżać wydajność aplikacji.

Jakiekolwiek nie byłyby to powody tej niechęci, faktem jest, że wysoka penetracja rynku jest niezaprzeczalnym atutem danego rozwiązania. Tak spektakularna popularność pluginu jak w przypadku Flasha jest zjawiskiem prawdopodobnie niepowtarzalnym (o czym świadczy chociażby średni sukces wtyczki Apple Quicktime). Idealnym rozwiązaniem byłaby zatem natywna dostępność oprogramowania w przeglądarce i dlatego duże nadzieje odnośnie Web3D pokładane są w technologii WebGL. Tutaj jednak na przeszkodzie staje firma Microsoft i jej dotychczasowe zapewnienia, że standard ten nie będzie obsługiwany przez przeglądarkę Microsoft Internet Explorer (patrz rozdział o WebGL). Kolejna odsłona „wojen przeglądarkowych” może skutecznie utrudnić sukces WebGL, podobnie jak poprzednia stała się gwoździem do trumny VRMLa.

Z drugiej strony, Adobe Flash nie jest obsługiwany przez urządzenia mobilne firmy Apple, co również ogranicza jego zasięg i odcina twórców od szczególnie dochodowego rynku aplikacji mobilnych. Jak dotąd, walka na rynku trwa, a wygrają ją prawdopodobnie rozwiązania, które będą w stanie dostarczyć treści jednocześnie na różne platformy (podobnie jak w tej chwili dzieje się z programami, które mogą jednocześnie współpracować ze sterownikami OpenGL lub Direct3D).

W witrynie zawarto informacje czym jest trójwymiarowa grafika oraz nakreślono podstaw niezbędnych do rozumienia sposobu jej generowania. Zaprezentowano język VRML, na podstawie którego prześledzono historię grafiki 3D oraz przeplatającej się z nią rzeczywistości wirtualnej. Wspomniano o martwych już dziś rozwiązaniach firm Adobe oraz Microsoft, które jednakowoż stanowią podwaliny sukcesu późniejszych projektów tych firm, a także są dobrą ilustracją na to, jak trudna to dziedzina. Dużo uwagi poświęcono technologii Java, która chociaż jest już dziś stabilna i wydajna, to nie może uwolnić się od złej sławy jaką obarczyły ją pierwsze wersje implementacji. Przedstawiono dotychczasową wersję Adobe Flasha, a także różne pluginy, między którymi znalazło się wiele silników do gier. Na końcu podsumowano wszystkie rozwiązania, umieszczając je w kontekście nadziei i trudności, z jakimi styka się Web3D.

Ze względu na mnogość rozwiązań i ich zróżnicowanie, wybór technologii wyświetlania grafiki trójwymiarowej na stronę internetową nie jest oczywisty. Niniejszy serwis powstała właśnie w celu ułatwienia tego zadania, a przynajmniej wskazania obszarów na które należy zwrócić uwagę. Z biegiem czasu, podejście twórców narzędzi do sposobu wykorzystania grafiki 3D uległo znacznej zmianie. Na samym początku trzeciego wymiaru w przeglądarkach, zakładano, że będzie to bogatszy, wygodniejszy i wizualnie atrakcyjny interfejs służący do obsługi wirtualnych światów. Bardzo ambitne plany odnośnie języka VRML nie zostały nigdy do końca zrealizowane, a cała historia standardu pokazuje wiele problemów z którymi do dziś styka się środowisko autorów interaktywnych, trójwymiarowych obrazów.

VRML dawał bardzo obszerny zestaw narzędzi i rozwiązań, które pozwalały w prosty sposób stworzyć wirtualny świat, ale narzucał też sztywne ramy, w granicach których należy się poruszać. Każda próba wykroczenia poza nie, skazana była na porażkę. Jednocześnie, w kolejnych wersjach standardu, starano się umieścić coraz więcej funkcji, komplikując tym samym i tak już nie łatwą implementację. Nie sposób wymyślić wszystkich możliwych zastosowań oprogramowania, jak również nie można programiście narzucać „jedynej słusznej” wizji. Z drugiej strony, zrozumiałym jest, że stworzenie silnika, który można w dowolny sposób modyfikować, może doprowadzić do tego, że każda aplikacja różni się od drugiej tak znacznie, że w efekcie trudno mówić o jakimkolwiek standardzie!

Dzisiejsze rozwiązania podchodzą w inny sposób do całego problemu. Nowoczesne technologie, takie jak WebGL lub Adobe Flash 11, skupiają się jedynie na tym, aby wygenerować grafikę o jak najlepszej jakości, w możliwie najkrótszym czasie. Stają się najniższą warstwą – interfejsem umożliwiającym „rysowanie” – podczas gdy ciężar logiki aplikacji i pozostałych niezbędnych jej składowych przerzucają na zewnętrzne oprogramowanie. Rozwarstwienie takie, nieobce w świecie informatyki, pozwala na dużą elastyczność, a także łatwiejszą kontrolę nad kodem źródłowym. Połączone aplikacje, z których każda wyspecjalizowana jest w jednej dziedzinie, wydają się być lepszym rozwiązaniem, niż jeden wszechstronny program. W każdym razie, jest to korzystne dla ogólnego rozwoju, szczególnie jeśli weźmie się pod uwagę model oprogramowania otwartego.