Veebilehitsejal Põhinev Rakendus Kolmemõõtmelise Mudeli Pindade Kujundamiseks

EESTI INFOTEHNOLOOGIA KOLLEDŽ

Timo Triisa

VEEBILEHITSEJAL PÕHINEV RAKENDUS KOLMEMÕÕTMELISE MUDELI PINDADE KUJUNDAMISEKS

Diplomitöö

INFOSÜSTEEMIDE ARENDUSE ÕPPEKAVA

Juhendaja: Märt Kalmo

Tallinn 2017

AUTORIDEKLARATSIOON

Deklareerin, et käesolev diplomitöö, mis on minu iseseisva töö tulemus, on esitatud Eesti Infotehnoloogia Kolledžile lõpudiplomi taotlemiseks Infosüsteemide arendamise erialal. Diplomitöö alusel ei ole varem eriala lõpudiplomit taotletud.

Autor Timo Triisa …………………………….

(allkiri ja kuupäev)

Töö vastab kehtivatele nõuetele

Juhendaja Märt Kalmo ……………………………..

(allkiri ja kuupäev)

Sisukord

Mõisted ja lühendid ...... 5

Sissejuhatus ...... 7

1. Probleemi püstitus ja metoodika ...... 8

1.1. Probleem ...... 8

1.2. Eesmärk ...... 9

1.3. Metoodika ...... 9

2. Ärianalüüs ...... 11

2.1. Lähtetingimused ...... 11

2.2. Ettevõtte nõuded ...... 11

2.3. Funktsionaalsed nõuded ...... 12

2.3.1. Piltide lisamine pindadele ...... 12

2.3.2. Kihid ...... 12

2.3.3. Pindade värvimine ...... 12

2.3.4. Trükiks ette valmistamine ...... 13

2.3.5. Kasutajaliides ...... 13

2.4 Mitte-funktsionaalsed nõuded ...... 14

3. Tehnoloogiate analüüs ...... 15

3.1. Nõuded tehnoloogiatele ...... 15

3.2. Tehnoloogiate otsimine ...... 16

3.3. Tehnoloogiate võrdlus ...... 17

3.3.1. Babylon.js ...... 17

3.3.2. Goo Engine ...... 18

3.3.3. PlayCanvas ...... 18

3.3.4. Three.js ...... 19

3.3.5. Hindamine ja kokkuvõte ...... 19

4. Arendusprotsess ja tulemused ...... 21

4.1. Prototüüpide loomine ...... 21

4.1.1. Prototüüpide funktsionaalsus ...... 21

4.1.2. PlayCanvas prototüüp...... 22

4.1.3. Babylon.js prototüüp ...... 22

4.1.4. Three.js prototüüp ...... 24

4.1.5. Prototüüpide jõudluse hindamine...... 24

4.1.6. Prototüüpide arendamise tulemused...... 26

4.2. Rakenduse loomine ...... 26

4.2.1. Arenduse käigus lisandunud funktsionaalsus ...... 27

4.3. Tulemus ...... 28

Kokkuvõte ...... 30

Summary ...... 31

Kasutatud kirjandus ...... 33

Lisa 1 – Babylon.js prototüübi lähtekood ...... 36

Lisa 2 – Three.js prototüübi lähtekood ...... 38

Mõisted ja lühendid

Application Programming Interface (API) – on reeglistik olemasoleva valmisprogrammiga suhtlemiseks

Arendusuuring – praktilise rakenduse loomist käsitlev uuring

Canvas – HTML5 standardi element, mis võimaldab kasutades JavaScripti, elemendile algoritmiliselt graafikat kujutada

Adobe Flash – multimeedia platvorm, millega saab luua interaktiivseid rakendusi erinevatele platvormidele

GitHub – võrgupõhine versioonihaldus repositoorium

Graafikakiirendi ehk graafikaprotsessor – kohandatud mikroprotsessor, mis tegeleb 3D- ja 2D-graafika visualiseerimisega

HTML – enimlevinud kodeerimissüsteem veebidokumentide loomiseks

Mebibait – (ingl mebibyte, MiB) mälumahu mõõtühik, mis on võrdne 1 048 576 baidiga.

PHP: Hypertext Preprocessor (PHP) – vabavaraline skriptimiskeel, mille eesmärk on lihtsustada dünaamiliste veebilehtede loomist

Plugin – tarkvarale lisafunktsionaalsust pakkuv eraldiseisev laiendus

Repositoorium – versioonihaldus tarkvarades kasutatav hoidla

Ristprojektsioon – perspektiiviõpetuses projektsioon, kus silmapunkti asemel antakse kujutamiskiirte siht, ning kujutamiskiired on ekraaniga risti

Silmapunkt – perspektiiviõpetuses vaatleja silma läätse keskpunkt

Stseen – kolmemõõtmeline ruum, mida kasutatakse objektide organiseerimiseks graafikaprogrammides

UV-kaardistamine – (ingl UV-mapping) kahemõõtmelise pinna kaardistamine kolmemõõtmelisele mudelile, eesmärgiga projitseerida kahemõõtmelist rastergraafikat mudeli pindadele

Web Graphics Library (WebGL) – JavaScripti API, kahe- ja kolmemõõtmelise graafika visualiseerimiseks veebilehitsejates, kasutades graafikakiirendeid ilma lisanduvate pluginateta.

WordPress – vabavaraline avatud lähtekoodiga sisuhaldustarkvara, mis on kirjutatud PHP-s

Sissejuhatus

Kolmemõõtmeliste mudelite visualiseerimine, kasutades graafikakiirendeid veebilehitsejate sisese funktsionaalsusena, on saanud võimalikuks selle kümnendi alguses. Enam ei ole sunnitud kasutaja paigaldama arvutisse lisanduvat tarkvara riistvaralise kiirenduse kasutamiseks veebirakendustes ning arendajad saavad vajaduselt kasutada seadme graafikakiirendit parema jõudluse tagamiseks.

Ettevõtte Metroprint Systems OÜ soovib pakkuda oma e-poe klientidele veebirakendust, milles on võimalik nende tootevalikus olevate toodete pindade kujundamine, vahetades toote värvi või lisades sellele pilte. Ometi ei leidu sellist terviklikku lahendust, mida Metroprint Systems OÜ vajab. Ettevõte on üsna kindel, et selline lahendus aitaks kaasa nende müügile. Autor usub, et ettevõtte soovid on teostatavad ja on otsustanud asuda ettevõtte probleemi lahendama.

Autor püstitab töös probleemi, selgitab töö eesmärki ning kirjeldab metoodikat millest lähtudes autor probleemi lahendab. Seejärel selgitab välja ettevõtte konkreetsed ärilised vajadused ning analüüsib milline peab olema rakenduse funktsionaalsus, et ettevõtte nõuded ja vajadused saaks täidetud ning probleem lahendatud.

Rakenduses vajamineva funktsionaalsuse põhjal otsib autor probleemi lahendamiseks sobivad tehnoloogiad. Autor kirjeldab rakenduse nõuete põhjal kriteeriumid, mida tehnoloogia peab suutma täita. Kriteeriumid täitnud tehnoloogiate põhjal, loob autor prototüüprakendused, mille eesmärk on veenduda tehnoloogiate võrdluses selgunud kriteeriumite täidetavuses, kontrollida tehnoloogia sobivust probleemi lahendamiseks, märgata võimalikke takistusi ning valida rakenduse arendamiseks kõige sobivam tehnoloogia. Töö tulemuseks valmib rakendus, mis lahendab ettevõtte Metroprint Systems OÜ probleemi. Autor hindab tulemuse vastavust ettevõtte nõuete ja soovidega.

