1

Fakultet elektrotehnike i računarstva Sveučilište u Zagrebu

Danijel Pobi

Predmet Seminar

Ogre3D

kolovoz, 2011.

2

Sadržaj:

1. Uvod ...........................................................................................3

2. Uvodno o Ogre-u ........................................................................4

3. Uvodni koraci programiranja s Ogre-om ....................................8

4. Pregled dizajna Ogre-a ..............................................................12

5. Korištenje Ogre-a ......................................................................19

a. Inicijalizacija .....................................................................19

b. upravljanje scenom ..........................................................21

c. materijali .........................................................................25

d. animacije ..........................................................................29

6. Alati ...........................................................................................33

7. Zaključak....................................................................................36

8. Literatura ..................................................................................36

3

1. Uvod

Cilj ovog seminara je opisati osnovno rad i korištenje Ogre sustava

iscrtavanja. Zašto je preciznije redi sustav iscrtavanja a ne Ogre engine bit de

objašnjeno odmah u uvodu o Ogre-u. Nadalje pokušat du objasniti zašto je Ogre

postao toliko popularan naspram drugih sustava i zašto je jedan od najviše

korištenih open source sustava kad je riječ o programiranju grafičkih aplikacija.

Ukratko du objasniti osnovne značajke i po čemu je Ogre tako poseban naspram

drugih. Nakon toga dolazi najduže poglavlje, osnove korištenja Ogre-a i

njegovih najvažnijih dijelova. Za kraj seminara sljedit de kratki pregled nekih

dostupnih alata i dodataka za neke popularnije programske pakete koji se

odnose na Ogre.

4

2. Uvodno o Ogre-u

Ogre ili Object Oriented graphics rendering engine (objektno orijentirani

grafičko iscrtavački sustav) je točno to što njegovo ime govori, sustav za

iscrtavanje grafike u realnom vremenu. Najčešde se zove i Ogre 3D jer se radi o

trodimenzionalnoj grafici. Iako se može koristiti za 2D grafiku, zbog nedostatka

optimizacije nije prikladan, jer u pozadini radi sve u 3D-u, ali preko billboarda i

time zauzima znatno više resursa nego da se koristi neki 2D engine. Engine (ili

na Hrvatskom pokretački sustav) je zato što upravo služi da pogoni 3D aplikaciju

bez da se programer zamara previše s detaljima iscrtavanja, a više posveti

samom sadržaju aplikacije koja se radi. S relativno malo koda Ogre se

inicijalizira i pokrene sve potrebne stvari da bi se dogodilo samo iscrtavanje.

Ogre pod svojim „poklopcem“ ima implementiran sustav koji inicijalizira i

pokrene sve potrebno za odabrani API iscrtavanja (Directx ili OpenGL) koju su

implementirani u obliku plugin-a, ali o tome više kasnije. Ogre3D je obijektno

orijentiran u tom smislu da je dizajniran tako da sve gleda kao kolekciju

objekata koji međusobno surađuju, a ne kao sekvenca diskretnih zadataka.

Tipična simulacijska arhitektura uobičajeno korištena u igrama je prikazana

doljnjim dijagramom gdje je računalno sklopovlje apstraktirano aplikacijskim

slojem, a igračka/simulacijska logika koristi sustave aplikacijskog sloja za

vrijeme (Timer), pristup kontrolama(HID=Human interface diveces, hrv. uređaji

ljudskog sučelja) i pristup datotekama(File System).

Mreža Video

Aplikacijski Sloj

HID

Zvuk

Simulacijska Logika

Timer File System

5

Logički sloj sadrži pravila simulacije i održava simulacijska stanja, dijeluje na

unos dobiven iz aplikacijskog sloja i mrežnog sloja. Sva stanja se periodično

prezentiraju korisniku preko audio-vizualnog „pogleda“ na stanja. U ovom

prikazu Ogre3D je samo Video sloj, jer samo to i radi. Ne rukuje s unosom

korisnika, nema sustav rukovanja stanjima u igri, nema komunikaciju s mrežom,

ne svira nikakve zvukove itd.

Po dizajnu Ogre3D je samo biblioteka za iscrtavanje i to je jedina zadada koju

dobro obavlja. Ogre3D nije game engine baš zbog tih razloga. Da bi bio game

engine (poput XNA, Unreal, Unity, Tourqe,...), mora u svojoj jezgri sadržavati

podršku za mrežnu komunikaciju, ulaz-izlaz, zvuk, imati niz službenih alata, itd.

Te sve funkcionalnosti su na samom programeru da implementira po svojim

potrebama ili potraži neke druge biblioteke koje de koristiti uz Ogre3D (poput

OpenAL za zvuk, OIS biblioteka za korisničko sučelje, itd).

Na kraju ovog poglavlja, mali pregled značajki zbog kojih se Ogre3D toliko

koristi:

Puna i jednaka podrška za OpenGL i DirectX

o sadrži i mobilne verzije OpenGl ES 1 i 2 (korisno za mobilne

aplikacije u iOS i Android)

o Mobile DirectX nikad nije u potpunosti zaživio, ali radi dijelom

Puna podrška za mnogo operativnih sustava

o na računalima Windows, Linux i Mac OS X

o mobilni operativni sustavi iOS i Android

Jednostavan framework koji se jednostavno integrira u bilo koju

postojedu aplikaciju

Automatsko rukovanje iscrtavačkog sustavnog managmenta i hijerarhijski

culling

Modan i sofisticiran skriptni sustav koji omogudava da se neke stvari

mijenjaju i održavaju bez da se dotakne ijedna linija koda programa

Podrška za sve texturalne i blending tehnike, kao i podrška za GPU

tehnike i sve visoko stupanjske i asemblerske shading jezike poput Cg,

HLSL i GLSL

Podrška za širok niz formata slika i textura (png, tga, dds, tif, gif, jpg...)

Puna podrška za materijalne nivoe detalja

6

Optimiziran binarni mesh format sa manualnim i automatskim

generacijama nivoa detalja

Potpun pristup indeks spremnicima, deklaracijama vertexa (vrhova) i

spremnika mapiranja

Exporteri za vedinu alata za 3D modeliranje (npr. 3DS Max, Blender,...)

Puna podrška za skeletalnu i pose (vertex) animaciju i sofisticirano

blendiranje bilo kojeg broja višestrukih težina po vertexu

Podrška za sklopovsko i programsko ubrzani skinning

Hijerarhija je plug-in bazirana, čime se omoguduje da u zadanom

trenutku odaberemo najpogodniji hijerarhijski manager

Puna podrška za nekoliko tehnika sjenčanja (stencil, texture, additive,

modulative) i sve s punom podrškom za sklopovsko ubrzanje

Napredni čestični sustav

Jednostavno korištenje i podrška za tehnike iscrtavnja neba (skybox,

skyplane, skydome)

Automatsko upravljanje prozirnosti objekta

Podrška za file system, ZIP i PK3 arhivne tipove

Lista se može još protezati, ali mislim da nema smisla nabrajati baš sve

mogudnosti koje su uključene.

Ogre3D je projekt otvorenog tipa (open source), što znači da su svi njegovi

dijelovi besplatni za korištenje i korisnik čak može raditi izmjene na njemu po

potrebi. Pokrenut je 2001. godine kad je idejni začetnik Steve „Sinbad“

Steerting imao ideju da treba još jedan sustav isctavanja koji bi trebao biti

neovisan o strukturi scene. Tijekom godina, ovo nije projekt na kojem je radilo

mnogo ljudi (ukupno tijekom zadnjih 10 godina je radilo na ovome oko 20

programera, a jedino osnivač stalno) i nije komercijalan, što znači da tko god je

radio na ovome bilo je u svoje slobodno vrijeme i bez ikakvih naknada (blago

rečeno nije nikome ništa plačeno). Biti u ekipi koja radi na razvoju Ogre3D-a je

više stvar prestiža nego išta drugo.

Iako glavni jezik za korištenje Ogre3D-a je C++, ima nekoliko uspješnih

projekata gdje su se napravili „wraperi“ oko Ogre API-ja da se podrže jezici C#,

