Simulator multisenzorial pentru navigarea în universuri virtuale, bazat pe tehnologiile Realităţii Virtuale

1. Simulator multisenzorial pentru navigarea în universuri virtuale, bazat pe tehnologiile Realităţii Virtuale Programul CEEX, Modul I, 2006 INFOSOC, Contract 130/2006

2. ARIA TEMATICĂ ACRONIM: Sim-Space TITLUL PROIECTULUI Simulator multisenzorial pentru navigarea în universuri virtuale, bazat pe tehnologiile Realităţii Virtuale ARIA TEMATICĂ 3. Tehnologii informaţionale şi de comunicaţii 3.1. Piloni tehnologici ai ICT 3.1.6. Dispozitive de simulare, vizualizare, interacţie şi medii combinate: dispozitive PERIOADA DE DERULARE Octombrie 2006 - August 2008

3. CONSORŢIU Proiectul este implementat de un consorţiu constituit din universităţi, institute naţionale de CDI şi firme private, aflate în regiuni geografice diferite: SSIB SA Suceava (conducător de proiect) Universitatea „Ştefan cel Mare” Suceava Universitatea Tehnică „Gh. Asachi” Iaşi ITC SA Bucureşti IPA SA Bucureşti SIAT SA Bucureşti Data Invest Iaşi

4. OBIECTIVE Proiectul Sim-Space propune utilizarea tehnologiilor RV (Realitate Virtuală) pentru realizarea unui simulator multisenzorial dedicat instruirii prin experiment, sub forma imersiunii în trecutul istoric. Se implementează un pilot demonstrativ pentru simularea unor călătorii într-o cetate medievală din Moldova, utilizând tehnologiile RV (motoare de generare interactivă, asambloare de software, generatoare de medii grafice 3D, medii active, obiecte grafice sintetice) şi echipamente specifice (cască RV, tracker, mănuşă de date, scaun cu vibraţii).

5. DESCRIERE Elementele principale în conceperea şi elaborarea unui mediu virtual sunt: • componenta grafică 3D cu ajutorul căreia se realizează vizualizarea; • modelul mediului virtual împreună cu toate elementele care-l populează; • motor de control al deplasării entităţilor componente; • feedback în timp real din partea ambelor părţi participante în cadrul interacţiunii om-calculator; • motor de simulare/control al comportamentului entităţilor sintetice şi fenomenelor naturale desfăşurate în mediul curent

6. DESCRIERE Componentele şi funcţiile principale ale unui sistem de RV sunt: • procese de intrare - controlează dispozitivele utilizate în introducerea datelor: tastatură, mouse, trackball, joystick, trackeri de poziţie 3D & 6D (mănuşă, head tracker, costum, etc). • procese de simulare - recunoaşte entităţile componente mediului şi intrările care acţionează asupra lor; tratează interacţiunile, acţiunile scriptice ale obiectelor, simulările legilor fizice, reale sau imaginare, şi determină starea mediului. • procese de randare (redare) - procesele de randare ale unei aplicaţii de RV sunt cele care creează senzaţiile cele mai intense utilizatorului.

7. DESCRIERE Pentru realizarea functiunilor proiectului Simulator multisenzorial pentru navigarea în universuri virtuale, bazat pe tehnologiile Realităţii Virtuale (Sim-Space) s-a optat pentru următoarele soluţii de modelare, dezvoltare şi redare: • Software de modelare pentru obiecte şi scene 3D: Autodesk 3D Studio Max (datorită capacităţilor sale de modelare a obiectelor şi simulare a interacţiunii fizice între obiecte în interiorul scenei, dar şi datorită multitudinii de formate pe care le suportă, compatibilitatea între mediul de modelare şi cel de asamblare). • Plug-in pentru compatibilitate între mediul de modelare şi mediile de asamblare a obiectelor şi motorul de redare 3D: oFusion (permite exportul obiectelor create în 3D Studio Max către Ogre 3D în cele mai bune condiţii). • Pentru asamblarea obiectelor 3D: s-a optat pentru două soluţii: Blender şi Irrlicht (cele două soluţii lucrează foarte bine atât cu 3D Studio Max, cât şi cu motorul de redare Ogre 3D). Blender este un set integrat de instrumente care permit crearea unei game vaste de conţinut 3D. Irrlicht oferă posibilitatea proiectării bidimensionale pentru crearea interfeţelor utilizator şi este format dintr-un ansamblu de funcţii şi biblioteci scrise în C++. • Pentru motorul de redare 3D: Ogre 3D (Object-Oriented Graphics Rendering Engine - Motor de Redare Grafică Orientat pe Obiect). Ogre 3D este un motor de redare 3D orientat spre scenă şi foarte flexibil.