1. Probleemi püstitus ja metoodika

1.1. Probleem

Ettevõtte Metroprint Systems OÜ soov on olla konkurentidest silmapaistvam ning pakkuda oma klientidele mugavamat e-poe keskkonda. Hetkel on ettevõttel e-poes tootevalik esitatud illustreerivate piltidega mööblist. Müüdav mööbel toodetakse omapärasel viisil kärgkartongist, mille pinnad saab katta ka trükimaterjalidega, mis võimaldab mööbli kodus ilma tööriistadeta lihtsalt kokku voltida (Designboard kodulehekülg, 2017). Kuid ettevõtte soovib olla veelgi unikaalsem ning nende põhiliseks ideeks kujunes veebirakendus. See võimaldab tootevalikuga tutvuda läbi kolmemõõtmeliste mudelite ja soovi korral ise mööbli pinda graafiliselt kujundada, lisades sellele näiteks pilte.

Sarnaste valmis lahenduste otsimiseks kasutas autor Google otsingumootoris märksõnu „design your own furniture“ ning hiljem täpsustas otsingut sõnadega „software“ ja „online“. Leitud interaktiivsed lahendused, mis sarnanesid kõige rohkem ettevõtte soovile, olid ruumide üldiseks planeerimiseks ning mööbli katte materjalide valimiseks – kolmemõõtmeliselt pööratavaid mudeleid ja lisatavate piltidega lahendusi autor ei leidnud.

Seega ettevõtte põhiliseks takistuseks on nende vajadusi täitva rakenduse puudumine. Autor leiab, et ettevõtte probleemi lahendamiseks tuleb luua eriotstarbeline rakendus. Ettevõttel puudub detailne ettekujutus kuidas rakendus töötama peaks ning kuidas see täpselt lõppkasutajat aitab. Seega rakenduse loomiseks tuleb autoril koos ettevõttega kirjeldada nõuded ja funktsionaalsus, mis on töö alustamiseks vajalikud, et valida õiged töövõtted ja tehnoloogiad lahenduse loomiseks.

Vaadates laiemalt, Metroprint Systems OÜ probleem on üldistatav ka teistele toodetele ja ettevõtetele ning selle lahenduse välja töötamine oleks kindlasti heaks aluseks sarnaste rakenduste loomisel. Seega leiab autor, et võrreldes lahenduseks sobivaid tehnoloogiaid, tuleks uurimisaluse ettevõtte spetsiifilised nõuded võrdlusest välja jätta ning keskenduda just kolmemõõtmelisust puudutavate aspektidega. See tähendab, et autor võtab küll Metroprint Systems OÜ vajadused aluseks ja lahendab ettevõtte probleemi, kuid keskendub antud töös kolmemõõtmelisust saavutavatele tehnoloogiatele.

1.2. Eesmärk

Autori eesmärk selle töö raames on leida parim viis eeltoodud probleemi lahendamiseks. Kaudselt on eesmärgiks ka pakkuda paremaid võimalusi lõpptarbijale, võrdlust teistele sarnaste nõuetega arendatavatele süsteemidele ning tagada kriteeriumid, mis võimaldaks sooritada kordusuuringut.

Diplomitöö analüütilise osa eesmärgiks on kirjeldada rakenduses vajalikud nõuded ja funktsionaalsus. Nende põhjal leida nõuetele vastavad tehnoloogiad ja vahendid, millega on võimalik veebilehitsejas esitada toodete kolmemõõtmelist projektsiooni ja tagada kasutajale tööriistad toote pindade kujundamiseks. Analüütiline ja praktiline osa on seotud tehnoloogiate võrdlemisel, kus parema võrdlustulemuse saamiseks luuakse tehnoloogiate põhjal prototüübid.

Diplomitöö praktilise osa eesmärgiks on analüütilises osas selgunud nõuete täitmine, mille käigus valmib rakendus, mis lahendab ettevõtte Metroprint Systems OÜ probleemi.

1.3. Metoodika

Autor lahendab probleemi arendusuuringu metoodikaga, jagades analüüsi kaheks osaks. Esimeses osas teostab autor ärianalüüsi, kus uurib ning kirjeldab ühe ettevõtte vajaduste näitel, milline funktsionaalsus on loodavas rakenduses vajalik, ning kas ja kuidas on võimalik rakendus teostada.

Teises osas teostab autor tehnoloogiate analüüsi, kus alguses üldistab funktsionaalsuse minimaalsele tasemele, mis puudutab kolmemõõtmeliste mudelite visualiseerimist ja käitlemist. Üldistamine on oluline, et oleks võimalik kindlate kriteeriumite järgi otsida ja võrrelda lahenduseks sobivaid tehnoloogiaid. Seejärel hindab autor tehnoloogiate sobivust probleemi lahendamiseks eelnevalt kirjeldatud kriteeriumite järgi.

Kriteeriumeid täitnud tehnoloogiate põhjal, loob autor prototüüp rakendused. Seejärel analüüsib autor prototüüpide tulemusi ning nende arenduse käigus ilmnenud takistusi. Prototüüpide loomise käigus peab selguma, kas tehnoloogia ikka sobib rakenduse arendamiseks. Töö alguses püsitatud probleemile lahendust pakkuv rakendus luuakse kasutades tehnoloogiat, mis on autori põhjendatud hinnangul prototüüpide loomisel kõige parimini hakkama saanud.

Tulemuste osas mainib autor parimaks osutunud tehnoloogiat ning kuidas see sobis rakenduse arendamiseks. Kas rakendus lahendab ettevõtte probleemi ja millised oleksid võimalused laiendusteks ja edasiarendusteks.

2. Ärianalüüs

2.1. Lähtetingimused

Viimasel kümnendil on tekkinud uus võimalus kasutada graafikakiirendeid veebilehitsejasse sisse ehitatud funktsionaalsusena. HTML5 sai arengus hoogu juurde, kui Adobe 2011 aastal loobus Flash-i mobiiliversiooni arendamisest (Adobe, 2011). Samal aastal loodi ka esimene WebGL spetsifikatsioon ning aasta lõpus oli WebGL API suurematesse veebilehitsejatesse implementeeritud (Mozilla Developer Network, 2017).

Ettevõttel Metroprint Systems OÜ puudub selge nägemus, milline peab olema loodava rakenduse funktsionaalsus ning milliseid tehnoloogiad rakendus peaks kasutamas. Tooted, mida ettevõte e-poes müüakse, projekteeritakse tarkvaras ArtiosCAD. Samast tarkvarast on saadud hetkel e-poes kasutusel olevad pildid ning on ka võimalik välja eksportida erinevates formaatides kolmemõõtmelisi mudeleid ja pinnalaotusi mööbli detailidest.

2.2. Ettevõtte nõuded

Ettevõte poolt esitatud nõuded on autor välja selgitanud pidades Metroprint Systems OÜ esindajatega läbirääkimisi. Ettevõte leiab, et esialgu võiks rakendus olla funktsionaalsuselt lihtsam, eesmärgiga välja selgitada, kas inimestel on teenuse vastu huvi ja hoida seni rakenduse arendamise kulud võimalikult väiksed.

Ettevõte näeb põhilise funktsionaalsusena kasutaja võimalust toote pindasid värvida ja piltidega illustreerida. Mudelil on pindasid, mida kasutaja ei tohiks saada kujundada, kuna sinna ei saa trükimaterjali kleepida. Need pinnad on kärgkartongi plaadi servad ning neid tuleks mudelil kujutada visuaalselt sarnaselt tegelikkusele, et jätta tarbijale tootest võimalikult täpne kuvand. Samuti on vaja rakenduses väljundit, kasutaja loodud kujunduse trükki saatmiseks.