Java, Python, Ruby, itd. Ipak ti pokušaji nisu dio službenog Ogre-a i samim time

su u raznim stadijima stabilnosti i završenosti. Ogre se razvija i održava koristedi

7

ISO C++ standard i kompatibilnost s bilo kojim drugim jezikom nije ni u

razmatranju Ogre razvojnog tima. Time da bi se Ogre iskoristio u potpunosti,

potrebno je poznavati C++ i opdenito razumijeti obijektno-orijentiranu

paradigmu. Bez ovoga razumijeti Ogre bi bilo kao pokušavati shvatiti strani jezik

bez ikakvog razumjevanja pravila ili semantike jezika. Naravno, potrebno je

znati i kako raditi programe koristedi SDK i razvojnu okolinu. Uz to bit de

potrebno i osnovno poznavanje 3D grafike i osvjetljenja.

8

3. Uvodni koraci programiranja s Ogre-om

U originalu razvoj Ogre-a je počeo na 32-bitnoj Windows platformi, koja je

još uvijek glavna platforma za razvoj Ogre-a. To ne znači da su ostale platforme

zanemarene. Ogre ima nativnu podršku za OpenGL što znači da ga je mogude

koristiti na bilo kojem operativnom sustavu s OpenGL sklopovljem, iako

službeno nisu direktno podržane ne-Linux UNIX platforme. Ogre je bio uspješno

portan na Pocket-PC računala (Windows CE), ali s jako ograničenom

funkcionalnošdu. Danas, zahvaljujudi OpenGL ES podršci Ogre bez problema

radi na iOS i Android uređajima. Ima čak i uspješnih portanja na konzole poput

Xbox-a što i nije iznenađujude jer je u jezgri Xbox-a windows, a API je DirectX,

ali postojanje porta nije službeno zbog mogudih pravnih problema.

Poanta je da Ogre-ov dizajn odvaja logiku od platforme i omogudava direktno

i modularno dodavanje podrške za različito sklopovlje i operativne sustave.

Korišteni C++ jezik prati moderni ISO C++ standard, što znači da bi se s malo

truda trebalo portati na službeno nepodržanu platformu i bez nekog truda iz

prve raditi na podržanoj platformi.

Vedina programskih sistema je ovisna o drugim programima i SDK-ima za

vanjsku funkcionalnost. To omogudava sistemu da balansira s postojedom,

zajedničkom funkcionalnosti bez da se dupliciraju neki radovi i omogudava

projektantskom timu da se fokusira na specijalizirane detalje svog programa.

Ogre nema mnogo biblioteka o kojima je ovisan. Ipak ima minimalan, dobro

isplaniran i besplatan (što znači da je uključen u Ogre SDK) set biblioteka za

razne funkcionalnosti. To su:

FreeType za management fonta i renderiranje (www.freetype.org)

