TRANSMOTION EMBERI MOZGÁS DIGITALIZÁLÁSA

Budapesti Műszaki Főiskola Neumann János Informatikai Főiskolai Kar Szoftvertechnológia Intézet

TUDOMÁNYOS DIÁKKÖRI DOLGOZAT

TRANSMOTION – EMBERI MOZGÁS DIGITALIZÁLÁSA

Szerzők:

Kertész Tamás műszaki informatika szak, III. évfolyam Rieger Péter László műszaki informatika szak, III. évfolyam Szolyka Sándor műszaki informatika szak, IV. évfolyam

Konzulens:

Vámossy Zoltán főiskolai docens

Budapest, 2005

TransMotion

-2-

http://transmotion.no-ip.org

Tartalomjegyzék Tartalomjegyzék............................................................................................................................... 2 Bevezető............................................................................................................................................. 4 1.1. A feladat ismertetése, témamegjelölés................................................................................. 4 1.2. A dolgozat tartalma .............................................................................................................. 4 Motion Capture ................................................................................................................................ 5 2.1. Mi is az a "Motion Capture"? ............................................................................................. 5 2.2. Gyakorlati felhasználási területek....................................................................................... 6 2.3. Történelmi áttekintés............................................................................................................ 7 2.4. A markerek............................................................................................................................ 8 2.5. Milyen markereket használjunk?........................................................................................ 9 2.6. A markerek használatának alapszabályai .......................................................................... 9 2.7. Markerek felismerése, követése ......................................................................................... 10 2.8. Zajos kép, Ghost Pointok ................................................................................................... 10 2.8. Zajos kép, Ghost Pointok ................................................................................................... 11 Performance Animation ................................................................................................................ 12 3.1. Bevezetés .............................................................................................................................. 12 3.1.1. Mi is az a "Performance Animation"? ...................................................................... 12 3.1.2. Miért éppen Maya? ..................................................................................................... 12 3.1.3. A fejezet tartalma ........................................................................................................ 12 3.2. A csontvázmodell elkészítése.............................................................................................. 13 3.2.1. A csontvázak ................................................................................................................ 13 3.2.2. Csuklópontok típusai (szabadsági fokoktól függően)............................................... 14 3.2.3. Csukló-láncolatok (joint chains)................................................................................. 14 3.2.4. Végtagok (limbs) .......................................................................................................... 14 3.2.5. Csontváz-hierarchia .................................................................................................... 14 3.2.6. Forward / Inverse kinematics ..................................................................................... 15 3.3. A karaktermodell elkészítése ............................................................................................. 16 3.3.1. Subdivision Surfaces ................................................................................................... 16 3.3.2. NURBS.......................................................................................................................... 16 3.3.3. Poligonális modell ........................................................................................................ 17 3.3.4. Clay objects .................................................................................................................. 17 3.3.5. Hibrid módszerek ........................................................................................................ 17 3.4. Kiegészítő elemek hozzáadása a jelenethez ...................................................................... 18

Kertész Tamás, Rieger Péter László, Szolyka Sándor

TransMotion

-3-


Hasonló rendszerek bemutatása, értékelése ................................................................................ 19 4.1. Vicon .................................................................................................................................... 19 4.2. Brainfactor Entertainment ................................................................................................ 20 4.3. Milánói Egyetem ................................................................................................................. 21 4.4. Pyros Pictures...................................................................................................................... 21 TransMotion ................................................................................................................................... 22 5.1. A rendszer fő moduljai ....................................................................................................... 22 5.2. Kalibráció ............................................................................................................................ 23 5.2.1. A kamerák elhelyezése ................................................................................................ 23 5.2.2. A kameráink................................................................................................................. 24 5.2.3. Külső paraméterek ...................................................................................................... 24 5.2.4. Belső paraméterek ....................................................................................................... 25 5.3. A kamerakezelő modul ....................................................................................................... 27 5.3.1. Mivel kezeljük a kamerákat? ..................................................................................... 27 5.3.2. Mi is az a DirectShow?................................................................................................ 27 5.3.3. Hogyan működik a DirectShow?................................................................................ 28 5.3.4. Hogyan használjuk a DirectShow-t videó-felvételre? .............................................. 28 5.3.5. A Capture osztály ........................................................................................................ 30 5.4. A főprogram ........................................................................................................................ 31 5.4.1. A .NET keretrendszer és a C# programnyelv ........................................................... 31 5.4.2. Interaktivitás................................................................................................................ 32 5.4.3. A modulok integrálása ................................................................................................ 33 5.5. A képfeldolgozó modul ....................................................................................................... 34 5.6. A 3D-s koordináták kiszámítása........................................................................................ 34 5.6.1. Az egyenletrendszer megoldása.................................................................................. 35 5.7. A két rendszer összekapcsolása ......................................................................................... 36 5.7.1. Maya Motion Capture API Library .......................................................................... 36 5.8. A Performance Animation környezet konfigurálása ....................................................... 37 5.9. A 3D-s környezet kialakítása ............................................................................................. 38 5.10. Tesztelés, az eredmények értékelése................................................................................ 38 5.11. Összefoglalás, továbbfejlesztési lehetőségek ................................................................... 39 Irodalomjegyzék ............................................................................................................................. 40 6.1. Felhasznált irodalom .......................................................................................................... 40 6.2. Ajánlott irodalom................................................................................................................ 42 Elérhetőségek.................................................................................................................................. 42


TransMotion

-4-


Bevezető 1.1. A feladat ismertetése, témamegjelölés A projekt célja az emberi mozgás optikai módon történő digitalizálása olyan valósidejű rendszerben, amely többkamerás élő felvételt vesz alapul. Egy mozgásszínészen elhelyezett jelölőpontok térbeli koordinátáit számítja ki, melyeket egy háromdimenziós karakter-modellhez rendel hozzá. A folyamatban két számítógép vesz részt: az egyik a kamerák képének feldolgozását és a képi információk kinyerését végzi, a másik pedig a 3D-s megjelenítésért felelős. A technológiának több megvalósítása is megtalálható a piacon, de ezek többnyire rendkívül költségesek, így például kutatási és tanulmányi célokra nem alkalmazhatók. Éppen ezért céljaink között szerepel, hogy a rendszer a hasonló megoldásokhoz képest jelentősen kisebb fajlagos költségű legyen, így valódi alternatívát nyújtson a költséghatékonyságot szem előtt tartó potenciális ügyfelek számára is. Hasonlóan a mai programozás többi területéhez, ez a rendszer is túl komplex lenne ahhoz, hogy minden elemét mi magunk készítsük el. Szerencsére segítségül hívhatunk már meglévő technológiákat, mint például az Intel által fejlesztett OpenCV, a Microsoft DirectShow, vagy a robosztus Alias Maya termék és a hozzá készült kiegészítők. A szoftverfejlesztés elsősorban Microsoft Visual Studio .NET 2003 fejlesztőkörnyezetben zajlik, a megjelenítés a Maya 3D-grafikus szoftver feladata. A felhasznált eszközök ismertetése a rendszer részletes leírásánál található.

1.2. A dolgozat tartalma A dolgozat első része rövid áttekintést ad a projekt alapját képező technológiákról. A rendszer alapvetően két fő részre osztható: a mozgás rögzítéséért a Motion Capture felelős, a megjelenítést a Performance Animation végzi. Ezután ismertetésre kerül néhány konkrét Motion Capture (továbbiakban MoCap) rendszer, melyek áttanulmányozása rendkívül hasznos volt számunkra. A második fő rész a saját rendszerünk, eddigi munkánk bemutatása. Szót ejtünk a kezdeti elképzeléseinkről, és hogy ezek miként változtak időközben, majd ismertetjük a rendelkezésünkre álló szoftver és hardver eszközöket, melyek segítségével a fejlesztés folyik. Ezután a rendszer egyes részeit részletesen tárgyaljuk, végül az eddig elért eredmények értékelése és a projekt további lehetőségeinek boncolgatása következik. A dolgozatot az irodalomjegyzék zárja.


TransMotion

-5-


Motion Capture 2.1. Mi is az a "Motion Capture"? A Motion Capture magyarul az élő mozgás folyamatának rögzítése és használható matematikai kifejezésekké alakítása néhány pont térbeli követésével. Lényegében egy technológia, amely lehetővé teszi az élő mozgás digitális mozgássá való alakítását. A megfigyelt objektum bármi lehet, ami a való világban mozog; a jelzőpontok azon helyeket jelölik, amelyek legjobban reprezentálják az objektum részeinek mozgását. Egy ember esetében ezek lehetnek például a csukló, könyék, térd, a fej jellegzetesebb pontjai. A technika lehetőséget ad álló objektumok 3D-s modellezésére is, továbbá használható akár az arc változásainak nyomon követésére is. A pontok egyéni mozgásának koordinátái egy feldolgozó egységhez kerülnek, amely ezen adatokból építi fel egy 3D-s karakter animációját. Az adatok feldolgozása történhet azonnal, valós időben (real-time), vagy akár utólag is, ilyenkor csak a jól sikerült felvételeket használják fel. Előfordul, hogy a jelölőpontok (markerek) takarásban vannak. Az ilyen helyzetek száma csökkenthető több kamera alkalmazásával, de többnyire szükség van manuális utófeldolgozásra, hogy megtaláljuk az elveszett markerek pontos pozícióját. Sok múlik az alkalmazott kamerák minőségén: nagyobb felbontás esetén könnyebb megkülönböztetni az objektumokat, az élek jobban elhatárolódnak, viszont ez értelemszerűen drágább kamerák használatát feltételezi. Ugyanazon kamera esetén általában választható, hogy nagyobb látószöget szeretnénk, hogy nagyobb területet vehessünk fel (nagyobb helyigényű mozgások rögzítése esetén, például ha több színész dolgozik együtt), vagy inkább egy kisebb terültre fókuszálunk, ezzel nagyobb felbontású képet kapva.

