Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Vadász László

Átírás

1 Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT Vadász László 2011

2 Szegedi Tudományegyetem Informatikai Tanszékcsoport 3D-s játék motor fejlesztése PyGL-ben Szakdolgozat Készítette: Vadász László informatika szakos hallgató Témavezető: Nagy Antal egyetemi adjunktus Szeged 2011

3 Feladatkiírás A feladatom egy olyan többplatformos (Linux, Windows) 3D-s motor fejlesztése Python [1] nyelven, mely az OpenGL [2] grafikus függvénykönyvtárat és a Qt [3] felhasználói interfészt használ. A motor egy egyszerű felületet biztosít többek között modellek betöltéséhez, textúrázáshoz, grafikusobjektumok manipulálásához, szövegek megjelenítéséhez és részecskerendszerekhez létrehozásához. A projekthez szorosan hozzá tartozik egy demó program is, amely bemutatja a motor képességeit. i

4 Tartalmi-összefoglaló A téma megnevezése: OpenGL alapú 3D-s játék fejlesztői felület Python nyelven. A megadott feladat megfogalmazása: A cél egy általánosan és könnyen használható, platformfüggetlen grafikus könyvár létrehozása volt, mely a megjelenítésen felül számos egyéb szolgáltatást is biztosít egy komplex alkalmazás összeállításához. A megoldási mód: A motor a Python, OpenGL Qt és numpy programkönyvtárakra épül. A rendszer ezek segítségével valósítja meg a szükséges adatok beolvasását, a matematikai műveletek elvégzését és 3D-s leképezést. Mindezt úgy, hogy a programozó számára egy egységes felületet biztosít. Alkalmazott eszközök, módszerek: Elsődlegesen nyílforrású eszközöket alkalmaztam a program megírása során: Python, OpenGL, Qt, numpy, Linux, NetBeans, Subversion, Epydoc, Gimp, Dia, OppenOffice, egyetlen kivétel a 3D Studio Max. A rendszer teljes mértékben objektumorientált, mely a rendszer tervezését is alapvetően meghatározta. Elért eredmények: A rendszer támogatja a legfontosabb 3D funkciókat, mint például a modellek betöltését, azok textúrázását és transzformálását, valamint magába foglalja az objektumok hierarchiájának kezelését, alapvető bevilágítást és szövegkezelést. Ezenfelül támogatja az eseményvezérlést és a beviteli eszközök kezelését. Kulcsszavak: API, Platformfüggetlenség, Python, OpenGL, Qt, Eseményvezérlés ii

5 Tartalomjegyzék Feladatkiírás...i Tartalmi-összefoglaló...ii Tartalomjegyzék...iii Bevezetés...2 I. Felhasznált eszközök Programozási nyelv és programkönyvtárak Python OpenGL (PyOpenGL) Qt (PyQt) numpy Fejlesztőkörnyezet Ubuntu, Linux NetBeans IDE Egyéb eszközök Subversion Epydoc ds Max Gimp Dia OpenOffice Writer...10 II. Az Ilo felépítése Adatszerkezetek és adattípusok A Python beépített típusai OpenGL típusok numpy típusok Vektorok (Vector modul) Kvaterniók (Quanternion modul) Mátrixok (Matrix modul) Modellekkel kapcsolatos struktúrák (d3d modul) Grafikus mag Singleton osztályok Gfx osztály GfxContext és GLContext osztályok GfxMatrix osztály Viewport osztály Fájlkezelés Konfigurációs fájl Osztálymetódusok a Python-ban Anyagjellemző kollekciók Színtér leíró fájl...28 iii

6 3.5. ModelFile osztály Modell leíró fájl ASE fájl Eseményvezérlés és felhasználói interakciók Qt eseménykezelő EventDispatcher osztály Eseményobjektumok Belső események Felhasználói interakciók Egyedi esemény osztályok Anyagjellemzők Material osztály Texture osztály Shader osztály Anyagjellemzők kezelése Grafikus elemek Mesh osztály Geometriák kezelése Leképezőobjektum RenderObject osztály RenderObjectContainer osztály RenderScene osztály Fények kezelése LightLibrary osztály LightObject osztály Szöveg megjelenítése Szövegleképezés Text osztály TextLine osztály Részecskerendszerek BaseParticleSystem osztály Az Ilo motor Az API telepítése Hardveres feltételek Ubuntu Linux rendszerre Windows 7 rendszerre...60 III. Bemutatóprogram A bemutatóprogram felépítése Fájlszerkezet A bemutatóprogram logikája Sajátosságok Képek a bemutató programból...66 IV. Irodalomjegyzék...67 V. Köszönetnyilvánítás...68 VI. Nyilatkozat...69 iv

7 Bevezetés A feladatom két részből tevődött össze. Az első részben az Ilo nevű 3D-s játékmotort készítettem el, mely a Python nyelven és az OpenGL grafikus rendszerre épül. A függvénykönyvtár bemutatására egy demó programot is létrehoztam, valamint részletesen dokumentációval is elláttam az egész kódbázist. A projektem az afrikai eredetű Ilo (fény, örömteli) nevet adtam. A célom az volt, hogy egy könnyen használható felület biztosítsak 3D-s alkalmazások fejlesztéséhez. Ezt a felületet 3D engine -nek is szokás nevezni. Az engine (motor) lényegében egy API, azaz Application Programming Interface. Egy olyan programkód gyűjtemény, mely nem egy önálló programként amit futtathatunk. Sokkal inkább egy eszköz más programok megírásához. Az API fő célja egy vagy több programozói felület egybefoglalása oly módon, hogy az leegyszerűsítse és megkönnyítse a fejlesztő dolgát úgy, hogy a legalapvetőbb funkciókra kész eszközöket ad a programozók kezébe. Az Ilo több programozói felületet integrál önmagába, többek között ezért nevezhetjük egy alkalmazás motorjának. Képes ellátni minden alapvető feladatot, amely egy 3D-s környezet felépítéséhez és manipulálásához szükséges. Ilyen funkciók például az ablakok kezelése, a leképező rendszer inicializálása és vezérlése, a grafikus objektumok tárolása, manipulálása és megjelenítése. Tovább számos egyéb kényelmi szolgáltatást is biztosít, amelyek szükség esetén igénybe vehetők. Ide lehet sorolni a 3D-s fájlformátumok kezelését vagy az eseményvezérlő modult. Az API teljes mértékben objektumorientált paradigmák szerint lett megtervezve és implementálva. A leírás során több ponton is kitérek a felhasznált technikákra és az alkalmazott programtervezési mintákra. A motor több más rendszerben már sikeresen használt ötletet is megvalósít. Az egyik ilyen ötlet az Adobe ActionScript 3.0 [4]-ban alkalmazott objektum hierarchia és eseményvezérlő rendszer, mely egyszerűsége ellenére igen hatékony megoldást nyújt. A másik meghatározó példát a Drome Engine [5] nevű 3D-s motor szolgáltatta, melyet Josh Beam írt C++ nyelven. Nagymértékben hozzájárult az Ilo grafi- 2

8 Bevezetés kus magjának végső formájához, illetve a Quanternion és a Camera) osztályok megvalósításához. A dolgozat első részében a projekt fejlesztése során felhasznált eszközöket vesszük sorra és megvizsgáljuk a feladat szempontjából fontos tulajdonságaikat. Ezt követően az API felépítését és egyes részegységeit tekintjük át, modulról modulra. Eközben megismerkedünk a beépített függvénykönyvtárakkal és felhasznált programozási technikákkal. Végül szemügyre vesszük az Ilo motor felhasználásával készült be mutatóprogramot. A könnyebb érthetőség érdekében (ahol csak lehetett) a leírás mellett szerepleni fog a probléma megoldásának pszeudokódja is, amely a Python nyelvtanára épül. Például: class A(object): def func(a,b,c): if True: for i in [1,2,3]: glxxx() pass # Ez egy megjegyzés # object osztály származtatása # Függvény / metódus definíció # Feltételes elágazás # Lista bejárása For ciklussal # XXX OpenGL függvény hívás # Üres utasítás 3

9 I. Felhasznált eszközök A fejlesztés során arra törekedtem, hogy lehetőleg csak nyílt forrású és szabadon felhasználható eszközöket alkalmazzak. Meglátásom szerint nem csak a kereskedelmi szofverekkel nyújthatnak megfelelő minőséget, sőt! Sokszor inkább a nyílt rendszerek bizonyulnak használhatóbbnak és megbízhatóbbnak. Továbbá rengeteg leírás érhető el az interneten keresztül ezekhez a szofverekhez. Nem csak az alkalmazás dokumentációját, de általában egy-egy probléma megoldását is megtalálhatjuk a program weboldalán (pl.: NetBeans) vagy a hozzá kapcsolódó közösségi fórumon. A fejlesztés közben csak egy olyan programot alkalmaztam, amely nem érhető el ingyenesen. Nagyon fontosnak tartom, hogy egy adott problémához a legmegfelelőbb eszközt használjuk, amelyet lehetőleg még a projekt előkészületei során válasszunk ki. A fejlesztés alatt számos alkalmazást és segédprogramot használtam fel, melyeket a következő alfejezetekben részletesen is bemutatok. Nem a programok jó és rossz tulajdonságait szeretném kihangsúlyozni, hanem inkább azt, hogy miért pont ezekre esett a választásom és miért voltak számomra ezek a legmegfelelőbbek a projekt elkészítéséhez. 1. Programozási nyelv és programkönyvtárak A nyelv és a programkönyvtárak kiválasztása a legfontosabb lépés, hiszen ezek nagymértékben befolyásolhatják a rendszer képességeit, arról nem is beszélve, hogy egy rossz választás kihat az egész fejlesztési folyamatra. Minden nyelvnek vannak gyenge és erős pontja. Az a legoptimálisabb ha a kiválasztott környezet, nem csak megfelelő nyelvi támogatást nyújt a céljaink eléréséhez, de rendelkezik bőséges és jó programkönyvtárakkal. A következő fejezetekben megismerkedhetünk az Ilo fejlesztése során alkalmazott nyelvvel és az ahhoz kapcsolódó programkönyvtárakkal, ezeken belül is a rendszer számára nélkülözhetetlen elemekkel. 4

10 Felhasznált eszközök 1.1. Python A Pythont egy bizonyos Guido van Rossum nevű holland programozó alkotta meg 1991-ben. A nyelv kifejlesztésekor az egyszerű szintaxis, a jól olvasható forráskód és a fejlesztés megkönnyítése volt az elsődleges cél. A Python egy interpretált nyelv, tehát a forráskód nem esik át tényleges fordításon. Az értelmező (Python interpreter) a futtatás során előbb feldolgozza az aktuális forrásfájlt (a forrás bytekódra fordítja), majd utasításról utasításra végrehajtja a programot. A Python három programozási paradigmát is támogat, melyeket akár egyszerre is alkalmazhatunk programunkban. Tetszőlegesen használhatjuk a funkcionális vagy az objektum-orientált paradigmákat. Az értelmező dinamikusan kezeli a változókat és azok típusait, melyeknek létrehozását és felszabadítását is teljesen automatikusan végzi. Azért döntöttem a Python mellett, mert kényelmesen és gyorsan lehet benne programozni. Az interaktív értelmezőnek köszönhetően könnyedén kipróbálhatóak és tesztelhetők az egyszerűbb komponensek, még mielőtt beépítésre kerülnének. Továbbá a Python támogatja az össze fontosabb platformot, így a portolásra (a motor egy másik rendszerre történő átírására) jóval kevesebb időt kellett fordítani. A fejlesztés során a Python [1] es verzióját használtam. A motor szempontjából viszont a sebesség is nagyon fontos kritérium. Ehhez a nyelv egy másik előnyös tulajdonságát használtam fel: a Python képes más nyelven írt függvénykönyvtárak importálására, oly módon, hogy az adott könyvtárat egy belső Python modulba csomagolják (wrappelik) és ezen keresztül érhetjük el annak függvényeit és objektumait. Ezzel a módszerrel készítették el az általam is használt PyOpenGL és PyQt modulokat is, melyek eredetileg C és C++ nyelven íródtak, de a becsomagoláson keresztül már Python-ból is használhatók az ezekben található modulok. Így a programkód jó része natív módon hajtódik végre, ezáltal jelentős sebesség növekedést érhetünk el OpenGL (PyOpenGL) Az OpenGL [2] (Open Graphics Library) a Silicon Graphics nevű amerikai cég által 1992-ben kifejlesztett grafikuskönyvtár, mely 2 és 3 dimenziós objektumok számítógépes 5

11 Felhasznált eszközök leképezéséhez nyújt egy igen bőséges függvénykönyvtárat. Nyíltsága, egyszerűsége, gyorsasága és kliens-szerver felépítése miatt igen hamar elterjedt és mára már minden grafikus lapkakészlet és operációs rendszer támogatja. Két fő oka is volt, hogy az OpenGL mellett döntöttem. Az egyik, hogy tanulmányaim során többször is szükség volt a használatára és igen megkedveltem a használatát. A másik pedig a platformfüggetlenség. Az OpenGL a PyOpenGL modulon keresztül kapcsolódik a Pythonhoz. A PyOpenGL a C alapú OpenGL könyvtár egy Python-os becsomagolása, mely segítségével elérhetővé válnak a grafikusfüggvények. Ráadásul ezeket is a Python-ban már megszokott egyszerűséggel használhatjuk (például: változó típusok kezelése). A PyOpenGL az alap OpenGL függvényeken felül tartalmazza a GLU és GLUT kiegészítőkönyvtárakat is. A fejlesztés során a PyOpenGL [6] es verzióját használtam Qt (PyQt) A Qt [3] egy igen elterjedt és nagyon jól használható grafikus felhasználói felületrendszer (GUI Framework), melyet C++-ban implementáltak és támogatja az összes fontosabb platformot. Sok kereskedelmi (pl.: Google Earth) és nyílt forrású (pl.: KDE) projekt alapját ez a framework képezi. Elsősorban a hordozhatósága és a letisztultsága miatt döntöttem a Qt mellett, melyet PyQt néven találhatunk meg a Python modulok között. Robusztusságának köszönhetően ugyanúgy alkalmazható az Ilo-hoz, hasonló kisebb projektekhez, mint komoly, nagy rendszerekhez. Egy másik nagy előnye, hogy nagy mértékben támogatja az OpenGL alapú leképezést, ami megkönnyítette az Ilo-ba integrálását. A fejlesztés során a PyQt [7] 4.6-os verzióját használtam numpy A numpy egy nagy tudású numerikus könyvtár, mely főbb erőssége a több dimenziós tömbökkel való műveletvégzés és a lineáris algebrában alkalmazott számítások elvégzése. A PyOpenGL is ezt a modult használja a vektor- és mátrixműveletek kiszámítására, így kézenfekvő volt, hogy ezt a könyvtárat használjam a rendszer fejlesztése során. 6

12 Felhasznált eszközök Ezzel nem csak a belső vektor- és mátrixosztályok létrehozása vált könnyebbé, de az OpenGL modullal is jobban együtt tud működni az API-val. A numpy-t ezen kívül más egyéb területken is alkalmazzák. A grafikai számításokhoz szükséges eljárásokon kívül számos más művelet elvégzésére is alkalmas. Jelölés rendszere és az objektumok elnevezései, sőt bizonyos mértékig (a Python határain belül) a szintaktikája is a MatLab nevű programozási nyelvre hasonlít. A fejlesztés során a numpy [8] s verzióját használtam. 2. Fejlesztőkörnyezet A nyelv és a hozzákapcsolódó könyvtárak (library) kiválasztása után a következő fontos lépés a fejlesztőkörnyezet kialakítása. Több okból sem szabad elhamarkodottan dönteni. Egyrészt fontos, hogy a választott eszközök illeszkedjenek és támogassák a használni kívánt programozási nyelvet, másrészről pedig kézreállónak és jól használhatónak kell lenniük. A két legfontosabb eszközünk az integrált fejlesztői környezet és maga az Operációs rendszer Ubuntu, Linux Operációs rendszernek a nyílt forrású Ubuntu-t választottam. Egy gyors, letisztult és megbízható rendszernek ismertem meg az évek során. A fejlesztés során az Ubuntu egy kiváló fejlesztői platformnak bizonyult. Számos olyan programot biztosít, melyek megkönnyítik a munkát. Az Ubuntu-t körülvevő hatalmas közösségnek, a jó támogatottságnak és a bőséges leírásoknak köszönhetően a felmerülő problémákra szinte azonnal megtaláltam a megoldást. A Linux alapvetően nem számít játék platformnak. Azonban ma már adottak az OpenGL-t támogató és megfelelő minőségű meghajtóprogramok, így nem okoz problémát a 3D-s leképezés ezen a platformon sem. Így a megfelelő függőségek telepítését követően minden tökéletesen működik, sőt a sebesség is elfogadható. Az Ubuntuval szállított meghajtó programok megfelelő teljesítményt nyújtanak az Ilo futtatásához, amennyiben a hardveres követelményeknek teljesülnek. A fejlesztés során az Ubuntu 9.10-es (Karmic Koala) [9] verzióját használtam. 7