Lõppkasutajal ei tohiks rakenduse kasutamiseks olla vaja lisanduvat tarkvara, rakendus võiks olla 3D mudelite disainist võõrale inimesele lihtsasti kasutatav. Ettevõte ei osanud täpsustanud, millised on lihtsasti kasutatava rakenduse tunnused, seega autor lähtub rakenduse kasutajaliidese ning funktsionaalsuse loomisel enda arusaamale lihtsast kasutatavusest.

2.3. Funktsionaalsed nõuded

2.3.1. Piltide lisamine pindadele Lähtudes ettevõtte soovidest, lisada mööbli pindadele pilte, leiab autor, et lisatud pilte peaks saama ka pinnal liigutada, pöörata ning nende suurust muuta. Teiseks peab saama ettevõte saata kasutaja loodud kujunduse trükki. Arvestades neid tingimusi, peaks autori arvates piltidega ümber käimine toimuma toote kahemõõtmelisel pinnalaotusel, mitte kolmemõõtmelise mudeli projektsioonil. Sellega väheneb keerukus, kuidas pildi transformatsioone ekraanil kursoriga läbi viia ja pärast pilt trüki jaoks kahemõõtmelisele pinnale projitseerida.

Pinnalaotus, mida ArtiosCAD projekteerimistarkvarast eksportida saab, on ettevõtte sõnul juba sobival kujul trükki saatmiseks. Seega võiks kasutada saadaolevat pinnalaotust lõuendina, kuhu peale kasutaja saab pilte lisada. Piltide projitseerimiseks mudeli pindadele, saab kasutada UV-kaardistamise meetodit, luues kaardi, mis viib mudeli tipud vastavusse pinnalaotuse koordinaatidega (Zeman, 2014).

2.3.2. Kihid Mitme pildi lõuendile lisamisel saab tekkida olukord, kus hiljem lisatud pilt katab varem lisatud pilti. Kasutajal võib olla soov piltide järjekorda muuta, et piltide kattuvust parandada. Kuna kasutatakse kolmemõõtmelist ruumi, tuleks iga lisatav pilt paigutada ruumis eelmisest pildist kõrgemale, tekitades sellega kihid. Piltide kihtides paiknemist saab muuta kasutajaliideses piltide nimistus. Oluline on, et piltide töötlemise ruum projitseeritaks ekraanile kasutades ristprojektsiooni. Vastasel juhul võidakse projitseerida silmapunktist kaugemale jäävad pildid väiksemana, kui lähedal asuvad pildid.

2.3.3. Pindade värvimine Mudeli pindade värvimine on autori sõnul mõistlik teha nii, et kõik mudeli pinnad saab katta ainult ühe – kasutaja poolt valitud värviga. Selline lahendus vähendab ettevõtte kulutusi keerulisemate lahenduste pealt, kus kasutaja saaks pinna selekteerida ning seejärel

12 selle värvi määrata, või pintslit jäljendava tööriistaga ise mudelile maalida. Erinevate pindade mitme erineva tooniga värvimiseks, saab kasutaja alati mudelile lisada ühe- või mitmevärvilisi pilte.

2.3.4. Trükiks ette valmistamine Kasutaja lisatud pildid lisatakse lõuendile, mis projitseeritakse kolmemõõtmelise mudeli peale. Sama lõuendit projitseeritakse ka tasapinnale, et näidata kasutajale ekraanil piltide paiknevust toote pinnalaotusel. Tasapinna projektsiooni on võimalik salvestada rastergraafikana kasutades JavaScriptis File API-t ning seejärel saata trükki (World Wide Web Consortium, 2015). Probleemiks võib tulla aga rastergraafika puudujääk, kus skaleerimisega tekib infokadu, ja trükis ei pruugi tulla kvaliteetne.

Projektsiooniks kasutatavat tasapinda ei tohi ka liiga suureks teha. Näiteks 4096x4096 piksli suuruse ja 24-biti värvisügavusega punktraster vajab 384MiB videomälu, aga 8192x8192 pikslit sama värvisügavusega vajab juba 1536MiB videomälu. Selle põhjal võib järeldada, et sülearvuti mille graafikakiirendi jagab protsessoriga sama põhimälu ja millel on 2GB mälu, ei suudaks rakendust toetada, kui rakendus püüab eraldada 1536MiB mälu. Seetõttu tuleks piirduda väiksema resolutsiooniga kujutisega ning pakkuda rakenduses väljundit ka algsete originaalmõõdus pildifailidega. Nende põhjal võiks saada trüki ettevalmistaja juba, mõnes laiema funktsionaalsusega rakenduses ja suurema jõudlusega seadmes, taasluua kasutaja kujunduse kõrgema resolutsiooniga.

Võib ette tulla olukord, kus kasutaja lisatav pilt on juba algselt liiga väikeste mõõtmetega, mis ei ole piisav tagamaks trükkimisel kvaliteetset tulemust, annab leevendada teadaandega rakenduses. Teadaanne hoiataks kasutajat pildi suuremaks skaleerimise korral võimalikust kvaliteedi langusest ning soovitab seda mitte teha või kasutada suurema resolutsiooniga pilti.

2.3.5. Kasutajaliides Ettevõttel ei olnud rakenduse kasutajaliidese kohta ettepanekuid. Võttes arvesse eelnevalt kirjeldatud funktsionaalsust, oleks vaja kasutajaliidesele kuvada piltide töötlemise lõuend, koos pinnalaotusega, ja toote kolmemõõtmelise mudeli projektsioon. Nende vaateaknad võiks olla korraga nähtavad ja paikneda kõrvuti. Lisades pilte pinnalaotusele, oleks tulemust kohe kolmemõõtmelisel mudelil näha.

Piltide kihtidel liigutamiseks ja pinna värvide muutmiseks on vaja tööriistariba. Piltide nimekirjas saaks muuta nende paiknevust kihtides, samas nimekirjas saab pilte kustutada. Piltide nimekiri ja toote värvi valimise tööriist võiks paikneda eraldi gruppidena, kuid samal tööriistaribal. Lisaks on vaja ka tööriistariba järgnevate funktsioonide paigutamiseks: kujunduse salvestamine, ettevõttele saatmine, väljundite eksportimine jms.

Autor leiab rakenduse keerukusest, et see võiks avaneda uues veebilehitseja kaardis või aknas. Sellega jääb kogu ekraani pind rakenduse kasutada ning välditakse ka rakenduse integreerimist olemasoleva veebipoe rakendusega.

2.4 Mitte-funktsionaalsed nõuded

Rakenduse tööd ei saa garanteerida liiga vähese põhi- ja videomälu olemasolul. Soovitatavalt peaks seadmel põhimälu olema vähemalt 4GB. Graafikakiirendi kasutamiseks peab see toetama OpenGL ES API versiooni 2.0 (Khronos Group, 2014). Arvestades kasutajaliidese analüüsis selgunud nõudeid, peaks seadme resolutsioon olema vähemalt 1024x768 pikslit. Töötamiseks on vajalik kaasaegne veebilehitseja, mis toetab tehnoloogiaid nagu WebGL ja File API.

Rakendus tuleks paigutada failisüsteemis e-poe rakendusest eraldi kataloogi, et vältida olukordi, kus ressursside nimed võivad kattuda või kasutatakse inimliku vea tõttu valesid ressursse.