2.1. ábra - Motion Capture stúdió [1]


TransMotion

-6-


2.2. Gyakorlati felhasználási területek A Motion Capture technológiában számos lehetőség rejlik. Napjainkban még csak néhány iparág alkalmazza, de a jövőben egyre nagyobb teret kaphat, számos kiaknázatlan terület van még, ahol megjelenése csak idő kérdése. Lássuk, melyek is ezek a felhasználási területek: •

filmipar: napjainkban egyre több filmben tűnnek fel számítógép által életre keltett szereplők, élőlények; ezek mozgását többnyire Motion Capture technológiával veszik fel valódi színészek segítségével, ennek köszönhető élethű mozgásuk a filmvásznon

2.2. ábra - Így készült a Gyűrűk Ura [www.lordoftherings.net]

•

játékipar: fokozottan igaz, ami a filmeknél, hiszen a számítógépes játékokban nincsenek valódi színészek, egyre kevesebb olyan játék jelenik meg, amelyikben nincs szükség valamilyen karakter animálására

2.3. ábra - Motion Capture felvétel [2]

•

•

számítógép vezérlése kézmozdulatokkal: szintén a filmeket hozhatjuk fel példának, egyelőre leginkább csak a tudományos fantasztikus mozikban láthattunk hasonlót, pedig a technikai feltételek már adottak, csak a megvalósítás (és főleg ennek széleskörű elterjedése) várat magára távvezérlés: veszélyes (sugárfertőzött, robbanásveszélyes) területeken távvezérelt robotok végezhetnek például mentőmunkálatokat


TransMotion

-7-


Az iparban jelenleg három elterjedt eljárást használnak a Motion Capture feladatok megvalósítására: optikai, elektromágneses és elektromechanikai. Ezenfelül létezik még egy-két kevésbé elterjedt megvalósítás, mint például a rádiófrekvenciás és ultrahangos rendszerek. [3]

2.4. ábra - Markerek a csontvázszerkezeten [www.okino.com]

2.3. Történelmi áttekintés A Motion Capture, mint a számítógépes karakter-animáció eszköze a 1970-es évek végén jelent meg először, de széleskörű elterjedése csak az utóbbi néhány évben kezdődött. Az ötlet, hogy lemásoljuk az emberi mozgást animált karakterek mozgatásához, természetesen nem új. A Disney a Hófehérke készítésekor az úgynevezett ’rotoscoping’ eljárást használta. A rajzfilm készítésekor először felvették a filmet igazi színészekkel, majd átrajzolták a képkockákon a színészeket rajzfilmfigurákra, így tették mozgásukat életszerűvé. Az 1980-as évek elején a Simon Fraser Egyetem professzora, Tom Calvert által kidolgozott rendszer potenciométereket használt, melyeket egy testre helyezett. A mérési eredményeket koreográfiai tanulmányokhoz és mozgási rendellenességek kutatásához használta fel. Az analóg adatokat át kellett alakítania digitális formába, majd ezeket táplálta be a számítógépbe és segítségükkel egy animált karaktert mozgatott. 1983-ban Ginsberg és Maxwell az MIT-n (Massachusetts Institute of Technology) egy Op-Eye nevű, korai optikai Motion Capture rendszert mutattak be. Egy bekábelezett ruhán LED-eket helyeztek el a testhajlatokban és egyéb anatómiailag fontos helyeken, majd két kamera képéből számolták ki a kamerák pozíciójának ismeretében a LED-ek 3D-s koordinátáit. A rendszer megjelenített egy pálcikaembert valós időben, majd eltárolta az adatokat, hogy később egy sokkal részletesebb karakter mozgatásához is felhasználhassák. A megoldás nem terjedt el igazán, mert nagyon magas költségekkel járt.


TransMotion

-8-


1993-ban az Acclaim bejelentése sokkoló hatású volt: az előző néhány évben egy nagyteljesítményű optikai mozgáskövető rendszert fejlesztettek ki, ami képes volt két karakter mozgatására kizárólag MoCap segítségével, egy időben 100 pont nyomon követésével, ráadásul mindezt valós időben! A rendszert videojátékokhoz használták. Az Acclaim levédette a szabadalmat, így az soha nem került piacra. [4]

2.4. A markerek A mozgás digitalizálásához a MoCap rendszerek úgynevezett markereket (jelölőket) használnak, ezek általában fehér, fekete vagy színes gömb alakú tárgyak, amiket a testhezálló ruhára rögzítenek, a kamerával felvett képen pedig ezek megkeresésével tudjuk meghatározni a pontok térbeli pozícióját. Lássuk milyen előnyei és hátrányai vannak a színes illetve fehér/fekete (egyszínű) markerek alkalmazásának:

SZÍNES MARKEREK

EGYSZÍNŰ MARKEREK

könnyű megkülönböztetni a markereket, hiszen a színük alapján egyértelműen azonosíthatók, ez egyszerű és gyors kód írását teszi lehetővé mivel minden marker egyedi, nem fognak összekeveredni, tehát megbízható

azonosítani kell a markereket, ehhez előzőleg tudatni kell a rendszerrel, hogy melyik marker hol van, majd a kódnak követnie kell ezek elmozdulásait – ez bonyolultabb kódot igényel és lassabb is a markerek összekeveredhetnek, gondoljunk csak a tapsolásra, a két kéz markerei felcserélődhetnek

a képfeldolgozás színes képek segítségével történik, ami nagyobb számításigénnyel jár és jóval több adat mozgatására, tárolására van szükség

a felvett színes kép előfeldolgozásra szorul, bináris formára kell hozni, viszont ez számottevően felgyorsítja a kép tartalmának kinyerését

rugalmatlan, mivel egy bizonyos színmennyiség után a színek számának növelése a rendszer bizonytalanságához vezethet (a színek többszöri alkalmazása esetén pedig fennáll a keveredés veszélye)

egyszerűen bővíthető, rugalmas, bármikor változtathatjuk a markerek számát, viszont ez tovább növeli az összekeveredés esélyét

több alak is könnyen kezelhető egy felvételen, mert egy színösszeállítást több színészre is lehet alkalmazni, persze a köztük lezajló interakció során már figyelni kell a keveredés problémájára

több alak szerepeltetésekor még nehezebb megkülönböztetni, szétválasztani őket – ez a kódba épített 'intelligenciával' talán megoldható, legalábbis csökkenthető az összekeveredett pontok száma

az eltérő megvilágítás (például árnyék) miatt az egymáshoz közeli színárnyalatok túl közel kerülhetnek egymáshoz, ez is keveredéshez vezethet

a megvilágítási problémák itt szinte egyáltalán nem lépnek fel, hiszen egy világos helyszínen a fehér markerből még az árnyékok hatására sem lesz fekete

1. táblázat - A színes és az egyszínű markerek összehasonlítása


TransMotion

-9-


2.5. Milyen markereket használjunk? Mind az egyszínű, mind a színes markerek alkalmazása mellett és ellen is rengeteg érv szól. Mivel real-time rendszer megvalósítását tűztük ki célul, rendkívül fontos szempont a gyorsaság. A sebesség alapján talán az egyszínű markerek használata felé billen a mérleg, mert összességében az tűnik gyorsabbnak. Viszont ez jóval bonyolultabb kódot, számos igen komoly probléma megoldását igényelné (mint pl. a markerek megkülönböztetése), ami jelentősen megnövelné a fejlesztési időt. Költségek tekintetében a fehér markerek nyújtanak kedvezőbb alternatívát. Egyrészt maguk a jelölők is alacsonyabb áron és könnyebben szerezhetők be, másrészt a színes markerekhez komolyabb, drágább kamerákra lenne szükségünk, hiszen a színhűség itt lényeges szempont. A színes markerekkel könnyebben érnénk el eredményeket, mivel a kód jelentősen egyszerűbb lenne. Így előbb tudnánk működő rendszert prezentálni, továbbá célszerű az egyszerűbb megoldástól a bonyolultabb felé haladni, vagyis ha a színes markerekkel már jól boldogulunk, akkor még mindig áttérhetünk a fehérek alkalmazására. Figyelembe véve a két megoldás előnyeit és hátrányait, egyelőre a színes markerek használata mellett döntöttünk.

2.6. A markerek használatának alapszabályai A térbeli koordináták kiszámításához a bemenetet (a kamerák képén keresztül) a markerek elhelyezkedése szolgáltatja. Vizsgáljuk meg, hogy mire kell odafigyelni ezek helyes használatához: •

• • •

a színésznek, akin a MoCap-et végezzük, testhezálló ruhát kell hordania, minden olyan részt, ami ’lötyög’ le kell fogatni, hogy minél inkább elkerüljük a takarásokat és a markerek is a helyükön maradjanak a markerek lehetséges elmozdulásait minimalizálni kell, mert különben pontatlanul fognak megjelenni a felvételen, valamint jól látható helyre kell őket elhelyezni, tehát például a könyök hajlatba értelmetlen rakni a markereket a lehető legközelebb kell helyezni a csontokhoz, ebből következően a mozgás során nem fognak elmozdulni hogy a MoCap rendszer könnyebben megkülönböztesse a jobb és baloldalt, a markereket aszimmetrikusan kell elhelyezni (színes markerek esetében nincs jelentősége) [5]


TransMotion

- 10 -