OpenIL (DevIL) što je biblioteka za manipulaciju slika (kompajliran

s više biblioteka da se objedini podrška za najčešde formate slika

poput jpeg,png,tiff,mng,...) (http://openil.sourceforge.net)

zziplib i zlib koje služe za kompresiju i upravljanje ZIP datotekama

To je što se tiče biblioteka koje su univerzalne za sve operativne sustave. Na

windowsima Ogre Direct3D podsistem zahtjeva da se ima instaliran DirectX

Runtime (koji je ionako dio svih novijih windowsa) ili ako se builda Ogre iz

9

izvornog koda, treba biti instaliran DirectX SDK. Ogre podržava HLSL i GLSL GPU

jezike sjenčanja i hardverski neovisan Cg API (Cg nije ovisan samo o NVIDIA

grafičkim čipovima, potrebne biblioteke dolaze u paketu s Ogre SDK).

Za programirati s Ogre-om je najbolje preuzeti ved kompajlirani Ogre SDK, jer

raditi s source kodom je dosta komplicirano i ne preporučuje se osim ako

nedete raditi izmjene na njemu. Ved kopmajlirani SDK je optimiziran i dovoljan

za 99% korisnika Ogre-a. Za naprednije korisnike koji žele skinuti izvorni kod a

to je mogude napraviti skidanjem s službenog SVN-a više verzija. Na SVN-u se

nalaze uz starije verzije dvije aktualne verzije, a to su stabilna koja se koristi za

izradu SDK-a i nestabilna verzija koja je trenutna verzija u razvoju.

Pokazat du na primjeru Visual Studia kako se Ogre instalira i sprema za

korištenje. Instalacija OgreSDK u verziji 1.7 na više je puno lakša nego prije i

sastoji se od 3 koraka:

1. Skidanje OgreSDK s interneta. Sve što je potrebno je odabrati verziju s

obzirom na verziju IDE-a koji se koristi:

download OgreSDK sa www.ogre3d.org/download/sdk

10

2. Otpakirati Preuzeti paket na željenu lokaciju

ekstraktiranje OgreSDK

3. Postavljanje OGRE_HOME enviroment varijable, koja koristi da bi se

pokazala lokacija Ogre direktorija. To se jednostavno napravi pomodu

komandne linije (setx komanda za Win 7/Vista, a set za win xp)

postavljanje enviroment varijable

Sljedede sad, samo radi provjere da je sve dobro instalirano, može se buildati

i pokrenuti „Sample browser“ set primjera koji dolazi s Ogre-om. Sam Visual

Studio projekt se nalazi u direktoriju OgreSDK-a pod imenom „OGRE“. Ako je

sve uspješno, buildanjem i pokretanjem bi trebali dobiti u konadnosti ovaj

prozor:

11

Ogre Sample Browser

Od ostalih razvojnih okolina, samo du spomenuti da postoje ved spremni SDK-

ovi za brzu integraciju u Xcode na Mac računalima, MinGW i paketi za Ubuntu

PPA. Za sva ostala razvojna okruženja trenutno jedino riješenje je buildati

source kod prema potrebi.

12

4. Pregled dizajna Ogre-a

Brzim pregledom na listu klasa i metoda Ogre-a može se vidjeti koliko je Ogre

opsežan i kompliciran. Sredom Ogre je obijektno orijentirana biblioteka klasa i

njegov sofisticirani hijerarhijski dizajn omoguduje da se s njim radi na puno

jednostavnijoj bazi samo onoga što je potrebno (mogude je napraviti aplikaciju

s Ogre-om u nekih stotinjak linija koda). Ogre pruža objektno orijentirane

metode pristupa obradi proceduralnih podataka i time iscrtavanje jednostavnih

geometrijskih primitiva na metu iscrtavanja (međuspremnik ekrana koji se

prikazuje na ekranu). Uobičajno kad se koristi OpenGL ili Direct3D za iscrtavanje

objekata treba pratiti niz koraka proceduralnog toka rada, drugim riječima

postaviti niz stanja iscrtavanja pozivima API-u, poslati razna geometrijska stanja

s mnogim pozivima API-a i redi API-u i GPU-u da iscrtavaju s drugim pozivima

API-ja. S objektno orijentiranim pristupom u iscrtavanju geometrije nema

potrebe da se koristi čista geometrija nego je potpuno maknuta i time sve što je

potrebno napraviti je definirati pokretne objekte, statične objekte koji čine

geometriju svijeta, svijetla, kameru i sve što je potrebno. Nema poziva API-u,

nego se samo stave objekti u scenu, a Ogre se brine o svemu ostalom. Tako se

može manipulirati scenom intuitivnijim metodama nego da se koriste čiste

transformacijske matrice. Sustav renderiranja apstraktira korišteni API (OpenGL

i DirectX) u jedinstveno sučelje do njihove funkcionalnosti. Funkcionalnost grafa

scene je apstraktirana u drugom sučelju tako da se mogu razne implementacije

grafa scene jednostavno korisiti. Na sličan način je mnogo stvari apstraktirano

poput objekata za iscrtavanje bili oni statični ili pomični.

Graf scene je odvojen od sadržaja scene i to je jedna od najbriljantnijih, ali i

ujedno najmanje cijenjih mogudnosti u dizajnu Ogre-a. Tradicionalne metode

spajaju sadržaj scene i graf scene u hijerarhiju koja prisiljava podklasiranje

sadržajnih klasa u čvorove grafa scene, što je u dosta slučajeva loš dizajn jer ne

dozvoljava izmjenu algoritma grafa scene bez da se prave promjene sa svim

dijelovima hijerarhije. Ogre s grafom scene postupa na razini sučelja, bez

pretpostavke i znanja kakav algoritam grafa scene je implementiran. Sučelje

grafa scene jedino brine o strukturi grafa. Čvorovi nemaju nikakvu ulogu

upravljanja, nego Ogre to pritisde dolje u ono što zove „renderable“ (iscrtljivo?)

13

iz čega se svi dijelovi geometrije scene stvaraju. Svojstva iscrtavanja (također

zvana materijali „materials“) za ove iscrtljive objekte se sadrže u Entity objektu

koji sadrži SubEntity objekt. Ovi SubEntity objekti su u biti iscrtljivi objekti. Da bi

se to lakše razumilo, ovdje je slika relacija grafa scene i sadržaja:

Sva geometrija i svojstva iscrtavanja su pristupačna grafu scene preko

MovableObject sučelja. Ogre omogudava korisniku da na čvor scene poveže

korisnički definiranu kontrolu poput dodataka za audio i sl. Ništa se ne treba

apstraktirati, samo se stvori jednostavno sučelje koje de graf scene prepoznati

da bi se moglo na njega nadovezati.

Plug-In Arhitektura je također jedna od glavnih značajki Ogre-a. Ogre

korisniku ne forsira određen API iscrtavanja, nego svaki API je upakiran kao

plugin za ogre da korisnik može odabrati šta mu najviše odgovara. Ne radi se

samo o API-u iscrtavanja, nego graf scene je sučelje i svaka implementacija

14

algoritma grafa scene je jedan plugin koji se može i tijekom izvođenja zamjeniti

ovisno o željenoj primjeni. Primjer je da imamo scenu u zatvorenom i tu nam

treba graf scene koji je dobar za zatvorne prostore, a kad izađemo iz

zatvorenog prostora na otvoreno, treba nam implementacija za velike prostore.

Glavna prednost plug-in arhitekture je da se ne moraju Ogre biblioteke

ponovno bildati da bi novi plug-inovi radili. Plug-inovi se jednostavno učitavaju

tijekom izvršavanja programa tako da se samo definira o kojoj vrsti plugina se

radi i koja mu je namjena.

Sklopovski podržano ubrzanje iscrtavanja je podržano u osnovici i

programsko ubrzanje nije opcija, tako da Ogre zahtjeva grafički procesor koji

podržava bilo koji od podržanih API-a. To omoguduje Ogre-u da slobodno radi

u otimiziranom modu s sklopovskim međuspremnicima (memorija dijeljena

između grafičkog sklopovlja i aplikacije). Time se mogu u potpunosti iskoristiti

napredna sklopovska ubrzanja uključujudi programibilne shadere. Ovakva

razina integracije programibilnog grafičkog cijevovoda (graphics pipline) i Ogrea

stavlja Ogre u poziciju gdje je usporediv s mnogim komercijalnim 3D sustavima

poput Unreal Enginea ili CryENGINE-a. Iako neke napredne stvari (poput

globalnog osvijetljenja Ambient Occlusion) ostaju na programeru da

implementira, ali pošto se ionako vedina toga radi „offline“, tj. ne u realnom

vremenu, to i nije neki nedostatak. Trenutno su podržanani Direct3D (do verzije

9 u potpunosti, verzija 10 je preskočena i samo nekoliko malih stvari je

implementirano, a sad se radi na verziji 11, dok mobile DirectX nikad nije

službeno napravljen) i OpenGL (do verzije 4 i OpenGL ES verzije 1 i 2).

Fleksibilni red iscrtavanja je napravljen da bi se lakše iscrtavali dijelovi scene.

Standardni proces iscrtavanja tipično ide ovako: terena i/ili geometrije svijeta,

pokretni obijekti, efekti, overlayi, zatim pozadina i/ili nebo. U ovakvoj tipičnoj

implementaciji teško je promjeniti redosljed iscrtavanja i to ponekad rezultira

kodom koji je teško održavati i ima nefleksibilan dizajn. Ogre tu nefleksibilnost

riješava uvođenjem redova iscrtavanja. Ogre jednostavno iscrtava sadržaj kako

je u redu. Sljededa slika pokazuje redosljed iscrtavanja gdje se stvari s manjim

prioritetom prvo iscrtaju tako da budu u pozadini (npr. sama pozadina scene),

dok stvari s velikim prioritetom se zadnje iscrtavaju i najčešde su najbliže (npr.

HUD=heds up display s trenutnim rezultatima ili izbornik aplikacije).

15

Prednost u fleksibilnosti ovakvog dizajna je što korisnik može promjeniti

prioritete iscrtavanja kako mu odgovara u određenom trenutku ili cijeli red

jednostavno isključiti.

Robustan sustav materijala omoguduje da se promjene unutar scene

naprave bez da se takne linija koda. Ogre sadrži skripte materijala koje se

sastoje od jedne ili više tehniques (tehnika) koje su kolekcija pass-ova (prolaza).

Pass se odnosi na prolaz iscrtavanja, a to je jedinica po kojoj se materijal

iscrtava unutar Ogre-a. Može se imati koliko se hode prolaza, ali treba paziti jer

svaki prolaz uzrokuje sasvim novu operaciju iscrtavanja (čim više prolaza, sporiji

rad). To uzrokuje pad performansi, ali ponekad je to jedino riješenje da se

dobije željeni efekt. Najbolja stvar ovog sustava je nastavak u slučaju pogreške,

gdje se od nabrojanih tehnika, automatski odabire teknika koja je podržana s

trenutnim sklopovljem. Drugim riječima sustav de pretragom prema dolje

odabrati koja tehnika mu najbolje odgovara. Također unutar skripte je podrža

shema (schemes) skripte, koju je najbolje opisati kao nivo detalja na razini

materijala (npr. napraviti shemu koja de koristiti tehnike samo podržane na

novim grafičkim karticama, dok imati i shemu sa jednostavnim efektima za

stare grafičke). Iako je i materijale mogude definirati u samom kodu, ovo je

mnogo elegantnije jer se izmjenama ne mora ponovno kompajlirati cijeli kod i

time se rastavlja stvaranje sadržaja aplikacije s samim radom aplikacije.

Optimizirani geometrijski i kosturski format je korišten za Ogre-ov sustav

„*.mesh“ i „*. skeleton“ podatke. To je binarni prikaz podataka (znači ne mogu

se vidjeti čisti podaci o vrhovima ili bilo čemu ostalom u tekstualnom editoru) i

16

kao rezultat toga Ogre podržava samo takav format modela koji je dosta

efikasan u učitavanju. To je zbog ved unaprijed optimiziranog izgleda binarnih

datoteka u eksporteru koji ih je napravio. Više o eksportanju modela u zadnjem

poglavlju o alatima. Optimiziranje binarnog formata je primarno u redovanju

vrhova poligona, geometrije i podataka kostiju, ali i u pravljenju nivoa detalja i

kreiranju tangenti za mreže poligona. Generiranje ovoga prije korištenja uklanja

potrebu da se generiraju tijekom izvođenja programa, čime se smanjuje

vrijeme učitavanja potrebnog objekta.

Višestruki tipovi animacija podržani u Ogre-u su: skeletal (kosturska), morph

(izobličenje) i pose (poze). Skeletalna animacija se odnosi na spajanje vrhova

na kosti u kosturu i popularno se naziva skinning (guljenje kože?). Na svaki vrh

može utjecati do 4 nezavisne kosti s određenim težinskim faktorom. Ovo je

korisno za prikazivanje realističnih deformacija vrhova npr. u aproksimaciji

pokreta ljudskog tijela gdje efekt pomicanja ruke ima utjecaj na deformaciju

mišida na ramenu. Skeletalna animacija je podržana keyframingom i tipično

Ogre exporteri je generiraju tijekom eksportiranja iz modelerskog alata. Morph

animacija je animacijska tehnika na razini vrhova gdje se spremaju apsolutne

lokacije vrhova (početne i krajnje) i interpolira između zadanih pozizcija tijekom

izvođenja programa. Razlikuje se naspram pose animacije po tome da sprema

odmake vrhova umjesto aplosultne pozicije i time se višestruke pose trake

mogu interpolirati da naprave jednu jedinstvenu animaciju. Morph je puno

ograničenija od pose animacije jer ne može se spajati s drugim morf

animacijama zbog aplosutnih pozicija vrhova. Pose i morph animacije se mogu

koristiti u paru s skeletalnom animacijom. Sve animacije se mogu izvoditi

programski ili na grafičkom sklopovlju koristedi vertex program. Ogreov

animacijiski sistem radi na principu kontrolera. On interpolira između ključeva u

animacijskoj traci.

Da bi se moglo nešta raditi s Ogreom ne mora se biti upoznat sa svim

aspektima Ogre API-a. Najčešde programer ima samo nekoliko ključnih dijelova

s kojima mora interaktirati u tipičnoj Ogre aplikaciji. Sljedi kratak pregled

ključnih dijelova, a u sljededem poglavlju de biti riječi kako se koriste:

Root Object (korijenski objekt) je glavna polazišna točka svake Ogre aplikacije

i pruža pristup svim podsistemima u Ogre aplikaciji. Konstrukcijom root objekta

aplikacija se pokrede, a njegovom destrukcijom se gasi.

17

ResourceGroupManager je jedinstveni objekt koji na kraju krajeva upravlja

sa svim resursima koje Ogre treba da bi iscrtao neku scenu. Ogre prepoznaje

sljedede vrste resursa:

Mesh: binarni optimizirani format za učitavanje mreže poligona.

Spremaju se kao individualne datoteke s .mesh ekstenzijom da ih Ogre

prepozna i asocira. Također sadrže podatke potrebene za pose i morph

animaciju.

Skeleton: tipično se referenciraju na .mesh datoteke i definira se u njima

hijerarhija kostiju. Također sadrže keyframe podatke potrebne za

skeletalnu animaciju. Spremaju se s .skeleton ekstenzijom često zajedno

s .mesh datotekama na koje se referenciraju.

Materijal: je skriptna datoteka na koju se referencira .mesh datoteka ili

se ručno postavlja u kodu. Najlakše ih opisati kao upute kako obojati

mesh na koji se referenciraju. Najčešde ih stvara exporter iz alata za

modeliranje, a sadrže .materijal ekstenziju. Nije binarni format, tako da je

lako čitljiv bilo kojim tekstualnim editorom.

GPU program: GPU programi (HLSL, GLSL, Cg) su prepoznati s .program

ekstenzijom. Programi niskog levela koriste .asm ekstenziju.

Teksture: 2D teksturalni podaci mogu biti u bilo kojem formatu

podržanom preko OpenIL slikovne biblioteke.

Compositor: Ogreov Compositor framework koristi Compositor skripte

na isti način kao što materijali koriste .materijal skripte. Razlika je jedino

što imaju .compositor ekstenziju.

Font: Ogre koristi datoteke za definiciju fonta koje de koristiti u

overlayima i te datotoeke koriste .font ekstenziju.

Svaki od ovih tipova resursa ima svoj posebni ResourceManager

(MaterialManager,FontManager,...), ali ako programer ne radi zaseban novi

plugin za novu vrstu resursa, nede biti potrebe za raditi s ResourceManager-

om. ResourceManager je odgovoran za traženje resursa po imenu, nema

direktan memoriski pristup managera koji se koristi za zadanu grupu resursa,

nego samo rukuje s ved učitanim resursima koje učitaju onda podređeni

manageri. Sljedi pregled nekih čestih managera u Ogre-u:

18

SceneManager: je s razlogom prvi jer je jedan od najvažnijih. Građen je

na principu grafa scene i služi za strukturiranje scene. On je izvor

SceneNode objekta koji su strukturalni elementi Ogre-ovog dizajna grafa

scene (predstavlja čvor u grafu scene). Sadržaj se spaja na čvor preko

Entity objekta (koji predstavljaju lišde u grafu scene), a sam Entity objekt

je implementacija MovableObject klase. Entity objekt se najčešde učitava

iz memorije gdje postoji kao binarni .mesh file, ali je mogude i stvoriti

ručno objekte kao ravnine i ostale primitive. Sami Entity objekti se ne

kredu kroz scenu, nego su čvorovi na koji se vežu Entity objekti ti koji se

kredu u sceni. Na čvorove je mogude spojiti i druge objekte poput kamere

i svijetla.

LogManager: Jednostavno samo sprema poruke rada sistema da se

mogu pratiti eventualne greške.

DynLibManager: služi za komunikaciju s dinamičkim bibliotekama i

centralni je za Ogre-ov plug-in dizajn.

PlatformManager: pruža apstraktni pristup detaljima sklopovlja i

operativnog sustava, npr. timerima i prozorima

ArchiveManager: služi za upravljanje arhivama na sistemu

ParticleSystemManager: upravlja detaljima i implementacijama raznih

čestičnih sustava, emitera i afektora.

MaterialManager: održava sve učitane materijalske instance u aplikaciji i

omogudava korištenje materijala na bazi imena.

SkeletonManager: upravlja svim učitanim skeleton instancama

MeshManager: upravlja svim meshevima učitanim.

HighLevelGpuProgramManager: upravlja, učitava i kompajlira sve

vosokostupanjske GPU shader i vertex programe korištene u aplikaciji

FontManager: upravlja i učitava sve korištene fontove

OverlayManager: upravlja učitavanjem i kreacijom 2D overlaya klase

koja se tipično koristi za izbornike ili prikaze trenutnih rezultata.

TextureManager: upravlja svim teksturama u aplikaciji

Iako ima još managera, ovo je bio kratak pregled nekih najčešde korištenih.

Na korisniku je dali de koristiti gotove implementacije ili zahvaljujudi plug-in

arhitekturi, može napraviti svoje.

19

5. Korištenje Ogre-a

Sada, po mom mišljenju ide najzanimljivije poglavlje, korištenje Ogre-a. Jedna

od najznačajnijih stvari kod Ogre-a je njegova fleksibilnost gdje se može birati

stupanj kontrole koji želite imati. Ali idemo krenuti od početka...

a) Inicijalizacija:

Prvo što je potrebno napraviti u bilo kojoj Ogre aplikaciji je stvoriti instancu

Root objekta. Konstruktor Root klase prima nekoliko opcionalnih parametara, a

sve su imena datoteka:

Root *root = new Root(); Root *root = new Root("plugins.cfg"); Root *root = new Root("plugins.cfg","ogre.cfg"); Root *root = new Root("plugins.cfg","ogre.cfg","ogre.log"); Root *root = new Root("","");

Sve gornje metode su ispravne. Parametri se predaju da se ne mora mnogo

ručnog koda pisati. Datoteke koje se navode kao parametri su u biti skripte

(osim .log) koje sadrže sve potrebne postavke inicijalizacije. Ne moraju biti tog

istog imena, ali ime je tako navedeno da se shvati bit. Datoteku ogre.log ne

treba posebno objašnjavati, tu se samo logiraju događanja u Ogre-u.

Datoteka plugins.cfg sadrži informaciju o plug-inovima koji de se učitati,

odnosno o modulima koje učitavamo. Ti moduli su najčešde pakirani u obliku

.dll biblioteka. Primjer plugin datoteke:

PluginFolder=. Plugin=RenderSystem_Direct3D9 Plugin=RenderSystem_GL Plugin=Plugin_ParticleFX Plugin=Plugin_OctreeSceneManager Prva linija kaže Root klasi gdje treba da traži pluginove koji de biti učitani (u

ovom slučaju direktorij s izvršnom datotekom). Nakon toga jednostavno

nabrajamo pluginove koje želimo učitati. Mogude je to i ručno u kodu napraviti i

to na sljededi način:

root->loadPlugin("RenderSystem_Direct3D9.dll");