3. Tehnoloogiate analüüs

3.1. Nõuded tehnoloogiatele

Kuna rakendus peab töötama veebilehitsejas siis on otstarbekas otsida tehnoloogiat mis põhineb JavaScriptil. Autor kasutab HTML5 elementi canvas kuna sellel on võimalus algoritmiliselt graafikat kujutada, lisaks on sellel graafikakiirendi tugi kasutades WebGL’i (World Wide Web Consortium, 2014). Autor leiab, et ainult WebGL API kasutamine soovitud tulemuste saamiseks võib olla liiga ajakulukas ja vajaminev kood mahult suur, kuna API on madala abstraktsioonitasemega (Khronos Group, 2011). Selleks otsib autor sobiva WebGL-i tuge pakkuva raamistiku või teegi millega rakendus kirjutada.

Sobivuse määramiseks kirjeldab autor kriteeriumid millele valitav tehnoloogia peab vastama. Kriteeriumid põhinevad näitajatele mille põhjal tehnoloogiaid võrrelda saab ja ärianalüüsis selgunud nõuetele, et veenduda tehnoloogiate sobivuses probleemi lahendamiseks. Kriteeriumid on järgnevad:

• Avatud lähtekoodiga – kas projekt on avatud lähtekoodiga. GBdirect kirjutab oma artiklis, et avatud lähtekoodiga projektid saavad täiendusi ja parandusi ka teistelt inimestelt ja ettevõtetelt, ning püsivad seetõttu kaasaegsemad. Rakendustes esineb vähem turvaauke ning suur kogukond võib pakkuda paremat abi probleemide korral (GBdirect, 2017). • Dokumentatsiooni ja juhendite olemasolu – autori jaoks on oluline kiirus, kui ruttu saab arendaja hakata uut tehnoloogiat kasutama hakata. Kiiresti valmiv rakendus on kliendile odavam ja säästab arendaja aega. Lisaks aitab dokumentatsiooni olemasolu teha kindlaks, kas teegi funktsionaalsus on piisav probleemi lahendamiseks.

• Kasutajaskonna suurus – avatud lähtekoodiga lahenduste puhul kasutab autor hindamiseks projekti toetavate, ehk programmikoodiga või muul viisil panust andvate, liikmete arvu. Autori arvates näitab kasutajaskonnas suurus, kui palju tehnoloogiat lähiajal edasi arendatakse, ning kui kindlalt saab vajadusel korral abi. • Probleemi lahendamiseks vajaminev funktsionaalsus – autor soovib luua rakenduses dünaamilise piltide lõuendi. Lõuendile lisatakse pilte, neid saab lõuendil liigutada, pöörata ja suurust muuta. Oluline on, et lõuendit saaks mudelile projitseerida kasutades UV-kaarte, ning et lõuendi saaks salvestada rastergraafikana. • Mugavusfunktsioonid – kas tehnoloogia ise, või selle kohta käiv abimaterjal, pakub tuge objektide liigutamiseks millegi suhtes, näiteks silmapunkti tiirlemiseks ümber punkti. • Mudelite sisendid – mis formaadis mudeleid on raamistikus või teegis võimalik sisse laadida. Oluline on, et formaat mida ettevõtte pakkuda suudab, oleks toetatud.

3.2. Tehnoloogiate otsimine

Autor otsis WebGL-i kasutavaid lahendusi Google otsingumootorist märksõnadega: „WebGL“, „library“ ja „framework“. Töö kirjutamise hetkel leidis autor 11 raamistiku ja teeki. Nende kõigi põhjalik võrdlemine on autori sõnu ebavajalik ning liiga aega nõudev. Kodulehelt ja dokumentatsioonist saadava info põhjal on juba näha, kas raamistiku funktsionaalsus on liiga pealiskaudne või põhieesmärgiks on midagi muud kui antud töö probleemi lahendamiseks vajaminev. Autor põhjendab lühidalt iga lahenduse juures, miks see edasisest võrdlusest välja jäetakse.

Tehnoloogiad mida autor hakkab põhjalikumalt võrdlema:

• Babylon.js • Goo Engine • PlayCanvas • Three.js

Tehnoloogiad mis autor leidis, kuid otsustas võrdlusest välja jätta:

• A-Frame – põhineb ise Three.js-il ja lisatud funktsionaalsus on eesmärgiga teha rakendusi virtuaalreaalsuse seadmetele (A-Frame, 2017) • KickJS – väga väike kasutajaskond, funktsionaalsus on üsna pealiskaudne (KickJS GitHub, 2017) • LayaAir – ametlik dokumentatsioon ja õpetused on suurem jaolt hiina keeles (LayaBox, 2017) • PrimroseVR – põhineb ise Three.js-il ja lisatud funktsionaalsus on eesmärgiga teha rakendusi virtuaalreaalsuse seadmetele (PrimroseVR, 2017) • TWGL – ei taga kriteeriumites nõutud funktsionaalsust (TWGL, 2017) • Unity – võimalus eksportida HTML5 ja WebGL lahendus (Unity3D, 2017). Konkurentide tehtud võrdluse põhjal on Unity tulemus kiiruselt aeglasem ja mahult suurem kui PlayCanvase samaväärne lahendus (PlayCanvas, 2016). • Voxel.JS – mõeldud kuubikutest mängude tegemiseks, sisaldab üleliigset funktsionaalsust (VoxelJS, 2017)

3.3. Tehnoloogiate võrdlus

3.3.1. Babylon.js Babylon.js on raamistik põhieesmärgiga arendada 3D mänge. GitHubi repositoorium on loodud aastal 2013 ja lõputöö kirjutamise hetkel on laetud repositooriumisse uuendusi, millest kõige viimane on üks päev vana. Raamistiku allalaadimisel on võimalik koostada erilahendus, kus saab välja jätta ebavajalikke mooduleid. Dokumentatsioonis on arvestatav kogus näiteid ja 8 tundi videokursust (Babylon.js GitHub, 2017; Babylon.js kodulehekülg, 2017).

Babylon.js kasutab enda failiformaati stseenide, mudelite, valgustuste, silmapunktide jms salvestamiseks ja laadimiseks. Importida on võimalik, COLLADA, Wavefront OBJ ja Stereolithography formaadis mudeleid. Lisaks pakutakse eksportimise pluginaid ja konversiooniprogramme teiste formaatide teisendamiseks Babylon.js enda formaati. Toetatud programmid on Blender, Unity ja 3D Studio Max (Babylon.js GitHub, 2017; Babylon.js kodulehekülg, 2017).

Funktsionaalsus silmapunkti tiirlemiseks ümber punkti ja panoraamimiseks mööda telge on olemas funktsiooni ArcRotateCamera näol. Lõuendi koostamiseks ja mudelile projitseerimiseks on olemas klassid DynamicTexture ja RenderTargetTexture (Babylon.js dokumentatsioon, 2017).

3.3.2. Goo Engine Goo Engine on kirjelduse põhjal üldotstarbeline WebGL teek. GitHubi repositoorium on loodud 2015 aasta novembris, olles neljast võrreldavast tehnoloogiast kõige uuem (Goo Engine GitHub, 2017). Saadaval on API kirjeldus, valmis näited erinevatest võimalustest ja 2 tundi videokursust. Sisu loomiseks on olemas platvorm Goo Create, mis toetab 3D Studio Max, Alembic, COLLADA, FilmBox, Wavefront OBJ formaate (Goo Create, 2017).