2.5. ábra - A markerek elhelyezése [6]

2.7. Markerek felismerése, követése A markerek megtalálása a képen az egyik legidőigényesebb feladat. Sokat gyorsíthat viszont a folyamaton a következő módszer: az első képkockán a markerek még bárhol lehetnek, ezért az egész képen kell keresni őket. Viszont a következő kép esetében már rendelkezünk némi információval a marker előző időpillanatbeli helyzetét illetően, ezért elegendő csak ennek a környezetét vizsgálni, hiszen két képkocka között a marker valószínűleg nem mozdult el nagyon sokat. A marker elmozdulását is megbecsülhetjük, ha az előző két időpillanatbeli pozíciójának különbségét hozzáadjuk az előző helyzetéhez. [7]

2.7. ábra - Marker keresése szekvenciálisan

2.6. ábra - Marker keresése spirálisan


TransMotion

- 11 -


2.8. Zajos kép, Ghost Pointok A túlságosan zajos kép feldolgozása igen nehézkes. Ennek érdekében különböző szűrőket és képfeldolgozó eljárásokat lehet alkalmazni. Sajnos az optikai MoCap rendszer egyik hátránya, hogy a fényviszonyokra igen érzékeny, ráadásul a különböző színek a sötétség-világosság hatásara nem lineárisan változnak meg. Ha egy feldolgozandó képen egy hibás pontot detektálunk és azt markerként ismertük fel, akkor Ghost Pointot találtunk. A Ghost Pointok kiszűrését nagyban megkönnyíti, hogy az emberi test arányainak nem megfelelő, vagy a megalkotott csontvázszerkezethez nem illeszkedő pontokat kizárhatjuk. A gond akkor kezdődik, amikor egy markerhez közel detektálunk egy Ghost Pointot. Ennek megoldására még nem találtunk megoldást. Esetleg előny lehet a színes markerek használata, hiszen nem valószínű, hogy egy adott színű marker mellé egy hasonló Ghost Point kerül. A hibás elhelyezkedésű, színkóddal ellátott elemeket a csontvázszerkezettel megint csak ki lehet zárni.


TransMotion

- 12 -


Performance Animation 3.1. Bevezetés 3.1.1. Mi is az a "Performance Animation"? Ellentétben a Motion Capture-rel, ez a rész a mozgás megjelenítésére szolgál, a modellezett karaktert kelti életre (az alkalmazott technikától függetlenül). A MoCap által rögzített adatokat leképezi a 3D-s karakter mozgására. Röviden a MoCap a mozgást reprezentáló adatok összegyűjtése, míg a Performance Animation pedig a végső karakteranimáció, amit a szereplő irányít. A karakteranimáció előállítását egy kész termék, a témában élen járó 3D modellező és animációs program fogja végezni: az Alias Maya 7.0. [8] 3.1.2. Miért éppen Maya? Az 3D animációs iparban legszélesebb körben elterjedt szoftverek közül az Alias Maya, valamint a Discreet 3D Studio Max a legdominánsabbak. Habár léteznek kifejezetten karakteranimálásra szakosodott rendszerek, mégis indokolt egy olyan program támogatottságát élvezni, mely egyedülálló módon már Oscar-díjjal is büszkélkedhet. Külön kimagasló tulajdonsága továbbá, hogy a Maya egy helyen ötvözi az általánosságot a specializáltsággal. 3.1.3. A fejezet tartalma Ezen rész a 3D-s karakter szimulációjához szükséges lépéseket taglalja, úgymint a csontvázszerkezet, a karaktermodell és a modell környezetének kialakítását, valamint a jelenet kiegészítő elemeinek hozzáadását. Ha mindez készen áll, végső lépésként szükség lesz továbbá az elkészült modell és a bejövő adatfolyam közti kapcsolat kialakítására; így egy működőképes, látványos rendszer kerülhet demonstrálásra.


TransMotion

- 13 -


3.2. A csontvázmodell elkészítése

3.1. ábra – Csontvázmodell [9]

3.2.1. A csontvázak A csontvázszerkezet egy többnyire élő modellek animálását segítő, 'csuklós' ízekre tagolt hierarchiai struktúra. Csontokból és az őket összekapcsoló csuklópontokból épül fel, így segítséget nyújt például humanoid karakterek mozgásának imitációjához. A már elkészült csontvázat tetszőleges (de a csontvázzal izomorf) karakterhez alkalmazhatjuk. Használhatunk 'rigid skinning' ill. 'smooth skinning' technikát, attól függően, hogy a modell merev test (pl. egy robot), vagy organikus felületű karakter. Egy jól szituált csontváz már lehetővé teszi az olyan másodlagos mozgásokat is, mint pl. a légzés vagy az izommozgás (3.1. ábra).

3.2. ábra – Csuklók [9]

A csontváz alap építőelemei az ún. csuklópontok (vagy 'jointok'), melyek mindegyikéhez egy vagy több csont kapcsolódik. Egy csuklóponthoz rendelt csont mozgásának lehetőségeit a pont attribútumai határozzák meg. A cselekvéseit limitálhatjuk például oly módon, hogy mennyire tud elforogni az előző csonthoz képest. A természetes (vagy kiinduló) pózhoz való visszatérési törekvést is szabályozhatjuk. (3.2. ábra)


TransMotion

- 14 -


3.2.2. Csuklópontok típusai (szabadsági fokoktól függően) • • •

Gömbcsukló (ball joint): három szabadsági fokkal rendelkezik, mindhárom tengelye körül képes forogni (pl. az ember válla) Kardáncsukló (universal joint): két szabadsági foka van, bármely két tengelye körül foroghat (pl. az ember csuklója) Könyökcsukló (hinge joint): egy szabadsági foka van, csak egy kedvezményezett tengelye körül tud forogni (pl. könyök, térd)

3.2.3. Csukló-láncolatok (joint chains) A csukló-láncon csuklók és csontok egy sorozatát értjük, mely egy csoportot alkot (3.3. ábra). A csukló-lánc a láncot alkotó legmagasabb hierarchiájú csuklónál kezdődik, ez a lánc szülő csuklója. 3.3. ábra – Csukló-láncok [9]

3.2.4. Végtagok (limbs) Végtagokon csukló-láncok egy vagy több összekapcsolt csoportját értjük (3.4. ábra). A kialakítható gráf topológiailag bármilyen típusú lehet; elágazásokkal teli fa (humanoid törzsétől az utolsó ujjpercekig), de pl. tartalmazhat hurkokat is (így speciális esetek, akár egy emberi száj animálása is megoldható - habár ettől léteznek alkalmasabb módszerek is). 3.4. ábra - Végtagok [9]

3.2.5. Csontváz-hierarchia A csontváz csuklók és csukló-láncok sorozatából áll, amik között hierarchikus kapcsolat van. Minden olyan csuklót, ami valamelyik másik csuklónál magasabb szinten helyezkedik el a csontváz-hierarchiában, szülőnek nevezünk. Hasonlóképpen minden olyan csuklót, aminél van magasabb szintű csukló, gyermeknek nevezünk. Minden csontváz rendelkezik pontosan egy gyökér (root) csuklóval. Az összes többi csukló ennek gyermeke, melyek a hierarchiai rendszer alsóbb szintjein helyezkednek el, így a gyökér hatással van a mozgásukra.


TransMotion

- 15 -


3.2.6. Forward / Inverse kinematics

3.5. ábra – Inverse Kinematics [9]

A csontváz-szerkezet mozgatására a Mayában kétféle módszer létezik. Az egyik a felülről-lefelé ható kinematika (Forward Kinematics), míg a másik ennek az ellentettje, az inverz kinematika (Inverse Kinematics - 3.5. ábra). A két elv látszólag ellentmond egymásnak, viszont a Maya 5.0-ás verziójában már megjelent egy hasznos funkció, mellyel súlyozottan egybe lehet őket olvasztani. A korábbi verziók csupán a kettő közti átkapcsolást tették lehetővé. [10] Forward Kinematics esetén a csukló-láncok csuklóinak mozgatása vagy forgatása egyesével történik, ha a lánc szülőjét mozgatjuk, annak mozgása hatással lesz az összes többi, a hierarchiában alatta elhelyezkedő csuklóra. A hierarchia alapján lefelé haladva határozzuk meg minden egyes csukló mozgását. Ideális megoldás például a váll-csukló forgatására, viszont alkalmazása nehézkes célzott mozgások esetében, pl. egy emberi kéz adott pontra irányításakor. Ezzel szemben az Inverse Kinematics olyan esetben ajánlott, amikor például egy lánc végét kívánjuk a megfelelő pozícióba mozgatni, ilyenkor az egyes csuklók orientációját és pozícióját a rendszer számítja ki helyettünk.

3.6. ábra – Karaktermodell [9]


TransMotion

- 16 -


3.3. A karaktermodell elkészítése Egy organikus felület létrehozása mindig is nagy kihívást jelentett a 3D grafikusok számára, ez a tény hatványozottan igaz egy bonyolult mozgást végző humanoid formára nézve. Szerencsére manapság a különböző modellező rendszerek már számos lehetőséget nyújtanak a folyamat megkönnyítésére. A felületgenerálás és -kezelés megoldására általában négyféle technikát használnak: • • • • •

Subdivision Surfaces NURBS Lo-Poly modelling Clay objects + hibrid módszerek

3.7. ábra - NURBS [9]