13 Felhasznált eszközök 2.2. NetBeans IDE A NetBeans a Sun (Oracle) által fejlesztett ingyenesen letölthető IDE (Integrated Development Environment Integrált Fejlesztői Környezet), melyet alapvetően Java és a a Java-hoz kötődő rendszerek fejlesztésére hoztak létre. Ennek ellenére egy ideje a Python-hoz is komoly eszközkészletet biztosítanak, ilyen eszköz például a forráskód elemeinek kiemelés, a kódkiegészítés, a szintaxis ellenőrzés, a beépített konzol és a debug funkciók. A letisztult kezelőfelület sok szempontból megkönynyítette a munkát, akár csak a beépülő plugin-ek melyek tovább növelték a rendszer hatékonyságát. A fejlesztés során végig megbízhatóan és stabilan működött. Negatívumként talán csak a nagy memóriaigényt, a lassú indulást és a még mindig fejlesztés alatt álló Python nyelvi bővítmény hiányosságai említhetők meg. De ezek csak kis mértékben voltak zavaróak. A fejlesztés során a NetBeans IDE [10] 6.8-as verzióját használtam. 3. Egyéb eszközök Ebben az alfejezetben azokat a programokat vesszük sorra, melyek csak közvetve kapcsolódnak a projekt létrehozásához. Ezek nélkül is elkészülhetett volna az Ilo. Azonban a forráskód tárolásához, demó program elkészítéséhez valamint a dolgozat megírásához még is nélkülözhetetlen eszközök voltak Subversion A forrásfájlok megfelelő tárolására az Apache által kifejlesztett nyílforrású verziókövető-rendszert, a subversion-t (SVN) használtam. Az SVN bővítmény formájában a Net- Beans-en keresztül is használható. Segítségével biztonságosan és hatékonyan tárolhattam a forrásfájlokat. Szükségesetén bármely korábbi verzióhoz (revision) visszatérhettem vagy összehasonlíthattam az aktuális állapottal. Továbbá a változások is jobban nyomon követhetővé váltak. A projektet a Google Code tárolójában (repository) helyeztem el, GNU GPLv2-es licenc alatt. Az SVN-be csak a karakteres forrásfájlok kerültek feltöltésre, a bináris jellegű állományok (pl.: bájtkód, stb.) nem. Ez alól egy-két textúra kivételt képez (pl.: fontmap), mert ezek nem változtak feltöltésről feltöltésre és szükségesek az API működéséhez. Minden feltöltés részletesen dokumentálva van, a könnyebb visszakövethető- 8

14 Felhasznált eszközök ség érdekében. A fejlesztés során a Subversion NetBenas bővítmény s verzióját használtam, mely az Apache Subversion [11] 1.6-os változatára épül 3.2. Epydoc Az Epydoc egy a Python-hoz kifejlesztett dokumentációkészítő-rendszer. A forráskód elemzésével és az egyes elemekhez (osztályok, metódusok, stb.) elhelyezett speciális, úgynevezett docstring -ek segítségével állítja össze a program dokumentációját (mint pl.: JavaDoc). A Python öndokumentáló, azaz minden modulhoz, osztályhoz és metódushoz megadhatunk egy szöveges leírást (docstring), ami bekerül a végleges rendszerbe és bármikor (futásközben is) lekérdezhető a help() függvény segítségével. Ezt a rövid leírást használja fel az Epydoc. A docstring-et elláthatjuk speciális jelölésekkel is, melyet az Epydoc értelmezője feldolgoz és ennek megfelelő generálja le a dokumentációt. Így nem csak esztétikailag (felsorolások, idézetek, linkek, stb.) lehet szebbé tenni, de sok plusz információt is elhelyezhetünk (pl.: típus információk, visszatérési értékek) a dokumentációban. Az Epydoc, alapvetően HTML dokumentumot generál, de képes PDF kimenet is létrehozni. A fejlesztés során az Epydoc [12] 3.0-s verzióját használtam ds Max A 3ds Max (korábbi nevén 3D Studio Max) egy modellező és animáció készítő szofver, melyet elsősorban játékprogramok objektumainak és mozgásanimációinak elkészítéséhez használnak. A felhasznált eszközök közül ez az egyetlen, amely nem érhető el ingyenesen (leszámítva a 30 napos próbaváltozatot). Azért a 3ds Max-et választottam, mert egyrészt hobbi szinten már korábban is használtam modellezésre és így hatékonyan tudtam vele dolgozni, másrészről csak ezzel lehet megfelelő ASE (Ascii Scene Exporter) formátumba elmenteni a már elkészült modelleket. Felmerült a Blender nevű nyílt modellező program használat is, de ez utóbbi feltétel miatt nem tudtam alkalmazni. A modellezésen felül az objektumok textúrázását is a 3ds Max-el segítségével csináltam meg. A modellek elkészítéséhez az Autodesk 3ds Max 2010 [13]-es programot használtam 9

15 Felhasznált eszközök 3.4. Gimp A demó programban található objektumok textúráit a nyílt forrású képszerkesztővel a Gimp-pel (GNU Image Manipulation Program) készítettem el. A szükséges képeket egy ingyenes textúra gyűjteményből (CG Texture [14]) töltöttem le, majd a Gimp segítségével méretre vágtam és összeillesztettem egy képpé azokat a darabokat, amelyek ugyan ahhoz a modellhez tartoztak. A textúrák elkészítéséhez a Gimp [ 15] es változatát használtam Dia A Dia egy szerkezeti diagram rajzoló alkalmazás, mellyel többek között kapcsolási rajzokat, folyamat ábrákat, és UML (Unified Modeling Language) ábrákat lehet készíteni. Az API átláthatósága kedvéért állítottam össze egy vázlatos osztálydiagramot. Az elkészült ábra nagy vonalakban tartalmazza a motor összes modulját, osztályát, valamint a köztük lévő kapcsolatokat. A diagramok elkészítéséhez a Dia [16] 0.97-es változatát használtam OpenOffice Writer Az OpenOffice [17] egy teljesen ingyenes irodai programcsomag, mely többek között a Writer szövegszerkesztőt is magába foglalja. A Writer egy általános célú szövegszerkesztő program, mely a rövid és hosszú kiadványok szerkesztésére egyaránt alkalmas. A sablonkezelő rendszerének köszönhetően egyszerűen és gyorsan össze állíthattam a dolgozat fő vázát, melynek így minden elem a megfelelő paraméterek beállításával egyszerűen módosítható. A Writernek széles eszközkészletet biztosít az egyszerű kiadvány készítéshez, mint például a stílusok alkalmazása, a tartalomjegyzék összeállítása vagy az irodalomjegyzék kezelése és létrehozás. Továbbá az elkészített dokumentumot minden fontosabb formátumban képes elmenteni, többek között Word doc-ban is. Sőt akár egyetlen kattintással PDF-be (Portable Document Format) is exportálhatom a kész szöveget, ezzel biztosítva annak hordozhatóságát. A dolgozat megírásához az OpenOffice Writer 3.2-es verzióját használtam. 10

16 II. Az Ilo felépítése Az Ilo számos modulból (Java terminológia szerint csomag vagy packege) épül fel, melyek mindegyik több osztályt tartalmaz. Python-ban (többek között a Java-tól eltérően) minden forrás fájl egy modulnak számít. Az Ilo-ban található modulok három fő csoportra bonthatók: Az első csoportba tartoznak az adatstruktúrákat megvalósító osztályok, amelyek nem függnek a rendszer többi moduljától. Viszont szinte minden adat ezekben a szerkezetekben van eltárolva. Éppen ezrét a többi modul aktívan használja ezeket. A másodikba a rendszerszintű modulok vannak, amelyek a felhasznált programkönyvtárakra (elsősorban az OpenGL) építkeznek. Ezek a modulok olyan osztályokat és metódusokat tartalmaznak, amelyek egyrészt leegyszerűsítik egyes funkciók használatát, másrészt olyan komplex feladatokat is megvalósítanak, mint például az OpenGL inicializálása vagy egy fényforrás beállítása. A harmadik csoportba azok a modulok foglalnak helyet, melyek már csak az előző kettő csoport funkcióin keresztül kommunikálnak és hívnak meg szolgáltatásokat a többi API-ból. Az ilyen modulból van a legtöbb az API-ban. Ezek valósítják meg többek között a modellek feldolgozás, tárolását és az ezekhez tartozó szolgáltatásokat, mint például az eseménykezelést és az objektumhierarchia felépítését. Ebben a fejezetben egyesével megvizsgálunk minden modult. Az áttekintést mindig a modult felépítő osztályoktól kezdjük és innen haladunk felfelé a modulok szintjéig. A fejezet végén pedig elérjük az API legfelső szintjét, ahol minden modul egy rendszerként működik. A motor használatáról a 3. fejezetben olvashatunk. A modulcsoportok sorrendjét is követve, először a felhasznált adatszerkezeteket vesszük számba. Ezt követően a grafikusmagot tekintjük át, mely az OpenGL könyvtárra épül és a második modulcsoport legjelentősebb tagja. A következő a fájlműveletekkel foglalkozó modul, ahol betekinthetünk a modellek és egyéb adatok beolvasásának metodiká- 11

17 jába. Majd az ablakkezelőt kiterjesztő osztályokat ismerjük meg. A harmadik csoportot az eseménykezelő alrendszerrel megismerésével kezdjük el. Szorosan ide kapcsolódik a felhasználó által, a különböző beviteli eszközök segítségével kiváltott interakciók. Az események után áttérünk a egyik legfontosabb részegységre: a grafikus objektumok hierarchiájára, amely felhasználja az összes eddig megvizsgált modult. Az utolsó részben a fények kezelésével és a szöveges információk megjelenítésével fogunk foglalkozni. Végül egy kis ráadásképpen megnézzük a beépített részecskerendszert. 1. Adatszerkezetek és adattípusok A grafikus rendszerek egyik sarkalatos pontja a megfelelően megtervezett és implementált adatstruktúrák. A 3D-s megjelenítéshez nagy mennyiségű adatra van szükség, melyeket a tárolás mellett gyorsan és hatékonyan kell elérni és feldolgozni. Ebben az alfejezetben csak a legfontosabb adatszerkezetekre fogok kitérni. Az ennél összetettebb típusok az ezt követő fejezetekben fogjuk tárgyalni. Mindenek előtt a beépített típusokat veszszük röviden sorra, majd pedig az Ilo-hoz készített osztályokat tekintjük át A Python beépített típusai A Python egy erősen típusos nyelv, melyről könnyen megfeledkezhetünk a dinamikus változókezelésnek és a lusta kifejezés kiértékelésnek köszönhetően. A lusta kiértékelés azt jelenti, hogy például egy függvénynek a paramétereiben átadott kifejezéseket (a mohóval ellentétben) csak akkor értékeli ki a Python, ha azokra valóban szükség van. A dinamikus változókezelésnek köszönhetően nincs szükség a változók deklarálására vagy a típusuk meghatározására. Az interpreter folyamatosan számon tartja az egyes változók aktuális értékeit és típusait. Így a nem megfelelő hivatkozásokat kivétel dobással jutalmazza a nyelv. A Python számos beépített típussal rendelkezik. Ezeket csak egyszerű felsorolás formájában tekintjük át az alábbi listában. Alapadattípusok: Egész számok int, long 12

18 Logikai értékek bool Lebegőpontos számok float Karakterláncok string Gyűjtemények: Listák list, tuple, array,... Szótárak dict Halmazok set, frozenset 1.2. OpenGL típusok A PyOpenGL-nek köszönhetően az OpenGL teljes mértékben illeszkedik a Python környezethez. Például nem szükséges a függvények hívásakor az OpenGL-ben megszokott paraméter konvenciókat használni (pl.: glvertex3f helyett glvertex), a PyOpenGL automatikusan feloldja ezeket a megadott paramétereknek megfelelően. A PyOpenGL ahogy már az előző fejezetben is említettem a numpy-t használja belső adattárolásra (pl.: mátrixok) és bizonyos számítások elvégzésére. Ezen felül csak a Python által biztosított típusokat használja adattárolásra numpy típusok A numpy alapvetően egydimenziós (array), kétdimenziós (matrix) és n-dimenziós (ndarray) adatstruktúrák kezelésére alkalmas (a MatLab-hoz hasonlóan). Nagy előnye, hogy az összes fontosabb vektor és mátrix műveletet képes elvégezni (pl.: vektorok szorzását mátrixokkal). Ezen felül számos egyéb matematika számítást is megvalósítottak benne (pl.: Fourier transzformáció), azonban a motor csak a vektor és mátrix műveletek elvégzéséhez nyújtott funkciókat használja. A következő bekezdésben azt is megtudhatjuk, hogy milyen formában alkalmazza az API a numpy képességeit Vektorok (Vector modul) Az általános vektor osztály a numpy ndarray osztályából származik. Azért nem az egydimenziós tömböt (array) terjeszti ki, mert az nem támogat olyan műveleteket, me- 13

19 lyek igen fontosak a motor szempontjából. Ilyen művelet például egy mátrix szorzása egy oszlopvektorral. A kiterjesztés során a következő metódusokat adtam hozzá: length A vektor hossza azaz elemeinek négyzetösszegének a gyöke. sqrlength A vektor elemeinek négyzetösszege. normal A vektor normalizálása, azaz minden elemét elosztjuk a hosszal. zeros A vektor kinullázása Ebből az általános osztályból származik három másik vektor típus, melyek dimenziók szerint lettek specializálva. Így jött létre a 2, 3 és 4 dimenziós (elemű) vektor típus. Mindegyik osztály felüldefiniálja az általános vektor által biztosított metódusokat a saját dimenziójának megfelelően. Továbbá az adott számú dimenzió miatt, minden elem nevesítve is elérhető, lekérdező és beállító (getter és setter) metódusokon keresztül, melyeknek egyetlen feladata a vektorban szereplő adott sorszámú érték lekérdezése vagy beállítása. A Pythonban lehetőség van speciális úgynevezett property metódusok definiálására. Például: class Osztaly: def init(): a = 10 b = def b(): return def b(value): b = value # public # private # a b-t lekérdező getter metódus # a b-t beállító setter metódus peldany = Osztaly print peldany.a # 10 pritn peldany.b # 20 pritn peldany.b = 30 # paldany. b értéke 30 lesz Működését tekintve teljesen olyan, mint egy metódus hívás, mely lekérdezi vagy beállítja az osztály valamely értékét. Használat közben viszont olyan, mint ha az osztály egy publikus osztályváltozójával végeznénk műveleteket. A vektor osztályok a következő property-ket támogatják: Vector2 Vector3 Vector4 x, y x, y, z x, y, z, w 14

20 1.5. Kvaterniók (Quanternion modul) A matematikában a kvaterniók [18] egy szám négyes, mely a komplex számok egyfajta kibővítése. Az egyik legfontosabb felhasználási területe a 3D-s forgatómátrixok számítása. Legnagyobb előnye, hogy jelentősen kevesebb művelet elvégzése szükséges egy kívánt forgatási mátrix kiszámításához, mintha azt mátrixszorzásokkal adtuk volna meg. Alapvetően elég, ha az x, y, z tengelyek elforgatáshoz tartozó Quanternion-t számoljuk ki, majd ezeket definíció szerint összeszorozzuk. A forgatási mátrix ebből már egy lépésben előállítható. Ábrázolás szempontjából egy négydimenziós vektorról van szó melyet, a Python beépített array osztályának felhasználásával hoztam létre. Az osztály megtervezésében nagy sokat segített a Drome motorban [5] található hasonló osztály Mátrixok (Matrix modul) A vektorokhoz hasonlóan itt is a numpy ndarray objektumából indultam ki és hoztam létre egy általános Matrix osztályt. Ez az osztály nem tartalmaz semmilyen új metódust, lényegében csak egy hivatkozás (alias) az ősére. További három specializált Mátrix származik az ndarray osztályból, rendre 2 2-es 3 3-as és 4 4-es méretűek. Ezek mindegyik három osztálymetódussal rendelkezik: zeros identity rotation Csupa nullákat tartalmazó mátrix. Egységmátrix, azaz csupa nulla mátrix főátlójában egyesekkel. A paraméterben megadott elforgatási szög alapján számítható forgatási mátrix. A 3 3-as és 4 4-es mátrixok esetében tengelyenként eltérő metódussal történik a számítás. A numpy-nek köszönhetően ezek az osztályok már öröklik az összes fontosabb mátrix műveletet, többek között: az összeadást, skalárral való szorzást, mátrixszal való szorzást, mátrix transzponálást és felbontást oszlopvektorokra Modellekkel kapcsolatos struktúrák (d3d modul) Több egyszerű osztály tartozik ebbe a modulba, melyek csak a modellek adatainak 15

21 tárolására szolgálnak. Főként tulajdonság metódusaik vannak, melyekkel beállíthatók az egyes adattagok. Éppen ezért csak röviden elemezzük őket. Vertex: A csúcspont (vertex) a 3D-s modellek legkisebb építőeleme, mely lényegében egy pont a térben. A legfontosabb tulajdonsága a térbeli pozíciója, melyet három számmal (x, y, z) írhatunk le. Ennek a pontnak a homogén koordináta rendszerbeli helyét a következő szám négyes adja: (x, y, z, w). Az API minden pont homogén koordinátájának negyedik értékét konstans 1-nek veszi, ezért azt elhagyhatjuk. Ha a csúcspont egy felület részét képezi, akkor szükség lehet a csúcs normálvektorára is. A normálvektor egy egység hosszú vektor, amely mindig merőleges a csúcsot tartalmazó felületre és egy (x, y, z) hármassal írhatjuk le. A Vertex osztály tárolja a normálvektor koordinátáit is. VertexUV: Ez az objektum a csúcspontokhoz tartozó textúrakoordinátákat tárolja, mégpedig két darab szám formájában (u, v). Ez a két szám egy pontot határoz meg a 2D-s képen, melynek felbontásától függetlenül minden pontjának koordinátája 0-tól 1-ig tart. Ebben a rendszerben a kép bal felső sarka az origó, azaz a (0, 0) pont. A nem a [0-1] tartományba eső számok esetében a rendszer az éppen aktuális textúraleképezési paraméterek szerint jeleníti meg a képet a felületen. Ezekkel a paraméterekkel meghatározhatjuk azt is, hogy a rendszer hogyan viselkedjen ha az (u, v) értékek nem a [0-1] intervallumba esnek. Azért nem a Vertex osztályban van eltárolva az (u, v) számpár, mert általában poligononként vannak beállítva a textúrák és így egy csúcsponthoz, több textúrakoordináta is tartozhat. Edge: Két csúcspontot összekötő szakaszt nevezünk élnek (edge). Az él objektum két csúcsponthivatkozást tartalmaz. Mivel minden élhez minimum egy, de legfeljebb két poligon (face) kapcsolódik, ezért az osztály képes tárolni két Face objektumhivatkozást is a könnyebb feldolgozás érdekében. Face: A poligon (face) egy élek által határolt terület. Egy poligonnak tetszőleges számú 16