Kodulehel saadaolevate õpetuste põhjal leiab autor, et Goo Engine on mõeldud rohkem kasutada läbi Goo Create platvormi ning eesmärk on pigem luua kunsti ja mänge kui tehnilisi rakendusi (Goo Create, 2017).

Lihtustav funktsioon silmapunkti tiirlemiseks ümber punkti on saadaval õpetusena (Goo Create, 2017). Autoril ei õnnestunud API kirjelduse põhjal selgeks teha, kas on võimalik luua lõuend, mida saab dünaamiliselt muuta ja mudelile projitseerida (Goo Engine dokumentatsioon, 2017).

3.3.3. PlayCanvas PlayCanvas on teek eesmärgiga luua mänge, GitHubi repositoorium on loodud 2014 aastal. Toetab formaate nagu 3D Studio Max, COLLADA ja Wavefront OBJ (PlayCanvas GitHub, 2017). Dokumentatsioonis on lisaks API kirjeldusele suur kogus näiteid, kuid autor peab negatiivseks asjaolu, et näidete vaatamiseks peab tegema PlayCanvase kodulehel konto. Sarnaselt Goo Engine-le on PlayCanvas kasutav teegina, kuid soovitatakse kasutada PlayCanvas Editor platvormi sisu loomiseks. (PlayCanvas dokumentatsioon, 2017; PlayCanvas kodulehekülg, 2017).

Silmapunkti tiirlemiseks on näidetes olemas klass OrbitCamera (PlayCanvas kodulehekülg, 2017). Dünaamilise lõuendi tegemiseks on olemas klass RenderTarget, mille funktsionaalsust saab kasutada mudelile projitseerimiseks ning lõuendi salvestamiseks. (PlayCanvas dokumentatsioon, 2017)

3.3.4. Three.js Three.js on üldotstarbeline teek, mis on GitHubi lisatud juba 2010 aastal, olles vanim neljas võrreldavast tehnoloogiast. Dokumentatsioonis on API kirjeldus ja suures koguses näiteid. Three.js toetab formaate 3D Studio Max, Wavefront OBJ, Collada, Babylon, Point Cloud Data jpt. Three.js kasutab teegis enda failiformaate nii geomeetria, materjalide kui ka stseenide kirjeldamiseks. Saadaval on eksportimise pluginad rakendustele 3D Studio Max, Blender, Maya ja Revit – mis salvestavad otse Three.js formaati. Three.js on suuresti modulaarne ning on võimalik koostada eriotstarbeline versioon, mis sisaldab vähem funktsionaalsust (Three.js GitHub, 2017, Three.js dokumentatsioon, 2017).

Olles teistest ligikaudu kuus korda suurema toetajaskonnaga, on näha ka põhjalikumat dokumentatsiooni koos suure hulga näidetega, mis on autori arvates Three.js-i suur eelis teiste samaväärsete tehnoloogiate ees. Miinusteks võib tuua aga selle, et tuleb ette uuendusi, mis muudavad funktsionaalust nii, et vanemaid versioone uuendades ei pruugi rakendus enam töötada (Three.js GitHub, 2017).

Funktsionaalsus piltide lõuendi jaoks on saadaval klassi WebGLRenderTarget kaudu. Silmapunkti tiirlemiseks ümber punkti on olemas klass OrbitControls (Three.js dokumentatsioon, 2017).

3.3.5. Hindamine ja kokkuvõte Kõik neli tehnoloogiat on avatud lähtekoodiga ning saadaval GitHub keskkonnas. See asjaolu teeb võrdlemise lihtsamaks, kuna kasutajaskonna suurust saab hinnata sama näitaja alusel. Kõikidel tehnoloogiatel on olemas dokumentatsioon ja näited, kuidas luua lihtne rakendus. Dokumentatsiooni osas oli Goo Engine neljast võrreldavaist kõige kehvema dokumentatsiooniga – autoril ei õnnestunud leida kinnitust, kas teek toetab funktsionaalsust projitseerida dünaamiline lõuend mudelile ja salvestada lõuend rastergraafikana.

Kasutajaskonna suurust võrreldes on selgelt näha Three.js ülekaalu, seega on tõenäoline, et Three.js saab lähiajal veel täiendusi ning parandusi. Kõige väiksema kasutajaskonnaga on tehnoloogia Goo Engine.

Vajaminev funktsionaalsus on saadaval kolmes tehnoloogias: Babylon.js, PlayCanvas ja Three.js. Goo Engine-i dokumentatsiooni põhjal ei suutnud autor kindlaks teha, kas teek suudab tagada vajaminevat funktsionaalsust. Mugavusfunktsioonid olid kõigis neljas

19 tehnoloogia puhul saadavad, mõnes otse teegi funktsionaalsuses, teistel õpetustes abistava klassina.

Mudelite sisenditena on toetatud üldlevinud formaadid nagu COLLADA, 3D Studio Max, FilmBox (Babylon.js-s eksportija kaudu) ja Wavefront OBJ. Silmapaistvamad olid Babylon.js ja Three.js, mis pakuvad ka erinevate rakenduste jaoks eksportija pluginaid. Pidades silmas ettevõtte Metroprint Systems OÜ nõudeid, selgus, et ArtiosCAD-st saab eksportida COLLADA formaadis mudeleid, mis antul juhul on toetatud kõigis tehnoloogiates.

Kokkuvõtlikult on rakenduse kirjutamiseks kõige ebasobivam tehnoloogia Goo Engine ning kõige sobivamad tehnoloogiad Babylon.js, PlayCanvas ja Three.js.

Babylon.js Goo Engine PlayCanvas Three.js

Avatud lähtekood Jah, GitHub Jah, GitHub Jah, GitHub Jah, GitHub

Dokumentatsioon Põhjalik Piisav Põhjalik Põhjalik

Kasutajaskonna 4433 tähte* 1067 tähte* 2640 tähte* 32518 tähte* suurus 128 toetajat 25 toetajat 128 toetajat 797 toetajat

Vajaminev funktsionaalsus Olemas Teadmata Olemas Olemas

Mugavusfunktsioonid Olemas Olemas Olemas Olemas

Mudelite sisendid OBJ, STL, OBJ, 3DS, OBJ, 3DS, OBJ, 3DS, DAE FBX, DAE, FBX, DAE DAE +eksportijad ABC +eksportijad Tabel 1 – Kriteeriumite täidetavus võrreldes nelja tehnoloogiat * Täht on GitHubi funktsionaalsus lisada projekt järjehoidjatesse ning võimalus näidata oma huvi projekti vastu. Andmed on uuendatud 03.05.2017 seisuga.

4. Arendusprotsess ja tulemused

4.1. Prototüüpide loomine

Kuna tehnoloogiate analüüsis selgus, et probleemi lahendava rakenduse arendamiseks sobib kolm tehnoloogiat, siis loob autor nende tehnoloogiate põhjal prototüüprakendused. Prototüüpide eesmärk on välja selgitada võimalikud probleemid, mis võivad lahenduse loomisel ette tulla, ning valida välja kõige sobilikum tehnoloogia ettevõtte Metroprint Systems OÜ probleemi lahendamiseks.

4.1.1. Prototüüpide funktsionaalsus Autor loob prototüüprakendustes funktsionaalsuse, millega saab kujutada Metroprint Systems OÜ poolt saadud mudelit, pöörata silmapunkti ümber mudeli, luua dünaamiline lõuend, mis võimaldaks lisada pilte, ning projitseerida lõuend mudelile. Sellise funktsionaalsuse implementeerimisel on võimalik kontrollida tehnoloogiate analüüsis selgunud võimaluste paikapidavust ning kas tehnoloogia sobib töö alguses püstitatud probleemi lahendamiseks.