Ezek javarészt egymásba átkonvertálhatóak, bár mindegyik rendelkezik némi sajátos természettel, ami a többi elvével összeegyeztethetetlen. Szöges ellentétben áll például a poligonális megközelítés a NURBS-szel, az egyik roppant mód memóriaigényes, míg a másikhoz hatalmas számítási kapacitásra van szükség. A végeredmény persze előbb-utóbb (napjaink hardware-sajátosságaiból kifolyólag) minden esetben a poligonális megjelenítés lesz. Tulajdonképpen ezen technikák előnyei/hátrányai a modell tervezése közben, valamint az animálás során domborodnak ki. 3.3.1. Subdivision Surfaces Kevés adat / sok számítás – röviden így lehetne jellemezni. Ezzel a technikával elegendő egy alacsony poligonszámú modellt megtervezni, abból a Maya simításokkal, lekerekítésekkel egy sokkal részletesebb modellt hoz létre (túlzó, de szemlétes példa, hogy egy gömb modellezéséhez elég egy kockát megszerkesztenünk). Gyors szerkeszthetősége révén valószínűleg ez lesz az egyik legmegfelelőbb módszer (viszonylag kevés technikai manipulációt igényel). Az elkészült objektumot végül át lehet alakítani gyorsabban kezelhető felületté is. (Napjaink tendenciája a hardver-támogatottságú Subdivision surface felé irányul, ami meglehetősen izgalmas, új lehetőségekhez vezet.) [11] 3.3.2. NURBS Az előbbihez hasonlóan szintén kevés adat és sok számítás jellemző erre a technikára is. Nevét a Non-Uniform Rational B-splines (Bezier-splines) kezdőbetűiből kapta. Lényege, hogy a felület kontroll-pontok helyzete alapján generálódik, a pontokra legjobban illeszkedő felületek létrehozásával. Viszonylag kevés adattal leírható egy komplex egybefüggő felület (feltéve, ha az adott mérettartományban viszonylag sima). Modellezés szempontjából igen bonyolult, ellenben az elkészült modell könnyen kezelhető, több célra is jól alkalmazható (3.7. ábra). [11] Kertész Tamás, Rieger Péter László, Szolyka Sándor

TransMotion

- 17 -


3.3.3. Poligonális modell Sok adat / gyors számítás (alapvetően sok számítás, de hardverileg igencsak támogatott). Az ősi technika, karakter-modellezés szempontjából életképtelen megoldás. Ellenben a Lo-Poly (alacsony poligonszámú) modellek gyorsaság szempontjából még mindig a fő megjelenítési formát jelentik például 3D-s játékok esetében, továbbá remek alap a Subdivision Surface-ek control mesh-ének elkészítéséhez. [11] 3.3.4. Clay objects Elve alapján sok kis, higanycsepp-szerűen egymásba olvadó objektumból lehet felépíteni egy komplexebb egységet. Nem a legoptimálisabb technika, rengeteg processzoridőt használ. Nagy előnye viszont, hogy a legkülönbözőbb organikus felületek is elkészíthetők vele, amit végülis a megjelenítés során előnyösebb formába is át lehet konvertálni. 3.3.5. Hibrid módszerek Egy test különböző részeinek megalkotásánál - annak eltérő tulajdonságai miatt különböző módszerek alkalmazása javasolt. Célszerű például a fej és a többi testrész különválasztása a modellezés erejéig. Általában a fejet NURBS technikával szokás létrehozni (összetettsége, jellegzetes topológiája miatt), míg a törzset mondjuk Subdivision Surface-szel (annak fa-struktúrájából adódóan). Esetünkben talán érdemes számba venni, hogy léteznek (bár egyelőre alacsony számban) kifejezetten modellezésre szakosodott szoftverek. Ezek olyan magasabb szintű eszközöket nyújtanak, amik hosszú idők alatt kiforrott eljárásokon alapulnak. Céljuk a minél folyékonyabb munkamenet biztosítása. Modellező stílusuk már inkább hasonlít egy képlékeny anyaggal való gyurmázásra, mint a szokásos technikai részletekkel való vesződésre, ugyanakkor minden esetben szinte kifogásolhatatlan kimenetet produkálnak. Kezdők számára gyorsan és könnyen tanulható, profik kezében erőteljes megoldások: • • •

Pixologic Z-Brush CuriousLabs Poser IZware Nendo

A technikai módszerek tehát adottak, közülük a számunkra legmegfelelőbbet választva a következő lépés a modell-tervezés. Alternatív megoldást jelenthet az Interneten fellelhető, ingyenes, sok esetben precízen kidolgozott karakterek korlátlan tárháza is. Ezekből esetleg egy katalógusszerű gyűjtemény is készíthető, amelyből a kész rendszer felhasználója kényelmesen válogathat. [12]


TransMotion

- 18 -


3.4. Kiegészítő elemek hozzáadása a jelenethez Az elkészült modell önmagában még nem elég egy látványos előadáshoz. Fontos, hogy a karakter egy reális élettérbe, kontextusba kerüljön. Ez a látszólag másodlagos kiegészítés adja meg a jelenet élethűségét. Az igazán meggyőző látvány kedvéért (speciális esetben) a 3D-s szereplő még interakcióba is léphet környezetével (pl. tárgyakat mozgathat). Ezek az apró adalékok egyáltalán nem jelentenek nagy kihívást, viszont nagymértékben növelik a produkció színvonalát. Ilyen adalék-elemek például egy berendezett szoba vagy kültér, esetleg egy szimbolikus virtuális környezet (mint pl. a modernebb televíziós hírműsorokban). A realisztikus hatások csökkenő sorrendjében a következő elem a jó megvilágítás. Ezzel teremthetünk kellemes atmoszférát jeleneteinknek. A megfelelő anyagminták is létfontosságúak, ezzel adunk tárgyainknak természetes részletességet. További élethűséget ruhaszimulációval, dinamikai rendszerek hozzáadásával (pattogó tárgyak, füst, tűz, folyadékok, stb.) érhetünk el, a 'mai trendeknek' megfelelően. A végső látványkompozíció, ill. animáció megjelenítésének kétféle módja is szóba jöhet. Ha a gyorsaság az elsődleges szempont, ilyen célokra a 3D-s szerkesztőablak a legmegfelelőbb. Ez egy egyszerűbb megjelenítési forma, egészen valós-idejű kimenet érhető el vele. Képi minőség szempontjából pedig a. 'render ablak' a legjobb megoldás, mely (a sebesség rovására) közel foto-realisztikus látványt nyújt.

3.8. ábra - A modell és környezete


TransMotion

- 19 -


Hasonló rendszerek bemutatása, értékelése 4.1. Vicon A Motion Capture piac egyik legmeghatározóbb szereplője a Vicon Peak. Rengeteg megoldást kínálnak a különálló kameráktól a MoCap szoftvereken át a komplett rendszerekig. Elsősorban professzionális eszközökkel foglalkoznak, ezek a mi költséghatékony elképzeléseinktől meglehetősen távol állnak, de egy rövid áttekintés erejéig érdemes megvizsgálni, hogy milyen lehetőségek is rejlenek a technológiában [13]. Világelsőnek hirdetik MX40 típusjelzésű kamerájukat (4.1. ábra), mely 4 megapixeles (2352x1728) felbontású képet tud felvenni, másodpercenként akár 1000 képkockát rögzítve. A kamera három beépített processzorral rendelkezik, kimenete 10 bites szürkeárnyalatú kép. A markereket különböző hullámhosszú vörös fénnyel világítja meg. Egy ilyen csúcsminőségű kamera ára természetesen tudásához igazodóan hatalmas összeg.

4.1. ábra - A Vicon MX40 kamera [13]

A rendkívül jó fényvisszaverő képességű markerek a szabadban nehezen alkalmazhatók, ezért általában stúdiókban történik a jelenet rögzítése. Ezen stúdiók a természetes fénytől el vannak zárva, hogy a külső fényviszonyok ne zavarják meg a felvételt. A kamerák legtöbbje az objektív köré épített erős vörös fényt kibocsátó LED (infra-stroboszkóp) fényében dolgozik. Az eseményteret a markerek anyagából készült ragasztószalaggal körbekerítik, majd a középpontját is kijelölik. A kalibráció után a mozgásszínészeket egy szintén a rendszerhez tartozó ruhába bújtatják, melyre ráilleszthetőek a markerek. A ruha anyaga teljesen fényelnyelő, így arról semmilyen fény nem verődik vissza, ezáltal biztosítva, hogy ne keletkezzenek hibásan detektált pontok (Ghost Point-ok).


TransMotion

- 20 -


A Vicon rendszerek legtöbbje nyolc vagy annál több kamerát is képes egyidejűleg kezelni. Legújabb rendszerüknél nem is adtak meg felső határt, itt csupán a feldolgozó egység erején múlik a rákapcsolható kamerák száma. Elhelyezésükkel kapcsolatban nincs szigorú megkötés, csupán néhány javaslat. Ajánlott a kamerákat különböző magasságban és helyzetben elhelyezni úgy, hogy a kamerák látószögében az ’eseménytér’ (az a terület, ahol a jelenet le fog játszódni) a lehető legjobban látszódjon. A kamerák számát és elhelyezését befolyásolja a digitalizálandó jelenet bonyolultsága. Ha egy ember járását szeretnénk felvenni, akkor nem szükséges nyolcnál több kamera (a lényeg, hogy egy markert legalább három kamera lásson), viszont ha egy bonyolult jelenetet (pl. valamilyen tömegjelenetet) szeretnénk számítógépre vinni, akkor számolnunk kell azzal, hogy az egyes kamerák nézőpontjából sok kitakart marker lesz, ami megnehezíti a feldolgozást.

4.2. ábra - A Vicon MX rendszer felépítése [13]