root->loadPlugin("Plugin_OctreeSceneManager.dll");

20

Prototip je jednostavan, samo moramo metodi dati koju točno biblioteku da

učita i to je to (.dll za windowse, a .so na Mac OS i Linux) . Na sličan način

možemo i odčitati, odnosno osloboditi resurse koje zauzme jedan plugin

jednostavnim pozivom root->unloadPlugin i na isti način samo damo ime

plugina koji treba osloboditi.

Datoteka ogre.cfg sadrži postavke iscrtavanja.

Render System=Direct3D9 Rendering Subsystem [Direct3D9 Rendering Subsystem] Allow NVPerfHUDD=No Anti aliasing=None Floating-point mode=Fastest Full Screen=No Rendering Device=ATI MOBILITY RADEON HD2600 Vsync=No Video Mode=800 x 600 @ 32-bit colour

Za osnovne stvari ako datoteka ved nije napravljena, može se koristiti Ogre-

ov ugrađeni dialog za odabir postavki pozivom na root->showConfigDialog() i

jednostavnim odabirom opcija, datoteka se automatski izgrađuje.

Nakon što smo osnovne stvari napravili, vrijeme je da se inicijalizira prozor za

iscrtavanje. Prozor se inicijalizira pozivom na metodu root->initialize. Initialize

metoda instruktira root da dovrši svoju inicijalizaciju i stvara prozor za

iscrtavanje. Da bi scena koju iscrtavamo bila vidljiva, treba se napraviti kamera.

Kamera se radi preko SceneManager sučelja, a ide otprilike ovako:

Camera cam= SceneMgr->createCamera("MainCam"); cam->setPosition(Ogre::Vector3(100,15,100)); cam->lookAt(Ogre::Vector3(100,15,-300)); cam->setFarClipDistance(1000); cam->setNearClipDistance(0.1); cam->setAspectRatio(1.33333333);

U ovom primjeru SceneMgr pokazivač je postojeda instanca SceneManager klase o kojoj de biti govora kasnije. Nakon kreiranja kamere, postavljaju se njena svojstva. Sljedede što treba napraviti je stvoriti viewport (gledište) na prozoru za iscrtavanje. To se radi na sljededi način: Viewport *vp=window->addViewport(camera); vp->setBackgroundColour(ColourValue(0,0,0));

Ovaj kod stvara gledište na prozoru koji smo prije inicijalizirali pomodu initialize() metode u Root klasi. Druga linija postavlja boju pozadine da bude

21

crna. Najlakši način da se u Ogre-u vrši iscrtavanje, tj. počne je pozivom metode Root->StartRendering(). To uzrokuje da Ogre iscrtava sadržaj koji ima u sceni. Ogre ipak prije poziva za početak iscrtavanja zahtjeva da se Root klasi doda FrameListener (osluškivač okvira?) klasa. Frame listener je u biti sučelje klase koju treba implementirati. class myFrameListener: public FrameListener{ public: bool frameStarted(const FrameEvent &evt); bool frameEnded(const FrameEvent &evt); }; //dodavanje frameListener klase u Root: root->addFrameListener(myListener); root->startRendering();

Implementacija metode frameStarted() se poziva svaki put prije nego se jedna slika iscrta, dok se frameEnded() metoda poziva nakon što je iscrtana slika. Tipično se u frameStarted metodu ubacuje logika simulacije i/ili igre, dok u frameEnded ubacuje rukovanje s unosom (npr. miš, tikovnica).

b) Upravljanje scenom

Kako je ved spomenuto nekoliko puta, za upravljanje scenom Ogre ima klasu

SceneManager. Njegova inicijalizacija je relativno jednostavna:

SceneManager* SceneMgr=root->createSceneManager(ST_GENERIC,"MySceneManager");

Tijekom učitavanja Ogre-a, ima mnogo pluginova, a među njima su i razne

implementacije SceneManagera. Prvi parametar kaže o kakvom Scene

Manageru se radi. ST_GENERIC kaže da se radi o minimalnoj implementaciji

SceneManagera koji nije optimiziran, ali je jako koristan za scene minimalne

kompleksnosti. Npr. BSPSceneManager se registrira kao ST_INTERIOR jer je

pogodan za rad sa zatvorenim prostorima, a TerrainSceneManager kao

ST_EXTERIOR_CLOSE. Generalno gledano SceneManager je odgovoran za

slijedede zadade:

Stvaranje i pozicioniranje pokretnih objekata, svijetala i kamera u

sceni na način da im se efikasno pristupa u grafu scene

Učitavanje i slaganje geometrije svijeta

22

Odbacivanje nevidljivih objekata i stavljanje vidljivih objekata u red za

iscrtavanje

Organiziranje i sortiranje svijetala

Postavljanje i iscrtavanje sjena u sceni

Postavljanje i iscrtavanje svih ostalih objekata u sceni poput pozadine

i neba

Prosljeđivanje ovog organiziranog sadržaja sustavu iscrtavanja za

iscrtavanje

Gavni razlog zašto Ogre ima više različitih tipova scena je dijelom u njegovom

plugin dizajnu i tome što se mogu učitati različiti manageri da se koriste po

potrebi. Npr. ako u simulaciji prostora imamo zatvorene prostore, zatim izlazak

na otvoreni prostor i u takvim slučajevima najbolje je koristiti scene manager

optimiziran za taj tip geometrije svijeta. S Ogre-om dolazi Octree Scene

manager koji pruža dva tipa: OctreeSceneManager i TerrainSceneManager.

OctreeSceneManager je manager opde namjere i može se koristiti za bilo kakvu

vrstu scene. U drugu ruku TerrainSceneManager je tipični primjer managera za

rad s heightmap (visinska mapa) terenskim scenama. Heitmap je jedna tekstura

gdje vrijednost boje znači visina terena.

Najčešda upotreba SceneManagera je u kreiranju pokretnih i nepokretnih

objekata kao svijetla, kamere, entiteta, čestičnih sustava, bilboarda, skyboxova,

statične geometrije, geometrije svijeta, itd. Sve što u sceni može postojati je

upravljano scene managerom, znači on je odgovoran za stvaranje, dohvadanje i

uništavanje objekata u sceni.

Kako je ved spomenuto, SceneManager je odgovoran za stvaranje i

upravljanje čvorovima (Scene Node) grafa scene. čvor grafa scene može imati

samo jednog roditelja a može imati nijedno ili više dijece koja mogu biti ili drugi

čvorovi ili objekt klase MovableObject koji de se iscrtati. Tijekom inicijalizacije

SceneManager klase korijenski čvor je automatski kreiran, a to je korijenski čvor

koji je jedini koji nema roditeljski čvor i može se redi da je on predak svih

čvorova u sceni. Korijenski čvor se ne može uništiti (osim uništavanjem cijelog

managera). Pogodan je da se na njega veže statična geometrija svijeta, jer iako

je pomičan, nema skoro nikakvog razloga da se miče, pa bi trebao biti smatran

kao nepokretan.

23

Hijerarhija čvorova se stvara dodavanjem dijece na postojedi čvor u grafu

scene. Manager ne stavlja sadržaj ili podatkovne objekte u scenu kad se stvori,

nego se to treba ručno raditi. Obijekt se može prispojiti čvoru u bilo koje

vrijeme i u bilo kojem stanju. Također je mogude prispojiti više objekata na

jedan čvor, ali nije mogude jedan objekt pripojiti više od jednom čvoru. Važno

je razumjeti da se transformacije (translacija, rotacija i skaliranje) rade na

čvorovima, a ne na samim objektima. Iako je koristedi parametre

transformacija, rotacija i skaliranja jednostavnije, podržano i klasično računanje

transformacijskim matricama. Transformacije na određenom čvoru mogu se

gledati na dva načina, a to su iz globalne i lokalne perspektive. Sve se

transformacije odnose u usporedbi s čvorom, a razlika je u tome što globalna

transformacija gleda naspram korijenskog čvora, dok lokalna transformacija

gleda naspram roditeljskog čvora.

Ogre je desni koordinatni sustav, što znači da smjer Z-osi se dobije