Autor valmistas Metroprint Systems OÜ poolt saadetud mudeli kasutamiseks ette vabavaralise tarkvaraga Blender. Autor kaardistas mudeli pinnad 4096x4096 piksli suurusele lõuendile, et lõuendi projitseerimine mudelile oleks võimalik.

Tehnoloogiate versioonid mille põhjal autor prototüübid loob:

• PlayCanvas versioon 0.211.0 • Babylon.js versioon 2.5 • Three.js versioon r84

Joonis 1 - Mudeli ja pinnalaotuse kaardistamine (ingl UV-mapping)

4.1.2. PlayCanvas prototüüp PlayCanvase kõik juhendid on tehtud PlayCanvas Editori jaoks, reaalseid näiteid programmikoodist on vähe. Autoril õnnestus siiski luua sarnaselt teistele rakendustele stseen, koos valgusallikate ja pöörleva kuubikuga, kuid tekkis probleeme mööbli mudeli rakendusse laadimisega.

Autor leiab, et sobiv failiformaat Filmbox on toetatud ainult PlayCanvas Editori poolt, mitte avatud lähtekoodiga teegi poolt, kuna lähtekoodis erinevates ressursside laadimiseks mõeldud klassides oli toetatud ainult PlayCanvase sisemine formaat. Nõutav funktsionaalsus on autori arvates täidetav, kuid jääb mulje, et teegis puudub otsene võimalus sobivate formaatide sisse laadimiseks.

Töö kirjutamise hetkel puudub autoril vajaminev informatsioon, kuidas PlayCanvase teeki erinevaid mudeleid sisse laadida. Takistuse ilmnemise tõttu pole esialgu rakendust võimalik valmis arendada ning autor jätab PlayCanvase prototüüpide edasisest võrdlemisest välja.

4.1.3. Babylon.js prototüüp Tutvudes eelnevalt kõigi tehnoloogiate võimalusega, jäi autoril silma, et Babylon.js-s puudub AmbientLight tüüpi valgusallikas ning juhend soovitab selle sarnase tulemuse saavutamiseks kasutada HemisphericLight valgusallikat (Babylon.js dokumentatsioon,

2017). Ometi ei taga HemisphericLight samasugust tulemust kui AmbientLight. AmbientLight ei olene suunast ning valgustab objekte iga külje pealt sama valgustugevusega. HemisphericLight seevastu sõltub suunast ning autori vaatlustulemuste põhjal võib järeldada, et erinevalt AmbientLight-st, ei läbi see külgi ning hajub. Joonisel 2 on näha, et mudeli jalgadele paistab vähem valgust, kui ülaosasse, sest

HemisphericLight on suunatud ülevalt alla. Joonis 2 - Babylon.js prototüübi visualisatsiooni tulemus Joonisel 3 on seevastu näha, kuidas AmbientLight valgustab mudeli ülemist ja alumist osa ühtlaselt.

Tulemuste võrdlemisel tuleb silmas pidada, et mõlemal joonisel on kasutatud ka DirectionalLight valgusallikaid ning see mõjutab tajutavat visuaali, kuid autor rõhutab antud juhul Babylon.js puudujäägile, mida joonistel on selgelt näha varjude kontrastsuse erinevuses.

Babylon.js-i puhul pidas autor esialgu võõraks lähenemist, kus erinevate objektide loomisel tuleb need kohe siduda stseeniga. See tähendab, et loodavaid objekte ei saa muutujatesse valmis panna ja alles vajaduse korral stseeni lisada. Viimane iseärasus ei tekita rakenduse arendamisel probleeme.

Kaamera vaatenurga laiust saab määrata ebamäärasel skaalal reaalarvuna. Dokumentatsioonis puudus kirjeldus, mis ühikutes vaatenurga laiust määrata saab. Autor eeldab, et see võib olla nurk radiaanides.

Dünaamilise lõuendi loomine, kasutades RenderTarget funktsionaalsust, õnnestus ning toimib nii nagu autor eeldas. Joonisel 2 on näha, et mudeli pindadele on projitseeritud pöörlev roosa kuubik, mis reaalses rakenduses asendatakse piltidega.

4.1.4. Three.js prototüüp Three.js baasil prototüübi arendamisel takistusi ei esinenud. Kaamera vaatenurk on sisestatav kraadides. Stseeni tuleb objektid lisada kasutades Scene instantsi add meetodit.

Three.js teegis õnnestus dünaamilise lõuendi loomine kasutades samuti RenderTarget funktsionaalsust ning lahendus toimib nii nagu autor eeldas. Joonisel 3 on näha, et mudeli pindadele on projitseeritud pöörlev roosa Joonis 3 - Three.js prototüübi visualisatsiooni kuubik, mis reaalses rakenduses asendatakse tulemus piltidega.

4.1.5. Prototüüpide jõudluse hindamine Jõudluse hindamiseks kasutab autor JavaScripti Console API time ja timeEnd funktsionaalsust. Autor mõõdab prototüüpide jõudlust eelnevalt kirjeldatud funktsionaalsuse põhjal. See on mõõtmiseks sobiv, sest on olemuselt ressursinõudlik ning võrdlusmoment on hea, kuna mõlemad võrreldavad tehnoloogiad kasutavad dünaamilise lõuendi loomisel RenderTarget funktsionaalsust.

Jõudluse mõõtmisel käivitab autor visualiseerimise funktsiooni 10 000 korda ning mõõdab toimingule kuluvat aega. Enne iga katse algust taaskäivitatakse veebilehitseja, lastakse rakendusel enne testi alustamist ligikaudu 20 sekundit töötada ning seejärel käivitatakse jõudlustest veebilehitseja konsoolist. Kõikide katsete ajal töötab arvutis minimaalne arv tööks vajalikke rakendusi. Katsed tehakse Windows 10 operatsioonisüsteemis, mõlema rakendusega kahel korral – veebilehitsejates Mozilla Firefox 53 ja Google Chrome 58. Arvutis on protsessoriks Intel Core i5-650, taktsagedusega 3,20GHz, millel on sisse lülitatud Intel Turbo Boost Technology ning graafikakiirendi NVIDIA GeForce GTX 1060, 8GB videomäluga.

Mõlemas rakenduses visualiseeritakse kaks stseeni, milles on kokku kaks silmapunkti, kaks AmbientLight valgusallikat või selle alternatiivi, 3 DirectionalLight valgusallikat, roosa pöörlev kuubik ja mööbli mudel millele roosa kuubik projitseeritakse. Jõudluse mõõtmisel ei kasutata veebilehitsejates funktsiooni requestAnimationFrame, kuna see sünkroniseerib visualiseerimise monitori värskendussagedusega ja piirab mitu kaadrit sekundis 24 visualiseeritakse. Täpsemat objektide jaotust ja ülesehitust saab vaadata mõlema rakenduse lähtekoodist, mis on saadaval töö lisades 1 ja 2.

Programmikood, mis prototüüpide jõudlust mõõdab:

var iterations = 10000; console.time('Test'); for (var i = 0; i < iterations; i++ ) { render(); }; console.timeEnd('Test'); Visualiseerimise kood, mida render funktsioonis välja kutsutakse:

Babylon.js

function render() { testMesh.rotation.x += 0.001; testMesh.rotation.y += 0.002; dynamicScene.render(); scene.render(); }

Three.js