4.2. Brainfactor Entertainment A Motion Capture technológia egyik legnagyobb magyarországi alkalmazója a Brainfactor Entertainment, akik elsősorban játékfejlesztéssel foglalkoznak, de mint az eddigi munkáik leírásából kiderül, számos területen fel tudták használni a VICON8-as rendszerrel felszerelt saját stúdiójukat. Mint írják, a rendszer real-time modellezésre is képes, ezt nagy előnyeként említik, mi is ilyen képességgel rendelkező rendszert szeretnénk megvalósítani. [2]


TransMotion

- 21 -


4.3. Milánói Egyetem Nagyon szemléletes videók találhatók a Milánói Egyetem egy tanárának honlapján, amik hasonlóak ahhoz, amit mi is létre szeretnénk hozni. Ez a rendszer egy egyszerű vázat alkot meg és azt mozgatja. Sajnos a leírásból nem derül ki, hogy képes-e real-time modellalkotásra, mint ahogyan a kamerák száma is rejtély marad. A videókat figyelmesen megnézve észrevehetjük a rendszer egy hibáját, hogy a kitakart pontokat nem ábrázolja. Ezen talán több kamera alkalmazásával vagy 'tippeléssel', azaz a kitakart pont legvalószínűbb helyzetének meghatározással lehetne segíteni. A mienkhez hasonlóan ez is egy hallgatói projekt. [14]

4.4. Pyros Pictures A Pyros Pictures honlapján rengeteg hasznos információ található, leírják a potenciális vevőik számára a MoCap folyamatát, hogy hogyan kell felkészülniük, mielőtt a stúdióba vonulnának. Színészek: rendkívül fontosnak tartják profi színész alkalmazását, kezdetben ez számunkra nem kivitelezhető a költségek miatt, viszont a fejlesztés fázisában bőven elég is, ha mi magunk végezzük a színész munkáját. Ha majd egyszer a rendszerünk kereskedelmi forgalmazásra alkalmas állapotba kerül, akkor ráérünk ezzel a problémával foglalkozni. Eszközök: mindegy, hogy a felvétel során használt eszközök hogyan néznek ki, hiszen az utolsó fázisban úgyis egy tetszőleges 3D-s modellhez lesznek a pontok hozzárendelve, csak az a lényeg, hogy segítsék a színészt az élethű mozgásban. Nagyon fontos továbbá, hogy ne takarják ki a markereket, pl. egy asztal célszerűen csak csövekből álljon. Kerülni kell a fényes vagy tükröződő anyagokat, mert ezek jelentősen megnehezíthetik a feldolgozást. Ruha: kulcsfontosságú eszköz; feszes, testhezálló ruhákra van szükség, mert ha a ruha túl laza és mozog a színészen, akkor a markerek is mozogni fognak, ez pedig nem kívánt mozgást fog eredményezni az elkészült modellen is (rezegni fognak az egyes pontok). Egy darabból álló aerobic ruha ajánlott. Több napos munkánál feltétlenül ugyanazt a ruhát kell alkalmazni, a markerek helye is fix kell, hogy legyen. Real-time: a rendszer nem rendelkezik ezzel a képességgel, ez a megbízónak plusz kiadásokat okozhat, hiszen ha nem tudják eldönteni, hogy két felvétel közül melyik a jobb, akkor mindkettőt fel kell dolgoztatniuk, viszont ennél a cégnél ez dupla költséget jelent. Egy real-time rendszernél ez nem okozna gondot, hiszen azonnal eldönthetné a vevő, hogy melyik mozgás a megfelelőbb számára. Tehát ha a mi rendszerünk képes lenne a valós idejű feldolgozásra, az a potenciális megbízók számára vonzóbb lehetne az e képességgel nem rendelkező megoldásokkal szemben. [1]


TransMotion

- 22 -


TransMotion 5.1. A rendszer fő moduljai Az elméleti jellegű bevezető részek után következzen saját munkánk ismertetése, az általunk eddig elért eredmények bemutatása. Feladatunk igen komplex, így a megvalósítás számos részfeladatra tagolható. A moduláris felépítés remekül illeszkedik a napjaink trendjéhez, a különálló komponensek elkészítése rugalmas felhasználhatóságot, könnyű bővíthetőséget eredményez, ugyanakkor külön problémát jelent az egyes modulok összekapcsolása. A rendszer a következő fő részekből épül fel: • • • • • • • •

Kalibráció Kamerakezelés Főprogram, felhasználói felület Képfeldolgozás A 3D-s koordináták kiszámítása A két rendszer összekapcsolása A Performance Animation környezet konfigurálása A 3D-s környezet kialakítása

5.1. ábra - Adatút a rendszeren belül


TransMotion

- 23 -


5.2. Kalibráció 5.2.1. A kamerák elhelyezése A helyes kamerapozíció rendkívül fontos, hogy használható felvételeket készíthessünk. Ha például a kamerákat egy teremnek ugyanazon a falán helyezzük el, akkor a színészt csak az egyik oldaláról látjuk, így számos markert elveszíthetünk. Célszerű tehát úgy elhelyezni őket, hogy a színészt lehetőleg minden oldalról láthassuk, így minimalizálható az elveszett markerek száma. Általánosan megfogalmazva, a kamerákat egy olyan gömb felületén kell egyenletesen elosztva elhelyezni, aminek középpontja a színész. Kitakarásokra természetesen ekkor is számítani kell, a fedésben lévő markerek problémája utófeldolgozással oldható meg. A mi esetünkben három kamerát kell elhelyeznünk megfelelően. A legjobb megoldásnak az látszik, ha a színész körül egy szabályos háromszöget képezünk belőlük, így mindegyik nagyjából 120 fokos szögben látja a színészt.

5.2. ábra - A kamerák elhelyezése


TransMotion

- 24 -


5.2.2. A kameráink A fejlesztéshez feltétlenül szükségünk van kamerákra, mivel csak ezek segítségével tudunk kísérletezni, tesztelni. Szerencsére rendelkezünk is három webkamerával, amik az említett célokra tökéletesen megfelelnek, professzionális alkalmazásra természetesen komolyabb eszközökre lenne szükségünk. A készülékek típusa Logitech QuickCam Zoom, a webkamerák mezőnyében viszonylag drágának számító készülékek, melyeket iskolánk bocsátott rendelkezésünkre, ezúton is köszönjük. 5.3. ábra - Logitech QuickCam Zoom

A kamerák egyik legfontosabb paramétere a felvétel felbontása, jelen esetben a gyártó ezt 640x480 képpontban maximalizálta, de mi többnyire 320x240-es felbontással használjuk a gyorsabb feldolgozás érdekében (hiszen a két pixelmennyiség között négyszeres a különbség). A másik legfontosabb érték a frissítési gyakoriság (frame rate), kameráink másodpercenként 30 különböző képet tudnak felvenni. A számítógéphez való csatlakozás USB-n keresztül történik. 5.2.3. Külső paraméterek A kamera külső paraméterei (Extrinsic parameters) határozzák meg a kamera pozícióját és orientációját a világ-koordinátarendszerben; az R rotációs mátrix és a T eltolás vektor. Ezen paraméterekre a későbbiekben szükségünk lesz, hogy a 3D-s koordináták számításakor kapott, a kamera saját lokális koordinátarendszerében értelmezett koordinátákat átszámíthassuk a világ-koordinátarendszerbe. A paraméterek meghatározásához először is fixen el kell helyezni a kameráinkat a felvétel eseménytere körül. Ha elmozdulnak, újra kell kalibrálni őket, mivel akkor a viszonylagos pozíciójuk és irányuk megváltozik. A paraméterek kiszámításához valamilyen ismert mintát kell használnunk, amit a világ-koordinátarendszer origójában (tipikusan az eseménytér közepén) helyezünk el. Gyakran használnak mintaként két egymásra merőleges, eltérő hosszúságú vonalat, amik mérete ismert (5.4.ábra). Ennek az L-betűnek a szárai kamera képén valahányszoros kicsinyítésben láthatók és egymással valamekkora szöget zárnak be, ezen adatok segítségével határozhatjuk meg a külső paramétereket.


TransMotion

- 25 -


5.4. ábra - Kalibrációs minta [grail.cs.washington.edu]

5.2.4. Belső paraméterek A kameráink belső paramétereinek (Intrinsic parameters) kiszámítását a GraphEdit nevű segédprogrammal valósítottuk meg (5.5. ábra), ami alapvetően a DirectShow szűrőinek kipróbálására való. A program által tartalmazott szűrők között megtalálható számos egyéb, a számítógépre telepített szűrő, így például az OpenCV-hez tartozó CalibFilter is (5.6. ábra) [15]. Ennek használatához elsőként szükségünk volt egy a kamera által jól felismerhető mintára. A program sakktábla-szerű mintát használ (5.7. ábra), ezt megfelelő méretben kinyomtatva elkezdhettük a kalibrálást.

5.5. ábra - Filterek használata a GraphEdit-ben


TransMotion

- 26 -


A program meghatározott időközönként képeket rögzít, de csak akkor, ha megtalálta a keresett mintát. Jelen esetben 9 oszloppal és 7 sorral rendelkeztünk, így összesen 8*6 pontot keresett, a fekete és fehér négyzetek csúcsainak találkozási pontjait. A minta sikeres felismerését színes vonalak jelzik. (5.8. ábra)

5.6. ábra - A CalibFilter konfigurálása