22 oldala lehet. Az API azonban csak a három csúcsponttal vagy ugyanennyi éllel megadható háromszög poligonokkal tud dolgozni. Ez a felületleképezés alapegysége is. Így a Face osztály a három csúcspontot, a hozzájuk tartozó textúrakoordinátákat, és a poligon normálvektorát tároljuk. A poligon normálvektora a csúcspontok koordinátáiból számítható, n = (B A) (C A) ahol ṉ a normálvektor, és az A, B, C a lap csúcsai. BoundingBox: Ez az osztály a modell legkisebb és legnagyobb koordinátájú pontját számítja ki és tárolja le. Az így kapott két csúcs, a modell köré rajzolható legkisebb téglalapot határozza meg. Többek között az ütközés vizsgálatkor lehet hasznos. BoundingShpere: Az előzőhöz hasonló objektum, mely a modell köré írható gömböt adja meg, oly módon, hogy átlagoljuk a csúcspontok koordinátáit így megkapva a gömb középpontját, majd megkeressük a középpontól legtávolabbi csúcsot és ez a távolság adja meg a sugarat. Szintén ütközés vizsgálat során lehet hasznos. 2. Grafikus mag A Gfx nevű modul kapcsolja össze a PyOpenGL-t a motor többi részével, ezáltal minden leképezéssel és grafikus megjelenítéssel kapcsolatos eljárás egy helyen van. Szintén az egységes kezelés érdekében a modul csak és kizárólag egyke (singleton), azaz egyszer példányosítható osztályokat tartalmaz (bővebben a következő alfejezetben). Ebből egyenesen következik, hogy egyszerre csak egy leképező környezetet tud kezelni az API. Öt osztály található a modulban. Az első a Gfx amely csak a leképezéshez kapcsolódó és az objektumok létrehozásához szükséges konstansokat tartalmazza. A következő a GfxContext melynek közvetlen leszármazottja a GLContext-t. Ez a két osztály tartalmazza az API-ban használt OpengGL függvények "alias"-ait. Az alias-ok olyan methódusok, amelyek nem értelmezik újra az eredeti függvényt, csak egy másik néven hivatkoznak azokra. Mindezt azért, hogy mindenhol elég legyen csak a Gfx osztályt 17

23 importálni. Továbbá itt találhatók a különböző leképezési meneteket (render pass) előkészítő és lezáró metódusok. A negyedik osztály a GLContext egyik belső osztálya (inner vagy nested class), a GfxMatrix. Az egyetlen feladata az OpenGL-es mátrixutasítások magasabb szintű kezelése. Végül az ötödik osztály a Viewport, ami az aktuális látómező paramétereit tárolja, és ezen keresztül állíthatjuk be azokat. Az alábbiakban részletesebben is megvizsgáljuk a modul egyes elemeit. Mindezek előtt teszünk egy rövid kitérőt az egykeosztályok felé Singleton osztályok A singleton osztály (más néven egykeosztály) [19] egy programtervezési minta (pa t - tern), ami olyan osztályok létrehozására ad egy elvi felépítést melyek csak egyszer példányosíthatók a program futása során. Ennek megvalósítása nagymértékben nyelvfüggő és többféleképpen is implementálható egy adott nyelven. Az Ilo-ban használt implementáció: class Singleton: instance = None def Singleton (): if instance!= None: instance = new Singleton else: raise SingletonClassError # A létező példány tárolója # new metódust definiálása def getinstance (): # A létező példány lekérdezése return instance A Python két lépésben hozza létre az osztályokat: az első fázisban maga az objektum jön létre, ezt a new metódus (magic function olyan metódus amely az interpreter számára speciális jelentéssel bír) definiálásával érhetjük el. A második fázisban a létrehozott objektum értékeinek inicializálása történik az init metódus segítségével. Mint a legtöbb objektumorientált nyelvben, itt is minden osztály ősosztálya az object (Pythonban a beépített osztályok kisbetűvel kezdődnek). Ebből kifolyólag a new, és az init metódus megadása elhagyható, ekkor az object osztály ugyan ezen metódusai hajtódnak végre. A Singleton osztálynak van egy protected, (csak a leszármaztatott osztályok számára látható) instance nevű adattagja. Ez tárolja az osztály egyetlen létező példányát. A konstruktort előbb ellenőrzi az instance osztályváltozó értékét és ha az None, akkor lét- 18

24 rehozza az osztály egy példányt és hozzárendel az instance változóhoz, különben SingletonClassError típusú kivétel keletkezik. Ezek után a getinstance osztálymetódussal kérhetjük le a létező osztálypéldányt. Azért nem a getinstance inicializálja az instance változót mert így elkülöníthető az első létrehozás fázisa a tényleges használa t - tól. Ezzel a módszerrel elkerülhetők azok a helyzetek, amikor még az OpenGL környezet létrehozása előtt hívunk meg olyan metódusokat amelyek csak az inicializálást követően lennének elérhetőek. Így lehetőség van arra, hogy az osztály konstruktorát az inicializálás megfelelő fázisban hívjuk meg, ezáltal az API használatakor már csak a getinstance metódussal érhetjük el az adott osztály referenciáját, amely már biztosan létezik Gfx osztály Ez egy statikus osztály, ami azt jelenti, hogy kizárólag olyan metódusokat és adattagokat tartalmaz amelyeket csak példányosítás nélkül érhetők el. Az Ilo motorban minden statikus osztály példányosításakor StaticClassError kivétel keletkezik. A Gfx annyiban tér el más statikus osztályoktól, hogy csak és kizárólag konstans adattagjai vannak és nem tartalmaz műveleteket. Ezek a konstansok nagyrészt OpenGLban definiált értékekre hivatkoznak. Ilyen konstans például a GL_PROJECTION melyre a projekciós mátrix elérésekor van szükség. Ezek a hivatkozások általában az eredetitől csak minimálisan térnek el. Rövidebb azonosítókkal rendelkeznek. Továbbá a Gfx az API számára az OpenGL-től független, viszont a leképezés szempontjából fontos értékeket is tárol, mint éldául: a NUM_TEXTURE_UNITS mely a textúrázási rétegek számát határozza meg. A Gfx osztály (mivel globálisan elérhető) ezért csak olyan állandókat tartalmaz, melyekre szükség lehet a program más részeiben is. Ezzel a módszerrel elrejthetünk bizonyos konstansokat a motor egyes részei elől. Természetesen az PyOpenGL modul importálásával az összes konstans elérhetővé válik. Pontosan emiatt a Gfx osztály nem tartalmazza az összes OpenGL konstans alias-át. Később látni fogjuk, hogy például a GLWidget osztálynak pontosan erre a csökkentett konstanskészletre van szüksége. 19

25 2.3. GfxContext és GLContext osztályok Mivel a GLContext a GfxContext közvetlen leszármazottja ezért ezt a két osztályt együtt vesszük szemügyre. A GfxContext minden a motorban implementált leképezőkörnyezet (az Ilo-ban csak az OpenGL van megvalósítva) alaposztálya mely csak a környezettől független általánosan használható metódusokat definiál. Míg a GLContext osztályban az OpenGL környezettől függő utasításokat foglalnak helyet. A GLContext egyszerre több feladatot is ellát. Először is a példányosítás során előbb ellenőrzi az összes felhasznált OpenGL utasítás elérhetőségét, miközben létrehozza az adott függvényekre a saját hivatkozásokat (alias képzés). Ezek után elvégzi a leképezéshez szükséges alapbeállítások inicializálását, beállít minden fontosabb OpenGL értéket ami a program futása során nem (vagy csak speciális esetekbe) változik (pl.: glshademodel, glhint, glpolygonmode, stb.). Szintén ebben a szakaszban inicializálódik a viewport és a gfxmatrix kezelő alrendszer (lásd a következő bekezdésekben), továbbá itt töltődik be és generálódik le a szövegkiíratáshoz szükséges struktúra. A szövegkiíratáshoz szükséges betűk létrehozásához a gllist nevű OpenGL-es objektumot veszszük segítségül. Ez az objektum csak adott OpenGL utasításokat képes tárolni (többek között: glbegin, glend és minden ami azok között is lehet). A lista létrehozását követően, egyetlen parancs kiadásával tetszőleges mennyiségben végrehajthatjuk, ezzel memóriát, CPU és GPU időt spórolva. Példaként vegyük egy betűhöz kirajzolásához szükséges 2D-s sík lap létrehozását: glnewlist(font + i, GL_COMPILE) glbegin(gl_quads) gltexcoord2f(0, 0) glvertex2i(0, 0) gltexcoord2f(1, 0) glvertex2i(16, 0) gltexcoord2f(1, 1) glvertex2i(16, 16) gltexcoord2f(0, 1) glvertex2i(0, 16) glend() gltranslate(12,0,0) glendlist() # Új gllist létrehozása # Az első tárolt utasítás # Az utolsó tárolt utasítás # A gllist lezárása A betűk generálásakor minden egyes karakterhez létrehozunk egy ilyen listát. A szövegkiíratás működéséről és kezeléséről a 8. fejezetben olvashatunk bővebben. 20

26 2.4. GfxMatrix osztály Ennek az osztálynak egyetlen feladata az OpenGL-ben használható mátrixok (GL_PROJECTION_MATRIX, GL_MODELVIEW_MATRIX, GL_TEXTURE_MATRIX) közötti átváltás és, azok lekérdezéseinek és beállításainak leegyszerűsítése. Először is minden mátrixműveletnél megadható, hogy melyik mátrixon szeretnénk azt elvégezni. Ha nem adjuk meg ezt a paramétert akkor az OpenGL számára aktuálisan beállított mátrixon hajtódnak végre a műveletek. A következő mátrixműveleteket végezhetjük el az osztály segítségével: getmatrix A megadott mátrix aktuális értéke Matrix4x4-ben setmatrix A megadott mátrix beállítása multiplymatrix A megadott mátrix beszorzása egy másikkal loadidentity A megadott mátrix beállítása az egységmátrixra Az OpenGL oszlop-sor formában tárolja a mátrixokat ezért az egyes műveletek (pl.: mátrix lekérdezése) esetében szükség lehet a mátrix transzponálására (a mátrix sorainak és oszlopainak felcserélése). Ehhez használhatjuk a Matrix4x4 transpose metódusát. A mátrixok típusok közötti váltásokat az API folyamatosan elmenti és tárolja, így könnyen visszakövethetjük, hogy melyiket használtuk utoljára. Az utolsó állapotot egyetlen metódushívással visszaállíthatjuk (previewmatrix), továbbá az éppen használatban lévő mátrix típusa is lekérdezhető (currentmatrix). Fontos megjegyezni, hogy a GfxMatrix nem egy önálló osztály: valójában a GLContext egy belső osztálya (Java-ban nested vagy inner class). A Pythonban bárhol deklarálhatunk új osztály, akár egy másik osztályon belül is (sőt függvények törzsében is!). Az így létrehozott osztályra csak az őt tartalmazón keresztül hivatkozhatunk. Erre a megoldásra azért volt szükség, mert ezeknek a mátrixoknak a kezelése teljes mértékben a GLContext feladatkörébe tartozik, viszont ezen belül mégis egy külön egységet képez melyet a GfxMatrix valósít meg. Ezen felül a GfxMatrix is singleton, mivel ez az osztály is rendszer szintű műveletek lát el. Szükség esetén a GfxMatrix funkciói elérhetők a GLContext, matrix adattagján keresztül. 21

27 2.5. Viewport osztály Mielőtt elmélyednénk az osztály részletezésében, előbb vizsgáljuk meg az OpenGL vetítéssel kapcsolatos tulajdonságait. A 3D-s leképezés során a perspektivikus és az ortogonális vetítés közül választhatunk az OpenGL-ben. Az alábbi ábra mindkettőt szemlélteti: II. 1. ábra: Perspektivikus és párhuzamos vetítés vágósíkjainak szemléltetése Az 1. ábán balra a perspektivikus vetítést láthatjuk, melynek legszembetűnőbb sajátossága, hogy a párhuzamos egyenesek a nézőponttól távolodva, mintha fokozatosan özsszetartanának (pl.: vasútisinek). Ebből az is következik, hogy a megfigyelt objektumok élei látszólag nem olyan szöget zárnak be mint ami várható lenne (pl.: egy kocka derékszögei). Ezzel szemben a kép baloldalán látható párhuzamos (más néven ortogonális) vetítés, szögtartó (azaz nem torzítja a szögeket). Amiért mégis előnyben részesítjük a perspektivikus vetítést a 3D-s grafikában, az az, hogy az emberi látáshoz ez áll a legközelebb, és ez szükséges a megfelelő térérzékeléshez is. Az ábrán jól látható, hogy 6 sík lap határolja a látómezőt. Ezeket a lapokat vágósíkoknak is nevezzük, mivel az OpenGL az ezen kívül eső elemeket egyszerűen levágja. Így csak a síkokon belüli pontok vesznek részt a leképezés folyamatában, tehát a jól megadott vágósíkokkal megtakaríthatunk némi számítási kapacitást és jelentős mennyiségű memóriát. Érdemes még megfigyelni az ábrán a koordinátarendszer állását, ugyanis jól látható az OpenGL által használt jobbsodrású rendszer, továbbá azt is észrevehetjük, hogy a z tengely határozza meg a 3D-s tér mélységét, azaz a z tengely merőleges a monitor síkjára. 22

28 Az előzőekhez hasonlóan a Viewport is egy singelton osztály. Feladata a látómező beállításainak elvégzése. Tárolja az aktuális OpenGL látómező x és y pozícióját, továbbá a szélességét és a magasságát (az ábrán az a és b élek). Ezek az értékek a program ablakának lokális koordináta-rendszerében értendők, továbbá a látómező méretei nem szükségszerűen egyeznek meg a főablakéval. Az osztály tartalmazza a látómező képarányát (ration) is. A képarány (az ábrán szereplő a és b élek aránya) megadása szükséges a perspektivikus vetítés kiszámításához. A nem megfelelő arány esetén a kiszámított kép torzulhat és az objektumok vízszintesen vagy függőlegesen nyújtottak lehetnek. A látószög (FOV Field Of View) paraméter, (az ábrán lévő oldalsó vetítősíkok, C és D által bezárt szög az O origóból nézve) szintén fontos adat a vetítés megadásakor. Értéke fokban értendő. Ez határozza meg, hogy a kamera mekkora térrészt képes egyszerre belátni. Az emberi szemnek megfelelő optika látószöge kb. 50. A FOV értékét az API konfigurációs fájljában lehet megadni. Valamint az osztály tárolja a legközelebbi (nearplane) és a legtávolabbi (farplane) vágósíkokat is (az ábrán az A-val és B-vel jelölt síkok). Az osztály metódusai segítségével beállíthatjuk a látómező méretét, amit a motor automatikusan is meghív minden ablakátméretezés alkalmával. A metódus hívásakor nem csak a látómező méreteződik át, de a képarány, a közeli és a távoli vágósíkok is itt kapnak értéket. A vágósíkok nézőponttól való távolságát jelenleg az Ilo határozza meg, két konstans érték formájában. Ezek az információk szükségesek az új látómezőhöz tartozó perspektivikus vetítési mátrix kiszámításához. Ehhez a gluperspective függvényt hívjuk segítségül, mely kiszámítja az új vetítési mátrixot és be is állítja azt az OpenGL-ben. 3. Fájlkezelés Három különböző fájl formátum feldolgozására van szükség az Ilo-ban: Szöveges fájl: ASE modell fájl XML fájl: konfigurációs fájlok, anyagjellemző gyűjtemények, színtér leírók Bináris fájl: képek A szöveges fájlok feldolgozása a legegyszerűbb a megfelelő specifikáció birtokában. 23