vektorskim umnoškom X i Y osi. Naspram 3ds Max programa (kojem je vertikala

Z-os), Ogre vertikalnu os smatra Y osi, x os raste u desno i time dubina je Z os

koja kako se udaljavamo ide u negativne vrijednosti. Na sljededoj slici je kocka

dužine stranice 1 s središtem u ishodištu:

24

Pokretni objekti u sceni su stvoreni u SceneManageru, u njemu se i

pridodaju čvorovima i manager ih po potrebi uništava. Pokretni objekti ne

moraju biti spojeni na graf scene, ali ako nisu spojeni ne mogu se iscrtati. Ved

sam spomenuo da jedan pokretni objekt može biti povezan na samo jedan čvor

u grafu. Iscrtljivi pomični objekti poput mesheva (mreža poligona) sadrže samo

geometriju i informacije o materijalima, ali nikako ne mogu sadržavati ikakvu

informaciju o strukturi grafa scene. Pokretni objekti ne moraju imati geometriju

ili podatke o materijalima, a najbolji primjer toga su kamere i svijetla.

Najbolji način kako demonstrirati neke stvari je primjerom stvaranja

jednostavne scene:

void createScene(void) {

// Postavljanje ambijentnog svijetla mSceneMgr->setAmbientLight(ColourValue(0.5, 0.5, 0.5)); // Stvarnje točkastog svijetla Light* l = mSceneMgr->createLight("MainLight"); l->setPosition(20,80,50); // Učitavanje mesha Entity *ent = mSceneMgr->createEntity("head", "ogrehead.mesh"); // Postavi materijal učitan iz Example.material ent->setMaterialName("Examples/EnvMappedRustySteel"); // Dodavanje entiteta na čvor mSceneMgr->getRootSceneNode()->createChildSceneNode()->attachObject(ent);

}

Rezultat je scena koja izgleda ovako:

25

Od ostalih mogudnosti SceneManagera mogli bi jedino spomenuti sljedede

funkcionalnosti:

Učitavanje geometrije terena

Pravljenje skyplane-a (nebeska ploča), skybox-a (nebeska kutija) i

skydom-a (nebeska kupola)

Definiranje i upravljanje maglom

Raditi upite na sceni, u biti je provjera koji prostor koji objekt zauzima

o ograničavajuda kutija poravnata s osima

o sferno

o Volumno ograničeno ravninom

o Linijsko

o arbitrarno sjecište

Raycasting (bacanje zrake)

Naravno da postoji još mnogo toga, ali ipak za naprednije stvari je najbolje

konzultirati se s službenom dokumentacijom radi više detalja.

c) Materijali

Materijali jednostavno rečeno definiraju kako de objekt kojemu je dodjeljen

reagirati na svijetlost. Osnova za čak i kompleksne materijale je boja. Ogre je po

tome tipičan i podržava četiri vrste boja za opis materijala, a to su ambijentna,

difuzna, emisivna i spekularna. Materijali se najčešde definiraju u alatu za

modeliranje, a tijekom eksporta eksporter izrađuje skriptu materijala najčešde s

direktnim preslikavanjem 1:1. Uz osnovne boje danas korišteno grafičko

sklopovlje podržava bar jednu ili više teksturnih jedinica. Riječ tekstura nije

samo fino ime za 2D sliku, nego može predstavljati i drugačije informacije

poput visinskih mapa, kubičnih ili volumskih mapa, površinskih mapa, itd.

Koristedi teksturnu mapu efikasno se „omota“ 3D objekt s 2D slikama i pikseli

slike de se ili kombinirati ili zamjeniti difuznu komponentu primarnih boja za

opis materijala.

Materijal sadrži jednu ili više tehnika koje sadrže jedan ili više prolaza. Samo

jedna tehnika je aktivna u isto vrijeme. To znači da u sljededoj shemi ako je

Tehnique 0 aktivan, ostale se ne koriste.

26

Tehnique (tehnika) u biti predstavlja alternativni način iscrtavanja objekta u

kojoj se mogu napraviti sheme i definirati nivoi detalja materijala (korisno da se

ne učitavaju velike teksture koje ionako nede biti vidljive), ali što je i važnije,

napraviti specijalizirane tehnike optimizirane za sklopovlje koje de se koristiti.

Pass(prolaz) je potpuno atomsko iscrtavačko stanje za dani iscrtljivi objekt u

zadanoj operaciji na GPU-u. Jedan iscrtljiv objekt se referencira na jedan

materijal, a kako je ranije spomenuto, Ogre odabire tehniku iz tog materijala

koja de se koristiti. Pass također referencira definiciju teksturne jedinice

potrebne za izvršavanje pass-a. Teksturna jedinica (texture unit) u Ogre

materijalu je u biti texture sampler na GPU-u i sadrži referencu na jednu

teksturu. Teksture se tipično nalaze u video memoriji sve dok više nisu

potrebne.

Sintaksa skripte materijala je relativno slična C jeziku. Nije komplicirana za

razumjet i dosta je jednostavno čitati i konstruirati material skriptu.

Najjednostavnije je primjerom vidjeti kako izgledaju skripte i kako se koriste.

Najjednostavnije skripta koja se može napraviti bez ikakvih komplikacija bi

izgledala nekako ovako:

27

material VerySimple {

technique { pass { diffuse 0.5 0.5 0.5 } }

}

Ali ipak na jednostavnim primjerima je skoro nemogude vidjeti sve i naučiti se

kako koristiti skripte. Zato sljededi primjer je material skripta korištena gore na

Ogre glavi kod kreiranja jednostavne scene:

material Examples/EnvMappedRustySteel {

technique { pass { texture_unit Diffuse { texture RustySteel.jpg } texture_unit Environment { texture spheremap.png colour_op_ex add src_texture src_current colour_op_multipass_fallback one one env_map spherical } } }

}

Prva stvar koju treba primjetiti je definirano ime materijala

Examples/EnvMappedRustySteel. Iako izgleda kao put prema sistemskoj

datoteci, to nije slučaj. Sve što je desno od ključne riječi material je ime

materijala, koje mora biti unikatno. Kod prolaza prva teksturna jedinica je

tekstura samog objekta. Druga teksturna jedinica predstavlja sfernu okolnu

mapu (enviroment map). Enviroment mapping nije skupa operacija za

dobivanje reflektivnog dojma površine bez korištenja raytracing-a (pradenje

zrake). Ova teksura se blenda s teksturom specifiranom prije nje. U nastavku su

slike tekstura, mesha bez materijala i mesha sa gornjom skriptom materijala:

28

RustySteel.jpg speremap.png

mesh bez materijala mesh sa materijalom

Skriptiranje materijala za programibilni grafički cijevovod (pipeline) je malo

kompliciranije. Za ubacivanje GPU programa u materijal treba napraviti tri

stvari, a to su: napisati sam program, deklaraciju programa i referencu na

program u samom materijalu. Opisati korištenje ovoga nije jednostavan

zadatak i po mom mišljenju to bi mogao biti zasebni seminar, pa nedu ulaziti u

to. Reči du samo da su podržane sve vrste GPU programa ukoliko ga sklopovlje

podržava.

29

d) Animacije

Ved sam pokrio nešta osnovno o animacijama u pregledu dizajna Ogre-a, a

sad demo udi malo detaljnije u njih. Na funkcionalnoj razini Ogre podržava dva

načina manipulacije objektima, a to su keyframed animacija i drugi tip je preko

kontrolera. Na najvišem apstraktnom nivou animacija u Ogre-u je kolekcija

traka koje su setovi podataka spremljeni kao funkcije vremena. Par vremenska

točka i vrijednost trake stvaraju keyframe. Ogre podržava sljedede tipove

animacijskih traka:

NumericAnimationTrack: keyframeovi sadrže jednu skalarnu vrijednost

AnyNumeric (struktura, tj. tip podatka) tipa

NodeAnimationTrack: keyframe sadrži tri vektora i quaternion koji

predstavljaju poziciju, skalu i rotaciju čvora u danom trenutku

