1

WebGLHet web in een derde dimensie

4

Colofon

5

AuteurNaam Jorick van Hees

Studentnummer 0803962

E-mailadres jorickvanhees@gmail.com

Website jorickvanhees.com

Instituut Communicatie, Media en Informatietechnologie

Opleiding Communication & Multimedia Design

Minor Game Design & Development

Begeleiding Hogeschool RotterdamEerste begeleider Rob van der Willigen

Tweede begeleider Rolf den Otter

AfstudeerbedrijfNaam Studio i2

Website i2.nl

Begeleiding Ivo Bakker

6

Een onderzoeksscriptie naar de praktische en functionele mogelijkheden van WebGL. Deze

techniek maakt het mogelijk om de rekenkracht van de grafische kaart te benutten in de

webbrowser, waarmee het mogelijk wordt om geavanceerde, interactieve 3D beelden weer

te geven op het web.

Het onderzoek maakt duidelijk wat de belangrijke factoren zijn bij 3D op het web, en wat

er belangrijk is bij het gebruik van webtechnieken. Daarnaast is de techniek WebGL onder-

zocht op het gebied van ondersteuning, mogelijkheden, huidige toepassingen, ontwikkel-

proces en toekomstperspectieven. In samenwerking met een 3D studio is er een prototype

ontwikkeld met WebGL die het onderzoek ondersteund vanuit de ervaring die is op gedaan

uit de praktijk.

Met deze kennis wordt er inzicht gegeven in het gebruik van WebGL in praktische en func-

tionele interactieve 3D toepassingen. Tevens laat het zien wat de voor-, en nadelen zijn

van WebGL in de producten van een bedrijf.

AbstractNederlands

7

A research to the practical and functional possibilities and implications with WebGL. This

technology makes it possible to use the power from the graphics processing unit inside the

webbrowser, and enables the possibility to create advanced and interactive 3 dimensional

images on the web.

The study makes the important factors in 3D on the web clear and what is important when

using webtechnologies. In addition, WebGL is examined in terms of possibilities, support,

current applications, development and future prospects. A prototype is developed in col-

laboration with a 3D visualization company which supports the study with the experience

gathered in practice.

This knowledge gives insight in the use of WebGL in practical and functional, interactive

3D applications. At the same time, it shows what the pros and cons are of WebGL in rela-

tion to the products of a company.

AbstractEnglish

8

Voorwoord

9

Deze scriptie vormt de afsluiting van mijn opleiding Communication & Multimedia Design

aan de Hogeschool Rotterdam. 4 jaar lang ben ik bezig geweest met interactie, ontwerp

en techniek. Deze scriptie is de afsluiting van die belangrijke periode in mijn leven, een

periode die in het teken stond van creativiteit, gezelligheid, stress en kennis.

De volgende mensen wil ik bedanken, zonder hen had ik nooit tot dit eindresultaat kunnen

komen:

Rob van der Willigen

Voor de begeleiding, de enorme kennis van het onderzoeken, de feedback en het vertrou-

wen. Zonder de feedback over het onderzoeksprocess had ik deze scriptie nooit op deze

manier kunnen schrijven.

Rolf den Otter

Voor de feedback tijdens de officiële bijeenkomsten.

Ivo Bakker en Studio i2

Voor de mogelijkheid om af te studeren bij een bedrijf dat mijn onderwerp heel goed kon

ondersteunen. Ik heb veel geleerd en heb het naar mijn zin gehad in mijn stageperiode.

Ook wil ik graag Ward van Teijlingen en Joost van den Berg bedanken voor de support,

de afleiding en de feedback tijdens de gehele opleiding. Als laatste wil ik mijn ouders

bedanken voor het vertrouwen, de ondersteuning en support wanneer ik dat het hardst

nodig had.

“You can’t connect the dots looking forward; you can only connect them look-

ing backwards. So you have to trust that the dots will somehow connect in your

future.”

Steve Jobs

10

Inhoud

11

1 Inleiding 12

2 Webtechnieken 20

3 3D visualisatie 40

4 Studio i2 52

5 Productconfigurator 60

6 Conclusie 74

7 Begrippenlijst 80

8 Bibliografie 84

9 Bijlagen 88

12

1

Vanwege de grote opkomst van het web is de vraag naar webtechnieken die de gebruik-

erservaring kunnen verbeteren, enorm gestegen (Anttonen, Salminen, Mikkonen, &

Taivalsaari, 2011). HTML5, CSS3 en Canvas zijn allemaal bekende voorbeelden van zulke

webtechnieken. Met behulp van deze technieken is het mogelijk om complete desktopap-

plicaties te bouwen in standaard webbrowsers, inclusief alle mogelijkheden die je gewend

bent van reguliere applicaties. Met behulp van de recente techniek WebGL wordt het mo-

gelijk om geavanceerde 3D computergraphics te integreren in deze applicaties die draaien

binnen huidige populaire browsers zoals Chrome, Firefox en Safari.

Inleiding

13

2.1 Bedrijfsinformatie

2.2 Probleemstelling

2.3 Onderzoeksvraag

2.4 Doelstelling

2.5 Conceptueel Model

2.6 Methodiek

14

1.1 BEDRIJFSINFORMATIE

Studio i2 in Delft is een bedrijf wat zich bezig houd met voornamelijk 3D visualisaties. Ze

zijn gespecialiseerd in de vastgoedsector maar willen zich in de toekomst meer richten op

andere markten waarin ze hun kennis van 3D visualisatie kunnen inzetten. Zo zijn ze nu

bezig met een aantal productconfigurators en websites welke veel 3D elementen herber-

gen.

Het bedrijf is voortdurend op zoek naar nieuwe technieken en ideeën om het aanbod voor

klanten uit te breiden en te verbeteren. Door het kleine aantal werknemers is het voor Stu-

dio i2 onmogelijk om alle nieuwe ontwikkelingen op de voet te volgen en uit te proberen.

De opleiding Communication & Multimedia Design streeft altijd naar het onderzoeken

en gebruiken van nieuwe multimediatechnieken, iets waar Studio i2 dus in potentie veel

voordeel uit kan halen.

Deze scriptie heeft als doel om Studio i2 inzicht bieden in het praktisch gebruik en nut

van WebGL voor een kleinschalig multimediaal bedrijf zoals Studio i2. Het bedrijf moet

aan de hand van deze scriptie kunnen beslissen of ze met WebGL aan de slag gaan, en wat

ze daarvoor dan moeten doen. Om het proces van het maken van een WebGL applicatie

inzichtelijk te maken voor het bedrijf, is er een stappenplan vervaardigd met daarin de

stappen die ik als CMD-professional heb gezet bij het ontwikkelen van een tastbaar en

toetsbaar technisch prototype.

1.2 PROBLEEMSTELLING

De ervaring van een gebruiker op het web over datgene wat wordt aangeboden, neemt

een steeds belangrijkere rol in voor bedrijven die actief zijn binnen de creatieve industrie.

Tegenwoordig zijn websites dynamisch, zij passen zich aan op de behoefte en gedrag van

een gebruiker en combineren verschillende webtechnieken om een zo meeslepende en

betekenisvolle ervaring te bewerkstelligen.

Opvallend daarbij is dat 3D tegenwoordig steeds meer aanwezig is binnen de wereld

van multimedia (Sons, Klein, Rubinstein, Byelozyorov, & Slusallek, 2010). Een goed en

veelgebruikt voorbeeld hiervan is een 3D configurator van een product, waarbij je online

