Realizarea Unui Magazin Virtual 3d
Introducere
Tehnologia computerului produce o mutatie esentiala asupra notiunii de realitate, mutatie care poarta numele de virtualitate. Computerul mijloceste aparitia unui nou tip de realitate, realitate experimentata in cadrul unui spatiu virtual, spatiu care nu se mai supune legilor realului obisnuit, ci legilor proprii. Noul tip de realitate a fost denumit realitate virtuala („Virtual Reality“ – VR), oximoronul avind rolul de a evidentia faptul ca virtualitatea este, in fapt, un nou tip de realitate.
Sintagma a facut cariera in literatura tehnoculturala, stirnind controverse, generind utopii sau distopii, promovind profetii sau critici. Pentru unii cercetatori de specialitate, denumirea de „realitate virtuala“ are incarcatura poetica, gratie asocierii tehnologie-arta-filozofie, sau chiar semnificatie mistica, prin intermediul discursului cybervizionar. O observatie neutra ar putea explica sintagma „realitate virtuala“ prin recursul la tehnologia computationala, ce mediaza constituirea unui spatiu greu de definit, care fie fascineaza, fie ameninta, dar care in orice caz este imposibil de ignorat si, mai mult decit atit, influenteaza perceptia asupra realitatii insesi. Fie ca apare sub denumirea de „synthetic environment“ (in domeniul militar), fie ca e preferata sintagma „virtual environment“ (la MIT sau NASA) sau sintagma „virtual world“ (la The Human Technology Laboratory de la Universitatea Washington din Seatle), realitatea virtuala s-a constituit intr-o disciplina specifica.
Datorita originii sale multiple (contracultura, fictiune a SF cyberpunk, NASA/ domeniu militar, arta pe computer, design si industrie computeristica), realitatea virtuala poate fi studiata din diverse perspective, de unde rezulta atit complexitatea teoretica, cit si aplicabilitatea bogata a domeniului. Diversi futurologi anticipeaza perfectionarea tehnologiei virtualitatii, tehnologie care in prezent are un potential limitat de construire de spatii, si avantajele desprinderii de constringerile lumii fizice. Alti teoreticieni, critici ai tehnologiei virtuale, depling disparitia spatiului real ddin cauza invaziei negative de virtualitate digitala.
Lucrarea de fata isi asuma o pozitie de mijloc intre aceste doua extreme, urmarind sa chestioneze filozofic raportul dintre realitate si virtualitate (realitate virtuala), deopotriva ca spatiu literal-tehnologic si ca spatiu imaginar. De asemenea, eseul nu recurge la disocieri de genul realitate vs. realitate virtuala, natural vs. artificial, prezenta vs. absenta, realitate vs. irealitate, ci la juxtapuneri de tipul realitate si virtualitate, natural si artificial, prezenta si absenta, realitate si irealitate etc.
Inainte de a sintetiza trasaturile realitatii virtuale sub forma conditiei virtualitatii, trebuie avut in vedere faptul ca statutul realitatii a constituit dintotdeauna subiectul unei profunde meditatii filozofice. Realitatea exista obiectiv, indiferent de perceptia simturilor umane sau este o proiectie subiectiva a acestora? Este realitatea doar ceea ce exista fizic si material sau gindurile, visurile, fictiunile umane constituie o realitate care-si cere drepturile ontologice? Disputele filozofice tematizind realitatea s-au orientat in principal fie spre idealism, fie spre realism, fie spre subiectivism, fie spre obiectivism.
Incepind cu anticii greci, filozofia si-a pus intrebari in legatura cu existenta mai multor tipuri de realitate. Binecunoscuta teorie a lui Platon discuta trei modele de realitate: realitatea ideilor (adevarata realitate), realitatea fizica obisnuita (copia primului tip de realitate) si realitatea artei (copia de gradul al doilea). De-a lungul istoriei filozofiei, notiunea de realitate a capatat diferite sensuri: de la ideea de realitate-substanta si de realitate secunda a ideilor la Aristotel pina la ideea de realitate divina si de realitate terestra in acceptiunea religioasa a Evului Mediu, de la realitatea simtirilor si realitatea intelectului la Descartes pina la realitatea stiintifica a modernitatii si la realitatea simulacrului in postmodernitate. Bineinteles, modificarea intelesului conceptului de realitate este mult mai complexa decit cea enumerata pe scurt aici, insa eseul de fata se opreste doar asupra ultimei teorii care prefigureaza notiunea de realitate virtuala a spatiului computeristic, si anume teoria simulacrului.
Conceptul de simulacru de la care se revendica conditia realitatii virtuale este bidirectionat in sens baudrillardian si in sens deleuzian. Simulacrul, in acceptiunea lui Baudrillard, este caracteristic erei hiperrealitatii in care simularile prolifereaza hiperstazic transformind realul in hiperreal: virtualitatea simularii inlocuieste realitatea si, la limita, notiunile de real si simulacru sint deopotriva rezultatele unor simulari succesive. Eseul de fata consuna cu cea de-a doua directie a teoretizarii simulacrului: Deleuze diferentiaza intre copie si simulacru, neacordind originalului statut privilegiat asupra copiei; originalul sau realul contine in sine posibilitatea simularii, astfel incit simulacrul (dislocat, nomadic si heterogen) inseamna deopotriva original sau real si simulare sau copie. Pentru Deleuze, virtualul nu se opune realului, ci actualului: ideea de virtual este discutata ca si multiplicitate si diferenta pentru a se putea actualiza. Actualizarea virtualului trebuie disociata de realizarea posibilului deoarece procesul de actualizare a conditiei virtuale nu se incheie niciodata, ci este un proces deschis, spre deosebire de realizarea posibilului care dezvolta si sfirseste un model deja existent.
Daca conditia posibilului se epuizeaza in fiecare realizare, virtualitatea cumuleaza o multitudine de actualizari posibile.
Tehnologia computerului aduce un interes deosebit in conditia virtualitatii. Virtualul devine identificat cu sinteticul sau artificialul numeric si se raporteaza ambivalent fata de real. Virtualitatea computerului contine in sine ideea de potentialitate care se poate actualiza in diverse moduri, astfel ca tehnologia digitala infirma formularea unei singure interpretari a virtualului drept inlocuire a realului. Virtualitatea spatiului computerizat coexista cu realitatea, precum actualizarea acestuia coexista cu posibilitatea. Interpretind tehnologia informationala ca producere a virtualului, si nu ca reproducere a realului, virtualitatea computerului poate reconstrui permanent o noua realitate. Realitatea virtuala se constituie in cele din urma ca spatiu (tehnologic, filozofic, artistic) care nu neaga realitatea fizica, precum simulacrul teoretizat de Baudrillard, ci coexista acesteia. Chiar daca computerul are capacitatea artificiala de a crea spatii virtuale care pot concura cu realitatea (asa-numita inducere de realism in cazul simularilor scolilor de soferi sau de piloti), realitatea ramine separata de virtualizare, nepierzindu-si statutul ontologic propriu. Realitatea poate fi dublata de virtualitate, fara a putea fi insa inlocuita de aceasta.
Termenul de realitate virtuala a fost creat de catre Jaron Lanier in 1987 si prefigurat in acceptiunea sa de imersie 3D de catre Morton Heilig in 1963 prin realizarea sistemului „Sensorama“.
Insa inceputurile realitatii virtuale se datoreaza lui Ivan Sutherland care, in 1966, a produs primul sistem de afisare montat pe cap (Head-Mounted-Display), destinat sa introduca privitorul intr-o lume 3D simulata vizual. La inceputul anilor ’70 Myron Krueger realizeaza „Metaplay“ sau „Videoplace“, mostre de arta interactiva telematica in care participanti aflati in locatii diferite impart aceleasi spatii digitale virtuale. Un alt exemplu de sistem al realitatii virtuale il constituie CAVE (Cave Automatic Virtual Environment) creat in 1991 de Daniel Sandin, Thomas DeFanti, Carolina Cruz-Neira. Acest sistem-camera plaseaza corpul utilizatorului/locuitorului direct in interiorul spatiului generat de computer. Din cadrul acestor exemple diacronice de evolutie a domeniului rezulta trasaturile realitatii virtuale: simulare digitala in timp real de spatii virtuale, interactiune a utilizatorului cu imaginile in perspectiva a bazelor de date, imersie a simturilor si a corpului fizic uman, teleprezenta.
O data cu raspindirea Internetului, termenul de realitate virtuala a inceput sa se suprapuna notiunii de cyberspatiu (cyberspace), concept utilizat la inceput ca jargon in literatura SF cyberpunk (fiind creat de William Gibson in 1984) si detinind trasaturi ale realitatii virtuale experimentate in laborator: un tip de realitate 3D a bazelor de date, realitate generata de tehnologia computerului in urma interactiunii, a imersiei si a teleprezentei. Pe de o parte, cyberspatiul evolueaza atit din jocurile video si programele grafice ale computerelor, cit si din spatiile virtuale ale simularilor. Pe de alta parte, cercetatorii realitatii virtuale experimenteaza previziunile tehnologice ale fictiunii SF. Astfel ca termenii de realitate virtuala si de cyberspatiu se refera la „realitati“ desfasurate simultan si partial autonom: experientele de laborator se dezvolta paralel cu literatura cyberpunk si cu World Wide Web-ul, insa nu fara a se influenta reciproc.
Cyberspatiul poate fi analizat sub diverse aspecte, ca si spatiu-interfata, spatiu de date (dataspace) sau spatiu al fluxurilor informationale navigabile, spatiu-retea, spatiu liminal, spatiu mental etc., conceptul cumulind o serie de paradoxuri: realitate fizica si realitate mentala, materialitate si imaterialitate, referentialitate topologica solida si retea lichida. Interpretat fie ca surogat al spatiului real prin construirea de interfete 3D si harti, fie ca spatiu cu o noua topologie geografica, cyberspatiul este deopotriva un spatiu real al tehnologiei si conceptual al metaforei, in care se imbina deopotriva tehnologia si mitologia, realitatea si imaginatia.
Unul dintre aspectele generarii cyberspatiului il constituie spatializarea sub forma de interfata: dincolo de suprafata ecranului computerului se presupune a exista cyberspatiul. Producerea adincimii 3D a spatiului digital este in fapt o iluzie electronica a adincimii obtinute pe o suprafata plata, iluzie produsa de dependenta computerului de modelul 2D al ecranului rectangular.
Computerul aduce adincimea la suprafata ecranului prin tehnica topografiei 3D care incearca sa ajunga dincolo de vizibil, in adincime, pentru a face invizibilul vizibil. Adincimea, devenita ea insasi un fenomen de suprafata al ecranului computerului, provoaca aparitia atit a discursului nostalgic dupa notiunea de adincime ca detinatoare a adevarului, a esentei, a ascunsului si a misterului, cit si a discursului catastrofic al pierderii referentialitatii in favoarea unei virtualitati inselatoare. Pe de alta parte, asistam la valorificarea interfetei computationale: designerii GUI (Graphical User Interface) fructifica raportul suprafata-adincime al interfetei prin accentuarea primului termen: adincimea 3D a imersiei in iconurile cyberspatiului este aplicata suprafetei ecranului computerului.
Ca spatiu al informatiei, cyberspatiul este puternic metaforizat: superautostrada a datelor pe care se poate calatori sau ocean informational pe care se poate naviga. Intr-o viziune de ansamblu, cyberspatiul se vizualizeaza ca o densa masa de date in care nu se pot izola parti sau locuri de intregul spatiului. Aceasta imagine holista este o aparenta provocata de faptul ca cyberspatiul nu are o forma identificabila, fixa si clara si datorita caracterului sau presupus infinit. De fapt, cyberspatiul Internetului are propria geografie, o geografie a fluxurilor si nodurilor informationale, devenind un spatiu-retea hibrid si multinodal. Din aceasta perspectiva, cyberspatiul nu are o natura fizica, ci se prezinta ca un liant intre computerele interconectate.
Ca un spatiu liminal, cyberspatiul este situat intre doua lumi, ecranul fiind pragul de trecere sau fereastra/poarta catre un alt spatiu. Localizat la limita dintre lumea realitatii, a hardware-ului compi de intregul spatiului. Aceasta imagine holista este o aparenta provocata de faptul ca cyberspatiul nu are o forma identificabila, fixa si clara si datorita caracterului sau presupus infinit. De fapt, cyberspatiul Internetului are propria geografie, o geografie a fluxurilor si nodurilor informationale, devenind un spatiu-retea hibrid si multinodal. Din aceasta perspectiva, cyberspatiul nu are o natura fizica, ci se prezinta ca un liant intre computerele interconectate.
Ca un spatiu liminal, cyberspatiul este situat intre doua lumi, ecranul fiind pragul de trecere sau fereastra/poarta catre un alt spatiu. Localizat la limita dintre lumea realitatii, a hardware-ului computeristic si a utilizatorului/locuitorului si lumea bazelor de date 3D in care acesta din urma este proiectat, cyberspatiul este construit prin intermediul a doua tendinte complementare: spatiul real fizic devine abstract si spatiul mental devine concret. Oscilarea intre aceste doua tendinte este fundamentata pe tematica cyberspatiului ca raport intre aici si acolo, dincolo de ecran si dincoace de ecran, in fata ecranului si in spatele ecranului, oriunde si niciunde.
Teoretizat ca spatiu mental, cyberspatiul este privilegiat in trasatura imaterialitatii, trasatura caracteristica conceptelor sau ideilor. In cadrul acestui tip de discurs, se neaga caracterul material (tehnologic si corporal) al spatiului digital, in timp ce se subliniaza natura informationala pura, non-fizica, imaginara a acestuia.
Lucrarea de fata respinge atit perspectiva utopica asupra tehnologiilor spatiului virtual care prefera conditia virtuala in dauna realitatii, cit si critica distopica a virtualitatii care considera realitatea virtuala un aspect novice al extinderii globale a pseudo-realitatii. Ceea ce propunem este acceptarea dublu-chestionabila a co-existentei dintre spatiul realitatii si spatiul virtual si valorificarea acestora in cadrul trasaturilor proprii. Atit realitatea virtuala, cit si cyberspatiul sint manifestari spatiale ale noilor tehnologii computationale care nu distrug realitatea, ci redefinesc si chestioneaza realitatea sau ofera noi lumi de explorat. Viziunea virtuala a spatiului depicteaza relatia dintre tehnologia digitala a informatiei si spatiul real fizic. Datele computerului se spatializeaza ca realitate virtuala sau cyberspatiu, acest nou tip de configuratie spatiala legind realitatea de virtualitate, materialitatea de imaterialitate, tehnologia de mintea umana, literalitatea de metafora sau imaginatie.
Metode de afisare
OpenGL
Despre OpenGL se vorbeste mult si poate tocmai de aceea se fac si multe confuzii. Ce este OpenGL? Cum se masoara performanta OpenGL?, iar în paralel, un glosar de termeni întâlniti în literatura de specialitate.
1. Ce este OpenGL?
OpenGL este un set standard de functii grafice 3D.
Acest standard îsi are originile în biblioteca grafica IRIS GL a lui Silicon Graphics Incorporated, fiind un format proprietar si suportat doar de propriile platforme hardware. În urma numeroaselor solicitari venite din partea marilor dezvoltatori de software de a face publica specificatia GL, SGI a trebuit sa rescrie specificatia deoarece în forma originala era prea dependenta de platforma hardware SGI. A rezultat un format nou, de data aceasta fiind asigurata portabilitatea si standardizarea. Noul nume: OpenGL.
Ca un exemplu de standardizare si portabilitate, putem enumera companiile care au achizitionat licenta acestei tehnologii: AT&T, Barco Chromatics, Cirrus Logic, Cray Research, Daikin, DEC, 3Dlabs, Fujitsu, Evans&Sutherland, Harris Computer, HP, Hitachi, Hummingbird Communications, IBM, The Institute for Information Indusrtry, Intel, Intergraph, Kubota Pacific, Media Vision, Microsoft, Miro, Mitsubishi, NEC, Peritek, Portable Graphics, PsiTech, RasterOps, SPEA, Samsung, Siemens-Nixdorf, SGI, Sony, Sun, Template Graphics Software si Univel.
Dintre acestia doar câtiva au implementat OpenGL în produsele lor: DEC, 3Dlabs, IBM, Intergraph, SGI si Sony (doar implementare software).
Specificatia, respectarea specificatiei si dezvoltarea OpenGL este controlata de un comitet numit OpenGL ARB (architectural review board) care cuprinde DEC, Evans&Sutherland, IBM, Intel, Intergraph, Microsoft si SGI.
La elaborarea specificatiei OpenGL au stat la baza urmatoarele doua principii:
independenta fata de platforma hardware;
independenta fata de sistemul de operare.
În plus, orice implementare a OpenGL trebuie sa fie conforma cu standardul de baza, ceea ce asigura programatorii ca functiile de baza vor fi disponibile pe orice platforma. Fiecare implementator este nevoit sa parcurga un set de teste de conformitate care sa certifice implementarea corecta si compatibilitatea OpenGL.
Ce nu este OpenGL?
– nu este un mediu de programare;
– nu este o interfata grafica;
– nu este orientat obiect.
Ce ofera OpenGL:
– primitive geometrice: puncte, linii si poligoane;
– primitive rastru;
– mod de lucru RGBA;
– modelarea si vizualizarea transformarilor de geometrie;
– eliminarea muchiilor ascunse (invizibile);
– antialiasing – tehnica netezirii muchiilor crestate prin modificarea culorii si intensitatii pixelilor pentru ca muchiile sa apara netede, continue;
– maparea texturilor – aplicarea de texturi 2D pe obiect 3D;
– efecte speciale – fum, ceata si dizolvari;
– evaluatori polinomiali – pentru reprezentari NURBS;
– operatii cu pixeli;
– stencil planes – lucrul cu portiuni de ecran;
– double-buffering – lucrul simultan cu doua rânduri de imagini, una care este afisata si una care este pregatita pentru afisare.
Dupa cum se poate observa din descrierea de mai sus, OpenGL este proiectat pentru utilizarea în aplicatii tehnice 3D cum ar fi CAD-ul (aplicatii precum Solid Edge, Pro Engineer sau I-DEAS), animatii de calitate (cum ofera Softimage) sau în aplicatii de simulare vizuala (Design Review, GVS, ExoDIS).
Implementarile OpenGL pot fi implementari hardware totale (de exemplu Intergraph, SGI) caz în care se obtin cele mai mari performante, implementari software (de exemplu Sony) sau implementari hardware partiale (de exemplu 3Dlabs/GLiNT) caz în care se obtin acceleratoare grafice ieftine din cauza rabatului de performanta. Cum OpenGL este independent de interfata grafica a sistemului de operare, nu exista o legatura strânsa între acestea doua, fiind suficiente doar câteva functii de legatura, nucleul de baza OpenGL ramânând acelasi indiferent de implementare.
2. Cum se masoara performanta OpenGL?
În momentul în care dorim sa achizitionam un accelerator OpenGL sau un sistem complet integrat care sa aiba implementat OpenGL, în mod normal prospectam piata, comparam performante, preturi si servicii. Daca în ceea ce priveste pretul si serviciile totul este clar, stim cum sa facem comparatia, în privinta performantei OpenGL lucrurile nu sunt tocmai simple. Si asta tocmai din pricina furnizorilor si a datelor pe care le ofera. În general se dau cifre care se refera la viteza de afisare a liniilor 2D sau 3D, a triunghiurilor, poligoanelor, suprafetelor etc., dar nu se specifica si conditiile în care au fost facute aceste masuratori. Si ca o ironie, din performantele de afisare a primitivelor nu rezulta performantele care vor fi obtinute în exploatarea reala cu aplicatii si date concrete.
Câteva dintre cele mai frecvent întâlnite metrici sunt:
3D vectors – în general se aleg vectori cu lungimea de 10 pixeli, iar punctele de la capete au coordonate X, Y si Z;
3D line strings – serii de vectori 3D conectati la capete;
3D triangles – triunghiurile utilizate în teste au suprafetele de 25 pixeli sau 50 pixeli. Este greu de comparat performantele diferitelor acceleratoare grafice pentru ca exista mai multe modalitati de desenare a triunghiurilor 3D. Aceste triunghiuri pot fi iluminate sau nu, pot fi în modul Gouraud-shaded, sau flat-shaded, reprezentate cu 24-bit color sau 16-bit color (uneori chiar 8-bit color). Fiecare din acesti factori influenteaza puternic numarul de triunghiuri afisate într-o secunda. De exemplu un triunghi flat-shaded este desenat mai rapid comparativ cu unul Gouraud-shaded, sunt necesare mai multe calcule pentru desenarea unui triunghi iluminat comparativ cu unul neiluminat. Multi producatori nu specifica în rapoarte ce tip de triunghiuri au folosit, ceea ce face imposibila o comparatie corecta. Recomandarile Intergraph sunt ca rapoartele sa fie întocmite pentru triunghiuri iluminate, Gouraud-shaded, 24-bit color, Z-buffer, marimi de 25 si 50 pixeli.
T-mesh – triunghiuri care pot fi desenate independent în asa fel încât oricare doua triunghiuri sa nu aiba laturi comune, sau suprafete alcatuite din triunghiuri astfel încât doua triunghiuri sa partajeze o latura. Datele reale din aplicatii contin de obicei mai multe elemente de tip 3D-triangles, T-mesh si quads;
Quads – poligoane cu patru laturi (patrulatere).
Pentru a veni în întâmpinarea acestor inadvertente cu care se confrunta consumatorii, a fost elaborat în 1994 un program de test numit Viewperf de catre subcomisia OpenGL Performance Characterization (OPC) care apartine de comisia Graphics Performance Characterization (GPC). OPC este parte componenta a Systems Performance Evaluation Corporation (SPEC) – aceeasi companie care produce larg utilizatele programe de testare a performantelor procesoarelor. Scopul OPC este de a realiza o metoda de comparare a performantelor OpenGL, metoda care sa nu depinda de platforma hardware, sistem de operare, sau interfata grafica. Sistemele de operare includ, dar nu sunt limitate la, OS/2, UNIX si Windows NT. Interfetele grafice includ, dar nu sunt limitate la, Presentation Manager, X si Windows. Intentia OPC este de a testa performantele grafice ale întregului sistem rulând aplicatii si nu doar performantele grafice în sine, dat fiind faptul ca din performantele de afisare a primitivelor nu rezulta performantele care vor fi obtinute în exploatarea reala cu aplicatii si date concrete.
OPC si-a propus urmatoarele obiective:
– standardizarea masuratorilor performantei OpenGL prin crearea de unitati de masura care sa nu depinda de o anumita platforma;
– sa ofere mecanisme care sa permita oricarui producator sau utilizator sa-si efectueze propriile evaluari;
– sa faca publice versiunile beta si finale ale programelor;
– sa genereze o lista a celor afectati direct, sau material de specificatiile de evaluare, sa ofere spre consultare publica aceste specificatii;
– sa contribuie la coerenta masuratorilor si evaluarilor performantei OpenGL astfel încât producatorii sa fie capabili de a prezenta masuratori bine executate, iar cumparatorii sa poata compara si evalua produsele.
Viewperf
Primul program de evaluare elaborat de OPC se numeste Viewperf si masoara performantele de rendering 3D ale sistemelor bazate pe OpenGL. Viewperf nu este o aplicatie concreta, în acceptiunea curenta, ci reprezinta o suita de teste bazate pe date reale.
Câteva din caracteristicile Viewperf:
– ofera un singur cod sursa pentru a efectua comparatii tip "mere cu mere, pere cu pere" între diverse platforme;
– ruleaza pe diferite procesoare incluzând Alpha, Intel, MIPS si PowerPC;
– cuprinde o mare varietate de caracteristici OpenGL si tipuri de rendering;
– foloseste seturi de date create pentru si utilizate de aplicatii reale;
– foloseste modele si parametri de rendering de la producatori diferiti;
– rezultatele sunt numere bazate pe cadre/secunda, ceea ce duce la o interpretabilitate facila a rezultatelor;
– furnizeaza un singur numar pentru fiecare tip de rendering si pentru fiecare set de date.
Parametrii masurati de Viewperf:
– primitive 3D incluzând puncte, linii, retele de linii, contururi liniare, triunghiuri 3D, retele de triunghiuri 3D, patrulatere si poligoane;
– atributele per vertex, per primitiva si per cadru;
– iluminarea;
– maparea texturilor;
– variatiile alpha;
– efectele speciale;
– eliminarea pixelilor clipitori (anti- aliasing);
– z-buffering-ul.
Ca orice program de test, Viewperf are si el unele limitari. Cele mai importante sunt ca nu poate rula singur fiind nevoie de interventia utilizatorului, nu tine cont de efectele cauzate de schimbarea primitivelor, de modificarile aparute în cadrul unui ciclu, de miscari complexe ale modelelor multiple, de încarcarea CPU în timpul testului, de efectele multi-fereastra si de calitatea vizuala.
Suita de teste
Viewperf consta dintr-o suita de 5 teste diferite: Awadvs-01 pentru animatii 3D, CDRS-03 pentru proiectarea industriala, DX-03 pentru vizualizari stiintifice, DRV-04 pentru explorarea machetelor 3D virtuale si Light-01 pentru alte tipuri de vizualizare. Fiecare dintre teste include o serie de sub-teste. Rezultatul final al unui test este o valoare medie a rezultatelor obtinute pentru fiecare sub-test al testului respectiv. Trebuie mentionat ca rezultatele sub-testelor au ponderi diferite în valoarea finala, ponderi care sunt direct proportionale cu gradul de dificultate al sub-testului.
Awads-01
Este un test bazat pe aplicatia Alias|Wawefront Advanced Visualizer pentru animatii 3D. Este o aplicatie high-end folosita în general de profesionisti. Este important de mentionat ca aceasta aplicatie nu este disponibila sub Windows NT, deci acest test nu poate fi folosit pentru comparatia între diferite platforme. Modelul utilizat în aceasta aplicatie este sistemul muscular uman. Aplicatia nu suporta multithreading, deci rezultatele vor fi aceleasi indiferent de numarul de procesoare. Sunt 10 sub-teste, dintre care primul are un grad de dificultate de 41.8% (ponderea în cadrul rezultatului final pe test) si foloseste interpolari triliniare, ceea ce duce la o mare calitate a imaginii obtinute. Acceleratoarele grafice care sunt suplimentate cu procesoare geometrice si cu memorie pentru texturi dau rezultate excelente la acest test.
CDRS-03
Aceasta aplicatie, facuta initial de Evans&Sutherland si apoi cumparata de Parametric Technologies, este utilizata în proiectarea industriala, mai ales în industria de automobile la proiectarea de interioare si exterioare. Aplicatia nu suporta multithreading, iar setul de date include si o mica textura (860K). Sporul cel mai mare de performanta la acest test este dat de acceleratorul geometric.
DX-03
IBM Visualization Data Explorer este o aplicatie de vizualizare si analiza stiintifica. În cadrul testului sunt vizualizate traiectoriile particulelor care strabat un jet de fluid. Date de tipul acesta pot proveni din simularea curgerii unor fluide sub anumite constrângeri. Setul de date este compus în majoritate din primitive de tip retele triunghiulare. Aplicatia nu suporta multithreading, nu include texturi, dar contine o sursa de lumina.
DRV-04
Aplicatia Design Review dezvoltata de Intergraph este folosita la explorarea machetelor 3D virtuale, utilizate în proiectarea obiectivelor industriale (instalatii cu tubulaturi, structuri metalice etc.). Setul de date utilizat reprezinta o parte din modelul 3D al unei platforme de foraj marin construite în Marea Nordului. Testul înseamna explorarea virtuala a platformei utilizând imagini realistice. Aplicatia este multithreading, deci mai multe procesoare înseamna un plus de performanta. Textura folosita este aceeasi cu cea de la testul CDRS, deci memoria pentru texturi (cât mai mare) este foarte binevenita.
Light-01
Aplicatia se numeste LightScape Visualization System si este dezvoltata de LightScape Technologies. Aplicatia combina algoritmi proprietari de difuzivitate cu diverse procedee de iluminare. Utilizatorii au posibilitatea de a modifica rapid tipul iluminarii si a texturilor pentru a obtine efectul vizual dorit. Setul de date utilizat la test reprezinta un interior dintr-un spatiu arhitectural. Aplicatia nu suporta multithreading si nici nu utilizeaza texturi.
Producatorii care si-au evaluat produsele cu ajutorul lui Viewperf prezinta de obicei valoarea finala la fiecare test. Este posibil ca un utilizator anume sa se confrunte cu o serie de date al caror specific sa nu fie acoperit de cele 5 teste si sa considere ca un subtest se potriveste cel mai bine cu cerintele sale.
Glosar de termeni întâlniti în literatura de specialitate:
24-bit color: sau "true-color", fiecare pixel de pe ecran are culoarea definita cu ajutorul a 24 biti (8 biti pentru rosu, 8 biti pentru verde si 8 biti pentru albastru). 24 biti ofera 16,7 milioane de combinatii posibile de rosu (R – red), verde (G – green) si albastru (B – blue). Desi ochiul uman nu poate distinge 16,7 milioane de culori diferite, numarul mare de culori permite obtinerea de imagini 3D shaded foarte apropiate de realitate. Unele placi video suporta doar culori pe 16 biti, adica 64K combinatii. Utilizarea unei game de culori mai reduse duce la pierderea efectului realistic al modelului afisat pe ecran. Pe de alta parte, cresterea numarului de culori duce la necesitatea cresterii latimii de banda de memorie a subsistemului grafic. De exemplu, afisarea pe 16 biti presupune o latime de banda dubla fata de afisarea pe 8 biti, pentru a afisa la aceeasi viteza. Adâncimea culorii, sau coordonata Z, este o alta informatie critica care trebuie luata în considerare în momentul în care sunt comparate performantele diferitelor acceleratoare grafice.
32-bit color: o alta descriere a lui "true-color" care, în aditie la cei 24 biti descrisi anterior, mai adauga înca 8 biti utilizati la definirea gradului de transparenta al pixelilor.
bit-planes: defineste numarul de biti care descriu fiecare pixel de pe ecran. De exemplu, 128 bit planes înseamna ca 128 biti controleaza modul de afisare al fiecarui pixel (pot fi 32 biti pentru controlul culorii, 32 biti pentru adâncime etc.). Memoria video este divizata în planuri de biti (mai multi biti presupun mai multa memorie).
double-buffering: majoritatea placilor grafice OpenGL lucreaza cu doua rânduri de imagini, una care este afisata si una care nu. Acestea doua sunt denumite uzual "front-buffer" si "back-buffer". Redarea fara fragmentari a unei animatii 3D presupune utilizarea unui card cu "double-buffering". În timpul în care un cadru aflat în "front buffer" este afisat pe ecran, în "back buffer" este pregatit cadrul urmator, dupa care continutul lui "back buffer" este transferat în "front buffer", concomitent cu aducerea cadrului urmator în "back buffer". Din cauza ca acest procedeu presupune multa memorie video, multe placi OpenGL nu suporta double buffering si/sau 24-bit color. Întrucât double-buffering este indispensabil pentru redarea continua a imaginilor 3D, la aceste placi grafice trebuie sa se faca rabat fie la numarul de culori (trecerea pe 16-bit color), fie la rezolutie (micsorarea acesteia), ambele variante ducând la scaderea calitatii imaginii.
frame-buffer: memoria video disponibila pe card pentru stocarea atât a informatiei afisabile, cât si a celei neafisabile (cum ar fi coordonata Z). Furnizorii cu pretentii utilizeaza un bloc contiguu de memorie pentru stocarea tuturor informatiilor, altii utilizeaza memorii VRAM pentru stocarea informatiei afisabile si memorii DRAM pentru informatia neafisabila.
Mflops: milioane de operatii în virgula mobila. Algoritmii OpenGL presupun un intens calcul în virgula mobila. Cu cât cardul poate efectua un numar mai mare de operatii în virgula mobila, cu atât mai rapid va fi redering-ul.
overlay-planes: multe aplicatii presupun afisarea de vectori peste o imagine rastru, cum sunt aplicatiile GIS (de exemplu desenarea unei linii reprezentând o sosea pe deasupra unei imagini scanate). Utilizarea de planuri suprapuse permite desenarea de vectori fara coruperea imaginii de pe fundal (a rastrului). Aceste planuri suprapuse mai sunt numite si planuri nedistructive si presupun existenta în memoria video a unor biti de control separati de planurile de imagini. Unele placi grafice ofera planuri de suprapunere pentru ambele rânduri de imagini, front buffer si back buffer, asa-numitul "double-buffered overlay planes".
stencil planes: mascarea anumitor portiuni din ecran (utilizarea sabloanelor). De exemplu un simulator de tanc poate folosi un stencil-plane pentru definirea unei ferestre care sa reprezinte peisajul exterior care se schimba odata cu deplasarea tancului. Imaginea din fereastra poate fi rapid actualizata, fara a fi nevoie de modificarea întregului ecran, care în cazul de fata reprezinta interiorul tancului. 8 asemenea planuri ofera posibilitatea definirii a 8 ferestre pe ecran.
Z-buffer: numarul de biti alocati fiecarui pixel pentru definirea adâncimii (coordonatei Z). Un numar mai mare de biti pentru z-buffer înseamna o mai mare acuratete în determinarea coordonatei z. Majoritate placilor grafice 3D suporta z-buffer doar de 16 biti, uneori de 24 biti. Pentru o calitate minima a imaginii sunt suficienti 16 biti, dar recomandarea este 24 sau 32 biti. În cazul reprezentarii unei instalatii care are o lungime de 500 m, dar care are tevi distantate la doar 5 cm, un z-buffer de 24 biti nu ofera suficienta acuratete pentru a afla care teava este deasupra celeilalte. Cardul video va încerca sa afiseze ambele tevi simultan, ceea ce duce la pâlpâiri deranjante pentru ochi (efect cunoscut sub numele de transpunerea triunghiurilor). Un z-buffer de 32 biti elimina aceste neajunsuri.
texture mapping: procesul de aplicare de texturi 2D pe obiecte 3D pentru marirea gradului de realism al obiectului. Fiecare texel (unitatea elementara a unei texturi) este aplicat pe pixelul corespunzator al obiectului.
texture fill rate: viteza cu care texelii sunt aplicati peste pixelii obiectului 3D. De exemplu o rata de 38 milioane reprezinta tot atâtia pixeli care au fost acoperiti de textura într-o secunda. Sunt mai multi factori care afecteaza viteza de mapare, dar cei mai importanti sunt modul de filtrare (sau interpolare) si adâncimea culorii texturii (care poate fi de 4, 8, 16 sau 32 biti per texel). Marirea numarului de biti de culoare per texel duce la o crestere semnificativa a calitatii imaginii, dar presupune si o latime de banda mai mare în accesarea memoriei video. Modul de filtrare afecteaza în aceeasi masura calitatea imaginii, dar presupune în plus si un volum de calcul mai mare. De exemplu maparea unei texturi pe 32 biti cu interpolare triliniara presupune, comparativ cu o textura pe 16 biti si interpolare biliniara, o latime de banda de 4 ori mai mare si un volum de calcul de 2 1/3 ori mai mare, în ipoteza ca dorim sa pastram aceeasi viteza de mapare. Atât timp cât nu se cunosc acesti 2 parametri, nu se poate face o comparatie corecta între vitezele de mapare ale diferitelor acceleratoare grafice.
texture map interpolation: când texturile sunt aplicate pe un obiect, procesorul grafic trebuie sa determine care texel va fi aplicat pe care pixel. Cum texturile sunt 2D, iar obiectele sunt 3D, nu va exista o corespondenta de 1:1 între texeli si pixeli. Exista 3 tipuri principale de interpolare sau filtrare: metoda celui mai apropiat vecin, interpolare biliniara si interpolare triliniara.
Metoda celui mai apropiat vecin – pixelul primeste valoarea texelului care îl acopera în cea mai mare masura, deci valoarea unuia dintre cei 4 texeli vecini. Aceasta metoda este folosita cel mai des în jocurile 3D din cauza vitezei mari la resurse mici, dar calitatea imaginii rezultante este de slaba calitate.
Interpolarea biliniara – valoarea pixelului este calculata pe baza celor 4 texeli vecini si foloseste 3 valori medii astfel: prima medie se calculeaza pe baza celor 2 texeli de sus, a doua medie pe baza celor 2 texeli de jos, iar a treia medie pe baza celor doua medii anterioare. Ultima valoare medie este cea care se atribuie pixelului. Interpolarea biliniara este potrivita pentru imagini statice, nu ofera imagini de mare calitate si este înca nepotrivita pentru obiecte în miscare, cum este cazul simularilor.
Interpolarea triliniara – foloseste mai multe texturi de rezolutii diferite derivate din textura de baza, fiecare reprezentând exact 1/4 din suprafata celeilalte. Astfel, daca o textura are 512×512 texeli, a doua va avea 256×256, a treia 128×128, … iar ultima 1×1. Folosind mai multe texturi de rezolutii diferite obtinem imagini de calitate excelenta mai ales când lucram cu apropieri/departari ale obiectelor, cum este cazul în majoritatea animatiilor si simularilor. Valoarea aplicata pixelului va fi o medie de 8 texeli – 4 din fiecare textura. Interpolarea triliniara înseamna calculul a 7 valori medii, comparativ cu 3 valori medii în cazul interpolarii biliniare. Necesita în plus o latime de banda dubla, fiind cititi 8 texeli, comparativ cu 4 texeli în cazul precedent. Modalitatea de calcul elimina posibilitatea de aparitie a pixelilor clipitori, asa-numitul fenomen de "texture aliasing". Pentru aplicatii care necesita obiecte în miscare, doar interpolarea liniara ofera calitate acceptabila.
DirectX 7
Grupul de tehnologii din DirectX fac dintr-un sistem Windows o platforma ideala pentru rularea aplicatiilor cu un continut multimedia bogat, sunet surround, animatii 3D sau grafica full-color. Tocmai din aceste motive si prin faptul ca multimedia este un element omniprezent in utilizarea unui calculator, aceste componente realizate de Microsoft sunt acum inglobate in sistemele de operare produse de amintita companie, cum ar fi Windows 98, Windows 2000, Windows XP.
DirectX nu mai este doar de domeniul C-ului (si cu un pic de ajutor Delphi), utilizatorii Visual Basic putandu-se bucura de un suport solid pentru aplicatiile dezvoltate in acest mediu. Ca premiera, DirectX 7 transfera in seama hardware-ului grafic calcularea geometriilor si a iluminarii (daca hardware-ul suporta).
DirectX este compus practic din doua straturi (layer-e) mari, fiecare cu o orientare bine gandita pentru a oferi dezvoltatorilor de aplicatii o baza solida pentru crearea de continut multimedia cat si pentru siguranta rularii respectivului continut pe orice platforma. Cele doua layere-e sunt DirectX Foundation si DirectX Media.
DirectX Foundation
Acest layer este practic un set de API-uri (Application Programming Interface) low-level pentru programarea jocurilor si aplicatiilor multimedia. Aici este inclus suport pentru grafica 2D si evident 3D, sunet si muzica, force feedback si perifericele de genul joystick-urilor, mouse-urilor etc., si, suportul pentru comunicatii in retea (multiplayer). Vom lua pe rand componentele din DirectX Foundation si sa vedem ce aduce nou in fiecare din acestea DX 7.
DirectInput
Evident, acest modul este cel care se ocupa de controlerele de jocuri, mouse-uri si, evident, de
aparatele force-feedback. La ora actuala, regasim pe piata acestor tipuri de periferice mouse-uri cu sapte taste, care sunt adevarate tastaturi pentru surfing sau pentru aplicatii. DirectInput ofera acum si acces exclusiv la tastatura si pornire intarziata a efectelor force-feedback. In SDK (Software Development Kit) exista un editor de efecte pentru force-feedback (Force Editor), foarte bine pus la punct, cu ajutorul caruia se pot salva efectele realizate, intr-un fisier RIFF, cu WriteEffectsToFile si pot fi enumerate apoi cu EnumEffectsInFile. Surprinzator, dar nu am gasit aici nici o metoda Load sau Read EffectsFromFile.
DirectPlay
Modificarile aduse in domeniul conexiunilor multiplayer (modem, retea locala sau Internet) sunt modeste, singura de mentionat fiind Ripple Launching. Astfel, un lobby (un server) nu trebuie sa porneasca aplicatiile stocate local pe calculatoarele utilizatorilor, ci apeleaza un program de lansare
propriu care, la randul sau, poate lansa aplicatia, odata ce au fost efectuate eventualele pregatiri necesare.
DirectSound
DirectSound este componenta wave-audio a DirectX API, oferind posibilitatea de mixaje cu latente mici, accelerare hardware si acces direct la dispozitivul de sunet. Algoritmii de procesare audio 3D au fost schimbati pentru a oferi o mai buna utilizare a CPU-ului, astfel gradul de exploatare a acestuia fiind configurabil. De asemenea, s-a optimizat si gestionarea hardware a vocii. Noile functii se folosesc in schimb exclusiv cu driver-ele WDM (Windows Driver Model).
DirectMusic
In generatia noua, componenta DirectMusic inglobeaza un sintetizator software: Microsoft Synthesizer si suporta standardul DLS 2 (DownLoadable
Sounds).
DirectDraw
DirectDraw este o interfata software care ofera acces direct la dispozitivele grafice (de afisare) mentinand in acelasi timp compatibilitatea cu Windows GDI (Graphic Device Interface). Aceasta componenta permite manipularea memoriei video, a blitter-ului hardware (componenta pentru efectuarea de operatii blit) si ofera suport pentru overlay hardware si flipping surface, intr-un cuvant ofera posibilitatea afisarii graficii aplicatiilor DirectX. La acest capitol a aparut suport pentru display-urile stereo (dispozitive active de genul ochelarilor 3D) si cateva metode noi in interfete, avand ca urmare trecerea la versiunea 7 a lui DirectDraw.
Direct3D
Cum sugereaza si numele, aceasta este componenta care se ocupa de grafica 3D interactiva. Direct3D ofera acces dependent de device la hardware-ul video 3D intr-o maniera independenta de device. Direct3D are doua moduri: Immediate Mode si Retained Mode, cel din urma fiind construit
peste primul dintre ele. Desi Direct3D este o componenta a DirectX Foundation si Retained Mode este o subcomponenta a Direct3D, acest mod nu este considerat ca facand parte din Foundation, ci din DirectX Media. De fapt, Microsoft chiar specifica in documentatia aferenta versiunii 7 a SDK-ului ca nu mai este planificata nici o dezvoltare pentru Retained Mode, acesta fiind practic iesit din uz.
Toate noutatile ce sunt aduse de partea graficii 3D se refera la Immediate Mode. Acesta include acum o biblioteca absolut noua, si anume Direct3DX, a caror functii au preluat actiunile obisnuite de initializare, de incarcare de texturi si care este si responsabila cu primitivele geometrice, sprites si transformarile 3D. Aceasta biblioteca este practic un layer de ajutor pentru acest tip de operatii, atat pentru Direct3D cat si pentru DirectDraw, ajutand programatorii sa se concentreze mai mult asupra operatiilor mai complexe din dezvoltarea unei aplicatii. Definirea surselor de lumina nu este realizata insa prin aceasta biblioteca si nici prin tehnicile cunoscute din DirectX 6, ci prin metodele noii interfete IDirect3DDdevice 7, care este urmasa IDirect3DDevice 3. Dar aceasta nu mai este compatibila cu obiectele individuale pentru parametrii iluminarii, materialelor si a viewport-urilor (obiectele din versiunile precedente: IDirect3Dlight, IDirect3Dmaterial 3 si IDirect3
DViewport 3), acestea fiind asimilate de noua interfata mai sus amintita. Acest fapt va obliga dezvoltatorii care doresc sa se foloseasca de noile posibilitati sa intervina cu multe modificari in engine-urile existente. In noua versiune Direct3D se poate folosi de acceleratoarele hardware 3D pentru a accelera operatiile de transformare si de iluminare, daca dispuneti de un device TnLHAL.
Direct3D si DirectDraw suporta un nou tip special de mapare a texturilor folosit in environment mapping si anume cubic environment map. Acest tip de mapare implica folosirea texturilor cu sase fete care pot contine imagini care urmeaza a fi aplicate unui obiect din scena, oferind chiar posibilitatea implementarii dinamice a environment mapping. Tot la capitolul texturi a fost imbunatatita si gestionarea acestora, Direct3D fiind capabil acum sa determine prioritatea unei texturi, stiind astfel care sa fie tinute in memorie si care sa fie inlaturate.
Acestea nu sunt singurele schimbari si noutati din Direct3D, dar sunt cele mai importante. Suportul pentru seturi speciale de instructiuni cum ar fi 3D-Now! incluse in procesoarele AMD si optimizarea celor MMX prezente in procesoarele Intel sau noul suport pentru Geometry Blending.
DirectX Media
Layer-ul Foundation a fost suplimentat cu un set de servicii de nivel inalt sub denumirea de DirectX Media, oferind suport pentru aplicatiile multimedia obisnuite si pentru obiectele multimedia
vehiculate in Internet.
DirectX Media este o familie de API-uri la nivel aplicatie si de controlere multimedia care ofera un suport bogat pentru interactiunea si integrarea a diferite tipuri de obiecte media pentru dezvoltarea aplicatiilor pentru crearea de continut multimedia online si digital. DirectX Media include urmatoarele componente: DirectX Show, pentru redarea continutului media, captura si streaming, DirectX Animation, pentru suportul animatiilor si interactiunea a diverse obiecte media care pot fi integrate in DHTML si DirectX Transform care ofera efecte 2D, 3D si de timp pentru aplicatii obisnuite si pagini web. Aici este inclus si modul Retained din Direct3D, despre care am pomenit mai devreme. Tot aici se regaseste suport pentru VRML.
Tehnici de desenare 3D
Arhitectura si ingineria pentru constructii si sistematizare apartin unuia dintre domeniile care se caracterizeaza printr-o remarcabila evolutie, pe masura implementarii celor mai noi inovatii din industria tehnologiei informatice.
Saltul de la schitele pe calc realizate cu ajutorul penitei cu tus si a riglei de calcul la plansetele digitizor, monitoarele cu diagonala mare si proiectarea 3D este intr-adevar spectaculos.
Programele din ce in ce mai performante si mai specializate permit arhitectilor o serie intreaga de facilitati ce asigura comenzi de desenare si modificare deosebit de usor de folosit, cotare automata, operare simultana in mai multe ferestre, realizarea de sectiuni si extrase de plan, vizualizari 3D si chiar proiectare in realitatea virtuala.
E de la sine inteles ca astfel de aplicatii necesita si o dotare hardware adecvata. Pentru procesarea aplicatiilor de arhitectura sunt utilizate statii grafice sau servere de mare putere, iar echipamentele periferice trebuie sa includa imprimante, plottere si scannere care sa permita realizarea de materiale grafice in formate specifice (A0 sau A1).
Utilizarea tehnologiei de realitate virtuala in proiectarea asistata de calculator in arhitectura
Aplicatiile realizate pana in prezent utilizand tehnologii de realitate virtuala se caracterizeaza, in esenta, prin generarea unor lumi artificiale si imersiunea utilizatorului in interiorul acestor lumi. Evolutia si eficienta unor astfel de sisteme sunt conditionate, in primul rand, de cresterea performantelor in domeniul hardware (calculatoare si dispozitive de interactiune specializate), astfel incat sa se asigure o imersiune "completa" a omului in lumea virtuala si, implicit, o comunicare directa, in timp real, cu acesta.
Optimizarea interfetei om-masina cu ajutorul tehnologiei de realitate virtuala constituie un subiect de cert interes in domeniul proiectarii asistate de calculator prin capacitatea acestui instrument inovativ de a oferi un contact natural intre om si sistemul respectiv de proiectare asistata de calculator. Cu o alta exprimare, mai aproape de o definire paradigmatica, se poate spune ca interfetele om-masina devin, in acest mod, intuitive.
Intr-o asemenea abordare, obiectul asupra caruia lucreaza proiectantul constituie un prototip virtual care se genereaza intr-o anumita stare (situatie) initiala si care poate fi reconstruit in orice etapa a procesului de proiectare, fara un efort substantial. Avantajul major este ca, in general, se porneste de la schite simple si se poate ajunge la obiecte si complexe de obiecte amplasate, dupa anumite considerente, in interiorul unui mediu sintetic, folosind tehnici (traditionale sau moderne) de proiectare 3D.
Prototipul asupra caruia opereaza, in raport cu creativitatea si experienta proprie, proiectantul uman poate fi redat intr-un context natural in orice faza de elaborare, astfel incat defectele fundamentale, adaptarile, caracteristicile nedorite pot fi identificate si corectate imediat, inainte de realizarea efectiva a proiectului.
Utilizand aceasta solutie in proiectarea arhitecturala, se poate crea un mediu ambiant avansat, prin simularea tuturor "trasaturilor" unei constructii, inclusiv iluminatul, incalzirea si acustica; se poate, de asemenea, circula prin incaperi, se pot experimenta anumite caracteristici ale proiectului (de exemplu: culori, spatii volumetrice, pozitii de fixare a luminii si intensitatii acesteia, ventilarea si dispozitivele de incalzire/racire ale camerelor). In sistemele clasice de proiectare, incercarea si verificarea solutiilor de proiectare se realizeaza prin efectuarea unor simulari la scara redusa (sau pe machete fizice reduse) ale obiectului proiectat, respectiv intr-o maniera costisitoare si in unele cazuri putin relevanta.
Sistemele de proiectare asistata de calculator in arhitectura, bazate pe realitate virtuala, permit generarea rapida a unor modele virtuale, complete la scara reala, asupra carora se pot face experimentari directe.
Un avantaj suplimentar oferit de acest tip de simulare virtuala a cladirii (produsul final al procesului de proiectare) decurge din faptul ca eventualii cumparatori (beneficiari) pot examina ei insisi proiectul intr-o faza incipienta, avand, pe de o parte, sansa de a vedea ceea ce pot cumpara, cat si, pe de alta parte, posibilitatea ca prin realitate virtuala, sa devina parteneri efectivi ai procesului de proiectare, putand propune modificari si adaptari. O abordare care va prezenta un real interes in anii urmatori o constituie integrarea unui modul de proiectare asistata de calculator pentru arhitectura intr-un sistem mult mai complex, bazat pe arte vizuale (teatru virtual, teleconferinta, muzeu virtual).
Evolutiile inregistrate in domeniul sistemelor de realitate virtuala se manifesta in prezent si prin aparitia unui concept nou, telesenzatia, care combina vederea artificiala, grafica pe calculator, realitatea virtuala si telecomunicatiile.
Preocupari pentru dezvoltarea in tara a unor astfel de sisteme exista si in cadrul ICI (Laboratorul de Sisteme de Inginerie Asistata de Calculator). Domeniul de implementare il constituie reconstructia virtuala a monumentelor istorice in vederea conservarii autenticitatii acestora, avand in vedere, intr-o prima etapa, Cetatea de Scaun din Suceava si extinderea ulterioara pentru celelalte monumente din Moldova.
Tehnologiile bazate pe realitate virtuala vor afecta in urmatorii ani intregul sistem de cultura, stiinta si comert, incluzand educatia si petrecerea timpului liber; la nivelul infrastructurii, evolutia este spre medii de dezvoltare si exploatare in retea.
Un sistem pentru reconstructia virtuala a monumentelor istorice reuneste telecomunicatiile si realitatea virtuala, prin proiectarea si dezvoltarea mediilor multi-utilizator conectate in retea si integreaza componente software din diferite domenii: constructia lumilor virtuale, arta vizuala, arhitectura, telecomunicatii, inteligenta artificiala, protocoalele de comunicatie. Aplicarea modelarii 3D si a vizualizarii fotorealistice in reconstructia monumentelor de arta se gaseste la inceputul unei dezvoltari semnificative.
Prin contrast, reconstructiile si reprezentarile clasice sunt realizate folosind mijloace conventionale (modele fizice, desene, fragmente de obiecte). In multe cazuri, zidurile si cladirile exista numai ca ruine, sunt reprezentate uneori numai prin fundatii, aspectul lor original fiind reconstituit in fapt numai in imaginatia vizitatorului. Reconstituirea fizica a unui ansamblu arhitectonic poate avea ca efect deteriorarea unor piese autentice sau chiar distrugerea unor elemente originale conservate pana in prezent.
Construirea unui monument de arta intr-un mediu de realitate virtuala implica dezvoltarea unei retele de participanti localizati in arii geografice diferite, interactiunea cu lumea virtuala relizandu-se prin Internet sau prin telecomunicatii cu banda larga.
Un monument virtual reprezinta o colectie electronica de date, care poate include diferite categorii de informatii, cum ar fi: picturi, desene, fotografii, diagrame, inregistrari secvente video, articole de ziar, planuri arhitectonice, toate stocate in baze de date pe un server de retea. Frumusetea unui monument virtual consta si in faptul ca poate conecta vizitatorul la informatii din toata lumea, legate de subiectul respectiv. Procesul de colectare a informatiilor este dinamic, fondul de baza actualizandu-se oricand cu noi colectii.
Pe plan mondial s-au raportat preocupari privind realizarea unor aplicatii de acest gen: reconstructia virtuala a orasului Pompei de catre o echipa a Universitatii Virginia, reconstructia virtuala a Marelui Altar al Pergamonului de la muzeul cu acelasi nume din Berlin, in cadrul proiectului european ESPRIT, denumit MUSA.
Aceste elemente sustin concluzia ca generarea unei lumi virtuale realizate prin colaborarea arhitectilor, a artistilor vizuali, a echipelor de proiectare asistata de calculator, a programatorilor si a specialistilor in ingineria de sunet poate contribui la reconstruirea monumentelor si siturilor istorice, conservandu-se astfel autenticitatea complexelor existente.
Transformari (translatie, scalare, rotatie)
Coordonatele nu sunt toate de acelasi tip. Ele pot fi coordonate spatiale absolute, coordonate spatiale relative sau coordonate system. Dupa tipul acestor coordonate spatiul poate fi impartit in patru categori:
Spatiu obiectual: Aceste coordonate definesc forma unui obiect. Adeseori se foloseste un punct de origine in centrul obiectului. Coordonatele obiectului vor fi stabilite in raport cu acest punct de origine. Fiecare obiect are propriul sau spatiu, coordonatele in spatiul obiectual fiind constante, ele modificandu-se doar daca dorim ca obiectul respectiv sa se transforme progresiv sau dintr-o data intr-un alt obiect (acest efect se numeste morfism).
Spatiul lumii: se creaza o lume in care toate obiectele sunt pozitionate, rotite si scalate intr-o pozitie relativa unei aceeasi origini. Coordonatele in acest spatiu sunt independente de pozitia camerei (punctului din care privim). In acest spatiu coordonatele obiectului se schimba doar daca acesta se misca.
Spatiul vizual: Acest spatiu este lumea vazuta din punctul de vedere al celui ce priveste, cu alte cuvinte lumea vazuta prin prisma pozitiei camerei de filmat.Toate coordonatele in acest spatiu se schimba daca pozitia camerei se schimba.
Spatiul ecranului: Spre deosebire de celelalte, acesta este un spatiu bi-dimensional. Acesta este proiectia spatiului vizual pe ecranul computerului. In acest spatiu, obiectele care sunt mai departe apar mai mici, iar cele care sunt mai aproape apar mai mari.
Pentru a realiza translatia unui obiect este suficient sa crestem sau sa scadem coordonata x sau/si y a tuturor punctelor ce alcatuiesc obiectul, in functie de directia in care vrem sa translatam obiectul. Obiectul poate fi translatat cu sau fara punctul sau de origine. Daca translatam obiectul fara punctul sau de origine, cand vom incerca sa rotim obiectul efectul nu va mai fi acelasi, deoarece acesta se va roti in jurul punctului sau de origine care a ramas neschimbat. Tot o translatie se realizeaza si atunci cand schimbam coordonatele x sau y ale camerei, doar ca aceasta are loc asupra tuturor obiectelor si doar asupra spatiului vizual, nu si asupra spatiului lumii.
Pentru a realiza scalarea unui obiect este suficient sa crestem sau sa scadem coordonata z a tuturor punctelor ce alcatuiesc obiectul. Toate observatiile facute la translatia obiectelor sunt valabile si aici.
Realizarea rotatiilor este putin mai complicata. Vom incepe mai intai cu rotirea unui punct intr-un sistem de coordonate 2D.
Folosind ecuatia cercului coordonatele punctului P' vor fi urmatoatele:
x' = x * cos() – y * sin()
y' = x * sin() + y * cos()
Demonstratie:
Coordonatele vor verifica ecuatia cercului:
X2 + Y2 = R2
X'2 + Y'2 = R2
De aici rezulta ca X2 + Y2 = X'2 + Y'2.
Verificand aceasta relatie vom obtine urmatorul rezultat:
X'2 + Y'2 = X2*cos2()-2*X*Y*cos()*sin()+
+Y2*sin2()+X2*sin2()+2*X*Y*cos()*sin()+
+ Y2 * cos2()
= X2 * cos2() + Y2 * (1 – cos2()) +
+X2 * (1-cos2()) + Y2 * cos2()
= X2 * cos2() + Y2 – Y2 * cos2() + X2 –
-X2 * cos2() + Y2 * cos2()
= X2 + Y2 (A)
Formulele de rotatie ale unui punct intr-un sistem de coordonate 2D sunt de fapt exact formulele de rotatie ale unui punct intr-un sistem de coordonate 3D, in jurul axei z, coordonata z ramanand nemodificata in urma acestei rotatii. Formulele de rotatie in jurul axelor x si y se deduc in mod asemanator si sunt urmatoarele:
x' =x
y' = y * cos() – z * sin()
z' = y * sin() + z * cos() , pentru rotatia in jurul axei x
x' = x * cos() – z * sin()
y' = y
z' = x * sin() + z * cos() , pentru rotatia in jurul axei y
Rotatiile se pot realiza si cu ajutorul matricilor.
Matricea de rotatie in jurul axei z:
cos (a) -sin (a) 0 0
sin (a) cos (a) 0 0 .
0 0 1 0
0 0 0 1
Matricea de rotatie in jurul axei y:
cos (a) 0 -sin (a) 0
0 1 0 0
sin (a) 0 cos (a) 0
0 0 0 1
Matricea de rotatie in jurul axei x:
1 0 0 0
0 cos (a) -sin (a) 0
0 sin (a) cos (a) 0
0 0 0 1
Rotatia dorita se poate realiza inmultind matricea corespunzatoare rotatiei cu vectorul coordonatelor punctului pe care vrem sa-l rotim, obtinandu-se un nou vector ce va contine coordonatele rotite:
1 0 0 0 x x'
0 cos (a) -sin (a) 0 * y = y'
0 sin (a) cos (a) 0 z z'
0 0 0 1 1 1
Crearea suprafetelor
Pentru crearea obiectelor vom folosi suprafetele poligonale. Suprafata poligonala de baza este triunghiul, cu ajutorul acestuia realizandu-se orice alta suprafata poligonala. Deci, obiectele noastre vor fi alcatuite dintr-o multime de triunghiuri, acestea fiind folosite si in cazul simularii unor suprafete curbate. Daca consideram un numar de triunghiuri suficient de mare, acestea vor da aspectul unei suprafete curbate. Pentru redarea suprafetelor curbate se mai folosesc si curbele Bezier. Pentru a realiza redarea unui triunghi trebuie mai intai sa proiectam cele 3 puncte in spatiul ecranului, dupa care ceea ce ne va ramane de facut este desenarea unui triunghi pe ecran, format din coordonatele proiectiilor. Pentru desenarea triunghiului vom folosi un algoritm de scalare orizontala, adica vom desena triunghiul prin desenarea unui numar de linii orizontale. Pentru fiecare linie va trebui sa cunoastem doua coordonate: coordonata de inceput a liniei si coordonata de sfarsit a liniei. Coordonatele de inceput ale liniilor le vom memora intr-un bufer, iar cele de sfarsit intr-un alt bufer. Determinand punctul de coordonata y minima si punctul de coordonata y maxima vom sti cate asemenea linii orizontale vom trasa. Aplicand un algoritm de trasare a unei linii intre cele doua puncte, fie folosind ecuatia dreptei de-a lungul axei y (la fiecare pas scadem/crestem valoarea lui y si obtinem valoarea lui x din ecuatia dreptei, valoare pe care o introducem intr-unul din bufere), fie folosind un algoritm de trasare performant si memorand valorile lui x (folosirea unui algoritm performant de trasare a unei linii este inutila, deoarece folosirea ecuatiei dreptei este suficienta). La sfarsitul acestei operatii vom avea unul din cele doua bufere.(nu putem sti care dintre ele pana nu il avem si pe).
Metode de ordonare a obiectelor
La rezolvarea acestei probleme pentru unele metode vom avea nevoie de putina matematica 3D (geometrie in spatiu).
Distanta dintre doua puncte.
Sa consideram doua puncte : A(Ax, Ay, Az), B(Bx, By, Bz).
Dx = Ax – Bx
Dy = Ay – By
Dz = Az – Bz
Distanta = sqrt(dx*dx + dy*dy + dz*dz)
Definitia unui vector 3D.
La un vector 3D ne putem gandi fie ca la un punct de coordonate <x, y, z>, fie ca la o linie ce pleca din origine <0, 0 ,0> si ajunge in punctul de coordonate <x, y, z>.
Lungimea unui vector este urmatoarea:
length = | <x,y,z> – <0,0,0> |
= sqrt( (x-0) * (x-0) + (y-0) * (y-0) + (z-0) * (z-0) )
= sqrt(x*x + y*y + z*z)
Un vector unitate se obtine impartind fiecare componenta a vectorului prin lungimea sa:
Vector unitate = <x,y,z> = | x , y , z |
length | length length length |
Produsul scalar a doi vectori.
Produsul scalar a doi vectori <Ax, Ay, Az> si <Bx,By,Bz> se calculeaza astfel:
A * B = Ax*Bx + Ay*By + Az*Bz
Daca A si B sunt vectori unitate, atunci produsul scalar este cosinusul unghiului dintre cei doi vectori.
teta = arccos (A * B)
Definitia unui plan.
Un plan poate fi definit prin normala sa si o valoare scalara k.
Ecuatia planului foloseste produsul scalar si este urmatoarea:
<x, y, z> * <nx, ny, nz> = k , unde <nx, ny, nz> este normala
Toate punctele care se afla in planul respectiv satisfac aceasta ecuatie.
De aici rezulta:
<x,y,z> * <nx,ny,nz> = k Punctul apartine planului
<x,y,z> * <nx,ny,nz> > k Punctul este de o parte a planului
<x,y,z> * <nx,ny,nz> < k Punctul este de cealalta parte a planului
Produsul vectorial.
Daca avem doi vectori <Ax, Ay, Az> si <Bx,By,Bz>, produsul vectorial este un vector perpendicular pe planul format de acesti doi vectori.
Produsul vectorial este urmatorul:
A x B = <Ay*Bz – Az*By, Az*Bx – Ax*Bz, Ax*By – Ay*Bx>
Facand produsul scalar intre axa x si axa y rezulta:
<1,0,0> x <0,1,0> = <0*0 – 0*1, 0*1 – 1*0, 1*1 – 0*0> = <0,0,1>
, care este axa z.
Calcularea unui plan din 3 puncte.
Pentru calcularea unui plan din trei puncte date, se calculeaza mai intai normala. Normala o vom calcula folosind produsul vectorial a doi dintre vectorii pe care ii formeaza cele trei laturi ale triunghiului format de cele 3 puncte. Apoi, pentru a determina scalarul k se face produsul scalar intre normala si unul dintre cele 3 puncte.
normala = (p1-p2) x (p3-p2)
k = normala * p1
, unde p1, p2 si p3 sunt cele 3 puncte date.
normala = (p1-p2) x (p3-p2)
= (0, -1, 0) x (1, -1, 0)
= <(-1) * 0 – 0 * (-1), 0 * 1 – 0 * 0, 0 * (-1) – (-1) * 1>
= <0, 0, 1>
, care este axa z.
k = normala * p1 = 0 * 0 + 0 * 0 + 1 * 0 = 0.
Z-buffering
Aceasta metoda presupune crearea unui bufer in care, pentru fiecare punct care il desenem pe ecran, tinem minte distanta la care se afla punctul respectiv. In momentul in care vom dori sa desenam un punct peste un alt punct deja existent, comparam distanta la care se afla noul punct pe care vrem sa-l desenam cu distanta memorata in bufer corespunzatoare pozitiei respective. Daca aceasta distanta este mai mica, atunci vom desena noul punct peste cel deja existent, iar daca nu, noul punct nu va mai fi desenat.
Aceasta metoda produce o acuratete foarte buna pentru redarea obiectelor, dar consuma memorie destul de mult pentru bufer. Pentru modul grafic 320×200, folosind pentru distanta valori de tipul unsigned int (adica cuprinse intre 0 si 65535) spatiul necesar pentru bufer este de 128Kb, ceea ce este destul de mult. Pentru o rezolutie de 800×600 spatiul ocupat va fi de 960Kb. De asemenea, daca vom dori sa folosim distante mai mari decat 65535 va trebui sa folosim pentru distanta tipul unsigned long int, fapt ce va duce la o dublare a spatiului de memorie necesar buferului. Nici performantele legate de viteza nu sunt prea bune, deoarece pentru fiecare punct pe care il desenam va trebui sa calculam distanta acestuia. Totusi e si normal – calitatea costa (doar daca nu gasim o metoda mai buna, din punctul de vedere al utilizarii memoriei si al vitezei, de aceeasi acuratete a redarii).
Ne vom referi in continuare la trasarea unui triunghi, trasare care de data aceasta va updata si z-buferul.
O prima metoda foloseste aproximarea distantelor punctelor, distantele punctelor fiind calculate exact, numai pentru cele trei puncte ce formeaza triunghiul. Pentru trasarea triunghiului vom folosi o functie de trasare a unei linii orizontale care tine cont de distanta (coordonata z) a punctului de start si de coordonata z a punctului de sfarsit. Deci pentru trasarea triunghiului vom mai avea nevoie de doua bufere in care sa memoram distantele.
O alta metoda este aceea care calculeaza pentru fiecare punct pe care il desenam pe ecran distanta la care acesta se afla in spatiu. Avand coordonatele punctului in spatiul ecranului putem recurge la operatiile inverse pe care le parcurgem pentru a proiecta punctul pe ecran pentru a determina coordonatele in spatiu ale acestuia. Apoi, folosindu-ne de ecuatia planului in care se afla punctul, ecuatia planului determinand-o cum am aratat mai sus, vom determina distanta la care se afla acesta.
Aceasta metoda este metoda de realizare corecta, din punct de vedere matematic, a calcularii distantei. Totusi, dupa cum se poate observa este o metoda care necesita destul de multe calcule, si de aceea performantele legate de viteza sunt mai scazute. Pe de alta parte rezultatele legate de aspect sunt foarte bune.
Back face removal
Aceasta metoda se bazeaza pe faptul ca majoritatea suprafetelor sunt vizibile doar dintr-o singura parte, si atunci cand privim din cealalta parte nu mai trebuie sa desenam suprafetele respective. Aceasta metoda se combina foarte bine cu metoda Z-buffering pentru a elimina suprafetele care nu se vad si a castiga viteza.
Pentru a elimina suprafetele care nu se vad folosim ecuatia planului. Inlocuim in ecuatia planului coordonatele punctului din care privim (x, y, z):
<x,y,z> * <nx,ny,nz> = k, unde <nx, ny, nz> este normala
Daca <x, y, z> * <nx, ny, nz> < k atunci ne aflam de-o parte a planului, daca nu de cealalta. Pentru ca aceasta metoda sa mearga trebuie sa avem grija sa ne definim toate suprafetele intr-un anumit sens, ori in sens orar, ori in sens antiorar, suprafetele fiind privite din partea vizibila.
In sens orar, pentru ca suprafata sa fie desenata trebuie ca produsul scalar dintre punctul din care privim si normala suprafetei sa fie mai mic decat 0, iar in sens antiorar produsul trebuie sa fie mai mare decat 0.
Arbori de partitionare binara a spatiului (BSP trees)
Problema cea mai mare a metodei Z-buffering este faptul ca se produce redesenarea. Sa presupunem ca desenam un obiect care este la o distanta foarte mare, iar apoi desenam un obiect care este la o distanta mai mica si care este pe aceeasi traiectorie. Este evident ca o mare parte din obiectul mai indepartat sau tot obiectul va fi acoperit de obiectul mai apropiat. Si atunci pe cel mai indepartat de ce sa il mai desenam. Chiar daca o parte din acesta ar ramane vizibila ar fi mai bine sa desenam mai intai obiectul cel mai apropiat si apoi pe cel mai indepartat pentru a evita redesenarea. Metoda de partitionare binara a spatiului isi propune tocmai acest lucru. Vom incerca sa sortam obiectele astfel incat cele care se afla mai aproape sa fie desenate inaintea celor mai indepartate. Daca veti incerca un algoritm oarecare de sortare a obiectelor veti observa ca nu veti reusi sa le mentineti in ordine.
In figura de mai sus ordinea in care vor trebui desenate suprafetele pentru a evita redesenarea este A, B, C. Obiectul B se afla inaintea obiectului C, dar obiectul A se afla inaintea obiectului B si deci acesta va fi primul care va fi desenat. Se poate observa ca daca obiectul A s-ar fi prelungit in spatele obiectului C, atunci nu ar mai fi posibila ordonarea. Dar daca obiectul A s-ar prelungi in spatele obiectului C, aceasta ar insemna ca obiectul A intretaie obiectul B. Deci cu alte cuvinte, pentru ca aceasta metoda de ordonare a obiectelor sa mearga este necesar ca obiectele sa nu se intersecteze unele cu altele.
Aceasta metoda de ordonare a obiectelor foloseste asa numitii arbori BSP (BINARY SPACE PARTITIONING), care sunt arbori binari. Fiecare nod al acestui arbore reprezinta un plan si, deoarece spatiul este infinit, putem spune ca imparte spatiul in doua jumatati. Putem numi cele doua jumatati "front" si "back", adica fata si spate. In figura 6 se poate observa un asemenea arbore in care literele b si f identifica subarborii "back" si "front".
Se poate observa ca suprafata A se afla in fata suprafetei B, iar suprafata C se afla in spatele suprafetei B.
Arborele BSP corespunzator figurii de mia sus este urmatorul:
Folosind arborii BSP, poligoanele fiecarui model (obiect) sunt reprezentate printr-un asemenea arbore. Parcurgerea arborelui se va face in felul urmator:
Se decide daca punctul din care privim se afla in fata sau in spatele planului reprezentat de catre nodul curent.
Daca punctul din care privim se afla in fata planului reprezentat de catre nodul curent vizitam mai intai subarborele "front", daca nu vizitam mai intai subarborele "back".
Dupa ce subarborele ales este parcurs, este redat poligonul reprezentat de catre nodul parinte.
Este parcurs si celalalt subarbore.
Texturarea suprafetelor
Figura 1.
Pentru orice poligon convex exista urmatoarele trei situatii:
Un singur punct se afla in spatele ecranului si atunci poligonul rezultat va avea in urma clipping-ului (taierii) un numar de puncte mai mare cu 1 decat poligonul original (Figura 1).
Doua puncte se afla in spatele ecranului si atunci numarul de puncte al poligonului ramane neschimbat, doar coordonatele celor ce se afla in spatele ecranului se schimba (Figura 2).
Mai mult decat doua puncte se afla in spatele ecranului. Daca "n" este nuamrul de puncte ale poligonului, iar "back" este numarul de puncte care se afla in spatele ecranului atunci numarul de puncte al poligonului rezultat in urma clipping-ului va fi n – back +2 (Figura 3).
Figura 2. Figura 3.
OBS.: la realizarea clipping-ului nu se va folosi planul ecranului, ci se va folosi un plan aflat putin mai in fata, paralel cu planul ecranului, deoarece planul ecranului se afla la coordonata Z = 0, iar la proiectarea punctelor obtinute in urma clipping-ului se va produce o impartire la 0. De asemenea intr-o vecinatate a acestui plan prin proiectarea acestor puncte se pot obtine valori foarte mari care ar putea depasi tipurile variabilelor pe care le folositi.
Pentru realizarea aplicari unei texturii asupra unei suprafete avem nevoie de coordonatele texturii in spatiu, textura fiind o suprafata rectangulara. Aceasta suprafata se poate afla in acelasi plan cu suprafata de desenat sau nu. De fiecare data cand vom misca sau roti punctul din care privim, coordonatele suprafetei pe care trebuie sa o desenam se vor modifica, si odata cu acestea coordonatele texturii corespunzatoare trebuiesc supuse acelorasi transformari.
O prima metoda ar fi crearea, la trasarea suprafetei, la fel ca la prima metoda de realizare a Z-buffering-ului, a cate doua bufere pentru coordonatele in textura (la Z-buffering se creau bufere pentru valorile distantelor), pentru punctele din care incepem trasarea liniei si pentru punctele in care se termina trasarea liniei. Coordonatele in textura vor fi variate uniform in functie de lungimea liniei de trasat. Deci pentru punctul din care incepem trasarea liniei vom avea doua coordonate tx1 si ty1 care reprezinta pozitia in textura a punctului, iar pentru punctul in care se termina trasarea liniei tx2 si ty2. Variatia poate fi calculata astfel:
Dx = (tx2 -tx1) / l
Dy = (ty2 – ty1) / l
, unde "l" este lungimea liniei de trasat.
O alta metoda, care spre deosebire de cea de mai sus realizeaza o texturare perfecta din punct de vedere matematic, va fi prezentata in continuare. Metoda de mai sus este o aproximare destul de grosolana, dar care da rezultate bune din punct de vedere al vitezei, si este foarte buna cand lucram cu obiecte compuse din foarte multe suprafete relativ mici si nu numai. Pentru anumite situatii si pentru anumite poligoane convexe poate da rezultate foarte bune. De asemenea, pentru un unghi mic intre normala planului si directia in care privim rezultatele sunt foarte bune.
Metoda pe care o voi prezenta in continuare foloseste efectiv notiuni de geometrie in spatiu, notiuni prezentate la sectiunea "Metode de ordonare a obiectelor".
Fie ecuatia planului A*x + B*y + C*z + D = 0 .
Cu ajutorul produsului scalar putem obtine cosinusul unghiului dintre cei doi vectori intre care facem produsul scalar, daca acesti vectori sunt vectori unitate. Fie punctul P(cx, cy), punctul pentru care dorim sa aflam coordonatele in cadrul texturii. Coordoantele spatiale ale acestui punct le vom obtine la fel ca la metoda a doua de la sectiunea "Z-buffering".
Figura 4.
Dupa cum se poate observa in Figura 4 coordonata x in textura este proiectia segmentului OP asupra segmentului OQ. Cu alte cuvinte x va fi egal cu OP inmultit cu cosinusul unghiului dintre cele doua laturi. Fie unghiul dintre segmentul OP si OQ. De aici rezulta:
cos() = [(P – O) / (PO)] * [(Q – O) / (QO)]
, unde "*" este produsul scalar. Vectorii au fost impartiti la lungimile lor pentru a fi vectori unitate.
x = PO * cos()
Substituind cos() in relatia aceasta rezulta:
x = (P – O) * (Q – O) / QO
Calcularea coordonatei y se va face in mod asemanator.
Tehnologii Web
De la aparitia HTML-ului, in anul 1990, Web-ul a suferit transformari majore – daca la inceput informatia era publicata intr-o forma statica, in prezent se insista pe aspectul grafic si pe interactivitate. Acest fapt a determinat aparita unor tehnologii menite sa faca fata noilor cerinte – Internet-ul devine Multimedia.
Daca multimedia se refera la date preasamblate si preprogramate, incluzand o suita de informatii din anumite medii, realitatea virtuala este dinamica si in interactiune permanenta cu receptorul ei. Multimedia este la baza bidimensionala, o serie de imagini prezentandu-se, conform unui scenariu predefinit, pe ecran, pe cand realitatea virtuala este tridimensionala, mult mai maleabila si intens interactiva, combinatie avansata de hardware si software multimedia.
Utilizatorul unui sistem virtual are libertatea de a explora lumea creata de calculator si de a interactiona direct cu ea.
Crearea unui spatiu virtual are similaritati cu procesul de proiectare urmat de arhitecti. In cartea sa ‘Towards a New Architecture’, Le Corbusier (Charles- Edouard Jeanneret) defineste arhitectura ca fiind ‘arta, un fenomen al emotiilor’. Manifestul sau, constand din faptul ca arhitectura se bazeaza pe trei elemente fundamentale, se poate aplica si in cazul realitatii virtuale.
Aceste elemente sunt:
– masa – lumea este construita din diverse forme (cuburi, conuri, sfere, cilindri, piramide) avand fiecare o masa;
– suprafata – o masa este ‘invelita’ de suprafata ei, suprafata dand individualitate fiecarei mase;
– planul – este generatorul lumii virtuale, ordonand-o si stabilind un set de reguli de constructie.
VRML 2
VRML a fost creat in primavara anului 1994, prezentat la prima conferinta WWW din Geneva, la dezvoltarea sa avandu-se in vedere independenta de platforma, extensibilitatea si abilitatea de a lucra in cadrul retelelor cu latime ingusta de banda. Dupa specificatia initiala VRML 1.0, a aparut VRML 1.1, in prezent fiind disponibila versiunea VRML 2.0.
In loc de a parcurge pagini cu imagini statice si de a urma hiper-legaturi, utilizatorii pot, de exemplu, sa umble pe coridoare si sa manipuleze obiecte, folosind o casca speciala de vizualizare (Head-Mounted Display: HMD) si o manusa pentru ‘comunicarea’ cu mediul. Mai nou, a aparut ecranul retinal
virtual (Virtual Retinal Display: VRD) pentru o explorare mai facila a lumilor 3D.
Crearea unui spatiu virtual are similaritati cu procesul de proiectare urmat de arhitecti. In cartea sa ‘Towards a New Architecture’, Le Corbusier (Charles- Edouard Jeanneret) defineste arhitectura ca fiind ‘arta, un fenomen al emotiilor’. Manifestul sau, constand din faptul ca arhitectura se bazeaza pe trei elemente fundamentale, se poate aplica si in cazul realitatii virtuale.
Pentru a genera un mediu in VRML trebuie avute in vedere urmatoarele:
– design si functionalitate
– originalitate
– proportie.
Noduri VRML
La baza, VRML manipuleaza obiecte, teoretic putand contine orice: forme geometrice 3D, imagini, sunet. Multimea de baza a obiectelor VRML consta din noduri. Nodurile formeaza structura initiala a tuturor lumilor VRML si se impart in urmatoarele categorii:
– noduri definind forme geometrice (sfere, solide rectangulare, etc): AsciiText, Cone, Cube, Cylinder, IndexedFaceSet, IndexedLineSet, PointSet, Sphere;
– noduri care specifica proprietatile si modul de aparitie a formelor: Coordinate3, FontStyle, Info, Material, MaterialBinding, Normal, ShapeHints, Texture2, TextureCoordinate2 etc.
– noduri ce transforma spatiul de lucru virtual: MatrixTransform, Rotation, Scale, Transform, Translation;
– noduri definind punctul de perspectiva (camera): OrthographicCamera, PerspectiveCamera;
– noduri care definesc modul de iluminare a obiectelor: DirectionalLight, PointLight, SpotLight;
– noduri de grupare: Group, Separator, Switch, TransformSeparator, WWWAnchor;
– noduri de import: WWWInline.
Sistemul de coordonate este cel cartezian tridimensional, unitatea de masura pentru distante fiind metrul, iar cea pentru unghiuri fiind gradul.
Campurile definind valori pentru proprietati pot fi de tip simplu (numar, vector, imagine) sau de tip compus. Tipurile de baza ale valorilor VRML sunt:
SFBitMask, SFBool, SFColor, SFEnum, SFFloat, SFImage, SFLong, SFMatrix, SFRotation, SFString, SFVec2f, SFVec3f (SF=Single value Field) sau MFColor, MFLong, MFVec2f, MFVec3f (MF=Multiple value Field).
Un exemplu:
#VRML 1.0 ascii
Separator {
DirectionalLight {
direction 0 0 -1
# directia de iluminare
}
Separator {
# creeaza o sfera violeta
Material {
diffuseColor 1 0 1
# culoare de forma RGB
}
Sphere {}
}
Separator {
Material {
# genereaza un cub verde
diffuseColor 0 1 0
}
Transform {
translation 0 2 0
# muta in sus (pe axa 0y) cu
}
# 2 m de la origine
Cube {}
# forma cubica de dimens.
implicite
}
Functionarea unui sistem VRML
Functiile de baza ale unui sistem (navigator) VRML se concretizeaza in:
– modelarea fiecarui obiect in cadrul lumii virtuale;
– stocarea si actualizarea informatiilor privind localizarea si aparenta fiecarui obiect (nod);
– simularea comportamentului obiectelor;
– desenarea lumii 3D;
– generarea sunetelor asociate obiectelor virtuale;
– navigarea prin mediul virtual;
– interactiunea utilizatorului cu obiectele din cadrul mediului.
Proiecte in domeniul realitatii virtuale distribuite:
Habitat – mediu virtual on-line multi-utilizator, rulat in cadrul retelei NiftyServe (Fujitsu), original conceput pentru Lucasfilm;
WorldsChat – mediu 3D social computerizat, permitand conversatii si explorari ale unor lumi virtuale
in Internet;
VirtualPolis – simularea unui oras accesibil via Internet, prototipul acestuia fiind prezentat la conferinta
VR’93 in Viena, bazat pe modelul clientserver;
CAVE Automatic Virtual Environment – sistem virtual distribuit pentru cercetari stiintifice.
SMIL
Pentru a crea prezentari multimedia pe Web, similare celor de la TV, Consortiul WWW a dezvoltat recent (a doua jumatate a anului 1998) un limbaj de specificare nou, descendent din XML 1.0, intitulat SMIL (Synchronized Multimedia Integration Language), oferind urmatoarele facilitati:
– descrierea comportamentului temporal al unei prezentari multimedia incluzand elemente text, audio, video, animatii;
– descrierea facila a aranjarii elementelor prezentarii in cadrul ecranului;
– asocierea de hiperlegaturi obiectelor multimedia in intregul lor sau partilor componente.
SMIL este asemanator HTML-ului, beneficiind de flexibilitatea limbajului XML (posibilitati de extindere) si imprumuta trasaturi ale foilor de stiluri specificate de CSS2 (Cascading Style Sheets level 2).
Structura unui document SMIL
Asa cum este de asteptat, un document SMIL este bazat pe marcatori delimitati intre < si >.
Elementul contine informatii independente de modul de desfasurare a prezentarii sau a prezentarilor multimedia si defineste aranjamentul in pagina Web a acesteia (eventual folosind alternative de afisare a obiectelor multimedia). Prin intermediul marcatorului se pot specifica pozitionari ale elementelor din corpul unui document SMIL, aceste pozitionari putand fi alese eventual dintr-un set de aranjamente (definite in diferite limbaje specifice: SMIL, CSS sau DSSSL).
Iata un exemplu care ilustreaza modul cum CSS2 poate fi utilizat ca o alternativa la aranjamentul de baza din SMIL:
s region=‘r1’ t { top: 20px;
left: 20px;
height: 200px; width: 300px }
s region=‘r2’ t { top: 400px;
left: 400px;
height: 100px; width: 50px }
height=‘200’ width=‘300’ />
height=‘100’ width=‘50’ />
v1.rm’ dur=‘30s’ />
src=‘http://www.infoiasi.ro/v/
v2.rm’ dur=‘2min’
repeat=‘2’ />
In doua zone de pe ecran vor fi afisate doua resurse: un film incarcat de pe un server aflat la distanta (care va dura 2 minute si va fi repetat de doua ori) si un film luat de pe serverul local (cu o durata de 30 de secunde).
Tag-ul poate contine definitii a mai multor regiuni de ecran (prin ) sau a unui aranjament general, utilizat de toate celelalte elemente (folosind ).
O regiune de document poate avea fixat un fundal (cu atributul background-color), o zona de ecran, in pixeli (atributele top, left, height, width), un identificator unic (atributul obligatoriu id), o maniera de incadrare a obiectului multimedia pe care il va contine: scalare, decupare, scrolling (atributul fit).
Coordonate. În cazul VRML s-a adoptat un sistem de coordonate cartezian tridimensional. În mod implicit, proiecția în planul ecranului se face în direcția axei Z pozitive, cu axa X pozitivă la dreapta și axa Y pozitivă în sus. Există un sistem de coordonate virtual general ("World Coordinate System") care conține mapările tuturor obiectelor din scena VR. După cum am arătat mai sus, transformările se cumulează coborând pe ierarhia grafului scenic.
Unități. VRML este definit foarte categoric din punctul de vedere al unităților de măsură. Toate distanțele sunt considerate ca fiind măsurate în metri, toate unghiurile sunt măsurate în radiani, timpul este măsurat în secunde, culorile sunt specificate în spațiul RGB prin numere între 0,0 și 1,0.
Prototipuri. Prototipizarea este un mecanism prin care un set de noduri existente poate fi extins conceptual prin crearea unei specificații pentru un nod nou'. Un prototip este compus din numele noului tip de nod, declarația de prototip care conține definirea evenimentelor și câmpurilor interne ale nodului, precum și definirea propriu-zisă a prototipului conținând o listă de unul sau mai multe noduri, rute și alte prototipuri. Deci un prototip definește numai un nou tip de nod ce poate fi creat din acel moment în scena VR și, în nici un caz, o instanță a acelui tip.
Altă facilitate oferită este aceea a referirii unor prototipuri ce apar în fișiere diferite sau chiar pe calculatoare diferite. Spre deosebire de prototiparea clasică, un prototip extern nu conține o implementare a noului tip de nod creat, ci doar o referință (de tip URL, de exemplu) la locul în care se găsește un prototip clasic, de unde acesta este preluat la momentul la care acest lucru este necesar. De asemenea, pentru a facilita crearea unor biblioteci de prototipuri, standardul VRML recunoaște sintaxa extinsă a URL-ului, putându-se astfel identifica simplu porțiuni în cadrul aceluiași fișier referit de URL-ul respectiv.
Mai jos va fi prezentat fisierul sursa cu magazinul virtual fara rafturi si fara produse. (Varianta VRML v2.0 utf8)
#VRML V2.0 utf8
DEF Group04 Transform {
translation -97.87 694.2 552.5
rotation 1 0 0 -1.571
children [
DEF Group04-TIMER TimeSensor { loop TRUE cycleInterval 3.333 },
DEF Group03 Transform {
translation 0 -1.086 -228.6
children [
DEF Group02 Transform {
translation 103.7 301.1 228.6
children [
DEF Tube01 Transform {
translation 0 -80.27 -1000
rotation -1 0 0 -1.571
scale 1 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0.45 0.45 0.45
shininess 0.3825
transparency 0.5
}
texture ImageTexture {
url "../maps/albastru.png"
}
}
geometry DEF Tube01-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube01-COORD Coordinate { point [
-320 0 2.798e-005, -320 2000 2.798e-005,
…………………………………………………………………………………………………
0.5 1, 0.5 0]
}
coordIndex [
0, 5, 4, -1, 0, 1, 5, -1, 1, 6, 5, -1, 1, 2, 6, –
……………………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
texCoordIndex [
0, 6, 5, -1, 0, 1, 6, -1, 1, 7, 6, -1, 1, 2, 7, –
……………………………………………………………………………………………………
106, 102, 103, -1, 106, 103, 104, -1]
}
}
]
},
DEF Cylinder02 Transform {
translation 4.578e-005 -80.27 -1010
rotation -1 0 0 -1.571
scale 1 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0.45 0.45 0.45
shininess 0.3825
transparency 0.5
}
texture ImageTexture {
url "../maps/albastru.png"
}
}
geometry DEF Cylinder02-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Cylinder02-COORD Coordinate { point [
0 0 0, 305 0 0, 301.2 0 -47.71, 290.1 0 -94.25,
……………………………………………………………………………………………
-0.025 0, -0.025 1]
}
coordIndex [
0, 2, 1, -1, 0, 3, 2, -1, 0, 4, 3, -1, 0, 5, 4, –
………………………………………………………………………………………………
22, 41, 42, -1, 22, 42, 43, -1]
}
}
]
},
DEF Cylinder03 Transform {
translation 4.578e-005 -80.27 1000
rotation -1 0 0 -1.571
scale 1 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0.45 0.45 0.45
shininess 0.3825
transparency 0.5
}
texture ImageTexture {
url "../maps/albastru.png"
}
}
geometry DEF Cylinder03-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Cylinder03-COORD Coordinate { point [
0 0 0, 305 0 0, 301.2 0 -47.71, 290.1 0 -94.25,
……………………………………………………………………………………
22, 41, 42, -1, 22, 42, 43, -1]
}
}
]
},
DEF Tube02 Transform {
translation 0 -80.27 -1000
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube02-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube02-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube03 Transform {
translation 0 -80.27 -724.4
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube03-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube03-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube04 Transform {
translation 0 -80.27 -524.4
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube04-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube04-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube05 Transform {
translation 0 -80.27 -324.4
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube05-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube05-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube06 Transform {
translation 0 -80.27 -124.4
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube06-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube06-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube07 Transform {
translation 0 -80.27 75.62
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube07-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube07-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube08 Transform {
translation 0 -80.27 275.6
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube08-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube08-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube09 Transform {
translation 0 -80.27 475.6
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube09-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube09-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube10 Transform {
translation 0 -80.27 675.6
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube10-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube10-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
},
DEF Tube11 Transform {
translation 0 -80.27 985
rotation -1 0 0 -1.571
scale 1.05 1 0.5017
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.349 0.349 0.349
ambientIntensity 1.0
specularColor 0.63 0.63 0.63
shininess 0.1925
transparency 0
}
}
geometry DEF Tube11-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Tube11-COORD Coordinate { point [
-305 0 2.666e-005, -305 15 2.666e-005, -287 15
…………………………………………………………………………………………
85, 82, 83, -1, 85, 83, 80, -1]
}
}
]
}
]
},
DEF Box03 Transform {
translation -1395 -380.3 228.6
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.05
transparency 0
}
texture ImageTexture {
url "../maps/boxSide.bmp"
}
}
geometry DEF Box03-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box03-COORD Coordinate { point [
-1.5 0 1500, 1.5 0 1500, -1.5 0 -1500, 1.5 0 -1500,
-1.5 600 1500, 1.5 600 1500, -1.5 600 -1500,
1.5 600 -1500]
}
texCoord DEF Box03-TEXCOORD TextureCoordinate { point [
19.99 0.0004998, 19.99 0.0004998, 0.00999 0.0004998,
0.00999 0.0004998, 19.99 0.9995, 19.99 0.9995,
0.00999 0.9995, 0.00999 0.9995]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
},
DEF Box01 Transform {
translation 103.7 -380.3 228.6
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0.225 0.225 0.225
shininess 0.145
transparency 0
}
texture ImageTexture {
url "../maps/boxDown.bmp"
}
}
geometry DEF Box01-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box01-COORD Coordinate { point [
-1500 0 1500, 1500 0 1500, -1500 0 -1500, 1500 0 -1500,
-1500 1 1500, 1500 1 1500, -1500 1 -1500, 1500 1 -1500]
}
texCoord DEF Box01-TEXCOORD TextureCoordinate { point [
0.01249 0.01249, 24.99 0.01249, 0.01249 24.99,
24.99 24.99, 0.01249 0.01249, 24.99 0.01249,
0.01249 24.99, 24.99 24.99]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
},
DEF Box04 Transform {
translation 103.7 -380.3 -1270
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.05
transparency 0
}
texture ImageTexture {
url "../maps/boxSide.bmp"
}
}
geometry DEF Box04-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box04-COORD Coordinate { point [
-1500 0 1.5, 1500 0 1.5, -1500 0 -1.5, 1500 0 -1.5,
-1500 600 1.5, 1500 600 1.5, -1500 600 -1.5,
1500 600 -1.5]
}
texCoord DEF Box04-TEXCOORD TextureCoordinate { point [
0.009991 0.0004995, 19.99 0.0004995, 0.009991 0.0004995,
19.99 0.0004995, 0.009991 0.9995, 19.99 0.9995,
0.009991 0.9995, 19.99 0.9995]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
},
DEF Box06 Transform {
translation 103.7 218.7 228.6
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0.225 0.225 0.225
shininess 0.145
transparency 0
}
texture ImageTexture {
url "../maps/boxUp.bmp"
}
}
geometry DEF Box06-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box06-COORD Coordinate { point [
-1500 0 1500, 1500 0 1500, -1500 0 -1500, 1500 0 –
…………………………………………………………………………………………
34, 16, 18, -1, 17, 36, 38, -1, 38, 19, 17, -1]
}
}
]
},
DEF Box02 Transform {
translation 103.7 -380.3 1727
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.05
transparency 0
}
texture ImageTexture {
url "../maps/boxSide.bmp"
}
}
geometry DEF Box02-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box02-COORD Coordinate { point [
-1500 0 1.5, 1500 0 1.5, -1500 0 -1.5, 1500 0 -1.5,
-1500 600 1.5, 1500 600 1.5, -1500 600 -1.5,
1500 600 -1.5]
}
texCoord DEF Box02-TEXCOORD TextureCoordinate { point [
0.009991 0.0004995, 19.99 0.0004995, 0.009991 0.0004995,
19.99 0.0004995, 0.009991 0.9995, 19.99 0.9995,
0.009991 0.9995, 19.99 0.9995]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
},
DEF Box07 Transform {
translation -1201 -380.3 -792.6
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.05
transparency 0
}
texture ImageTexture {
url "../maps/boxSide.bmp"
}
}
geometry DEF Box07-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box07-COORD Coordinate { point [
-403.2 0 0, 403.2 0 0, -403.2 0 0, 403.2 0 0,
-403.2 600 0, 403.2 600 0, -403.2 600 0, 403.2 600 0]
}
texCoord DEF Box07-TEXCOORD TextureCoordinate { point [
0.003497 0.0004995, 6.997 0.0004995, 0.003497 0.0004995,
6.997 0.0004995, 0.003497 0.9995, 6.997 0.9995,
0.003497 0.9995, 6.997 0.9995]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
},
DEF Box08 Transform {
translation -797.4 -380.3 -1261
rotation 0 -1 0 -1.571
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.05
transparency 0
}
texture ImageTexture {
url "../maps/boxSide.bmp"
}
}
geometry DEF Box08-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box08-COORD Coordinate { point [
-468 0 0, 468 0 0, -468 0 0, 468 0 0, -468 600 0,
468 600 0, -468 600 0, 468 600 0]
}
texCoord DEF Box08-TEXCOORD TextureCoordinate { point [
0.003497 0.0004995, 6.997 0.0004995, 0.003497 0.0004995,
6.997 0.0004995, 0.003497 0.9995, 6.997 0.9995,
0.003497 0.9995, 6.997 0.9995]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
},
DEF Box05 Transform {
translation 1602 -380.3 228.6
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.05
transparency 0
}
texture ImageTexture {
url "../maps/boxSide.bmp"
}
}
geometry DEF Box05-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box05-COORD Coordinate { point [
-1.5 0 1500, 1.5 0 1500, -1.5 0 -1500, 1.5 0 -1500,
-1.5 600 1500, 1.5 600 1500, -1.5 600 -1500,
1.5 600 -1500]
}
texCoord DEF Box05-TEXCOORD TextureCoordinate { point [
0.00999 0.0004995, 0.00999 0.0004995, 19.99 0.0004995,
19.99 0.0004995, 0.00999 0.9995, 0.00999 0.9995,
19.99 0.9995, 19.99 0.9995]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
}
}
]
}
]
},
DEF Box09 Transform {
translation 103.7 381.2 0
children [
Shape {
appearance Appearance {
material Material {
diffuseColor 0.5882 0.5882 0.5882
ambientIntensity 1.0
specularColor 0 0 0
shininess 0.145
transparency 0
}
texture ImageTexture {
url "../maps/CLOUD2.jpg"
}
}
geometry DEF Box09-FACES IndexedFaceSet {
ccw TRUE
solid TRUE
coord DEF Box09-COORD Coordinate { point [
-800 0 2000, 800 0 2000, -800 0 -2000, 800 0 -2000,
-800 0.2 2000, 800 0.2 2000, -800 0.2 -2000, 800 0.2 -2000]
}
texCoord DEF Box09-TEXCOORD TextureCoordinate { point [
0 0, 1 0, 0 1, 1 1, 0 0, 1 0, 0 1, 1 1, 0 0, 1 0,
0 1, 1 1]
}
coordIndex [
0, 2, 3, -1, 3, 1, 0, -1, 4, 5, 7, -1, 7, 6, 4, -1,
0, 1, 5, -1, 5, 4, 0, -1, 1, 3, 7, -1, 7, 5, 1, -1,
3, 2, 6, -1, 6, 7, 3, -1, 2, 0, 4, -1, 4, 6, 2, -1]
texCoordIndex [
9, 11, 10, -1, 10, 8, 9, -1, 8, 9, 11, -1, 11, 10, 8, -1,
4, 5, 7, -1, 7, 6, 4, -1, 0, 1, 3, -1, 3, 2, 0, -1,
4, 5, 7, -1, 7, 6, 4, -1, 0, 1, 3, -1, 3, 2, 0, -1]
}
}
]
}
]
}
Director – ShockWave
Cu produsul Director MX se pot crea aplicatii si continut prin combinarea de secvente audio, video, bitmaps, vectori, text, fonturi si multe altele. Produsul functioneaza eficient cu interfata Macromedia MX pentru utilizatori si puteti beneficia si de avantajele fara precedent ale integrarii cu Macromedia Flash MX. Va puteti dimensiona aplicatiile cu o arhitectura plug-in extensibila.
Macromedia Director MX combina orice media si trimite oriunde continutul, atunci cand este online cat si atunci cand este offline. Integreaza usor diferite tipuri de media, incluzand formate video (RealVideo, QuickTime si AVI), audio (MP3, WAV, AIF si RealAudio), bitmap (JPG, GIF, PNG, BMP, PSD, TIFF si PICT) si vector (SWF).
Realizat astfel incat sa faca fata tuturor datelor de pe mediile fixate, Director MX incarca si descarca rapid datele in memoria sistemului pentru play back -uri pe CD sau DVD. Apoi continutul poate fi trimis catre Shockwave Player.
Se adauga facilitati si functionalitati cu extensiile Xtra, care sunt parte componenta a arhitecturii extensibile plug-in din Director MX. Se pot crea aplicatii complete care pot accesa, lansa sau controla alte aplicatii din cadrul executabilului Director MX.
Se lucreaza in mod asemanator ca si cu produsele din familia Macromedia Flash MX, si se creaza continut dinamic bogat si aplicatii exceptionale. De fapt, cei mai multi utilizatori ai produsului Director MX combina puterea produsului Macromedia Flash MX cu cea a Directorului MX pentru a folosi la capacitate maxima ambele produse. Se pot importa fisiere Macromedia Flash si se pot modifica rapid cu noile caracteristici Macromedia Flash MX Launch and Edit.
Se reduce timpul de dezvoltare cu noul control Lingo asupra obiectelor Macromedia Flash MX. Puteti avea acces complet la toate proprietatile si metodele obiectelor Macromedia Flash MX predefinite.
Se pot folosi tehnologiile de server Macromedia cu Director-ul MX.
Se pot crea jocuri multiuser, aplicatii pentru invatamant la distanta si puteti avea colaborari in timp real cu Macromedia Flash MX Communication Server. Se pot trimite date catre Macromedia ColdFusion MX si se pot primi inapoi cu Macromedia Flash MX Remoting Service, care este o conexiune sigura, de inalta performanta intre ColdFusion Mx si Shockwave Player.
Caracteristici:
Design-ul este familiar si conform cu celelalte produse Macromedia MX .
Answers panel: acces imediat la suport, sfaturi si alte resurse disponibile pe site-ul dumneavoastra.
Peste 40 de tipuri de media: suport pentru multiple formate grafice (incluzand canalele alpha), QuickTime, AVI, MP3, WAV,AIFF, animatii, sincronizare. compunere avansata de imagini si efecte playback de sunet.
Control precis al sunetului
Rotatii, micsorari, si multe altele cu motorul de animatii din Director MX.
QuickTime 6 Xtra: Beneficiati de avantajele facilitatilor Apple QuickTime 6, incluzand si suportul pentru MPEG4.
Aplicatii de sine-statatoare: Produsul ofera iesire catre CD, DVD-ROM, chioscuri etc, prin folosirea executabilelor de sine statatoare.
Suport Microsoft Windows si Apple Machintosh: Se creaza platforme cu continut accesibil pe platforme diverse.
Speech Xtra: Se realizeaza automat conversia text-to-speech, fara a fi nevoie de un screen reader.
Noile metode Global Lingo: Se realizeaza conversia textului in sunet si se controleaza volumul si formatul audio.
Integrare de continut HTML: Se importa text de tip HTML in Director MX, mentinand intotdeauna controlul asupra tuturor referintelor de legatura.
Parsare XML: Se trimit constructori complecsi care pot fi controlati si manipulati fara a descarca fisiere mari.
Suport Macromedia Flash Comunication Server: Se pot accesa camere USB sau FireWare, microfoane instalate si multe altele.
Control Lingo asupra obiectelor Macromedia Flash: Se reduce timpul de dezvoltare prin aducerea si setarea tuturor proprietatilor unor obiecte predefinite Macromedia Flash.
Extensii Xtra: Se extinde functionalitatea Director MX cu arhitectura Macromedia Open Architecture (MOA).
Multi-Resolution Mesh (MRM): Puteti controla numarul de poligoane folosite pentru vizualizarea unui obiect, tinand cont de distanta pana la camera, rata cadrului si de alte conditii.
Director 8 conține o gamă largă de noi caracteristici, generate majoritatea de feedback-ul utilizatorilor. In aproape fiecare aspect al programului a crescut performanța. Următoarele secțiuni includ un rezumat al acelor noi caracteristici.
Director 8 prezintă mai multe caracteristici majore, care simplifică mult creația de multimedia, toate fiind tratate în cele ce urmează:
• Property Inspector – Property Inspector a devenit o singură fereastră care-și schimbă formatul corespunzător selecției. Aceasta poate afișa informații despre membri, imagini de sprite (Sprite – În traducere literară „spiriduș“. În grafica pe calculator, mică imagine ce poate fi mutată pe ecran independent de celelalte imagini din fundal. Spiridușii sunt utilizați pe scară largă în secvențele animate și în jocurile video. (n.t.)), elemente de interfață și chiar fereastra Stage în sine.
• Scenă (Stage) căreia i se poate aplica zoom – Se poate apropia (zoom in) sau îndepărta (zoom out) conținutul ferestrelor Stage pentru a arăta mai multe sau mai puține detalii. În plus, Stage poate fi extinsă pentru a depăși marginile ferestrei Stage, astfel încât să puteți lucra cu elemente care sunt în afara dreptunghiului Stage.
• Cast Window List View – Se pot alege acum între modul de vizualizare standard „celulă“ al unei distribuții (cast) sau un mod de vizualizare de tip listă. Ultimul asigură sortarea după diferite proprietăți.
• Imagini Sprite fixabile – Se pot fixa acum pe loc imaginile sprite. Deși acestea pot fi deblocate ușor, astfel se previn modificările accidentale ale imaginilor sprite, precum și modificări făcute de autori de multimedia care lucrează la film.
• Linii de orientare – Ca în programele de machetare, se pot stabili acum în Stage linii de orientare orizontale și verticale, pentru a ajuta la alinierea obiectelor.
• Câmpuri de gestionare a bunurilor – Fiecare membru al distribuției (cast member) are acum un creator, o dată a creării, o dată a modificării și un câmp de comentariu. Se pot folosi pe acestea pentru a organiza și întreține distribuția.
Scripturi legate
Se pot avea avea fișiere de text externe care sunt folosite ca scripturi Lingo. Filmele pot partaja scripturi și puteți folosi cu ușurință editoare de text externe pentru a le edita.
Imbunătățiri generale în Lingo
În general, performanța limbajului Lingo a fost optimizată. Unele noi caracteristici specifice:
• Timeout – Acest nou tip de obiect care permite stabilirea de cronometre care apelează handlere la anumite intervale de timp.
• flushInputEvents – Acum se pot șterge clicurile de mouse și apăsările de taste, care este posibil să fi avut loc în timp ce utilizatorii așteptau încărcarea unui film sau încheierea unei transmisii.
• isOKToAttach – Acum se poate stabili atașarea comportamentelor doar la anumite tipuri de imagini sprite.
• scriptList – Întreaga listă de scripturi a unui sprite poate fi acum verificată și stabilită cu Lingo, iar Score va reflecta orice modificări.
• Operații la nivel de bit – Funcțiile bitAnd, bitNot și bitXOr permit să se efectueze operații la nivel de bit asupra variabilelor.
• Conștientizarea aplicației – Handlerele de evenimente activateApplication și deactivateApplication permit detectarea când este trimis un proiector în fundal sau când este adus în prim-plan.
• Detectarea handlerelor – Funcțiile handler și handlers permit testarea existenței unui handler într-un script.
• the markerList – O alternativă la the labelList care întoarce o listă de marcaje (Nume dat unui cadru în fereastra Score) (marker) Lingo corectă.
Lingo și imaginile
Creatorii de lucrări cu Director au control direct asupra fiecărui pixel din membrii-bitmap. Noile comenzi, cum ar fi copyPixels, getPixel, setPixel, draw și fill, permit crearea și modificarea bitmap-uri.
Scalarea cu Shockwave
Îmbunătățirea principală din Shockwave este că acum filmele se pot scala, ca filmele Flash. Asta înseamnă că puteți face un film Shockwave să umple fereastra utilizatorului, iar filmul se va întinde pentru a face acest lucru, oricare ar fi dimensiunea ferestrei.
Vectori multicurbă
Formele vectoriale pot conține acum mai multe curbe.
Introducerea textului editabil
Inline IME (Input Method Editor) acceptă introducerea caracterelor multioctet, cum ar fi cele utilizate în alte limbi decât engleza, în membri-text editabili. Comenzile de editare standard, cum ar fi copierea, tăierea și lipirea pot fi și ele utilizate în membrii-text editabili.
Noi comportamente în bibliotecă
Biblioteca de comportamente din Director 8 include toate favoritele din Director 7, plus multe altele noi. Există un întreg set de comportamente care utilizează noul Lingo pentru imagini, pentru a crea tranziții sprite individuale; un alt set creează o canava pentru desen și mai există un set pentru crearea unei camere de discuții multiutilizator.
Parametrii de compresie a imaginii
Exista posibilitatea de a utiliza compresia JPEG pentru bitmap-uri când se salveaza filmul ca film Shockwave. Se poate selecta un parametru de comprimare diferit pentru fiecare bitmap și un parametru prestabilit pentru întregul film.
Controlul sunetului
Deși Score poate trata sunetele de fundal și comportamentele din bibliotecă pot adăuga sunete la butoane și la alte elemente simple, cunoașterea comenzilor Lingo care controlează sunetul este necesară pentru utilizarea sunetului în programe Director cu diferite efecte. Toate cele trei tipuri principale de sunet – membri interni ai distribuției, fișiere externe și secvențe audio Shockwave – pot fi controlate cu Lingo
Utilizarea comenzilor Lingo pentru sunet
Director 8 prezintă o cale cu totul nouă de redare a sunetelor cu Lingo. Aceste noi comenzi pentru sunet înlocuiesc vechea comandă puppetSound care funcționează în continuare.
Numărul 1 reprezintă primul canal Sound. Cuvântul „membrulMeuSunet“ reprezintă un membru al distribuției. Dacă în canalul Sound 1 din Score e redat deja un sunet, atunci e înlocuit cu sunetul din acest membru. Sunetul este redat imediat; nu așteaptă reluarea cadrului sau o comandă updateStage pentru a începe.
Se mai pot reda sunete în canalul Sound 1 cu o simplă comandă puppetSound:
puppetSound "membrulMeuSunet"
Utilizarea acestei comenzi diferă în două privințe de utilizarea comenzii puppetSound cu un număr de canal. Mai întâi, sunetul nu începe redarea până nu începe cadrul următor sau până nu e folosită o comandă updateStage. A doua diferență este aceea că e folosit primul canal Sound disponibil. De aceea, dacă sunt ocupate canalele Sound 1 și 2, va fi folosit canalul 3.
Se pot utiliza canalele Sound de la 1 la 8., chiar dacă în Score sunt disponibile doar primele două.
Pentru a opri redarea unui sunet și a returna către fereastra Score controlul asupra canalului Sound, emiteți doar o comandă puppetSound cu un 0 ca membru, astfel:
puppetSound 1, ?
Comenzi Lingo noi pentru sunet
Noul mod în care Director redă sunetele gravitează în jurul obiectului sound.
Acesta se aseamănă foarte mult cu obiectul sprite care se asociază cu un canal Sprite din Score. Obiectul sound este asociat cu un canal Sound. Există un total de opt canale Sound pe care le puteți utiliza. O cale rapidă de a reda un sunet:
sound(1).play(member("sunetulMeu"))
Funcția play ia un membru-sunet drept singurul său parametru. Începe să încarce sunetul, după care îl redă când a încărcat suficient din el. Se pot experimenta uneori, dar nu de obicei, o întârziere în timp ce sunetul se încarcă.
Se mai poate adăuga un sunet în coada pentru redare, după care se poate reda cu play. Exemplu:
sound(1).queue(member("sunetulMeu"))
sound(1).play()
În loc să se transmita un întreg membru-sunet funcției queue sau play, se poate transmite o listă de proprietăți cu mai multe informații. De exemplu, se poate include proprietatea #preloadTime pentru a preciza cât din sunet trebuie încărcat înainte să înceapă redarea. Timpul este exprimat în milisecunde.
sound(1).queue([#member: member("sunetulMeu"), \
#preloadTime: 1???)
Se pot folosi mai multe funcții queue pentru a stabili redarea mai multor sunete, unul după altul. Când e folosită comanda play, sunt redate toate sunetele, fără pauză între ele.
sound(1).queue(member("ragtime"))
sound(1).queue(member("wacky"))
sound(1).play()
Utilizând proprietățile #startTime și #endTime se poate reda doar un fragment dintr-un sunet. Timpul este exprimat în milisecunde.
sound(1).setPlayList([ \
[#member: member("ragtime"), \
#startTime: 76?4, \
#endTime: 1?1?5]])
sound(1).play()
Se poate determina și reluarea sunetului de un număr finit de ori, folosind proprietatea #loopCount.
sound(1).queue( \
[#member: member("ragtime"), \
#startTime: 1?1?5, \
#loopCount: 3, \
#endTime: 15?17]])
sound(1).play()
Lista de proprietăți folosită într-o comandă queue sau play poate deveni complexă. Nu numai că se poate specifica momentul de pornire și momentul de oprire ale redării sunetului, ci se pot stabili momente de pornire și de oprire diferite pentru un ciclu din sunet. De exemplu, să presupunem că se doreste ca sunetul să fie redat de la început, până la milisecunda 10105, după care să revină la 7604, să repete acest lucru de trei ori și să continue până la terminarea sunetului. Următoarea secvență face acest lucru:
sound(1).queue( \
[#member: member("ragtime"), \
#loopStartTime: 76?4, \
#loopCount: 3, \
#loopEndTime: 1?1?5]])
sound(1).play()
Alte comenzi pentru sunet
Mai există multe alte proprietăți, comenzi și funcții pentru sunet, care pot schimba modul de redare a unui sunet. Toate comenzile din lista următoare pot fi folosite după un obiect-sunet care utilizează sintaxa cu punct, la fel cum au fost folosite comenzile play și queue.
• breakLoop() – Când un sunet este în curs de reluare (ciclare) această comandă permite sunetului să depășească sfârșitul ciclului și să continue redarea restului sunetului.
• isBusy() – Întoarce TRUE în cazul în care canalul Sound este utilizat în mod curent pentru a reda un sunet.
• fadeIn(s) – Stabilește volumul sunetului la 0, după care crește volumul pe durata a s milisecunde, până se ajunge la volumul integral.
• fadeOut(s) – La fel ca fadeIn dar în sens invers.
• fadeTo(v,s) – Mută volumul sunetului la v (un număr între 0 și 255) în s milisecunde.
• getPlayList() – Întoarce lista de redare pentru canalul Sound.
• setPlayList() – În loc să folosiți mai multe comenzi queue, puteți întocmi întreaga listă de redare a unui canal Sound trimițându-i o listă de membri-sunet sau o listă de proprietăți.
• pause() – Oprește sunetul, permițându-vă să folosiți comanda play() pentru a-l relua din același punct.
• playNext() – Trece imediat la următorul sunet din coadă.
• rewind() – Readuce sunetul curent la început.
• stop() – Oprește sunetul. Orice membri-sunet care mai sunt în coadă în bufferul de sunet rămân acolo, pregătiți pentru următoarea comandă play().
• showProps() – Afișează în fereastra Message toate proprietățile canalului Sound.
În plus față de aceste comenzi, mai există un număr de proprietăți ale sunetului. Urmează o listă completă:
• channelCount – Întoarce numărul de canale Sound dintr-un membru-sunet. De exemplu, o valoare egală cu 2 vă spune că sunetul e stereo.
• currentTime – Timpul curent în milisecunde scurs pentru redarea unui sunet. Această proprietate poate fi acum stabilită în Director 8.
• elapsedTime – Numărul de milisecunde de redare a sunetului. Numărul continuă să crească, indiferent de cicluri sau de modificările aduse lui currentTime.
• endTime – Timpul de încheiere, în milisecunde, al sunetului redat curent.
• loop – O proprietate de membru. Aceasta este echivalentă cu proprietatea loop din caseta de dialog Sound Cast Member. Îi puteți schimba valoarea cu această proprietate Lingo.
• loopCount – De câte ori e pus acest sunet să se reia. Valoarea 0 înseamnă că sunetul se reia la infinit.
• loopEndTime – Timpul de încheiere a ciclului din sunetul curent.
• loopStartTime – Timpul de începere a ciclului din sunetul curent.
• loopsRemaining – În cazul în care sunetul ciclează în mod curent, această proprietate întoarce numărul de cicluri care au mai rămas de parcurs.
• member – Referința de membru a sunetului redat curent.
• pan – Vă permite să schimbați balansul unui sunet. –100 înseamnă că tot sunetul vine din difuzorul din stânga, iar 100 înseamnă că tot sunetul vine din cel din dreapta.
• preloadTime – Numărul de milisecunde de sunet care se încarcă înainte să înceapă redarea. Valoarea prestabilită e de 1500.
• sampleCount – Rata de biți a sunetului, luând în calcul faptul că sunetul e mono, respectiv stereo.
• sampleRate – Întoarce rata frecvenței de eșantionare a membrului-sunet.
• sampleSize – Întoarce dimensiunea eșantionului, în biți, a membrului-sunet. Valori obișnuite sunt 8 sau 16.
• startTime – Timpul de pornire a sunetului redat curent în canal.
• status – Întoarce fie 0 pentru nimic, 1 pentru încărcare, 2 pentru adăugare în coadă, 3 pentru redare sau 4 pentru întrerupere.
• volume – Vă permite să stabiliți volumul, de la 0 la 255, al unui canal Sound.
Un exemplu de comportament care redă un sunet în canalul 1 cu un pan bazat pe poziția sprite-ului. Pe măsură ce sprite-ul se deplasează în Stage, pan face sunetul să vină mai dinspre difuzorul din stânga sau din dreapta, corespunzător poziției sprite-ului.
property pSound
on getPropertyDescritionList me
list = [:]
addProp list, #pSound, \
[#comment: "Sound", \
#format: #sound, \
#default: ""]
return list
end
on beginSprite me
sound(1).queue(pSound)
sound(1).play()
end
on exitFrame me
x = sprite(me.spriteNum).locH
stageWidth = (the Stage).drawRect.width
p = 2??*x/stageWidth-1??
sound(1).pan = p
end
on endSprite me
sound(1).stop()
end
Mai există multe proprietăți pentru determinarea capacității calculatorului de a reda sunete:
• the multiSound – Aceasta este TRUE în cazul în care calculatorul acceptă redarea mai multor sunete simultan.
• the soundDevice – Această proprietate vă spune care dispozitiv din sistem este utilizat pentru redarea sunetelor. Proprietatea poate avea de obicei trei valori: „MacSoundManager“, „Macromix“ și „QT3Mix“. Prima e disponibilă doar pentru Mac și funcționează destul de bine. „Macromix“ e disponibilă doar pentru calculatoarele care rulează Windows, fără QuickTime 3, și este foarte lentă. Dacă filmul e redat sub Windows și aveți instalat QuickTime 3, ar trebui să-i atribuiți acestei proprietăți „QT3Mix“ pentru performanțe maxime.
• the soundDeviceList – Această proprietate întoarce o listă de dispozitive de sunet curent disponibile.
• the soundEnabled – Această proprietate vă furnizează o funcție pentru sunet mut. Dacă o stabiliți la FALSE, sunetul nu se mai aude dar valoarea proprietății de volum nu se schimbă, așa că se folosește același nivel de volum când proprietatea soundEnabled e stabilită din nou la TRUE.
Utilizarea punctelor de referință
Accesul în Lingo la informațiile despre punctele de referință este simplu. Există o mulțime de comenzi și funcții pe care le puteți utiliza, după cum se descrie în continuare:
• cuePointNames – O proprietate de membru-sunet, care întoarce o listă de puncte de referință din sunet.
• cuePointTimes – O proprietate de membru-sunet, care întoarce o listă de momente, în milisecunde, când apar puncte de referință.
• mostRecentCuePoint – Întoarce numărul celui mai recent punct de referință dintr-un membru-sunet sau dintr-un canal Sound, care a fost transmis.
• isPastCuePoint – Vă spune dacă sunetul a transmis deja un număr de punct de referință.
• on cuePassed – Un handler care răspunde la evenimentul unui punct de referință dintr-un sunet, care a fost transmis.
SFAT – Toată sintaxa punctelor de referință poate fi folosită și pentru secvențele video digitale. Specificați doar numărul de canal Sprite în care e secvența, în locul numărului de canal Sound.
Utilizând cuePointNames și cuePointTimes împreună, Se pot avea liste atât cu numele punctelor de referință cât și cu momentele exacte când apar.
Adăugarea punctelor de referință la un sunet e ceva ce se realizează în programe de editare a sunetului. Metoda de adăugare variază de la un program la altul.
Pentru a sincroniza o prezentare sau o animație cu un sunet, se poate folosi un handler on cuePassed simplu într-un comportament de cadru. Următorul comportament reține filmul la cadrul curent în timp ce e redat sunetul. Apoi, când apare un punct de referință, face filmul să sară la un cadru etichetat cu exact același nume ca al punctului de referință.
on exitFrame me
go to the frame
end
on cuePassed me, whichChannel, cuePointNumber, cuePointName
member("cue").text = cuePointName
go to frame cuePointName
end
În plus, acest comportament plasează numele punctului de referință într-un membru-text. Se poate folosi o tehnică precum aceasta pentru a afișa texte de piese muzicale pentru a acompania melodia. Se plaseaza doar versurile în fișierul de sunet, ca puncte de referință. După aceea se utilizeaza handlerul on cuePassed pentru a arunca punctele de referință într-un membru-text.
Redarea sunetelor externe
Redarea celor mai multe sunete externe e exact la fel ca redarea membrilor-sunet din Internet. Tot ce trebuie să se faca este să se importe ca fișiere legate. Membrul-sunet face referire la acest fișier extern pentru datele de sunet, dar toate comenzile Lingo îl tratează ca sunet intern.
Se mai poate reda un fișier de sunet care nu e legat ca membru al distribuției. Doar o comandă formată din două cuvinte execută această acțiune: sound playFile. Exemplu:
sound playFile 1, "sunetulMeu.aif"
Acest sunet redă fișierul specificat în canalul 1. Dacă fișierul nu e în același dosar ca filmul, ar trebuie precizata o cale de fișier completă.
Avantajul principal al redării fișierelor de sunet externe este că Director le derulează continuu de pe unitatea de disc sau de pe CD-ROM. Asta înseamnă că nu trebuie încărcat întregul sunet în memorie înainte de a fi redat.
Comanda sound playFile poate reda fișiere AIFF sau wave, cele mai obișnuite formate de fișier pentru Mac, respectiv Windows. Poate reda și fișiere Shockwave audio. Sunetele formatate ca „AU“ pot fi redate atâta timp cât aplicația Sun AU Import Xtra e prezentă.
Pentru a opri un sunet care a fost pornit cu comanda sound playFile, se foloseste comanda puppetSound cu canalul Sound și 0 drept nume de sunet, cum ar fi:
puppetSound 1, ?
Mai există și o comandă perimată, stop, care face același lucru, dar care probabil nu va mai fi acceptată în viitor.
Utilizarea pieselor audio Shockwave
Redarea pieselor Shockwave audio e puțin diferită față de redarea sunetelor obișnuite. Pentru a reda sunete Shockwave audio trebuie să se creeze un membru al distribuției Shockwave audio. Se poate face asta selectând Insert, Media Element, Shockwave Audio.
Cea mai importantă parte din această casetă de dialog este Link Address, care precizează calea completă sau relativă a fișierului audio Shockwave. În cazul în care calea e relativă iar filmul e redat în Director sau într-un proiector, calea poate preciza un fișier de pe unitatea de disc sau de pe CD-ROM, nu din Internet.
Se poate folosi caseta de dialog Import pentru a importa complet un sunet SWA astfel încât să fie conținut în biblioteca de distribuție internă. În orice caz, asta anulează scopul derulării continue, care e să redea fișiere de sunet foarte mari fără a necesita mai întâi încărcarea lor completă în memorie. Sunetele SWA interne nu funcționează în Shockwave.
După ce a fost creat un membru Shockwave audio, se poate folosi și proprietatea url pentru a schimba poziția unui fișier în Lingo. Asta înseamnă că e necesar doar un membru pentru a reda mai multe fișiere, atâta timp cât fișierele sunt redate la momente diferite.
Pentru a începe redarea unui fișier Shockwave audio se foloseste comanda play, astfel:
play member "sunetulMeu.swa"
Comanda stop oprește redarea, astfel:
stop member "sunetulMeu.swa"
Comanda pause permite oprirea sunetului, dar după aceea se foloseste comanda play pentru a reîncepe redarea din același punct, nu de la începutul sunetului.
Listă completă a proprietăților membrilor:
• bitRate – Întoarce rata de biți, în kbps, a fișierului.
• bitsPerSample – Întoarce dimensiunea, în biți, a fiecărui eșantion. Valori obișnuite sunt 8 și 16.
• copyrightInfo – Întoarce informațiile de drepturi de autor stabilite la crearea fișierului Shockwave.
• duration – Întoarce lungimea sunetului în tacturi (1/60 dintr-o secundă).
• numChannels – Întoarce numărul de canale din sunet. De exemplu, 2 înseamnă stereo.
• percentStreamed – Întoarce o valoare între 0 și 100 care corespunde la cât de mult din fișier a fost citit din Internet.
• percentPlayed – Întoarce o valoare între 0 și 100 care corespunde la cât de mult din fișier a fost redat.
• preloadTime – Cantitatea din fișier care ar trebui încărcată în memorie înainte să înceapă redarea, exprimată în secunde.
• sampleRate – Rata frecvenței sunetului.
• soundChannel – Proprietatea de memorie care determină ce canal Sound e utilizat pentru redarea sunetului. Dacă se dă valoarea 0, Director alege primul canal Sound disponibil.
• state – Întoarce o valoare care vă spune ce face membrul în orice moment.
• streamName – La fel ca proprietatea url.
• url – Adresa fișierului Shockwave audio. Se poate stabili și restabili această proprietate pentru a reutiliza un membru. Astfel se pot reda fișiere audio diferite folosind același membru.
• volume – Volumul sunetului. O valoare între 0 și 255.
Stare Definiție
0 Derularea continuă din Cast s-a oprit.
1 Membrul distribuției se reîncarcă.
2 Preîncărcarea s-a încheiat cu succes.
3 Membrul distribuției este redat.
4 Redarea membrului distribuției este întreruptă.
5 Pentru membrul distribuției s-a încheiat derularea continuă.
9 A apărut o eroare.
Viteza CPU (unitatea centrală) e insuficientă.
Medii Virtuale Distribuite
Un mediu virtual distribuit reprezintă un sistem software care permite interacțiunea în timp-real, de la distanță, a mai multor utilizatori, încorporând grafică 3D și sunet stereo.
Caracterizare
Un mediu virtual distribuit se bucură de următoarele caracteristici principale:
Iluzia spațiului comun: toți participanții au iluzia localizării în același spațiu tridimensional (aceeași cameră sau clădire ori același areal). De cele mai multe ori, spațiul este fictiv, generat electronic, dar trebuie să prezinte aceleași proprietăți pentru toți utilizatorii (aspect meteorologic, acustică, textură etc.).
Iluzia prezenței comune: Fiecare dintre participanți ia forma unei persoane virtuale, numită avatar, care are, printre altele, asociate următoarele:
o reprezentare grafică (pe cât posibil, cât mai realistă);
un model al structurii corpului (prezența membrelor, antenelor etc.);
un model al deplasării (mulțimea mișcărilor și gesturilor pe care le poate executa);
un model fizic (e.g. greutate, înălțime etc.).
Un avatar nu trebuie să posede formă umanoidă și un utilizator poate avea asociate mai multe reprezentări de tip avatar. Nu toți participanții din cadrul mediului virtual trebuie să fie controlați de om, o parte dintre avatari putând fi creați de program, având sau nu inteligență artificială.
Iluzia timpului comun: mediul virtual distribuit permite interacțiunea în timp-real dintre utilizatori.
Posibilitatea comunicării: posibilitățile comunicării includ comunicarea prin gesturi, prin text introdus de la un dispozitiv de intrare sau prin voce.
Partajarea Informațiilor: în afara faptului de a facilita comunicarea dintre utilizatori, sistemul oferă posibilitatea de a interacționa cu mediul virtual (de exemplu, participanții la o simulare virtuală pot selecta, muta, transforma obiecte care există în mediu și pot să le dea altor utilizatori).
Un proiectant de mediu virtual distribuit poate oferi utilizatorilor libertatea de a construi edificii, de a desena pe o tablă sau chiar de a distruge mediul.
Conectarea mai multor utilizatori la sistem diferențiază mediile virtuale distribuite de realitatea virtuală obișnuită. Abilitatea de a partaja diverse obiecte ale mediului îi conferă o nouă dimensiune, față de serviciile conversaționale clasice (cfiaf-uii, sisteme de tele-con-ferințe). Interactivitatea în timp-real este o altă caracteristică suplimentară, care nu apare la navigatoarele Web sau la serviciile de poștă electronică.
Mediile virtuale distribuite sunt cele mai indicate pentru aplicații necesitând crearea tele-prezențel.
Un mediu virtual distribuit prezintă următoarea structură:
motoare și display-ere grafice (stații de lucru grafice, deseori suportând OpenGL, căști de vizualizare, ecrane retinale etc.);
dispozitive de comunicare și control (tastatură, mouse, joystick, mănușă senzorială, detectoare de mișcare, microfoane, boxe audio și altele);
• sisteme de procesare distribuită;
• rețele (rapide, locale: Ethernet, Token Ring sau mondiale: ISDN(IntegratedServices Dls-trlbutlon Network), DSI (Defense Slmulatlon
Internet), comunicarea realizându-se printr-un protocol special: VR.TP (Virtual Reallty Transfer Protocol) sau folosindu-se standardul Llvlng Worlds).
Problemele care pot surveni în implementarea și funcționarea unui mediu virtual distribuit sunt, în principal, cele legate de managementul în timp-real al resurselor, pierderea de date, lărgimea de bandă, eterogenitatea și scalabilitatea echipamentelor, configurarea și exploatarea software-ului.
Mediile virtuale distribuite sunt, concomitent, sisteme distribuite, aplicații grafice și aplicații Interactive, integrând sisteme de baze de date (utile pentru memorarea datelor persistente care generează mediul: forme și localizări de obiecte, texturi, informații despre avatari etc.), interacționând cu sisteme tranzacționale (de comerț electronic, de exemplu) și trebuind să asigure autentificarea utilizatorilor și jurnalizarea activităților.
Origini
Istoria mediilor virtuale distribuite începe cu … Mediile virtuale militare. Unul dintre cele mai cunoscute este SIMNET (Simulator Net-worklng), dezvoltat pentru DARPA începând cu 1983 și dat în folosință abia în anul 1990, jucând un rol destul de important și în operațiunea „Furtună în Deșert" de peste câțiva ani. Scopul proiectului a fost dezvoltarea unui mediu virtual distribuit ieftin pentru antrenarea unor unități militare cu efectiv restrâns. Din ideile și succesul lui SIMNET ia ființă un protocol denumit Dlstrlbuted Interactive Slmulatlon (DIS), standardizat în 1993 (IEEE 1278), având un ecou răsunător în domeniul militar, dar prezentând unele inconveniente ca numărul redus de participanți (maxim 300 de utilizatori concomitent), mărimea pachetelor de date și necesități hardware destul de însemnate (pentru simulări cu un grad mare de realism se folosesc numai stații SGI). SIM-NET și ulterior DIS folosesc o tehnică specială numită dead-reckoning pentru evitarea inundării rețelei cu pachete de date. Jocurile în rețea. Conceput inițial de Gary Tarolll de la Silicon Graphics Inc. (SGI), simulator de zbor disponibil în premieră în vara anului 1983 și inclus în software-ul oricărei stații grafice comercializate de SGI în perioada 1984-1992. Partea de rețea a fost adăugată începând cu 1984, dar utilizatorii conectați la simulator nu puteau interacționa unul cu altul. Acest lucru este însă posibil la programul demonstrativ Dogfight, limitat inițial la 10 utilizatori din rațiuni de evitare a congestiei rețelei. Aceste două aplicații au inspirat, peste ani, dezvoltarea mediilor virtuale distribuite, mai ales prin faptul că SGI a făcut sursele programelor publice (fragmente din aceste surse au fost folosite pentru proiectul NPSNET pe care-1 vom descrie mai tirziu).
O altă sursă de inspirație a constituit-o Doom (idSoftware), apărut pe piață în decembrie 1993 ca aplicație shareware, punct de cotitură în industria jocurilor în rețea, oferind un mediu 3D realist, zgomotos și populat cu monștri. Succesorul lui, Doom II, a fost disponibil din octombrie 1994 și s-a vândut în peste 1,6 milioane de exemplare. A fost portat și pe stații de jocuri precum Sega 32X, Super Nintendo, Sony PlayStation sau Nintendo 64.
Pentru Macintosh, se poate menționa un joc cu grafică impresionantă și sunet spațial, denumit Marathon, apărut în 1994, care oferea, ca și Doom, utilitare pentru editarea și crearea de către utilizator a scenelor 3D. Mediile virtuale academice. Unul dintre eforturile timpurii ale comunității academice în crearea de medii virtuale distribuite este concretizat în grupul de cercetare NPSNET, având la bază câteva proiecte studențești ca FOG-M (Fiber-OpticaUy Gmded MissUe System), VEH (VeMck Simulator) și MPS (Mov-Ing Platform Simulator}, dezvoltate pe stații Unix în perioada 1986-1988.
NPSNET (Naval Postgraduate School Net-work) a avut mai multe stadii de dezvoltare. NPSNET-1, a cărui demonstrație publică a avut loc la Conferința SIGGRAPH'91, folosea un protocol propriu de comunicare și putea rula într-o rețea locală. Au urmat NPSNET-2, NPSNET-3 și NPSNET-Stealth, cel din urmă, operațional din 1993, fiind compatibil cu sistemele SBV1NET. Ultima versiune, NPSNET-IV, a continuat să fie dezvoltată până în decembrie 1996, oferind marea majoritate a facilităților mediilor virtuale distribuite actuale.
Un alt proiect, PARADISE (Performante ArcMtecture for Advanced Distributed Interactive Simulation Environments), a fost inițiat în 1993 la Universitatea Stanford, focalizat în principal pe problemele de comunicare în rețea, având ca punct de plecare programul Dogfight menționat anterior. Astfel, PARADISE utilizează tehnici de multicast, algoritmi performanți dead-reckoning, posedând o arhitectură orient ață-obiect (C++), diverse module de interfață fiind scrise în Tel. Sistemul este operațional pe stații IBM RS/6000 cu capabilități OpenGL.
Institutul Suedez de Informatică dezvoltă un mediu compatibil cu SIMNET și DIS, denumit Distributed Interactive Virtual Environ-ment (DWE). Totul a pornit în 1991, de la editorul de grafică bidimensională Multidraw, avându-1 ca autor pe OlafHagsand. Acest program ulterior s-a dovedit a fi catalizatorul proiectului Telepresence, care a fost redenumit ca DIVE în 1992. Dacă inițial sistemul rula pe IBM/RS 6000, permițând conectarea simultană a numai doi utilizatori, ulterior a fost portat pe stații Sun, ultima versiune, DIVE 3.0, folosind o interfață grafică utilizator concepută complet în Tcl/Tk.
Alt proiect academic este BrickNet, inițiat la Universitatea Națională din Singapore, rulând pe stații Sun și SGI Indigo, apoi pe PC-uri, fiind creat în 1991 de Gurmlnder Singh.
Medii virtuale distribuite bazate pe VRML
Datorită limitărilor hardware ale mașinilor conectate la Internet și lipsei de investiții de amploare în tehnologia VRML, relativ puține organizații au realizat experimente majore în domeniul mediilor virtuale distribuite. Sistemele proiectate de obicei suportă un număr redus de participanți (sub 20 de utilizatori). Problemele puse în discuție în ceea ce privește interoperabilitatea mediilor virtuale pe Web pot fi următoarele:
tipuri de informații trebuie transferate între sistemele care compun mediile virtuale?
Ce protocol trebuie ales pentru realizarea transferului?
Care este arhitectura software de rețea pe care poate să ruleze în condiții optime un astfel de sistem?
Pentru primele două întrebări, putem răspunde că tipurile de date și, respectiv, protocoalele folosite sunt:
schimbările de stare și interacțiunile între entități (transferate prin protocoale punct la punct);
elementele care compun mediul (obiecte, avatari,…) disponibile prin cereri client-server via HTTP – HyperText Transfer Protocol sau VRTP – Virtual Reality Transfer Protocol;
pointerii și referințele de rețea (reprezentate prin URI-uri);
fluxurile de date multimedia în timp-real (transmise în maniera multicast, prin proto coale ca RTP – Real-Time Protocol).
Pentru cea de-a treia problemă, soluțiile se dovedesc a fi multiple. Astfel, vom da în continuare câteva exemple de medii virtuale distribuite, fiecare cu propria sa arhitectură.
DIS-Java-VRML
Dezvoltat la Naval Postgraduate School (Statele Unite ale Americii), proiectul este considerat de autorii lui drept model pentru mediile virtuale distribuite bazate pe VRML. Efor-turile proiectanților s-au focalizat asupra transferului informațiilor despre schimbările de stare și interacțiunile dintre entitățile care compun mediul, dezvoltându-se o bibliotecă de clase Java și o arhitectură pentru inter-schimbul de pachete de date DIS în Internet. Arhitectura software de rețea, la nivel general, este prezentată în următoarea ilu stratie.
Arhitectura software generală a unui sistem DIS-Javas-VRML
O metodă de implementare ar fi aceea în care browserul VRML realizează atât vizualizarea lumilor 3D, cât și procesarea codului Java. O altă abordare este cea în care sistemul constă dintr-o aplicație Java de sine stătătoare sau dintr-un applet Java, fișierele VRML fiind prelucrate de un vizualizator VRML auxiliar.
Experimentele practice efectuate au arătat că un mediu DIS-Java-VRML poate suporta până la 40 de utilizatori conectați simultan, în condiții acceptabile de viteză de transfer.
Living Worlds
Acest proiect este conceput de grupul de cercetare al Consorțiului Web 3D (fost Consorțiul VRML), scopullui fiind definirea unui set de convenții VRML 2.0 pentru realizarea interoperabilității mediilor virtuale distribuite. Living Worlds nu reprezintă, așadar, o arhitectură completă a unui mediu virtual efectiv, ci mai mult oferă o serie de standarde privind utilizarea VRML-ului în acest context: suport pentru prezența virtuală a mai multor participanți, pentru interacțiunea participant -participant sau participant-sistem, pentru asamblarea dinamică a mediului din diverse componente precum avatari, modele partajate, camere virtuale și altele. Astfel, sunt disponibile biblioteci (abstracte) conținând scene/ noduri VRML care pot fi folosite de proiectanții și programatorii de lumi 3D.
Sunt definite următoarele interfețe pentru:
coordonarea poziției și stării obiectelor partajate (inclusiv avatari);
schimbul de informații între obiectele unei scene VRML;
asigurarea securității aplicațiilor VRML (la nivel de sistem și de tilizator);
(4) dezvoltarea unei biblioteci de utilitare și extensii VRML 2.0;
(5) identificarea și integrarea în timpul rulării a scripturilor VRML.
Pentru asigurarea interoperabilității și independenței de platformă, Living Worlds impune ca limbajul de programare a sistemului să fie Java.
Aplicațiile bazate pe specificațiile Living Worlds (încă în stadiu de cercetare) sunt:
blaxxun Interactive – compus din clienții blaxxun Communlty Client pro și serverele blaxxun Communlty Server objects, posedă propriul browser VRML 2.0 oferind suport pentru applet-uri Java externe;
Sony Communlty Place – are ca scop asigurarea unor condiții bune de vizualizare a lumilor 3D virtuale chiar și pentru clienții conectați la Internet prin modem, furnizând servicii conversaționale de tip chat (text sau
grafic), interacțiunea cu obiecte animate etc. Serverul și clienții folosesc un protocol special, denumit VSCP (Virtual Society Client Protocol), bazat pe TCP/IP;
Open Communlty – mediu virtual distribuit dezvoltat de Mitsubishi Electric Research Lab (MERL), reprezintă și o bibliotecă software oferind servicii precum comunicațiile în rețea, transportul datelor audio și obiectelor VRML în timp-real. Protocolul folosit este ISTP (Interactive Sfiaring Transfer Protocol). Sistemul este conceput în limbajul C, dar în viitor va fi rescris în Java.
Unelte de dezvoltare
Pentru a asigura modularizarea, portabilitatea și adaptarea mediului la lumea dinamică a In-ternetului, s-au imaginat diverse aplicații pentru asistarea programatorilor și designerilor de sisteme virtuale distribuite. Majoritatea uneltelor de dezvoltare (toolklt-mi) sunt disponibile gratuit pe Internet. Deja există o serie de aplicații și biblioteci care facilitează munca de construire a unui mediu virtual distribuit (bazat sau nu pe VRML) dintre care pot fi amintite:
Bamboo este un mediu de programare a sistemelor virtuale distribuite, ideea de bază fiind asigurarea în manieră dinamică a scala-bilității acestora. Modular, preluând filosofia Adobe sau Netscape de a utiliza p/ug-in-uri, Bamboo poate fi adaptat conform dorințelor utilizatorilor, fiind independent de platformă (se poate încărca mașina virtuală Java ca modul, deși aplicația este concepută în C++). Partea de rețea este inspirată din A CE (Adaptive Communlcatlon Environment), pe baza căruia a fost construit.
High Level Architecture (HLA) inițial a fost dezvoltat în cadrul Departamentului de Apărare SUA și nu a reprezentat un standard deschis, public. In prezent, HLA se află în adopția organizațiilor IEEE și OMG (Object Management Group). Arhitectura este u na obiectu ala, fiecare simulator de lumi virtuale 3D reprezentând o componentă, denumită federate, constituită dintr-o colecție de obiecte, posedând diferite atribute, capabile de a iniția și răspunde la evenimente. Un federate își înregistrează obiectele prin intermediul unei componente mlddleware denumită Run-Tlme Infrastruc-ture (RT1). RTI colaborează cu instanțele RTI aflate pe alte calculatoare pentru a obține informații despre ceilalți participanți și a le trimite date. Colecția tuturor componentelor federate împreună cu instanțele RTI asociate formează așa-numita federație (fed-eratlon). RTI oferă suport pentru managementul federației, managementul obiectelor dintr-un federate, managementul datelor vehiculate în rețea, managementul proprietarilor obiectelor și managementul timpului. Specificația HTL pune la dispoziția programatorilor interfețe spre limbajele C++, Java și Ada, implementările RTI deja existând pe platforme precum Sun Solaris, SGI TRIX, Linux și Windows NT.
Java Shared Data ToolHt (JSDT) este pus la dispoziție de Sun și oferă un cadru de dezvoltare a aplicațiilor Java colaborative (e.g. suport pentru sincronizarea automată a zonelor de memorie partajată și definirea de canale abstracte pentru trimiterea și re-cepționarea evenimentelor partajate). Utilizând JSDT, se poate implementa complet HLA RTL
Shared Data Objects (SDO) reprezintă oferta gratuită a laboratorului Alpha-Works de la IBM care pune la dispoziție un toolklt Java, util pentru crearea mediilor virtuale distribuite, asemănător cu JSDT, dar furnizând mai multe facilități pentru programatori.
Aplicatie (Magazin Virtual 3D)
Prezentare generala
Ca aplicatie, mi-am propus realizarea unui Magazin Virtual 3D, interacativ, care poate fi accesat atat local cat si online.
Aplicatia permite navigarea (cu ajutorul sagetilor) intr-un magazin virtual, vizualizarea produselor de pe rafturi si selectarea unui anumit produs (cu ajutorul butonului din stanga al mouse-ului). O data produsul selectat, se deschide o noua fereastra, in care il putem vedea detaliat si cu ajutorul mouse-ului, actionand asupra lui, il putem roti pentru o vizualizare din toate unghiurile. Fereastra in care este prezentat produsul mai contine pretul, o descriere a acestuia si un cos virtual in care sunt toate cumparaturile care au fost facute pana atunci. Produsul vizualizat poate fi introdus in cos cu ajutorul butonului “+” (prin apasari repetate se introduc main multe produse). In cazul in care s-a gresit, sau se vrea renuntarea la unele produse, se selecteaza acesta din lista derulanta, si se apasa pe butonul “-”. Daca se doreste intoarcerea in magazin se apasa butonul “Return“. Aplicatia se incheie cand se apasa butonul ”Next” din dreapta jos a ferestrei de navigare.
Specificatii
Aplicatia a fost realizata in programul Macromedia Director v.8.5, limbajul de programare care s-a folosit este 3D Lingo (Director internal script).
Elementele grafice (magazinul, rafturile, afisele, plantele, produsele) au fost realizate in 3D Studioa MAX v.5.1.
Exemplificari din codul sursa pentru definirea si creare lumii, importarea de obiecte, crearea sistemului de lumini.
global vCloneNr
global rayHeight
property p3dWorld
property pSprite
property pCamera
global objnr
on beginSprite me
–Proprietati Generale
personHeight=165
objects=member("smallobj")
– initializarea proprietatilor
p3dWorld = sprite(me.spriteNum).member
pSprite = sprite(me.spriteNum)
pCamera = pSprite.camera
– pozitia camerei este verticala (D8.5)
pCamera.projectionAngle = 80
pCamera.fieldOfView = 80
– pozitionarea camerei
pCamera.transform.position = vector(0,personHeight,900)
– roteste camera un punct inainte de-a lungul axei z
pCamera.pointAt(vector(0,personHeight,0))
–pCamera.hither = 1
–pCamera.yon = 1000
– Culoarea Ambientala
p3dWorld.ambientColor = rgb(255, 255, 255)
– Construieste Magazinul
importmodel("shop","",vector(0,0,0))
–Se importa obiectele din libraria ShockWave
vCloneNr = []
vObjView=[]
repeat with i = 1 to objnr
importmodel("so"&i,"obj"&i,"")
vCloneNr[i]=0
vObjView[i]=0
end repeat
–Import dulapuri
tmp=importmodel("dulap","d1",vector(1000,0,0))
posvect=["",vector(350,0,-1000),vector(350,0,-500),vector(350,0,0),vector(-350,0,0),vector(-350,0,-500),vector(-350,0,-1000)]
repeat with i=2 to posvect.count
clonemodel(tmp,"d"&i,posvect[i])
end repeat
–Fill shelves with objects
objfill(6,"d3",1,2,15,-50,45,0)
objfill(7,"d3",1,2,15,50,45,0)
objfill(4,"d3",5,19,15,-150,45,0)
objfill(9,"d3",4,5,25,-150,45,0)
objfill(6,"d3",3,19,15,-150,45,0)
objfill(5,"d3",2,10,15,-150,45,0)
objfill(7,"d3",2,5,15,50,45,0)
objfill(1,"d3",6,5,40,-120,45,0)
objfill(2,"d3",6,5,40,-140,45,0)
–Sterge modelele originale din lume
repeat with i = 1 to objnr
p3dWorld.deleteModel("obj"&i)
end repeat
–Import lumini
importmodel("lumini","",vector(0,450,0))
–Import aplice
importmodel("becuri","",vector(0,550,0))
–Import banners
tmp=importmodel("cola","",vector(0,400,250))
clonemodel(tmp,"",vector(-350,400,-250))
tmp=importmodel("pepsi","",vector(650,400,0))
clonemodel(tmp,"",vector(650,400,-500))
–Import planta
tmp=importmodel("planta","",vector(135,0,0))
clonemodel(tmp,"",vector(-135,0,-500))
clonemodel(tmp,"",vector(350,0,350))
tmp=importmodel("planta2","",vector(-500,0,350))
–Import cutie
tmp=importmodel("cutie","c1",vector(-350,0,350))
clonemodel(tmp,"c2",vector(250,0,350))
clonemodel(tmp,"c3",vector(800,0,350))
–Import benzi
tmp=importband("banda1","d1",48)
repeat with i in [2,4,5,6,7]
cloneband(tmp,"d"&i,48)
–cloneband(tmp,"d"&i,25)
end repeat
tmp.transform.rotate(0,-180,0)
repeat with i in [2,4,5,6,7]
cloneband(tmp,"d"&i,-45)
–cloneband(tmp,"d"&i,-25)
end repeat
tmp.transform.rotate(0,-180,0)
–Import pasi
tmp=importmodel("footstep","",vector(0,.5,0))
repeat with i=1 to 4
clonemodel(tmp,"",vector(0,.5,-i*60))
end repeat
tmp.rotate(0,0,-90)
repeat with i=1 to 5
clonemodel(tmp,"",vector(i*60,.5,-290))
end repeat
tmp.rotate(0,0,90)
–Import gard
tmp=importmodel("gard","",vector(-160,0,600))
clonemodel(tmp,"",vector(-370,0,600))
clonemodel(tmp,"",vector(160,0,600))
clonemodel(tmp,"",vector(370,0,600))
tmp=importmodel("gard1","",vector(-65,55,600))
–Import lant
tmp=importmodel("lant","",vector(-650,500,0))
clonemodel(tmp,"",vector(650,500,-250))
clonemodel(tmp,"",vector(-650,500,-500))
end
Sursa 3D studio MAX care realizeaza sistemul de lumini din lumea virtuala.
*SCENE {
*SCENE_FILENAME "light.max"
*SCENE_FIRSTFRAME 0
*SCENE_LASTFRAME 100
*SCENE_FRAMESPEED 30
*SCENE_TICKSPERFRAME 160
*SCENE_BACKGROUND_STATIC 0.0000 0.0000 0.0000
*SCENE_AMBIENT_STATIC 0.0000 0.0000 0.0000
}
*MATERIAL_LIST {
*MATERIAL_COUNT 1
*MATERIAL 0 {
*MATERIAL_NAME "1 – Default"
*MATERIAL_CLASS "Standard"
*MATERIAL_AMBIENT 0.5882 0.5882 0.5882
*MATERIAL_DIFFUSE 0.5882 0.5882 0.5882
*MATERIAL_SPECULAR 0.9000 0.9000 0.9000
*MATERIAL_SHINE 0.1000
*MATERIAL_SHINESTRENGTH 0.0000
*MATERIAL_TRANSPARENCY 1.0000
*MATERIAL_WIRESIZE 1.0000
*MATERIAL_SHADING Blinn
*MATERIAL_XP_FALLOFF 0.0000
*MATERIAL_SELFILLUM 0.0000
*MATERIAL_FALLOFF In
*MATERIAL_XP_TYPE Filter
}
}
*GROUP "Group01" {
*HELPEROBJECT {
*NODE_NAME "Group01"
*HELPER_CLASS "Dummy"
*NODE_TM {
*NODE_NAME "Group01"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 1.0000 0.0000
*TM_ROW2 0.0000 0.0000 1.0000
*TM_ROW3 22.1980 -490.4048 65.7654
*TM_POS 22.1980 -490.4048 65.7654
*TM_ROTAXIS 0.0000 0.0000 0.0000
*TM_ROTANGLE 0.0000
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*BOUNDINGBOX_MIN -909.8088 -980.8096 -520.7039
*BOUNDINGBOX_MAX 954.2048 0.0000 652.2346
}
*LIGHTOBJECT {
*NODE_NAME "Omni01"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni01"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -901.8088 -972.8096 -512.7039
*TM_POS -901.8088 -972.8096 -512.7039
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni06"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni06"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 946.2048 -972.8096 644.2346
*TM_POS 946.2048 -972.8096 644.2346
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni02"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni02"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -901.8088 -972.8096 -193.2182
*TM_POS -901.8088 -972.8096 -193.2182
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni03"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni03"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -901.8088 -972.8096 644.2346
*TM_POS -901.8088 -972.8096 644.2346
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni04"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni04"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -901.8088 -972.8096 180.0874
*TM_POS -901.8088 -972.8096 180.0874
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni05"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni05"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 946.2048 -972.8096 -193.2182
*TM_POS 946.2048 -972.8096 -193.2182
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*GEOMOBJECT {
*NODE_NAME "Box01"
*NODE_PARENT "Group01"
*NODE_TM {
*NODE_NAME "Box01"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 1.0000
*TM_ROW2 0.0000 -1.0000 -0.0000
*TM_ROW3 589.0603 0.0000 250.2151
*TM_POS 589.0603 0.0000 250.2151
*TM_ROTAXIS -1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*MESH {
*TIMEVALUE 0
*MESH_NUMVERTEX 8
*MESH_NUMFACES 12
*MESH_VERTEX_LIST {
*MESH_VERTEX 0 526.5140 0.0000 202.3856
*MESH_VERTEX 1 651.6066 0.0000 202.3856
*MESH_VERTEX 2 526.5140 -0.0000 298.0447
*MESH_VERTEX 3 651.6066 -0.0000 298.0447
*MESH_VERTEX 4 526.5140 -66.2255 202.3855
*MESH_VERTEX 5 651.6066 -66.2255 202.3855
*MESH_VERTEX 6 526.5140 -66.2255 298.0447
*MESH_VERTEX 7 651.6066 -66.2255 298.0447
}
*MESH_FACE_LIST {
*MESH_FACE 0: A: 0 B: 2 C: 3 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 2 *MESH_MTLID 1
*MESH_FACE 1: A: 3 B: 1 C: 0 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 2 *MESH_MTLID 1
*MESH_FACE 2: A: 4 B: 5 C: 7 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 3 *MESH_MTLID 0
*MESH_FACE 3: A: 7 B: 6 C: 4 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 3 *MESH_MTLID 0
*MESH_FACE 4: A: 0 B: 1 C: 5 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 4 *MESH_MTLID 4
*MESH_FACE 5: A: 5 B: 4 C: 0 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 4 *MESH_MTLID 4
*MESH_FACE 6: A: 1 B: 3 C: 7 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 5 *MESH_MTLID 3
*MESH_FACE 7: A: 7 B: 5 C: 1 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 5 *MESH_MTLID 3
*MESH_FACE 8: A: 3 B: 2 C: 6 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 6 *MESH_MTLID 5
*MESH_FACE 9: A: 6 B: 7 C: 3 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 6 *MESH_MTLID 5
*MESH_FACE 10: A: 2 B: 0 C: 4 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 7 *MESH_MTLID 2
*MESH_FACE 11: A: 4 B: 6 C: 2 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 7 *MESH_MTLID 2
}
}
*PROP_MOTIONBLUR 0
*PROP_CASTSHADOW 1
*PROP_RECVSHADOW 1
*MATERIAL_REF 0
}
*LIGHTOBJECT {
*NODE_NAME "Omni07"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni07"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 946.2048 -972.8096 180.0874
*TM_POS 946.2048 -972.8096 180.0874
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni08"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni08"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 946.2048 -972.8096 -512.7039
*TM_POS 946.2048 -972.8096 -512.7039
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni09"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni09"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -5.3663 -972.8096 419.6559
*TM_POS -5.3663 -972.8096 419.6559
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni10"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni10"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -5.3663 -972.8096 46.3503
*TM_POS -5.3663 -972.8096 46.3503
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
*LIGHTOBJECT {
*NODE_NAME "Omni11"
*NODE_PARENT "Group01"
*LIGHT_TYPE Omni
*NODE_TM {
*NODE_NAME "Omni11"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 -0.0000 -1.0000
*TM_ROW2 0.0000 1.0000 -0.0000
*TM_ROW3 -5.3663 -972.8096 -273.1354
*TM_POS -5.3663 -972.8096 -273.1354
*TM_ROTAXIS 1.0000 0.0000 0.0000
*TM_ROTANGLE 1.5708
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*LIGHT_SHADOWS Off
*LIGHT_USELIGHT 1
*LIGHT_SPOTSHAPE Circle
*LIGHT_USEGLOBAL 0
*LIGHT_ABSMAPBIAS 0
*LIGHT_OVERSHOOT 0
*LIGHT_SETTINGS {
*TIMEVALUE 0
*LIGHT_COLOR 1.0000 1.0000 1.0000
*LIGHT_INTENS 1.0000
*LIGHT_ASPECT -1.0000
*LIGHT_TDIST -1.0000
*LIGHT_MAPBIAS 1.0000
*LIGHT_MAPRANGE 4.0000
*LIGHT_MAPSIZE 512
*LIGHT_RAYBIAS 0.0000
}
}
}
Cerinte System
Hardware:
Windows: Intel Pentium processor (Pentium II or higher recommended)
Macintosh: Power Macintosh Power PC processor (G3 or higher recommended)
32 MB of installed RAM
16-bit color display
3D accelerator video card (recommended)
Software:
DirectX 7.0 or higher
A Web Browser with Shockwave Player v.8.5 installed
Bibliografie
S.Singhal, M.Zyda – „Networked Virtual Environments", Addison-Wesley, New York, 1999
N.Teroshima – „Telesensation – Distributed Interactive Virtual Reality – Overview and Prospects", l FI P, 1994
Q.Wang – „Networked Virtual Reality", Mașter Thesis, University of Alberta, 1994
„The Virtual Reality Modeling Language", International Standard ISO/IEC 14772-1:1997, VRML Consortium, 1997
D. Brutzman (1998). "The Virtual Reality Modeling Language and Java". Communications of ACM 41 6 (1998).
R. Camiciottoli, J.M. Corridoni, A. Del Bimbo (1998). "3D Navigation of Geographic Data Sets". IEEE Multimedia. Vol. 5 2, April-June 1998.
G. Cattaneo, U. Ferraro, G.F. Italiano, V. Scarano. "Concurrent Algorithms and Data Types Animation over the Internet". Proceedings of Fundamentals and Foundation of Computer Science, 15th IFIP World Computer Congress, Wien (Austria), August 31, Sept. 4 1998.
OpenGL: http://sgy.com/technology/openGL/glspecl.l/glspec.html
Virtual Reality Universe: http://vruniverse.com
Director 8.5: http://macromedia.com
3D Studio MAX: http://discreet.com
International Standard ISO/IEC (1997) "14772-1:1997: The Virtual Reality Modeling Language." http://www.vrml.org/Specifications/VRML97
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Realizarea Unui Magazin Virtual 3d (ID: 149169)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.