8. DESCRIERE Echipa de implementare a proiectului Sim-Space a realizat modelul experimental al pilotului demonstrativ, sub forma unui sistem integrat hardware&software, pentru simularea unor călătorii în cetatea virtuală medievală: Cetatea de Scaun medievală de la Suceava. Sistemul proiectat se adresează percepţiei subiectului, oferă acestuia accesul la o lume imaginară, sintetică, guvernată de legi şi reguli implementate prin algoritmii, modulele şi rutinele proiectului. S-au integrat în sistem fluxurile, interfeţele şi algoritmii conceptualizaţi în cadrul Etapei 2. Au fost elaborate tehnic şi conceptual funcţionalităţile care să asigure simularea unei călătorii virtuale în Cetatea medievală de la Suceava, configurată în timp în perioada domniei lui Ştefan cel Mare.

9. Utilizareatehnologiei GIS pentru reconstrucţia virtuală Au fost realizate două aplicaţii GIS bazate pe platforma NetSET proprie partenerului DATA Invest Iaşi, una referitoare la planul bidimensional al Cetăţii de Scaun a Sucevei conform unei schiţe arheologice realizate de arhitectul Romstorfer şi cea de-a a doua referitoare la relieful din zona înconjurătoare cetăţii, de asemenea în conformitate cu o schiţă a aceluiaşi arhitect austriac. Modelele 2D şi 3D obţinute pot fi utilizate pentru calibrarea dimensională a variantei de cetate reconstituită în spaţiul realităţii virtuale. Modelul 3D poate fi deocamdată exportat doar în format DXF.

10. Utilizareatehnologiei GIS pentru reconstrucţia virtuală

11. Utilizareatehnologiei GIS pentru reconstrucţia virtuală

12. Clasa Aplicaţie Clasa aplicaţie constituie punctul de pornire al oricărui proiect OGRE 3D. Trebuie să conţină un constructor şi un destructor care vor iniţializa, respectiv distruge cei doi membri esenţiali ai aplicaţiei, membrii Root – punctul de pornire al unei aplicaţii şi FrameListener - elementul de interfaţare utilizat pentru a recepţiona evenimentele ce apar la fiecare cadru: modificarea poziţiei sau orientării camerei, evenimente declanşate de maus sau tastatură etc. Toate elementele iniţializate prin constructor trebuie tratate la apelarea destructorului pentru a elibera spaţiul de memorie ocupat de acestea. Alături de Root şi FrameListener, membrii de bază ai unei clase aplicaţie sunt Camera, SceneManger şi Window.

13. Membrii Clasei Aplicaţie Membrul Rootconstituie punctul de plecare al oricărei aplicaţii client şi prin intermediul său o aplicaţie primeşte acces către fundamentele sistemului, şi anume: sistemul de redare disponibil, managementul configuraţiilor salvate, fişiere de tip jurnal (logging) şi să acceseze alte clase ale sistemului. Funcţionează ca o „centrală” prin care toate celelalte obiecte pot fi apelate. O instanţă de Root trebuie creată înainte ca orice altă operaţie OGRE să fie apelată. Este o clasă de faţadă şi oferă un punct convenabil de acces către toate subsistemele unei aplicaţii OGRE. Membrii clasei FrameListener, sunt singura modalitate prin care se poate apela propriul cod în timpul buclei de redare a OGRE atunci când este folosit un mod de redare continuă, cum ar fi de exemplu metoda startRendering().

14. Membrii Clasei Aplicaţie Pentru a putea vizualiza conţinutul unei scene este esenţial să dispunem o cameră. Camera constituie punctul de vedere din care scena va fi redată. Camerele OGRE suportă atât proiecţia de tip perspectivă (obiectele devin din ce în ce mai mici pe măsură ce camera se îndepărtează de ele; este implicită), cât şi cea de tip ortografică (stilul schiţă, blueprint, mărimea rămâne aceeaşi indiferent de distanţă). Camerele au diferite moduri de redare (de exemplu texturat, wireframe), câmp de vedere, distanţe de redare etc., permiţându-ne vederi complexe multi-fereastră, dacă acest lucru este dorit, permiţând şi împărţirea ecranului sau vederi de tip Picture-in-Picture (imagine în imagine). Camerele menţin propriile puncte de vedere, rata aspectelor şi sisteme de coordonate într-un spaţiu măsurat între -1 şi 1 pentru coordonatele x şi y şi 0 şi 1 pentru coordonata z. În timpul redării, camera va reda către un punct de vedere care va translata aceste coordonate parametrice în coordonate ecran. Este recomandat ca atât camera cât şi punctul de vedere care realizează translaţia să aibă aceeaşi rată a aspectului (de exemplu 4:3).De asemenea obiectele de tip cameră pot fi ataşate unor noduri din scenă, fapt ce se poate dovedi extrem de util pentru evitarea obiectelor dintr-un spaţiu ce comportă o geometrie.