Kellő mennyiségű kép rögzítése után a CalibFilter kiszámítja a kamera belső paramétereit, majd egy txt fájlba elmenti az adatokat (2. táblázat). Ezután megtekinthető a kalibrált, valós kép, ami esetünkben csak minimálisan tért el a kamera eredeti képétől. Felmerült, hogy talán nincs is szükségünk kalibrációra, mert kameráink már gyárilag kalibráltak, de a térbeli koordináták számításakor a három kamera hibája együttesen jelentkezik, így már sokat ronthat a rendszer pontosságán, ezért mégsem hagyhatjuk ki ezt a lépést.

5.7. ábra - Kalibrációs minta

5.8. ábra - Felismert minta


TransMotion

- 27 -

paraméter fókusztávolság (fc) optikai középpont (cc) pixelarány (s) radiális torzítás (k1) radiális torzítás (k2) tangenciális torzítás (p1) tangenciális torzítás (p2)

1. kamera [410,7; 412,7] [166,1; 105,1] 0 - 0,038192 0,181668 - 0,002969 - 0,001587

http://transmotion.no-ip.org 2. kamera [411,1; 411,7] [158,4; 111,5] 0 - 0,090304 0,268627 - 0,002003 - 0,002035

3. kamera [408,6; 410,1] [167,1; 98,7] 0 - 0,008231 - 0,039288 - 0,002138 - 0,001269

2. táblázat - A kamerák belső paraméterei

5.3. A kamerakezelő modul 5.3.1. Mivel kezeljük a kamerákat? A kamerakezelő modul projektkörnyezetbe való illesztésével kapcsolatban kompromisszumokkal teli, nehéz döntés elé álltunk. Ezzel kapcsolatban a fő problémát a (3D-s térlátáshoz szükséges) kettő, illetve több kamera szimultán használata jelenti. Egyéb ismert rendszerekkel, pl. az OpenCV-vel szemben a DirectShow lehetőségeit találtuk a legelőnyösebbnek számunkra. Döntésünket a következő tapasztalati tények indokolják: • • •

az OpenCV a DirectShow-val szemben nem támogatja kettőnél több kamera egyidejű használatát a DirectShow önmagában nem, de a DirectShowLib, mint ennek .NET-es kiterjesztése lehetővé teszi a .NET-es C# környezetben való alkalmazást is szükség esetén a DirectShowLib-et felhasználó kód C#-ból könnyen portolható C++ nyelvre

5.3.2. Mi is az a DirectShow? A Microsoft által Windows platformra készített DirectShow API (Application Programming Interface) egy ’média-folyam architektúra’, melynek segítségével nagyon jó minőségű audió-videó alkalmazások készíthetők mind visszajátszáshoz, mind pedig rögzítéshez. Számos multimédia formátumot támogat (pl. tömörített videó- ill. hanganyagokat is kezel), valamint a Windows-ra külön telepített kodekeket is elérhetjük általa. Gyakorlatilag lehetőség nyílik minden olyan analóg és digitális eszközről való rögzítéshez, mely a WDM-en (Windows Driver Model) vagy a ’Video for Windows’-on alapul. A DirectShow, mint a DirectX technológia szerves része, képes automatikusan észlelni és kihasználni a jelen lévő audió/videó-gyorsító hardvereket is. Használatával leegyszerűsödik a média-lejátszás, -konvertálás és –rögzítés, miközben alsóbb rétegű folyamvezérlőkhöz is hozzáférést biztosít. Esetünkben ez utóbbi tulajdonsága nagymértékben hozzájárul munkánkhoz, mert egyéni megoldásokat alakíthatunk ki általa. [16]


TransMotion

- 28 -


5.3.3. Hogyan működik a DirectShow? A DirectShow a különböző adatforrások, formátumok és hardvereszközök kezelése érdekében moduláris architektúrával rendelkezik; különböző szoftver komponenseket, úgynevezett filtereket (szűrőket) vegyít és kapcsol össze. Az összekapcsolt filterek egy adatfolyam-gráfot alkotnak, amit felvétel esetén ’Capture Graph’-nek hívnak. Általános Capture Graph-ben az adatút a forrás-szűrőtől (Capture Filter) különböző transzformációs szűrőkön keresztül a megjelenítő szűrőig (Video Renderer) tart.

5.9. ábra - A DirectShow architektúra [16]

5.3.4. Hogyan használjuk a DirectShow-t videó-felvételre? Első lépésként fel kell építenünk a capture-folyamatot végző gráfot. A mi esetünkben a Capture Graph-ből a felvétel során kihagyható az utolsó filter, ami a videó-megjelenítést végzi, így a gráf csak két elemből, a Capture Filter-ből és a ’Sample Grabber’-ből áll. A Sample Grabber filter segítségével tudunk a videóból képeket kinyerni. Ha a Motion Capture felvételnél a kamerák által látott kép közvetlen megjelenítésére is szükségünk van, a gráfot kiegészíthetjük egy kis erőforrásigényű Video Renderer szűrővel, ekkor az egykimenetű SampleGrabber filtert ’Smart Tee’-re kell cserélnünk. A Capture Graph-ek általában sokkal bonyolultabbak, mint a fájlból való visszajátszásra készített gráfok. Ezért a DirectShow egy, a Capture Graph megépítését segítendő plusz osztállyal szolgál, amit ’Capture Graph Builder’-nek hívnak. Ez az osztály egy ’ICaptureGraphBuilder2’ típusú interfésszel rendelkezik, ami Capture Graph-építő metódusokat tartalmaz. Az ezekből példányosított objektumok segítségével már megépíthető a capture-folyamatot végző gráfunk.


TransMotion

- 29 -


Második lépésként a Capture Graph vezérlését is meg kell oldanunk, ezt az ’IMediaControl’ interfész alapján tehetjük meg. Az ehhez hozzárendelt gráf elindítására, megállítására és a futás felfüggesztésére van lehetőségünk metódusai által.

5.10. ábra - Capture Graph Sample Grabber-rel

5.11. ábra - Capture Graph Smart Tee és Video Renderer filterrel


TransMotion

- 30 -


5.3.5. A Capture osztály A Capture osztály feladata, hogy megteremtse a kapcsolatot a DirectShow-val. Ezt a ’DshowLib’ library-n keresztül oldottuk meg, mely lehetővé teszi számunkra a DirectShow rendszerének felhasználását .NET környezetben. Az osztály metódusai: •

•

•

• •

Capture: 1 + 3 túlterhelt (overloaded) konstruktor metódus, mellyel megadhatjuk a használni kívánt kamera sorszámát, a felvétel képfrekvenciáját (frame rate), valamint a kimeneti kép szélességét/magasságát pixelben. A metódus számba veszi a rendszerre csatlakoztatott kamerákat, majd a megadott sorszámút aktiválja. Ezután meghívja a ’SetupGraph’ metódust, ami létrehozza a Capture Graph-et. SetupGraph: ebben a metódusban építjük fel a gráfot. Létrehozzuk a Graph Builder-t, valamint a filter objektumokat (SampleGrabber, SourceFilter). Konfigurálásuk után a két filtert (a GraphBuilder objektummal) hozzáadjuk a Capture Graph-hez. Ezután az elkészült gráf készen áll a capture-folyamat elindítására. Start: ezzel indíthatjuk el a capturefolyamatot. A gráf MediaControl objektumának adja ki az utasítást a lejátszásra. Pause: ezzel függeszthetjük fel az éppen futó capture-folyamatot. GetBitMap: az aktuális kép memóriabeli kezdőcímével tér vissza. 5.12. ábra - A Capture osztály


TransMotion

- 31 -


5.4. A főprogram 5.4.1. A .NET keretrendszer és a C# programnyelv Fejlesztői környezetként a Microsoft Visual Studio .NET 2003-at választottuk, ami a .NET keretrendszer alkalmazására épül (.NET Framework 1.1). A .NET általános problémákra egyszerű megoldást kínál, rugalmas, ezáltal a fejlesztés tempója nagymértékben felgyorsul. Korszerű technológia, mely pozitívan hat projektünk jövőbeli fejlesztésére, kiegészítésére. Stabil, hibatűrő rendszert eredményez, mely teljesítményben is felveszi a versenyt a hagyományos, natív kóddal. Előnye továbbá a kompatibilitás, platformfüggetlenség - távlati céljaink között szerepel a kézmozdulatokkal való számítógép-vezérlés, akár különböző mobil eszközökkel is. A .NET-re alapuló programnyelvek fő képviselője a C#, mellyel a leginkább érdemes elindulni a fejlesztés útján. Míg a főprogram C# nyelvben készül, beépülő moduljai egyéb programnyelvekben írt kódok is lehetnek. Bár nincs nagy sebességbeli különbség, bizonyos esetekben, például a tipikusan erőforrás-igényes képfeldolgozó résznél mégis szükség lehet a C++-ban rejlő lehetőségekre. Az első megközelítésre tisztán C#-ban, gyorsan és egyszerűen megírt program a későbbiekben egy hatékonyabb C++ kód prototípusául szolgálhat.


TransMotion

- 32 -


5.4.2. Interaktivitás A főprogram egyik feladata, hogy kapcsolatot teremtsen a felhasználóval. A felhasználói felület jelenleg a következő funkciókkal rendelkezik: • • • • • •

a kamera felvételi paramétereinek beállítása a megtalálandó markerek tulajdonságainak definiálása markereknek a csontváz kontrollpontjaihoz történő hozzárendelése hálózati kapcsolat konfigurálása kimeneti fájl megadása a mozgásfelvétel elindítása

A továbbiakban a felhasználói felület még számos egyéb beállítási lehetőséggel fog bővülni. Meg lehet majd adni például, hogy milyen modell mozgását szeretnénk követni, például ember, kutya, stb. Ekkor ki fog rajzolódni egy leegyszerűsített csontváz-modell, amin megadhatjuk a marker-csukló párokat. Lehetőség lesz megtekinteni a kamerák képét is, de kezdetben valószínűleg a rendszer nem lesz olyan gyors, hogy egyszerre jelenítse meg és dolgozza fel a három kamera képét.