29 A Python a fájl kezelést is megkönnyíti. Elég az open függvény segítségével megnyitni a dokumentumot. Az így kapott file objektum iterálható, ami azt jelenti, hogy egy for ciklus segítségével beolvashatjuk a fájl tartalmát, a ciklus változó minden iterációban a fájl következő sorát kapja értékül. A ciklus magjában string műveletekkel a fájl leírásának megfelelően feldolgozhatjuk az egyes sorokban tárolt információt. inputfile = open("path/file", "r") for line in inputfile: parseline(line) # Fájl megnyitása olvasásra ("r") # Fájl beolvasása soronként # A sorok értelmezése Az XML (extensible Markup Language) fájlok értelmezésére (parse) a Python-ban található minidom nevű modult használtam. A minidom csak a legalapvetőbb értelmezési funkciókat biztosítja, viszont az Ilo-ban felhasznált struktúrákhoz ezek is bőven elegendők. A modul az XML fájl betöltésekor azonnal értelmezi annak tartalmát és felépít belőle egy belső adatstruktúrát (DOM Document Object Model). A DOM lényegében egy objektumhierarchia melyben az egyes elemek tartalmazhatnak újabb elemeket, illetve mindegyiknek meg van a saját metódus- és adattagkészlete, mely segít a struktúra bejárásában, az adatok kiolvasásában és a tulajdonságok megváltoztatásában. A képek a bináris fájlok kategóriájába tartoznak. Feldolgozásukra a Python által biztosított Image osztályt használjuk, amely a PIL [20] (Python Image Library) része. A PIL képes beolvasni és kezelni az összes elterjedtebb képformátumot és a motor számára megfelelő formátumba konvertálni (erről bővebben az 5. Anyagjellemzők fejezetben olvashatunk). Az általános bináris fájlok értelmezéséhez már saját osztályt kell készíteni. Ehhez hasznos lehet a Struct nevű osztályt, ami egy szöveg változóban megadott formátummaszk alapján értelmezi az adatokat és ennek segítségével blokkosítva dolgozhatjuk fel az adott fájlt. Így az egyes blokkok kinyerését követően a feldolgozás menete megegyezik a sima szöveges dokumentuméval. A formátummaszkok (az egymást követő bájt blokkok jelentését leíró string) leírását a fájl formátumának a specifikációja határozza meg. A fájlok kezelésére nincs központosított rész az API-ban. Az anyagjellemző kollekciókat és a színtér fájlokat a Library osztály kezeli, míg a konfigurációs állományt a Config osztály dolgozza fel. A következő alfejezetekben ezekről lesz szó. 24

30 3.1. Konfigurációs fájl Az API legfontosabb beállításait alapértelmezetten a config.xml fájl tartalmazza. A fájl kategóriákra bontva tárolja az egyes beállításokat. Egy bejegyzésnek három attribútuma van: név, érték és típus. Az alábbi példa a library_init értéket logikainak definiálja és True-ra állítja: <iloconfig> <category name="base"> <item name="library_init" value="true" type="bool" /> </category> </iloconfig> A konfigurációs fájl betöltését és feldolgozását a config modul Config osztálya végzi. Az értékek négyféle típusúak lehetnek: logikai (bool), egész szám (int), lebegőpontos szám (float) és karakterlánc (string). A betöltés folyamán az értékek a típusuknak megfelelő konverzión esnek át. A Config osztály csak osztálymetódusokat tartalmaz. A Config osztály a következő metódusokat biztosítja az adatok kezelésére: loadconfigxml Konfigurációs fájl betöltése reset Konfigurációs értékek törlése, alapértékeket kivéve hasvalue Szerepel-e a megadott beállítás az adatbázisban getvalue A megadott beállítás lekérdezése A Config osztály már a konfigurációs fájl betöltése előtt is tartalmaz számos beállítást, melyek elengedhetetlenül fontosak a motor megfelelő működéséhez. A konfigurációban szereplő értékeket egy dict nevű beépített struktúrában (dict azaz dictionary, leginkább egy asszociatív tömbre hasonlít) tároljuk, mégpedig a következő formában: dict["categoryname.itemname"] = value A konfigurációs állományba tetszőleges mennyiségű és típusú értéket felvehetünk, ezáltal nem csak az API beállításait, de a ráépülő program paramétereit is tartalmazhatja. Sőt akár több konfigurációs fájlt is betölthetünk egyszerre. Azt azonban figyelembe kell venni, hogy a megegyező paraméter nevek (kategória és név együtt) esetén a később betöltött értékek felülírja a korábban beolvasottakat. 25