VertexAnimationTrack: keyframe sadrži ili referencira poziciju vrha u

danom vremenu

Animation State (animacijsko stanje) je posrednik interakcije između

aplikacije i animacije u Ogre-u. U alatu za modeliranje se definiraju višestruke

animacije na vremenskoj ravnini, a kao dio eksportiranja različitim vremenskim

intervalima možemo zadati ime. U kodu koristimo to ime da bi se referencirali

na točno određenu animaciju, a objekt vrada animacijsko stanje koje pruža

pristup sljededim parametrima:

Length: dohvat duljine animacije u sekundama

Current position: dohvat ili postavljanje trenutne pozicije u sekundama

od početka animacijskog segmenta

Animation name: ime animacijskog intervala

Looping: provjera ili postavljanje hode li se animacija vrtiti u krug, tj, dali

kad završi krede ispočetka ili potpuno staje

Enabled: provjera ili postavljanje dali je animacija omogudena

Weight: u slučaju blendanja koliki utjecaj ima ova animaciju u tome

U animacijsko stanje dodajemo vrijeme kako bi se animacija nastavila izvoditi

ili oduzimamo vrijeme kako bi išla unazad. Dodaje se uvijek razlika u vremenu

(delta vrijeme) ili oduzima ako želimo da animacija se vrti unatrag.

30

Skeletal Animation se još najviše koristi od svih animacijskih tipova u Ogre-u.

U ovoj vrsti animacije, vrhovi u meshu se povezuju na kosti koje čine kostur.

Kosti u pravom smislu te riječi ovdje ne postoje, nego to su samo matrične

palete i zato pravo tehničko ime ove vrste animacije je matrix palette skining.

Skeletalna animacija radi tako da računa poziciju vrha kao funkciju

transformacijske matrice koja predstavlja kost. Keyframe-ovi u skeletalnoj

animaciji su jednostavno relativni pomaci od kostiju u obliku pozicije,

orijentacije i skale. Skeleton (kostur) u Ogreu definira hijerarhiju sličnu

čvorovima u grafu scene tako da sve kosti imaju roditelja osim korijenske i na

slični način funkcioniraju kad su u pitanju transformacije. Kostur se može

gledati analogno ljudskim zglobovima (pošto jedna kost predstavlja jednu

točku). da bi se vrhovi modela micali kad se kost u kosturu pomakne, oni

moraju biti vezani za kost i to se zove vertex binding (vezanje vrhova). Vrhovi

mogu biti vezani za više kosti, a pomicanje s obzirom na svaku kost se određuje

težinskim faktorima. Tom metodom možemo simulirati npr. savijanje mišida u

tijelu tako da svaki vrh vežemo za nekoliko kostiju s određenim težinskim

faktorom.

Vertex Animation (animacija vrhova) se odnosi na činjenicu da umjesto

animacije kostiju u kosturu i računanje pozicija vrhova kao funkcije tih kostiju,

stvarna pozicija vrhova se animira. Zato ova metoda animacije zahtjeva najviše

resursa jer treba stalno čuvati cijelu kopiju svih podataka animiranih vrhova za

svaki morph tarhet ili pozu u animaciji. Iako vrlo zahtjevno, to je ponekad jedini

način da se dobije željeni efekt pogotovo u animaciji ljudskog lica. Animacija

vrhova referencira cijeli set vrhova na bazi sve-ili-ništa. To znači da na nivou

mesha, sva dijeljena geometrija mesha čini podatke o vrhovima, što znači da se

nemože imati nekoliko vrhova da sudjeluju u recimo morph animaciji, a

nekoliko u pose animaciji. Vertex animacija ima dvije vrste, a to su morph

animacija i pose animacija. Morph animacija je najjednostavniji i najdirektniji

od ta dva tipa. Stvarne pozicije vrhova se spremaju za sekvencijalni „snapshot“

(brzo okidanje?) i zovu se morph targets u morph animaciji. Pozicija vrhova

mesha u sceni se podešavaju i spremljeni keyframe sadrži apsolutnu poziciju

svakog vrha u animiranom meshu. Ova metoda zahtjeva dosta resursa jer svaki

keyframe sadrži kompletnu kopiju podataka vrhova, ali lagano se radi

animacijski proces jer je to jednostavna stvar računanja pozicija između

početne i krajnje. Glavni nedostatak ove vrste animacije je jer se nemogu

31

kombinirati s više morph tarhet animacija u jednu, jer spremljene pozicije

vrhova su apsolutne što čini spajanje podataka različitih animacija skoro

nemogude. (npr. dvije trake da pokušaju animirati istu ruku). Pose animacija

značpi da različite poze modela su spremljene u animacijske trake. Ove poze se

mogu spajati ili blendati da stvore kopliciraniju i realističniju animaciju nego što

je mogude bez blendanja. Najveda razlika između mor4ph animacije je u tome

da se pozicije vrhova spremaju kao pomak od normalne neutralne poze i samo

podaci vrhova na koji se mijenjaju se sprema. To rezultira tome da pose

animacije je fleksibilnija, zahtjeva manje resursa i efikasnija od morph

animacije. Sljededi niz sličica pokazuje različite poze spremljene u isti mesh, a

kompleksnija animacija se dobiva blendanjem između više poza.

neutralan sretan tužan ljut

Blendanje animacija je često korišteno za stvaranje komplicirane animacije u

sceni. Jedina iznimka je da se ne mogu blendati pose i morph animacija

zajedno, ali sve ostale mogu. Kad se blendaju vertex i skeletalna animacija

zajedno Ogre prvo računa(ili blenda) vertex animaciju prvo, zatim na to dodaje

skeletalne deformacije na blendane vrhove. Glavni i najbitniji primjer blendanja

više različitih animacija je animacija ljudi. Tijelo čovjeka je najbolje animirati

skeletalnom animacijom, dok lice s pose animacijom. Blendanje dviju animacija

je također najbolji način da se naprave promjene s jedne animacije na

drugu(npr. promjena sa trčanja na hodanje se radi blendanjem obje vrste

animacija u jednu).

Sve spomenute animacije se mogu izvoditi na dva načina, a to su programski

(na CPU) i sklopovski ubrzana (na GPU pomodu GPU vertex programa).

Sklopovski ubrzana animacija pruža mogudnost da sami kontroliramo red

blendanja, ali to znači da se moraju i stvoriti kompleksni GPU programi i

32

naravno onda se ne mogu spajati s programskom animacijom. Za korištenje je

puno jednostavnija programska animacija, jer za sklopovski ubrzanu animaciju

moramo paziti na specifikaciju korištenog GPU (npr. moja HD2600 grafička

podržava samo 120 kostiju po skining prolazu) i naravno treba dobro poznavati

odabrani jezik GPU programa i njegove mogudnosti. Na kraju valja samo

napomeniti da iako sklopovski ubrzana animacija je teža za svladati, ali zato je

puno efikasnija.

Ovdje sam nabrojao i pokazao kako se koriste neke od najbitnijih

mogudnosti. Iako ih ima mnogo više, i ovisno šta se treba, mislim da bi bilo

dobro spomenuti neke važnije stvari koje nisam pokrio, a to su:

Upravljanje resursima (resource manegement) koji podrazumjeva

inicijalizaciju, učitavanje, uništavanje resursa i pristup i upravljanje

arhivama

Render targets (mete iscrtavanja) gdje se detaljno proučava prozor

iscrtavanja (render window), gledišta (viewport), iscrtavanje tekstura i

materijala, klase iscrtavanja, itd

Billbordi i čestice sa definicijama billborda, setova i lanaca, kao i

definiranje čestičnog sustava pomodu billboarda, emitera čestica,

afektora i načini na koji se to sve iscrtava

Dinamične sjene sa pregledom tehnika sjenčanja koje se koriste u Ogre-u

poput stencil shadowing, texture shadowing, modulative shadow

blending i additive shadow masking

2D i compositing gdje se proučavaju overlayi, Compositor framework,

Compositor Chains i kako se sve to koristi.

33

6. Alati

Koliko god dobar i modan bio ogre, beskoristan je ako nema šta iscrtati. To