5.13. ábra - A felhasználói felület


TransMotion

- 33 -


5.4.3. A modulok integrálása A főprogram (MainForm) másik feladata az egymástól jól elkülöníthető modulok összekapcsolása. A rendszer jelenlegi moduljai egy-egy osztálydefiníciót tartalmaznak (5.14. ábra). A MainForm ezekből egy-egy objektumot példányosít, melyek segítségével eggyel magasabb absztrakciós szinten képes megoldani az összetett MotionCapture problémát. Plusz feladatot jelent továbbá a kiszámolt adatok fájl- és hálózati kimenetre való küldése, ennek megoldása a MainForm saját osztályán belül történik.

5.14. ábra - Programmodulok


TransMotion

- 34 -


5.5. A képfeldolgozó modul A képfeldolgozásért az ImageProcess nevű modul felelős. Ennek része a MarkerDetection osztály, melynek adattagjai tartalmazzák a feldolgozni kívánt kép, valamint a keresett markerek tulajdonságait: Kép: a feldolgozni kívánt kép memóriabeli kezdőcíme a bmpPtr nevű, IntPtr típusú pointerben tárolódik, a hivatkozott kép formátuma pedig a (BitmapData típusú) bmpData tagváltozóban. Ezek beállítására két property, a SetBmpPtr és a SetBmpData szolgál. A bmpData által érhető el a kép (feldolgozáshoz szükséges) pixelformátuma, egy sorának hossza byte-ban, valamint szélessége és magassága. Az osztály metódusai ezen beállított paraméterek alapján számítják a memóriacímeket. Marker: a marker-detektáláshoz szükségesek a markerek jellemző tulajdonságai, ami alapján a keresés történik. Ezen attribútumok például a marker színe, nagysága, az előző pozíciója (a hatékonyabb keresés érdekében). 5.15. ábra - A MarkerDetection osztály

A jelenlegi (TDK bemutatóra szánt) verzióban a marker-keresést egy egyszerű algoritmus végzi, mely egyetlen fehér markert detektál, képterületenként összegzett színintenzitás alapján. A modult olyan külső könyvtár(ak) függvényeivel tervezzük kiegészíteni, melyek jól optimalizált képfeldolgozó rutinokat tartalmaznak. Ilyen pl. az Intel OpenCV library, mely jellemző pontok gyors megtalálására kínál egyszerű megoldást.

5.6. A 3D-s koordináták kiszámítása A kalibrációs eljárások során megkapott információk (a kamera pozíciója a világkoordinátarendszerben, a kamera orientációja) segítségével kiszámíthatóak a markerek térbeli helyzetének koordinátái. Mivel színes markereket alkalmazunk, a színkódok alapján triviálisan össze tudjuk párosítani a három képről származó marker információkat. Első lépésben a megtalált pixel koordinátákat az alábbiak szerint átalakítjuk kamera koordinátarendszerbe, ahol Xim, Yim a képpont pixel koordinátái, Ox, Oy a kép optikai középpontja (ezen a ponton metszi – derékszögben – a kamera Z irányú tengelye a képsíkot), sx, sy a pixel effektív mérete, valamint Xc, Yc és Zc a számítandó kamerakoordinátarendszerbeli értékek.


TransMotion

- 35 -


X c = −( X im − O x ) s x Yc = −(Yim − O y ) s y Zc = 0 Második lépésként ezeken az értékeken a kalibráció során kinyert adatok segítségével egyszerű transzformációkat hajtunk végre, így megkapva a világkoordináta rendszerben lévő pontot.

⎡X w ⎤ ⎡X c ⎤ ⎡X c ⎤ ⎡X w ⎤ ⎢ Y ⎥ = R ⎢ Y ⎥ + T ⇒ ⎢ Y ⎥ = R −1 ⎢ Y ⎥ − T ⎢ w⎥ ⎢ c⎥ ⎢ c⎥ ⎢ w⎥ ⎢⎣ Z w ⎥⎦ ⎢⎣ Z c ⎥⎦ ⎢⎣ Z c ⎥⎦ ⎢⎣ Z w ⎥⎦ ahol R a rotációs mátrix, T a kamera pozíció Mivel egy egyenest két pontja egyértelműen meghatározza, a kapott pont és a kamera fókuszpontja segítségével húzunk egy egyenest mindhárom kamera esetében. Ezeknek elméletileg egy pontban kell metszeniük egymást, ez pedig a keresett pont világkoordinátarendszerbeli pozíciója. A három egyenes egy – három egyenletből álló – három ismeretlenes lineáris egyenletrendszert alkot, aminek ismeretlenei a Cramer-szabály vagy Gauss-elimináció segítségével könnyedén kiszámíthatók.

5.16. ábra - Az egymást egy pontban metsző egyenesek

5.6.1. Az egyenletrendszer megoldása Egy egyenletrendszer megoldható a változó helyettesítés módszerének általánosításaként ismert Cramer-szabály alkalmazásával. Eszerint az egyenletrendszer felírható az alábbi módon, ahol az A mátrix az együttható-mátrix, x az ismeretlenek oszlopvektora, valamint b az eredmény oszlopvektora.

Ax=b Kertész Tamás, Rieger Péter László, Szolyka Sándor

TransMotion

- 36 -


Esetünkben háromszor hármas mátrixként felfogva:

⎛ a 11 ⎜ ⎜ a 21 ⎜a ⎝ 31

a 12 a 22 a 32

a 13 ⎞⎛ x1 ⎞ ⎛ b1 ⎞ ⎟⎜ ⎟ ⎜ ⎟ a 23 ⎟⎜ x 2 ⎟ = ⎜ b2 ⎟ a 33 ⎟⎠⎜⎝ x 3 ⎟⎠ ⎜⎝ b3 ⎟⎠

Az egyenletrendszer ismeretleneit könnyen megkaphatjuk a következő hányadosok képzésével. (Amennyiben A mátrix determinánsa nem nulla!)

D1 detA D x2 = 2 detA D x3 = 3 detA x1 =

D1, D2 és D3 azon mátrixok determinánsai, melyeket úgy képzünk, hogy az A mátrix első, második illetve harmadik oszlopát kicseréljük a jobb oldalon szereplő b eredményvektorra.

⎛ b1 ⎜ D1 = ⎜ b 2 ⎜b ⎝ 3

a 12 a 22 a 32

a 13 ⎞ ⎛ a 11 ⎟ ⎜ a 23 ⎟ D2 = ⎜ a 21 ⎜a a 33 ⎟⎠ ⎝ 31

b1 b2 b3

a 13 ⎞ ⎛ a 11 ⎟ ⎜ a 23 ⎟ D3 = ⎜ a 21 ⎜a a 33 ⎟⎠ ⎝ 31

a 12 a 22 a 32

b1 ⎞ ⎟ b2 ⎟ b 3 ⎟⎠

5.7. A két rendszer összekapcsolása Az egyik fő feladatot a rendszer két különálló komponensének összekapcsolása jelenti, melyek a gyors adatfeldolgozás érdekében terv szerint külön számítógépen futnak. Erre azért van szükség, mert a komplex, animált 3D-s objektumok real-time megjelenítése már önmagában nagymértékű erőforrást igényel. A két számítógép közti folytonos adatkapcsolatot TCP/IP protokollon keresztül oldjuk meg. 5.7.1. Maya Motion Capture API Library

A Maya egy rendkívül összetett rendszer, de kiváló strukturáltsága révén mégis könnyen átlátható és kezelhető. Képességei a 3D-s grafika minden részterületére kiterjednek, így lehetőséget biztosít számunkra a jól kidolgozott Motion Capture technikák könnyed használatához. A fejlesztőknek kiadott ’Maya Motion Capture API Library’ tartalmazza az általános MoCap függvényeket. Kertész Tamás, Rieger Péter László, Szolyka Sándor

TransMotion

- 37 -


Az alapelgondolás szerint létezik egy szerver ill. egy kliens process, melyek a gépek közti adatforgalmat bonyolítják. A beépített függvények használata mentesíti a programozót a kommunikációs részletek kimunkálásától. A folyamatok egymás közt socket-eken keresztül kommunikálnak, nekünk csak ezekkel kell foglalkoznunk, a hálózat konkrét működése számunkra transzparens. Ez lehetővé teszi azt is, hogy a szerver és a kliens Maya akár egyazon gépen fusson. A MoCap szerverrel egyedi névvel ellátott csatornákat hozhatunk létre. Ezek mind független adatfolyamok, rendelkeznek külön speciális felhasználási céllal és adattípussal. [17] A szerver library kb. 20 felhasználó által hívható rutint tartalmaz, melyek 4 kategóriába sorolhatók: • • • •

kliens/szerver kommunikációs rutinok, melyek kommunikációs protokollt, sorrendtartó adat-struktúrát, valamint hibaüzeneteket kezelnek soros-port kezelő rutinok, melyekkel soros vonali eszközöket használhatunk a ’termio.h’ beható ismerete nélkül Quaternion kezelő rutinok: Euler-szögek, quaternionok és mátrixok közti konvertálást biztosítják az általános szerver rutinokkal socket-eket hozhatunk létre, és inicializálhatjuk azokat a szerver/kliens kommunikációhoz.