function render() { testMesh.rotation.x += 0.001; testMesh.rotation.y += 0.002; renderer.render(dynamicScene, dynamicCamera, dynamicTexture); renderer.render(scene, camera); }

Jõudluse testi tulemused veebilehitsejas Firefox on järgmised:

• Babylon.js visualiseeris 10 000 kaadrit 6,45 sekundiga • Three.js visualiseeris 10 000 kaadrit 2,08 sekundiga

Jõudluse testi tulemused veebilehitsejas Chrome on järgmised:

• Babylon.js visualiseeris 10 000 kaadrit 4,52 sekundiga • Three.js visualiseeris 10 000 kaadrit 1,99 sekundiga

Tulemused näitavad, et sama ülesehitusega rakendus töötas Three.js teeki kasutades vähemalt 2 korda kiiremini, kui Babylon.js-i kasutades.

4.1.6. Prototüüpide arendamise tulemused Babylon.js prototüüp suutis täita vajaminevaid nõudeid. Raamistik kujutab vaikeväärtusena mudelitele madala resolutsiooniga tumeda varju, mis autori arvates ei näe hea välja. Muid probleeme Babylon.js raamistikuga prototüübi loomise käigus ei esinenud.

Three.js prototüübi arendamine kujunes autori arvates kõige lihtsamaks põhjalike näidete tõttu, kuid võttis teistest kirjutamise poole pisut rohkem aega. Probleeme funktsionaalsuse loomise käigus ei esinenud ja teek suudab täita vajaminevad nõuded. Jõudlustestis oli Three.js suutlikus tunduvalt parem kui Babylon.js – Three.js on ligikaudu 2 korda kiirem.

4.2. Rakenduse loomine

Võttes arvesse tehnoloogiate analüüsi, prototüüpide loomisprotsessi ning isiklikku eelistust otsustas autor, et lahenduse loomiseks sobib kõige paremini Three.js teek. Rakenduse arendamisel ületamatuid probleeme ei esinenud.

Autor lähtus rakendus arendamisel protseduraalse programmeerimise stiilist ning inkrementaalse arendamise mudelile. Autor ei kasutanud arendusprotsessis otseselt ühtegi konkreetset arendamise raamistikku, kuid lähtus koolis õpetatust viisil mida pidas vajalikuks.

Joonis 4 - Ekraanipilt rakendusest

4.2.1. Arenduse käigus lisandunud funktsionaalsus Piltide galerii

Piltide lisamiseks avaneb rakenduse sisese aknana, kust saab valida pilte, mida lõuendile lisada. Galeriisse on võimalik lisada pilte enda arvutist, kui ka kasutada ettevõtte poolt pakutavaid piltide kogumikke. Lõuendile mitme pildi lisamisel ei pea ühte pilti mitu korda videomällu laadima. Samuti projekti salvestamisel salvestatakse korduvate piltide korral ainult üks koopia.

Teksti lisamine

Ettevõttel tuli rakenduse arendamise käigus idee, lisada tootele teksti rakenduse sisese funktsioonina. Autor kaalus olukorda, kus veebilehitsejas saadaolevate kirjatüüpide valik on ebapiisav ja seetõttu funktsionaalsus ka vähekasutatud. Samas nõustub autor ettevõttega, et kõik kasutajad ei pruugi tulla selle peale, et nad saavad teksti pildina tootele lisada, vaid loodavad sellist funktsionaalsust rakenduselt. Autor kasutas funktsionaalsuse loomisel HTML5 canvas elementi, millele saab lisada teksti ning seejärel kasutada canvas elemendi sisu rastegraafikana lõuendil.

Eelvaate salvestamine

Ettevõttel tekkis ka teine soov, kus kasutaja saaks salvestada kolmemõõtmelise mudeli projektsiooni rastergraafikana, eesmärgiga näidata oma kujundust kolleegidele või tuttavatele. Lahenduse implementatsioon vajas autori sõnul ühe nupu lisamist ja mudeli projektsioon on juba sarnaselt lõuendile rastergraafikana salvestatav.

Failiformaat

Salvestamiseks ja ettevõttele saatmiseks mõeldud fail koostatakse esialgu JSON vormingus, kuhu lisatakse pildifailid, mis eelnevalt tihendatakse ZIP vormingusse ja lisatakse Base64 kodeeringus. Base64 kodeering teeb autori sõnul küll pildifailid suuremaks aga JSON vormingus salvestamine ja sellest lugemine on lihtsam, kui binaarse vormingu puhul. Autor plaanib hilisemate arenduste käigus failivormingu ümber teha binaarsele kujule. Funktsionaalsus toetada tulevikus mitut versiooni failivorminguid on rakenduses juba praeguseks implementeeritud.

Faili saatmine ettevõttele

Autor leidis, et kasutajal oleks lihtsam, kui saab sobiva faili saata ettevõttele hinnapakkumise koostamiseks otse rakendusest. Kuna rakendus toetab juba disaini salvestamist enda failiformaati, siis on võimalik seda faili ka serverisse üles laadida. Autor kasutab serverisse laadimiseks XMLHttpRequest klassi ning fail saadetakse kasutades HTTP protokolli ja multipart/form-data’t.

Kuna ettevõtte e-pood on ehitatud WordPress sisuhaldustarkvara peale, otsustas autor kasutada juba ettevõttele tuttavat keskkonda ning arendas WordPressile plugina kasutades PHP-d. Antud laiendus salvestab üleslaetud faili kataloogi, teeb uuest hinnapäringust andmebaasi kande ning seejärel näitab WordPress administraatori paneelis kanded välja. Autor eeldab, et laiendus ei pruugi vastata WordPressi kõikidele nõuetele. Kuna selline funktsionaalsus ei kuulu töö algsesse skoopi, näeb autor lahendusena tutvuda WordPressi nõuetega hiljem ning seejärel plugina koodi refaktoreerida.

4.3. Tulemus

Autor uuris milliste tehnoloogiatega on kõige mõistlikum ettevõtte Metroprint Systems OÜ probleemi lahendada. Töö käigus selgus, et lahendusteks sobilike tehnoloogiaid on kaks, kuid parema tulemuse saab kasutades Three.js teeki, mis osutus teisest võrreldavast teegist vähemalt 2 korda kiiremaks. Three.js teegiga ei tekkinud rakenduse arendamisel puudujääke ega tagasilööke, teek sobis lahenduse loomiseks hästi. Autor leiab, et tehnoloogiate analüüsi ja prototüüpide loomise tulemustest, võib olla kasu ka neile, kellel vajadust sarnaste nõuetega rakenduse loomiseks.

Lõputöö kirjutamise jooksul lõi autor probleemi lahendamiseks rakenduse, mille Metroprint Systems OÜ oma e-poes kasutusele on võtnud ja planeerib kujundamiseks sobivate toodete juurde lisamist. Metroprint Systems OÜ jäi antud lahendusega rahule ja soovib lähitulevikus lisanduvat funktsionaalsust ning rakenduse viimistlemist. Hetkel takistab arendustööde jätkumist töö suur ajaline maht ja sellest tulenev hind. Ettevõte soovib enne veenduda, et rakendus end ära tasub.

Autor usub, et rakendus täidab enda eesmärki ning pakub ettevõttele lisaväärtust, kuna vastab ettevõtte nõudmistele ja lahendab probleemi püstituses leitud puudused. Kuigi ettevõtte on tulemusega rahul, leiab autor, et lahenduse tegelikku tulemust on veel raske

28 hinnata, sest rakendus on kasutusel olnud vaid mõned nädalad ja puudub piisav aruandlus mille põhjal hinnang anda.