nešta što se iscrtava, je uobičajeno stvoreno u drugim programima ili je Ogre-u

predočeno preko nekih formalnih sredstava, što znači da postoje alati koji

pripremaju digitalni sadržaj koji Ogre može koristiti. Pošto Ogre čita jedino svoj

binarni mesh/animacijski format, to znači da za svaki 3D alat koji se koristi,

moramo imati eksporter koji de pretvoriti podatke geometrije, materijala i

animacija u Ogre-ov format. Sljedi kratki pregled alata za koje ogre ima

eksportere:

Blender je potpuno besplatan alat za 3D modeliranje. Eksporter za

blender podržava u potpunosti Ogre-ov mesh format, materijale i

animacije (skeletal, morph i pose). Dio je službenog alata, pa se tako sa

svakom verzijom blendera osvježava

Softimage|XSI je prvi komercijalni program koji je prepoznao vrijednost

Ogre-a, njegove zajednice i pruža direktnu podršku Ogre-ovom timu za

stvaranje eksportera za njihov XSI paket modeliranja.

3D Studio Max je sad u vlasništu Autodeska i jedan je od najkorištenijih

alata za 3D modeliranje u svijetu. Iako je ponuđena podrška za službeno

stvaranje alata za export, napravljeni su službeni exporteri, ali samo za

ranije verzije, dok novije verzije (od 2008 na dalje) nemaju službeni

eksporter

Milkshape 3D je jedan od najjeftinijih komercijalnih 3D alata na tržištu i

dosta je omiljen kod nekih modelera zbog jednostavnosti upotrebe.

Time zbog njegove jednostavnosti i popularnosti postoji službeni

eksporter

Maya je u svoje vrijeme bio jedan od najkorištenijih programa. Iako je

sad isto kao i 3ds max u vlasništvu Autodeska nije toliko popularan kao

3dsmax. Službeni eksporter postoji, ali ima istu sudbinu kao i 3ds max-ov

Mod Ogre-a ipak nije u čekanju da se službeni eksporteri i alati naprave, nego

neki članovici Ogre zajednice aktivno razvijaju i održavaju alate za neke

popularne programske pakete. Sljedi pregled nekoliko najpopularnijih:

34

Alias|Wavefront Maya ima neslužbene eksportere koji su u raznim

stadijima spremnosti, pogodni za 90% zadataka. Nemaju samo

mogudnosti nekih naprednih eksportanja materijala

oFusion je eksporter za 3ds Max koji je prvo razvijen za jednu tvrtku, ali

je postao jedan od najkorištenijih neslužbenih alata. S podrškom za GPU

shadere, eksportanje cijele scene i niza naprednih mogudnosti, postao je

najbolji eksporter uopde. Jedina šteta je što ne podržava verije 2010 na

dalje

OgreMax je ipak najkorišteniji neslužbeni alat za eksport. Popularnost

može zahvaliti time što ne samo da eksporta podatke, nego može služiti

za eksportanje cijele scene u .scene format i time se može cijela scena

automatski učitati u Ogre.

Google SketchUP je sam google razvio sa svojim 3D alatom. Sam

sketchUP je jako jednostavan alat koji se može praktički bez ikakvog

tehničkog znanja koristiti

Za stvaranje digitalnog sadržaja i opdenito kontrolu imamo sljedede

programe:

Particle Editor koji je fleksibilni, modni i najjednostavniji način za kreirati

čestične sustave i skripte preko jednostavnog grafičkog sučelja. Ovo je

stvarna Ogre aplikacija, tako da je u realnom vremenu mogude gledati

stvoreni čestični sustav.

Mesh Viewer je jednostavna aplikacija koja služi samo da bi se učitao i

prikazao objekt i animacije za stvarnu Ogre aplikaciju, bez da se učitaju u

stvarnu aplikaciju.

ATI RenderMonkey Exporter služi za eksportiranje shader programa iz

ATI-evog (Sad AMD-ovog) okruženja za razvoj GPU shader-a. Eksporter

pretvara RenderMoneky podatke u Ogre-ovu material skriptu.

Važni službeni dodaci za Ogre su sljededi:

COLADA koja je bila važna inicijativa u 3D grafičkoj industriji. To je trebao

biti format koji bi univerzalno bio podržan sa strane svih alata u obliku

XML sheme, ali nije bio opde prihvaden u cijeloj industriji. COLADA plugin

je razvijen prema specifikaciji 1.3.1 i očekuje se da de se dalje razvijati.

35

Paging Scene Manager je Ogreov Scene Manager plugin dizajniran da

omogudi efektivno iscrtavanje velikih terena mapiranih heightmapama.

Upravlja nivoima detalja terena i jako je pogodan za simulacije leta i

opdenito simulacije velikih terena.

Streaming Video razvijen je s Theora bibliotekom i namjena mu je

videosadržaj iscrtati umjesto teksture. Zato se naziva i videoplugin.

Također da bi svaka simulacija (ili igra) bila potpuna, treba efikasan način

računanja fizike. Ogre nema službenu biblioteku za rad s fizikom, ali zato ima

niz komercijalnih i nekomercijalnih biblioteka koje u suradnji s Ogre-om rade

bez ikakvih problema, čak se i vežu na entity instancu i omoguduju jako realan

prikaz i računanje fizike. Slijede najvažnije biblioteke:

OgreODE je besplatna biblioteka s svom funkcionalnosti komercijalnih

proizvoda. Biblioteku održava jedan član Ogre-tima u suradnji s ogre

zajednicom.

NxOgre je komercijalana biblioteka i komercijalno se zove Novodex.

Licencu je kupila Agei-a, koju je kasnije kupila NVIDIA. Još Ageia je

integrirala podršku za svoj PhysX procesor i time omogudava sklopovsku

obradu fizike ako sustav ima sklopovlje za to (bilo individualnu PhysX

karticu ili sad neku noviju NVIDIA grafičku karticu).

OgreNewt je također jedna od besplatnih biblioteka koja se redovno

razvija i održava.

Nekoliko skriptnih jezika je povezano direktno na ogre. Pošto je popis dosta

dugačak i sami jezici su u različitim fazama stabilnosti i završenosti, samo du

spomenuti nekoliko najčešdih:

PyOgre korišten za spajanje s Pythonom

OgreDotNet za spajanje s .NET Frameworkom (C# je kompletniji, dok VB

je dosta nestabilan)

Ogre4J za povezivanje s Javom

36

7. Zaključak

Ogre je nizom ovih godina postao jedan jako modan i cjienjen sustav za

iscrtavanje sa obilnom podrškom i velikom bazom korisnika. Također valja

napomeniti da jedan od glavnih razloga njegove popularnosti je velik niz

platformi koje podržava i time smanjuje potrebno vrijeme koje treba uložiti da

bi se program mogao koristiti na drugom operativnom sustavu. Važno je i

napomenuti da je ogre toliko kompleksan, a opet toliko jednostavan da se

može koristiti za sve mogude projekte gdje se zathjeva bilo kakav 3D grafički

prikaz. Zbog niza mogudnosti, pogodan je i za animaciju i simulaciju

kompleksnih stvari poput animacije ljudi, životinja, itd.

S ovakvim tempom u podržanim platformama, kao i veliki broj ljudi koji se

trude doprinjeti (službeno i neslužbeno) Ogre-u, sigurno je da Ogre nije jedna

od onih biblioteka koje, kako se naprave da se ne održavaju i ne rastu s

trenutnim zahtjevima na tržištu. Same činjenice da Ogre radi na iOS uređajima,

android uređajima i da se radi DirectX 11 podrška su dokaz da je ovo ozbiljni

sustav koji de i dalje rasti i razvijati se.

8. Literatura

1. Pro Ogre 2D Programming, Gregory Junker, Apress, 2006.

2. http://www.ogre3d.org

3. Ogre API reference manual (dolazi s SDK)

4. http://www.ogre3d.otg/tikiwiki/Home (tutoriali, upute, alati,...)

5. http://www.ogre3d.org/forums/ (forumi sa svime što se u gornjim materijalima ne može nadi o Ogre-u)