Ezen rutinok részletes referencia-szintű ismertetését a Motion Capture API Guide tartalmazza. [18] A szerver-kliens architektúra fent ismertetett megvalósításának kapcsán a következő probléma merül fel: míg a MotionCapture rész menedzselt kódú rendszer, a Maya hálózatkezelő rétege natív kódot használ. Bár ezek egymással alapvetően összeegyeztethetetlenek, a problémának mégis létezik egzakt megoldása: a nem menedzselt kód .NET környezetbe való beemelése „Platform invoke” vagy „COM interop” használatával (előbbi menedzselt kódból történő külső DLL függvények hívását jelenti, míg utóbbi COM objektumok elérését interfészeken keresztül).

5.8. A Performance Animation környezet konfigurálása A megjelenítő felület kialakítására két lehetőség adódik: a Maya saját szerkesztőfelületének alkalmazása, valamint különálló Maya Application létrehozása. Míg az előbbi a megjelenítésen túl a Maya teljes funkcionalitását kínálja, utóbbi pusztán a megjelenítésért felelős. A Maya Application a Maya főprogramjától független alkalmazás, ám annak library függvényeit használja fel.


- 38 -

TransMotion


A környezet kialakításáért egy a Mayába ágyazott MEL (Maya Ebedded Language) script felelős, mely a következő feladatokat végzi: • • • • •

létrehoz egy grafikus felhasználói felületet, ahol a felhasználó válogathat az előre elkészített 3D-s karakter-modellekből és az őket körülvevő környezetekből betölti a kiválasztott „scene”-eket, ami megjelenik a megjelenítő/szerkesztő felületen megteremti a kapcsolatot a Motion Capture szerverrel, az adatcsatornákat hozzárendeli a ’motion capure device’-hoz a device adatfolyamait 3D-s pontokhoz kapcsolja, melyek a karaktercsontvázat mozgatják végül pontatlanság-javító expression-öket hoz létre, amiket a csontvázszerkezethez csatol

5.9. A 3D-s környezet kialakítása A Performance Animation során megjelenített 3D-s virtuális karakter(ek) és környezetük (virtuális világ) kialakítása első lépésben egy grafikai design folyamatot jelent (látványtervezés). Ha a látható objektumok elkészültek, további feladat ezek működési rendszerének felépítése, amitől maga az animálás leegyszerűsödik számunkra. A karakteranimáció, ruha-szimuláció, dinamika és egyéb komplex rendszerek tipikus esetek; az egzakt mozgásokat a rendszer számítja. További teendőnk az objektumokhoz textúrát (mintát) rendelni, valamint fényforrásokat adni a jelenethez. A teljes folyamat részletes ismertetése nem feladata dolgozatunknak, ezekkel a technikákkal a Maya dokumentációi kimerítően foglalkoznak.

5.10. Tesztelés, az eredmények értékelése A rendszernek egyelőre a kamerakezelő és a markerdetektáló része van tesztelhető állapotban, ezért ezekkel végeztünk méréseket. A tesztgép egy AMD Athlon 64 3000+ processzoros számítógép volt, a többi hardvereszköz a teszt szempontjából lényegtelen. A gépen Windows XP SP2 operációs rendszer futott és a .NET Framework 1.1 volt telepítve. A Visual Studio Release módba volt állítva. A teszteredmények a processzoridő használatának százalékában értendők. beállítások 640x480 marker nélkül 640x480 markerrel 320x240 marker nélkül 320x240 markerrel

minimum 15 % 24 % 5% 9%

átlag 23 % 33 % 11 % 16 %

maximum 29 % 40 % 18 % 23 %

3. táblázat - A teszteredmények


TransMotion

- 39 -


Az eredményekből jól látható, hogy a felbontás jelentős mértékben befolyásolja a sebességet, a különbség körül-belül kétszeres. A markerdetektálás lassít ugyan, de elfogadható határon belül. Igaz viszont, hogy ez még csak egy nagyon kezdetleges eljárás, a továbbiakban ennél jóval bonyolultabb kódra lesz szükségünk, ráadásul több markert is detektálnunk kell majd egy képen. A program jelenlegi állapotában, a markerdetektálás bekapcsolásával, három kamera egyidejű alkalmazása esetén, 640x480-as felbontásban már kevésnek bizonyulna a rendszer teljesítménye, de 320x240-ben még kezelni tudná mindhárom kamerát. Bebizonyosodott, hogy a kód roppant mód erőforrás-igényes, így a megfelelő optimalizáció kritikus fontosságú.

5.11. Összefoglalás, továbbfejlesztési lehetőségek A rendszer természetesen még nincs kész. Három ember néhány hónap alatt nem képes létrehozni egy teljes Motion Capture rendszert. De munkánk megalapozása megtörtént, megismerkedtünk a szükséges módszerekkel, a téma publikációjával, a szakirodalommal. Az első lépéseken túl vagyunk, a fejlődés folyamatos. A kalibrációt illetően a belső paraméterek kiszámítása kész, a külső paraméterekkel még foglalkoznunk kell. A kamerák képét már tudjuk kezelni, de a kód még erős optimalizációra szorul, továbbá a három kamera egyidejű használata is megoldásra vár. A főprogramban sikerült összekapcsolni az egyes modulokat, a felhasználói felület rendelkezik már számos funkcióval, de még kezdetleges, rengeteg kiegészítést igényel. A markerdetektálás kísérleti jelleggel már működik, de a késztől még távol van. A 3D-s koordináták visszafejtésének matematikai háttere ismert, ennek implementációja az egyik legfontosabb feladatunk az elkövetkező hónapokban. A hálózati kommunikáció megvalósítása közel kész. A Performance Animation rész már használható állapotban van, itt még a 3D-s modellek, objektumok elkészítése a feladatunk. A jövőre nézve vannak már elképzeléseink, terveink. Rövidtávon a hiányzó vagy félkész részekkel kívánunk foglalkozni, rengeteg munka vár még ránk. Hosszabb távon a rendszer egyéb területeken való felhasználása szerepel terveink között, ilyen lehet például a számítógép kézzel történő vezérlése, ami egy izgalmas, lehetőségekkel teli, jelenleg kiaknázatlan terület. A Motion Capture technológia bár már most is komoly szereplője a játékiparnak, de mi egy egészen új alkalmazási módon gondolkozunk, történetesen a játékok MoCap segítségével történő vezérlésére, ami a játékélményt soha nem látott szintre emelhetné.


- 40 -

TransMotion


Irodalomjegyzék 6.1. Felhasznált irodalom [1] Pyros Pictures, Inc. http://www.pyros.com [2] Brainfactor Entertainment KFT. http://www.brainfactor.com [3] Experimental Motion Capture Systems Development http://www.rpi.edu/~ruiz/research/research2/krmkmocap.htm Utolsó látogatás: 2005.11.06. [4] ACM SIGGRAPH (Special Interest Group on Computer Graphics) Education Committee http://www.siggraph.org/education/materials/HyperGraph/animation/character_animation/ motion_capture/history1.htm Utolsó látogatás: 2005.11.06. [5] Carneige Mellon Entertainment Technology Center, Marker Placement Guide http://www.etc.cmu.edu/projects/mastermotion/Documents/markerPlacementGuide.doc Utolsó látogatás: 2005.11.06. [6] University of Washington, Computer Science & Engineering http://www.cs.washington.edu/ Utolsó látogatás: 2005.11.06. [7] Vaxjö Universitet, Matematiska och Systemtekniska Institutionen Construction of a Motion Capture System http://www.msi.vxu.se/forskn/exarb/2004/04087.pdf [8] Alias Systems Corp. http://www.alias.com [9] Maya Unlimited v5.0 Documentation: CharacterSetup.pdf http://www.3dlinks.com (Maya Tutorials) Utolsó látogatás: 2005.10.06.


TransMotion

- 41 -


[10] Maya Unlimited v5.0 Documentation: CharacterSetup.pdf – Skeletons http://www.3dlinks.com (Maya Tutorials) Utolsó látogatás: 2005.10.06. [11] Maya Unlimited v5.0 Documentation: SubDs.pdf, NURBS.pdf, Polygons.pdf http://www.3dlinks.com (Maya Tutorials) Utolsó látogatás: 2005.10.06. [12] Fej-modellező leckék http://www.highend3d.com/maya/tutorials/patch/ Utolsó látogatás: 2005.05.12. [13] Vicon Peak http://www.vicon.com [14] Borghese, A. N. Department of Computer Science, University of Milano http://homes.dsi.unimi.it/~borghese/Research/MotionCapture.html Utolsó látogatás: 2005.11.06. [15] OpenCV CalibFilter http://w3.impa.br/~pcezar/3dp/original/CVL_html/appPage/doc_calib.html Utolsó látogatás: 2005.10.22. [16] Microsoft Platform SDK http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ Utolsó látogatás: 2005.10.11. [17] Maya DevKit Documentation, Motion Capture API / Motion Capture Design Philosophy [18] Maya DevKit Documentation, Motion Capture API Guide


- 42 -

TransMotion


6.2. Ajánlott irodalom [1] ‘A legkiválóbb 3D-grafikai oldal’ (technikai szempontból) http://www.highend3d.com Utolsó látogatás: 2005.11.06. [2] ’A legkiválóbb 3D-grafikai oldal’ (művészi szempontból) http://www.raph.com Utolsó látogatás: 2005.11.06.

Elérhetőségek Kertész Tamás [email protected] Rieger Péter László [email protected] Szolyka Sándor [email protected] Vámossy Zoltán docens, intézetigazgató-helyettes http://ultra.obuda.kando.hu/~vamossy/ [email protected] TransMotion honlap http://transmotion.no-ip.org/


TRANSMOTION EMBERI MOZGÁS DIGITALIZÁLÁSA

Recommend Documents