Laiendusvõimalustena näeb autor parandada kasutajaliidest ning teha piltide töötlemise funktsionaalsus sarnasemaks graafikaprogrammile Adobe Illustrator. Lisaks uuris autor võimalust salvestada piltide töötlemise lõuend kohe Portable Document Format-i, millega ei tekiks olukorda, kus rastergraafika jääb trükiks liiga väikseks.

Kokkuvõte

Käesoleva diplomitööga on autor loonud rakenduse, mis lahendab ettevõtte Metroprint Systems OÜ probleemi. Veebirakendus pakub ettevõtte e-poe klientidele võimalust kujundada toote pindasid ning tellida ettevõttelt omapärane mööbliese. Vajaminevat terviklikku lahendust varasemalt saada polnud ning töö alustamise hetkel puudus autoril ning ettevõttel selge arusaam, kuidas olukorda lahendada. Selleks püstitas autor probleemi, seadis eesmärgi ning kirjeldas metoodika, mille abil oli võimalik probleemile lahendus leida.

Koostöös ettevõttega, selgitas autor välja rakenduse loomiseks vajalikud nõuded ja funktsionaalsuse. Rakenduses vajamineva funktsionaalsuse põhjal otsis autor probleemi lahendamiseks sobivad tehnoloogiad. Kokku leidis autor 11 teeki ja raamistikku, millest 4 olid sobilikud põhjalikuks analüüsiks. Autor kirjeldas tehnoloogiate sobivuse määramiseks kriteeriumid, mis rakenduse loomisel vajalikud on.

Tehnoloogiad, mis kriteeriumeid täitsid, oli 3 ning nende põhjal arendas autor prototüübid, mille eesmärk oli kontrollida tehnoloogia sobivust probleemi lahendamiseks ning märgata võimalike puudujääke tehnoloogiates. Prototüüpide arendamisel tulid kahel tehnoloogial välja puudujäägid, millest üks oli arendustööd takistav. Prototüüpimisega säästis autor väärtuslikku aega vältides takistuste ilmnemist rakenduse arendamise käigus. Kõige paremaid tulemusi pakkus teek Three.js, mille põhjal lõi autor ettevõttele Metroprint Systems OÜ probleemi lahendava rakenduse.

Autor hindab, et tulemus vastab töö alguses püstitatud nõuetele ja ettevõtte soovidele, kuid on vara öelda, kas rakendus e-poe klientidele huvi pakub. Rakendus on laienemisvõimeline ja Metroprint Systems OÜ jätkab autoriga koostööd.

Summary

With the thesis “Browser-Based Application for Designing Surfaces of Three-Dimensional Model” the author has developed a web application, which solved a problem for Metroprint Systems OÜ. The application offers a possibility for the company's customers to design and order customized pieces of furniture. Before the author had started working with the thesis, there weren’t any suitable solutions available online. Furthermore, at first, neither the company nor the author knew how to resolve the situation. To clarify the situation, the author addressed a problem, set a goal and defined a methodology, which made it possible to find a solution to the problem.

In cooperation with Metroprint Systems OÜ, the author found out the requirements and functionality needed to develop the application. Based on those requirements, author searched for technologies needed for developing the application. The author found a total of 11 libraries and frameworks, 4 of which were eligible for comprehensive comparison. The author defined more comprehensive criteria to decide which technologies were suitable for developing the functionality stated before.

Three of the technologies which met the criteria, were used to create prototypes. The purpose of the prototypes was to check and to be sure that those technologies were indeed able to fulfill the functionality needed in the application and to spot possible drawbacks before starting development of the application. Prototyping revealed shortcomings on two of the technologies, in which one was fatal and prevented the further study of the framework. The author saved valuable time with prototyping, avoiding upcoming problems on later stages of the development. Three.js library gave the best results in prototyping, being at least twice as fast as Babylon.js. The author used Three.js library to create the final application for Metroprint Systems OÜ.

The author evaluated that the final application will meet the original requirements and the company's needs. In the author's opinion, it is still early to say, does this application attract potential target group or not. Metroprint Systems OÜ continues to work together with the author to expand the functionality of the application.

Kasutatud kirjandus

A-Frame (27.05.2017). Kodulehekülg [https://aframe.io]

Babynlon.js (03.05.2017). Dokumentatsioon [https://doc.babylonjs.com]

Babylon.js (27.04.2017). Github [https://github.com/BabylonJS/Babylon.js]

Babylon.js (27.04.2017). Kodulehekülg [http://www.babylonjs.com/]

Adobe ajaveeb (09.11.2011). Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5 [https://blogs.adobe.com/conversations/2011/11/flash-focus.html]

Designboard kodulehekülg (29.03.2017). Re-Board kärgkartong [http://designboard.ee/re-boardist]

GBdirect (03.05.2017). Benefits of Using Open Source Software [http://open-source.gbdirect.co.uk/migration/benefit.html]

Goo Create (27.04.2017). Kodulehekülg [https://learn.goocreate.com/]

Goo Engine (27.04.2017). Dokumentatsioon [http://code.gooengine.com/latest/docs/]

Goo Engine (27.04.2017). GitHub [https://github.com/GooTechnologies/goojs]

Khronos Group (2011). WebGL 1.0 Quick Reference Card [https://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf]

Khronos Group (27.10.2014). WebGL Specification [https://www.khronos.org/registry/webgl/specs/1.0.3/]

KickJS (27.04.2017). GitHub repositoorium [https://github.com/mortennobel/KickJS]

LayaBox (27.04.2017). LayaAir dokumentatsioon [http://ldc.layabox.com/doc/?nav=ch-js-0-3-0]

Mozilla Developer Network (29.03.2017). WebGL [https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API]

PlayCanvas (27.04.2017). Dokumentatsioon [http://developer.playcanvas.com/en/api/]

PlayCanvas (27.04.2017). GitHub [https://github.com/playcanvas/engine]

PlayCanvas (27.04.2017). Kodulehekülg [https://playcanvas.com/]

PlayCanvas (04.08.2016). PlayCanvas versus Unity WebGL [https://blog.playcanvas.com/playcanvas-versus-unity-webgl/]

Primrose (27.04.2017). Kodulehekülg [https://www.primrosevr.com/]

Zeman, N. B. (2014). Essential Skills for 3D Modeling, Rendering, and Animation Florida: Taylor & Francis Group, LLC

Three.js (28.04.2017). Github [https://github.com/mrdoob/three.js]

Three.js (28.04.2017). Dokumentatsioon [https://threejs.org/docs/]

TWGL (27.04.2017). Kodulehekülg [https://twgljs.org/]

Unity3D (27.04.2017). Dokumentatsioon [https://docs.unity3d.com/Manual/webgl-gettingstarted.html]

VoxelJS (27.04.2017). Kodulehekülg [http://voxeljs.com]

World Wide Web Consortium (21.04.2015). File API Specification [http://www.w3.org/TR/2015/WD-FileAPI-20150421/]

World Wide Web Consortium (28.10.2014). HTML5 Specification [https://www.w3.org/TR/html5/scripting-1.html#the-canvas-element]

Lisa 1

Lisa 1 – Babylon.js prototüübi lähtekood Prototüüpi saab näha internetis aadressil http://z-bit.ee/diplomitoo/babylonjs/

Babylon.js prototüüp

Lisa 2

Lisa 2 – Three.js prototüübi lähtekood Prototüüpi saab näha internetis aadressil http://z-bit.ee/diplomitoo/threejs/

Three.js prototüüp