31 A getvalue metódus segítségével kérhetjük le a megadott névhez tartozó értéket. getvalue("categoryname.itemname") Ha nincs ilyen bejegyzés a beállítások között akkor IloError típusú kivétel keletkezik. Ennek elkerülése érdekében használhatjuk a hasvalue metódust, mellyel kideríthetjük, hogy létezik-e a megadott bejegyzés a konfigurációs értékek között Osztálymetódusok a Python-ban Az osztálymetódus leginkább a Java-ban használt static kulcsszóval deklarált metódusokra hasonlít, de azért vannak különbségek. A Python-ban megkülönböztetünk classmethod és staticmethod metódusokat. A legfontosabb eltérés az, hogy míg a classmethod automatikusan megkapja a saját osztályára hivatkozó paramétert (ugyan úgy mint ahogy a normál metódusok is megkapják paraméterként azt az objektumot amiből meghívtuk), addig a staticmethod esetében ez nem történik meg. Például: class A: def normalmethod(self, def classmethod(cls, def staticmethod(param):... a = A() a.normalmethod('x') # self == a; param == 'x' A.classMehod('x') # cls == A; param == 'x' A.staticMethod('x') # param == 'x' 3.3. Anyagjellemző kollekciók A programban használt anyagjellemzők gyűjteményeket egy az API számára kifejlesztett úgynevezett XIM (XML Ilo Material) típusú fájlokban tárolhatjuk. Az anyagjellemzők minden fontos tulajdonságát tartalmazza (anyagtulajdonságok, textúrák, árnyékolók, stb., lásd az Anyagjellemzők alfejezetben). A fájl XML formában tárolja az adatokat: <matlib> <details> <name>materialliblaryname</name> <description> <![CDATA[ description]> </description> </details> <materials> <material id="materilid"> <name> # A kollekció neve # A kollekció leírása # A kollekció kezdete # Anyagjellemző azonosítója 26

32 <![CDATA[materialName]]> # Anyagjellmező leírása </name> <properties # Anyagjellmező tulajdonságai ambient="0;0;0;0" # visszavert szórtfény színe diffuse="0;0;0;0" # visszavert duffuse szín specular="0;0;0;0" # fény megcsillanás színe emission="0;0;0;0" # kibocsájtott fény színe shininess="10.0" # csillogás erőssége /> <texture # Textúra src="data/texture/hause.jpg" # elérési út filter="mipmap" # képszűrési eljárás /> <vertexshader></vertexshader> # Veretxshader program <fragmentshader></fragmentshader> # Framgentshader program </material> </materials> </matlib> A motor képes külön-külön is betölteni az XIM fájlokat, de a színtér leíró fájlban is (lásd. a következő bekezdésben) hivatkozhatunk rá és a benne található anyagjellemzőkre, az Ilo ezeket automatikusan beolvassa. A fájl értelmezését a Library osztály addximmatlib metódusa végzi. A metódus a kollekció elérési útját és a beolvasandó anyagjellemző azonosítók listáját (material ID) várja paraméterül. Az utóbbi paraméterrel szabályozhatjuk, hogy mely anyagjellemzők kellenek, ha nem adunk meg értéket akkor az összeset betölti. A beolvasott adatokból egy Material osztály jön létre mely automatikusan bekerül a Library anyagjellemzői közé a fájlban meghatározott azonosítóval (név ütközés esetén IloLibraryErro típusú kivétel keletkezik) Színtér leíró fájl Az Ilo a színtér adatainak tárolására XIS (XML Ilo Scene) fájlt használja mely az XIM-hez hasonlóan egy speciálisan erre célra kialakított XML fájl. A XIS elég sok paraméterrel rendelkezik. Alkalmas egy komplett 3D-s színtér leírására annak minden objektumával együtt. Azonban az Ilo, jelen állapotában csak a fontosabb paramétereket értelmezi. Az alábbi fájlrészlet egy egyszerű XIS fájlt mutat be: <map version="1.0"> <details> <mapid>test01</mapid> <mapname> <![CDATA[Test map]]> </mapname> <maptype>test</maptype> </details> <geometries> <geometry id="geommap" # Színtér leíró verziója # A színtér paraméterei # A színtér azonosítója # Színtér leírása # Színtér típusa # Színtér által haszált # geometriai kollekciók listája # A geometria belső azonosítója 27

33 src="data/model/map.ase" # A geometria forrása format="ase" # A geometrai fájl típusa /> </geometries> <matlibs> # Színtéren használt anyag- <matlib # jellemző kollekciók listája id="matlib01" # A kollekció belső azonosítója src="data/matlibs/matlib01.xml" # A kollekció elérési útja /> </matlibs> <mapobjects> # Színtér objektumok jellemzői <object id="main" # Objektum azonosító az Ilo-ban geometry="geommap.map" # kollekció.geometria azonosító Visible="1" # Az objektum láthatósága 1 0 coord="0;0;0" # Az objektim koordinátái x,y,z angle="0;0;0" # Az objektum elforgatása x,y,z scale="1;1;1" # Az objektum méretezése x,y,z texture="matlib01.zold_fu" # Kollekció.anyagjel. azon. /> </mapobjects> </map> A fájl feldolgozását a Library osztály loadscenexml metódusa végzi. Először beolvassa a fájl elején meghatározott anyagjellemző és geometria adatokat tartalmazó listákat (csak a neveiket, a listaelemeket még nem nyitja meg), majd ezt követően a <mapobjects/> lista elemei következnek melyeket elment egy belső struktúrába. A következő lépésben az elmentett mapobjects elemekből kiolvassa, hogy melyek azok a geometriák és anyagjellemzők amelyekre szükség lesz. Ezután megnyitja előbb a geometria majd az anyagjellemző kollekciókat és csak a valóban szükséges elemeket olvassuk be közvetlenül a Library osztályba. Végül a beolvasott objektumok hivatkozásait hozzárendeli a mapobjects elemeihez. A módszer előnye, hogy az összes geometria és anyagjellemző objektumot csak egyszer olvasunk be. Tehát egy objektumot tetszőleges mennyiségben újrahasznosíthatunk, mégpedig úgy, hogy közben számos paraméterét megváltoztathatjuk a program futása során. Fontos megjegyezni, hogy a színtérbetöltés egy extra funkciója a motornak mely csak limitáltan alkalmazható valódi programokban. Ennek azaz oka, hogy az egyes struktúrák nagymértékben projektfüggőek. Emiatt egy komolyabb fejlesztés során ajánlott a Library osztály kiterjesztése, oly módon, hogy megfeleljen a felmerülő újabb igényeknek is. Szintén ebbe a probléma körbe tartozik a támogatott modell fájlok száma és típusa. Az Ilo csak egy speciális formában tudja kezelni a modelleket. A megfelelő konverzió elvég- 28

34 zése a fájlfeldolgozó feladata. A motor által támogatott jelenlegi modell kezelési rendszer jó példa lehet egy esetleges tovább fejlesztéshez, továbbá az Ilo jól bővíthető ebből a szempontból ModelFile osztály A ModelFile egy összekötő osztály. Célja, hogy a beolvasott modellek adatait olyan formában tárolja amit a leképező rendszer már egyszerűen fel tud dolgozni. Csak adattagjai vannak, melyek a fájlok feldolgozása során kapnak értéket és grafikus objektumok létrehozásakor olvassuk ki őket. Interfészt képez a modellfájlok és az Ilo között, tárolja a csúcspontok összes fontos paraméterét (pozíció, szín, textúra koordináta, normálvektor), valamint a lapokhoz tartozó csúcsok sorszámait. Minden paraméter külön listában van eltárolva. A modellek adatai között nagy a redundancia például két csúcsponthoz ugyan az a textúra koordináta tartozik. Az Ilo ezt úgy kezeli, hogy a listában egyszer letárolt adatokat objektumreferenciák segítségével kapcsolja össze az egymáshoz tartozó értékekkel, például: az egy csúcshoz tartozó adatok összerendelését is automatikusan elvégzi a rendszer amikor létrehozza az egyes modellekhez tartozó struktúrákat Modell leíró fájl ASE fájl Az ASE [21] (Ascii Scene Exporter) egy speciális modell leíró fájl. A legtöbb modell fájllal ellentétben nem binárisan hanem ASCII karakterekkel kódolt, jól olvasható formában tárolja a geometriai és egyéb kiegészítő információkat. A fájl több egymásba ágyazott blokkból épül fel. A blokkokat csillaggal jelölt kulcsszavak kezdődnek (pl.: *SCENE) és a tartalmukat kapcsos zárójelek határolják. A blokkokon belül lehetnek újabb blokkok vagy adattagok. Az adattagokat szintén csillagozott kulcsszavak vezetik be. Az adattagok esetében a kulcsszót közvetlenül az adatok következnek szóközzel elválasztva: *MESH_VERTEX A példában egy csúcspont megadását láthatjuk, ahol a kulcsszó után (*MESH_VERTEX) először a csúcs sorszáma található. Az ezt követő három szám pedig a csúcs koordinátáit adják meg, rendere x, y, z formában. A fájl elkészítésére a 3ds Max nevű szofvert használtam. Az általam ismert progra- 29

35 mok közül csak ez képes megfelelően exportálni ASE típusú fájlt. Mivel itt teljes scene exportot hajt végre a program, ezért a nyers geometria adatok mellett a fájl tartalmaz további információkat is. Tárolja többek között a scene meta adatait és a felhasznált anyagjellemzőket. A fájlformátum támogatja az modellek animációs fázisainak tárolását is. Egyszerre több geometria objektum is elhelyezkedhet a fájlban, mindegyik saját azonosítóval ellátva, ezért az Ilo geometria kollekciónak tekinti ezeket a fájlokat és minden objektumot külön tárol el a Library-ben az ASE fájlban használt azonosítóval megegyező néven. A fájl feldolgozását az ase modul végzi mely a megnyitás után soronként értelmezi annak tartalmát. A sok adat közül az Ilo csak a geometriai objektumokat veszi ki és dolgozza fel. A kiolvasott adatokat egy ModelFile példány tárolja. 4. Eseményvezérlés és felhasználói interakciók Az eseményvezérlő a motor egyik legfontosabb és egyben legizgalmasabb része. Az egésznek az az alapgondolata, hogy a rendszerben történő különféle eseményeket (pl.: betöltés befejeződése, leképezési ciklus kezdete, stb.) nem egy központi objektum kezeli, hanem minden elemhez amelyben támogatják az eseménykezelést, saját eseménykezelőket rendelhetünk. Ahhoz, hogy egy objektum eseményt tudjon kibocsájtani (dispatch event) vagy egy adott esemény bekövetkezését figyelhesse (event listening), a EventDispatcher osztálynak szerepelnie kell ősei kötött. Az EventDispatcher biztosítja a megfelelő metódusokat és tárolókat ahhoz, hogy az objektum képes legyen kezelni az eseményvezérlést. Ezzel a módszerrel minden objektum maga kezeli a saját eseményeit. Egy esemény bekövetkezésekor az eseményvezérlő létrehoz egy új (a paraméterekben megadott) esemény objektumot, mely számos információt hordoz magában. Nagy előnye ennek a rendszernek, hogy nem szükséges az események bekövetkeztének folyamatos ellenőrzése: elég akkor megvizsgálni, hogy rendeltünk-e megfigyelőt az eseményhez ha az bekövetkezett. Sőt így könnyen felülkerekedhetünk az olyan speciális eseteken amikor például párhuzamosan töltünk be adatokat a program futása közben és a betöltés követően azonnal szeretnénk megjeleníteni az egyes objektumokat. Ekkor elég a betöltés befejezéséhez hozzárendelni egy eseménykezelő függvényt ami elvégzi a szükséges inicializálást a betöltött elemen. 30

36 A rendszer ötletét az Adobe ActioScript 3.0-ból merítettem, mely már régóta hatékonyan használja ezt a koncepciót. Az Ilo nem tartalmazza ennek az eseménykezelő rendszernek minden funkcióját. A jelenlegi változatban csak a legszükségesebb funkciók érhetők el. Először a Qt eseménykezelőjét nézzük át, majd részletesen megvizsgáljuk, hogy az Ilo-ban ez milyen formában jelenik meg és, miként épül fel a saját belső eseményrendszere Qt eseménykezelő Egy nagy ablakkezelő rendszer nem lehet teljes saját eseményvezérlő nélkül. A Qtben az eseményt signal-nak nevezik míg az eseményfigyelőt slot-nak. A Qt esetében a QObject (mely minden Qt osztály őse) connect metódusa segítségével köthetjük a slotot a signal-hoz: connect(quit, SIGNAL(clicked()), this, SLOT(close())); A példában látható SIGNAL és SLOT, egy-egy speciális C macro a connect metódus paraméterei pedig rendere a következőket jelentik: quit A kilépés gomb clicked() A kilépés gomb kattintás signal-t kiváltó metódusa this Az slot-ot tartalmazó objektum close() A slot mely a signal bekövetkezésekor aktiválódik A példából is látható, hogy az esemény figyelőhöz kötése során a signal-t küldő objektumot is meg kellett adni akár csak a slot esetében. Ebből következik, hogy bármikor bármilyen objektumon belül felvehetünk akármilyen signal-slot kötést ugyanis ezeket a rendszer globálisan kezeli. Az Ilo-val szemben több előnye is van. Egyrészt tetszőleges metódus átadható signal-nak vagy slotnak akár paraméterekkel együtt is. Az Ilo-ban minden eseményhez külön-külön fel kell venni egy új kezelőt. Másik előnye, hogy natív és globális. Ennek ellenére mégis úgy vélem, hogy az Action Script 3.0 rendszere jobban alkalmazható az Ilo-ban. Többek között mert könnyebben átlátható a hierarchikus struktúrákban és számos tovább fejlesztési lehetőséget nyújt, mint például a buborékos esemény továbbadás (bubling), ami azt jelenti, hogy ha történt egy esemény (pl.: ütközés) a modell hierarchia egyik elemében akkor az addig ugrik szülőről szülőre amíg nem talál egy meg- 31

37 felelő típusú esemény kezelőt ami lekezeli vagy el nem éri a gyökér elemet. Ez az ötlet hasonlít a kivételdobásra és kivétel kezelésre EventDispatcher osztály Ez az osztály végzi az eseményvezérlést. Ahhoz, hogy az Ilo-ban egy objektum képes legyen eseménydobására vagy eseményfigyelésére, akkor annak az ősosztálya között szükségszerűen szerepleni kell az EventDispatcher-nek. Az osztálynak két fő feladata van: először is képes események kibocsájtására (event dispatch), másodszor lehetőséget ad eseményfigyelők (listener) regisztrálására. A rendszer sajátossága, hogy csak az objektumon belül keletkezett eseményeket képes elkapni és átadni a figyelőknek. Viszont a figyelő metódusokat bárhol máshol definiálhatjuk, a lényeg, hogy a megfelelő objektum eseménykezelőjéhez kössük hozzá. Ahogy az előző bekezdésben már említettem, ennek a rendszernek egy tovább fejlesztett változata képes az események objektumok közti átadására (bubbling) is. Az EventDispacher a következő publikus metódusokat biztosítja: dispatchevent Esemény kibocsájtás addeventlistener Figyelő kötése egy eseményhez haseventlistener Lekérdezi, hogy van-e figyelője a paraméterben meg- adott eseménynek. removeeventlistener Töri a megadott eseményhez kötött figyelőt. Eseménydobás Az eseménydobás során a dispatchevent metódus számára egy felparaméterezett eseményobjektum példányt adunk át, mely tartalmazza az esemény típusát is. Az esemény típusa alapján a disopatchevent végignézi a beregisztrált eseményfigyelők listáját és ha megegyező típusút talál akkor végrehajtja azt úgy, hogy paraméterként átadja az eseményobjektumot. Ebből következik, hogy minden eseményfigyelő metódus kötelezően egy paraméterrel rendelkezik: def dispatchevent(event): if event.type in listenerlist: # Van-e figyelő a eseményhez for listener in listenerlist[event.type]: listener(event) # Összes figyelő meghívása dispatchevent(event(event.change)) # CHANGE típusú esemény dobása 32

38 Figyelők kezelése Az eseményfigyelők tetszőleges metódusok lehetnek, de fontos, hogy rendelkezniük kell pontosan egy darab paraméterrel az eseményobjektum fogadására. A figyelők regisztrálását az addeventlistener metódus végzi. Regisztráláskor meg kell adni azt is, hogy milyen típusú eseményekre reagáljon a figyelő, és magát az eseményfigyelőt is. Az addeventlistener a figyelőket eseménytípus szerint helyezi el egy speciális listában. Egy típushoz több figyelőt is hozzárendelhetünk. Ahhoz, hogy megszüntessük az esemény figyelését a removeeventlistener metódust kell használnunk. Meg kell adni az esemény típusát és a figyelőt (ugyan azt a függvény objektumot amit korábban regisztráltunk) is, hogy törölni lehessen a megfelelő elemet. A haseventlistener metódussal lekérdezhetjük, hogy rendeltünk-e már figyelőt egy adott esemény típushoz: def listener(event): pass # Figyelő létrehozása # Figyelő regsiztrálása addeventlistener(event.change, listener) # Figyelő törlése removeeventlistener(event.change, listener) # False-al tér vissza mert nincs figyelő az eseményhez haseventlistener(event.change) 4.3. Eseményobjektumok Az eseményobjektumok az események adatait tartalmazó üzenet osztályok, melyek eseménydobáskor keletkeznek a rendszerben és minden a típusukhoz rendelt figyelőnek automatikusan átadódnak. Az eseményobjektumok mindegyike az Event osztály leszármazottja, így könnyen létre tudunk hozni általános eseményfigyelőt. Az Event osztály felépítése: class Event(object): CHANGE = "change" # Egy esemény típus def init (type): _type = type _target = None # Event konstruktor # Típus tárolása # Eseménydobó tárolása Az eseményobjektum típusát elsősorban nem az őt reprezentáló osztály határozza meg hanem type adattag ami egy karakterlánc típusú érték. Az eseményobjektum típusát 33

39 kötelező megadni a létrehozáskor. A a rendszer által is támogatott típusokat az eseményosztály statikus osztályváltozók formájában tárolja, de lehetőség van tetszőleges típus megadására is: dispatchevent(event(event.change)) #A következő eseménydobás ekvivlens az előzővel dispatchevent(event("change")) Az eseményobjektumok másik fontos adattagja a target ami az eseményt dobó objektumra mutató hivatkozás. Ennek az értékét a dispatchevent metódus adja meg. Azért fontos ez az adattag, mert így a figyelő metódus műveleteket tud végezni az eseményt kiváltó objektumon. Az Event osztály leszármazottai további adattagokat adnak hozzá az előbbi kettőhöz, hogy még több információt adjanak át a figyelőknek, illetve újabb esemény típusokat definiálnak. A következő alfejezetekben az Ilo által biztosított Esemény osztályokat nézzük át Belső események Többek között a rendszeren belül bekövetkezett események figyelése is a belső eseményvezérlő feladata. Ilyen belső esemény például a grafikus mag inicializálása, de számos további esemény is keletkezik a rendszer futása során. Lássuk, milyen főbb esemény osztályok vannak beépítve az Ilo-ba. Event: Az alap eseményosztály számos általános esemény típust definiál. Többek között: egy objektum valamely állapota megváltozott (change), végbement az grafikus rendszer inicializálása (gl_init), következő képkocka leképezése (enter_frame) valamint a grafikus elemek egymásba ágyazása (added) és szétbontása (remove). ElementEvent: A grafikus elemek eseményeikor keletkezők. Jelenleg csak egy típust ismer, mégpedig azt, hogy az objektum leképezése befejeződött (rendered). WindowEvent: 34

40 Az ablak átméretezésekor (resize) keletkező eseményobjektum. Tárolja az átméretezett ablak pozícióját (x, y), szélességét (width) és magasságát (height) Felhasználói interakciók A felhasználó által kiváltott eseményeket legelőször a Qt eseménykezelője érzékeli. Az Ilo-ban meg vannak az ezek lekezeléséhez szükséges függvények. Amelyek az elkapást követően kinyerik a megfelelő adatokat és a belső eseménykezelőn keresztül tovább dobjuk az adott eseményeket. Csak a beviteli eszközök esetében kell ezt az eljárást alkalmazni. Az Ilo az egér és a billentyűzet kezelésére biztosít eseményosztályokat. KeyboardEvent: Egy billentyű leütésekor (press) és felengedésekor (release) keletkezik ilyen esemény. Mindkét esetben négy extra adatot tartalmaz a létrejövő objektum. Az első egy egész szám mely a billentyű kódját határozza meg, az ezt követő három logikai érték pedig a Ctrl, Alt és Shif kiegészítő billentyűk aktuális állapotát adja meg (a lenyomott állapot az Igaz értéknek felel meg). MouseEvent: Ez az esemény az egér mozgatásakor (move), valamely gombjával történő kattintáskor (click, release) és a görgő használatakor (wheel) keletkezik. Az eseményobjektum tárolja az egér aktuális x, y pozícióját és a relatív elmozdulását. Továbbá a lenyomott gomb kódját, és az egérgörgő relatív elmozdulását. A Qt számos további beviteli eszközt támogat (pl.: Joystick), melyeket hasonlóan egyszerűen be lehet építeni a jelenlegi rendszerbe az Event osztály leszármaztatásával Egyedi esemény osztályok Mi magunk is definiálhatunk saját eseményobjektumokat. Egyszerűen csak le kell származtatnunk az Event osztályt és már kész is. Az alap paramétereket kedvünk szerint bővíthetjük. Mindez akkor lehet hasznos, ha a készülő programunkat eseményvezéreltté szeretnénk elkészíteni. Amennyiben az objektumaink az EventDispatcher-ből származik akkor már is dobálhatjuk az általunk készített eseményeket. 35

41 5. Anyagjellemzők Az anyagjellemzők meghatározása elengedtethetetlen a realisztikusabb és részletgazdagabb megjelenítéshez. Az anyagjellemzők meghatározzák az geometriai objektumok színét, mintázatát és fényvisszaverő tulajdonságait. A textúrák segítségével részletgazdagabbakká tehetjük a felületeket. A különböző árnyékolók (shader) még tovább finomíthatják az egyes objektumok kinézetét (fragment shader), sőt akár az formájukat is megváltoztathatják (vertex shader). Végső soron az anyagjellemzők adják meg a színtér igazi részleteit, melytől realisztikusabbá válik a képernyőn megjelenő sok ezer poligon. Az anyagjellemzőket az Ilo három részre bontja, a következőkben ezeket tekintjük át. Az első maga az anyagjellemző, mely magában foglalja az anyag tulajdonságait (szín, csillogás, stb értékek), a textúrát és a shader-eket. A textúra és a shader méretüknél fogva két külön részt alkotnak. Az anyagjellemzők kezeléséről a fejezet végén lesz szó Material osztály Az anyagjellemző osztály önmagában csak az anyag tulajdonságait és az OpenGLből elérhető paramétereket tárolja. Továbbá lehetőség van egy textúra és egy shader (vertex és fragment shader egyben) hozzárendelésére is, de ez nem kötelező. Az anyag jellemzőit a következő paraméterekkel lehet megadni: ambient Az anyag színe szórt fényben diffuse Az anyag színe diffúz fényben specular Az anyag által visszavert fény színe emission Az anyag által kibocsájtott fény színe shininess Az anyag csillogásának mértéke A szórt fény a közvetett megvilágítás amely minden testet ugyan akkora intenzitással világít meg. A diffúz fény esetében már számít az objektum és a fényforrás egymáshoz viszonyított elhelyezkedése. Ebben az esetben a testet érő fény intenzitását a felület normálvektora és a fényvektor által bezárt szög koszinuszával arányos (Lambert törvény). A visszavert fény a felületről visszatükröződő fény hatását próbálja kelteni, az OpenGL erre 36

42 a Phong megvilágítási modellt használja. Ebben az esetben is számít a fényforrás és a test helyzete. A kibocsájtott fény beállításával maga a test is fényforrássá válik, ekkor a megadott színt bocsájtja ki. Végül a csillogási érték a fényvisszaverődés mértékét határozza meg. A Material osztály biztosít néhány metódust is: settexture Textúra hozzárendelése az anyagjellemzőhöz setshader Shader hozzárendelése az anyagjellemzőhöz bindmaterial Az anyagjellemző aktiválása remove Anyagjellemző törlése A settexture és setshader esetében egyszerűen csak hozzárendeljük az anyagjellemzőhöz a megfelelően létrehozott osztálypéldányokat, amiket a rendszer felhasznál a leképezés során Texture osztály A Texture osztály az anyagjellemzők bitképekkel (bitmap) megadható részét kezeli. Általában ezek a bitmap-es anyagjellemzők határozza meg a felület igazi részleteit és szüntetik meg az egy színű homogén kinézetet. Ezzel a módszerrel tetszőleges mintázatot adhatunk (a kép maximális felbontásának határain belül) a felületeknek, melyek ezáltal realisztikusabbak lesznek, és az ember számára könnyebben felismerhető válnak az egyes objektumok. Vegyük például azt amikor egy téglatestre apró sűrűn elhelyezkedő zöld levelek mintázatát feszítjük, azonnal az az érzésünk támad mintha az egy sövény lenne, de ha mondjuk vörös égetett agyag mintázatot adunk neki akkor már inkább egy téglára fog hasonlítani. Az osztály létrehozásakor meg kell adni a textúrának használt kép elérési útját és a leképezéskor alkalmazandó filterezési módot. A textúra betöltésekor a már korábban említett PIL (Python Image Library) könyvtár segítségét vesszük igénybe. A PIL támogatja az összes ismertebb képfájlformátumot. A betöltést követően nyers RGB (Red Green Blue) bitmap-pé konvertáljuk a képet, amit már az OpenGL is fel tud dolgozni. A korábbi OpenGL verziókkal szemben az 3.0-ban már nem szükséges, hogy a beolvasott kép felbontása a kettő valamely hatványa legyen sőt, a textúra szélességének és magasságának sem 37

43 kell megegyeznie. Az Ilo csak kétdimenziós textúrákkal dolgozik, tehát nincs lehetőség sem többrétegű vagy animált textúrák használatára. Az textúra létrehozásnak első lépése, hogy kérünk az OpenGL-től egy textúraazonosítót a glgentextures függvény segítségével, mely egy egész típusú értékkel tér vissza. Ezzel az azonosítóval hivatkozhatunk később az elkészült textúrára. Ezt követően utasítjuk az OpenGL-t a glbindtexture függvénnyel, hogy az előbb létrehozott azonosítóval szeretnénk műveleteket végezni. Ugyan ez az utasítás szükséges ahhoz a leképezés során ahhoz, hogy mostantól a megadott azonosítóval rendelkező textúrát kívánjuk használni a felületek textúrázásához. A következő lépés a betöltött kép RGB adatainak hozzárendelése a textúra azonosítóhoz, erre a glteximage2d utasítást használjuk. Mindezek előtt szükséges még a textúra paramétereinek, elsősorban a filterezésnek a beállítása. A filterezéssel meghatározzuk, hogy az OpenGL milyen számítási eljárást alkalmazzon a textúra kicsinyítése, illetve nagyítása során. gltexparameteri(gl_texture_2d, GL_TEXTURE_MAG_FILTER, GL_NEAREST) gltexparameteri(gl_texture_2d, GL_TEXTURE_MIN_FILTER, GL_NEAREST) A fenti példa arra utasítja az OpenGL-t, hogy a textúra kicsinyítése (GL_TEXTURE_MIN_FILTER) és nagyítása (GL_TEXTURE_MAG_FILTER) során is a közelítő (GL_NEAREST) számítási módot használja. Így például ha az adott felület túl közel kerül a megfigyelőhöz akkor sem kezd el pixelesedni, mert az OpenGL köztes megfelelően közelített képpontokat szúr be. Hátránya, hogy (főleg kis felbontású textúrák esetén) az új köztes képpontok miatt homályossá válhat a textúra. A Texture-nak két publikus metódusa van: a bindtexture és a remove. A bindtexture az osztály példány által tárolt textúra azonosítót állítja be aktuális textúrának, ezt követően a rendszer minden textúrakoordinátákkal rendelkező objektumra ezt a textúrát fogja alkalmazni addig amíg egy újabb bind utasítást ki nem adunk. A remove metódus a megfelelő OpenGL utasítások segítségével törli a textúra adatait a memóriából. Ezeken felül van még egy osztálymetódusa is az Texture-nak: unbindtexture. Az a metódus csak annyit csinál, hogy nullára állítja a leképezéskor használandó textúra azonosítóját, ezáltal textúra nélküli objektumokat is létrehozhatunk. Mellesleg ez az metódus minden bindmaterial híváskor lefut ha az adott anyagjellemző nem rendelkezik textúrával. 38

44 5.3. Shader osztály A régebbi 3D-s gyorsító kártyákban csak fix leképező csővezetékek (render pipiline) voltak, amelyek megkapták az adatokat és elvégezték a szükséges számításokat, majd megjelenítették a képernyőn az eredményt. A mai kártyák már engednek némi beleszólást ebbe a feldolgozási folyamatba. Lehetőségünk van olyan speciális programok írására amelyek megváltoztathatják a pipline-ban lévő adatokat. Ezeket a programokat árnyékolóknak (shader) nevezzük. Alapvetően kétféle típusú árnyékolót különböztetünk meg az alapján, hogy a csővezeték mely szakaszát képes vezérelni. A leképezési rendszer felépítését tekintve előbb az úgy nevezett vertex shader-ek hajtódnak végre melyek a objektumot csúcspontjain képesek műveleteket végezni. Lehetőség van a test deformálására vagy valamely csúcsponti paraméter megváltoztatására (pl.: szín, vagy textúra koordináta). A második a fragment shader ami a csővezeték végén található és akkor hajtódik végre mikor az OpenGL a kép 2D-s leképezését végzi. Ekkor még rendelkezésre állnak bizonyos 3D-s információk is, mely alapján a végleges kép pixelenkénti utómunkálatait végezhetjük el. Minden shader egy önálló program, melyet a grafikus kártya hajt végre a csővezeték megfelelő szakaszában. Ezeket a programokat egy a C-hez nagyon hasonló, speciálisan a shader-ekhez kifejlesztett nyelven kell megírni és maga az OpenGL fordítja és tárolja őket. A shadereket a textúrákhoz hasonlóan lehet hozzárendelni grafikai elemekhez. A shader program elsősorban ennek az objektumnak az adataihoz fér hozzá, de ezen felül lehetőség van például a fényforrások és más fontos információk lekérdezésére is. Tetszőleges számú shader programot alkalmazhatunk a leképezés során, de adott objektumhoz egyszerre legfeljebb csak egy vertex és egy fragment shader köthető. Az Ilo kizárólag a GLSL-ben (OpenGL Shading Language) [22] íródott árnyékolókat támogatja, amelyeket a Shader osztály kezel. A Shader osztály konstruktora csak a vertex és a fragment shader forráskódját várja paraméterül karakterlánc formájában. Nem kötelező mindkettőt megadni, lehetőség van csak vertex vagy csak fragment shader program létrehozására is. Miután megadtuk a szükséges paramétereket az osztály megfelelő metódusai elkészítik a shader programot: def createshader(vsrc, fsrc): program = glcreateprogram() 39

45 vshader = glcreateshader(gl_vertex_shader) glshadersource(vshader, vsrc) glcompileshader(vshader) glattachshader(program, vshader) fshader = glcreateshader(gl_fragment_shader) glshadersource(fshader, fsrc) glcompileshader(fshader) glattachshader(program, fshader) gllinkprogram(program) Először is létrehozunk egy tárolót a shader programok számára a glcreateprogram függvény segítségével, mely egész típusú azonosítóval tér vissza. Ezek után minden shader-nek létrehozunk egy külön tárolót amibe beletöltjük a forráskódot. A betöltött forráskódot a glcompileshader függvénnyel lefordítjuk, majd a glattachshader segítségével hozzáadjuk az előbb készített shader programhoz. Végül már csak a program linkelésre van szükség melyet a gllinkprogram-al végezhetünk el. Ha a fordítás során hiba történt akkor azt az OpenGL egy változóban tárolja el, amit a glgetshaderinfolog függvénnyel olvashatunk ki. Ugyan úgy mint a Texture osztály esetében a Shader is csak a bindshader és a remove metódusokat támogatja és ugyan az a feladatuk is. A belső mechanizmus viszont eltér. A shader objektumhoz kapcsolása (bind) a gluseprogram függvénnyel történik aminek a shader program azonosítóját kell átadnunk paraméterként. A shader törlésekor körültekintően kell eljárni mert a program eltávolítása előtt le kell választani a vertex és fragment shader-eket (gldetachshader) és csak utána törölhetjük a teljes programot (gldeleteprogram). A Shader osztály is tartalmazza az unbindshader osztálymetódust, mely a nulla azonosítóval hívja meg a gluseprogram függvényt, így kikapcsolva minden shader hozzárendelést Anyagjellemzők kezelése Az anyagjellemzők kezelését a már korábban is többször említett Library osztály végzi. A fájlok kezelésével foglalkozó fejezetben már tárgyaltuk, hogy milyen módon töltjük be az anyagjellemző kollekciókat, arról viszont még nem esett szó, hogy miként is rendszerezzük ezeket az adatokat. A Library osztály egy igen fontos része az Ilo-nak. Biztosítja, hogy ne legyen kétszer 40

46 ugyan az az adat letárolva. A betöltés folyamán a megadott azonosítók alapján rendszerezi az anyagjellemzőket, majd ezeket a program bármely pontjáról elérhetjük a Library segítségével. A Library osztály külön szótárat (Python dict típus) tart fenn az anyagjellemzők tárolására és számos metódust biztosít ezek elérésére és kezelésére: hasmaterial Ellenőrzi az megadott azonosító létezését getmaterial A megadott azonosítójú anyagjellemzőt adja vissza addmaterial Új anyagjellemző hozzáadása megadott azonosítóval removematerial A megadott azonosítójú anyagjellemző törlése removeallmatreials Minden anyagjellemző törlése A hasmaterial kivételével mindegyik metódus IloLibraryError kivételt dob ha a paraméterek között megadott anyagjellemző azonosító nem létezik (az addmaterial esetében éppen ellenkezőleg, az azonosító létezésekor keletkezik hiba). Van még egy metódus mely az anyagjellemzők kezeléséhez kötődik (addximmatlib) melyet a fájlkezelés fejezetben már részletesen megtárgyaltunk. A Library osztálynak csak a fele foglalkozik az anyagjellemzőkkel, a másik része a geometria objektumokat kezeli, melyről a következő fejezetben tudhatunk meg többet. 6. Grafikus elemek Mi most a grafikus elemek alatt azokat a részeket fogjuk érteni amelyek a leképezés során megjelenhetnek a képernyőn. Továbbá számos műveletet is elvégezhetünk rajtuk, melyekkel többek között pozicionálhatjuk vagy éppen hierarchiába rendezhetjük őket. Maguk a grafikus objektumok sokszögekből (poligon) épülnek fel. Az Ilo csak háromszög poligonokat (triangle) használ a leképezésre. A grafikus objektum alaposztálya a Mesh mely a geometria adatok betöltésének utolsó fázisa. Ezt a mesh objektumot (mely a Library osztály geometriái közé is bekerül) a színtér felépítése során rendeljük hozzá egy leképezőobjektumhoz (RenderObject). Ez a leképezőobjektum köti össze a geometriai információkat az anyagjellemzőkkel és itt kapnak tulajdonságokat is az egyes grafikai elemek (pl.: pozíció, elforgatás, méretezés, stb.). Az Ilo ezeknek a leképezőobjektumoknak a leszármaztatásával hozza létre a megjelenítési hierarchiát és hasonló módon mi magunk 41

47 is bővíthetjük a leképezhető objektumtípusok listáját: például a fényforrások is ebből az objektumból származnak, így örökölve a pozicionáláshoz szükséges tulajdonságokat. A fejezetben előbb a Mesh osztály vesszük szemügyre majd a leképezőobjektumok szerkezetével ismerkedünk meg. Itt fogok kitérni a megjelenítési hierarchia felépítésének mechanizmusára és a grafikus elemek leképezésének folyamatára. A fejezet végén a leképezési objektumok egy speciális kibővítését is megvizsgáljuk Mesh osztály A Mesh osztály feladata, hogy a ModelFile-ból (lásd: fájlkezelés) kinyert adatokat előbb a megfelelő módon összerendezze (pl.: a csúcspontok háromszögpoligonokhoz rendelése), illetve az így felépített struktúrát tárolja és leképezze. Az adatok összerendezésére azért van szükség, mert a modell fájlok általában a helytakarékosság miatt az azonos koordinátán levő csúcspontokat nem tárolják el, így a lapok csak a csúcs sorszámát ismerik. Ugyan ez igaz a textúrakoordinátákra is. Az összerendezés során előbb a csúcspontokat és a textúrapontokat tároljuk el a nekik megfelelő Vertex és VertexUV objektumokban. Mivel minden csúcsnak van normálvektorja ezért azokat a Vertex objektumban tároljuk. Ezek után a lapokat definiáljuk a Face osztály segítségével, melyek hivatkozás formájában tárolják a hozzájuk tartozó csúcspontokat és textúrapontokat. Végül az élekhez tartozó csúcspontokat határozzuk meg és tároljuk le az Edge osztály példányaiban. Az egész folyamatra azért van szükség, hogy a leképezés során könnyen el tudjuk érni a leképező rendszer a megfelelő adatokat, illetve így egyszerűbb az egyes egységek módosítása vagy lekérdezése: például az élek eltárolása hasznos lehet bizonyos árnyék készítő algoritmusok számára. Ahhoz, hogy az OpenGL letudja képezni az objektumokat, meg kell adnunk egységes formában a geometria minden csúcsának a jellemzőit és az összekapcsolás módszerét (pl.: háromszögeket vagy négyszögeket alkosson a megadott csúcsokból). Az OpenGL 1.0-ban a glbegin és glend függvényhívások között kellett megadni minden csúcsot (glvertex) és annak minden jellemzőjét (pl.: szín, textúrakoordináta, normálvektor) egy-egy függvénnyel: glbegin(gl_triangles) # Első csúcs és jellemzői # Háromszög lapok készítése 42

48 glcolor(r1, g1, b1) glvertex(x1, y1, z1) # 1. csúcs színe # 1. csúcs koordinátái # Második csúcs és jellemzői glcolor(r2, g2, b2) glvertex(x2, y2, z2) # Harmadik csúcs és jellemzői glcolor(r3, g3, b3) glvertex(x3, y3, z3) glend() Ezzel a módszerrel rengeteg függvény hívásra van szükség mely nagy poligon szám esetén már rendesen lelassíthatja a rendszer működését. Ennek kiküszöbölésére létrehozták a gllist objektumot. Ez az OpenGL-es objektum képes tárolni a fentebb megadott formában lévő utasításokat és ezeket egy előfordítást követően egyetlen függvényhívással tetszőleges számban leképezhettük. Használatával jelentős sebességnövekedés érhető el, viszont komoly hátránya, hogy a létrehozást követően nem módosítható. Továbbá mind a megadási formája mind pedig a hardveres gyorsítása igen nehézkes feladat. Jelenleg a legjobb megoldást a VBO, azaz a Vertex Buffer Object nyújtja. A VBO külön bufferekben tárolhatja a geometria csúcsainak minden jellemzőjét. Nagy előnye, hogy leképezéskor csak meg kell adni a megfelelő VBO-kat és egyetlen paranccsal a teljes objektum létrehozható. Tehát a leképezéshez igen kevés függvényhívásra van szükség, továbbá a buffer létrehozásakor megadható, hogy hogyan viselkedjen az adott VBO. Három viselkedést támogat az OpenGL: statikus (static), folytonos (stream) és dinamikus (dynamic). A rendszer ennek megfelelően optimalizálja a bufferek memória használatát, és biztosítja az adatokhoz való hozzáférést vagy módosítást. Szintén fontos tény, hogy ezek az objektumok a 3D-s gyorsító saját memóriájába kerülnek ami általában jóval gyorsabb mint a rendszer memória, tovább javítva a leképezés sebességét. A VBO hátránya, hogy a dinamikus viselkedés mellett minden kirajzoláskor át kell másolni a buffereket a videomemóriába, ami ronthatja a teljesítményt. Az OpenGL-ben a következőképpen hozhatunk létre Vertex Buffer Object-et: # VBO generálása vertexvbo = glgenbuffers(1) # Adatok betöltése a VBO-ba glbindbuffer(gl_array_buffer, vertexvbo) glbufferdata(gl_array_buffer, vertexlist, GL_STATIC_DRAW) # VBO leképezése 43

49 glbindbuffer(gl_array_buffer, vertexvbo) # A betöltött VBO típusa és formátuma glvertexpointer(3, GL_FLOAT, 0, None) # A leképezéshez használt poligonforma, és csúcsok számának megadása gldrawarrays(gl_triangles, 0, numofface * 3) A példában csak a csúcspont adatokat adtuk meg, de lehetőség van szín, textúrapont és normálvektorok megadására is. A leképezéskor minden megadott jellemzőt betöltünk és a gldrawarray függvény segítségével kirajzoljuk. A kirajzolás pontos helyét és módját, már a leképezőobjektum fogja meghatározni, amivel a fejezet későbbi részében fogunk megismerkedni. A Mesh osztály a következő publikus metódusokat biztosítja: rendermesh A geometria leképezése (lásd: előző bekezdésben) rendernormalvectors Normálvektorok leképezése shownormalvectors Normálvektor szakaszok létrehozása hidenormalvectors Normálvektor szakaszok törlése remove VBO-k törlése A shownormalvectors a meglévő csúcspontok és azok normálvektorjaiból kiszámítja minden csúcsra a hozzá tartozó normálvektort reprezentáló szakaszt. Ezt a szakaszt az OpenGL GL_LINE típusú glbegin/glend-es rajzoló eljárásával jelenítjük meg, melyet egy gllist objektumban tárolunk és a rendernormalvectors metódusban hívjuk meg. A normálvektorok megjelenítéséhez azért nem használunk VBO-t mert így egyszerűbb a megvalósítás. Ez a funkció csak tesztelés céljából van a rendszerbe építve, ezért a sebességre gyakorolt negatív hatásaival kevésbé foglalkozunk. A normálvektorok leképezésének kikapcsolásához használjuk a hidenormalvectors metódust, mely töröl minden ehhez kapcsolódó adatot a memóriából. A normálvektorok megjelenítése futásközben is be- és kikapcsolható. Végül a remove metódus a Mesh törlésére szolgál, eltávolít minden VBO példányt a memóriából Geometriák kezelése A geometriai adatok kezelését és tárolását a Library osztály végzi. Mint metódusaiban, mind pedig működésében teljes mértékben megegyezik az előzőfejezetben ismerte- 44

50 tett anyagjellemző kezelővel. Eltérés csak az egyes metódusok elnevezésében van (Material helyett Geometry) illetve, hogy a geometriai adatokat az anyagjellemzőktől elkülönítve egy másik szótárban tároljuk Leképezőobjektum Az előző fejezetekben már megismerkedtünk a geometriákkal és az anyagjellemzőkkel, viszont arról még nem esett szó, hogy ezek hogyan illeszkednek az Ilo-ba és egyáltalán mi alapján is megy végbe a grafikus elemek leképezése. Az Ilo ezen elemek megfelelő sorrendű leképezéséhez és a velük való műveletvégzéshez egy hierarchikus objektumstruktúrát hozunk létre. A leképezőobjektumok adják ennek a struktúrának az alapját. A hierarchikus elrendezés azt jelenti, hogy van az elemek között alá- II. 2. ábra: A hierarchikus elrendezés fa ábrázolása és fölérendeltségi viszony. Úgy is mondhatnánk, hogy az elemek szülő-gyermek kapcsolatban állnak. Minden gyermeknek lehet újabb tetszőleges számú gyermeke. Ezt a szerkezetet fa formájában is szokták ábrázol ahol a minden elem ősét gyökér (root) elemnek nevezzük, míg a legutolsó, gyermekekkel nem rendelkezőket pedig leveleknek (leaf) hívjuk. Az egy szülőtől származók gyerekeket testvéreknek is nevezik. Az Ilo-ban egy ehhez hasonló szerkezetben vannak elrendezve az egyes grafikusobjektumok. Ezt a struktúrát kihasználva arra is van lehetőség, hogy az egyes elemek örököljenek bizonyos tulajdonságokat szülő objektumuktól: ilyen tulajdonság például az elem térbeli pozíciója. Leképezéskor egy elem koordinátáit mindig a szülő objektum által meghatározott helyi vagy másképpen lokális (local) koordináta-rendszerben kell érteni, így egy elem mozgatásakor minden a struktúrában alatta lévő (minden gyermek) objektum is vele mozog. Ugyan ez igaz a forgatásra és a méretezésre is. Az Ilo nem csak az eseményvezérlésben, de az objektumhierarchia kialakításában is 45

51 az ActioScript 3.0-t vette alapul. A motor csak az elképzelés alapjait valósítja meg, de így is elég szolgáltatást biztosít összetett hierarchiák felépítéséhez is. A fa szerkezetben háromféle elemet különböztetünk meg. Az első a gyökér elem (root az Ilo-ban: scene), mely tetszőleges számú elemnek lehet a szülője, de ő maga senkinek sem lehet a gyereke. A második típusba azok az elemek tartoznak amelyeknek egy szülőjük van és tetszőleges számú gyerekük (Ilo-ban: container). A harmadik típus a levél (leaf) aminek egy szülő eleme van és nem lehet gyereke (Ilo-ban: renderobject). Ezt a három típust egy-egy osztály reprezentálja a motorban. Ezeket az előbbiekhez képest fordított sorrendben, az osztályok öröklődése szerint tekintjük át RenderObject osztály A RenderObject az alapja az egész grafikai elemstruktúrának, annak ellenére is, hogy a hierarchiafában a legutolsó helyet foglalta el azaz nem képes újabb elemeket tárolni. Az öröklődés szempontjából viszont ez a kiindulási osztály és ennek bővítésével valósíthatjuk meg az előző részben felvázolt három hierarchia elemtípust. A RenderObject a leképezés legkisebb egysége (leszámítva néhány kivételt, lásd szöveg megjelenítés), mely összekapcsolja a geometriát és a hozzá tartozó anyagjellemzőt. Ezenfelül számos igen fontos objektum tulajdonságot is tartalmaz. A RenderObject az EventDispatcher osztályból származik, így tetszőleges eseményt rendelhetünk bármelyik grafikus elemhez. Ez egy nagyon fontos jellemzője az osztálynak. Igazi értékét a tényleges program fejlesztése során mutatja meg, amikor az egyes objektumokat eseményekkel vezérelhetjük. Például figyelőket rendelhetünk az ütközésvizsgálathoz, vagy egyéb adatváltozáshoz. A motor jelenleg csak igen kis mértékben használja ki ezt a lehetőséget. Az eseménydobások a hierarchiához történő hozzáadásra és törlésre korlátozódnak, de ezek tetszés szerint bővíthetőek a megfelelő származtatással. Az objektum a következő eseményeket támogatja: ADDED Az elemet hozzáadjuk a hierarchiához ADDED_TO_SCENE Az objektumot a színtérhez adjuk hozzá REMOVE Az objektumot töröljük a hierarchiából REMOVE_FROM_SCENE Az objektumot töröljük a színtérről 46

52 RENDERED Az objektum leképzése befejeződött A RenderObject számos paraméterrel rendelkezik amelyekkel azonosíthatjuk és módosíthatjuk az objektumunkat. Illetve ezek között a tulajdonságok között van a Mesh és a Material értékek is amelyek megmondják melyik geometriát és textúrát szeretnénk használni az objektum leképezése során. id Az objektum egyedi azonosítója name A objektum beszédes neve (rövid leírása) parent Az objektum szülő eleme a hierarchiában scene Hivatkozás az objektum hierarchia gyökerére visible Az objektum láthatósága: True ha látható, különben False coord Az objektum 3D-s koordinátái (x, y, z) scale Az objektum méretezése (x, y, z), 1.0 az alapértelmezett angle Az objektum elforgatása a 3 főtengely mentén (x, y, z) geometry Az objektum geometriája material Az objektum anyagjellemzői shownormals Az geometria normálvektorjainak megjelenítése Ezek a paraméterek futásközben lekérdezhetők és módosíthatók, még az anyagjellemző és a geometria is. Ez azt is jelenti, hogy futásközben kicserélhetjük egy objektum megjelenését (textúráját), vagy a formáját, amit ha ügyesen kihasználunk, érdekes hatásokat kelthetünk a programunkban vagy megspórolhatjuk a hierarchia újraépítését. Az RenderObject pozíciója, elforgatása és méretezése mind az objektum lokális koordináta rendszerében értendők, ami azt jelenti, hogy a hierarchia gyökerétől kezdve öszszeadódnak az elem őseinek ezen értékei és az aktuális objektum paraméterei a már öszszegzett értékekhez adódnak hozzá. Tehát, ha az objektumunkat eltoljuk 10 egységgel a z irány mentén úgy, hogy a szülő elemét előtte elforgattuk az x tengelye körül 90 fokkal, akkor az eredmény úgy fog kinézni mintha az y tengely mentén mozgattuk volna az objektumunkat. A RenderObject egyetlen metódusa a render (az azonosító végén lévő dupla aláhúzásjel azt jelöli, hogy csak az Ilo használhatja) mely az objektum leképezését készíti elő 47

53 és meghívja a geometria és az anyagjellemző megfelelő függvényét. A függvény működését a következő kódrészlet mutatja be: def render (): if visible and geometry!= None: # Láthatóság és geometria ellenőrzés glpushmatrix() # Transzformációs mátrix mentése gltranslate(coord) # Objektum koordináták beállítása glrotate(angle.x, 1.0, 0.0, 0.0) # Forgatás az x tengely körül glrotate(angle.y, 0.0, 1.0, 0.0) # Forgatás az y tengely körül glrotate(angle.z, 0.0, 0.0, 1.0) # Forgatás az z tengely körül glscale(scale) # Objektum méretezése if material!= None: material.bindmaterial() else: Texture.unbindTexture() geometry.rendermesh() # Anyagjellemző ellenőrzése # Ha van akkor átváltunk rá # Ha nincs akkor kikapcsoljuk # Geometria leképezése if shownormals: # Normálvektorok leképzése geometry.rendernormalvectors() # esemény dobás leképezés után if haseventlistener(event.rendered): dispatchevent(event(event.rendered)) glpopmatrix() # Transzformációs mátrix # visszaállítása Jól látható, hogy a csak a geometria meglétének és a láthatóság ellenőrzését követően hajtódik végre a leképezés. A leképezés a transzformációs mátrix lementésével kezdődik, majd sorra beállítjuk az objektum pozícióját, elforgatását és méretezését. Ezt követően beállítjuk az anyagjellemzőt, ha van, különben teljesen kikapcsoljuk. A következő fázis a geometria leképzése és ha be van kapcsolva akkor a normálvektorjait is itt jelenítjük meg. Ha kész a leképezés, kibocsájtunk egy RENDERED eseményt. Legvégül visszaállítjuk a transzformációs mátrix leképezés előtti értékét. A mátrix elmentésének az egymásba ágyazott elemek esetén lesz igazi jelentősége RenderObjectContainer osztály Ez az osztály a RenderObject leszármazottja. A RenderObjectContainer azonkívül, hogy ugyan úgy képes geometriaobjektumot tárolni, ahogy a szülő osztálya is, lehetőséget ad más leképezőobjektumok tárolására. Bármilyen grafikus elemet el tud tárolni, amely a RenderObject-től származik. Ez az osztály valósítja meg a hierarchia elemek tároló típusát, mely tetszőleges számú gyermekkel rendelkezhet, de csak egy szülője lehet. A RenderObjectContainer a következő metódusokat biztosítja az eltárolt gyereke eleme kezelésére: 48

54 addelement Új grafikus elem hozzáadása a tárolóhoz getelementsbyname Elem lekérése a neve alapján removeelement Elem törlése a rámutató referencia segítségével removeelementsbyname Elem törlése a megadott name paraméter alapján Az elemek hozzáadása során az adott elem nem csak bekerül a tárolóba, de a szülő (parent) és a gyökér (scane) hivatkozások is itt adódnak át. A név szerinti elem törléskor (mivel nincs előírva az egyedi nevek használata) minden azonos nevű elem törlődik. Nem megfelelő hivatkozás esetén vagy egy elem többszöri hozzáadásakor ElementError kivétel keletkezik. Mind törléskor (REMOVED), mind pedig hozzáadáskor (ADDED) dobódik egy-egy esemény. A tárolót szótárral (dict) valósítjuk meg ahol a tárolt elem lesz az adatelem azonosítója és az adattag pedig az objektum neve: container[child] = name Ezzel a módszerrel elkerülhető az ugyan azon elemek többszöri hozzáadása egy tárolóhoz. Valamint az objektumok elnevezése is opcionálissá válik. A fejezet elején vázolt hierarchiai tulajdonságok miatt és mert ez az osztály több elemet is tárol, ezért a leképezés menete megváltozik. A leképezés során nem csak a saját geometria adatait kell megjelenítenie, de a tárolt gyerekelemeket is. Ezért a leképezéskor be kell járni a gyerekek listáját és egyesével meghívni az adott elemek render metódusát. Azonban nem mindegy a sorrend, ugyanis az elemeket úgy kell leképezni, hogy azok az aktuális objektum lokális koordináta-rendszerében legyenek. Éppen ezért a gyerekek listájának bejárása előtt kell beállítani az objektum tulajdonságokat (pozíció, elforgatás, méretezés) és csak ez után következhetnek a tárolt elemek. A RenderObjectContainer saját geometriáját a tárolt elemek után jelenítjük meg RenderScene osztály A RenderScene egy speciális RenderObjectContainer mely a harmadik hierarchia típust adja meg. Ennek az osztálynak nincs szülője, csak gyerek elemei lehetnek, így ez a grafikus elem adja a hierarchiafa alapját (gyökerét). Az Ilo-ban az teljes grafikus objektum hierarchia erre az osztályra épül, mivel csak annyiban tér el a RenderScene a RenderObjectContainer-től, hogy nincs parent adattagja, ezért teljesen megegyeznek. 49

55 Egyedül az elemek hozzáadása és törlése tér el annyiban, hogy más eseménykiváltást idéznek elő, mint az ős osztályban (ADDED_TO_SCANE, REMOVED_FROM_SCENE). 7. Fények kezelése A fények megjelenítése a 3D-s környezetben egy fontos kérdés, mert nagy mértékben hozzájárulnak a képernyőn megjelenő kép valósághűségéhez. Az Ilo-ban a fényforrások kezelését a LightLibrary osztály végzi, mely egy singleton osztály. A LightLibrary fényforrás objektumokat, LightObject típusú elemeket tárol. Az OpenGL-ben mindig van egy felső határa az egy időben felhasználható fényforrások számának. Ezt a számot a grafikus chip képességei határozzák meg. Az OpenGL képest ezt az értéket kiolvasni. Emiatt a korlátozás miatt csak a LightLibrary-től lehet új fényforrást igényelni. Ezeket a kikért fényforrásokat eltárolja és ezek alapján állapítja meg, hogy van-e még rendelkezésre álló erőforrás LightLibrary osztály A LightLibrary létrehozásakor (szigorúan az OpenGL inicializálást követően) lekérdezzük a rendszer által felhasználható fényforrások számát (az OpenGL követelményei szerint ez a szám minimum 8). Ez alapján hozzuk létre a nem használt fényforrások azonosítóinak listáját. A fényforrások tárolásán kívül ez az osztály kezeli a globális bevilágítást is, melyről a későbbiekben lesz szó. Lássunk a főbb tagfüggvényeket: addlight Fényforrás kérése removelight Kérés törlése getlinkedlightsids A már felhasznált fények azonosítóinak listája getlinkedlightobjects A használt fényekhez kacsolódó objektumok listája turnonlights Világítás leképezés be turnofflights Világítás leképezés ki switchlight Világítás leképezés váltása globalambient A globális szórt fény színe A fényforrás igénylése során előbb megbizonyosodunk arról, hogy van még felhasz- 50

56 nálható OpenGL azonosító: ha van akkor létrehozunk egy LightObject változót melyet eltárolunk a LightLibrary-ben, majd az addlight metódus ugyan ezzel az értékkel tér vissza, hogy rögtön használatba is vehessük. Ha már nincs több felhasználható fényforrás akkor IloError hibát kapunk. A fényobjektumok törlésekor meg kell szüntetni a fényforrások linkelését is, hogy később újra hasznosítani tudjuk azt. Lehetőség van lekérdezni az osztálytól, hogy eddig mely fényforrás azonosítókat használtuk fel (getlinkedlightsids) illetve, hogy ezeket mely objektumokhoz kapcsoltuk (getlinkedlightobjects). A fényekkel kapcsolatos beállítások központosítása érdekében a LightLibrary-vel végezhetjük el a globális fénybeállításokat is. Az egyik ilyen beállítás maga a bevilágítás be- és kikapcsolása: glenable(gl_lighting) gldisable(gl_lighting) # Bevilágítás bekapcsolása # Bevilágítás kikapcsolása A másik fontos beállítási a globális szórt fény színe. Ez az a fény melyet az OpenGL mindig biztosít annak érdekében, hogy tényleges fényforrások hiányában is láthatók legyenek a leképezett geometriák. Ennek a beállítását a globalambient metódussal végezhetjük el a szín és az áttetszőségi érték megadásával (RGBa) LightObject osztály A LightObject egy modul szinten privát osztály, tehát csak ezen a modulon belül lehet példányosítani. Ez azért szükséges, mert csak a LightLibrary-ban van rá szükség. E t - től függetlenül a példányosított LightObject-eket már bármely másik modulban is használhatjuk. A LightObject osztály a RenderObject osztályból származik. Így ugyan úgy tudjuk mozgatni és forgatni mint bármely más grafikuselemet és a hierarchiába is könnyen beépíthető. Gyermek eleme nem lehet, viszont megadhatunk geometria jellemzőt is, ami a tesztelést is megkönnyíti illetve éles rendszerben is hasznos lehet. Az Ilo kétféle fényforrást támogat (ugyan azokat mint az OpenGL): az egyik a pontszerű fény (omni), amely egy pontból bocsájt ki fényt minden irányba, a másik típus pedig a reflektor (spot), aminek megadhatunk extra paraméterekkel egy kúp alakú tölcsért és csak ezen belül érvényesül a fényforrás fénye. Ennek megadásához meg kell hívni az 51

57 objektum setspot metódusát amelynek két paramétere van: a tölcsér iránya és a nyílás szöge. Az unsetspot metódus törli az extra paramétereket és visszakapjuk a kiindulási pontfényt. A fényforrás beállítására számos paraméter áll rendelkezésünkre, ezeket a következő lista sorolja fel. lighttype Fényforrás típusa (omni vagy spot) diffuse A fényforrás diffuse színértékei ambient A fényforrás ambient színértékei specular A fényforrás specular színértékei lightintesity A fényforrás intenzitása A fényforrás típusáról már volt szó, az ezt követő paraméterek pedig a kibocsájtott fény tulajdonságait határozzák meg. A diffuse, az ambient és a specular ugyan azt jelentik mint az anyagjellemzőknél, csak most a fény szempontjából. Az OpenGL a fény és az anyagjellemző megfelelő tulajdonságaiból kalkulálja ki a a végleges színt ami jelentősen eltérhet a megadott értékektől. A LightObject a többi fényforrástól függetlenül is fel- és lekapcsolható az enabled és a disabled parancsokkal. 8. Szöveg megjelenítése Fontos, hogy a rendszer képes legyen megjeleníteni szöveges információkat is a képernyőn. A legtöbb ablakkezelő rendszerben ezzel nem kell törődnünk, mivel a szöveg kiíratás mikéntjével nem kell törődni. Egyszerűen csak beállítjuk a paramétereket (betűcsalád, méret, szín, stb.) és már meg is jelenik a szöveg a kívánt formába. Hasonló célt tűztem ki az Ilo-ban is a szövegkezelő rendszer számára. Viszont ebben az esetben minden betű kiíratásáról az OpenGL rendszeren belül kell gondoskodni. A 3D-s környezeteben alapvetően kétféleképpen jeleníthetünk meg szöveget, 2D-ban vagy 3D-ban. Az Ilo csak a 2D-s szöveg leképezést támogatja. Ennek a módszernek a lényege, hogy csak a képernyő síkjára írunk. Ami azt jelenti, hogy a szöveget csak ezen a síkon belül mozgathatjuk, forgathatjuk, skálázhatjuk. Továbbá a szöveg mindig kitakarja az összes 52

58 többi 3D-s grafikai elemet. Úgy is mondhatnánk, hogy a szöveg a legfelső rétegen van. A betűk megjelenítéséhez többféle módszert használhatunk: vagy egy betűket tartalmazó textúrát (FontMap) használunk és minden betű egy négyszög poligonra van kifeszítve. Vagy a másik lehetőség, hogy TrueType betűk alapján állítjuk elő a betűket. Ez utóbbi sokkal összetettebb eljárásokat igényel és jelentősen erőforrás igényesebb is, viszont sokkal jobban skálázhatók a betűk és tetszőleges betűkészletet lehet használni. Az Ilo Font- Map-et használ a betűk kirajzolására. A 3D-s megjelenítés esetén a betűket is 3D-s grafikus elemeknek kell elképzelni, így ugyan azok a paraméterek érvényesülnek ezekre is mint a többi hasonló elemre. A térben mozgathatjuk, forgathatjuk és skálázhatjuk a szöveget. Textúrákat és árnyékolókat is alkalmazhatunk rájuk. Ehhez az eljáráshoz nem használható a FontMap. Vagy eltároljuk az összes betűt mint grafikai elem, vagy a TrueType módszerhez hasonlóan futásközben generáljuk az egyes betűket. Az első módszer több memóriát igényel (főleg több betűkészlet használata esetén), viszont kevésbé számítás igényes mint a második. A következő alfejezetek az Ilo által használt szövegmegjelenítő osztályokat és leképezéshez használt eljárást mutatja be Szövegleképezés Az Ilo csak a 2D-s és ezen belül is csak a FontMap-es megjelenítést támogatja. Ehhez szükség van egy FontMap textúrára amely szigorúan mátrix elrendezésben tartalmazza a képeket fekete háttéren fehér színnel. Kétféle betűtípusra osztható, melyek karakter tartalmaznak. A karakterek indexe megegyezik az ASCII-ben meghatározott karakterkódokkal (pontosabban a (karakterkód-32)-vel, mivel a vezérlő karaktereket nincsenek benne). A textúra felbontása tetszőleges, a beépített FontMap 256x256 méretű. FontMap létrehozásához könnyen találhatunk segédprogramot amivel könnyedén generálhatunk sajátot. Amennyiben a resource/fontmap be van állítva a konfigurációs-fájlban akkor az OpenGL inicializálását követően az Ilo létrehozza a FontMap alapján a betűk listáját. A lista minden eleme egy gllist ami egy négyszög poligont definiál úgy, hogy a FontMap megfelelő betűjének az (u, v) koordinátáit is megadjuk. A poligon létrehozása után (még 53

59 mindig a gllist-en belül) meghívjuk a gltranslate(12,0,0) függvényt. Ezzel azt érjük el, hogy egy betű kiíratása után automatikusan a következő karakter pozíciójára ugrik a virtuális kurzorunk. A szövegobjektumok megjelenítésére a leképező folyamat legvégén kerül sor. A leképezés előtt be kell állítani a környezet számos paraméterét: először is a vetítést átállítjuk ortografikus módba, majd kikapcsoljuk a fényeket és végül beállítjuk az áttetszőséget (Blending). Ezt követően megjelenítjük a Text (lásd a következő fejezetben) osztályban található szövegobjektumokat. A szövegleképezést követően minden környezeti beállítást visszaállítunk Text osztály Ennek az osztálynak a segítségével hozhatunk létre új szövegobjektumokat, illetve törölhetjük is azokat. Erre az addtext és a removetext metódusokkal tehetjük meg. Ha az összes objektumot ki akarjuk törölni a listából, akkor használjuk a removeall-t. A Text egy listában tárolja az összes létrehozott szövegobjektumot. Azért van erre szükség, hogy a leképezés során ennek segítségével egy menetben meg lehessen jeleníteni az ös z- szes szöveget. Az osztály felépítése hasonlít a LightLibrary-éra, ugyan úgy egyke mintát használ és egy olyan objektumot tárol amit csak a saját modulján belül lehet példányosítani. Az addtext éppen ennek a láthatatlan TextLine osztály példányával tér vissza. Ez két okból is fontos: egyrészt mert így futás közben módosíthatjuk a szövegobjektum tartalmát és paramétereit, valamint ennek segítségével (referenciájával) tudjuk törölni az eredeti objektumot a listából TextLine osztály Ennek az osztálynak az egyetlen célja a szövegobjektum paramétereinek tárolása. A következő adattagokat tartalmazza: x y text A szöveg x pozíciójára a képernyőn A szöveg y pozíciójára a képernyőn A megjelenítendő szöveg 54

60 scale A szöveg skálázása fontset Betűkészlet használata (0 vagy 1) A koordináták pixelben értendők és a (0, 0) pont a képernyő jobb felső sarkában található, a maximális értékeket pedig az ablak méretei határozzák meg. A scale egy két elemű lista és a [1.0, 1.0] érték adja meg az eredeti szövegméretet. Végül a fontset a FontMap-ben található 2 betűkészletnek megfelelően 0 vagy 1 értéket vehet fel. 9. Részecskerendszerek A 3D-s részecskerendszerek egy hatalmas témakör, hiszen idetartozik minden olyan szimulációs eljárás amely a valós részecskék mozgását próbálják lemodellezni. Idetartozik például a füst és por hatások, a folyadékok szimulálása, sőt, a manapság a filmiparban látható monumentális csatajelenetekhez is speciális részecskerendszert alkalmaznak. Ezeknek a rendszereknek az a lényege, hogy adott egy bizonyos mennyiségű elem, amelyet egy szabályrendszer fog össze. A részecskerendszer működését ez a szabályrendszer határozza meg, ez mondja meg az részecskéknek, hogy hogyan viselkedjenek. Ilyen szabály lehet a gravitációs erő (vagy annak hiánya), a szél vagy az ütközésekkor bekövetkező események definiálása. Maguk a részekék is igen sokféle tulajdonsággal és megjelenéssel rendelkezhetnek. Általában mindig van sebességük és irányuk, de ezen felül a rendszernek megfelelően bármilyen egyéb tulajdonságuk is lehet. Kinézetük lehet egy sík poligon vagy 3D-s objektum is. Az Ilo-ban egy végtelenül egyszerű részecskerendszer van, amely elsősorban az API képességeinek prezentálására lett beépítve. Ettől függetlenül igény szerint tovább bővíthető és fejleszthető, mivel az részecskerendszerek alapelemei megtalálhatók benne BaseParticleSystem osztály Az Ilo-ban ez az osztály valósít meg egy részecskerendszert, mely igen kevés szolgáltatással rendelkezik. Sok más osztályhoz hasonlóan ez is a RenderObject-ből származik, ami azt jelenti, hogy bármely objektumhoz hozzá ragaszthatjuk egy tároló segítségével. 55

61 Az konstruktor két paramétert vár, az egyik a részecskék száma, a másik pedig a részecskékre kifeszített textúra. Már ebben a fázisban legenerálódik a megadott számú részecske, a megfelelő belső metódusok segítségével. Az egyes elemekhez tartozó adatok (pozíció, méret, elforgás, stb.) egy belső osztály tárolja (Particle). A részecskerendszerek legfontosabb része a megfelelő inicializálás, lényegében ez határozza meg a rendszer viselkedését, és ezen múlik a megjelenítés hitelessége is. Szintén ebben a szakaszban jönnek létre a részecskék megjelenítéséhez szükséges, gllist-be ágyazott textúrázott négyszög poligonok. Az inicializálást követően beindul a részecskék mozgása. Az osztály render metódusát használjuk fel az egyes szakaszok kiszámítására és leképezésére. Két fontos dolog is történik az elemek megjelenítése előtt, a szokásos pozicionálás mellett: Először is meghíjuk a glblendfunc(gl_src_alpha, GL_ONE) függvényt az itt látható paraméterekkel. Ennek hatására a részecskékhez megadott textúra fekete területei áttetszők lesznek és realisztikusabbá válik a megjelenítés (pl.: por vagy füst esetében). A glblendfunc segítségével más effekteket is létrehozhatunk, ami igen látványossá teheti a látványt. Másodszor engedélyezzük a GL_POLYGON_OFFSET_FILL-t. Erre azért van szükség mert könnyen előfordulhat, hogy az egyes részecskéket alkotó négyzet poligonok pontosan egy síkban vannak, ilyenkor a kerekítési hibákból kifolyóan a felületek villódzani kezdenek. Miután engedélyeztük a beállítást, a leképezés során használhatjuk a glpolygonoffset függvényt, ahol megadhatjuk minden poligon esetében a megfelelő eltolás értéket. Minden részecske közel egy tucat paraméterrel rendelkezik. El van tárolva az elem pozíciója, elforgása, mérete, sebessége, stb., ezek többsége az egyes animációs lépések kiszámításához szükségesek. Van azonban két paraméter amelyek elengedhetetlenek: az egyik a részecske élettartama, a másik pedig az öregedés sebessége. Azért fontosak ezek az értékek, mert így újra tudjuk hasznosítani a részekéket. Ha lejárt egy elem élete akkor nem töröljük, hanem újra inicializáljuk és helyezzük a kezdőpontba, új életet kezd. Az Ilo-ban található részecskerendszer kísérleti jellegű, ami abban nyilvánul meg, hogy minimális a paraméterezhetősége illetve egyetlen hatás szimulálására van beállítva. 56

62 A motor ezen része már inkább a demó alkalmazás felé közelít, hiszen bemutatja a rendszer bővíthetőségét. 10. Az Ilo motor Ahhoz, hogy használhassuk az Ilo motor nyújtotta lehetőségeket, elég, ha leszármaztatjuk az IloEngine osztályt. Az IloEngine a RenderScene-ből származik, ami azt jelenti, hogy közvetlenül hozzáférhetünk a grafikuselem hierarchia gyökeréhez és minden metódusához. Az IloEngine nem csak a hierarchia első eleme, de lényegében az összes fontosabb komponens is itt kapcsolódik össze. Itt vannak definiálva többek között az ablakkezelő és az OpenGL környezet inicializálása is. Ebben az osztályban alakulnak át a Qt által dobott események az Ilo-ban egységesen használt eseményobjektumokká. Ezeken felül hozzáférést biztosít minden főbb objektumhoz: application Qt futtató környezet window Qt ablak objektum glcontext A leképező rendszer főobjektuma library Az adatok tárolására szolgáló struktúra Továbbá számos segédfüggvény is megtalálható az osztályban: vertsync Függőleges szinkronizálás beállítása fps Maximális FPS szám beállítása hidemouse Egér elrejtése/megjelenítése A függőleges szinkronizálás lényege, hogy utasítjuk a videóvezérlőt, hogy csak bizonyos esetekben engedje a képernyő frissítését. Ez általában azt jelenti, hogy csak akkor frissül a képernyő tartalma, ha már befejezte az előző kép megjelenítését. Így csökkenthetjük a kép vibrálását. Azt a funkciót teljes mértékben a Qt kezeli. Az FPS (Frame Per Second) azaz a képkocka másodpercenkénti száma. Az Ilo folyamatosan számolja ezt az értéket. A getcurfps metódussal kérdezhetjük le az aktuális FPS értéket. Ezen felül az fps adattaggal korlátozhatjuk a maximális képkocka számot. Ennek 57

63 az értéke a konfigurációs-fájlban is beállíthatjuk, de akár futás közben is megváltoztathatjuk. 11. Az API telepítése Az Ilo használatához szükséges, hogy a fel legyenek telepítve a megfelelő függvénykönyvtárak. Ebből következik, hogy az Ilo használatához szükséges, hogy biztosítva legyenek a szofveres feltételek. A függőségek részletes leírása az alábbi fejezetekben található. A másik fontos következmény, hogy az Ilo-t nem lehet úgy telepíteni mint egy programot. Valójában a fejlesztői környezet részét képezi, ezért a telepítési útmutató lényegében ennek a környezetnek a kialakítását írja le. Az Ilo-t használó program telepíthető változatának előállítása már teljes mértékben a fejlesztő feladata. A telepítési útmutatók csak a legszükségesebb elemekre tér ki, amelyek szükségesek ahhoz, hogy a rendszer el tudjon indulni, például terminálon keresztül. A fejlesztő környezet többi elemét tetszés szerint összeállíthatjuk (pl.: IDE, képszerkesztő, stb.) Hardveres feltételek Az Ilo alapvetően kis erőforrás igényű könyvtárakra épül, viszont a Python sokat ront ezen a helyzeten. Tényleges teszteket nem végeztem azzal kapcsolatban, hogy milyen a minimális hardver igénye a rendszernek. Csak arról tudok nyilatkozni, hogy a rendszer amelyen fejlesztettem és teszteltem, kiválóan futott nagy poligonszámú (~ poligon) modellek betöltése esetében is. A fejlesztés során a következő rendszert használtam: Processzor Memória Videóvezérlő Intel Core2 Duo 2GHz 2 Gb nvidia GeForce 9300M Ubuntu Linux rendszerre Minden szükséges összetevő telepíthető az Ubuntu tárolójából (repository), illetve egyes komponensek előtelepítve érkeznek az operációs rendszerrel. Python 2.6 Alapértelmezetten telepítve van 58

64 PIL (Python Image Library) Python Qt4 PyOpenGL NumPy 1.3 Alapértelmezetten telepítve van sudo apt-get install python-qt4 sudo apt-get install python-opengl sudo apt-get install python-numpy Windows 7 rendszerre A Windows rendszeren egy kicsit komplikáltabb a helyzet. Minden komponenst saját kezűleg kell letöltenünk az egyes webhelyekről. Letöltés előtt ne felejtsük el ellenőrizni a verziószámokat és a rendszer architektúrát. Ha megvannak az egyes összetevők akkor azokat könnyen telepíthetjük, mivel a kiegészítőkönyvtárak telepítője (amely már csak lefordított binárisokat tartalmaz) észleli a rendszerben lévő Python verziókat. Sajnos vannak buktatói is a telepítésnek. Például Windows Vista és Windows 7 rendszereken a telepítő nem állítja be registry bejegyzéseket és így a további komponensek nem találják a telepített Python-t. A másik probléma, hogy a numpy-nek nincs 64 bites verziója, így minden komponensből (a Python-nal együtt) csak a 32 bites verziót telepíthetjük. A dolgozathoz mellékelt lemezen megtalálhatók a teljes telepítőkészlet. 59

65 III. Bemutatóprogram A programnak a célja, hogy bemutassa az Ilo 3D-s grafikus motor által nyújtott szolgáltatásokat, valamint mintaként szolgáljon más Ilo-ra épülő alkalmazásokhoz. Azért van erre szükség, mert az Ilo önmagában csak egy osztály és függvény halmaz, melyet nem lehet önállóan futtatni, csak ha beépítjük egy projektbe. A bemutatóprogram az Ilo képességeit hangsúlyozza ki, ami azt jelenti, hogy semmilyen játéklogikát nem tartalmaz. Már egy egyszerűbb játékprogram megírása is túlmutat a dolgozat keretein, így valójában ezt a bemutatóprogramot tekinthetjük egy technológiai demónak is, ahol a grafikai megjelenítésen van a hangsúly. A program alaptémáját a Vissza a jövőbe című filmtrilógia harmadik része ihlette. A filmből jól ismert időgép a vadnyugati város részlet előtt elhaladó síneken helyezkedik el. A tereptárgyak alapvetően nagy poligonszámúak (főként az autó). Így nem csak szebb képet kapunk a részletgazdag objektumok miatt, de a motor jó terhelhetőségére láthatunk példát. A program csak korlátozottan tartalmaz interakciót, a kamera tetszőleges mozgatása mellett, csak egy-két objektum mozgatására és egyes paraméterek ki-/bekapcsolására van lehetőség. 1. A bemutatóprogram felépítése Mindenek előtt vizsgáljuk meg a program könyvtárszerkezetét, és tekintsük át, hogy az egyes mappák mit tartalmaznak. Az alábbiakban vázol struktúra a számtalan út közül egy, tetszőlegesen módosítható Fájlszerkezet A 3. ábrán jól látható, hogy a bemutatóprogram két főkönyvtárat tartalmaz. A ilo természetesen az Ilo modul és osztály fájljait tartalmazza. Az egész program erre a kódbá- 60

66 Bemutatóprogram zisra épül. Ha használtunk volna más programkönyvtárat akkor már célszerű lett volna egy külön lib könyvtárat létrehozni azoknak az Ilo-val együtt. A másik könyvtár ( demo ) tartalmazza a program összes adatfájlját. A következő adattípusokat találjuk meg itt: Modellfájlok Ezek tárolják a leképezendő objektumok poligonhálóinak adatait: csúcspontok koordinátái, textúra koordináták, normálvektorok, stb. A demóban minden modell ASE típusú fájlban van eltárolva. Textúrafájlok Bitképfájlok (a demóban JPEG) amelyeket a modellek textúrázáshoz használ fel az Ilo. XML-fájlok Ezen fájlok segítségével konfigurálhatjuk a rendszer III. 3. ábra: Fájlszerkezet működését, adhatjuk meg a betöltendő modellek és textúrák listáját és az azok közötti kapcsolatokat. A két főkönyvtár mellett láthatunk egy game.py fájlt mely a demó logikáját tartalmazza. A következő fejezeteben ezt bonjuk szét A bemutatóprogram logikája. Ahogy a fejezet elején már említettem, a program csak a legalapvetőbb funkciókat mutatja be, mint egy technikai demó. A következő részben sorra vesszük a demó létrehozásának főbb lépéseit és az Ilo alkalmazását: Mindenek előtt a programunknak le kell származtatnunk az IloEngine osztályt, majd a konstruktorban meg kell hívnunk az IloEngine konstruktorát, opcionálisan megadhatjuk a saját konfigurációs fájlunk elérési útvonalát: class Game (IloEngine): def init (self): IloEngine. init (self, "demo/config.xml") self.fok = 0 inicializálása # saját változó 61

67 Bemutatóprogram A következő fontos lépés a az IloEngine preload függvényének felüldefiniálása. Ez a metódus automatikusan meghívódik az OpenGL környezet inicializálást követően, éppen ezért célszerű itt beállítani a főbb változókat, kiindulási értékeket és az eseménykezelő függvényéneket: def preload(self): # kamera objektum eltárolása self.cam = self.glcontext.camera # kamera pozícionálása self.cam.moveto(0.0,-40.0,20.0) # eseménykezelők beállíása self.addeventlistener(keyboardevent.press, self.keyevent) self.addeventlistener(event.enter_frame, self.enterframe) self.addeventlistener(mouseevent.move, self.mouseevent) Szintén ezen a metóduson belül érdemes elkezdeni a modellek betöltését is, melyet megehetünk a mapdata.xml fájl segítségével. Ennek egy objektum tároló lesz az eredménye amit hozzá tudunk fűzni a gyökér elemhez (csak a gyökér elemből elérhető elemek lesznek leképezve!): self.level = self.libraly.loadscenexml('demo/mapdata.xml') self.addelement(self.level, "level") De lehetőségünk van teljesen manuális betöltésre is: # létrehozunk a modell számára egy üres tárolót self.car = RenderObjectContainer() # betöltjük a kívánt modellt a rendszer geometria könyvtárába self.libraly.addgeometryfromfile("demo/model/delorien.ase", "ase", "*") # a megfelelő elemeket hozzáadjuk a 'car' objektumhoz for i in ['body', 'door', 'inside', 'Mrfusion', 'window', 'hood'] : self.car.addelement(renderobject(i, self.libraly.getgeometry(i), None)) # Az elkészített tárolónkat hozzáadjuk a gyökér elemhez self.addelement(self.car, "delorien") A következő lépés a fényforrások beállítása. # Az egyszerűség kedvéért elmentjük a fénykezelő objektumot self.light = LightLibraly.getInstance() # Globális fény beállítása self.light.globalambient([0.5,0.5,0.5,1.0]) # fények felkapcsolása self.light.turnonlights() # Egyedi fényforrás létrehozása self.sun = self.light.addlight() # Tulajdonságok beállítása self.sun.diffuse = [1.0,1.0,1.0,1.0] self.sun.lightintesity = 100 self.sun.coord.z = 4000 self.sun.setspot((0.0,0.0,-10.0), 10.0) # A fényforrás beillesztése a hierachia gyökerébe self.addelement(self.sun, "light_1") Szövegmező beállítása: # Új szövegmező a képernyő bal felső sarkától 10 pixel távolságra 62

68 Bemutatóprogram # és az 'fps' szöveget jelenít meg self.msg = Text.getInstance().addText(10, 10, "fps") Részecskerendszer létrehozása: # Részecskerendszer létrehozása 'first' néven, 10 részecskével és # a 'fust.bmp' tesztra asználatával self.particle = BaseParticleSystem("first", 10, "demo/.../fust.bmp") # Részecskerendszer hozzáadása a hierachiához self.addelement(self.particle, 'particle') A beállításokat követően már csak preload elején beállított eseménykezelőket kell létrehoznunk. Ezekben tetszés szerint elérhetjük a már létező objektumainkat. Példaként tekintsük meg az egér eseménykezelő metódusát: def mouseevent(self, event): # A kamerát az x temnegelye mentén elforgatjuk az egér y koordinátájának # utolsó értéktől való eltérésével self.cam.rotatex = event.delta[1] # Az előzőhöz hasonlóan, csak itt a kamera z tegelyét forgatjuk x-el self.cam.rotatez = -event.delta[0] 2. Sajátosságok Az Ilo elkezdése előtt, készítettem egy rövid összefoglalót melyben szerepeltek az ehhez hasonló Python alapú grafikuskönyvtárak és azok főbb jellemzői. Akkor még nem volt ennyi grafikusrendszer, amely csak és kizárólag a Pythonra építkezett. A kategória egyik régóta jelenlevő tagja a PyGame mely egy kifejezetten játékok fejlesztéséhez megírt és igen jó modul gyűjtemény. Viszont főként a 2D-s grafikára koncentrál és csak minimális 3D-s támogatást tartalmaz, illetve a játékok logika fejlesztését segítő részek is inkább az árkád és táblajátékokra van kihegyezve. Az Ilo fejlesztése és főként a megtervezése során csak a saját tapasztalataimra építkeztem és ezért is kerültek bele olyan technológiák és terminológiák amelyeket más rendszerekben már sikeresen alkalmaztak (pl.: objektumhierarchia, vagy az eseménykezelés). Az egyes részek implementálása során számtalan példakódot böngésztem át, viszont ezek csak az egyes modulok és magának a nyelvnek a jobb megismeréséhez adtak segítséget. Mindezek tükrében mondhatom, hogy az Ilo bár nem tartalmaz új technológiát vagy speciális eljárást, még is a maga nemében és összeállításában egyedül álló. 63

69 Bemutatóprogram 3. Képek a bemutató programból III. 4. ábra: Bemutatóprogram indítása III. 5. ábra: Balról spot megvilágítás (árnyékolással). Jobbról globális bevilágítás (árnyékolás nélkül) 64