15. Scenă redată în modul PM_POINTS

16. Scenă redată în modul PM_WIREFRAME

17. Scenă redată în modul PM_SOLID

18. Membrii Clasei Aplicaţie Membrul SceneManagerpermite administrarea unei scene, adică elemente precum obiectele şi potenţialele elemente de geometrie a scenei. Pentru a putea reda unul sau mai multe obiecte, primul dintre acestea trebuie ataşat managerului de scenă. Ulterior, celelalte obiecte pot fi ataşate fie unui alt obiect, creându-se o relaţie părinte-copil între cele două obiecte, fie direct managerului de scenă, rezultând o structură te tip arborescent în care managerul de scenă este nodul părinte. OGRE suportă managere de scenă simultane, camera decizând să afişeze scena aparţinând managerului de scenă care a instanţiat-o. Deşi majoritatea aplicaţiilor creează şi utilizează un singur manager de scenă la un anumit moment dat, utilizarea instanţelor multiple de manager de scenă se poate dovedi utilă, mai ales în momentul în care se doreşte optimizarea procesului de redare a unei scene mari şi încărcate, împărţind-o la mai multe managere de scenă, în funcţie de zonele care ar pute fi vizibile la un anumit moment dat.

19. Tipuri de manager de scenă • ST_GENERIC • ST_INTERIOR • ST_EXTERIOR_CLOSE • ST_EXTERIOR_FAR • ST_EXTERIOR_REAL FAR

20. Hărţile şi texturile necesare terenului Harta de înălţime Textura terenului Textura detaliată

21. Exemplu de fişier de configurare # Textura de bază pentru teren WorldTexture=Iarba3.jpg # Textura detaliată DetailTexture=Iarba2.jpg # În câte subdiviziuni de textură care intră într-o subdiviziune de teren DetailTile=3 # Sursa hărţii de înălţime PageSource=Heightmap # Textura hărţii de înălţime Heightmap.image=teren.png # Mărimea unei pagini în puncte PageSize=1025 # Mărimea subdiviziunilor TileSize=65 # Mărimea unei pagini e teren în unităţi ale lumii PageWorldX=14000 PageWorldZ=14000 # Înălţimea maximă a terenului MaxHeight=200

22. Scenă ce utilizează managerul de scenă de tip Teren, utilizând elementele prezentate anterior

23. Membrii Clasei Aplicaţie Membrul Window este parte esenţială în procesul de redare şi va fi instanţiat la începutul acestuia. Reprezintă suportul, „pânza” pe care se realizează redarea. Este o clasă abstractă, iar relaţia instanţelor acestei clase faţă de un sistem de redare care controlează redarea unei scene este de timp mai mulţi la unul, astfel încât mai multe ferestre pot fi implicate în redarea acestuia. De asemenea într-o fereastră pot exista mai multe puncte de vedere (viewports).

24. Metodele Clasei Aplicaţie Metodele de bază ale clasei aplicaţie sunt: • go(); • setup(); • setupResources(); • chooseSceneManager(); • createCamera(); • createViewports(); • loadResources(); • createScene(); • createFrameListener().

25. Metodele Clasei Aplicaţie Crearea scenei o vom realiza prin apelarea metodei createScene(). În interiorul acesteia vom pune la punct ultimele detalii legate de scenă (lumini, ceaţă, SkyBox sau SkyDome). // Culoarea fundalului mSceneMgr->setAmbientLight( ColourValue( 1, 1, 1 ) ); // Ceaţa ColourValue fadeColour(0.95, 0.9, 0.85); mWindow->getViewport(0)->setBackgroundColour(fadeColour); mSceneMgr->setFog(FOG_LINEAR, fadeColour, 0.0, 5000, 20000); // SkyDome mSceneMgr->setSkyDome(true, "Examples/CloudySky", 5, 8);

26. Metodele Clasei Aplicaţie După ce toate aceste detalii vor fi puse la punct se vor încărca obiectele în scenă. Prezentăm un scurt exemplu de cod necesar încărcării unui obiect în scenă alături de ilustrarea procesului de redare al acestuia. Entity *teren = mSceneMgr->createEntity( "Teren","Teren.mesh" ); SceneNode *nodteren = mSceneMgr-> getRootSceneNode()-:createChildSceneNode( "Teren" ); nodteren->attachObject( teren ); nodteren->scale( 50.0, 1.0, 50.0);