je product kan aanpassen aan je eigen smaak en wensen (zo heeft Porsche een state-of-

the-art configurator ontwikkeld waarmee het mogelijk is om een auto samen te stellen in

3D - http://www.porsche.com/international/modelstart/). Op dit moment wordt dit vaak

gedaan door middel van Flash of Javascript in combinatie met statische afbeeldingen (zie

hoofdstuk ?), maar aan deze technieken zitten een aantal voordelen en nadelen vast.

Ook andere visualisaties maken vaak gebruik van vrij omslachtige manieren voor 3D

weergave. Niet economisch efficiënt om te maken, maar vaak ook niet fijn voor de eindge-

bruiker, die soms een plugin moet installeren om alle content te bekijken wat de wachttijd

15

aanzienlijk langer maakt (Fui-Hoon Nah, 2004).

Er bestaat dus een vraag naar een goede, productieve en kostenefficiënte manier om 3D

content te implementeren in browsers. Het is dus zoeken naar een manier die kwaliteit en

gebruiksgemak bied voor de eindgebruiker, maar ook past in de workflow van een bedrijf.

Een techniek die projecten met een korte looptijd en veel lastminute aanpassingen mo-

gelijk maakt en vergemakkelijkt. Ook moet het bruikbaar zijn voor een 3D artist die vaak

de technische kennis van een programmeur mist.

1.3 ONDERZOEKSVRAAG

Mijn hoofdvraag luidt:

Wat is de praktische toepasbaarheid van WebGL voor interactieve 3D toe-

passingen op het web?

Om deze hoofdvraag op een goede manier te kunnen beantwoorden, is het belangrijk

dat ik mij eerst verdiep in huidige webtechnieken en bekijk wat de relatie daarvan is tot

WebGL. Dit verschaft inzicht in de huidige status en relevantie van WebGL op het web en

welke plaats deze techniek heeft binnen de huidige webtechnieken (hoofdstuk 2).

Ook is het noodzakelijk om te onderzoeken hoe WebGL zich verhoudt tot bestaande

3D visualisatietechnieken en te bekijken wat de voordelen en nadelen hiervan zijn ten

opzichte van elkaar. Op deze manier wordt WebGL niet alleen vergeleken met andere

technieken op het web, in verband gebracht met theorieën die zich uit spreken over wat

goede visualisaties nu eigenlijk zijn, iets wat cruciaal is voor mijn onderzoek (hoofdstuk

3). Binnen de 3D wereld bestaan namelijk al veel technieken waar een complete workflow

omheen zit. Het is belangrijk om te kijken hoe WebGL daar tussen past en wat een verand-

ering in de techniek betekend binnen een bedrijf, de workflow en het resultaat.

1.4 DOELSTELLING

De conclusies uit mijn literatuurstudie (hoofdstuk 2 en 3) zijn samen gebracht in een

conceptueel model dat hieronder is weergegeven (figuur x). Dit model moet inzicht geven

in het gebruik van WebGL met betrekking tot het ontwikkelen van een functioneel product

door kleine bedrijven zoals Studio i2.

Dit conceptuele model wordt afgezet tegen een case studie van Studio i2 en een product

dat zij ontwikkelen. Hierbij komen onder andere de producten aan bod (zoals reeds eerder

besproken de productconfigurator), de workflow en het type klanten. Met behulp van deze

werkwijze moet het mogelijk zijn om een antwoord te geven op de vraag van Studio i2 of

WebGL een geschikte techniek voor het bedrijf is.

16

1.5 CONCEPTUEEL MODEL

Dit conceptueel model beschrijft in het kort de stappen die nodig zijn bij het ontwikkelen

van een 3D webapplicatie met WebGL. Het conceptueel model bestaat uit 3 stappen: De

keuze van de gewenste producteigenschappen, de keuze van de technische laag binnen

WebGL voor de ontwikkeling en het uiteindelijke product. Deze stappen zijn in een uit-

gebreidere vorm terug te vinden in hoofdstuk 5.1, waarin ik beschrijft hoe ik deze stappen

zelf heb gezet in de 5 maanden die ik stage heb gelopen.

Stap 1 komt voort uit hoofdstuk 2: 3D visualisatie. Er wordt daarin beschreven wat er

belangrijk is binnen de wereld van 3D visualisatie en applicaties. Daar uit blijkt dat er

twee factoren van belang zijn, namelijk de kwaliteit en interactiviteit (zie voor meer uitleg

hierover de conclusie van hoofdstuk 2). Deze factoren moeten tegenover de kosten (of

budget) worden gezet, omdat dat een belangrijk aspect is van een concept (zie hoofdstuk

4: Studio i2). In deze stap moeten de eisen aan het product concreet worden gemaakt, deze

eisen zijn namelijk van belang in de volgende stap.

Stap 2 komt uit hoofdstuk 3: Webtechnieken en WebGL. In dit hoofdstuk wordt er gekeken

naar de ontwikkeling van WebGL en hoe dit zich verhoudt tot andere technieken op het

web. In dit deel moet ook rekening worden gehouden met de keuzes die zijn gemaakt in

deel 1. Er zijn 3 verschillende lagen binnen de ontwikkeling van WebGL, die elk op een

ander niveau zitten qua complexiteit. In deze stap is het belangrijk om te kiezen voor één

van deze lagen, deze keuze moet onderbouwd zijn met de eisen uit stap 1.

Stap 3 is het product wat is voortgekomen uit de resultaten uit stap 1 en 2. De twee voor-

gaande stappen bepalen in grote mate hoe het product er uit komt te zien qua techniek en

leggen de basis voor het technische model van het product. Het product dat ik heb ontwik-

keld is beschreven in hoofdstuk 5.

17

Figuur 1: Conceptueel model

1Kwaliteit

Interactiviteit

Gewenste producteigenschappen

Kosten

2

3

Framework

Native WebGL

Keuze van technische laag binnen WebGL voor deontwikkeling van een webapplicatie

Product

Content Management System

18

1.6 METHODIEK

Het prototype heb ik ontwikkeld met als doen inzicht te verwerven in het ontwikkelen

van WebGL in combinatie met Three.js. Dit proces levert praktische informatie die samen

met de informatie uit het literair onderzoek een goed beeld kan geven over het ontwik-

kelen van WebGL applicatie, de voor- en nadelen, workflow en problemen die ik tegen ben

gekomen.

Op dit gebied verschilt mijn scriptie in grote mate met de opbouw van andere scripties,

waarin de conclusies van het onderzoek worden gebruikt in de ontwikkeling van het

prototype. Bij deze scriptie is dat dus omgedraaid, omdat de kennis uit het onderzoek veel

waardevoller is dan het prototype. Het prototype is dus puur ontwikkeld om het onderzoek

te ondersteunen.

In de 5 maanden bij het 3D visualisatiebureau Studio i2 heb ik veel meegekregen over het

maken van 3D visualisaties. Het bedrijf kon mij vertellen wat hun workflow was, welke

klanten zij hadden en welke problemen zij tegen kwamen tijdens het ontwikkelen van

webapplicaties. Omdat een 3D visualisatiebureau heel andere kennis in huis heeft dan een

gemiddelde webontwikkelaar, hebben zij een compleet ander beeld van webtechnieken,

wat erg interessant is voor het onderzoek. Op deze manier is het mogelijk om WebGL

op een heel andere manier te bekijken, vooral op het gebied van visuele kwaliteit en de

voordelen voor een klant en eindgebruiker.

De expertise van het bedrijf, mijn ervaring in WebGL en Three.js door het prototype en de

informatie uit het literair onderzoek moeten er voor zorgen dat ik een gedegen antwoord

kan geven op de hoofdvraag en een goed advies aan het bedrijf van uitbrengen over de

techniek WebGL.

19

20

2

Sinds het ontstaan van het web heeft men continue nieuwe technieken ontwikkeld om

de groei van het web te ondersteunen. De eerste techniek die speciaal voor het web

was ontwikkeld was de HyperText Markup Language. Deze techniek was oorspronkelijk

bedoeld om documenten weer te geven binnen een browser (vandaar ‘markup’, oftewel

‘opmaak’), maar is ondertussen uitgegroeid naar een taal om interactieve applicaties te

maken met hulp van CSS en Javascript.

In dit hoofdstuk wil ik onderzoeken welke factoren van belang zijn bij het gebruik van, en

ontwikkeling met webtechnieken. Daarnaast wordt WebGL onderzocht op het gebied van

ontwikkeling, gebruik en (bestaande) toepassingen, om hiermee inzichtelijk te maken hoe

WebGL zich verhoudt tot andere webtechnieken.

Webtechnieken

21

2.1 User Centered Development

2.2 Media op het web

2.3 Mobiele platform

2.4 Ontwikkeling

2.5 Huidige staat van WebGL

2.6 Toepassingen, mogelijkheden en toekomst

2.7 Conclusie

22

2.1 USER CENTERED DEVELOPMENT

Wanneer men een webapplicatie gaat bouwen, is het een goed idee om van te voren te ki-

jken naar de technieken die men wilt gebruiken, en de ondersteuning daarvan. In het boek

“User-centered Web development” geeft Jonathan Lazar aan dat het van groot belang is

dat men altijd de gebruiker in het achterhoofd houd bij het ontwikkelen voor het web. Niet

alleen binnen het ontwerpprocess, maar zeker ook op het gebied van ontwikkeling.

“Web developers should not substitude their own personal preferences for

the principles of user-centered design. What a web developer might consider

“cool”, a user might consider to be annoying. A web developer’s perceptions and

knowledge base can thus be quite different from those of the targeted users of the

technology.”

Lazar, 2001

Wat ik hieruit opmaak, is dat een technologie niet moet worden gekozen vanuit het oog-

punt van ontwikkeling, maar vanuit de gebruiker. Het is goed mogelijk dat een techniek

zeer veelbelovend is qua technische mogelijkheden, maar totaal onbruikbaar is voor een

eindgebruiker omdat de techniek niet aansluit op de eindgebruiker, bijvoorbeeld door de

missende ondersteuning van de browser die wordt gebruikt.

23

2.2 MEDIA OP HET WEB

Multimedia op het web is vaak interactief en speelt in op de gebruiker, websites spelen in

op de wensen van een gebruiker en proberen een zo betekenisvolle ervaring te creëren

voor een consument (Ha & McCann, 2008).

2.2.1 Wachttijden voor de gebruiker

Vele onderzoeken hebben uitgewezen dat de aandachtsspanne van een gebruiker op het

internet bijzonder kort is. Bij het laden van een pagina is dit zo’n 4 seconde, als de pagina

dan nog steeds niet is geladen en er wordt geen indicatie gegeven dat het nog werkt, zal

de gebruiker de pagina verlaten. Jakob Nielsen (Nielsen, 1993) beschrijft in zijn boek “Us-

ability Engineering” 3 belangrijke momenten van wachttijden. 1 seconde is de limiet qua

wachttijd wanneer je de ervaring van de gebruiker niet wil onderbreken. Het is dus belan-

grijk dat de content binnen die seconde is geladen en op het scherm staat, zeker wanneer

ze midden in een applicatie zitten (zoals een product-configurator).

Tegenwoordig worden internetverbindingen steeds sneller, de gemiddelde snelheid van

een internetverbinding in Nederland is in kwartaal 3 van 2011 bijna 8,5 MB/s; iets meer

dan 1 MB/s (akamai.com, n.d.). Het downloaden van een afbeelding van 500 KB duurt on-

geveer een halve seconde. Er moet natuurlijk rekening worden gehouden met de snelheid

van een server en meerdere gebruikers op een internetverbinding, maar 1 MB/s is een

goede maat om aan te houden. Mocht er onverhoopt toch meer data moeten worden inge-

laden, dan is het aan te raden om aan de gebruiker aan te geven dat hij bezig is met laden.

Figuur 2: Belangrijke momenten in de

wachttijden van een gebruiker binnen

een applicatie

Onmiddelijke ervaring

Onafgebroken ervaring

0.1 seconde

1 seconde

Aandachtsspanne10 seconde

24

2.2.2 Computersnelheid

Naast de tijd die het kost om de content in te laden van het internet, is het ook belangrijk

om te kijken naar de snelheid van een computer. Het is heel goed mogelijk dat de content

snel gedownload is, maar dat het systeem waar de gebruiker op werkt niet de gewenste

rekenkracht bevat. Dat kan betekenen dat de gebruiker alsnog enkele seconden moet

wachten op een reactie in de applicatie, zeker bij complexe webapplicaties en zware

grafische beelden. Dit is iets wat lastig te beïnvloeden is, maar het is een goed idee om dit

mee te nemen met de ontwikkeling van een applicatie.

Hoewel computers steeds sneller worden, komen apparaten als netbooks hard in opkomst.

Deze klein laptops zijn weliswaar volwaardige computers, maar hebben aanzienlijk minder

rekenkracht aan boord (vooral op grafisch gebied). Ook tablets worden steeds vaker

verkocht en zijn vaak trager dan conventionele computers.

25

2.3 MOBIELE PLATFORM

Met de komst van de iPhone in 2007 is de markt voor smartphones gigantisch gegroeid. In

kwartaal 3 van 2011 zijn er 118.1 miljoen smartphones verkocht (een groei van 42,6% ten

opzichte van kwartaal 2 - International Data Corporation, 2011). Ook dankzij de opkomst

van tablets is het duidelijk dat de klassieke computer heel hard terrein verliest op het

internet. Het aandeel van internetverkeer van “web-enabled handheld devices” - zoals

smartphones en tablets - was bijna 10% in 2011, met de verwachting dat dit in 2012 hard

zal stijgen (comScore, 2012). Overigens worden in deze cijfers alleen het reguliere HTTP

verkeer meegenomen. Applicaties die uit de verschillende app-stores komen worden niet

meegeteld.

2.3.1 Technieken op mobiele telefoons

Deze cijfers geven aan dat mobiele platformen een grote rol gaan spelen in de toekomst

van het web. Op het gebied van interactie en ontwerp, maar ook zeker in de technieken die

gebruikt worden. Een bekend voorbeeld hiervan is Flash van Adobe. Toen bekend werd dat

Apple’s iPhone geen Flash zou ondersteunen (Jobs, 2010), was er heel veel ophef. Flash

was één van de belangrijkste technieken om rijke gebruikerservaringen op het web te bou-

wen. Omdat de iPhone van Apple zo goed verkocht, lieten steeds meer bedrijven Flash val-

len en gingen over op andere technieken. De ontwikkeling van alternatieven zoals HTML5

en CSS3 kreeg een grote duw in de rug door de vraag naar een goede vervanger. Adobe

heeft zelf aangegeven dat ze Flash niet verder ontwikkelen voor mobiele platformen, maar

in plaats daarvan hun focus zullen leggen op HTML5 (Winokur, 2011).

Deze trend is terug te zien in de ondersteuning van webstandaarden van mobiele brows-

ers. Waar browsers op regulieren desktop computers vaak nog bepaalde functies niet

ondersteunen (met name Internet Explorer), zijn mobiele browsers hier een stuk verder in.

2.3.2 Mobile 3D

Ook op mobile gebied gebeurt er een hoop qua 3D. Er worden op dit moment gigantisch

veel games gemaakt voor smartphones en tablets. Vaak zijn deze games gewone applica-

ties die te downloaden zijn uit de verschillende ingebouwde App-stores. Het nadeel van

deze losse applicaties, is dat er verschillende versies ontwikkeld moeten worden voor elk

platform. Effectief ben je een applicatie dan meerdere keren aan het bouwen, en dat kost

veel tijd en geld.

Een groot deel van de smartphonemarkt ondersteund geen flash, voornamelijk door het

missen van Flash op Apple’s mobiele apparaten. Adobe heeft zelf ook aangegeven dat ze

Flash niet meer verder ontwikkelen voor mobiele apparaten (Winokur, 2011). Complexe

3D visualisaties worden hierdoor lastig op mobiele telefoons door de missende techniek.

Ook omdat het bij mobile development belangrijk is om de hoeveelheid data die wordt

gebruikt, in de gaten te houden, waardoor er niet vele afbeeldingen doorgestuurd kunnen

worden.

26

De hardware in mobiele apparaten maakt gigantische sprongen, in de nieuwste generatie

smartphones zit al een Quad-core processor, samen met een geavanceerde grafische chip.

Fabrikanten zijn druk bezig om ook de mobiele browsers “WebGL-compatible” te maken.

Zo is de Sony Ericsson Xperia 1 de eerste Android telefoon die WebGL ondersteund (Isberg,

2011). Door deze ontwikkelingen kunnen we redelijk zeker zeggen dat WebGL binnenkort

ook beschikbaar wordt voor de mobiele telefoon.

2.3.3 Mobiele internetverbindingen

Met de opkomst van de smartphone en tablet wordt er ook steeds meer gebruik gemaakt

van een mobiele internetverbinding (statowl.com, n.d.). Mensen zijn tegenwoordig altijd

online via hun smartphone. Dit heeft vele voordelen en nadelen, zo biedt het heel veel

mogelijkheden voor interactieve installaties op locatie, maar moet er wel rekening worden

gehouden met een internetverbinding, die is namelijk stukken trager dan een vaste lijn.

Wel moet er opgemerkt worden dat het gebruik van een mobiele internetverbinding zeer

afhankelijk is van de doelgroep en de website. Het is daarom aan te raden om onderzoek

te doen naar het gebruik van een applicatie. Misschien is het helemaal niet nodig om een

mobiele versie te bouwen van de 3D applicatie.

27

2.4 ONTWIKKELING

De ontwikkeling van applicaties op het web verschilt hevig met de ontwikkeling van

reguliere applicaties. Er zijn een aantal fundamentele verschillen in die twee vormen van

applicatieontwikkeling die worden beschreven in “Transforming the web into a real ap-

plication platform” (Anttonen et al., 2011):

Performance

Javascript wordt door vele bestempeld als een techniek die niet is geschikt voor grote

en uitgebreide applicaties. Daarnaast moet er altijd rekening worden gehouden met de

snelheid van een netwerk. Zo is het lastig om grote bestanden over te sturen zonder teveel

vertraging en moet alles geoptimaliseerd worden. Ook een browser zelf kan de boel flink

vertraging ten opzichte van een native applicatie.

Compatibiliteit

Er zijn voordelen en nadelen in dit geval. Een voordeel van webapplicaties is dat ze op elk

apparaat werken met een browser. Het is dus niet meer nodig om een applicatie te schri-

jven voor verschillende platformen zoals Windows, OS X, Linux, iOS en Android.

Een groot bekend nadeel is het feit dat veel browsers nog niet gestandaardiseerd zijn. Zo

is HTML5 en CSS3 slechts deels ondersteund in oudere versies van Internet Explorer. Het

grootste nadeel is dat je als ontwikkelaar geen controle hierover hebt, en dat kan lastig

zijn bij grote applicaties met veel verschillende gebruikers.

Interactie

Het is niet - of op een moeilijke manier - mogelijk voor webapplicaties om instellingen

aan te passen binnen het besturingssysteem zelf. Een goed voorbeeld is de muis: Games

zorgen ervoor dat de muis altijd binnen het venster van het spel blijft, bij een browser is

dat eigenlijk niet mogelijk en is het aan de ontwikkelaar van de browser om dit te imple-

menteren.

Ook geeft de interactie van een browser zelf enkele problemen voor een webapplica-

tie. Het gebruik van de “vorige/volgende” knop binnen een browser kan erg verwarrend

zijn binnen een applicatie. Ook dingen als drag & drop en copy / paste zijn moeilijker te

implementeren in een browser. Het is wel mogelijk (zeker in recente browsers), maar het is

aanzienlijk meer werk ten opzichte van een klassieke applicatie.

Een ander belangrijk punt is het feit dat er een internetverbinding aanwezig moet zijn om

ervoor te zorgen dat de applicatie werkt. HTML5 brengt wel offline mogelijkheden met zich

mee, maar het blijft verre van ideaal.

Veiligheid

Hoewel de veiligheid van webapplicaties steeds beter wordt, zie je toch vaak nieuwsber-

ichten van beveiligingslekken. Het feit dat alle data over het internet wordt verstuurd is

eigenlijk al een risico, de data kan immers overal worden onderschept.

28

Development

Webdevelopment en regulier development verschilt enorm. Zowel in de werkwijze als

in de programmeertaal. Een ontwikkelaar voor C, C++ of C# applicaties kan niet zo maar

applicaties gaan bouwen in PHP, Phyton of Javascript vanwege de compleet verschillende

stijl van ontwikkelen.

Distributie

Dit is het grootste voordeel wat webapplicaties hebben. Wanneer de applicatie geüpdatet

wordt, is deze bij iedereen direct up-to-date. Het is voor eindgebruikers niet meer nodig

om handmatig (of semi-automatisch) applicaties te updaten. Kritieke updates kunnen op

deze manier heel makkelijk uitgerold worden.

Op dit moment zijn webapplicaties hard op weg om volwaardige applicaties te worden.

Vooral Google is hier heel heftig mee bezig. Zo hebben ze een complete office-suite online

staan en hebben ze een compleet Operating System ontwikkeld gebaseerd op webapplica-

ties (Chrome OS).

2.4.1 WebGL Development

WebGL is een Javascript API en is gebaseerd op OpenGL. Het vergt de denkwijze en

ontwikkelmethode die bij OpenGL ook van toepassing is. Op die manier zou je het ontwik-

kelen van WebGL applicaties kunnen vergelijken met het ontwikkelen van desktopappli-

caties. Aan de andere kant is Javascript een webtechniek, en heeft daardoor een geheel

andere workflow dan programmeertalen als C++ of Java (Leung & Salga, 2010).

Javascript

Door veel mensen wordt het ontwikkelen van grote applicaties in Javascript gezien als een

slecht idee. Javascript is (vergeleken met andere talen zoals C) traag en dat is zeker merk-

baar wanneer een applicatie groter in omvang wordt. Ook het ontwikkelen van (gestruc-

tureerde) Javascript code is lastiger dan bij andere talen (Taivalsaari, Mikkonen, Ingalls, &

Palacz, 2008).

Het voordeel van het schrijven van WebGL in javascript is de implementatie in een web-

site. Ook de interactie van de website met het Canvas en de WebGL applicatie is relatief

eenvoudig en verschilt weinig met dat wat een webdeveloper gewent is met reguliere

HTML, CSS en Javascript. Dit heeft als grote voordeel dat mensen met kennis van Javas-

cript relatief makkelijk aan de slag kunnen met WebGL. Een bijkomend voordeel is dat

Javascript al heel veel wordt gebruikt op websites, waardoor het bouwen van de rest van

de website niet op een andere manier hoeft te gebeuren. Technieken als Flash en Unity

werken vaak binnen een eigen omgeving die in een website wordt “geplakt” door middel

van een ‘player’. Hierdoor is het lastiger om deze techniek in een website te verweven.

29

2.4.2 <canvas>

Het canvas element is een nieuwe HTML tag geïntroduceerd met HTML5. Met dit ele-

ment is het mogelijk om grafische rasterbeelden te renderen door middel van scripts in

de browser. Het zorgt voor een gebied (een canvas) binnen het Document Object Model

waarin scripts een bitmap kunnen renderen. Het canvas heeft als groot voordeel dat het

grotendeels op dezelfde manier kan worden behandeld als andere DOM elementen. Zo is

het mogelijk om andere elementen over het canvas heen te leggen met CSS. Zo kan een

canvas-element naadloos in een website worden geïntegreerd.

Het canvas-element op zich doet niets op zichzelf, maar zal altijd aangestuurd moeten

worden door een script, het canvas-element update alleen maar een bitmap.

Apple introduceerde in 2004 het canvas-element als onderdeel van WebKit. Het werd

vooral gebruikt voor Dashboard Widgets (een onderdeel van Apple’s besturingssysteem

OS X), maar ook in Safari was het beschikbaar (Hickson, 2004).

2.4.3 Libraries

Het ontwikkelen van WebGL is niet te vergelijken met het ontwikkelen van andere webt-

echnieken. WebGL lijkt heel erg op OpenGL en het is voor een webontwikkelaar lastig om

mee werken omdat het een heel andere manier van ontwikkelen vereist. Het is een stuk

gecompliceerder dan de gemiddelde Javascript toepassingen (Leung & Salga, 2010).

Zoals met veel technieken het geval is, is er een grote community actief die meewerkt aan

de ontwikkeling van libraries. Deze libraries zijn grote codeprojecten die als doel hebben

de implementatie van een techniek makkelijk te maken. Ook maken ze dingen die normaal

gesproken veel tijd en programmeerwerk kosten, makkelijk. Een bekend voorbeeld van

een library voor javascript is jQuery.

Ook voor WebGL bestaan er libraries, deze zijn er vooral op gericht om WebGL toegankelijk

te maken voor de webdeveloper, en het ontwikkelen van WebGL applicaties meer te laten

lijken het ontwikkelen voor het web. Omdat WebGL een heel recente techniek is, zijn veel

van deze libraries nog niet helemaal af of bevatten bugs.

2.4.4 Three.js

Een bekende en goed presterende library is Three.js. Deze library is ontwikkeld om op een

makkelijke en simpele manier 3D applicaties te bouwen, of zoals ze zelf zeggen; “voor

dummy’s”. Hoewel sommige ontwikkelaars kan afschrikken (vaak betekend dit dat een

ontwikkelomgeving weinig mogelijkheden bied of een slechte performance), is Three.js

erg interessant. Het maken van een 3D applicatie is inderdaad kinderlijk eenvoudig, maar

toch is het mogelijk om er heel complexe applicaties mee te bouwen en goede prestaties

te behalen.

30

Three.js is ontwikkeld om onafhankelijk te werken met verschillende renderengines. Zo

was het oorspronkelijk mogelijk om te renderen met DOM, SVG en Canvas, maar toen

WebGL werd geïntroduceerd is deze ook ingebouwd (Cabello, n.d.).

Daarnaast is Three.js één van de grootste (zo niet de grootste) library die er op het mo-

ment is. Dit heeft als groot voordeel dat er veel andere mensen zijn die er mee werken,

bugs snel worden gevonden en er veel plugins voor worden geschreven. Daarnaast is

Three.js open-source wat als groot voordeel heeft dat het altijd door ontwikkeld kan

worden, ook wanneer de originele auteur geen interesse meer heeft.

Zelf vergelijk ik Three.js graag met jQuery. jQuery is een uitgebreide library voor javascript

zelf en bied een heel makkelijke manier om bepaalde dingen te doen in javascript die nor-

maal gesproken veel moeite kosten. jQuery wordt heel veel gebruikt, wordt erg goed on-

derhouden en is heel makkelijk in gebruik. Datzelfde geld voor Three.js. Er zit een actieve

community achter en het bouwen van applicaties met behulp van de library is bijzonder

eenvoudig wanneer je wat ervaring hebt.

2.4.5 Implementatie & Investering

De implementatie van WebGL is over het algemeen vrij makkelijk. Het opzetten van een

simpele scene met behulp van Three.js is in no-time gedaan. Een scene kan je door middel

van een iFrame (wegens verschillende Javascript functies voor de interactie) heel simpel

in een pagina zetten.

Het bouwen van een applicatie kost veel tijd, maar kan vaak opnieuw gebruikt worden,

zeker wanneer er tijdens de ontwikkeling rekening mee wordt gehouden. Een applicatie

die 3D DAE modellen kan tonen met simpele camerabesturing is makkelijk opnieuw te ge-

bruiken wanneer hij voor de eerste keer is ontwikkeld. Ook een applicatie om bijvoorbeeld

3D grafieken te genereren is goed herbruikbaar.

31

2.5 HUIDIGE STAAT VAN WEBGL

WebGL is een open standaard voor het implementeren van 3D computergraphics in de

webbrowser. De techniek zorgt voor een brug tussen Javascript en OpenGL zodat er

gebruik kan worden gemaakt van de rekenkracht van een grafische kaart. Daarmee wordt

het mogelijk om geavanceerde 3D graphics te tonen binnen websites door middel van het

Canvas element in HTML5.

2.5.1 Hardware

Om WebGL te kunnen draaien is er een grafische kaart vereist die ondersteuning bied voor

OpenGL 2.1 en OpenGL ES 2.0. Vrijwel alle recente grafische kaarten hebben hier onder-

steuning voor. Alle NVidia, AMD en Intel chips, maar ook de geïntegreerde chips.

Het belangrijkste met betrekking tot de hardware is de rekenkracht. Er is een gigantisch

verschil in rekenkracht tussen dure, geavanceerde grafische chips, low-budget kaarten en

geïntegreerde chips. Een WebGL applicatie kan heel goed draaien op een geavanceerd

workstation met een krachtige grafische kaart, maar een netbook kan hier heel veel moeite

mee hebben. Het is een erg goed idee om de applicatie tussendoor te testen op diverse

systemen.

2.5.2 Hardware acceleratie

Een trend in de huidige mediatechnieken is hardware acceleratie. Hiermee wordt het ge-

bruik van specifieke hardware (zoals een videokaart) voor specifieke taken bedoelt. Denk

aan het decoderen van video op de grafische kaart of het verwerken van geluiden door een

geluidskaart. Het voordeel hiervan is dat deze hardware specifiek gemaakt is voor dit soort

taken en daardoor vele malen sneller is dan wanneer een taak wordt uitgevoerd door de

processor (ook wel softwarematig genoemd).

Omdat WebGL gebaseerd is op OpenGL, maakt de techniek gebruik van de grafische kaart.

Alle WebGL specifieke functies die je gebruikt (zoals raytracing, het tekenen van vectoren

en dergelijke) worden uitgevoerd op de grafische kaart. Een grafische kaart is specifiek

ontworpen voor dit soort taken en is dan ook zeer snel, bij sommige taken wel 17x sneller

(Doverspike, 2011). Hierdoor kunnen complexe grafische modellen zonder veel problemen

gerenderd worden. Ik heb zelf een test uitgevoerd met een model met meer dan 160.000

vertexes, en die werd zonder problemen weer gegeven. Ik moet hierbij wel melden dat het

zonder bijzondere belichting gebeurde, wat een grote impact kan hebben op het gener-

eren van het beeld.

2.5.3 Browserondersteuning

Op 3 maart 2011 bracht de Khronos Group de 1.0 specificatie van WebGL uit (Khron-

osGroup, 2011). Met de techniek zou het mogelijk worden om de grafische kaart aan te

spreken binnen de browser. Al voordat de uiteindelijke versie rond was, waren er al brows-

32

ers die de techniek ondersteunde. Google introduceerde de techniek in zijn browser met

de release van Chrome 9 op 3 februari 2011 (chrome.blogspot.com, n.d.), Mozilla deed dat

met Firefox 4.0 op 22 maart 2011 (Mozilla, 2011). Apple volgde iets later met Safari 5.1,

hoewel WebGL in Safari standaard uit staat, en door de gebruiker moet worden aangezet

(FairerPlatform, 2011). Ook Opera volgde in oktober met de implementatie in Opera’s

Alpha releases (Kleinhout, 2011).

Browser Ondersteuning sinds versie... Huidige versie

Google Chrome Chrome 9.0 Chrome 19.0

Mozilla Firefox Firefox 4.0 Firefox 13.0

Safari Safari 5.1 (alleen in developer modus) Safari 5.1

Opera Opera 12 Alpha Opera 11

Internet Explorer Geen ondersteuning Internet Explorer 9

2.5.4 Internet Explorer

Met meer dan 35% marktaandeel, is Internet Explorer nog steeds één van de meest aan-

wezige browsers op het web. Zo’n groot deel van de gebruikers kan niet zo maar gene-

geerd worden.

Microsoft over WebGL

In juni 2011 melde MSRC Engineering - een onderdeel van Microsoft dat zaken met betrek-

king tot beveiliging onderzoekt voor Microsoft producten - op hun blog dat ze WebGL

een onveilig techniek vinden. Hoewel sommigen dit bestempelen als een loze kreet van

Microsoft, heeft het bedrijf wel degelijk een punt (zie §x).

“In its current form, WebGL is not a technology Microsoft can endorse from a

security perspective.”

(MSRCEngineering, 2011)

Hoewel de berichten van Microsoft vrij negatief zijn, stelt één van Microsofts toparchitect-

en dat het een grote fout zou zijn als Microsoft om deze rede helemaal niets met WebGL

zou doen. Internet Explorer heeft WebGL nodig, en andersom geld hetzelfde (Bar-Zeev,

2011). Op het moment van schrijven lijkt Microsoft niets te zien in WebGL, maar het zou

kunnen dat ze zichzelf in de voet schieten door deze standaard niet te implementeren,

zeker nu het marktaandeel van Internet Explorer steeds verder terugloopt.

IE Chrome Frame

Ondanks deze ontwikkeling heeft Google een open source plugin ontwikkeld voor Inter-

net Explorer waarmee het mogelijk wordt om bepaalde Chrome technieken in Internet

Explorer te gebruiken. Onder andere het Canvas element wordt ondersteund, ook wordt

Figuur 3: Schema met de status van de ondersteuning van WebGL.

33

de Chrome Javascript engine gebruikt, wat de prestaties op het gebied van Javascript ten

goede komt. Met behulp van Google Chrome Frame is het dus ook mogelijk om WebGL te

gebruiken in Internet Explorer vanaf versie 6.

Google Chrome Frame is vooral gericht op gebruikers die geen mogelijkheid hebben om

een andere browser te installeren, door bijvoorbeeld bedrijfsregels. Chrome Frame heeft

geen administrator rechten nodig om geïnstalleerd te worden, wat het voor de eindge-

bruiker heel makkelijk maakt om de plugin te gebruiken en toch op een normale manier

het web te kunnen bekijken.

IEWebGL

Een ander project om WebGL naar Internet Explorer te brengen is IEWebGL. Deze ActiveX

plugin zorgt ervoor dat er zonder problemen WebGL kan worden gedraaid in Internet

Explorer. Hierdoor kunnen mensen het oude vertrouwde Internet Explorer gebruiken en

toch WebGL content bekijken. Wel moet de gebruiken handmatig een plugin installeren en

moet de ontwikkelaar een aantal regels code toevoegen aan het script.

2.5.5 Marktaandeel van WebGL ondersteuning

Voordat men gebruik wilt maken van een techniek, is het vaak een goed idee om te kijken

in hoeverre dit wordt ondersteund door systemen van gebruikers. Voor welk deel van de

markt is de content - geleverd door deze nieuwe techniek - nu daadwerkelijk zichtbaar?

Data wordt vergaard van de websites StatCounter, Net Market Share en Wikimedia. Hoewel

ik durf stellen dat dit een redelijk accuraat beeld geeft, zitten er toch een aantal haken en

ogen aan de manier van meten.

De verschillende websites vergaren deze statistieken op een vrij eenvoudige manier. Stat-

Counter gebruikt een stukje code - dat op zo’n 3 miljoen verschillende websites staat - die

doorgeeft aan StatCounter welke “user-agent” de website bezoekt. Op die manier krijgt

StatCounter redelijk betrouwbare data binnen over het marktaandeel van de verschillende

browsers. Het probleem met user-agents is dat deze soms nep kunnen zijn. Sommige

browsers kunnen twee keer een user agent versturen, of een totaal andere (Keizer, 2008).

Ook zullen dingen als virusscanners en bots (van bijvoorbeeld Google) de statistiek ver-

storen, zeker wanneer deze expres een andere user-agent gebruiken (Metz, 2008).

Wikimedia meet alleen de gebruikers die op Wikipedia komen. Dit kan een erg verstoord

beeld geven, zeker wanneer het gaat om een specialistische site (zoals w3schools, waar

vooral ontwikkelaars komen).

Als laatste is er soms nog een verschil in de manier van meten. Zo meet Net Market Share

unieke bezoekers, terwijl StatCounter alle bezoeken van gebruikers meet. Op die manier

hebben gebruikers die veel pagina’s bezoeken meer invloed op de statistieken van Stat-

Counter, en minder op die van Net Market Share.

34

Onderstaande grafiek laat het marktaandeel van verschillende browserversies zien. Ik heb

versies van browsers gegroepeerd op de ondersteuning van WebGL. Zo hebben alle versies

van Chrome 9.0 en hoger ondersteuning voor WebGL. De versies lager dan 9.0 hebben

geen ondersteuning en zijn daarom bij een andere groep gezet. Voor het gemak gaan we

er van uit dat overige browsers (dat kunnen tablet browsers - die doen zich vaak voor als

een desktop browser - of browsers zoals Chromium zijn) geen ondersteuning hebben voor

WebGL.

Browser (versie) Marktaandeel

Chrome (>9.0) 26,48

Firefox (>4.0) 20,52

Opera (>12) 0,03

Safari (>5.1) 10,22

Internet Explorer 30,98

Chrome (<9.0) 0,3

Firefox (<4.0) 5,22

Safari (<5.1) 0,58

Opera (<12) 3,8

Overig 1,87

Uit bovenstaande opsomming blijkt dat bijna de helft (46%) van alle desktop browsers

WebGL 100% ondersteunen, zonder plugin of andere extensie. De verwachting is dat dit

percentage blijft groeien, gezien hef feit dat Internet Explorer marktaandeel verliest, en

mensen langzaam maar zeker zullen upgraden naar een nieuwere versie van hun browser

(bijvoorbeeld de 5% die op een lagere versie van Firefox zitten dan 4.0).

Figuur 4: Marktaandeel van browsers, gesorteerd op de status van WebGL onderste-

uning. Data komt van StatCounter, opgehaald op 13 maart 2012. Statistieken gaan

alleen over desktopbrowsers en zijn wereldwijd.

35

2.6 TOEPASINGEN, MOGELIJKHEDEN EN TOEKOMST

Bijna alles is mogelijk met WebGL en andere webtechnieken, zolang computers snel ge-

noeg zijn en er genoeg tijd en geld beschikbaar is om het te realiseren. Zeker wanneer het

budget gering is, is het verstandig om gebruik te maken van bestaande libraries en tools

die het voor ontwikkelaars makkelijk maken.

Het schrijven van native WebGL vereist heel veel kennis en tijd. Feitelijk moet er een

engine worden geschreven (vergelijkbaar met engines uit games) die graphics, input en

berekeningen voor zijn rekening houd. Deze engine zorgt ervoor dat objecten op het sch-

erm verschijnen. Het zelf schrijven van een 3D engine is ontzettend moeilijk vanwege de

gigantische hoeveelheid aan wiskunde en natuurkunde die verstopt zit in een 3D engine.

Zeker het schrijven van een uitgebreide engine die zorgt voor realistische graphics en

interactiviteit is een heel opgave en vaak niet te doen voor kleinere bedrijven.

2.6.1 Toepassingen

WebGL kan ingezet worden op vele gebieden, niet alleen de visualisatie van objecten en

omgevingen. Zo is datavisualisatie een mooi voorbeeld. Zeker de laatste tijd is datavisuali-

satie een trend die opkomt (McDonnell, 2011).

Google heeft al WebGL in zijn zoekmachine gebouwd. Wanneer je bepaalde formules invo-

ert, krijg je een 3 dimensionale grafiek te zien die draait met WebGL. Een goed voorbeeld

van een simpel, maar doeltreffende oplossing.

Er zijn specifieke libraries geschreven voor datavisualisatie met WebGL. PhiloGL is zo’n

library die speciaal is ontwikkeld voor datavisualisatie. Ook met Three.js heb ik uit experi-

menten ervaren dat het maken van grafieken relatief eenvoudig is.

Er zijn vele vormgen van 3D visualisatie op het web mogelijk. Niet alleen ter entertain-

ment, maar ook functionele visualisatie van bijvoorbeeld data. Tijdens mijn zoektocht naar

WebGL op het web ben ik vele voorbeelden tegen gekomen, het is erg interessant om te

zien hoe deze voorbeelden op sommige punten compleet verschillen (qua doel, beeld en

interactie).

36

Adizero F50

Stopp LA ontwikkelde voor Adidas een promotiewebsite voor de Adizero F50. Ze vonden

voorgerenderde afbeeldingen niet meer van de tijd, het werd hard tijd dat commerciële

websites WebGL gingen inzetten. Met behulp van de grafische kaart konden ze een model

van meer dan 100.000 polygonen zonder problemen real-time weergeven op het web.

Voor de 60% van de mensen zonder WebGL ondersteuning, bouwde ze een Flash versie.

De applicatie detecteerde automatisch welke versie er gebruikt kon worden.

In de applicatie kan je de Adidas F50 voetbalschoen van alle kanten bekijken. Tevens zijn

er hotspots waarop je kan klikken voor meer informatie (zowel in tekst als in een filmpje).

Ook is het mogelijk om de schoen uit elkaar te halen met behulp van een slider.

My Robot Nation (http://myrobotnation.com)

Ontwerp je eigen robot en laat deze printen in een 3D printer. Dat is het concept van My

Robot Nation. Met een configurator kan je onderdelen selecteren en je robot aanpassen.

Ook is het mogelijk om kleuren te veranderen en de robot in een positie te zetten. Door

op verschillende onderdelen te klikken kan je deze onderdelen aanpassen. Opvallend is

de camera die in Isometrisch perspectief is geplaatst. Het ziet er niet heel raar uit maar

de keuze is interessant. Verder zijn er weinig andere visuele details te zien, zo is er geen

schaduw of een ondergrond aanwezig.

Rome (http://ro.me)

Google heeft ondertussen al diverse experimenten met WebGL op zijn naam staan. Rome

is zo’n experiment. Met behulp van WebGL hebben ze een interactieve muziekvideo

gemaakt voor het nummer Black van Danger Mouse en Daniele Luppi. Het doel van het

experiment is het tonen van de mogelijkheden van moderne webtechnieken. Al eerder

maakte Google diverse experimenten (misschien is “demo” een beter woord ervoor) die

gebruik maakte van de kracht van het web, zoals “The Wilderness Downtown”.

Figuur 5: Screenshots van My Robot Nation.

37

Figuur 6: Screenshots van Adizero F50.

Figuur 7: Screenshots van Rome.

38

2.7 CONCLUSIE

Op dit moment zijn er maar weinig functionele producten die gebruik maken van WebGL.

Langzaam maar zeker komen er steeds meer applicaties en tools beschikbaar die het

werken met de techniek makkelijk maken, maar de techniek is nog niet 100% klaar voor

echt productiewerk, zeker niet voor een klein bedrijf.

Globaal gezien wordt de techniek ondersteund door ongeveer de helft van de webgebruik-

ers, maar dit kan verschillen per website en doelgroep. Zo is het percentage gebruikers

van een technologiesite met een browser die WebGL ondersteund, aanzienlijk hoger; zo’n

70% (tweakers.net, n.d.).

Gezien de complexiteit van de techniek is het aan te raden om een framework te ge-

bruiken bij het ontwikkelen van applicaties. Three.js is een erg compleet en makkelijke

te gebruikten framework, maar is nog wel in een ontwikkelstadium, en daarom nog niet

bruikbaar voor commercieel productiewerk. Wanneer Three.js volledig is ontwikkeld en uit

beta fase komt, is het een zeer interessante library die erg toegankelijk is.

Vergeleken met andere 3D webtechnieken zoals Unity en Flash heeft WebGL een aantal

belangrijke voordelen:

» Open standaard

» Zonder plug-in beschikbaar in de meeste webbrowsers.

» Makkelijke en flexibele integratie met het Document Object Model door Javascript

» Groot toekomstperspectief

Naast deze voordelen zijn er ook een aantal nadelen:

» Javascript is traag voor grote applicaties

» Het is lastig om een WebGL applicatie te ontwikkelen zonder behulp van een library.

» Wanneer je een library gebruikt, ben je afhankelijk van de ontwikkeling daarvan.

Wanneer we deze voordelen en nadelen tegenover elkaar zetten, durf ik te concluderen

dat WebGL een ontzettend interessante techniek is die we in de toekomst nog vaak zul-

len tegenkomen. Op dit moment bevind WebGL zich in de overgang van experimenteel

naar functioneel. Libraries worden volwassen en bruikbaar, en de ondersteuning vanuit

bestaande 3D applicaties is ook aan het groeien. Een bedrijf moet voor zichzelf bepalen

of de overstap naar WebGL een verstandige keuze is. Dit hangt af van de te ontwikkelen

applicaties en de kennis die aanwezig is binnen het bedrijf. Het vergt in ieder geval een

flinke investering, maar wel één waarmee je een voorsprong kan krijgen in de toekomst.

Mocht een bedrijf er voor kiezen om WebGL te gebruiken, is het aan te raden om een

onderzoek te doen naar de eindgebruikers van de applicatie. Niet alleen is de browse-

rondersteuning van belang, maar ook is het verstandig om bij elke gebruiker een bench-

39

mark uit te voeren (al dan niet op de achtergrond). Op die manier is het mogelijk om een

goed beeld te krijgen van de systemen van gebruikers. Daaruit kan dan blijken of WebGL

een verstandige keuze is voor de betreffende applicatie.

40

3

In dit hoofdstuk wil ik antwoord geven op de vraag:

Hoe verhoudt WebGL zich tot bestaande 3D visualisatietechnieken en welke

plek heeft de techniek in de 3D visualisatiewereld?

3D bedrijven hebben allemaal een eigen manier van werken en gebruiken bepaalde soft-

warepakketten die ze volledig beheersen. Het is zonde om al deze kennis weg te gooien bij

de overstap naar een nieuwe techniek, en daarom is het een goed idee hoe deze nieuwe

techniek past in de huidige 3D wereld en wat het betekend voor de workflow en bedrijfs-

voering.

3D Visualisatie

41

3.1 Gebruik van 3D

3.2 Factoren

3.3 Technieken

3.4 WebGL en bestaande 3D applicaties

3.5 Conclusie

42

3.1 GEBRUIK VAN 3D

3.1.1 Games

De game-industrie is één van de snelst groeiende markten (Bilton, 2011). Door deze groei

is de vooruitgang in software en hardware gigantisch snel gegaan de afgelopen jaren.

30 jaar geleden had een game nog twee strepen en een stip, terwijl we nu in gigantische

virtuele werelden kunnen lopen waar alles op elkaar reageert en levensecht lijkt.

De meeste webgames zijn geschreven in Flash en zijn voornamelijk 2 dimensionaal. De

grootste oorzaak hiervan is het feit dat er gewoonweg geen technologie beschikbaar is om

echte 3D games te maken. In games is namelijk heel veel interactiviteit en input van de

speler / gebruiker aanwezig, anders is er immers geen gameplay.

Flash wordt op dit moment heel veel gebruikt om simpele 2D games te ontwikkelen en

Unity heeft een plug-in ontwikkeld waarmee games die zijn ontwikkeld met hun engine,

makkelijk op het web beschikbaar worden. Ook WebGL is uitermate geschikt voor games

op het web, OpenGL wordt namelijk al heel vaak gebruikt in normale games.

3.1.2 Datavisualisatie

Op het web is een gigantische hoeveelheid aan data te vinden. Om deze data begrijpelijk

te maken, wordt er heel veel gevisualiseerd. Als we kijken naar het DIKW model (zie figu-

ur), maakt datavisualisatie de stap van data naar informatie. Het is dan aan de gebruiker

om de stap naar kennis en uiteindelijk wijsheid te maken.

Het huidige web met alle media en interactiviteit is uitermate geschikt voor datavisualisa-

tie. In tegenstelling tot gedrukte media, is het mogelijk om op een interactieve manier data

weer te geven. Hierdoor is het mogelijk om op een simpele manier (veel) data te vergeli-

Figuur 8: De wijsheidpyramide die de

relatie tussen 4 vormen laat zien, met

daarbij de stap van datavisualisatie.

Data

InformatieDatavisualisatie

Kennis

Wijsheid

43

jken en inzicht te krijgen in verbanden.

Zo kan de variabele “tijd” op een makkelijke manier aangepast worden door middel van

bijvoorbeeld een slider in de vorm van een tijdbalk. Ook is het mogelijk om bepaalde vari-

abelen wel of niet weer te geven, waardoor de data in meer detail kan worden bekeken.

Met behulp van 3D is het mogelijk om een extra dimensie toe te voegen om nog meer

data te vergelijken. Dat kan in de vorm van een simpele grafiek met 3 assen, maar interes-

santer zijn de creatieve oplossingen zoals een wereldbol waarop de vluchten van diverse

vliegmaatschappijen zijn geprojecteerd (http://www.senchalabs.org/philogl/PhiloGL/ex-

amples/worldFlights/).

Figuur 9: Het verschil tussen 2D en 3D

X X

Y ZY

44

3.2 FACTOREN

Er zijn een aantal factoren die van invloed zijn op de kwaliteit (in de breedste zin van het

woord) van een 3D applicatie. Het ontwerp hangt altijd af van de inhoud, het doel en de

gebruiker.

“I think design covers so much more than the aesthetic. Design is fundamen-

tally more. Design is usability. It is Information Architecture. It is Accessibility.

This is all design.”

(Boulton, 2005)

Ik denk dat het stuk wat Mark Boulton hier schrijft, “spot-on” is. Een ontwerp, of visuele

representatie moet altijd het doel en de inhoud ondersteunen. Iets kan er visueel inter-

essant uit zien, maar dat moet de inhoud wel ondersteunen. Dit is goed terug te zien in

games met betrekking tot 3D. In 2007 werd de computergame Crysis uitgebracht. Het

spel werd na de release geprezen als één van de beste games dat jaar, maar een terugblik

jaren later had een veel kritischere kijk op het spel; “Crysis was the epitome of style over

substance.”.

Om dat in perspectief te zetten, de game Minecraft was grafisch iets heel anders dan wat

de wereld gewend was van computergames in 2010. Toch werd Minecraft heel goed ont-

vangen en kreeg een plek in de tentoonstelling “The Art of Video Games” in 2012.

Dit is een simpel, maar heel duidelijk voorbeeld van hoe visuele beelden vaak alleen

content kunnen ondersteunen. Visuele pracht en praal kan interessant zijn voor even, maar

uiteindelijk is de inhoud veel belangrijker.

Tijdens mijn onderzoek en experimenten binnen Studio i2 ben ik tot de conclusie ge-

komen dat er 3 belangrijke factoren invloed hebben op interactieve 3D visualisaties:

» Performance

Oftewel de prestaties van een applicatie. Niet alleen het aantal frames per seconde,

maar ook de laadtijden en hoe snel een applicatie reageert.

» Visuele kwaliteit

De beelden die op het scherm worden getoond.

» Interactiviteit

Het aanpassen van elementen binnen een 3D applicatie. Dit kan het standpunt zijn

bij een weergave van een ruimte, maar ook de kleur van een object binnen de 3D

omgeving.

45

3.2.1 Performance

Het lijkt voor de hand liggend dat de performance belangrijk is bij computer graphics,

maar het is een heel erg belangrijk onderdeel voor de ervaring van een gebruiker. Vertrag-

ing binnen een applicatie is namelijk funest voor de gebruikerservaring (Bryson, 2007).

Naast de normale factoren die van invloed zijn op de prestaties van een applicatie, is er

ook nog het aantal FPS wat een applicatie kan behalen. Het aantal keer dat het beeld wordt

ververst is essentieel voor het gebruik van een applicatie. Zeker bij real-time gegener-

eerde 3D omgevingen is dit van belang, en moet in de gaten gehouden worden.

Naast real-time rendering zijn prestaties ook belangrijk (hoewel minder) bij voorgeren-

derde afbeeldingen. Zeker wanneer er een groot aantal afbeeldingen moet worden gege-

nereerd is het belangrijk dat het maken van een afbeelding niet te lang duurt. Mocht er

een fout zitten in het model of afbeelding dan kost het veel tijd om dit te corrigeren. Zeker

met strakke deadlines (of lange rendertijden) is dit erg ongemakkelijk.

3.2.2 Visuele kwaliteit

De visuele kwaliteit is één van de dingen die direct in het oog springt bij het gebruik van

3D. Het is meteen zichtbaar en het valt de gebruiker meteen op. Daarom is de visuele

kwaliteit bijzonder belangrijk voor de eerste indruk, wanneer deze tekort komt zal de ge-

bruiker minder snel geneigd zijn om de applicatie verder te gebruiken. In dat geval zou hij

het gebruiksgemak mislopen waar juist zoveel aandacht aan is besteed in de ontwikkeling.

De visuele kwaliteit is lastig te meten, er zijn geen harde feiten die te vergelijken zijn en

over smaak valt niet te twisten. Het is een goed idee om te letten op de ondersteuning

van de inhoud. Past de gebruikte visuele stijl wel bij het gene wat getoond wordt? Wordt

de gebruiker niet afgeleid van wat belangrijk is? Komt de boodschap volledig over op de

gebruiker?

Een goed voorbeeld is de (simpele) visualisatie van data. Deze worden vaak in grafieken

weer gegeven en bieden een makkelijke manier om verbanden te maken. Complexere data

(met meerdere factoren) wordt steeds vaker in een 3 dimensionaal stelsel weer gegeven.

Op die manier is er meer ruimte voor interactiviteit en kan er meer data worden getoond

in een enkel beeld. Google heeft laatst een extra functie gebouwd die het mogelijk maakt

om wiskundige formules weer te geven in 3D (mocht dat van toepassing zijn). Het ziet er

heel simpel uit en is niet heel visueel aantrekkelijk, maar het doet wat het moet doen:

Inzichtelijk maken van de ingevoerde formule.

Voor een productconfigurator is het juist belangrijk dat de gebruiker een goed beeld krijgt

van het product dat wordt aangeboden. Wanneer je producten op internet besteld, heb

je niet de kans om het heel goed te bekijken. Het is onmogelijk om het product vast te

houden, te voelen en van alle kanten te bekijken. Daarom is het heel belangrijk om het

product zo realistisch mogelijk te tonen op het beeldscherm van een gebruiker. Foto’s

46

kunnen hierbij erg goed helpen, maar vaak geeft het geen goed ruimtelijk beeld en kun-

nen belangrijke details niet opvallen (zoals het gebruikte materiaal). Een 3D weergave kan

ervoor zorgend dat men een ruimtelijk beeld krijgt, zeker wanneer de gebruiker zelf het

beeld kan draaien. Een hoge interactiviteit en een hoge mate van aanwezige media (veel

beeld, geluid en andere elementen die de zintuigen prikkelen) zorgt ervoor dat de ge-

bruiker het idee krijgt dat hij “in de winkel is” en is dus goed voor het weergeven van een

product.(Algharabat & Dennis, 2009)

3.2.3 Interactiviteit

Interactiviteit bij 3 dimensionale omgevingen is een belangrijk aspect. 3D omgevingen

kennen een aantal vormen van interactiviteit (Jankowski, 2011):

Navigatie

De navigatie is één van de belangrijkste onderdelen van de interactie binnen een 3D om-

geving. 3D beelden worden vaak weergegeven op een 2D oppervlak, wat een fundamen-

teel probleem is. Er zijn 3 dimensies waarin een gebruiker kan navigeren, maar er zijn vaak

maar 2 dimensies voor de besturing en weergave. De besturing kan worden opgedeeld in 2

elementen, de verplaatsing en de oriëntatie.

Verplaatsing

Het verplaatsen van het perspectief - of de camera - van de gebruiker. Er zijn verschil-

lende manieren voor het verplaatsen van de camera. Verplaatsing van het perspectief kan

worden opgedeeld in vier verschillende soorten: Globale beweging, gerichte beweging,

specifieke coördinaat beweging en specifieke baanbeweging (Mackinlay, Card, & Robert-

son, 1990). In de paper “A taskonomy of 3D web use” (Jankowski, 2011) worden verschil-

lende voorbeelden beschreven van deze soorten beweging.

Oriëntatie

Een gebruiker moet een idee hebben van waar hij zich bevind in een 3D omgeving. Vaak is

het een goed idee om bij kleine omgevingen ervoor te zorgen dat men “van natura” weet

waar hij zich bevind. Mocht het een complexere omgeving betreffen, dan zijn er hulpmid-

delen die hierbij kunnen helpen (bijvoorbeeld een kaart).

Selectie

Afhankelijk van het doel en de mogelijkheden van een 3D applicatie moeten objecten

geselecteerd worden. Dit kan direct binnen een 3D omgeving (door middal van raytracing

in combinatie met de muis), of via externe elementen, zoals een lijst van objecten die zich

binnen de 3D omgeving bevinden (denk aan de “layers” binnen Adobe Photoshop).

Manipulatie

Het aanpassen van specificaties van objecten. Dit hangt heel erg samen met de selectie.

Vaak wordt eerst een object geselecteerd waarna het gemanipuleerd wordt.

47

Systeembeheersing

Ook het aanpassen van de context van een 3D applicatie is van belang, zoals het aanpas-

sen van de kwaliteit (in verband met de snelheid van je computer).

Deze elementen gecombineerd zorgen voor de complete interactiviteit binnen een 3D

applicatie. Afhankelijk van het doel en de mogelijkheden zijn bepaalde elementen niet, of

nauwelijks aanwezig, terwijl andere elementen juist van groot belang zijn voor het succes

van de applicatie. Zo hoeft er bij een weergave van een 3D model nauwelijks manipulatie

aanwezig te zijn, maar bij een 3D product configurator speelt dat juist weer een heel grote

rol.

48

3.3 TECHNIEKEN

3.3.1 Flash

In 1995 werd door FutureWave Software “FutureWave Animator” ontwikkeld dat grafische

beelden en animaties naar het web zou brengen. Eind 1996 werd FutureWave overgenom-

en door Macromedia en ontstond Macromedia Flash 1.0 (Gay, n.d.). In 2005 is Macromedia

overgenomen door Adobe, die verder is gegaan met het ontwikkelen van Adobe Flash

(Campbell & Saviage, 2005).

Marktaandeel

Flash wordt door heel veel desktopsystemen ondersteund, zo’n 95% van alle systemen

heeft een Flash plugin geïnstalleerd (StatOwl, 2012). Flash is dan ook het meest onderste-

unde mediaplatform binnen het web. Vooral dankzij de afspeelmogelijkheden van media

binnen Flash (denk aan webvideo’s, YouTube) is het zo populair.

Toekomst

Door velen (onder andere Adobe zelf) wordt Flash gezien als een techniek die aan het ein-

de van zijn leven is. Voornamelijk door de missende ondersteuning op de mobiele markt is

Flash bezig met een duidelijke ondergang. Ontwikkelaars kiezen er steeds vaker voor om

webapplicaties te bouwen met andere technieken zoals Javascript en HTML5, omdat Flash

geen toekomst heeft. Daarnaast werken andere technieken wel op mobiele apparaten en is

het zonde om te investeren in een techniek die “dood is verklaart”.

Apple heeft ervoor gekozen om Flash niet te ondersteunen op hun iOS apparaten (iPhone

en iPad) (Jobs, 2010). Hoewel andere fabrikanten de techniek nog niet laten vallen, ziet

Adobe zelf ook in dat Flash niet de toekomst heeft (Winokur, 2011).

3.3.2 Javascript

Javascript is een veelgebruikte en breed ondersteunde client-side programmeertaal. Hi-

ermee is het mogelijk om dynamisch webpagina’s aan te passen en dingen te veranderen.

Veel interactieve elementen die op webpagina’s aanwezig zijn, zijn gemaakt met behulp

van Javascript. Denk aan menu’s die uitklappen, inhoud dat wordt bijgewerkt zonder de

heel pagina te verversen (AJAX) en andere dynamische elementen.

Zo wordt javascript ook gebruikt voor de weergave van 360 graden afbeelding. Deze kleine

webapplicaties maken gebruik van verschillende afbeeldingen van hetzelfde object, waar

in elke afbeelding het product een aantal graden verder is gedraaid. Zo is het mogelijk om

met bijvoorbeeld 72 afbeeldingen een volledige cirkel maken en zo de illusie creëren dat

de gebruiker daadwerkelijk het product ronddraait.

3.3.3 Unity3D

In de oorsprong is Unity3D ontworpen om games in te ontwikkelen (http://unity3d.com/

49

unity/). Het platform bied een uitgebreide user interface aan om te ontwikkelen en er zijn

mogelijkheden om te exporteren naar iOS, Android, PC, Mac, diverse consoles en een web

player. Hierdoor is het voor ontwikkelaars heel makkelijk om applicaties te ontwikkelen

voor diverse platformen zonder daar heel veel in te investeren.

3.4 WEBGL IN COMBINATIE MET BESTAANDE 3D APPLICATIES

Er zijn diverse programma’s waarin modellen kunnen worden gemaakt. Maya, 3D Studio

Max, Blender en Cinema 4D zijn voorbeelden van krachtige software waarmee het relatief

makkelijk wordt gemaakt om complexe modellen te maken. Naast het maken van de vorm

van een model is het ook mogelijk om textures erop te plakken, lichten te plaatsen, ef-

fecten toe te voegen en een camera te plaatsen die de positie van het beeld bepaalt. Ook

is het vaak mogelijk om een animatie te maken binnen een pakket.

Vaak wordt zo’n model gebruikt in rendersoftware die er een afbeelding of video van

maakt. Deze software ‘maakt’ een realistische beeld van een scene door verschillende

natuurkundige berekeningen te maken. Zo wordt de inval en reflectie van het licht be-

rekend, het perspectief, scherptediepte en andere factoren die een rol spelen in een beeld

wat de werkelijkheid probeert te benaderen. Maar het is ook mogelijk om een model te

exporteren naar een bestand dat kan worden gebruikt in andere software of applicaties

zoals Unity, Flash of Three.js.

3.4.1 Autodesk Maya

Maya is één van de bekende en veelgebruikte programma’s om 3D modellen mee te

ontwikkelen. Het programma heeft een uitgebreide interface en bied veel functies die het

ontwikkelen van 3D modellen makkelijk maken.

De modellen die gemaakt worden in Maya kunnen ook gebruikt worden in diverse andere

technieken. Zo is het mogelijk om Maya modellen te exporteren naar Collada-bestanden.

3.4.2 Collada

De Collada-standaard is een relatief nieuwe standaard dat wordt ontwikkeld door de

Khronos groep, welke ook de WebGL standaard ontwikkeld. Het doel van deze standaard

is het creëren van een universeel bestandsformaat voor 3D modellen dat door alle 3D ap-

plicaties wordt ondersteund (Khronos, n.d.).

Op dit moment hanteren de meeste applicaties nog hun eigen bestandsformaat. Vaak zit

er in dit bestand ook gegevens die het programma kan gebruiken voor extra functies. Veel

applicaties (waaronder Maya) hebben beperkte ondersteuning voor Collada, niet altijd

worden alle gegevens in het Collada bestand opgeslagen en ook het importeren van een

Collada-model gaat niet altijd even goed, wat het idee achter het Collada bestandsformaat

50

teniet doet (Roosendaal & Sharybin, 2012).

Ook Three.js bied ondersteuning voor Collada. Hoewel het nog niet ideaal werkt, is het wel

bruikbaar. Af en toe missen er bepaalde oppervlakken van een model of zitten er fouten in

de textures die erop zijn gezet.

XML

Het grootste probleem van Collada is het feit dat het op XML is gebaseerd. Hoewel deze

techniek prima is voor bepaalde doeleinden, is het verre van ideaal voor gebruik op het

web. XML neemt door de opbouw van het bestand, heel veel ruimte in (Yeung, Ng, &

Cheng, 2005). Een Collada bestand uit Maya (met ongeveer 40.000 polygonen) kan makke-

lijk 40 MB groot worden, veel te groot voor gebruik op het web. Er zijn een aantal oplossin-

gen voor dit probleem, maar het blijft een moeilijk punt.

Het is mogelijk om het aantal polygonen te verminderen van het model. Hoewel het mo-

gelijk is dat er detail verloren gaat, zitten er vaak polygonen in die niet nodig zijn. In het

ideale geval zou een model speciaal ontwikkeld moeten worden voor gebruik met WebGL,

maar dit vergt een hoop extra tijd en kosten. Het is wel mogelijk om een model te com-

primeren door middel van algoritmes, maar vaak gaat er dan nodeloos detail verloren en

de kwaliteit van een model gaat er niet op vooruit

Een andere optie is het gebruik van JSON. Dit is een alternatief voor XML dat is gebaseerd

op Javascript. Het kost veel minder ruimte om dezelfde data op te slaan en is daarom een

stuk beter geschikt voor het web.

Figuur 10: De stappen van Autodesk

Maya naar de browser.

Figuur 11: Inefficiëntie van XML. De

rode onderdelen zijn overbodig voor de

meeste applicaties.

<note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body></note>

Autodesk Maya Three.jsCollada WebGL Browser

51

3.5 CONCLUSIE

3D visualisatie kent 2 belangrijke factoren die van invloed zijn op het eindresultaat van 3D

visualisatie, die elk een aantal belangrijke punten hebben waarop gelet moet worden:

» Kwaliteit

» Interactiviteit

Onder kwaliteit verstaan we grotendeels de grafische kwaliteit, maar ook voor een deel de

wachttijden en het aantal frames per seconde wat de applicatie kan halen op een gemid-

deld systeem. Het belangrijkste op grafisch gebied is de projectie van 3D naar 2D. Dit

heeft niet alleen invloed op de kwaliteit van het beeld, maar ook op het ruimtelijk beeld

wat gebruikers creëren.

Interactiviteit is niet bij alle visualisaties belangrijk. Bij simpele statische afbeeldingen

is er weinig interactie aanwezig, maar bij de meeste 3D toepassingen speelt het een heel

grote rol. In games is de gameplay één en al interactie, datavisualisaties maken vaak

gebruik van de input van een gebruiker om bepaalde data wel en niet te tonen. De vele

vormen van navigatie laten al zien dat er heel veel mogelijkheden zijn qua interactiviteit

binnen 3D omgevingen.

3.5.1 WebGL

De visuele kwaliteit van WebGL applicaties is bijna altijd lager dan de visuele kwaliteit

van voorgerenderde afbeeldingen. Er zijn minder details aanwezig, de belichting is minder

realistisch en de materialen zijn minder overtuigend.

De algemene kwaliteit van WebGL is afhankelijk van de tijd die er in wordt gestopt. Met

een groot budget is het mogelijk om zeer geavanceerde 3D applicaties te bouwen die

niet onder doen voor andere technieken. Helaas is dat budget er niet altijd en moeten er

concessies worden gedaan in de kwaliteit. Met hulpmiddelen zoals libraries is het nog

steeds mogelijk om kwalitatief sterke applicaties te bouwen, maar je bent als ontwikkelaar

dan afhankelijk van externe partijen en de doorontwikkeling van deze library, iets wat niet

altijd even veel zekerheid bied.

Naast het budget is ook het rekenvermogen van de eindgebruiker van belang. Een onder-

zoek naar de doelgroep van een applicatie is dan ook sterk aan te raden.

WebGL is ontzettend sterk op het gebied van interactiviteit. Door de zeer eenvoudige inte-

gratie van WebGL met Javascript, het Document Object Model en andere webtechnieken,

zijn de mogelijkheden eindeloos, de grens ligt puur bij de kennis en creativiteit van de

ontwikkelaar.

52

4

Studio i2 is een visualisatiebureau in Delft, dat voornamelijk werkt in het gebied van

architectuur en bouwkunde. Ze zijn voornamelijk bezig met het visualiseren van diverse

bouwprojecten, maar de laatste tijd is ook de 3D product-configurator hard in ontwikkeling

binnen het bedrijf.

In deze case-study beschrijf ik een klein visualisatiebureau dat zich voor een deel bezig-

houd met 3D visualisaties op het web. Ik onderzoek de workflow van het bedrijf, de kennis

die ze in huis hebben en van welke software er gebruik wordt gemaakt. Ook de klanten en

producten komen aan bod. Op die manier is het mogelijk om het bedrijf te analyseren en

inzicht te krijgen in de denkwijze, mogelijkheden en eventuele tekortkomingen van het

bedrijf.

Studio i2

53

4.1 Kennis

4.2 Producten

4.3 Klanten

4.4 Conclusie

54

4.1 KENNIS

Studio i2 heeft veel specialistische kennis met betrekking tot het maken van 3D graph-

ics. Ze werken erg veel met Autodesk Maya in combinatie met MentalRay. Zo goed als alle

visualisaties maken ze met deze twee applicaties, daarom is het voor het bedrijf relatief

eenvoudig om modellen in Maya te maken en deze op een realistische manier weer te

geven in MentalRay. Een groot deel van de opdrachten (zoals de visualisatie van vastgoed)

is dan ook gebaseerd op deze workflow.

Naast deze werkzaamheden is Studio i2 ook steeds meer bezig met webtoepassingen. Zo

werken ze hard aan de 3D configurator en hebben ze diverse interactieve 3D applicaties

gebouwd, ook op het gebied van vastgoed. Ook bouwen ze af en toe de website die bij

deze 3D applicaties horen, om zo een naadloze integratie te garanderen tussen de appli-

catie en de website. De front-end neemt Studio i2 meestal voor eigen rekening, maar de

back-end wordt uitbesteed aan freelancers omdat de kennis niet aanwezig is binnen het

bedrijf.

Het bedrijf heeft geen echte programmeurs in dienst, en dat blijkt af en toe nog wel eens

een valkuil te zijn. Simpele problemen oplossen is vaak geen probleem, maar heel applica-

ties schrijven is lastig. Hierdoor is het bedrijf vooral afhankelijk van bestaande applicaties

die door middel van een GUI aangepast kunnen worden.

55

4.2 PRODUCTEN

Het portfolio van Studio i2 bestaat grotendeels uit de visualisatie van vastgoed, dat

komt mede door de bouwkundige achtergrond van enkele medewerkers. De visualisaties

worden vaak gebruikt om mensen op locatie het doel te tonen, maar ook om bouwplannen

van een architect te verkopen aan een opdrachtgever. Hierdoor is het erg belangrijk dat

het gebouw er goed en realistisch uit ziet, het moet immers een beeld vormen voor een

eventuele koper.

4.2.1 Productconfigurator

De productconfigurator is een webapplicatie waarbij de gebruiker een product kan

samenstellen door te kiezen uit verschillende elementen. Deze elementen zijn bepaalde

onderdelen van het totaal en maken samengevoegd een product. De elementen zijn ge-

groepeerd in verschillende categorieën, elke categorie bestaat uit een onderdeel van het

product, uit elke categorie kan maar één onderdeel gekozen worden.

Op deze manier is het voor de gebruiker mogelijk om een product aan te passen naar zijn

of haar smaak. Dat kan in de vorm van kleur, maar ook in de grootte, bepaalde details of

het materiaal. Zo is het bijvoorbeeld mogelijk om de wijzerplaat te veranderen bij een

productconfigurator voor horloges.

Ook bij de productconfigurator is het van belang dat de beelden een goede representatie

geven van de werkelijkheid. Vaak kunnen potentiële klanten het product alleen maar be-

zichtigen op het internet en niet in het echt. Zeker bij producten die aan de prijs zijn (zoals

een bank of een dure horloge) is het erg belangrijk dat een gebruiker een goed beeld

krijgt van het product. Om men een beter beeld te geven, werkt Studio i2 hard aan een 3D

productconfigurator. Dat is een productconfigurator waarbij het mogelijk is om het product

360 graden rond te draaien, zo is het van alle kanten te bekijken.

De productconfigurator werkt met behulp van Javascript en voorgerenderde afbeeldingen.

Een object wordt 72 keer gerenderd, bij elke render wordt deze 5 graden verder gedraaid.

Op die manier wordt het mogelijk om op een mooie en vloeiende manier om het object

heen te draaien. Met behulp van Javascript worden deze afbeeldingen één voor één

getoond, afhankelijk van de input van de gebruiker. Op die manier krijgt de gebruiker de

illusie dat hij het object daadwerkelijk kan draaien.

Omdat er bij een productconfigurator veel verschillende opties zijn, is het onmogelijk om

alle opties van te voren te renderen. Het aantal afbeeldingen stijgt exponentieel met het

aantal opties dat er mogelijk is. Een simpel rekenvoorbeeld geeft aan hoeveel ruimte er

benodigd is hiervoor:

Stel we hebben een horloge waarbij we 5 verschillende elementen kunnen aanpassen. Al

deze elementen hebben 10 verschillende opties. Dat betekend dat we 5^10 = 9.765.625

mogelijke combinaties hebben. Om deze combinaties in 360 graden te tonen, moeten we

56

alles nog eens keer 72 doen, wat neerkomt op 703.125.000 afbeeldingen. Als we er van

uit gaan dan alle afbeeldingen 50KB groot zijn, hebben we ongeveer 35,16 TB aan af-

beeldingen nodig. Het opslaan van deze afbeeldingen is bijzonder kostbaar, maar ook het

versturen van alle data naar de gebruikers is een probleem. Ook moeten we niet vergeten

dat het renderen van deze afbeeldingen veel tijd kost, een enkele afbeelding kan zo een

uur duren.

Om dit probleem op te lossen, maakt Studio i2 gebruik van PNG’s met transparantie.

De verschillende onderdelen hebben ieder een eigen reeks met afbeeldingen, die over

de andere onderdelen worden geplakt. Er wordt als het ware een afbeelding getoond

die bestaat uit verschillende lagen met PNG’s. Met deze techniek wordt er aanzienlijk

bespaard op het aantal afbeeldingen. Het enige nadeel is dat PNG’s weinig compressie

bieden, waardoor er nog steeds vrij veel data naar een gebruiker moet worden gestuurd.

Hoewel deze techniek van afbeeldingen in combinatie met Javascript prima werkt voor

simpele configurators, is het niet toereikend wanneer er meer interactie is vereist. Zo is

het niet mogelijk om de producten in de afbeeldingen aan te passen, de afbeeldingen zijn

immers al gerenderd. De breedte van een bank traploos aanpassen is praktisch onmogelijk,

gezien het aantal opties dat erbij komt. Ook is het niet mogelijk om een product om de ver-

ticale as te draaien, gezien het aantal afbeeldingen dan weer exponentieel zou stijgen.

Op een gegeven moment is het dus nodig om een andere manier te zoeken om dit te real-

iseren. Het is dan nodig om te gaan werken met echte 3D modellen die real-time worden

gerenderd door de computer van de gebruiker. Op die manier hoeft een server alleen de

3D modellen aan te leveren. Ook is het dan mogelijk om deze modellen aan te passen door

de gebruiker, denk aan het schalen over een bepaalde as.

Figuur 12: Schematische weergave van

het combineren van afbeeldingen tot

een product.

Achtergrond

Combinatie van opties

Opties

57

4.3 KLANTEN

Ondanks dat veel architectenbureaus hun visualisaties zelf doen, zijn er toch veel van hen

die de visualisatie uitbesteden. Dat kan gebeuren bij een krappe deadline, of wanneer een

architect een net wat mooiere visualisatie wil. Ook kunnen ze om speciale dingen vragen

zoals een 360 graden foto, een animatie of een interactieve visualisatie.

Naast architecten zijn er ook andere klanten bij Studio i2. Deze klanten kunnen elk bedrijf

zijn wat een visualisatie nodig heeft. Vaak willen klanten ook een website bij hun visuali-

satie zodat het geheel bij elkaar past en alles door één partij wordt geleverd. Denk aan een

horlogefabrikant die een productconfigurator wilt hebben met daaromheen een website.

Studio i2 kan dan een totaalpakket aanbieden.

58

4.4 CONCLUSIE

Studio i2 is een bedrijf wat heel veel weet van visualisaties, voornamelijk in de vastgoed-

sector. Deze kennis, samen met de kennis van webtechnieken zorgt ervoor dat ze ook in-

teractieve visualisaties kunnen bouwen wanneer een klant dat verlangt. Deze interactieve

visualisaties kunnen ze ondersteunen met een website, zodat een gebruiker een gehele,

op elkaar afgestemde ervaring krijgt wanneer deze gebruik maakt van het product.

Het enige wat Studio i2 echt mist is een programmeur. Dat is lastig wanneer ze een

website aan het bouwen zijn, de front-end wordt wel binnen het bedrijf gedaan, maar de

back-end wordt uitbesteed. Hoewel dit goed kan werken, is het vooral bij kleine websites

een stuk fijner om de back-end in combinatie met de front-end te maken. Dat scheelt tijd

en uiteindelijk ook geld.

Wanneer Studio i2 meer opdrachten krijgt waar er veel geprogrammeerd moet worden,

raad ik ten zeerste aan om een all-round developer aan te nemen. Deze kan helpen bij het

bouwen van websites (zowel de front-end als de back-end), en kan ook bijdrage aan de

automatisering binnen het bedrijf.

59

60

5

Het prototype is gemaakt om het onderzoek te ondersteunen. Door het ontwikkelen van

een WebGL applicatie is het voor mij duidelijk geworden wat er allemaal komt kijken bij

de ontwikkeling van zo’n webapplicatie. Deze kennis is van groot belang in het onderzoek

en de conclusie, het bied namelijk een praktische kijk op WebGL binnen de wereld van 3D

visualisatie.

Om de mogelijkheden van WebGL uit te testen, heb ik een productconfigurator gebouwd in

WebGL met behulp van Three.js. De productconfigurator is een concept waar Studio i2 op

dit moment actief mee bezig is. Met de kennis die het bedrijf heeft met betrekking tot dit

onderwerp, is het mogelijk om een goede evaluatie te maken over WebGL in vergelijking

met bestaande technieken.

De interface en het ontwerp van het prototype is niet bijzonder interessant, het onderzoek

is namelijk ingesteld op de technische kant van het verhaal, daar waar WebGL ook een

technisch onderwerp is. Hier heb ik dan ook extra aandacht aan besteed.

Productconfigurator

61

5.1 Concept

5.2 Uitwerking en techniek

5.3 WebGL versus bestaande configurator

5.4 Inka3D

62

5.1 ONTWIKKELPROCES

Een belangrijk onderdeel van deze scriptie is het ontwikkelen van een prototype. Dit

prototype moet inzicht geven in het ontwikkelproces van WebGL. Figuur 13 beschrijft het

stappenplan wat ik tijdens het ontwikkelen van mijn prototype heb doorlopen. Het stap-

penplan is door het bedrijf te gebruiken wanneer zij zelf aan de gang gaan met WebGL. Ik

beschrijf de verschillende onderdelen in het stappenplan, en zal daarbij ook voorbeelden

geven die op mijn ontwikkelde prototype slaan.

In het figuur is ook de tijd die het heeft gekost om deze stap te doorlopen visueel weerge-

geven door middel van een balk die loopt van 0 tot 100 procent. In totaal heb ik ongeveer

15 weken gewerkt aan het prototype, bij elke stap zal ik ook de precieze tijdsbesteding

zetten.

5.1.1 Concept

Het begint allemaal bij een concept of idee. Vaak heeft de klant een idee wat hij wil

uitwerken, met dat idee gaat hij naar een bedrijf waar hij dit voorlegt. Het is dan aan het

bedrijf om te kijken naar de technische mogelijkheden. Om deze keuze te maken, zijn

er een aantal dingen die duidelijk moeten zijn. Dat kan vanuit de klant komen, maar dat

kan een bedrijf ook zelf bepalen. Zo heeft de klant vaak weinig kennis van de kosten die

gemoeid zijn met het uitwerken van bepaalde concepten, het is dan aan het bedrijf om

te bepalen wat het budget is voor een product. Een bedrijf kan er soms voor kiezen om te

investeren in een bepaald product, omdat deze kennis kan worden gebruikt in toekomstige

producten.

Naast de kosten, is het van belang om vast te stellen wat de gewenste kwaliteit moet zijn

van de applicatie. Is realisme een belangrijke factor in het product, of voldoet het om

dingen schematisch weer te geven? In welke mate moet de applicatie interactief zijn? Is de

keuze voor WebGL aan de hand van deze elementen wel onderbouwd?

Als laatste moet ook de doelgroep worden meegenomen. Het is namelijk maar de vraag of

de platformen van gebruikers WebGL ondersteunen. Als dit niet het geval is, is er helemaal

geen reden om van WebGL gebruik te maken. Ook al maak je nog zo’n fantastische applica-

tie met WebGL, het zal waardeloos zijn als niemand er gebruik van kan maken.

Productconfigurator-1week

Het concept van mijn prototype is de productconfigurator. Deze wordt beschreven in

hoofdstuk 4. Op dit moment heeft Studio i2 een dergelijke configurator gebouwdmet

behulp van andere technieken, het is dus erg interessant om deze na te bouwen in WebGL

en te bekijken wat de verschillen zijn op het gebied van kwaliteit, interactiviteit en ontwik-

keling.

Voor mijn prototype zijn geen specifieke eisen gesteld. Het is belangrijk dat het prototype

een goed beeld geeft van de mogelijkheden en kwaliteit van WebGL, en ook inzicht kan

geven in de ontwikkeling. Dat slaat ook op de doelgroep: Het bedrijf zelf. Dit betekend dat

63

Figuur 13: Het proces van

concept naar prototype.Concept

Onderzoek naar techniek

Eisen

Mogelijkheden

Ontwikkeling & ondersteuning

Toekomst

Kwaliteit

Interactiviteit

Doelgroep

Kosten

Platform & browser

Investering

Keuze technisch platformNative WebGL

Framework

Three.js

Inka3D

Experimenteren techniekInteractief experiment

Modellen inladen

Browsercompabiliteit

Bouw prototypeThree.js

Collada modellen

Evaluatie prototypeOntwikkelproces

Herbruikbaarheid

Kwaliteit

Vergelijking met andere technieken

i2

i2

i2

i2

64

de eisen als volgt kunnen worden gesteld:

» Een realistisch beeld geven van de visuele en interactieve mogelijkheden van WebGL.

Oftewel, de visuele kwaliteit moet zo hoog mogelijk zijn, de interactieve mogelijkheden

moeten worden belicht en daarnaast moet het bruikbaar zijn op een gemiddeld platform

om te testen.

De kosten zijn wel duidelijk, het prototype moest binnen de stageperiode worden ontwik-

keld door één persoon en er was weinig budget beschikbaar voor hulpmiddelen die aange-

schaft moesten worden. Wel was het mogelijk om gebruik te maken van Autodesk Maya en

diverse modellen die Studio i2 heeft ontwikkeld voor eerdere projecten.

5.1.2 Onderzoek naar techniek

Nadat het concept is gespecificeerd, de eisen zijn vastgesteld en de doelgroep in kaart is

gebracht, begint het onderzoek naar een geschikte techniek. Hierbij moeten de mogeli-

jkheden aansluiten op de eisen (qua kwaliteit en interactiviteit), en is het belangrijk dat de

techniek geschikt is voor de doelgroep.

Het is belangrijk om het toekomstperspectief mee te nemen bij de keuze van een techniek.

Het investeren in een techniek die over een paar jaar er niet meer toe doet (zoals Flash,

zie hoofdstuk 3), is zonde. Het kan lonen om als bedrijf meer te steken in de ontwikkeling

van een product met een techniek die later opnieuw kan worden gebruikt. Niet alleen

de daadwerkelijk ontwikkelde producten, maar ook de kennis die is opgedaan tijdens de

ontwikkeling van zo’n product is van belang.

Naast de kostentechnische investering, is het een goed idee om ook te kijken naar de

andere mogelijkheden van de techniek. Het zou kunnen dat de aanpassing in de workflow

er voor zorgt dat het bedrijf zich kan uitbreiden naar andere markten door de opgedane

kennis (denk aan het ontwikkelen van modellen voor games door de kennis van low-poly

modellen).

Productconfigurator-2weken

Gezien het doel van dit prototype (namelijk: een realistisch beeld geven van de visuele

en interactieve mogelijkheden van WebGL), was de keuze voor WebGL bijzonder simpel

en was het niet nodig om te kijken naar andere technieken. Bij de evaluatie komen andere

technieken wel aan bod, zie daarvoor hoofdstuk 5.1.6.

5.1.3 Keuze technisch platform

Na de keuze van de techniek, is het nodig om te kiezen voor een ontwikkelmethode binnen

deze techniek. Er zijn namelijk verscheidene manieren om te ontwikkelen met diverse

technieken, een simpel voorbeeld kan worden gegeven aan de hand van HTML en CSS. Het

is mogelijk om een HTML website te bouwen in een simpele texteditor (zoals kladblok)

65

waar pure code in wordt geschreven. Maar het gebruik van een WYSIWYG (“What you see is

what you get) editor is ook mogelijk.

Bij WebGL is dat precies hetzelfde. Het is mogelijk om native WebGL te schrijven, maar er

zijn diverse libraries beschikbaar die het ontwikkelen van 3D applicaties met WebGL mak-

kelijk maken. De keuze hiervan hang af van het doel van de applicatie, het budget, toekom-

stperspectief, ontwikkeling en ondersteuning.

Productconfigurator-1week

In mijn onderzoek naar de WebGL techniek ben ik een aantal belangrijke dingen tegenge-

komen. Ten eerste was het programmeren van “native WebGL” niet te doen. De kennis die

daarvoor was vereist had ik niet in huis en het budget (of in mijn geval, de tijd) was niet

aanwezig om deze kennis op te doen. Daarom moest ik kijken naar een library die wel te

gebruiken was met mijn kennis.

Al snel kwam Three.js naar voren, in diverse discussies op internet (zoals op Stackoverflow)

werd Three.js beschouwd als een toegankelijke, maar zeer krachtige library. Ook het aantal

“watchers” op Github (mensen die het project volgen) was een veelvoud meer dan bij

andere library’s, wat aangeeft dat Three.js niet zo snel een stille dood zal sterven. Na wat

kleine experimenten met Three.js, zoals het weergeven van een kubus met schaduw, kwam

ik erachter dat Three.js inderdaad een ontzettend fijne library is en was mijn keuze snel

gemaakt.

Het aantal mogelijkheden met Three.js is eindeloos, datavisualisatie, games, animaties,

bijna alles is mogelijk in Three.js, omdat het werkt met 3 simpele elementen: Objecten,

camera’s en lichten. De grote hoeveelheid extensies die beschikbaar is voor de techniek

helpt enorm bij het ontwikkelen waardoor het soms kinderspel is om bepaalde functies te

implementeren in de applicatie. Zo maakt een plugin het mogelijk om een ‘onclick-event’

aan een object te hangen, met een enkele regel code.

Ook heb ik nog gekeken naar Inka3D, een plugin voor Maya die het mogelijk maakt om

scene’s te exporteren naar WebGL, zie hiervoor hoofdstuk 5.4.

5.1.4 Experimenteren Techniek

Voordat er een concreet product wordt ontwikkeld, is het belangrijk om de techniek in de

vingers te hebben. Hiermee voorkom je dat achteraf blijkt dat de aanpak niet helemaal

goed is en dat je al het gedane werk opnieuw moet doen. De kennis van een techniek

door te experimenteren zorgt ervoor dat je als ontwikkelaar een goed beeld krijgt van

de mogelijkheden en valkuilen. Het spreekwoord: “Al doende leert men” is hier goed van

toepassing.

Tijdens het experimenteren kan je als ontwikkelaar ook een goed idee krijgen van wat er

allemaal mogelijk is met een techniek. Niet alleen of het originele concept te realiseren

is, maar ook of er nog functies aan toe te voegen zijn door ideeën die zijn ontstaan tijdens

het experimenteren.

66

Figuur 14: Schematische weergave van

het combineren van 3D modellen tot een

product

OptiesAchtergrond

Combinatie van opties

67

Productconfigurator-5weken

Voordat ik begon aan de ontwikkeling van de productconfigurator, heb ik vele experi-

menten gedaan met Three.js. Het begon bij het tonen van een ronddraaiende kubus met

een schaduw eronder. Daarna heb ik geëxperimenteerd met interactie door middel van het

klikken op objecten en het besturen van de camera met het toetsenbord.

Ook heb ik kleine stappen gezet in het ontwikkelen van het begin van een kleine game

in WebGL. In dat experiment is het mogelijk om 2 objecten te bewegen over een raster.

Daarnaast heb ik geëxperimenteerd met het inladen van Collada modellen. Ik heb hierbij

gebruik gemaakt van diverse modellen die Studio i2 heeft ontwikkeld voor eerdere pro-

jecten.

Met deze experimenten kon ik bekijken hoe de techniek werkte in diverse browsers.

Chrome en Safari (beide gebruikmakend van Webkit) hadden beide geen enkele moeite

met de experimenten, en ook Firefox werkt prima qua performance. Alleen de kwaliteit

blijkt minder te zijn in Firefox, omdat deze (in tegenstelling tot Chrome en Safari) geen

anti-aliasing toepast op de applicatie, waardoor schuine randen er uit zien als trappetjes.

Ook Inka3D kwam aan bod tijdens het experimenteren, maar door de gebrekkige interac-

tiviteit is deze techniek in deze fase afgevallen.

68

5.1.5 Bouw Prototype

Wanneer je als ontwikkelaar een goed beeld hebt van de techniek die is gekozen, is het

tijd voor het ontwikkelen van een prototype. Dit prototype kan worden gebruikt om te

tonen aan klanten en een indruk te krijgen van het eindresultaat. Nog lang niet alle func-

ties hoeven aanwezig te zijn in een prototype, maar het is belangrijk dat het prototype

representatief is op het gebied van kwaliteit en dat het idee erachter goed zichtbaar is.

Productconfigurator-5weken

Het bouwen van de productconfigurator heb ik uiteindelijk gedaan met behulp van Three.

js en Collada. Deze technieken bleken het gunstigste te zijn op het gebied van kwaliteit,

flexibiliteit en interactie.

Omdat de modellen van Studio i2 niet geschikt zijn voor gebruik op het web en met Three.

js, heb ik gekozen om modellen te gebruiken uit Google Warehouse, een online biblio-

theek met modellen die te importeren zijn in Google Sketchup. In Sketchup is het mogelijk

om een scene die deze modellen bevat, te exporteren naar een Collada bestand, waardoor

deze te importeren is in Three.js.

Het prototype van de productconfigurator laat goed zien wat de mogelijkheden zijn van

WebGL. Hoewel er nog enkele elementen verbeterd kunnen worden (zoals de modellen,

die op dit moment niet speciaal voor WebGL zijn ontwikkeld), is het representatief voor

een uiteindelijk product. Het is niet mogelijk om elementen van een product aan te pas-

sen, zoals dat gaat bij een productconfigurator, maar het geeft wel aan dat het mogelijk is

om een model in te laden na de input van een gebruiker. Het combineren van modellen

(zie figuur x) zorgt er uiteindelijk voor dat er relatief simpel een echte productconfigurator

wordt gebouwd.

5.1.6 Evaluatie prototype

Aan de hand van het prototype kan er worden gestart met de (door)ontwikkeling van

het uiteindelijke product. Het is bij de evaluatie belangrijk om het prototype te vergeli-

jken met andere producten in dezelfde categorie. Daarmee wordt het duidelijk hoe een

techniek zich verhoudt tot andere technieken en of de workflow van andere technieken

vergelijkbaar is.

Wanneer blijkt dat het prototype niet toereikend is, is het belangrijk om te kijken waar dat

aan ligt. Het probleem kan liggen bij de kwaliteit, dat die gewoonweg niet toereikend is,

maar ook het ontwikkelproces kan te kostbaar blijken. Mocht het prototype wel aansluiten

op het concept, dan is de stap naar een functioneel product niet heel groot meer.

Productconfigurator-1week

Zie hiervoor hoofdstuk 5.3: WebGL versus bestaande productconfigurator.

69

5.2 UITWERKING EN TECHNIEK

Het uiteindelijke prototype bestaat uit een webpagina gebouwd in XHTML in combinatie

met CSS en Javascript. Het is een simpele pagina met het WebGL element centraal, een

simpele titel en wat knoppen die zorgen voor de interactiviteit met de WebGL applica-

tie. Met deze knoppen is het mogelijk om een model in de scene te zetten, en het vorige

model te verwijderen. Op dit manier is het mogelijk om verscheidene modellen in te laten

en af te wisselen aan de hand van de keuze van de gebruiker.

Het WebGL is ingevoegd door middel van een iFrame. Het iFrame huisvest een andere

XHTML pagina met daarin het canvas element. Op die manier wordt het makkelijk om de

muispositie op te vangen relatief aan het WebGL gedeelte van de website, wat vooral van

belang is wanneer men op bepaalde elementen in de WebGL scene wil klikken.

De modellen zijn Collada modellen die afkomstig zijn uit Google Warehouse, een online

bibliotheek met modellen die te importeren zijn in Google Sketchup. In Sketchup is het

mogelijk om een scene te exporteren naar Collada, waardoor deze te importeren is in

Three.js. Ik heb gekozen voor deze modellen omdat deze vaak een stuk minder polygonen

bevatten, waardoor ze sneller in Three.js worden geladen.

Helaas zijn deze modellen op dit moment nog niet perfect te importeren. Sommige zijdes

van het model zijn niet zichtbaar of missen in de webapplicatie. In de recente releases van

Three.js staan veel verbeteringen met betrekking tot Collada, dus ook in de toekomst zal

dit een stuk beter worden.

Figuur 15: Schermafbeelding van een

stoel uit de Three.js productconfigurator.

70

De scene bestaat uit een houten vloer waarop de modellen staan, met in de omgeving een

zwarte mist. De modellen worden belicht door 2 onzichtbare lichtbronnen die links-, en

rechtsvoor iets boven de modellen zijn geplaatst. Dit zorgt voor voldoende belichting van

de modellen terwijl er nog wel wat contrast aanwezig is. De modellen laten een schaduw

vallen op de grond, maar niet op zichzelf. Dit heeft te maken met de Three.js library, die

schaduwen nog niet volledig ondersteund.

Door met de muis te klikken en te slepen, kan de camera gedraaid worden. De camera

draait op een denkbeeldige bol die om de scene is geplaatst. Door met de muis te scrollen

is het ook mogelijk om in te zoomen op de scene.

Oorspronkelijk was het idee om een volledige productconfigurator te maken, maar gezien

de beschikbare tijd ben ik hier van af gestapt en heb ik gefocust op de weergave van de

modellen. Door modellen niet te verwijderen, is het mogelijk om meerder modellen te

combineren. Elk onderdeel van het product wordt dan een los model die wordt ingeladen.

Door ze allemaal op dezelfde plek in de scene te zetten, kunnen deze meerdere modellen

samen een product vormen in de webapplicatie.

71

Figuur 16: Schermafbeelding van een

kast uit de Three.js productconfigurator.

72

5.3 WEBGL VERSUS BESTAANDE CONFIGURATOR

Helaas heb ik de modellen die zijn gebruikt voor de klassieke productconfigurator, niet

kunnen gebruiken omdat deze niet geschikt waren voor gebruik met Three.js en WebGL.

Ondanks dat kan ik een redelijke vergelijking maken tussen het WebGL prototype en de

klassieke productconfigurator die werkt met Javascript en afbeeldingen die van te voren

zijn gerenderd.

Het belangrijkste verschil zit hem natuurlijk in de techniek. Het WebGL prototype rendert

zelf de beelden terwijl de gebruiker er naar kijkt, terwijl de beelden al van te voren zijn

gerenderd bij de klassieke productconfigurator. Dit heeft als voordeel dat er minder data

naar de gebruiker gestuurd hoeft te worden, alleen het model en de code om dit model

op het scherm te zetten is nodig voor de complete visuele weergave. Zeker wanneer de

gebruiker het model bekijkt vanaf diverse hoeken en in verschillende configuraties scheelt

dit aanzienlijk.

Het renderen aan de kant van de eindgebruiker heeft ook nog een groot nadeel. Je hebt als

ontwikkelaar namelijk niet complete controle over wat er aan de kant van de eindgebruik-

er gebeurt. Zo is het mogelijk dat de gebruiker op een netbook werkt, welke een zwakke

grafische kaart bevat. Hierdoor kan de framerate van de applicatie bijzonder laag zijn. Dit

zorgt ervoor dat je als ontwikkelaar nooit zeker weet of de eindgebruiker een goed beeld

krijgt van het product.

73

5.4 INKA3D

Tijdens mijn experimenten heb ik geprobeerd om modellen uit Maya in de browser te

tonen door middel van WebGL. Dit heb ik gedaan met behulp van een aantal hulpmidde-

len, waaronder Inka3D.

Inka3D is een plugin voor Maya die het mogelijk maakt om scene’s te exporteren naar

WebGL. Het is speciaal gemaakt voor Maya en maakt verder geen gebruik van WebGL

libraries. Het is dus erg moeilijk om de applicatie aan te passen nadat deze is geëxporteerd

vanuit Maya. Het grote voordeel van deze plugin is het feit dat de modellen zo goed als

perfect uit Maya komen. Er zijn weinig tot geen fouten in de modellen te ontdekken en de

framerate blijft zeer acceptabel, ook bij complexe modellen.

Het grootste nadeel aan Inka3D is de matige interactiviteit die mogelijk is. Tijdens mijn

experimenteren heb ik geen makkelijke manier gevonden om de camera aan te passen met

de muis of elementen in de scene aan te passen. Wel is het mogelijk om een animatie te

maken, zoals het draaien van de camera om een object.

Ik zie het voordeel van Inka3D niet in praktische toepassingen. Alles wat mogelijk is met

Inka3D is makkelijker en mooier te maken door middel van vaste afbeeldingen of een

video, daarom bied het in mijn ogen geen voordelen en is het overbodig.

Figuur 17: De stappen van Autodesk

Maya naar WebGL door middel van

Inka3D.

Figuur 18: Schermafbeelding van een

model geëxporteerd met Inka3D.

74

6

Op dit moment staat WebGL nog in de kinderschoenen en wordt het vooral gebruikt in

technologische experimenten. Een aantal bedrijven heeft zich al gewaagt aan het func-

tioneel gebruiken van de techniek, maar de schaal van die bedrijven en de kosten die dat

meebrengt zegt een hoop over de huidige staat.

WebGL is een techniek die een hoop technische kennis vraagt en veel ervaring in Javas-

cript en programmeren in het algemeen, iets wat Studio i2 op dit moment niet in huis

heeft. Om WebGL te gebruiken, moeten ze daar dus in investeren door een programmeur

aan te nemen.

Wanneer Studio i2 investeert in WebGL en Three.js, is het mogelijk om in de toekomst uit

te breiden naar andere markten waarin WebGL een belangrijke rol kan spelen, zoals games

en datavisualisatie

Conclusie

75

6.1 Three.js Productconfigurator

6.2 Terugblik

6.3 Final thoughts

76

6.1 THREE.JS PRODUCTCONFIGURATOR

Het is relatief eenvoudig om een productconfigurator te bouwen in WebGL met behulp van

Three.js. Ook is het heel goed mogelijk om een Content Management System hier omheen

te bouwen, zodat het vaker is te gebruiken. Het enige wat dan nog op maat moet worden

gemaakt zijn de modellen en natuurlijk de website zelf.

Een belangrijk onderdeel van de productconfigurator is natuurlijk de weergave van het

product. Het product is vaak datgene wat verkocht moet worden, dat betekend dat deze er

zo goed mogelijk uit moet zien. Alle details en materialen moeten kloppen, maar ook de

belichting moet in orde zijn.

Naast de weergave van het product zelf, is ook de rest van de scene van belang. Het

product neemt vaak maar 40% van de ruimte op het scherm in beslag, waardoor de

achtergrond van groot belang is voor de algehele visuele ervaring. Vaak wordt er gebruik

gemaakt van een vervaagde achtergrond om te zorgen dat de aandacht volledig op het

product gericht is. Er zijn in Three.js een aantal mogelijkheden om een achtergrond te

creëren. De makkelijkste methode is het toevoegen van mist. Deze mist zorgt ervoor dat de

scene langzaam wit of zwart wordt in de diepte, hierdoor wordt de illusie gecreëerd dat er

niet echt een einde zit aan de scene.

Modellen die worden gemaakt voor het renderen door middel van MentalRay, zijn niet

direct te gebruiken in Three.js. De COLLADA modellen zijn te groot (het kan oplopen tot

zo’n 50MB) om over het web te versturen en met zo veel polygonen is het lastig om een

goede framerate te realiseren binnen de applicatie. Daarom moeten deze modellen spe-

ciaal worden ontwikkeld voor gebruik in Three.js. Dat betekend dat het aantal polygonen

beperkt moet blijven en het materiaal simpel moet zijn. Wanneer de modellen ook worden

gebruikt in normale afbeeldingen door middel van MentalRay, moeten deze dus twee keer

worden gemaakt.

6.1.1 De klant

In overleg met een klant kan worden gekozen voor een WebGL productconfigurator, deze

heeft een aantal voordelen en nadelen voor de klant:

Voordelen

» Werkt zonder plugin bij zo’n 50% van de webgebruikers

» Mogelijkheid om een product in de volledige 360 graden te bezichtigen.

» Oneindig veel interactiviteit mogelijk

Nadelen

» Eventuele hogere kosten door het dubbel maken van modellen

» Lagere visuele kwaliteit

» Werkt nog niet op mobiele apparaten en bepaalde browsers

77

6.1.2 Studio i2

Daarnaast zijn er ook nog voordelen en nadelen voor Studio i2 bij een WebGL productcon-

figurator

Voordelen

» Geen rendertijd meer

» Snel opnieuw te gebruiken

» Kennis van Three.js is ook voor andere doeleinden te gebruiken

Nadelen

» Veel programmeerkennis nodig

» Andere workflow met betrekking tot het modelleren

6.1.3 Conclusie

Het belangrijkste advies wat ik kan geven is: Pas de techniek aan naar de eisen van het

uiteindelijke product en -nog belangrijker- de eindgebruiker. Wanneer Javascript in com-

binatie met voorgerenderde beelden voldoet aan aan de eisen van het product, is er geen

enkele reden om WebGL te gebruiken. Wanneer er echter meer interactiviteit gewenst is

(zoals het traploos aanpassen van de afmetingen van een product), is het een goed idee

om te kijken wat WebGL en Three.js kunnen betekenen. Let echter altijd op de eindge-

bruiker, als de website voornamelijk wordt bekeken op mobiele apparaten, is het (nog)

geen goed idee om WebGL in te zetten, die ondersteunen de techniek namelijk niet.

Met dat in het achterhoofd is het geen verkeerd idee om het bedrijf voor te bereiden op

deze nieuwe techniek. Wanneer Studio i2 een programmeur in dienst neemt, kan deze op

rustige momenten kijken naar Three.js en WebGL en daarmee wat prototypes te ontwik-

kelen. Dat is niet alleen goed voor het portfolio van het bedrijf (je laat immers zien dat je

bezig bent met nieuwe en innovatieve technieken), maar kan ook aan klanten laten zien

wat er allemaal mogelijk is.

78

6.2 TERUGBLIK

In mijn tijd heb ik heel veel geleerd over WebGL. Deze scriptie bevat veel informatie over

alles wat te maken heeft met de techniek en 3D op het web. Het prototype is niet direct

om te zetten naar een product dat kan worden gebruikt, waardoor het op de korte termijn

minder oplevert. Maar de kennis die in deze scriptie zit is op de lange termijn een stuk

waardevoller voor een bedrijf, omdat het in gaat op de diepere gedachte achter de tech-

niek en de manier waarop deze gebruikt moet worden.

Het is leuk om te melden dat Studio i2 ondertussen al een product heeft uitgerold waar

WebGL in is verwerkt. Het betreft een applicatie waarin het mogelijk is om een 360 graden

foto te bekijken op de PC, iPad en iPhone. Op de PC werkt dat gewoonlijk met Flash, maar

wanneer de browser WebGL ondersteund, wordt Flash niet gebruikt maar gaat de applica-

tie over op WebGL, wat de performance ten goede komt.

6.3 FINAL THOUGHTS

Aan het einde van mijn onderzoek kan ik concluderen dat WebGL in combinatie met Three.

js een zeer toegankelijke techniek is voor de gemiddelde webdeveloper waar heel veel

mooie dingen mee mogelijk zijn. De limiet ligt puur in de creativiteit van de ontwikkelaar,

met genoeg tijd en budget is vrijwel alles mogelijk. Ik verwacht dan ook dat de toekomst

erg mooie dingen zal brengen op het gebied van 3D graphics op het web in combinatie

met WebGL.

79

80

7Begrippenlijst

81

3D artist

Iemand die 3D modellen ontwikkeld en ontwerpt, vaak met behulp van software zoals

Autodesk Maya.

3D Engine

Een engine is de basis van een 3D applicatie. Deze neemt de weergave van modellen op

zijn rekening, de berekening van het licht en de camera. Ook dingen als de detectie van

botsingen van modellen kunnen door de engine worden gedaan. Engine’s zijn vaak (zeker

in games) erg complex en zijn goed uitgedacht.

Framework

Zie ‘library’.

Framerate

Het aantal beelden per seconde in multimedia. Ookwel verversingsfrequentie genoemd.

Library

Een library, ookwel ‘bibliotheek’ in het nederlands, is een verzameling code die er vaak

voor zorgt dat een programmeur niet continue dezelfde code hoeft te schrijven voor be-

paalde zaken. Daarbij maken library’s het vaak mogelijk om bepaalde taken efficiënt uit te

voeren, die normaal gesproken vele regels code nodig hebben.

Native WebGL

Hiermee bedoel ik WebGL zonder gebruik van hulpmiddelen zoals libraries. Het ontwikke-

len met native WebGL betekend dat er echte WebGL code wordt geschreven, en geen code

die een library vertaald naar WebGL.

Plugin

Een plugin is een uitbreiding op een applicatie die vaak een bepaalde taak versimpeld of

functionaliteit toevoegt aan de applicatie.

Productconfigurator

Een applicatie waarmee het mogelijk is om een product aan te passen naar de wens van de

gebruiker. Zie ook hoofdstuk 4.2.1.

Renderen

Een 3D scene omzetten naar een afbeelding of video. Dit gebeurt vaak met software die

alle elementen in een scene meeneemt in het maken van deze afbeelding, zoals het licht,

de reflectiviteit van een oppervlakte en de camera.

82

Scene

Een 3D omgeving met daarin objecten, lichten, camera’s en andere elementen.

Webapplicatie

Een webapplicatie is een softwareapplicatie die draait binnen de webbrowser. Vaak staat

de applicatie online op een website, maar met de komst van HTML5 is het ook mogelijk om

deze offline te gebruiken.

83

84

8Bibliografie

85

» akamai.com. (n.d.). akamai.com. akamai.com. Retrieved April 3, 2012, from http://www.akamai.com

» Algharabat, R., & Dennis, C. (2009). Using Authentic 3D Product Visualisation for an Electrical Online Retailer JCB, 1–21.

» Anttonen, M., Salminen, A., Mikkonen, T., & Taivalsaari, A. (2011). Transforming the web into a real application platform: new technologies, emerging trends and missing pieces (pp. 800–807). ACM. doi:10.1145/1982185.1982357

» Bar-Zeev, A. (2011, June 16). Why Microsoft and Internet Explorer need WebGL (and vice-versa). realityprime.com. Retrieved March 6, 2012, from http://www.realityprime.com/articles/why-microsoft-and-internet-explorer-need-webgl

» Bilton, N. (2011, July 5). Video Game Industry Continues Major Growth, Gartner Says. bits.blogs.nytimes.com. Retrieved April 2, 2012, from http://bits.blogs.nytimes.com/2011/07/05/video-game-industry-continues-major-growth-gartner-says/

» Boulton, M. (2005, September 28). Turning the corner: Designing for Web 2.0 | Mark Boulton. markboulton.co.uk. Retrieved April 13, 2012, from http://www.markboulton.co.uk/journal/comments/turning-the-corner-designing-for-web-20

» Bryson, S. (2007). Effects of lag and frame rate on various tracking tasks, 1–12.

» Cabello, R. (n.d.). Issue #1960: White Paper for Three.js? github.com. Retrieved June 11, 2012, from https://github.com/mrdoob/three.js/issues/1960

» Campbell, H., & Saviage, M. (2005, December 5). Adobe to acquire Macromedia. adobe.com. Retrieved March 15, 2012, from http://www.adobe.com/aboutadobe/invrela-tions/adobeandmacromedia.html

» chrome.blogspot.com. (n.d.). chrome.blogspot.com. chrome.blogspot.com. Retrieved March 6, 2012, from http://chrome.blogspot.com

» comScore. (2012). comScore 2012 Mobile Future in Focus, 1–49.

» Doverspike, J. (2011). GPU vs. CPU Rasterization, 1–6.

» FairerPlatform. (2011, May 3). New in OS X Lion: Safari 5.1 brings WebGL, Do Not Track and more | FairerPlatform. fairerplatform.com. Retrieved March 6, 2012, from http://fairerplatform.com/2011/05/new-in-os-x-lion-safari-5-1-brings-webgl-do-not-track-and-more/

» Fui-Hoon Nah, F. (2004). A study on tolerable waiting time: how long are Web users willing to wait?, 1–37.

» Gay, J. (n.d.). The History of Flash. adobe.com, The Dawn of Web Animation. Retrieved March 15, 2012, from http://www.adobe.com/macromedia/events/john_gay/page04.html

» Ha, L., & McCann, K. (2008). An integrated model of advertising clutter in offline and online media. International Journal of Advertising, 27(4), 569. doi:10.2501/S0265048708080153

» Hickson, I. (2004, July 12). Hixie’s Natural Log: Extending HTML. ln.hixie.ch. Retrieved June 12, 2012, from http://ln.hixie.ch/?start=1089635050&count=1

» International Data Corporation. (2011, November 3). Samsung Takes Top Spot as Smartphone Market Grows 42.6% in the Third Quarter, According

86

to IDC. idc.com. Retrieved March 5, 2012, from http://www.idc.com/getdoc.jsp?containerId=prUS23123911

» Isberg, A. (2011, November 29). Xperia™ phones first to support WebGL™ — Develop-er World. developer.sonymobile.com. Retrieved June 12, 2012, from http://developer.sonymobile.com/wp/2011/11/29/xperia-phones-first-to-support-webgl/

» Jankowski, J. (2011). A taskonomy of 3D web use. In Web3D ‘11: Proceedings of the 16th International Conference on 3D Web Technology. Presented at the Web3D ‘11: Proceedings of the 16th International Conference on 3D Web Technology,  ACM Re-quest Permissions. doi:10.1145/2010425.2010443

» Jobs, S. (2010, April 1). Thoughts on Flash. apple.com. Retrieved March 5, 2012, from http://www.apple.com/hotnews/thoughts-on-flash/

» Keizer, G. (2008, June 23). Firefox 3.0 boosts Mozilla’s market share. computer-world.com. Retrieved March 13, 2012, from http://www.computerworld.com/s/arti-cle/9102398/Firefox_3.0_boosts_Mozilla_s_market_share

» Khronos. (n.d.). COLLADA - 3D Asset Exchange Schema. (Khronos, Ed.)khronos.org. Retrieved June 12, 2012, from http://www.khronos.org/collada/

» KhronosGroup. (2011, March 3). Khronos Releases Final WebGL 1.0 Specification - Khronos Group Press Release. khronos.org. Retrieved March 6, 2012, from http://www.khronos.org/news/press/khronos-releases-final-webgl-1.0-specification

» Kleinhout, H. (2011, October 13). Opera Desktop Team - Introducing Opera 12 alpha. my.opera.com. Retrieved March 6, 2012, from http://my.opera.com/desktopteam/blog/2011/10/13/introducing-opera-12-alpha

» Lazar, J. (2001). User-centered Web development. Jones and Bartlett Publishers.

» Leung, C., & Salga, A. (2010). Enabling WebGL (pp. 1369–1370). ACM. doi:10.1145/1772690.1772933

» Mackinlay, J. D., Card, S. K., & Robertson, G. G. (1990). Rapid Controlled Movement Through a Virtual 3D Workspace, 1–6.

» McDonnell, S. (2011, March 28). Deloitte’s Top Technology Trends for 2011: Data Visualization and Real Analytics. spotfireblog.tibco.com. Retrieved June 12, 2012, from http://spotfireblog.tibco.com/?p=5591

» Metz, C. (2008, June 26). AVG disguises fake traffic as IE6. theregister.co.uk. Retrieved March 13, 2012, from http://www.theregister.co.uk/2008/06/26/avg_disguises_fake_traffic_as_ie6/

» Mozilla. (2011, March 22). Mozilla Firefox 4 Release Notes. mozilla.org. Retrieved March 6, 2012, from http://www.mozilla.org/en-US/firefox/4.0/releasenotes/

» MSRCEngineering. (2011, June 16). WebGL Considered Harmful. blogs.technet.com. Retrieved March 6, 2012, from http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx

» Nielsen, J. (1993, January 1). Response Time Limits. useit.com, The 3 Important Limits. Retrieved March 5, 2012, from http://www.useit.com/papers/responsetime.html

» Roosendaal, T., & Sharybin, S. (2012, January 6). Collada importer/exporter kickout. lists.blender.org. Retrieved June 12, 2012, from http://lists.blender.org/pipermail/bf-committers/2012-January/035006.html

87

» Sons, K., Klein, F., Rubinstein, D., Byelozyorov, S., & Slusallek, P. (2010). XML3D: inter-active 3D graphics for the web. In Web3D ‘10: Proceedings of the 15th International Conference on Web 3D Technology. Presented at the Web3D ‘10: Proceedings of the 15th International Conference on Web 3D Technology,  ACM Request Permissions. doi:10.1145/1836049.1836076

» StatOwl. (2012, February 1). Web Browser Plugin Market Share / Global Usage. statowl.com. Retrieved March 15, 2012, from http://www.statowl.com/plugin_overview.php

» statowl.com. (n.d.). statowl.com. statowl.com. Retrieved March 15, 2012, from http://www.statowl.com

» Taivalsaari, A., Mikkonen, T., Ingalls, D., & Palacz, K. (2008). Web Browser as an Applica-tion Platform: The Lively Kernel Experience, 1–25.

» tweakers.net. (n.d.). tweakers.net. tweakers.net. Retrieved June 4, 2012, from http://tweakers.net

» Winokur, D. (2011, November 9). Flash to Focus on PC Browsing and Mobile Apps; Ado-be to More Aggressively Contribute to HTML5 (Adobe Featured Blogs). blogs.adobe.com. Retrieved March 5, 2012, from http://blogs.adobe.com/conversations/2011/11/flash-focus.html

» Yeung, L. W., Ng, W., & Cheng, J. (2005). Comparative Analysis of XML Compression Technologies, 1–32.

88

9Bijlage

89

9.1 index.html

9.2 webgl.html

9.3 product_configurator.js

9.4 Experiment 1: shadows.html

9.5 Experiment 2: onclick.html

9.5 Experiment 3: advancewars.js

90

9.1 INDEX.HTML1. <!DOCTYPE html>2. <html>3. <head>4. <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8” />5. <title>Productconfigurator</title>6. <link href=”css/style.css” rel=”stylesheet” type=”text/css” />7. <script src=”js/jquery.js” type=”text/javascript”></script>8. </head>9. <body>10. <div class=”center wrapper”>11. <div class=”header”>12. <h1>ProductConfigurator</h1>13. </div>14. 15. <divclass=”configurator”>16. <div class=”selection”>17. <divclass=”webgl-container”>18. <!-- Insert the WebGL element via an iFrame. This makes mouse-interaction easy. -->19. <iframename=”webgl”id=”webgl-frame”src=”webgl.html”></iframe>20. </div>21. <ul class=”options”>22. <!-- Adding a model is fairly simpel with an onclick javascript action -->23. <li onclick=”addModel(‘models/billy/IKEA_-_Billi___Benno.dae’)”>24. <imgsrc=””>25. <h3>Ikea Billy</h3>26. <span class=”price”>&euro; 99,-</span>27. </li>28. <lionclick=”addModel(‘models/galant/Galant.dae’)”>29. <imgsrc=””>30. <h3>IkeaGalant</h3>31. <span class=”price”>&euro; 99,-</span>32. </li>33. <li onclick=”addModel(‘models/billy2/billy2.dae’)”>34. <imgsrc=””>35. <h3>Ikea Billy 2</h3>36. <span class=”price”>&euro; 99,-</span>37. </li>38. <lionclick=”addModel(‘models/poang/poang.dae’)”>39. <imgsrc=””>40. <h3>LeuningRechts2</h3>41. <span class=”price”>&euro; 599,-</span>42. </li>43. <li onclick=”addModel(‘models/bank2/bank2.dae’)”>44. <imgsrc=””>45. <h3>Ikea Bank</h3>46. <span class=”price”>&euro; 99,-</span>47. </li>48. <div class=”clear”></div>49. </ul>50. <div class=”clear”></div>51. </div>52. </div>53. </div>54. <script type=”text/javascript”>55. // This is an important and tricky part of the system. Because the actual WebGL is inside an iFrame,56. // we need to reach that iFrame to execute code inside the WebGL application. To do this, we use57. // jQuery to assign the iFrame to a variable, which we use to execute functions.58. var dataFrame;59. var current;60. $(document).ready(function(){61. dataFrame=window.webgl;62. });63. function addModel(location){64. dataFrame.removeModel(current);65. current = dataFrame.loadModel(location);66. }67. </script>68. </body>69. </html>

91

9.2 WEBGL.HTML70. <!doctype html>71. <html>72. <head>73. <title>WebGLtest</title>74. <!-- This CSS makes sure that the html document and canvas fills the whole iFrame75. so it doesn’t generate any scrollbars -->76. <style>77. html, body, .container {78. margin:0;79. padding:0;80. width:100%;81. height:100%;82. overflow:hidden;83. }84. 85. .wrapper {86. width:100%;87. height:100%;88. margin:0;89. z-index:1;90. }91. </style>92. </head>93. <body>94. <divclass=”wrapper”id=”webgl”></div>95. <!-- inserting all the scripts. It is important to maintain a correct order of96. inserting the scripts, as some scripts require other scripts and generate errors97. when these scripts aren’t yet loaded -->98. <script src=”js/jquery.js”></script> <!-- jQuery for easy acces of the DOM -->99. <script src=”js/Three.js”></script> <!-- Three.js core -->100. <!-- These are all extensions that make developing Three.js easy -->101. <script src=”js/ColladaLoader.js”></script>102. <script src=”js/SphereControls.js”></script>103. <!-- The code to create the productconfigurator itself -->104. <scriptsrc=”js/product_configurator.js”></script>105. </body>106. </html>

92

9.3 PRODUCT_CONFIGURATOR.JS1. // Set variables2. var container;3. var camera, scene, renderer, stats;4. var sphere, plane, cube, cube2;5. varlight;6. var mesh, model, current;7. var controls;8. init();9. animate();10. 11. function removeModel(){12. scene.remove(current);13. }14. 15. function loadModel(location){16. // When a model is loaded, remove the current (old) model from the scene.17. removeModel();18. // Import a model19. varloader=newTHREE.ColladaLoader();20. // This is the loader which loads the collada model.21. loader.load(location,function(geometry){22. model=geometry.scene;23. model.scale.set(1, 1, 1);24. model.position.y = -30;25. // This loop enables shadow on all elements of the model.26. // The model consists out of multiple layers, so we need to loop through each layer to makes sure27. // the whole model casts a shadow.28. for(vari=0;i<model.children.length;i++){29. model.children[i].castShadow = true;30. for(varii=0;ii<model.children[i].children.length;ii++){31. model.children[i].children[ii].castShadow = true;32. for(variii=0;iii<model.children[i].children[ii].children.length;iii++){33. model.children[i].children[ii].children[iii].castShadow = true;34. for(variiii=0;iiii<model.children[i].children[ii].children[iii].children.length;iiii++){35. model.children[i].children[ii].children[iii].children[iiii].castShadow = true;36. }37. }38. }39. }40. model.castShadow = true;41. model.updateMatrix();42. // Rotate the model so it displays correctly in the scene43. model.rotation.x = 270 * (Math.PI/180);44. scene.add(model);45. current = model;46. });47. }48. 49. // Initiate the scene.50. function init(){51. // Get the container with jQuery along with the width and height52. var$container=$(“#webgl”);53. varwidth=document.body.offsetWidth;54. varheight=document.body.offsetHeight;55. 56. // Create the scene itself with a black fog.57. scene=newTHREE.Scene();58. scene.fog=newTHREE.Fog(0x050505,800,1200);59. 60. // Create a perspective camera with a ratio equal to window’s ratio.61. camera=newTHREE.PerspectiveCamera(40,width/height,1,1200);62. camera.position.set(0, 30, 0);63. scene.add(camera);64. 65. // Create a plane which acts as the ground. We use a JPG image as texture.66. vargt=THREE.ImageUtils.loadTexture(“images/vloer_003_6m.jpg”);67. vargg=newTHREE.PlaneGeometry(2000,2000);68. vargm=newTHREE.MeshPhongMaterial({color:0xffffff,map:gt,perPixel:true});69. varground=newTHREE.Mesh(gg,gm);70. // Repeat the texture over the mesh71. ground.material.map.repeat.set(4,4);72. ground.material.map.wrapS=ground.material.map.wrapT=THREE.RepeatWrapping;73. // Make sure the ground receives a shadow.74. ground.receiveShadow=true;75. // We lower the ground so the camera can’t “dive” under the floor.76. ground.position.y=-30;77. scene.add(ground);78. 79. // Add lights to the scene, we add 2 for better visibility of the model.80. scene.add(newTHREE.AmbientLight(0x222222));81. varlight=newTHREE.SpotLight(0xffffff,1,1000);82. light.position.set(100,250,100);83. light.castShadow=true;84. light.shadowMapWidth=1024;85. light.shadowMapHeight=1024;86. light.shadowMapDarkness=0.95;87. scene.add(light);

93

88. 89. varlight=newTHREE.SpotLight(0xffffff,1,500);90. light.position.set(-100,150,150);91. light.castShadow=true;92. light.shadowMapWidth=1024;93. light.shadowMapHeight=1024;94. light.shadowMapDarkness=0.95;95. scene.add(light);96. 97. // Set the renderer, the object that actually generates the WebGL98. renderer=newTHREE.WebGLRenderer({antialias:true});99. renderer.setSize(width,height);100. // We use the fog color to fill the rest of the window which isn’t covered by any object.101. renderer.setClearColor(scene.fog.color,1);102. renderer.gammaInput=true;103. renderer.gammaOutput=true;104. renderer.shadowMapEnabled = true;105. // Add the renderer to the container in the DOM106. $container.append(renderer.domElement);107. 108. // Add controls which are used to rotate the camera around the object.109. controls=newTHREE.SphereControls(camera,window,500);110. controls.target.set(0,0,0);111. }112. 113. function animate(){114. controls.update();115. render();116. }117. 118. function render() { 119. renderer.render( scene, camera );120. requestAnimationFrame(animate);121. }122. 123. functionradianDegree(degree){124. returndegree*(Math.PI/180);125. }

94

9.4 EXPERIMENT 1: SHADOWS.HTML1. <!doctype html>2. <html>3. <head>4. <title>WebGLtest</title>5. <style>6. html, body {7. font-family:Arial,Helvetica;8. background-color:#eee;9. width:100%;10. height:100%;11. margin:0;12. padding:0;13. overflow:hidden;14. }15. 16. .container {17. margin:0;18. width:100%;19. height:100%;20. }21. 22. .wrapper {23. width:100%;24. height:100%;25. background-color:#AAA;26. margin:0;27. }28. 29. </style>30. <script src=”js/jquery.js”></script>31. <script src=”js/Three.js”></script>32. </head>33. <body>34. <divclass=”wrapper”id=”webgl”></div>35. </body>36. <script type=”text/javascript”>37. 38. // Set variables39. var container;40. var camera, scene, renderer, stats;41. var cube;42. varpointLight;43. var plane;44. 45. // Initialize (create objects and cameras)46. init();47. 48. animate();49. 50. function init(){51. // Get the container with jQuery52. var$container=$(“#webgl”);53. var width = $container.width();54. varheight=$container.height();55. 56. // Create a camera57. // Camera angle = 7058. camera=newTHREE.PerspectiveCamera(45,width/height,1,10000);59. // Set camera position and camera target position60. camera.position.z = 800;61. camera.position.x = 400;62. camera.position.y = 400;63. // Create camera target vector64. cameraTarget=newTHREE.Vector3(0,0,0);65. camera.lookAt(cameraTarget);66. 67. // Create a new scene68. scene=newTHREE.Scene();69. 70. // Create a mesh by creating a cube geometry with a basic red material71. geometry=newTHREE.CubeGeometry(200,200,200);72. material=newTHREE.MeshLambertMaterial({color:0xff0000,shading:THREE.FlatShading});73. 74. cube=newTHREE.Mesh(geometry,material);75. 76. // Add the cube to the scene77. scene.add(cube);78. 79. // Add a plane to the scene80. plane=newTHREE.Mesh(newTHREE.PlaneGeometry(500,500),newTHREE.MeshLambertMaterial({color:0xCCCCCC,shading:

THREE.FlatShading}));81. plane.position.y = -200;82. plane.rotation.x=radianDegree(270);83. plane.overdraw = true;84. plane.recieveShadow = true;85. scene.add(plane);86.

95

87. // Add a light to the scene88. // create a point light89. pointLight=newTHREE.PointLight(0xFFFFFF);90. 91. // set its position92. pointLight.position.x=50;93. pointLight.position.y=500;94. pointLight.position.z=500;95. 96. // add to the scene97. scene.add(pointLight);98. 99. // Add the camera to the scene100. scene.add(camera); 101. 102. // Create the renderer103. renderer=newTHREE.CanvasRenderer();104. renderer.setSize(width,height);105. $container.append(renderer.domElement);106. }107. 108. function animate(){109. // Render the 3D scene110. render();111. 112. requestAnimationFrame(animate);113. }114. 115. function render() {116. cube.rotation.y+=0.02;117. cube.rotation.z+=0;118. 119. pointLight.position.x+=0;120. 121. renderer.render( scene, camera );122. }123. 124. functionradianDegree(degree){125. returndegree*(Math.PI/180)126. }127. 128. </script>129. </html>

96

9.5 EXPERIMENT 2: ONCLICK.HTML1. <!doctype html>2. <html>3. <head>4. <title>WebGLtest</title>5. <style>6. html, body {7. font-family:Arial,Helvetica;8. background-color:#eee;9. width:100%;10. height:100%;11. margin:0;12. padding:0;13. overflow:hidden;14. }15. 16. .container {17. margin:0;18. width:100%;19. height:100%;20. }21. 22. .wrapper {23. width:100%;24. height:100%;25. background-color:#AAA;26. margin:0;27. }28. 29. .ext-input {30. width:960px;31. height:28px;32. background-color:#FFF;33. padding:20px;34. box-shadow:0px0px20px0px#CCC;35. }36. 37. .clear {38. clear:both;39. }40. 41. </style>42. <script src=”js/Three.js”></script>43. <script src=”js/threex.domevent.js”></script>44. <script src=”js/threex.domevent.object3d.js”></script>45. </head>46. <body>47. <div class=”container”>48. <div class=”clear”></div>49. <divclass=”wrapper”id=”webgl”></div>50. <div class=”ext-input” id=”info”>51. 52. </div>53. </div>54. </body>55. <script type=”text/javascript”>56. 57. // Set variables58. var container;59. var camera, scene, renderer, info, projector;60. var meshes = {};61. var mouse2d;62. var cube;63. init();64. 65. animate();66. 67. function init(){68. // Get the container with jQuery69. varcontainer=document.getElementById(‘webgl’);70. 71. varwidth=container.offsetWidth;72. varheight=container.offsetHeight;73. 74. projector=newTHREE.Projector();75. 76. // Create a camera77. camera=newTHREE.PerspectiveCamera(45,width/height,1,10000);78. // Set camera position and camera target position79. camera.position.z = 500;80. camera.position.x = 500;81. camera.position.y = 500;82. 83. // Create a new scene84. scene=newTHREE.Scene();85. camera.lookAt(scene.position);86. 87. // Create a mesh by creating a cube geometry with a basic red material

97

88. geometry=newTHREE.CubeGeometry(50,50,50);89. material=newTHREE.MeshLambertMaterial({color:0xff0000});90. 91. cube=newTHREE.Mesh(geometry,material);92. meshes[‘cube1’] = cube;93. 94. // Add a plane to the scene95. varplane=newTHREE.Mesh(96. newTHREE.PlaneGeometry(400,200,10,10),97. newTHREE.MeshLambertMaterial({color:0xCCCCCC,shading:THREE.SmoothShading})98. );99. plane.position.y = -50;100. plane.rotation.x=radianDegree(270);101. meshes[‘plane1’] = plane;102. 103. // Add light to the scene104. varlight=newTHREE.SpotLight();105. light.position.set(170,330,-160);106. 107. // Add shadows to the scene108. light.castShadow=true;109. cube.castShadow = true;110. cube.receiveShadow = true;111. plane.receiveShadow = true;112. plane.castShadow = true;113. 114. // Add all the objects, lights and camera to the scene115. scene.add(light);116. scene.add(cube);117. scene.add(plane);118. scene.add(camera);119. 120. THREE.Object3D._threexDomEvent.camera(camera);121. 122. // Create the renderer123. renderer=newTHREE.WebGLRenderer({antialias:true});124. renderer.shadowMapWidth = 1024;125. renderer.shadowMapHeight=1024;126. renderer.setSize(width,height);127. renderer.shadowMapEnabled = true;128. renderer.shadowMapSoft = false;129. container.appendChild(renderer.domElement);130. setBinds();131. }132. 133. function animate(){134. // Render the 3D scene135. render();136. requestAnimationFrame(animate);137. }138. 139. function render() {140. // Rotate the cube141. meshes[‘cube1’].rotation.y+=0.0;142. 143. document.getElementById(“info”).innerHTML=“info”;144. 145. renderer.render( scene, camera );146. }147. 148. function setBinds(){149. meshes[‘cube1’].on(‘click’, function(object3d){150. object3d.target.scale.x+=2;151. object3d.target.scale.z*=1.01;152. });153. }154. 155. functionradianDegree(degree){156. returndegree*(Math.PI/180);157. }158. </script>159. </html>

98

9.6 EXPERIMENT 3: ADVANCEWARS.JS1. // Set variables2. var container;3. var camera, scene, renderer, stats, controls;4. var keyPress = new Array();5. var units = new Array();6. var tiles = new Array();7. var cameraPosition = {};8. var selected;9. var hover;10. var marker;11. 12. // Set gameplay variables13. // Time it takes for a unit to move 1 tile14. var speed = 100;15. // Tile size16. var tileSize = 10;17. // Segments used in the red arrow18. vararrowSegments=2;19. 20. // Tweening variables21. varmoving;22. var position = {};23. vartarget={};24. var tween;25. 26. // Initialize (create objects and cameras)27. init();28. animate();29. 30. 31. function animate(t){32. // Update gamestate (gameloop)33. updateState(t);34. 35. // Render the 3D scene36. render();37. 38. requestAnimationFrame(animate);39. }40. 41. function render() {42. renderer.render(scene, camera);43. }

Opmerking: Het doel van dit experiment was het ontwikkelen van een kleine game (op basis van

Nintendo’s Advance Wars). Daar ben ik een heel eind mee gekomen, maar ik heb het helaas niet af

kunnen maken omdat het teveel tijd kostte. Op de bijgeleverde CD staat alle code die hiervoor is ge-

schreven, deze staat in het mapje “advancewars”. Omdat het zo veel code is, heb ik deze niet allemaal

toegevoegd in de bijlage.

99

100

101