39. De la modelare la asamblarea în scenă În urma procesului de modelare cu ajutorul 3D Studio Max, obiectele vor fi salvate în fişiere de tip MAX. Pentru a putea fi încărcate în scena creată utilizând OGRE 3D, vom utiliza exporterul oFusion. Acesta va crea un fişier de tip mesh şi unul de tip material pentru fiecare mesh exportat. Utilizarea unor denumiri sugestive pentru obiectele MAX sau părţile lor componente este recomandată pentru a uşura gestionarea obiectelor.

40. De la modelare la asamblarea în scenă Fereastra exporterului oFusion

41. De la modelare la asamblarea în scenă Să luăm ca exemplu zidurile cetăţii. Scena conţine nu mai puţin de 314 mesh-uri. Pe lângă numărul mare de linii de cod şi gestiunea foarte dificilă a obiectelor încărcate, apare o problemă şi mai mare: poziţionarea acestora în scenă. În plus, trebuie să ţinem cont că aceste obiecte constituie doar o parte a scenei şi multe alte mesh-uri vor trebui încărcate. Pentru a evita astfel de probleme legate încărcarea unui număr mare de mesh-uri, lucru care ar necesita scrierea de cod suplimentar şi o gestionare foarte riguroasă a tuturor obiectelor sau de poziţionarea şi orientarea în scenă a acestora, vom ataşa (Edit mesh –> Edit Geometry –> Attach) toate mesh-urile obiectelor imobile ale scenei la un plan orizontal.

42. De la modelare la asamblarea în scenă Scena Zidurile Cetăţii – 314 mesh-uri

43. De la modelare la asamblarea în scenă Scena Zidurile Cetăţii – după ataşare

44. De la modelare la asamblarea în scenă Planul trebuie desenat într-o poziţie inferioară pe axa y celui mai de jos obiect ce va fi redat în scenă. De asemenea la poziţionarea pe axa y va trebui să ţinem cont de terenul ce va fi redat, astfel încât suprafaţa planului şi cea a terenului să nu se intersecteze şi în urma procesului de redare planul adiţional să apară în scenă. Astfel toate obiectele modelate individual vor se vor regăsi în aceeaşi poziţie relativă faţă de plan ca şi în faza de modelare, operaţiile de scalare, rotire sau mutare afectând întregul ansamblu ca pe un singur obiect. Ele vor constitui un tot unitar, aceste operaţii fiind aplicate tuturor obiectelor conţinute în mesh-ul comun.

45. De la modelare la asamblarea în scenă Pentru obiectele ce conţin texturi de reliefare (bump) vom avea nevoie de o linie suplimentară, introdusă manual, întrucât oFusion CE nu „exportă” (copie) decât fişierul imagine ce va reprezenta harta de reliefare, fără a o asocia în fişierul material: colour_op replace. În plus, pentru reliefare se pot utiliza mai multe texturi, având însă grijă ca ultima textură definită în cadrul respectivului material să fie textura de suprafaţă. În cazul în care dorim să utilizăm o textură pe subdiviziuni ale unei suprafeţe (tiling), putem utiliza instrucţiunea scale, parametrii fiind 1/n şi 1/m, unde n reprezintă numărul de subdiviziuni pe axa x, iar m numărul de subdiviziuni pe axa y.În cazul în care fişierul resources.cfg nu este modificat, fişierele obţinute în urma exportului cu oFusion vor trebui copiate după cum urmează: fişierele mesh în directorul OgreSDK\media\models, fişierele material în directorul OgreSDK\media\materials\scripts, iar fişierele pentru texturare în directorul OgreSDK\media\materials\textures.

46. De la modelare la asamblarea în scenă Bootstrap] Zip=../../media/packs/OgreCore.zip [General] FileSystem=../../media FileSystem=../../media/fonts FileSystem=../../media/materials/programs FileSystem=../../media/materials/scripts FileSystem=../../media/materials/textures FileSystem=../../media/models FileSystem=../../media/overlays FileSystem=../../media/particle FileSystem=../../media/gui FileSystem=../../media/DeferredShadingMedia Zip=../../media/packs/cubemap.zip Zip=../../media/packs/cubemapsJS.zip Zip=../../media/packs/dragon.zip Zip=../../media/packs/fresneldemo.zip Zip=../../media/packs/ogretestmap.zip Zip=../../media/packs/skybox.zip