NEUMANN JÁNOS INFORMATIKAI FŐISKOLAI KAR
SZAKDOLGOZAT
BMF-NIK 2006
SZOLYKA SÁNDOR NIK-O-NI-02-175
-3-
HALLGATÓI NYILATKOZAT
Alulírott szigorló hallgató kijelentem, hogy a szakdolgozat saját munkám eredménye. A felhasznált szakirodalmat és eszközöket azonosíthatóan közöltem. Egyéb jelentősebb segítséget nem vettem igénybe. Az elkészült szakdolgozatban talált eredményeket a főiskola, a feladatot kiíró intézmény saját céljaira térítés nélkül felhasználhatja.
Budapest, 2006..............................
............................................... hallgató aláírása
Szolyka Sándor
Digitally signed by Szolyka Sándor DN: CN = Szolyka Sándor, C = HU, O = TransMotion Reason: I am the author of this document Location: Budapest, Hungary Date: 2006.05.21 17:30:50 +02'00'
-4-
Tartalomjegyzék Tartalomjegyzék ............................................................................................................... 4 1. Bevezető.................................................................................................................... 7 1.1. A feladat ismertetése, témamegjelölés.............................................................. 7 2. Motion Capture ......................................................................................................... 8 2.1. Mi is az a "Motion Capture"? ........................................................................... 8 2.2. Gyakorlati felhasználási területek..................................................................... 9 2.3. Történelmi áttekintés ...................................................................................... 10 2.4. A markerek ..................................................................................................... 12 2.5. Milyen markereket használjunk? .................................................................... 13 2.6. A markerek használatának alapszabályai ....................................................... 13 2.7. Zajos kép, Ghost Pointok................................................................................ 14 2.8. Markerek felismerése, követése...................................................................... 15 3. Performance Animation.......................................................................................... 16 3.1. Bevezetés ........................................................................................................ 16 3.2. A csontvázmodell elkészítése ......................................................................... 16 3.2.1. A csontvázak........................................................................................... 16 3.2.2. Csuklópontok típusai (szabadsági fokoktól függően)............................. 18 3.2.3. Csukló-láncolatok (joint chains)............................................................. 18 3.2.4. Végtagok (limbs) .................................................................................... 18 3.2.5. Csontváz-hierarchia ................................................................................ 19 3.2.6. Forward / Inverse Kinematics................................................................. 19 3.3. A karaktermodell elkészítése .......................................................................... 20 3.3.1. Subdivision Surfaces............................................................................... 21 3.3.2. NURBS ................................................................................................... 21 3.3.3. Poligonális modell .................................................................................. 21 3.3.4. Clay objects............................................................................................. 22 3.3.5. Hibrid módszerek.................................................................................... 22 3.4. Kiegészítő elemek hozzáadása a jelenethez.................................................... 23 4. Hasonló rendszerek bemutatása, értékelése............................................................ 24 4.1. Vicon............................................................................................................... 24 4.2. A Brainfactor Entertainment VICON8-as rendszere ...................................... 26 4.3. Egy hallgatói projekt a Milánói Egyetemen ................................................... 26 4.4. A Pyros Pictures MotionAnalysis rendszere .................................................. 26 5. TransMotion............................................................................................................ 28 5.1. Rendszerterv ................................................................................................... 28 5.1.1. A rendszer felépítése............................................................................... 28 5.1.2. Fejlesztőeszközök ................................................................................... 30 5.2. Kamera-kalibráció .......................................................................................... 31 5.2.1. Kamera-modell ....................................................................................... 31 5.2.2. A kameráink............................................................................................ 32 5.2.3. Kamera-kalibráció – az elmélet .............................................................. 33 5.2.4. Kamera-kalibráció – a gyakorlat............................................................. 35 5.2.5. A belső paraméterek kiszámítása............................................................ 36 5.2.6. A kamerák torzításmentes képének kiszámítása..................................... 39 5.2.7. A külső paraméterek kiszámítása ........................................................... 41
-55.2.8. A kamerák elhelyezése ........................................................................... 42 5.2.9. Továbbfejlesztési lehetőségek ................................................................ 43 5.3. A kamerakezelő modul ................................................................................... 44 5.3.1. Mivel kezeljük a kamerákat? .................................................................. 44 5.3.2. Mi is az a DirectShow?........................................................................... 44 5.3.3. Hogyan működik a DirectShow?............................................................ 45 5.3.4. Hogyan használjuk a DirectShow-t videó-felvételre? ............................ 46 5.3.5. A Capture osztály.................................................................................... 47 5.3.6. A Capture osztály továbbfejlesztési lehetőségei..................................... 48 5.4. A képfeldolgozó modul .................................................................................. 49 5.4.1. A markerek adatstruktúrájának kialakítása............................................. 49 5.4.2. A marker osztály..................................................................................... 50 5.4.3. A CamMarker osztály............................................................................. 52 5.4.4. A MarkerDetection osztály..................................................................... 52 5.4.5. A findMarkers metódus .......................................................................... 53 5.4.6. A findMarkers metódus sebesség-optimalizációja ................................. 54 5.4.7. A markerkereső modul továbbfejlesztése ............................................... 55 5.5. A 3D-s koordináták kiszámítása ..................................................................... 57 5.5.1. Kezdeti nehézségek................................................................................. 57 5.5.2. Az egyenesek meghatározása ................................................................. 58 5.5.3. Az egyenesek feltételezett metszéspontja............................................... 61 5.5.4. A kamerák pozíciója a világ-koordinátarendszerben.............................. 62 5.5.5. Két kitérő egyenes feltételezett metszéspontja ....................................... 62 5.5.6. Vektor look-up table ............................................................................... 64 5.5.7. A gyakorlati megvalósítás ...................................................................... 65 5.6. A Maya szerver modul.................................................................................... 67 5.6.1. Maya Motion Capture API Library ........................................................ 68 5.6.2. A modul kialakítása ................................................................................ 69 5.6.3. A modul működése ................................................................................. 69 5.7. A főprogram.................................................................................................... 71 5.7.1. A főprogram feladata .............................................................................. 71 5.7.2. A főprogram elvi működése az adatút szempontjából............................ 72 5.7.3. A főprogram gyakorlati kialakítása ........................................................ 74 5.7.4. A párhuzamosítás bevezetése ................................................................. 75 5.7.5. A felhasználói felület kialakítása............................................................ 76 5.7.6. Továbbfejlesztési lehetőségek ................................................................ 78 5.8. A Performance Animation környezet konfigurálása ...................................... 78 5.8.1. A megjelenítő felület .............................................................................. 78 5.8.2. Konfiguráció MEL szkripttel.................................................................. 79 5.8.3. Motion Capture felvétel készítésének módja.......................................... 81 5.8.4. Továbbfejlesztési lehetőségek ................................................................ 82 5.9. A 3D-s környezet kialakítása.......................................................................... 83 5.9.1. A 3D-s karaktermodell............................................................................ 83 5.9.2. A 3D-s karakter csontvázának kialakítása .............................................. 84 5.9.3. A karakter anyagának kialakítása ........................................................... 85 5.10. Tesztelés, az eredmények értékelése .............................................................. 87 5.10.1. A markerek ............................................................................................. 87 5.10.2. A kamera-kalibráció ............................................................................... 88 5.10.3. Az első tesztkörnyezet ............................................................................ 89 5.10.4. A második tesztkörnyezet....................................................................... 91
-65.10.5. Teszteredmények .................................................................................... 94 5.10.6. Az eredmények értékelése ...................................................................... 95 5.11. Továbbfejlesztési lehetőségek ........................................................................ 95 5.12. Összefoglalás .................................................................................................. 96 5.13. Summary......................................................................................................... 96 5.14. Az elvégzett munka felosztása........................................................................ 97 5.15. A projekt honlapja .......................................................................................... 98 6. Irodalomjegyzék ..................................................................................................... 99 6.1. Felhasznált irodalom....................................................................................... 99 6.2. Ajánlott irodalom.......................................................................................... 101 7. Elérhetőségek........................................................................................................ 102
-7-
1. 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ós-idejű
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ó 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 Autodesk Maya termék és a hozzá készült kiegészítők. A szoftverfejlesztés elsősorban Microsoft Visual Studio .NET 2005 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ó.
-8-
2. Motion Capture 2.1.
Mi is az a "Motion Capture"? A Motion Capture (MoCap) 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.
1. ábra - Motion Capture stúdió [1]
-9Sok 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.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. ábra - Így készült a Gyűrűk Ura [2]
• 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,
animálására
amelyikben
nincs
szükség
valamilyen
karakter
- 10 -
3. ábra - Motion Capture felvétel [3]
• 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 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. [4]
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
rajzfilmfigurákra, így tették mozgásukat életszerűvé.
a
képkockákon
a
színészeket
- 11 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. 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. [5]
4. ábra - Markerek a csontvázszerkezeten [6]
- 12 -
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é
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
mivel minden marker egyedi, nem fognak összekeveredni, tehát megbízható
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
- 13 -
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
- 14 • 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) [7]
5. ábra - A markerek elhelyezése [8]
2.7.
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ására 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.
- 15 -
2.8.
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. [9]
6. ábra - Marker keresése szekvenciálisan
7. ábra - Marker keresése spirálisan
- 16 -
3. Performance Animation 3.1.
Bevezetés 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ő karakter-animáció, amit a szereplő irányít. A karakter-animá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 Autodesk Maya 7.0. [10] A 3D animációs iparban legszélesebb körben elterjedt szoftverek közül az Autodesk Maya, valamint az Autodesk 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.2.
A csontvázmodell elkészítése
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 (8. ábra).
- 17 -
8. ábra - Csontvázmodell [11]
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 (9. ábra).
9. ábra - Csuklók [11]
- 18 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 (10. á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.
10. ábra - Csukló-láncok [11]
3.2.4. Végtagok (limbs) Végtagokon csukló-láncok egy vagy több összekapcsolt csoportját értjük (11. á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 11. ábra - Végtagok [11]
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).
- 19 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. 3.2.6. Forward / Inverse Kinematics 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 - 12. á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é. [12]
12. ábra - Inverse Kinematics [11]
- 20 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.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 • egyéb hibrid módszerek 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.
- 21 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 (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 Subdivision surface hardvertámogatottsága felé irányul, ami meglehetősen izgalmas, új lehetőségekhez vezet.) [13] 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 (Beziersplines) 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ó (13. ábra). [13]
13. ábra - NURBS [11]
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. [13]
- 22 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. [14]
- 23 -
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.
14. ábra - A modell és környezete
- 24 -
4. Hasonló rendszerek bemutatása, értékelése 4.1.
Vicon A Motion Capture piac egyik legmeghatározóbb szereplője a Vicon. 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 [15]. Világelsőnek hirdetik MX40 típusjelzésű kamerájukat (15. á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.
15. ábra - A Vicon MX40 kamera [15]
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.
- 25 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). 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.
16. ábra - A Vicon MX rendszer felépítése [15]
- 26 -
4.2.
A Brainfactor Entertainment VICON8-as rendszere 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 a modell real-time megjelenítésére is képes, ezt nagy előnyeként említik, mi is ilyen képességgel rendelkező rendszert szeretnénk megvalósítani. [3]
4.3.
Egy hallgatói projekt a Milánói Egyetemen 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ásával
lehetne
segíteni.
A mienkhez hasonlóan ez is egy hallgatói projekt. [16]
4.4.
A Pyros Pictures MotionAnalysis rendszere A Pyros Pictures egy 14 kamerás - az amerikai MotionAnalysis cégtől vásárolt -
rendszert használ optikai Motion Capture felvételek készítésére. Honlapjukon 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
- 27 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]
- 28 -
5. TransMotion 5.1.
Rendszerterv
5.1.1. A rendszer felépítése Egy teljes optikai Motion Capture rendszer igen összetett, ezért már a kezdetektől fogva részekre osztott megvalósítást képzeltünk el. Mivel a mozgás rögzítése illetve megjelenítése két jól elkülöníthető feladat, logikusnak tűnt a kettő határán szétválasztani a rendszert. A felosztás azonban nem csak logikai alapon történt, hiszen - a két feladat számításigényére való tekintettel - a végrehajtást két külön számítógépre bíztuk, szerver-kliens kapcsolattal. A Motion Capture illetve a Performance Animation feladatok önmagukban is annyira összetettek, hogy ésszerű további részekre bontani őket. A moduláris felépítés remekül illeszkedik 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 szerver feladata tehát a mozgás rögzítése, a Motion Capture felvétel elkészítése, a folyamatot további öt modulra bontottuk: • A moduláris felépítésből következően először is létre kell hoznunk egy főprogramot, ami az egyes modulok összehangolásáért felelős. A funkciók egyesítése mellett a felhasználóval való kapcsolatteremtés, tehát a felhasználói felület kialakítása is e modul feladata. • Mivel kamerákkal szeretnénk dolgozni, szükségünk van ezek kalibrációjára. A kalibrációs modul szerepe a kamerák külső és belső paramétereinek meghatározása, illetve ide tartozik még a kamerák megfelelő elhelyezése. • Ha végeztünk a kalibrációval, szükségünk van a kamerák képének kinyerésére. A kamerakezelő modul tehát a feldolgozáshoz szükséges képek előállításáért felelős.
- 29 • A kapott képen meg kell keresnünk a markerek pozícióját, hogy a későbbiekben
számolhassunk
vele.
A
markerkereső
modul
feldolgozza a kamerák képét, majd meghatározza rajtuk az egyes markerek helyét. • Ha már rendelkezünk a markerek 2D-s pozíciójával, ebből valahogyan térbeli információt kell kinyernünk. A 3D-s koordináták kiszámítását végző modul tehát előállítja a másik gép felé továbbítandó adatokat. A szerver és a kliens közötti kommunikáció hálózaton keresztül történik. A két rendszert összekapcsoló modul létrehozza a kapcsolatot, meghatározza a továbbított adatok formáját és sorrendjét, majd szükség esetén lebontja az összeköttetést.
17. ábra - A rendszer felépítése
- 30 A kliens feladata a 3D-s karaktermodell megjelenítése és a kapott adatok alapján történő animálása. A Performance Animation részt két részre osztottuk: • A mozgás megjelenítéséhez szükség van számos beállítás elvégzésére. A Performance Animation környezet konfigurálása a kapott adatok és a karaktermodell összehangolását, és utóbbi mozgatásának előkészítését jelenti. • Ha mindezzel kész vagyunk, kezdődhet az utolsó lépés, a karakteranimáció. A következő modul feladata tehát a 3D-s megjelenítés, amihez létre kell hozni a 3D-s modellt és környezetét is. 5.1.2. Fejlesztőeszközök Fejlesztőkörnyezetként a Microsoft Visual Studio .NET 2005-öt választottuk, ami a .NET keretrendszer alkalmazására épül (.NET Framework 2.0). 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. 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# nyelven készül, beépülő moduljai egyéb programnyelveken í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 is szolgálhat. Szót kell ejtenünk még az Intel által fejlesztett, nyílt forráskódú OpenCV libraryről is, hiszen a továbbiakban ezt is használni szeretnénk. Az OpenCV a képfeldolgozáshoz és gépi látáshoz kapcsolódó feladatok rendkívül hatékony megoldására
készült
rutinokat
tartalmazó
függvény-könyvtár.
A
kód
Intel
processzorokra lett optimalizálva, de természetesen egyéb x86-os processzorokon is elfut. A rutinokat C és C++ nyelven írták; kezdetben az Intel mérnökei, majd később egy lelkes programozó csapat folytatta a munkát. Fejlesztése napjainkban is tart, jelenlegi legújabb verziója (beta 5) 2005 júliusában jelent meg. [17][18][19]
- 31 -
5.2.
Kamera-kalibráció
5.2.1. Kamera-modell Ha kamerákkal szeretnénk dolgozni, fontos hogy megismerkedjünk a kamerák képalkotási módszereivel, illetve magával a kamera fogalmával. A kamera olyan zárt doboz, ami rendelkezik egy nyílással (apertúra), melyen keresztül a fény beáramlik, illetve egy felülettel, ami képes a képet rögzíteni, digitális kamera esetén a fénysugarakat elektromos jelekké alakítani. A kamerák kétdimenziós képe a háromdimenziós világ képének leképzése egy síkba, amit képsíknak nevezünk [20]. Ennek a leképzésnek a matematikai leírására a kamera-modell szolgál, ilyen például az úgynevezett pinhole-kamera (18. ábra). Pinhole-kamera esetében az apertúrát ponttá zsugorítjuk, tehát a kamerába érkező fénysugarak mind ezen a ponton haladnak keresztül, ami gyújtópontként is ismert. A kamera belsejében a képsíkon így fordított állású képet kapunk. Azt a pontot, ahol a beérkező fénysugár merőleges a képsíkra, optikai középpontnak nevezzük. Az optikai középpont (és így a képsík) távolsága a gyújtóponttól a fókusztávolság. A pinhole-kamerák a képet perspektív projekcióval képezik le a képsíkra. Ennek következménye, hogy a távolabbi objektumok kisebbnek látszanak, illetve a párhuzamos egyenesek (a képen vagy a végtelenben) találkoznak.
18. ábra - Pinhole-kamera
- 32 5.2.2. A kameráink A fejlesztéshez szükségünk volt kamerákra, mivel csak ezek segítségével tudtunk kísérletezni, tesztelni, illetve használni az elkészült rendszert. Szerencsére rendelkeztünk néhány webkamerával, amik az említett célokra kezdetben tökéletesen megfeleltek,
de
professzionális
alkalmazásra
természetesen komolyabb eszközökre van szükség. A fejlesztés teljes ideje alatt három darab Logitech QuickCam Zoom (19. ábra) típusú készüléket használtunk,
melyeket
konzulensünk
bocsátott
19. ábra - Logitech QuickCam Zoom [21]
rendelkezésünkre, ezúton is köszönjük. 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áltuk 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), a kamerák másodpercenként 30 különböző kép felvételére képesek. A számítógéphez való csatlakozás USB-porton keresztül történik. Később, a tesztelés idején további három kamerára tettünk szert; ezek Logitech QuickCam Pro 5000 (20. ábra) típusúak, a webkamerák mezőnyében felsőkategóriás eszközöknek számítanak. Technikai paramétereik megegyeznek az előző típussal, látszólag csak külső felépítésükben térnek el: tetszőlegesen állítható talpakat kaptak, amik sokkal könnyebb elhelyezhetőséget biztosítanak. Azonban már az első bekapcsoláskor észrevettük, hogy lényegesen jobb minőségű képet adnak, mint az eddigi kameráink. Ugyanakkora felbontáson a kép sokkal élesebb, a színhűsége nagyságrendekkel jobb; az eddigi fakó 20. ábra - Logitech QuickCam Pro 5000 [21]
képek helyett szép élénk színeket láttunk.
- 33 Három kamera együttes használatával akadályba ütköztünk. Először a GraphEdit nevű programban próbáltuk megjeleníteni a képüket, ami két kamerával tökéletesen működött is, de három kamera esetében különféle hibajelenségeket és hibaüzeneteket tapasztaltunk. Ezután kipróbáltuk másik számítógépen is, ahol tökéletesen működött egyszerre a három kamera. Idővel rájöttünk a probléma okára: az első gép alaplapja csak két ’USB gyökérhub-ot’ (USB Root Hub, 21. ábra) képes kezelni, míg a másiké négyet. Ebből azt a következtetést vontuk le, hogy mindegyik kamera lefoglal egy teljes USB gyökérhub-ot.
21. ábra - USB gyökérhub-ok a rendszerben
Mivel mégis az első gépet szerettük volna tesztgépnek használni, ezért beszereztünk egy négyportos PCI-os USB-vezérlőt, aminek segítségével már a tesztgép is képessé vált a három kamera szimultán kezelésére. Mindenesetre meglepőnek tartjuk, hogy a modern, 64 bites AMD Athlon 64 processzorokat kiszolgáló nVidia nForce 4 Ultra chipset csak két USB gyökérhub-bal rendelkezik, míg az egy generációval régebbi, AMD Athlon XP processzorokhoz tervezett, költséghatékony rendszerek alapjául szolgáló SiS 748 chipset néggyel is megbirkózik. 5.2.3. Kamera-kalibráció – az elmélet A kamerák képalkotása nem tökéletes, ám a hibák számokban kifejezhetők. A fizikai paramétereik kamera-kalibráció segítségével határozhatók meg. A kalibráció során kapott adatokat kétfelé lehet osztani: belső paraméterek (Intrinsic parameters) és külső paraméterek (Extrinsic parameters).
- 34 A belső paraméterek határozzák meg a kamera fizikai jellemzőit, amik az adott kamerára mindig azonosak, függetlenül attól, hogy a kamera hol helyezkedik el. A belső paraméterek a fókusztávolság, a pixel-dőlésszög, az optikai középpont helye illetve a torzítási együtthatók. A kamerák képén különböző mértékű torzítások jelentkezhetnek. Ez azt eredményezheti, hogy például két, a képsíkon elméletileg párhuzamos vonal a képen görbe vonalként jelenik meg, ezt a jelenséget radiális torzításnak nevezzük. Ezenkívül jelentős lehet még a tangenciális torzítás hatása is, ami gyártási hibák miatt keletkezik. Mivel a kamerák képéből kinyert információk alapján szeretnénk 3D-s pozíciókat számítani, rendkívül fontos, hogy a kamerák pontos képet adjanak. A kamerák torzított képéből az eredetit kamera-kalibráció segítségével állíthatjuk vissza (22. ábra). [22]
22. ábra - Torzított és javított kép [22]
A külső paraméterek a kamera és a körülötte lévő világ viszonyára adnak számszerű értékeket, amik csak a kamera adott helyzetében igazak, a kamerát elmozgatva már újra ki kell számítani ezeket. A kamera külső paraméterei 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. E 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.
- 35 Gyakran használnak mintaként két egymásra merőleges, eltérő hosszúságú vonalat, amik mérete ismert (23. ábra). Ennek az L-betűnek a szárai a 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ározzák meg a külső paramétereket.
23. ábra - Kalibrációs minta [8]
5.2.4. Kamera-kalibráció – a gyakorlat A kamerák kalibrációja annyira komplex feladat, hogy önmagában is lehetne egy szakdolgozat témája, ezért mi létező megoldások után néztünk, amiket felhasználhatnák céljainkra. Az interneten számos kész program létezik erre a feladatra, ám nagyrészük kereskedelmi szoftver, mi pedig ingyenes megoldást kerestünk. Természetesen ilyenre is található példa, ezek közül talán a legelterjedtebb a ’CalibFilter’ illetve a ’Camera Calibration Toolbox’ [23]. Mindkettőt ugyanazok készítették (kilétükre honlapjukon nem sikerült fényt deríteni), így a két megoldás nagyon hasonló egymáshoz, csak a megvalósítás eszköze különbözik. A CalibFilter a nyílt forráskódú Intel OpenCV részeként használja fel annak kalibrációs rutinjait. Mint a neve is mutatja, ún. szűrőként működik, a Microsoft DirectShow-ba beépülve használható. A Camera Calibration Toolbox a Matlab szoftverkörnyezetére épül, némileg különböző megközelítésből nyújtja ugyanazt a funkcionalitást. Tekintve, hogy minden érdeme ellenére a Matlab egy különálló, terjedelmes és igen költséges alkalmazás, szemben az ingyenes, nyílt forráskódú OpenCV-vel, aminek használatát egyébként is terveztük, utóbbi tűnt jobb választásnak, így a továbbiakban ennek használatára támaszkodtunk.
- 36 Sajnálatunkra azonban a CalibFilter csak a kamerák belső paramétereinek kiszámítására képes, a külső paraméterekkel kapcsolatos számítások elvégzésére pedig nem találtunk kész megoldást, így ezt magunknak kellett elvégezni. Szerencsére az OpenCV egyes függvényeit ebben az esetben is segítségül hívhattuk, ám a konkrét megvalósítás a mi feladatunk volt. 5.2.5. A belső paraméterek kiszámítása A
kameráink
belső
paramétereinek
kiszámítását
a
GraphEdit
nevű
segédprogrammal valósítottuk meg (24. ábra), ami alapvetően a Microsoft DirectShow szűrőinek kipróbálására való. Segítségével egy könnyen átlátható grafikus felületen elhelyezhetünk különféle kép- vagy videó-forrásokat és szűrőket, majd ezek összekapcsolásával tesztelhetjük együttes működésüket, hogy a későbbiekben egy biztosan működő megoldást implementálhassunk, ha saját kódból szeretnénk használni a filtereket.
24. ábra - Filterek használata a GraphEdit-ben
A program saját szűrői mellett 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. Ez a szűrő az OpenCV kalibrációs függvényeinek használatára épül, így perspektív leképzésű pinholekameramodellt használ. A GraphEdit-ben a videó-forrás és a megjelenítés közé kell helyezni, ezután jobb egérgombbal előhívható a konfigurációs ablak (25. ábra).
- 37 -
25. ábra - A CalibFilter konfigurálása
A kalibrációhoz sakktábla-szerű mintát használ (26. ábra), ennek mérete tetszőlegesen állítható: egyrészt a sorok és oszlopok száma, másrészt az egyes négyzetek oldalhosszúsága cm-ben. Ezután következik a gyűjtendő képkockák száma, ahol minél többet állítunk be, annál pontosabban tud számolni. Majd ha beállítottuk az egyes képkockák rögzítése között eltelt időt, kezdődhet a kalibráció. A program a fekete és fehér négyzetek csúcsainak találkozási pontjait keresi, illetve az ezek által alkotott, meghatározott méretű mintát. A minta sikeres felismerését színes vonalak jelzik (27. ábra).
26. ábra - Kalibrációs minta
27. ábra - Felismert minta
- 38 Először is szükségünk volt tehát egy a kamera által jól felismerhető mintára. Jó minőségű nyomtatóval készítettünk egy egyenként három cm-es oldalhosszúságú négyzetekből álló, kilenc oszlopos és hét soros mintát, majd ezeket az értékeket beállítottuk a programban. A Start megnyomása után a program elkezdte keresni a képen a mintát. Amikor megtalálta, rögzítette a képet, majd a beállított négy másodperc után ismét addig vizsgálta a kamera képét, amíg meg nem találta rajta a mintát. Húsz kép begyűjtése után kiszámolta a kamera belső paramétereit, majd egy txt fájlba elmentette az adatokat (2. és 3. táblázat). A lementett adatok a következők: kamera-mátrix, torzítás-vektor. A kameramátrix tartalma: a fókusztávolság értéke vízszintes és függőleges pixel-méretben kifejezve (tehát a fókusztávolság cm-es értéke elosztva a pixel cm-es méretével), az optikai középpont helye a képen és a pixel vízszintes és függőleges oldala által bezárt szög (a jelenlegi verzió ezt az értéket ideálisnak tekinti, ezért nem számítja ki, mindig nullát ad értékül). A torzítás-vektor tartalma: a radiális torzítás illetve a tangenciális torzítás együtthatói. Ezután megtekinthettük a valós, torzítás nélküli képet, ami esetünkben csak minimálisan tért el a kamerák eredeti képétől. Felmerült, hogy talán nincs is szükségünk a torzítás kiküszöbölésére, mert kameráink torzítása nem jelentős, 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 hagyhattuk ki ezt a lépést.
paraméter
1. kamera
2. kamera
3. kamera
fókusztávolság (fc)
[410,7; 412,7]
[411,1; 411,7]
[408,6; 410,1]
optikai középpont (cc)
[166,1; 105,1]
[158,4; 111,5]
[167,1; 98,7]
0
0
0
radiális torzítás (k1)
- 0,038192
- 0,090304
- 0,008231
radiális torzítás (k2)
0,181668
0,268627
- 0,039288
tangenciális torzítás (p1)
- 0,002969
- 0,002003
- 0,002138
tangenciális torzítás (p2)
- 0,001587
- 0,002035
- 0,001269
pixel-dőlésszög (s)
2. táblázat - A Logitech QuickCam Zoom kamerák belső paraméterei
- 39 paraméter
1. kamera
2. kamera
3. kamera
[347,1; 347,0]
[345,3; 348,0]
[344,7; 344,8]
[152,8; 97,6]
[149,4; 95,3]
[168,6; 105,6]
0
0
0
radiális torzítás (k1)
- 0,005288
0,032659
0,002134
radiális torzítás (k2)
0,062099
- 0,039119
0,007669
tangenciális torzítás (p1)
- 0,013426
- 0,026763
- 0,019310
tangenciális torzítás (p2)
- 0,007577
- 0,004410
- 0,000666
fókusztávolság (fc) optikai középpont (cc) pixel-dőlésszög (s)
3. táblázat - A Logitech QuickCam Pro 5000 kamerák belső paraméterei
5.2.6. A kamerák torzításmentes képének kiszámítása A kamera torzításának korrigálására az OpenCV kínál megoldást, de sajnos ezt nem használhattuk fel, mert nekünk csak a megtalált markerek pozíciójának torzításmentes ismeretére van szükségünk, az egész kép visszaállítása felesleges lenne és nagymértékben lassítaná a feldolgozást, hiszen másodpercenként 20-30 képkocka összes pixelére kellene végezni számításokat, ami egy időkritikus alkalmazásnál megengedhetetlen. Tehát meg kellett írnunk az erre vonatkozó kódot is, amihez szükséges volt a torzítás működésének megismerésére [24]. A továbbiakban használt jelölések (a 2. és 3. táblázatban szereplőkhöz hasonlóan): fc a fókusztávolság (mivel két értéke van, vektorként használjuk), cc az optikai középpont (szintén vektorként), s a pixel-dőlésszög, k1 és k2 a radiális torzítás együtthatói, p1 és p2 pedig a tangenciális torzítás együtthatói. Induljunk ki az eredeti, torzítatlan képből. Legyen P (Xc, Yc, Zc) egy képpont pozíciója a kamerakoordinátarendszerben. Vetítsük ezt a pontot a képsíkra a belső paraméterek alapján, ennek pozíciója legyen xn (x, y).
⎡ X / Z ⎤ ⎡ x⎤ xn = ⎢ c c ⎥ = ⎢ ⎥ ⎣ Yc / Z c ⎦ ⎣ y ⎦
- 40 Vezessük be az r2 = x2 + y2 jelölést. A P pont torzított pozícióját xd adja meg:
⎡ x (1) ⎤ x d = ⎢ d ⎥ = 1 + k1 ∗ r 2 + k 2 ∗ r 4 ∗ x n + dx ⎣ x d (2)⎦
(
)
ahol dx a tangenciális torzítás vektor:
( (
) )
⎡ 2 ∗ p1 ∗ x ∗ y + p 2 ∗ r 2 + 2 ∗ x 2 ⎤ dx = ⎢ 2 2 ⎥ ⎣2 ∗ p 2 ∗ x ∗ y + p1 ∗ r + 2 ∗ y ⎦ A P pont torzított képének pixel-koordinátáit Ppixel (xp, yp) adja meg. A képsík és a pixel-koordinátarendszer közötti kapcsolat a következőképpen alakul:
⎡xp ⎤ ⎢y ⎥ = M ⎢ p⎥ ⎢⎣ 1 ⎥⎦
⎡ x d (1) ⎤ ∗ ⎢⎢ x d (2)⎥⎥ ⎢⎣ 1 ⎥⎦
ahol M a kamera-mátrix:
⎡ fc(1) M = ⎢⎢ 0 ⎢⎣ 0
s cc(1) ⎤ fc(2) cc(2)⎥⎥ 0 1 ⎥⎦
Egyszerűsítve a következő egyenleteket kapjuk: x p = fc (1) ∗ x d (1) + s ∗ x d ( 2) + cc (1) y p = fc ( 2) ∗ x d ( 2) + cc ( 2)
Ez az általános modell felhasználja az s értékét is, azaz működik nem téglalapalakú pixelekre is, bár a CalibFilter jelenlegi verziója ezt nem számítja ki – a fejlesztők ígérete szerint a jövőbeli verziók erre is képesek lesznek. A fenti összefüggéseket felhasználó kódrészlet a 3D-s pozíciót számoló modulban került implementálásra.
- 41 5.2.7. A külső paraméterek kiszámítása
A külső paramétereket kiszámító CameraCalibration program egy konzolalkalmazás, ami a rendszer többi részéhez hasonlóan Visual Studio 2005-ben íródott, ám azokkal ellentétben C++ nyelven, ráadásul nem menedzselt kódban. Erre azért volt szükség, mert a kalibrációhoz az OpenCV függvényeit használtuk, az OpenCV pedig nem kompatibilis a C# kóddal, de még a menedzselt C++ kóddal sem. Ezért sajnos le kellett mondanunk a C# nyújtotta előnyökről, sőt a kalibrációs program és a főprogram közti kommunikációt is csak közvetetten tudtuk megoldani. A program működése röviden a következő: • miután elhelyeztük a kamerákat, a főprogramból elindítjuk a kalibrációt, egymás után az összes kamerára 1. a főprogram az inkompatibilitás miatt nem közvetlenül, függvényhívással indítja el a programot, hanem a lefordított CameraCalibration.exe fájlt futtatja a megfelelő paraméterekkel, amiket a program main függvénye fogad • a program egy ablakban megjeleníti a kívánt kamera képét 2. ha a főprogram a rendszerben lévő valamelyik kamera azonosítóját adta át paraméterként (0, 1, …, n), akkor ennek a képét 3. ha a főprogram által azonosítóként átadott szám -1, akkor pedig megjelenít egy kameraválasztó menüt • minden egyes képkockára meghív egy rutint, ami 4. megpróbálja megkeresni a mintát a képen 5. a megtalált pontok pozícióját kiszámolja szubpixeles pontossággal 6. kirajzolja a képre a mintát, illetve ha nem sikerült megtalálni, akkor csak a megtalált pontokat – ebből lehet következtetni arra, hogy miért nem volt sikeres a mintafelismerés 7. másolatot készít a képről a későbbi lementés céljára • ha a mintakeresés sikeres volt, a felhasználó bezárja az ablakot • ekkor az utoljára megjelenített kép másolata feldolgozásra kerül
- 42 8. az adott kamera belső paraméterei betöltődnek a megfelelő változókba 9. a program kiszámítja a külső paramétereket 10. átszámolja a kapott rotációs vektort rotációs mátrixszá, mert a továbbiakban ezzel fogunk dolgozni 11. az összes kalibrációs paramétert lementi egy a főprogram által megadott nevű fájlba • a feldolgozott képet lementi a szintén a főprogram által megadott nevű fájlba • a főprogram számára visszatérési értékként megadja, hogy sikerült-e megtalálni a mintát a képen, ami ettől függően működik tovább. 5.2.8. 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 kellett elhelyeznünk megfelelően. A legjobb megoldásnak az látszott, ha a színész körül egy szabályos háromszöget képezünk belőlük, így a lehető legegyenletesebben oszlanak el az eseménytér körül (28. ábra).
- 43 -
28. ábra - A kamerák elhelyezése
5.2.9. Továbbfejlesztési lehetőségek
A kamera-kalibrációs modul jelenleg a célnak teljesen megfelel, ellátja a kívánt funkciókat. Felmerült azonban, hogy a belső kalibrációt saját kódból, a CalibFilter használatának mellőzésével kellene végrehajtani. Gyakorlatilag ekkor is ugyanazt az OpenCV-s kódot használnánk, de így nem lenne szükségünk külön programra (GraphEdit), ami tovább egyszerűsítené a program használatát. Ennek megvalósítása nem igényel sok munkát. A pontosság növelésének érdekében, illetve a 64 bites processzorok elterjedése miatt, célszerű lenne a modult átalakítani 64 bites üzemmódra. Az OpenCV változóinak és függvényeinek többnyire létezik 64 bites pontosságú változata is, tehát ez nem jelent problémát. Szintén a pontosság növelésére adna lehetőséget a 320*240-es felbontás helyett a 640*480-as felbontás használata. Ez is könnyedén megvalósítható, ám egyúttal egy jelentős hátránnyal is járna: amilyen felbontásban végezzük a kalibrációt, olyan felbontásban kell használnunk a kamerákat a későbbiekben is, viszont ez a kamerakezelő és a markerkereső modul számára jelentős (gyakorlatilag négyszeres) többletterhelést róna. Ez a fejlesztés ezért egyelőre csak távlati terveinkben szerepel. A modult célszerű lenne integrálni a főprogramba, hogy ne külső programból kelljen futtatni. Mivel az OpenCV kamerakezelését sehogy nem tudjuk C#-ból használni,
a
kalibrációs
programból
függvényhívással futtatható lenne.
DLL-t
szeretnénk
készíteni,
így
egy
- 44 A mintafelismerést ki lehetne egészíteni egy olyan kóddal, ami felismerné azt is, hogy a mintát melyik oldaláról látjuk. Ezzel kiküszöbölhető lenne az a probléma, hogy a kamerák helyzetét különböző origókhoz képest kapjuk meg. Ezt a minta egyik sarkába helyezett jelölés segítségével oldhatjuk meg, ám implementálása már nem triviális feladat.
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é kerültünk. 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. Általunk eleve ismert képfeldolgozó rendszerekkel szemben (mint pl. az Intel OpenCV, vagy a Matlab) a kiterjedt multimédiás funkciókkal bíró Microsoft DirectShow lehetőségeit találtuk előnyösebbnek. 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 DirectShowLib, azaz a DirectShow .NET-es kiterjesztése lehetővé teszi számunkra a C# környezet alkalmazását • későbbi fejlesztéseinket a DirectShow rugalmas videófolyam-gráfja nagymértékben támogatja 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ás, mind pedig rögzítés céljából. 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.
- 45 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. [25] 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. A gráfban elágazások is lehetnek, így pl. megoldható az eredeti kép és a szűrt kép egyidejű megjelenítése és fájlba írása. Sőt, ha a rendszerre installált szűrők képességei nem elégítenék ki a feldolgozáshoz szükséges igényeinket, lehetőségünk adódik saját szűrő implementálására is.
29. ábra - A DirectShow architektúra [25]
- 46 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ás-igényű Video Renderer szűrővel, ekkor az egy-kimenetű SampleGrabber filtert ’Smart Tee’-re kell cserélnünk az elágazás megvalósításához. 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. 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.
30. ábra - Capture Graph Sample Grabber-rel
31. ábra - Capture Graph Smart Tee és Video Renderer filterrel
- 47 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. A capture 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, mellyel létrehozza a Capture Graph-et. •
ebben
SetupGraph:
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 capturefolyamat elindítására. • Start: ezzel indíthatjuk el a capturefolyamatot.
A
gráf
MediaControl
32. ábra - A Capture osztály
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.
- 48 5.3.6. A Capture osztály továbbfejlesztési lehetőségei
A jelenlegi osztály két szűrőt tartalmaz, melyek csupán a capture folyamatot végzik. A gráfot ki lehet egészíteni úgy, hogy a megjelenítésen kívül még extra szűréseket is megvalósítson a videó-folyamon:
• Processzor-erőforrást spórolunk meg azzal, ha a videót nem képenként kirajzolva jelenítjük meg, hanem a ’Video Renderer’ szűrőt alkalmazzuk. Ezzel az eljárással a kamerából érkező videó-folyamot minden köztes várakoztatás nélkül a képernyőre vetíthetjük. • Ahhoz,
hogy
a
képfeldolgozás
a
stream-es
megjelenítéssel
párhuzamosan fusson, a gráfban egy elágazást kell létrehozni, a ’Smart Tee’ szűrő segítségével.
• Elvileg a kamera torzítását kompenzáló kódrész is ide kerülhetne, ám fontos itt felismerni, hogy a markerkereséshez nincs szükség az egész kép kisimítására; csupán a megtalált pontokra kell meghívni a korrekciót. • A
markerkeresést
nagymértékben
segítjük,
ha
zajszűrést
is
alkalmazunk; erre jó a Gauss filter, melyet alkalmazva jelentősen csillapíthatjuk a megtalált markerpontok statikus zaj okozta remegését. • Tulajdonképpen a komplett markerdetektálást is megvalósíthatjuk filterként a gráfban, ezt a meglévő osztály filter-interfészes
kiegészítésével érhetjük el.
- 49 -
5.4.
A képfeldolgozó modul A markerek kameraképen való pozícióinak meghatározásáért a markerDetection
nevű modul felelős. Ez a modul egyetlen MarkerDetection osztályból áll, 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 pointerben
tárolódik, a hivatkozott kép formátuma pedig a bmpData tagváltozóban. Ezá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. A findMarkers metódus ezen beállított paraméterek alapján számítja 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: a marker neve, színének középértéke, minimum és maximum küszöbe csatornánként, valamint a markereknek megfelelő pixelek száma, ezen pixelkoordináták összege, és a visszatérő X, Y markerpozíció. 5.4.1. A markerek adatstruktúrájának kialakítása
A fejlesztés során kialakult egy összetett, hierarchikus marker-adatstruktúra, amit a menet közben felmerült elvárások alapján kellett megtervezni. Ezek az elvárások a következők voltak: • olyan marker-osztály definíciót kellett létrehozni, mely tetszőleges számú marker színbeállítást kezel
• a marker-osztály rendelkezzen azonosítónévvel (a szerver-kliens oldali egyértelmű megfeleltetéshez), alsó/felső szín-küszöbbel, visszatérő 2D marker-koordinátával,
markerdefiníció
hozzáadás/törlés
funkciókkal
• a későbbiekben fontosnak találtuk, hogy a markerek színdefiníciói kameránként eltérőek is lehessenek (a gyakorlatban a kamerák
színképei jelentős eltérést mutatnak), ezért a markerdefiníciókat
- 50 hierarchikusan kamera-osztályba ágyaztuk (így lehetőség nyílik tetszőleges számú kamera tetszőleges számú markerbeállításaira is) • a legfelső (MarkerDetection) osztály tartalmazza a markerkereső metódust, mely az összes alatta lévő osztály markerbeállításai alapján
visszatér a pontok 2D-s pozíciójával • továbbá a kész adatstruktúra biztosítson lehetőséget a fájlba mentésre; ezáltal egyszerű lehetőség nyílik a marker-beállítások megőrzésére, többféle marker-definíció menedzselésére
33. ábra - A MarkerDetection osztály hierarchikus felépítése
5.4.2. A marker osztály
A felsorolt elvárások a 33. ábra által szemléltetett hierachikus osztálydefinícióhoz vezettek, amit egymásba ágyazott osztályokkal (ún. nested-class módon) alakítottunk ki. Először a legalsó szinten lévő marker osztály készült el, amely tartalmazza az összes markerdetektáláshoz szükséges adatot, valamint a visszatérő X, Y koordinátákat. Az osztályból így annyi objektumpéldány hozható létre, ahány markerre a Motion Capture-höz szükségünk van. Az adattagokról a 34. ábra ad áttekintést.
- 51 • name: ez egy string típusú mező; a marker nevét
tartalmazza,
amit
a
főablak
markerlistájától kap • thresholdMin: összetett típus, ami egy 3bájtos
(markerThreshold
nevű)
RGB
struktúrából áll; ez felel meg a marker (még megengedett) legsötétebb színének • thresholdMax: markerThreshold struktúra; ez felel meg a marker legvilágosabb színének • middleColor:
ez
markerThreshold legsötétebb
struktúra;
és
középértéke,
szintén a
legvilágosabb amit
egy marker színének
szín-mintavételnél
alkalmazunk • N: integer típus, az adott markerszínnek megfelelő
pixelek
számát
tárolja
-
a
markertalálat sikerességéről is tájékoztatást ad; értékét a findMarkers metódus határozza meg • wx, wy: a makernek minősített pixelek x és y koordinátáinak összegét tárolja, amiből a findMarkers metódus az N adattaggal osztva súlypontot számít • X, Y: a findMarkers metódus fő eredménye, ami a marker képsíkon lévő pozícióját adja; ha a marker nem található, értéke -1; -1 • a marker osztály csupán két metódussal rendelkezik: ezek a konstruktor (az értékek inicializálására), valamint a dispose.
34. ábra - A MarkerDetection osztály
- 52 5.4.3. A CamMarker osztály
A következő elváráshoz, hogy a markerdefiníciók kameránként különbözőek is lehessenek, a marker osztályt egy kameraosztályba ágyaztuk (CamMarker), így ebből annyi objektum példányosítható, ahány kamerát használni szeretnénk a Motion Capture felvételhez. Az osztály egyetlen adattagját a fent ismertetett marker osztály adja; metódusai pedig
• az új kamera hozzáadására (add), • törlésére (delete), • kameránkénti markerszám módosítására (setMarkerCount), • valamint az osztály konstruktorára vonatkoznak. 5.4.4. A MarkerDetection osztály
Ez a legfelső szinten lévő osztály a hierarchiában, közvetlenül ebből érhető el a markerek 2D-s pozícióit kiszámító metódus. Az elvárásoknak megfelelően az összes
osztályon belül lévő, kameránként különböző módon definiált markert detektálja az adott kamerához tartozó képen. Erről a szintről érhető el továbbá az új CamMarker-t hozzáadó metódus, illetve azok, amelyekkel minden kamerához együttesen adhatunk / törölhetünk markereket (addMarkerForAllCams, deleteMarkerForAllCams), ill. beállíthatjuk azok számát (setMarkerCountForAllCams).
Már csak egy további kikötés maradt, mégpedig az, hogy ezen osztályon belül lévő összes beállított paramétert el is tudjuk menteni. Nos, ez innentől egyszerűen megoldható a jól szervezett kialakításnak köszönhetően, valamint a .NET adta lehetőségnek, hogy egy objektum állapotterét ’sorosítás’ (Serialization) után streamként fájlba írhatjuk. Ehhez minden osztályra meg kell adnunk a [Serializable] attribútumot, ily módon jelölve, mely adatok vehetők bele a sorosításba. Itt fontos megjegyeznünk, hogy előfordulhat olyan eset is, mikor egy alosztályt nem tudunk sorosítani. Ilyen pl. a BitmapData típus - ebben az esetben használjuk a [NonSerializable] attribútumot, amely mentesíti az alosztályt a sorosítás alól. Lényeges, hogy az egész markerDetection objektum mentését nem magával az osztállyal végezzük, hanem ezt a főprogramból tesszük meg.
- 53 5.4.5. A findMarkers metódus
A findMarkers metódus felelős a markerek megtalálásáért. Bemeneti adatai a vizsgálandó kép (bmpData), és a markerek színküszöb értékei (thresholdMin, thresholdMax); végeredményként pedig a markerek 2D-s pozícióját (X, Y) adja vissza. Több kamerás rendszer révén egy további paraméterre is szükség van; ez az aktuális kamera indexe (camIndex), amely megmondja, a több kamerakép közül éppen melyiken dolgozzon a metódus. A feldolgozás az egész képre értelmezett sorfolytonos pixelvizsgálattal történik, melynek során minden pixelről megállapítjuk, hogy az beletartozik-e a definiált markerek valamelyikébe: • a szkennelés egy kettős for-ciklussal történik, x és y képtengely irányában. • először meghatározzuk a kép kezdőcímét (ezt egy byte típusú pointerben tároljuk), amit a ciklusok belsejében (a 3-bájtos RGB színértékek alapján) hármas eltolással léptetünk. • az aktuálisan következő bájt-hármasokra a marker-küszöbértékek szerint egy összetett feltételt vizsgálunk, mégpedig annyiszor, ahány markerünk van, illetve kevesebbszer, ha már bebizonyosodott, hogy az adott pixel megfelel egy markerdefiníciónak. • a feltétel teljesülése esetén növeljük az adott markernek megfelelő pixelszámot (N-et), valamint a súlypontszámításhoz szükséges wx, wy értékeket az aktuális pozícióval. A főablakban aktiválható egy extra funkció, mellyel a nem markernek minősített pixeleket eltüntethetjük a beállítások könnyebbé tétele érdekében. Ez a funkció egy plusz feltételvizsgálattal az aktuális pixel színét feketére állítja. A kép szkennelését követően a súlypontszámításról egy plusz kódrész gondoskodik, ami annyit tesz, hogy a markerekre kiszámított wx, wy értékeket leosztja a megtalált pixelek számával (N). Ennek eredménye a marker X, Y adattagjában lesz tárolva.
- 54 5.4.6. A findMarkers metódus sebesség-optimalizációja
Egy ilyen időkritikus metódusnak - mint a minden képkockára kameránként meghívott, teljes képet feldolgozó findMarkers - a lehető legoptimálisabbnak kell lennie. A kód legelső verziói hatékonysági szempontból még nagyon kezdetlegesek
voltak (éppen csak a helyes működés szempontjából feleltek meg); majd az optimalizációs munkának köszönhetően bontakozott ki a jelenlegi megfelelően gyors
algoritmus. A sebességi tesztek során mért eredmények továbbá érdekes tapasztalati tények sorához vezettek.
Képfeldolgozó algoritmusok implementálásánál a pointerek használata triviális, amit első lépésben megtettünk. Természetesen a menedzselt .NET környezet is ad erre lehetőséget; unsafe blokk használatával, plusz az azt engedélyező fordítási opció bekapcsolásával. Hatására kódunk ’kibújik’ a biztonságos memóriakezelést biztosító Marshal felügyelete alól, ám egyúttal nagyságrendekkel gyorsabbá is válik. A .NET egyik nagy előnye, hogy beépített funkcióival alapból minden programozási paradigmát támogat, sok esetre kész megoldást kínál - valójában ezért is választottuk projektünkhöz ezt a környezetet. Néha viszont hasznos szolgáltatásai, és az objektum-orientáltság maga hátráltató körülménnyé válhat egy-egy időkritikus alkalmazásban. Konkrétan például, a .NET rendelkezik egy saját szín-struktúrával, ami - az osztályhoz hasonlóan - kód és adat implementációja szemantikai részegységbe zárva. Ebből az adatokat property-ken keresztül nyerhetjük ki, ami hasznos ugyan, de több számunkra fölösleges művelettel jár, amit ráadásul pixelenként hatszor kell elvégeznünk. Adódott tehát az igény egy saját színdefiníció létrehozására, mely három darab (RGB) bájton kívül nem áll semmi másból. Ezáltal az algoritmus hatékonysága jelentősen megnőtt. Itt meg kell jegyeznünk, hogy ez előre sejtett kérdés volt, amit egy,
a későbbiekben ismertetett alapos mérési módszer remekül illusztrált. Egy következő - az optimalizálás során felmerült - érdekesség a kívülálló objektumok adattagjainak elérésével kapcsolatos. A rendszer számára ez ugyanis lényegesen több számítással jár, mintha egyszerű lokális változókat használnánk. Ez a
dolog az előzőleg ismertetett problémával ellentétben már nem tűnt túl triviálisnak – a fordítás
automatikus
optimalizálásában,
valamint
a
processzor
adat-cache
kihasználásában bízva. Emiatt úgy kellett átalakítani a kódot, hogy az összes kép-
- 55 szkennelésnél használt adat először lokális változókba kerüljön. A látszólag
indokolatlan, jelentős futásidőbeli eltérésre a Visual Studio „Performance Tool”-ja révén sikerült rámutatni. A Performance Tool egy olyan eszköz, melynek segítségével kódunk hatékonyságát egyszerűen mérhetjük. Sajnálatos módon ez a funkció nem része az
általunk használt Visual Studio 2005 Professional Edition-nek (a program Béta verziójában találkoztunk vele), mostmár csak a Team Foundation Edition-ből érhető el számos egyéb tesztelési módszer mellett; ezért hamarosan tervezzük az erre való áttérést. Használatához elegendő csupán a vizsgálandó programrészeket megadnunk, majd bizonyos ideig futtatni a programot. Utólag lehetőségünk van a mintavételezés frekvenciájának beállítására (ez két mintavétel közti elemi processzorműveletek
számára vonatkozik). Az eszköz bizonyos (megadott) számú utasításonként plusz mérőfunkciókat ellátó parancsokat illeszt a kódba, amikkel futásidőben elemezhetővé válik a program. A mérések arról adnak tájékoztatást, hogy pontosan mely részek
végrehajtásával időzik legtöbbet a processzor a futtatás idejében. 5.4.7. A markerkereső modul továbbfejlesztése
Bár modulunk jelenlegi verziója is megfelelően fürgének mondható, léteznek még továbbfejlesztési lehetőségek a 2.8-as fejezetben ecsetelt módszerek tükrében. A jelenleg megvalósított markerdefiníciós struktúra teljes és hibamentes – viszont a mögöttes, kissé bonyolultnak tűnő kód letisztítására vonatkozóan is vannak ötletek. Indokolt lenne a .NET beépített objektumlistájának (ArrayList típus) kihasználása, ezzel mellőzhetnénk a különböző dinamikus tömbök kezeléséhez szükséges összetett metódusokat, mint pl. amik az objektumok hozzáadását/törlését végzik. A kód a későbbi felhasználás szempontjából így jóval egyszerűbbé, átláthatóbbá válhat. Tény, hogy a kamerakép statikus zaja meglehetősen kedvezőtlenül hat a markerdetektálásra. A súlypontszámításos módszer az ebből fakadó remegést valamelyest kompenzálja, de nem szünteti meg teljesen – a valóságban egyhelyben álló marker a látott kép alapján számítva ugrál. Ésszerű lenne tehát, ha valamilyen zajszűrőt használnánk. A képekre alkalmazott medián- vagy Gauss-szűrő a problémát elvileg teljesen megoldaná, de ilyen időköltséges algoritmust sajnos nem engedhetünk meg egy valósidejű rendszer esetében.
- 56 A probléma orvoslására a Kálmán szűrőt hívhatjuk segítségül; amellyel ráadásul nem a kép, hanem eleve a számított mozgás zaja csillapítható. Ez a módszer lényegesen kevesebb erőforrást vesz igénybe – gyakorlatilag elhanyagolható a képfeldolgozó rutinokéhoz képest. Az 35. ábra a szűrő általános hatását, a 36. ábra pedig a zaj nagyságára vonatkozó bemeneti paraméter szűrőre gyakorolt hatását szemlélteti.
35. ábra - A Kálmán filter hatása a zajra [26]
36. ábra - A Kálmán filter eredményessége különböző beállítások mellett [27]
- 57 Az egész képre alkalmazott markerkereső algoritmusunk az optimalizálási munkáknak köszönhetően szinte már a lehető leggyorsabb, ám ezt még mindig nagyságrendekkel gyorsabbá lehet tenni, mégpedig a következő trükkel. A Kálmán filter egy másik nagyszerű oldalának kihasználásáról van szó; mégpedig a nem
determinisztikus rendszer következő állapotára vonatkozólag tett jóslatáról. Esetünkben tehát nem fontos az egész képkockát végigszkennelnünk - elegendő csupán a következő becsült markerpozíció valamilyen nagyságú környezetében keresnünk. Például ha a képnek csak a tized részét vizsgálnánk, ez a jelenlegi gyorsaság közel tízszereséhez vezetne.
5.5.
A 3D-s koordináták kiszámítása
5.5.1. Kezdeti nehézségek
A kalibrációs eljárások során megkapott információk segítségével kiszámíthatóak a markerek térbeli helyzetének koordinátái. Először meg kell keresni mindhárom kamera képén ugyanazokat a markereket. 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. Ha mindhárom kamerán megtaláltuk a markert, következhet a 3D-s koordináták visszafejtése. Mivel az irodalomkutatás során nem találtunk semmilyen erre vonatkozó leírást, magunknak kellett kidolgozni egy módszert. A 3D-s pozíció kiszámítási módja: ismerjük a kamerák térbeli pozícióját
ugyanabban a világ-koordinátarendszerben, így van három fix pontunk a térben. Ismerjük a kamerák orientációját is ehhez a koordinátarendszerhez képest, a megtalált marker pozícióját a pixel-síkon, illetve a képsíkon elhelyezkedő pixelek helyzetét a kamera-koordinátarendszerben (ezek a fókusztávolság, a pixelméret és az optikai középpont
ismeretében
kiszámíthatók).
Utóbbit
átszámolva
a
világ-
koordinátarendszerbe megkapjuk az adott marker képsíkon való elhelyezkedésének 3Ds pozícióját. Van tehát kameránként két 3D-s pontunk. Ezeket a pont-párokat összekötve három egyenest kapunk, melyek mindegyike a kamera középpontján halad át, a képsíkot pedig a megtalált marker pozíciójában metszi. Eltekinthetünk attól is, hogy a kamera a képet a gyújtópont mögött, fordított állásban jeleníti meg, hiszen ekkor is ugyanarról az
- 58 egyenesről beszélünk. Ez a három egyenes egy pontban kell, hogy találkozzon, ez pedig a keresett marker világ-koordiná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.
37. ábra - Az egymást egy pontban metsző egyenesek
Az elméletben azonban található néhány hiba: • nem ismerjük a fókusztávolság és a pixelméret számszerű értékét, csak az arányukat, így nem tudjuk megmondani a pixelek képsíkon való elhelyezkedésének térbeli pozícióját • mivel a kamerák pontatlanok, a három egyenesnek a valóságban soha nem lesz közös metszéspontja, hanem kitérő egyenesek lesznek, bár elég közel fognak elhaladni egymás mellett – tehát a metszéspont, vagyis inkább a feltételezett metszéspont kiszámítása nem olyan egyszerű, mint gondoltuk • a tesztek során bebizonyosodott, hogy a kamerák 3D-s pozícióját nem a világ-koordinátarendszerben kapjuk meg. 5.5.2. Az egyenesek meghatározása
A 3D-s modul elkészültét sokáig hátráltatta, hogy a kalibráció során kapott adatokat nem tudtuk értelmezni. Úgy gondoltuk, hogy a 3D-s koordináták számításához mindenképpen szükségünk van a kamera fókusztávolságának és a pixelméretének
- 59 ismeretére, viszont az OpenCV csak ezek arányát adja meg, amiből sehogy nem tudtuk visszafejteni ezeket az értékeket. Azonban rájöttünk, hogy valójában nincs is szükségünk ezen értékekre. Elég, ha a kamera középpontjából a marker képsíkon való elhelyezkedése felé mutató vektort ismerjük, hiszen a kamera helyének és ennek a vektornak az ismeretében fel tudjuk írni a kívánt egyenes irányvektoros egyenletét. A vektor hossza pedig nem számít, tehát az egyes koordinátáinak értéke sem, csak az egymáshoz viszonyított arányuk.
38. ábra - Az irányvektor
Az irányvektor koordinátáit pedig ki tudjuk számítani a következőképpen: mindhárom koordinátát ki tudjuk fejezni pixelegységben. A fókusztávolság értéke ismert, a kalibráció során pont pixelegységben kaptuk meg, ez lesz a vektor z koordinátája. Az x és y koordináták pedig megegyeznek a marker optikai középponthoz képest vett pozíciójával, mivel a z tengely az optikai középpontban metszi a képsíkot, a pozíciót pedig értelemszerűen szintén pixelegységben kapjuk meg. A pixelsík és a kamera koordinátarendszere közötti összefüggés a következő: X c = −( X im − O x ) ∗ s x
- 60 Yc = − (Yim − O y ) ∗ s y
Zc = f ahol Xim, Yim a képpont pixel koordinátái, Ox, Oy a kép optikai középpontja, sx, sy a pixel effektív mérete, f a fókusztávolság, valamint Xc, Yc és Zc a számítandó kamerakoordinátarendszerbeli értékek. Ezekkel a képletekkel a koordinátákat cm-ben kapnánk meg. Viszont mivel sx, sy értékét nem ismerjük, ráadásul a koordinátákat most pixelegységben
szeretnénk
megkapni,
a
képleteket
át
kell
alakítanunk
a
következőképpen: X c = O x − X im Yc = O y − Yim
Zc = f A fókusztávolságot az OpenCV két értékben adja meg: vízszintes és függőleges pixelegységben kifejezve. Ahhoz, hogy mindhárom koordinátát ugyanabban az egységben kapjunk meg, mindegyiket fx vagy fy segítségével kell kifejeznünk. Viszont Xc, Yc értékét különböző egységben kapjuk meg, ezért egyiküket át kell alakítani, hogy a másik függvényében kapjuk meg. Minden értéket a vízszintes pixelegységben kifejezve: X c = O x − X im Yc = (O y − Yim ) ∗
fy fx
Zc = f x Így a koordinátákat már a kamera-koordinátarendszerben, ugyanabban az egységben kifejezve kapjuk meg. Ezzel egy problémát kiiktattunk, az egyenesek mégis felírhatók.
- 61 5.5.3. Az egyenesek feltételezett metszéspontja
A kitérő egyenesek legvalószínűbb metszési pontjának kiszámolására a következő megoldást találtuk ki (az 39. ábra jelöléseit használva): először is két egyenes metszéspontját kell megkeresni. Vegyünk két kamerát, ezek középpontja legyen T1 és T2, a hozzájuk tartozó egyenesek legyenek
a és b, irányvektoruk pedig a és b.
Számítsuk utóbbiak vektoriális szorzatát, amely merőleges mindkét egyenesre, ez lesz ab. Ezután vegyük b és ab vektoriális szorzatát, ami mivel merőleges mindkét egyenesre, az általuk meghatározott sík normálvektora lesz, ezért legyen ez n. T1 és n segítségével határozzuk meg az X síkot. Az a egyenes X síkot egy pontban metszi, ez lesz A.
39. ábra - A marker legvalószínűbb helyének kiszámítása
Most vegyük a és ab vektoriális szorzatát, m-et. T2 és m segítségével írjuk fel az Y síkot. A b egyenes Y síkot egy pontban metszi, ez lesz B. Ha megvan az A és a B pontunk, ezeket átlagolva megkapjuk P-t, ami a két egyenes legvalószínűbb metszéspontja. Ezután végezzük el ezt a számítást minden egyenes-párra, majd az így kapott pontok koordinátáinak átlagolásával megkapjuk a keresett marker térbeli pozícióját. Két egyenes esetén (ha csak két kamerát használunk, vagy csak két kamerán találtuk meg a markert), akkor elegendő mindössze egyszer elvégeznünk ezt a számítást. Három kamerával már három egyenes-párral kell számolnunk, n kamera esetén pedig
- 62 n∗
(n − 1) 2
metszéspontot kell keresnünk (a sokszög csúcsait összekötő átlók számához hasonlóan). Ezzel a második problémára is találtunk megoldást. 5.5.4. A kamerák pozíciója a világ-koordinátarendszerben
A külső paraméterek kiszámítása után teszteltük, hogy jó adatokat kaptunk-e. Első látásra jónak tűntek, mert nagyságrendileg megfeleltek, de miután kimért pozícióban kalibráltuk be őket, az eltolás-vektorok valótlan értékeket mutattak. Ekkor arra gondoltunk, hogy az OpenCV nem a világ-koordinátarendszer origójához képest adja meg az eltolást, hanem az origót adja meg a kamera-koordinátarendszer közepéhez képest. Ezután a kapott koordinátákat transzformáltuk a kamera rotációs mátrixával, az így kapott értékek pedig már tényleg a világ-koordinátarendszerhez képest viszonyított értékek voltak. Ezzel a harmadik problémát is megoldottuk (megjegyeznénk, hogy ez a lényeges információ az OpenCV dokumentációjában sehol nem szerepel). 5.5.5. Két kitérő egyenes feltételezett metszéspontja
Nézzük meg a második probléma megoldásánál ismertetett elméleti módszert a gyakorlatban! A két vektor vektoriális szorzatának kiszámítása a következőképpen történik: az a (a1, a2, a3), b (b1, b2, b3) és az ab (i, j, k) vektorok koordinátáiból alkotunk egy mátrixot, aminek determinánsát az i, j, k koordináták helyén kiszámítva megkapjuk a vektoriális szorzat koordinátáit: i a × b = a1 b1
j a2 b2
k a a3 = 2 b2 b3
a3 a ∗i − 1 b3 b1
a3 a ∗ j+ 1 b3 b1
a2 ∗k b2
a × b = (a 2 ∗ b3 − a3 ∗ b2 ) ∗ i − (a1 ∗ b3 − a3 ∗ b1 ) ∗ j + (a1 ∗ b2 − a 2 ∗ b1 ) ∗ k A másik két vektor vektoriális szorzata ugyanígy számítandó, ez eredményezi a sík normálvektorát. Ezután következik a sík egyenletének és az azt metsző egyenes egyenletének felírása, az ezeket együttesen kielégítő pont koordinátáinak kiszámítása.
- 63 Ha n (A, B, C) a sík normálvektora, P0 (x0, y0, z0) a sík ismert pontja és P (x, y, z) a keresett metszéspont, akkor a sík egyenlete a következőképpen írható fel: A ∗ (x − x0 ) + B ∗ ( y − y 0 ) + C ∗ ( z − z 0 ) = 0 Legyen v (v1, v2, v3) a síkot metsző egyenes irányvektora, Q (i0, j0, k0) az egyenes ismert pontja és P (x, y, z) a síkkal közös metszéspontja, eszerint a síkot az alábbi egyenletrendszerrel jellemezhetjük:
x − i0 y − j 0 z − k 0 = = v1 v2 v3 Fejezzük ki ebből y-t és z-t!
y=
v2 ∗ ( x − i0 ) + j 0 v1
z=
v3 ∗ ( x − i0 ) + k0 v1
Láthatjuk, hogy a képletekben x az egyedüli ismeretlen, tehát annak ismeretében ki tudjuk számolni y-t és z-t is. Helyettesítsünk be a sík egyenletébe, majd fejezzük ki xet!
⎞ ⎛v ⎞ ⎛v A ∗ ( x − x0 ) + B ∗ ⎜⎜ 2 ∗ ( x − i0 ) + j0 − y 0 ⎟⎟ + C ∗ ⎜⎜ 3 ∗ (x − i0 ) + k 0 − z 0 ⎟⎟ = 0 ⎠ ⎝ v1 ⎠ ⎝ v1 ⎛ ⎛ v ⎞ v ⎞ v v ⎜⎜ A + B ∗ 2 + C ∗ 3 ⎟⎟ ∗ x − A ∗ x0 − ⎜⎜ B ∗ 2 + C ∗ 3 ⎟⎟ ∗ i0 + B ∗ j0 − B ∗ y 0 + C ∗ k 0 − C ∗ z 0 = 0 v1 v1 ⎠ v1 v1 ⎠ ⎝ ⎝
⎛
x=
⎞
( A ∗ x0 + B ∗ y 0 + C ∗ z 0 ) + ⎜⎜ B ∗ v 2 + C ∗ v3 ∗ i0 − B ∗ j0 − C ∗ k 0 ⎟⎟ v1 ⎝ A ∗ v1 + B ∗ v 2 + C ∗ v3 v1
⎠
- 64 Az x, y és z kiszámításával megkapjuk a sík és az egyenes metszéspontját. Ugyanezt a számítást elvégezzük a másik síkra és a másik egyenesre, majd a két metszéspont koordinátáinak átlagát véve megkapjuk a két egyenes legvalószínűbb metszéspontját. 5.5.6. Vektor look-up table
A markerek 3D-s pozíciójának kiszámításához szükséges egyeneseket a rendszerben a kamerák világ-koordinátarendszerbeli helyzetének és az egyenesek irányvektorainak
segítségével
tároljuk.
Az
irányvektorok
koordinátáit
a
következőképpen számíthatjuk ki: az első probléma megoldásánál ismertetett módon kapott, pixelegységben kifejezett koordinátákat, amiket a kamera origójához képest kaptunk meg, áttranszformáljuk a világ-koordinátarendszerbe, azaz elforgatjuk. A következő egyenletből indulunk ki, ahol R a rotációs mátrix, T a kamera pozíció:
⎡X c ⎤ ⎡X w ⎤ ⎢Y ⎥ = R*⎢Y ⎥ +T ⎢ c⎥ ⎢ w⎥ ⎢⎣ Z c ⎥⎦ ⎢⎣ Z w ⎥⎦ Ez egy ismert összefüggés a kamera- (Xc, Yc, Zc) és a világ-koordinátarendszer (Xw, Yw, Zw) között, csakhogy ez pont a fordított átalakítást írja le, mint ami nekünk kell, ezért a következő formára hozzuk: ⎡X w ⎤ ⎡X c ⎤ ⎢ Y ⎥ = R −1 * ⎢ Y ⎥ − T ⎢ w⎥ ⎢ c⎥ ⎢⎣ Z w ⎥⎦ ⎢⎣ Z c ⎥⎦ Így újabb problémával szembesülünk, ugyanis a rotációs mátrix inverzére lesz szükségünk. Szerencsére speciális mátrixszal van dolgunk, aminek van két fontos tulajdonsága: • minden rotációs mátrix determinánsa 1 • a rotációs mátrix ún. ortogonális mátrix, aminek inverze megegyezik a transzponáltjával – ez jelentősen megkönnyíti az inverz mátrix kiszámítását, hiszen elég a mátrix főátlójára egy tengelyes tükrözést végezni.
- 65 A képleten még egy módosítást végre kell hajtanunk: mivel nem egy pont pozícióját, vagy egy helyvektort transzformálunk, hanem egy irányvektort, az eltolást nem kell, sőt nem is szabad elvégeznünk, elég elforgatnunk, akkor kapjuk ugyanazt az irányvektort a világ-koordinátarendszerben. A helyes képlet így a következő:
⎡X w ⎤ ⎡X c ⎤ ⎢ Y ⎥ = R −1 * ⎢ Y ⎥ ⎢ w⎥ ⎢ c⎥ ⎢⎣ Z w ⎥⎦ ⎢⎣ Z c ⎥⎦ Tehát a mátrix inverzének kiszámítása után a fenti képlet alapján ki tudjuk számítani
bármelyik
pixelbe
mutató
irányvektort.
Viszont
minden
kamera
másodpercenként 20-30 képkockáján látható összes marker esetében ez rengeteg számítást jelent, ennek gyorsítására ún. look-up table-t használunk. Ennek lényege, hogy elég minden kamera minden pixelére csak egyszer kell elvégezni ezt a számítást, mivel ez nem fog változni, ezért létrehozunk egy tömböt, amiben eltároljuk minden pixelhez a hozzá tartozó irányvektor transzformált koordinátáit. A tömb elemeinek értékét a program indulásakor számítjuk ki, a markerek térbeli pozíciójának számításakor pedig ebből a tömbből olvassuk ki a megfelelő értékeket, így nem kell újra és újra kiszámolnunk őket. 5.5.7. A gyakorlati megvalósítás
A
3D-s
pozíciót
számoló
modul
a
Point3DSolver
osztályban
került
implementálásra. Ez rendelkezik egy Camera nevű alosztállyal, amiben az egyes kamerák adatait tároljuk: kameraazonosító és -név, optikai középpont, fókusztávolság, rotációs mátrix, eltolás vektor, torzítási együttható vektor, vektor look-up table, illetve a megtalált marker pixel-koordinátái. A modul működése a következő: • a főprogram példányosítja a Point3DSolver osztályt 12. a program létrehoz egy Camera objektumokból álló tömböt, melynek méretét a főprogram állítja be a rendszerben található kamerák száma alapján 13. a főprogram feltölti a tömböt a rendelkezésre álló kamerák adataival • a főprogram meghívja a Point3DSolver objektum Setup metódusát
- 66 14. az egyes kamerák eltolás vektorát transzformálja a rotációs mátrixukkal, így megkapjuk a kamera pozícióját a világ-koordinátarendszerben, ahogy ezt 5.5.5. fejezetben ismertettük 15. feltölti a vektor look-up table-t, minden elemére elvégzi az inverz mátrixszal való szorzást • ezután
kezdődik
a
Motion
Capture
folyamat 16. a
markerdetektáló
modul
megkeresi
a
kamerák képén a markereket, majd ezek pozíciója
a
Point3DSolver
objektumban
tárolt Camera objektumok adattagjaiba kerül 17. a
főprogram
GetMarker3DPosition
meghívja
a
metódust,
ami
kiszámítja a marker térbeli pozícióját 18. a 3D-s koordinátákat hálózati kapcsolaton keresztül
továbbítja
a
Performance
Animation modulnak. 40. ábra - A Point3DSolver osztály
A modul eleinte csak kettő vagy három kamerával működött, később – egy újabb kamera beszerzésével – ez a szám négyre növekedett, de ekkor még nem általános megoldást használt, hanem külön kódrészlet szolgált a különböző számú egyenesekkel történő számításra. Később azonban elkészült egy univerzális megoldás, ami tetszőleges számú kamerával működik. Nem is a kamerák száma a meghatározó, hanem az, hogy az adott
markert hány kamera képén sikerült megtalálni. Ha ez a szám kettőnél kevesebb, akkor a főprogramra meg se hívja a GetMarker3DPosition metódust, ilyenkor a hálózaton sem továbbítódik adat, a kliens oldalon az előző állapot jelenítődik meg. Ha a markert kettő, vagy annál több kamera képén találtuk meg, akkor a program ugyanennyi egyenes alapján számolja ki a marker
- 67 3D-s pozícióját, tehát több kamera fokozhatja a rendszer pontosságát. A kamerák számát illetően nincs megkötés. Tekintve, hogy a modul a feladatát maradéktalanul ellátja, univerzális számú kamerával működik, ráadásul mindezt kellően gyorsan, továbbfejlesztése ilyen szempontokból nem szükséges. Egyedül a pontosság területén képzelhető el előrelépés, amit a look-up table szubpixeles pontosságúvá alakításával tervezünk megvalósítani. A markerdetektálás már eleve szubpixelesen adja meg a marker 2D-s pozícióját, így ha pl. a look-up table méretét mindkét dimenzióban a tízszeresére növelnénk, akkor egy tizedessel pontosabb koordinátákkal számolhatnánk. Ez a feldolgozás folyamatán semmit sem lassítana (csak a felvétel előtt a tömb feltöltése tartana tovább), egyetlen hátránya a jelentősen megnövekedett memóriaigény lenne.
5.6.
A Maya szerver modul A Maya szerver modul célja, hogy kapcsolatot teremtsen a kiszámított Motion
Capture adatokat felhasználó Autodesk Maya programmal. A kapcsolatteremtés hálózaton keresztül történik, annak érdekében, hogy a 3D mozgásdigitalizálás (Motion Capture), illetve a 3D megjelenítés (Performance Animation) két számítógép között elosztott erőforrást használhasson. Bár önmagában mindkét feladat megkívánja magának egy-egy gép teljes mértékű kihasználását, annak sincs akadálya, hogy ezek ugyanazon számítógépen fussanak – épp a hálózati kialakítás révén. Ahhoz, hogy a két program egymással kommunikálni tudjon, a Maya Software Development Kit (SDK) nyílt C++ kódú Motion Capture Server könyvtárait használtuk fel. Segítségével definiálható egy ún. hálózati Motion Capture Device, amely folyamatosan mozgásadatokat sugároz a Maya kliens számára.
- 68 -
5.6.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 kiforrott Motion Capture technikák használatához is. A fejlesztők számára közzé tett ’Maya Motion Capture API Library’ tartalmazza az általános MoCap függvényeket. Az alapkialakítás szerint létezik egy szerver ill. egy kliens process, melyek a gépek közti adatforgalmat bonyolítják. 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. 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. [28] A szerver library kb. 20 felhasználó által hívható rutint tartalmaz, melyek négy kategóriába sorolhatók: • kliens/szerver protokollt,
kommunikációs
sorrendtartó
rutinok,
adat-struktúrát,
melyek
kommunikációs
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. [29]
- 69 5.6.2. A modul kialakítása
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 Motion Capture 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). Választásunk a Platform invoke megoldásra esett, figyelembe véve azt, hogy a
szerver modul kialakításánál nincs szükségünk objektumok használatára, mivel az csak egyszerű függvényhívásokból áll – állapotterének megtartására pedig a kód globális változói is megfelelőek. Ilyen kialakítás mellett az egész modul gyakorlatilag egy osztályként működik. Modulunk tehát egy DLL-lé (Dynamic Link Library) fordul, amiben a szükséges interfész függvényeket kívülről (a .dll-t meghívó program számára) elérhetővé tesszük. Ehhez a fordítónak minden függvénydefiníció előtt meg kell adnunk az extern „C” kulcsszót, a __declspec(dllexport) attribútum-szintaxist (a függvény tárolásának formátuma) és a paraméterhívási sorrend direktíváját, ami alapértelmezetten __stdcall. 5.6.3. A modul működése
A modul első lépésként beállítja a hálózati portot, amin keresztül programunk a Mayával kommunikálni fog. Ezután kialakítja a hálózati kapcsolatot a Mayával. Ehhez létrehoz egy socket-et, és várakozik egészen addig, amíg a klienssel való handshake (kézfogás) meg nem történik. A kapcsolat akkor jön létre, amikor a Mayában lefut a megfelelő adatszerver definíciós szkript (lásd: 5.8. fejezet). Ha a kliens csatlakozott, eltárolja a socket azonosítóját. Ezután a főprogramból átadjuk a marker 3D-s koordinátáit a modulnak, majd a paraméterként (X, Y, Z struktúrákból álló tömbként) kapott aktuális értékeket beállítjuk a küldéshez, amiket a szerver egy adagban elküld a Mayának. Első lépésben lekérdezi a kliens állapotát, amiből kiderül, ha menet közben történt valamilyen hiba, időtúllépés, vagy ha épp üzent nekünk valamit a kliens.
- 70 • Hiba esetén a megfelelő helyre generálunk egy hibaüzenetet - a kliensnek, a rendszernaplóba vagy a szabvány-hibaportra. • Időtúllépés esetén csak akkor küldünk adatot, ha épp Motion Capture felvétel közben vagyunk – ekkor ugyanis minden kiszámolt adatra szükség van, amik előbb-utóbb úgyis célba fognak érni. • Üzenet érkezése esetén a program kiszolgálja a klienst annak igénye szerint. Kliens hiba vagy leállítás esetén a szerver oldalon is terminálunk,
a
jogosultság
megtagadhatjuk,
elvégezzük
kérést a
megadhatjuk,
kézfogást,
vagy
épp
visszatérünk
a
szervernévvel/verzióval, az adatcsatornákat létrehozzuk, ha még nincsenek. Adatkérő üzenet esetén pedig küldjük a következő csomagot, ami a markerpozíciókat tartalmazza. Végül a kapcsolatot le kell zárnunk. Az erre szolgáló függvény a csatlakozott kliens azonosítója alapján lezárja a socketet, és az azonosítót alaphelyzetbe állítja. A Maya szerver modul további részei nem publikusak a .dll-t meghívó program számára. A createChannels függvény létrehozza az adatcsatornákat a markerpozíciók küldéséhez, ha még nincsenek definiálva. A létrehozható csatornákból többféle is lehet, annak különböző használati módjai alapján. Esetünkben csak 3D-s pont pozíciójára vonatkozó adatok átküldésére van szükség, de létezik definíció pl. orientációra, skálázásra, súlyozásra, stb., illetve ezek külön egydimenziós koordinátáira is. A függvény
tehát
létrehozza
a
markerek
számának
megfelelő
mennyiségű
háromdimenziós pozíció-csatornákat, amiket ’ch01’-től kezdődően számozva
elnevez. A Mayából ezekre a csatornanevekre hivatkozva nyerhetjük ki az aktuális markerpozíciókat. Az adatküldést a getData függvény végzi, ami a létrehozott adatcsatornákra egyenként ’ráülteti’ a beállított aktuális 3D-s markerpozíciókat. Modulunk
jelenlegi
verziója
gyakorlatilag
minden
szükséges
feladatot
megfelelően elvégez. Ilyen értelemben továbbfejlesztésre tulajdonképpen nincs is szükség.
- 71 -
5.7.
A főprogram
5.7.1. A főprogram feladata
A főprogram (MainForm) feladata az egymástól jól elkülöníthető modulok összekapcsolása, a felhasználói felület kialakítása, illetve a bevitt adatok összehangolása, célba juttatása. A MainForm a modulok együttes használatával egy
magasabb absztrakciós szinten képes megoldani az összetett Motion Capture problémát. Az adatút egyes állomásai – amelyek javarészt sorrendben egymásra épülnek – a következők:
Modul
Nyelv
Hely
Fájlnév
Funkció
Kalibráció
C++
Capture
C#
különálló Capture.cs fájl
Kameraképek elérése.
Megjelenítő ablakok
C#
különálló CameraForm.cs fájl
Kameraképek, detektált markerek megjelenítése, színmintavétel.
Markerkeresés
C#
különálló MarkerDetection.cs fájl
Tetszőleges számú színes marker pozíciójának meghatározása a képsíkon.
3D pont meghatározás
C#
különálló point3DSolver.cs fájl
Tetszőleges számú marker pozíciójának meghatározása a térben.
Maya szerver
C++
futtatható Kamerák paramétereinek CameraCalibration.exe állomány inicializálása.
külső DLL
mayaServer.dll
A kiszámolt 3D-s koordináták (TCP/IP alapú) küldése a kliens Maya felé.
4. táblázat – A főprogram által vezérelt modulok
Fontos megemlíteni, hogy az adatútnak létezik még két másik állomása, amik önmagukban nem alkotnak különálló modult, hanem a főprogram részét képezik. Az egyik a mozgásadatok fájlba rögzítése, ami gyakorlatilag az adatút végét jelenti. A másik a különböző beállítások fájlba mentése, illetve visszatöltése, ami az adatúttal párhuzamosan történik.
- 72 5.7.2. A főprogram elvi működése az adatút szempontjából
A Motion Capture felvételhez szükséges adatok (vagy paraméterek) először a kamera kalibráció során jelennek meg. Ezeket a program legközelebb csak a 3D
modulban használja fel, ezért a képmegjelenítés, markerdetektálás ezen első lépés kihagyásával is elérhető. A kalibrációt egy konzolos alkalmazás végzi, ami az adatokat fájlokba menti. Először tehát ezt a programot kell elindítanunk egy folyamat objektumként, aminek átadjuk a megfelelő paramétereket (kimeneti képfájl, amibe a
kameraképet menti, kalibrációs adatfájl, illetve a kamera logikai- és fizikai azonosítója). Megvárjuk, amíg a folyamat végez, majd az adatfájlokat szöveges állományként visszaolvassuk
–
ezután
a
megkapott
értékeket
átadjuk
a
3D
modul
objektumpéldányának. Programunk a folyamatot sorban minden kijelölt kamerára
elindítja, és ha valamelyik sikertelen volt, lehetőséget ad annak kihagyására vagy ismétlésére. Programunk számára a következő adat-inputot a kamerák képei jelentik. A sorban érkező képek pedig a markerdetektáláshoz és a képernyőn történő megjelenítéshez ágazhatnak el. Ez jelenti számunkra a legnagyobb adatcsatornát – a
szűk keresztmetszetet (a legtöbb optimalizálásra ennek kapcsán van szükség). A kamerakezelő osztályból létrehozunk annyi objektumot, amennyit a felhasználó a kamerakezelő felületen bejelölt, majd ezek mindegyikén elindítjuk a képfolyamot. Ha később valamelyik kamera bejelölését visszavonják, nem szabadítjuk fel annak objektumát, csak a stream-et állítjuk meg, ezáltal rugalmasabbá válik az interaktivitás. Felbontás-váltásnál minden kameraobjektumból újat hozunk létre az új paraméterekkel. A kamerakezelő modultól érkező képeket a program külön megjelenítőablakokba irányítja, ezekből annyit hoz létre, ahány kamera ki van jelölve a főformon.
Az ablakokból beállíthatóak a markerek színei, amit programunk az egérkurzor pozíciója alapján mintavételez a képről, 3*3 pixelnyi terület átlagát számítva. Lévén, hogy a markerek színei kameránként különbözőek is lehetnek, a színbeállítást az aktuális ablak kamerájához tartozó markernek adja. A markerdetektálás bemeneti adatait a kameraképek és a markerek színdefiníciói jelentik. A képeket a capture modulból kapja, a markerbeállításokat pedig
a
felhasználói
felületről.
Először
létrehozzuk
a
megfelelő
számú
markerobjektumot, melyek értékeiket aztán több helyről is kaphatják: a főablak
- 73 színbeállító csúszkáitól, a megjelenítő ablakok színmintavételezésétől vagy éppen mentett fájlból. A
fájlkezelés ún. objektum-sorosító eljárással történik, melynek során az egész hierarchikus felépítésű (háromszintű)
markerdetektáló
objektumot
bináris
adatfolyam formára hozzuk, amit így már stream-ként fájlba
írhatunk.
A visszatöltés (ennek inverzével) hasonló elven működik. A
markerpontok
3D-s
koordinátáinak
számítását végző modul a bemeneti adatait a kamerakalibrációs résztől, valamint a markerdetektáló
modultól kapja. Főciklusunk először minden egyes kameraképre
kiszámíttatja
a
markerek
2D-s
koordinátáit, majd markerenként külön-külön továbbítja a 3D modulnak, ami visszatér azok térbeli helyzetével. Itt már csak azokat a markereket vesszük számításba, amelyek legalább két kamera képén megtalálhatók – ha ez a feltétel nem áll fenn, az előző ciklusban kiszámított pozíciót tartjuk meg. A térbeli koordináták adatai innen még két helyre ágazhatnak, mégpedig a hálózati modul bemenetére, illetve a mozgásadat-fájlba. Ahhoz, hogy a mozgás egzakt módon legyen helyileg rögzítve, nem elég csupán az egymást követő képkockákra kiszámított 3D-s markerpozícókat sorban elmentenünk. A ciklusok kissé eltérő futásideje miatt pontatlan eredményt kapnánk – ezért minden adatot időbélyegzővel kell ellátnunk. A mozgás visszajátszása során pedig ennek megfelelően időzítve kell küldenünk az adatokat a hálózatkezelő modulnak.
41. ábra - A MainForm osztály
- 74 A fejlesztés során felmerült az igény a felhasználói felület számos szerteágazó beállításának fájlba mentésére, amik a programból való kilépés után is megmaradnak
és indításkor visszatöltődnek. Ehhez létrehoztunk egy formbeállításokat tartalmazó sorosítható objektumot, amit ezáltal a program indításakor és bezárásakor bináris stream-fájlként kezelhetünk. 5.7.3. A főprogram gyakorlati kialakítása
Miután
megismerkedtünk
a
modul
működését illetően a ’mit csinál’ kérdésre adott válasszal, nézzük meg a ’hogyan csinálja’ szempontjából is. Inicializálás: indításnál a főprogram a
kamerakezelő
modul
alapján
lekérdezi
a
rendszerre csatlakoztatott kamerák számát,
és ennek megfelelően létrehozza a kameralistát az ablak Cameras részében. Ha a rendszerre nincs kamera csatlakoztatva, vagy ha azok már használatban vannak más program által, a program egy hibaüzenettel leáll. A továbbiakban még
létrehoz
egy-egy
példányt
a
markerdetektáló és a 3D-s pozíciót számító
modulok
osztályaiból.
A
kamerakezelő
modulból egyelőre még nem példányosítunk, mert ez a kiválasztott kamerák számától függ. A főciklus működése: az egész program
folyamatos, ciklikus működését egy timer objektum biztosítja, amely a rendszeridő alapján egy megadott frekvenciával hívogatja meg a rendszer
szívét
jelentő
frameProcessing
metódust. A frekvenciát a felhasználói felület
Cameras
részében
változtathatjuk.
Ez
42. ábra - A teljes Solution
alapértelmezetten 100 Hz, tehát főciklusunk minimum 10 ezredmásodpercenként hívódik meg, ami lehet több is abban az esetben, ha ciklusunk nem végez ez idő alatt.
- 75 A frameProcessing metódusnak periódusonként sorrendben a következő fő feladatokat kell ellátnia:
• képek lekérése a megjelölt kameráktól • markerdetektálás elvégzése a kameráktól kapott képek mindegyikére • a 3D-s koordináták kiszámítását végző modul meghívása a megtalált markerek 2D-s pozícióival • a kiszámított 3D-s markerpozíciók küldése a Mayának Ezen feladatok mindegyike opcionális – a felhasználói felületről megadható, melyeket végezze el a program. Mivel ezek a számítások egymásra épülnek, a működést csak a függőségi viszony alapján állíthatjuk be. A Motion Capture felvételhez mindenképp szükséges feladatokon kívül vannak még egyéb elvégzendő részek is a metódusban; ilyen a képmegjelenítés, valamint a 3D-s mozgásadatok fájlba írása. 5.7.4. A párhuzamosítás bevezetése
A kód kialakítása során törekedtünk a többszálúság bevezetésére – célszerű a kamerák képeit párhozamosan lekérni, amiket aztán a markerdetektáló modul szintén párhuzamosan dolgozhat fel. Többmagos processzoroknál ez a fajta eljárás különösen előnyös lehet.
43. ábra – A párhuzamos működés elvi ábrája
- 76 Elsőként a kamerakezelés párhuzamosítására került sor, mivel a DirectShow eleve párhuzamos kialakítása miatt ez könnyen megoldható volt. A .NET-es / C#-os szálkezelés tanulmányozását követően a markerdetektálás szálasítása volt soron. Az osztály képfeldolgozó függvényéből létrehozott szálak már képesek voltak ugyan kameránként párhuzamosan működni, de a képkockánkénti műveletvégzés érdekében a ciklusos szál-létrehozás nem vezetett eredményre (a rendszer lassult).
Annak érdekében, hogy a markerdetektálás folyamatos, szakadatlan szálon működjön, a .NET ún. ThreadPool megoldásához kellett folyamodni, e technikával könnyen elérhető, hogy egy szál, miután befejezte munkáját, kapjon egy új feladatot. A leállított szál felszabadítását késlelteti, míg az új metódust ismét hozzá nem rendeljük – ezáltal felmentve a rendszert a folyamatos, sűrű szálcserétől. Programunk jelenlegi verziója a soros, illetve párhuzamos működésre is ad opciót, ami beállítható a felhasználói felületről. 5.7.5. A felhasználói felület kialakítása
A felhasználói felület az adatút egymásra épülő állomásainak tükrében lett kialakítva - balról jobbra haladva találhatók az egyes modulok beállítási lehetőségei. Ennek megfelelően mindegyik részhez megkötés is tartozik, a modulokat mindaddig nem indíthatjuk el, míg a hozzájuk tartozó szükséges beállítások rendelkezésre nem állnak. A szükséges hibaszűrések minden beviteli mezőn megtalálhatók – a hálózati porthoz például kizárólag csak számokat írhatunk.
44. ábra - A felhasználói felület
- 77 A kamera kalibrációs felületről végezhetjük el a kamerák külső paraméterinek meghatározását, sorrendben az összes kamerára. A kapott értékeket a program fájlba menti. A kalibrációs paraméterek későbbi visszatöltésére is van lehetőség. A kamera-beállítások felületen adhatjuk meg a kamerák felbontását, kiválaszthatjuk a felvételhez használt kamerákat, beállíthatjuk a képtovábbítás mintavételi frekvenciáját, valamint a megjelenítő-ablakok automatikus elrendezését is bekapcsolhatjuk. Az FPS jelző felület a mozgás felvételének folyamatosságáról, valamint a kamerákból érkező, fel nem dolgozott képek számáról ad tájékoztatást. A Marker detection felületen van lehetőségünk a markerkeresés paramétereinek beállítására. Megadhatjuk a keresett markerek számát, illetve az egyes markereket el is nevezhetjük. A felületen látható egy színes markerminta labda, amely az aktuálisan definiált marker színét reprezentálja. A csúszkákkal a szín komponensenkénti minimum és maximum vágását adhatjuk meg, a tartományokba eső színárnyalatok még az aktuálisan kiválasztott marker színének számítanak. A definiált markerszínek kameránként eltérőek is lehetnek, ezért mindegyikre külön beállíthatjuk ezeket. A markerkeresést a Detect markers gombbal tudjuk aktiválni, a megtalált markerek színes karikákkal lesznek jelölve a kameraablakokban. Ha a Marker colors only opciót bekapcsoljuk, akkor a kameraablakok képein csak a beállított értékeknek megfelelő színek jelennek meg. Segítségével láthatjuk, hogy a program az adott színű markerből mekkora területet vesz számításba. A beállítás akkor a legmegfelelőbb, ha a megjelenített pontok az egész markerre kiterjednek, és nem keverednek közéjük egy másik marker pontjai. Ha végeztünk, a beállításokat elmenthetjük, illetve ezek visszatöltésére is van lehetőség. A kameraablakok elsősorban a kamerából érkező képek megjelenítésére szolgálnak, de számos egyéb hasznos funkciót is ellátnak, pl. a markerszínek beállítását innen is elvégezhetjük. Lehetőségünk van a megjelenítést megállítani, ekkor az utolsó kirajzolt képkocka merevítődik ki. Ez a funkció a Motion Capture felvételnél igen hasznos lehet, mert a képmegjelenítés nem terhel le plusz erőforrást, ami ezáltal kihathat a felvett mozgás minőségére. A program a Motion Capture adatokat TCP/IP hálózati protokoll segítségével osztja meg a kliens számítógéppel; a hálózati kapcsolat felületen azt a portot kell megadnunk, amelyen keresztül a program kapcsolatot teremt a Maya klienssel.
- 78 A Motion Capture felvétel során lehetőségünk van a kiszámolt 3D-s mozgásadatokat folyamatosan fájlba írni; a fájl visszajátszását a Playback gombbal indíthatjuk. 5.7.6. Továbbfejlesztési lehetőségek
Főprogramunk továbbfejlesztési tervei közt szerepel egy plusz mozgásfelvételi üzemmód hozzáadása, amely csak és kizárólag a Motion Capture-höz elengedhetetlen számításokat végzi; a felvételt lassító, egyéb kiegészítő funkciók mellőzésével. Utólagos
videó-feldolgozással
a
valósidejű
rendszerünk
kiegészíthető,
amely
lényegesen folyamatosabb és precízebb 3D-s mozgásfelvételt produkál. Egy a processzor terheltségét és az FPS-t kijelző diagram is hasznos lehet a továbbiakban. A párhuzamos feldolgozás (szálkezelés) fejlesztése igen jelentős szerepet tölt be a projekt hatékonyságának további növelésében. A program univerzalitása érdekében tervezzük egy adatfolyam-gráf szemléletű felhasználói felület kialakítását, amely nagyrészt hasonló a DirectShow gráfokhoz, vagy esetleg közvetlenül azokra is épülhet. Ezzel a kialakítással a folyamathoz különféle feldolgozóegységek (pl. szűrők) is hozzáadhatók lennének. Többféle kimenetre is irányíthatjuk az adatokat, mint pl. mentés videó fájlba, helyi 3D-megjelenítés, valamint a mozgásadat hálózatra irányítása.
5.8.
A Performance Animation környezet konfigurálása
5.8.1. A megjelenítő felület
A megjelenítő felület kialakítására két lehetőség kínálkozik: 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, annak library függvényeit használja fel.). Projektünkhöz a Maya
főprogramját
találtuk
a
leginkább
megfelelőnek
a
mozgásfelvétel
megjelenítéséhez és rögzítéséhez egyaránt. A felvételt így utólag szabadon szerkeszthetjük, vagy akár dolgozhatunk vele valós időben is.
- 79 5.8.2. Konfiguráció MEL szkripttel
A konfiguráció kialakításához a Mayába ágyazott MEL (Maya Ebedded Language) szkriptet használtuk, mellyel a program funkcionalitását szinte tetszőleges mértékig növelhetjük. Minden, amit a Maya grafikus felületével elvégezhetünk, automatizálható
és
kiterjeszthető
általa.
Eljárásokat
készíthetünk
speciális
modellezéshez, animációhoz de akár dinamikus rendszerekhez, foto-realisztikus renderelési feladatokhoz is. MEL szkriptünk jelenlegi verziója a következő feladatokat végzi:
• megteremti a kapcsolatot a Motion Capture szerverrel, • az adatcsatornákat hozzárendeli a ’Motion Capure Device’-hoz, • annyi pontot hoz létre a virtuális térben, ahány markerrel dolgozunk, • a device adatfolyamait a pontokhoz kapcsolja, melyek a karaktercsontvázat mozgatják. A fejlesztés során egyéb szkripteket is felhasználtunk, amik a tesztelést és debug-olást segítették elő. A háromdimenziós matematikai számítások eredményei nagyon nehezen értelmezhetőek, ha azokat csak puszta számértékek reprezentálják. Szükség volt tehát egy szemléletes 3D-megjelenítésre, ami alapján a köztes számítási fázisokat ellenőrizhettük, továbbfejleszthettük. A valós idejű illusztrációk remekül rámutattak a 3D-s pont-visszafejtés különböző lépcsőinek hibáira, amit így valós időben korrigálni tudtunk - sok esetben anélkül, hogy a futó programot egyáltalán leállítottuk volna. Ezek a szkriptek a következők voltak: • kamerák helyzetének megjelenítése az origóhoz (sakktáblához) képest; • a
kamerák
gyújtópontjából
az
azok
képsíkjain
megjelenő
markerpozíciókon át húzott egyenesek, plusz a marker kirajzolása.
- 80 -
45. ábra - A teszteléshez használt szkriptek együttes alkalmazása
Ezekhez először egy-egy extra adatcsatornát hoztunk létre a szerver modulból, amihez hozzákötöttük a plusz paramétereket, mint pl. a kamera helyzete és a számított egyenesek irányvektorai. A szkript létrehozta a megfelelő számú egyenest és 3D pontot, valamint egy NURBS labdát a markernek. Az egyenesekhez hozzákapcsolta a létrehozott 3D pontokat, oly módon, hogy egy pont mozgatásával a hozzá tartozó egyenes mindig a pont irányába tartson (ezt a pontot nevezzük el iránypontnak). A kívánt egyenesek megjelenítéséhez még annyit kellett megtennünk, hogy az adatcsatornákat a megfelelő objektumokhoz rendeljük; a marker pozícióját tehát a NURBS labdához, a kamerák helyzetét az egyenesek kezdőpontjához, míg az irányvektorokat az iránypontokhoz rendeltük. A szkript által tehát gombnyomásra megjeleníthetjük a Motion Capture szerverünk által számított egyeneseket (kameránként az adott markerek irányában) – amiből rögtön látszik, ha rossz a kalkuláció (nem tükrözik a valóságot, pl. széttartóak). A markerlabdának is meg kell találnia az egzakt helyét; ott, ahol az egyenesek közti távolság páronként a legkisebb – ez is rögtön kitűnik az ábrázolásból. A szkript alapján a 3D modult addig javítgattuk, amíg meg nem született a várt, pontos eredmény.
- 81 5.8.3. Motion Capture felvétel készítésének módja
A Motion Capture szerver által közvetített mozgásokat a Mayában Motion Capture Device-ok segítségével használhatjuk fel. A Motion Capture Device mintavételezi és rögzíti a mozgást, és mindezt valós időben teszi.
Az eszközt a Motion Capture szerver elindítása után egy szkript parancs kiadásával definiálhatjuk. Ezzel a kapcsolat a két számítógép között létre is jön. Megjegyzés: egyszerre több ilyen eszközt is definiálhatunk, melyek különböző forrásból kaphatják az adatokat – például összetettebb felvételek esetén, amin egyidejűleg több szerver is dolgozhat. A Motion Capture folyamatot a Maya Device Editor-ából tudjuk vezérelni (46. ábra) Az ablak felső részében látható az eszközválasztó, amely azokat a Motion Capture Device-okat jeleníti meg, amiket az előzőleg ismertetett módszerrel
definiáltunk. Egy eszköznek itt láthatjuk a struktúráját (hogy milyen csatornákkal rendelkezik), és hogy a csatornákon érkező adatok mihez vannak kapcsolva. Az ábrán látható, hogy esetünkben van egy „TransMotion” eszköz, és ennek annyi csatornája, ahány markerrel dolgozunk. Minden csatorna alatt – hierarchiailag még egy szinttel – megtalálhatóak az X, Y, Z tengelyek, melyek az adott marker 3D-s pozíciójára vonatkoznak; pontosan úgy, ahogyan ezt a szerver modulban definiáltuk. Egy tengelyt kiválasztva a mapping fül alatt megadhatjuk, hogy az mely objektum milyen tulajdonságához legyen kötve (pl. pozíció, orientáció, stb.). Itt az értékeket tetszőlegesen
skálázhatjuk,
illetve
el
is
tolhatjuk. Esetünkben az objektumok egy csontváz csuklópontjai, amik a hozzárendelt 3D-s karaktert mozgatják; tulajdonságai pedig az X, Y, Z pozíciók. Ezek az összeköttetések írják le tehát, hogyan kapcsolódik a Motion
46. ábra - Device Editor
Capture eszközünk a Maya attribútumaihoz.
Miután beállítottuk az eszközünket – úgy, hogy azt például egy csontvázhoz rendeltük hozzá – a szerkesztőablakban máris láthatjuk, hogy a virtuális 3D-s karakterünk felveszi az élő színészünk mozgását. Előfordulhat, hogy a mozgás kissé
- 82 zajos – a markereknek megfelelő pontok remegnek – vagy épp akadozó/darabos a
Motion Capture számítások nagy erőforrásigénye miatt. Ezeket a nem kívánt hatásokat szűrőkkel és interpolációs eljárásokkal korrigálhatjuk. Szűrőként egy euler filter áll
rendelkezésünkre, valamint több interpolálási mód közül a Gauss-t használjuk – ezeket hozzáadhatjuk a Device Editor filters füle alatt. Mindezek után, ha a szerkesztőablakban látott mozgás megfelelőnek bizonyul, a felvételt a Device Editor / Controls panelen indíthatjuk el (Take File), ami az adott kimeneti fáljba másodpercben megadott hosszúságú mozgást rögzít. A mentést bármikor visszatölthetjük, és a mozgást tetszőleges 3D-s karakterhez rendelhetjük. 5.8.4. Továbbfejlesztési lehetőségek Komplex felvételek: Motion Capture felvételeknél igen jelentős szerepet játszik
az, hogy hány kamerával dolgozunk. Több kamera hozzáadásával nemcsak a mozgás pontosságát javíthatjuk, hanem a markerek kitakarásának esélyét is nagymértékben
csökkenthetjük. Jelenlegi programunk maximum 3 kamerával dolgozik megfelelő gyorsasággal. Bár ez a későbbiekben nagy eséllyel javulni fog, a komplexebb, több karakteres felvételekhez egy rendszer valószínűleg nem lesz elegendő. Erre a problémára megoldást kínál, ha egyszerre több számítógépre bízzuk a feladatot, melyek egyenként mondjuk 3-4 kamerát kezelnek. Megtehetjük, hogy a
rendszereket (mivel azok hálózaton küldik az adatokat) a Mayán belül kapcsoljuk össze. Mindössze annyi a dolgunk, hogy több Motion Capture Device-ot hozunk létre
egymás mellett, amiket a megfelelő szerverekhez kapcsolunk. Például feloszthatjuk úgy a feladatot, hogy egy-egy karakter mozgását külön-külön számítógépek digitalizálják. Ily módon a felvételek komplexitása valóban tetszőleges mértékig növelhetővé válik. 3D modellezés kézzel: a Motion Capture technológiára alapozva más, egyelőre
szokatlannak tűnő megoldásokat is építhetünk; mint például a kézzel történő modellezés. Az összetettebb 3D-s testek elkészítése hagyományos módon egérrel és
billentyűzettel végezve egy nehézkes szerkesztői folyamat. A viszonylagos nehézség az igen kis szabadsági fokot biztosító beviteli eszközök használatából adódik – az egér csupán egyetlen kétdimenziós pont mozgatására ad lehetőséget (precízebb módon
ugyan). A pontok és a dimenziók közt történő folyamatos váltogatás tehát jelentősen visszaveti a modellezés hatékonyságát. Képzeljünk el egy olyan beviteli eszközt,
- 83 amellyel a testeket szabad kézzel alakíthatjuk, mintha csak egy gyurmatömböt formálnánk, vagy épp egy ceruzát, amivel térben rajzolhatunk. A Maya tetszőlegesen programozható felületéhez könnyen írhatunk olyan MEL szkripteket, amellyel ez a fajta modellezési folyamat elérhetővé válik. Konkrétan lehetőségünk van nem csak a 3D-s objektumok, hanem azok pontjainak mozgatására is a Motion Capture által - ily módon megoldható, hogy míg az egyik kezünkkel az objektumot tartjuk, a másikkal a pontjait formáljuk. Erre az izgalmas lehetőségre már tettünk is egy próbát. Az alábbi ábrán láthatjuk, ahogy három marker segítségével egy NURBS labdát formálunk (47. ábra).
47. ábra - 3D-s modellezés kézzel
5.9.
A 3D-s környezet kialakítása
5.9.1. A 3D-s karaktermodell
A mozgás megjelenítéséhez elsősorban egy avatárra van szükségünk. Ez egy háromdimenziós karakter-modell, amely a mozgásszínészünk mozgását fogja utánozni értelemszerűen így tetszőleges humanoid torzó lehet, amivel rögzíteni szeretnénk a felvételt. A 3. fejezetben leírtak alapján a modellünk többféle felülettípusból is kialakítható. Az ábrán látható alien figuránkhoz (48. ábra) Subdivision Surface-t használtunk, ami karaktermodellezéshez talán a legszerencsésebb választás. Először egy alien-t ábrázoló előlnézeti képet tettünk a szerkesztőablakba, ami alapján a 3D-s forma könnyebben megszerkeszthető. Az egész folyamat során elegendő volt csak a fél testet megszerkeszteni, amit aztán a fősíkra tükröztünk. Szokás szerint egy poligonális kockából indultunk ki, majd oldalainak felosztásával, pontjainak pozícionálásával először kialakítottuk a törzs közelítő alakját.
- 84 A fejet és a végtagokat ugyanezzel a technikával növesztettük ki a törzsből, végül a finomabb megmunkálást igénylő részeket
(pl. fej, bordák) a poligon további
részletezésével formáztuk meg. Ezzel elkészült a modell alacsony poligonszámú alakja, amit aztán Subdivision Surface-szé konvertáltunk. Az eredmény egy tökéletesen sima, egybefüggő felület lett, ami megfelelően részletes.
48. ábra - A karaktermodell készítésének állomásai
5.9.2. A 3D-s karakter csontvázának kialakítása
A következő lépésben ki kellett alakítanunk a csontvázat az elkészített modell formájának megfelelően. A csuklópontokat oldalnézetben, a medencecsonttól kiindulva a megfelelő helyekre illesztettük. A csontok hierarchikus rendszerében ez a kiindulási pont a legfelső szint – ha mozgatjuk, az egész csontváz eszerint mozog. Mivel modellünk szimmetrikus, elég volt csupán a csontváz egyik felét felépíteni, amit aztán tükröztünk. Az elkészült csontvázat aztán megfelelően paramétereztük - melyik csukló merre fordulhat, maximum milyen szögben állhat és milyen a nyugalmi állapota. Utolsó lépésként pedig a csontvázat a megfelelő beállításokkal hozzárendeltük a karakterhez, ami eztán már megfelelő módon felvette a beállított pozitúrákat.
- 85 -
49. ábra - A csontvázszerkezet
5.9.3. A karakter anyagának kialakítása
Ahhoz, hogy karakterünk élethűbbnek hasson, anyagmintát is kellett hozzá definiálnunk. Létrehoztunk egy anyagminta-gráfot, amit (matematikai, ill. fájlból betöltött képek felhasználásával) textúra-objektumokkal bővítettünk. A különböző textúrákat anyagunk több tulajdonságához is hozzárendeltük, úgymint alapszín, árnyékszín, érdesség és fénylés. Az így kialakult gráfot a 50. ábra szemlélteti.
- 86 -
50. ábra - Anyagminta gráf
Miután elkészültünk a karaktermodellel, hozzárendeltük a csontvázszerkezetet, ráhelyeztük a textúrákat, majd lerendereltük a végleges modellt (51. ábra). A teljes Motion Capture folyamat végén ennek valósághű mozgását láthatjuk majd. A modellnek környezetet egyelőre nem készítettünk.
51. ábra - Az elkészült karaktermodell
- 87 -
5.10. Tesztelés, az eredmények értékelése 5.10.1. A markerek
Egy sikeres felvétel készítéséhez fontos, hogy megfelelő markereket használjunk. Eleinte vásárolni akartunk kész markereket, ám az interneten nem találtunk olyan magyarországi forgalmazót, amely ilyesmit árulna. Külföldön léteznek olyan cégek, amelyek kínálatában a Motion Capture-höz szükséges kellékek széles választéka megtalálható, ám ezek rendkívül költséges megoldások, beszerzésük is nehézkes itthon, ráadásul külön markereket nem találtunk, csak egy összetettebb termékcsomag részeként. Ezért úgy döntöttünk, hogy magunk fogjuk elkészíteni a markereinket. Korábban megállapodtunk, hogy színes markereket alkalmazunk. Az elképzelés az volt, hogy vásárlunk jó fényvisszaverő képességű, minden irányból ugyanolyan színűnek látszó színes fóliákat, amiket kis méretű, könnyű és gömbölyű tárgyakra (pl. ping-pong labda) rögzítünk. Egy szaküzletben találtunk a követelményeknek megfelelő, speciális anyagú fóliákat, vásároltunk is négy különböző színűt (piros, fehér, sötétkék és sárga színben). Ezek olyan anyagból készültek, mint pl. amit a rendőrségi ruhákon is láthatunk, ahol szintén a nagyon jó fényvisszaverő képességük miatt alkalmazzák őket. Kipróbáltuk, hogy a kamerák hogyan látják ezeket a fóliákat: a tapasztalat az volt, hogy szórt fénynél valóban jó eredményt érhetünk el velük, ám ha direkt fényt kapnak, akkor hajlamosak a csillogásra, ilyenkor a képen csak fehér foltokat látunk. Ezután vásároltunk még hagyományos, matt színű fóliákat is (narancssárga, világoskék, világoszöld, sötétzöld, világos-rózsaszín, sötét-rózsaszín és kékeszöld színben). Bár ezek általános célú anyagból készültek (az áruk is nagyságrendekkel alacsonyabb), a próbák során – meglepő módon – mégis ezek adtak jobb eredményt. Matt színűknek köszönhetően nem csillogtak, a színük viszont ezeknek is jól látható volt a kamerák képén. Egyelőre nem döntöttük el, hogy melyik fóliákat alkalmazzuk, a későbbi (közel stúdió-körülmények közötti) tesztelés tapasztalataira bíztuk a választást. A markerek elkészítéséhez szintén szükséges ping-pong labdákból is beszereztünk egy tucatot, majd egy hajszárító segítségével rájuk olvasztottuk a fóliákat. Az elkészült markereket az 52. ábra mutatja be.
- 88 -
52. ábra - Az elkészített markerek
5.10.2. A kamera-kalibráció
A modulok közül elsőként a kalibrációs modul került tesztelhető állapotba, ezért ezzel kezdtük vizsgálódásunkat. A kamerák belső paramétereinek meghatározását a korábban már ismertetett módon, a CalibFilter segítségével végeztük. A kamerákat az asztalra helyezett minta körül forgatva a program összesen 20 képet gyűjtött, majd kiszámolta és fájlba mentette a belső paramétereket. A felismerés feltételeinek pontosabb megismerésével ekkor még nem foglalkoztunk. A külső paraméterek kiszámítása már nem volt ilyen egyszerű feladat. A CalibFilter használatánál még nyugodtan mozgathattuk a kamerákat, ám itt már a kamerák mozgástere korlátozott volt, mivel valahol rögzítenünk kellett őket. Három kamerát kellett úgy beállítani, hogy mindegyikük megtalálja a mintát, miközben azt nem mozdíthattuk el (hiszen a külső paraméterek meghatározásánál ez már alapvető követelmény). A mintafelismerés nagyon bizonytalanul működött, ezért szükségünk volt a mintafelismerést zavaró körülmények feltérképezésére. A kísérletek során az alábbi következtetésekre jutottunk: • Kezdeti
feltételezésünkkel
ellentétben
a
mintafelismerés
a
fényviszonyokra nem annyira érzékeny. Bár jó megvilágításnál
biztosabban működött, kevesebb fénynél is egészen jól használható maradt. • A problémát elsősorban a tévesen megtalált sarokpontok jelentették. Ha a kamerák képén valamilyen sötét rész volt látható, az gyakran meggátolta a mintafelismerést. A minta közelében lévő fekete billentyűzet például rengeteg tévesen érzékelt pontot eredményezett.
- 89 Minél több zavaró pont volt a képen, annál kevesebb piros jelölés jelent meg, ebből következtethettünk a tévesen felismert sarokpontok számára. • A mintafelismerés egyik alapvető követelménye tehát a jó háttér. Ha a képen a minta körül csak homogén fehér környezet látható, a felismerés jól működik. Ezek a tapasztalati tények vezettek a későbbiekben ismertetett tesztkörnyezetek kialakításához. 5.10.3. Az első tesztkörnyezet
Miután az összes különálló modul elért egy olyan fejlettségi fokot, hogy kipróbálhassuk működésüket, kialakítottunk egy tesztkörnyezetet, ahol kísérletezni kezdtünk. Tudtuk, hogy a fehér háttér és a zavaró objektumok minimalizálása nagyon fontos a kalibráció során, de a célnak megfelelő környezet nem állt rendelkezésünkre. Kezdetben nem is volt szükség egy komplett stúdióra, így egy kicsinyített stúdiót készítettünk (53. ábra).
53. ábra - Az első tesztkörnyezet
Egy számítógépház dobozának kivágtuk az egyik oldalát, majd belülről fehér A4es papírlapokkal kitapétáztuk, ezzel biztosítva a homogén hátteret. Ezután a kalibrációs mintát a doboz közepére helyeztük, a három kameránkat pedig a doboz tetejének három sarkára rögzítettük. Így a kamerák csak a mintát és annak fehér környezetét látták.
- 90 Mintaként egy 9*7 db, 3 cm oldalhosszúságú fekete-fehér négyzetből álló sakktáblát használtunk. A megfelelő megvilágításról egy asztali lámpa gondoskodott. Ilyen feltételek mellett a kalibráció nem okozott problémát. Eleinte három kamerával próbáltuk csak a rendszert, majd később további hárommal. Ennél több kamera nem állt rendelkezésünkre, de hat kamerával a rendszer működőképes volt, megcáfolva korábbi feltételezésünket, miszerint minden egyes kamera külön USB-gyökérhubot igényel. Ennek magyarázatára nem jöttünk rá, de valószínűleg az új kamerákra már nem igaz ez a feltételezés. Markerdetektálás: az egyik elkészült markerünket a minta fölé helyezve a
markerdetektálás hatékonyságát próbálgattuk. Egy marker esetén 95 %-ban sikerült jól megtalálni a marker helyét, a használt markerszíntől függően. A három kamerának jelentősen eltérő színei voltak, így fontos volt az adott marker színét mindegyikre külön beállítani. Viszont az egyes kameráknak más-más irányba tolódott el a színképe, és ez a driver-ükben történő állítgatás után is megmaradt. Az egyik kamerának kékes színei voltak, a másiknak pirosas, a harmadik viszonylag jó képet adott. Ezzel egy újabb akadályba futottunk: a kékes képen a kék színű markerünk felismerése sokkal bizonytalanabbá vált, mivel a program számos pontot érzékelt kéknek tévesen. A pirosas képű kamera esetén pedig a piros színű markerek felismerése okozott problémát. Nehéz volt tehát olyan markerszínt találnunk, ami mindegyik kamera képén nagy biztonsággal detektálható. A tapasztalatok alapján a markerdetektáló modul hatékonyságát a lehetőségekhez képest megfelelőnek minősítettük, a fejlődési lehetőséget jobb képességű kamerák alkalmazásában láttuk. A később beszerzett kamerák színhűsége már kiváló volt, így ezekkel meg is oldódott ez a probléma. Az első három kamerával 4-5 különböző színű markert tudtunk jó hatásfokkal felismerni, efölött már egymást zavarták a túl hasonló színek. Próbálkoztunk a színtartományok alsó és felső határértékének változtatásával, általában a színmintához képest ±10 bizonyult a legmegfelelőbb beállításnak. Alacsonyabb érték esetén kevés pontot talált meg a program, magasabb értéknél pedig már egymásba értek a színtartományok, túl sok tévesen detektált pont volt. A három újabb kamerával jelentősen növelni tudtuk a megkülönböztethető markerek számát. Egy üres papírlapra helyeztünk az összes fóliából egy kis darabot, az
- 91 így készült palettán a program a meglévő 11 markerszínünkből a fehér kivételével mindet képes volt felismerni (54. ábra). A fehér értelemszerűen a papír és a környezet színe miatt nem működött. Több színnel egyelőre nem próbálkoztunk.
54. ábra – A megtalált markerek
3D-s pozíció számítás: miután már használható 2D-s pozíciókat tudtunk
számolni, elkezdtük a 3D modul tesztelését. A számítások eredményét hálózati kapcsolaton átküldve láthattuk a Mayában a markerek számított pozícióját. Kezdetben ez nem tükrözte a valóságot, számos hibára derült fény. Ezek azonban csak apró javításokat igényeltek, a megoldás alapelvén nem kellett változtatnunk. A könnyebb tesztelhetőség érdekében a Mayában egy segéd-szkriptet használtunk, amivel nemcsak a markerek pozícióját, hanem a kamerák helyzetét és a 3D-s számításhoz használt egyeneseket is láthattuk. Így tudtuk tesztelni az egyenesek metszéspontját számoló kódrészletet is. Hamarosan eljutottunk oda, hogy az ábrázolt pontok mozgása már hasonlított a valósághoz. Ezután több pont mozgatásával próbálkoztunk, ezek egymáshoz viszonyított helyzete is valósághű volt. A 3D-s karaktermodellhez egyelőre még nem rendeltük hozzá a kapott koordinátákat. 5.10.4. A második tesztkörnyezet
A 3D-számítások tesztelése során első tesztkörnyezetnek használt kis méretű dobozt a fejlesztés során a projekt lassan ’kinőtte’. Miután a 3D-számító modul helyes működése a próbák során bebizonyosodott és tetszőleges számú kamerával is leteszteltük, szükségünk lett egy nagyobb, stúdiókörülményeket biztosító helyre.
- 92 Egy fehér falú szoba sarkát bevilágítottuk több fehér fényű lámpával, a kalibrációs mintát pedig a falra rögzítettük. A kamerákat (összesen hat darabot) a minta körül helyeztük el félkörívben, a lehető legmesszebb és jól szétszórva, 2-3 méter távolságban. A kalibráció során kiderült, hogy a különböző kamerák bizonyos esetekben a sakktábla-minta más-más pontját veszik origónak. Ennek felderítésére a Mayában megjelenítettük a kamerák feltételezett pozícióit, amiből jól látszott, hogy azok mennyire felelnek meg, vagy mondanak ellent a valóságnak. Jelenleg a kalibrációs minta átellenes oldalain lévő kamerák – ugyanazt a képet látva – nem megfelelően ismerik fel abszolút helyzetüket. Ezen a problémán lehet segíteni, ha a kalibrációs modult átírjuk, és a mintát kiegészítjük olyan elemekkel, amik alapján már egyértelműen meg lehet határozni, éppen melyik oldalról látszik. A kalibráció során az eddigi mintát (9*7 db 3 cm-es négyzet) nagy nehézségek árán, más-más fényviszonyokkal és több szögből sem tudtuk megtaláltatni a kamerákkal. Arra következtettünk, hogy a minta túl kicsi a 320*240 felbontáshoz, ezért nyomtattunk egy nagyobbat (6*4 db 6 cm-es négyzet), amit két lapból illesztettünk össze. A nyomtatás minőségét is javítottuk 600 dpi-re, így egy sokkal sötétebb színű, kontrasztosabb mintát kaptunk. Erre már minden helyzetből gyors és sikeres lett a kalibráció, a tesztet folytathattuk. Az elkészített gömb alakú markerekből hármat a projekt egyik tagjának vállára, könyökére és csuklójára rögzítettünk. A látott markerszíneket hozzárendeltük a különböző kamerákhoz. A markerdetektálás hatékonysága sajnos nem minden esetben volt megfelelően eredményes, a mindössze 3-4-féle szín mindegyike bizonytalanul remegett; ekkor ugyanis igen kevés számú képpont felelt meg a markerszíneknek. A fények megfelelő beállításaival rengeteget javult az eredmény, akár 10 különböző pontot is nagy magabiztossággal kezelt a rendszer. A megtalált markerpozíciók mozgásán érzékelhető volt egy, a kamera zajából fakadó enyhe remegés. Bebizonyosodott megkülönböztethető
tehát színek
a
megvilágítás
számára
illetve
a
magas
fokú
pontosságra,
befolyása
tehát
a
a
felvétel
összminőségére nézve. A tesztből szintén kiderült, hogy ha a markerek a kameráktól távolra kerülnek, szintén csökkenhet a találat esélye. Ezt a problémát magasabb kamerakép-felbontással javíthatjuk, amellyel viszont nagymértékben csökken a markerdetektálás sebessége.
- 93 A markerekről tesztelés közben készült fényképek alapján remekül kitűnik, ahogyan a fényvisszaverő anyagból készült fóliák erős fény (a vaku) hatására élénk homogén színnel látszanak (52. ábra). Akkor kapnánk a lehető legmegfelelőbb felvételt, ha minden kamera pozíciójában egy erős fényforrás is lenne.
55. ábra – Az élő szereplő és a karaktermodell csontváza
A teszt során készítettünk egy felvételt, amin a mozgásszínész karjának mozgását rögzítettük. A 55. ábra jobboldalán látható a szervergép képernyője, baloldalt pedig a kliensgép által megjelenített kép, jelen esetben a modell csontváza. A mozgást rögzítettük, a csukló mozgásának tengelyenkénti görbéi az alábbi ábrán láthatók (56. ábra). A felvételhez az utófeldolgozás is hozzátartozott, melynek során a pontok 1-2% át jelentő nyilvánvalóan hibás részeket korrigáltuk.
56. ábra – A mozgásgörbe
- 94 5.10.5. Teszteredmények
A tesztek során számszerű méréseket végeztünk a kamerakezelő modul sebességégét illetően. A méréseket 1-6 kamerával végeztük, de a rendszerhez folyamatosan hat kamera volt csatlakoztatva. Először csak a kamerák képét kértük le, ezekkel semmilyen műveletet nem végeztünk, a megjelenítésüket is kikapcsoltuk. Vizsgáltuk a processzorhasználatot (57. ábra), illetve az FPS-t (5. táblázat). Utóbbit másodpercenként mértük - összesen tízszer, majd ezeket az értékeket átlagoltuk. Ha a kamerák képét meg is jelenítettük, akkor az FPS érték nem változott, így a táblázatban ez külön nem szerepel. Végeztünk méréseket úgy is, hogy mindegyik kamera képén három markert megkerestünk, ez nagyon kis mértékben változtatta az FPS-t. kamerák száma csak kamerakezelés markerkereséssel
1
28,7 FPS
28,5 FPS
2
23,6 FPS
23,7 FPS
3
18,3 FPS
18,0 FPS
4
12,1 FPS
12,5 FPS
5
10,4 FPS
10,7 FPS
6
9,1 FPS
9,2 FPS
5. táblázat - Teszteredmények
A processzorhasználatot a Windows Task Manager programjával vizsgáltuk. A kamerákat kis szüneteket hagyva egyesével bekapcsoltuk. Látható, hogy mindegy egyes kamera növelte a processzorhasználatot (57. ábra). Az ábrán egy vízszintes beosztás tíz százalékot jelent, a függőleges fehér vonalak pedig a kamerák bekapcsolásának idejét jelzik.
57. ábra - A processzorhasználat
- 95 Ha a rendszert teljes funkcionalitásával működtettük – tehát az eddigieken felül be volt kapcsolva a 3D-számító, és a hálózatkezelő modul is – a tesztértékek gyakorlatilag nem változtak kimutathatóan. A teszteket egy AMD Athlon64 3000+ processzoros, 1 GB memóriával felszerelt számítógépen végeztük Windows XP operációs rendszer alatt. A kamerák az alaplapra illetve egy USB-kártyára voltak csatlakoztatva. A programot Release módban futtattuk. 5.10.6. Az eredmények értékelése
A tesztek alapján látható, ahogy a rendszer teljes funkcionalitásával működik, valós-idejű 3D-s mozgásfelvétel készítésére képes. A további fejlesztések csupán az egyes modulok kiterjesztésére vonatkozólag indokoltak; úgymint a kalibrációs lehetőségek kiszélesítése tetszőleges kamerapozíciókra, kameraképek lekérésének sebességnövelése háromtól több kamera esetén, valamint a markerdetektálás zajmentesítése.
5.11. Továbbfejlesztési lehetőségek Az egyes modulok leírásánál már ismertettük azok továbbfejlesztési lehetőségeit, de ezen kívül is vannak terveink a jövőre nézve. A program kellőképpen rugalmas és könnyen kibővíthető, így további funkciók hozzáadása, illetve a rendszer egyéb célokra való felhasználása is lehetséges. • Tervünk
például
a
számítógép
kézzel
történő
vezérlésének
megvalósítása, ami egy izgalmas, lehetőségekkel teli, jelenleg kiaknázatlan terület. Ennek egy speciális formája lehet a korábban már említett 3D-s modellezés megvalósítása. • A Motion Capture technológia bár már most is komoly szereplője a játékiparnak, 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én, ami a játékélményt soha nem látott szintre emelhetné. • Felmerült továbbá egy saját kódra épülő kalibrációs program készítése is, ami az OpenCV C és C++ kódja helyett modern C# nyelven készülne, speciálisan a projekt igényeit kielégítve.
- 96 -
5.12. Összefoglalás A projekt célja egy olyan rendszer készítése volt, amely képes az emberi mozgás digitalizálására és megjelenítésére. Kezdeti célkitűzéseink között szerepelt a valósidejű feldolgozás lehetőségének biztosítása, illetve a költség-hatékonyságot is szem előtt tartottuk. Időközben felmerült az igény a rendszer univerzális kialakítására is. Kijelenthetjük, hogy a rendszer képes a kitűzött feladat elvégzésére. A kamerák képéből kinyert információ alapján kiszámolt 3D-s koordináták segítségével élethűen mozgatni tudunk egy 3D-s karaktermodellt. Bár a feldolgozás sebessége hagy még kívánnivalót maga után, a folyamat mégis valósidőben zajlik. A továbbiakban pedig lehetőség adódik majd a felvétel utólagos feldolgozásával a sebesség növelésére is. A rendszer használatához elegendő néhány egyszerű webkamera és két közepes teljesítményű számítógép (a markerektől és egyéb kellékektől eltekintve), ilyen szempontból a megvalósítás valóban költség-hatékonynak tekinthető. A tetszőleges számú kamera és marker használatának lehetősége, a moduláris felépítés, illetve a könnyű kibővíthetőség a rendszert kellőképpen univerzálissá teszi. A működéséhez ugyan számos külső feltételnek kell egyszerre teljesülnie, a megfelelő stúdió-körülmények mellett azonban a rendszer összes modulja a célnak megfelelően működik. Mindazonáltal az egyes modulok hatékonyságán van még mit javítani, a jövőben ez határozza majd meg a fejlesztés fő irányvonalát.
5.13. Summary The aim of the project was to create a system to digitalize and visualize human motion. Our initial objectives were to assure the opportunity of real-time processing; respectively the low cost of the system was relevant. In the meantime we made efforts to make it universal. We can assert that the system is able to fulfill the set task. With the aid of the 3D coordinates, according to the information acquired from the image of the cameras, we can animate a 3D character-model realistic. Though the speed of processing is not optimal, it is still real-time. Hereafter we will be able to increase the speed postprocessing the record. To use our system, some simple webcams and to mainstream
- 97 performance computer is required only (aside from the markers and other accessories), so from this point of view the implementation is really low cost. The opportunity of using arbitrary number of cameras and markers, the modular structure and the ability to be improved make our system universal as required. Though many outer conditions must be suitable simultaneous, with adequate studio-circumstances all the modules are working satisfying. However the efficiency of the single modules is to be improved, in the future this will declare the main guideline of development.
5.14. Az elvégzett munka felosztása A dolgozat alapját képező rendszer, illetve maga a dolgozat három félév alatt készült háromfős projektmunka keretében, a feladatok felosztása a következőképpen alakult: • Kertész Tamás: a kamerák külső és belső kalibrációja (5.2), a markerek
3D-s
koordinátáinak
kiszámítása
(5.5),
a
dolgozat
szerkesztése, valamint a honlapunk tartalmi részének kialakítása. • Rieger Péter László: a markerkereső modul (5.4) elkészítése. • Szolyka Sándor: a kamerakezelés megvalósítása (5.3), a főprogram megtervezése (5.7), a képfeldolgozó modul továbbfejlesztése (5.4), a hálózati modul elkészítése (5.6), a Performance Animation környezet konfigurálása (5.8), a 3D-s környezet kialakítása (5.9), az ábrák készítése, illetve a honlap szerkesztése. Az irodalomkutatás és a tervezés (2, 3, 4) közös munkával készült. A többi, fel nem sorolt rész Kertész Tamás és Szolyka Sándor együttes munkája.
- 98 -
5.15. A projekt honlapja Projektünk természetesen az interneten is jelen van. Honlapunk – a modern, korszerű technológiák használatának jegyében – Macromedia Flash 8 programban készült. Nyomon követhető rajta a projekt élete, megtalálhatók rajta a fejlesztéssel kapcsolatos legfrissebb hírek, aktuális információk. Az összes fontosabb dokumentum (TDK dolgozat, előadások, munkanaplók, stb.) letöltésére is lehetőség van. Megtalálható a fejlesztők rövid bemutatása, illetve a projekt céljának megfogalmazása és a felhasznált szoftver- és hardvereszközök ismertetése is. Esetleges észrevételeit, visszajelzéseit vendégkönyvünkbe írhatja a látogató. Számlálónkon nyomon követhető az oldal látogatottsága is.
58. ábra - http://transmotion.no-ip.org
- 99 -
6. Irodalomjegyzék 6.1.
Felhasznált irodalom
[1]
A Pyros Pictures, Inc. honlapja. http://www.pyros.com Utolsó látogatás: 2006.05.14.
[2]
A Gyűrűk Ura mozifilm hivatalos honlapja. http://www.lordoftherings.net Utolsó látogatás: 2006.05.14.
[3]
A Brainfactor Entertainment KFT. honlapja. http://www.brainfactor.hu Utolsó látogatás: 2006.05.14.
[4]
Ruiz, K. Kísérleti Motion Capture rendszerek tervezése. http://www.rpi.edu/~ruiz/research/research2/krmkmocap.htm Utolsó látogatás: 2006.05.14..
[5]
Sturman, D. J. A Motion Capture rövid története. http://www.siggraph.org/education/materials/HyperGraph/animation/character_ani mation/motion_capture/history1.htm Utolsó látogatás: 2006.05.14.
[6]
Az Okino Computer Graphics honlapja. http://www.okino.com/conv/exp_bvh.htm Utolsó látogatás: 2006.05.14.
[7]
Master Motion projekt, Carnegie Mellon Egyetem. Marker elhelyezési útmutató. http://www.etc.cmu.edu/projects/mastermotion/Documents/markerPlacementGuid e.doc Utolsó látogatás: 2006.05.14.
[8]
MoCap labor a Washingtoni Egyetemen. http://grail.cs.washington.edu/mocap-lab/index.html Utolsó látogatás: 2006.05.14.
[9]
Lindequist, J. és Lönnblom, D. Motion Capture rendszer építése. http://www.msi.vxu.se/forskn/exarb/2004/04087.pdf Utolsó látogatás: 2006.05.14.
[10] Az Autodesk honlapja. http://www.autodesk.com/ Utolsó látogatás: 2006.05.14.
- 100 [11] Maya Unlimited v5.0 Documentation. CharacterSetup.pdf http://www.3dlinks.com/tutorials_maya.cfm Utolsó látogatás: 2005.10.06. [12] Maya Unlimited v5.0 Documentation. CharacterSetup.pdf – Skeletons http://www.3dlinks.com/tutorials_maya.cfm Utolsó látogatás: 2005.10.06. [13] Maya Unlimited v5.0 Documentation. SubDs.pdf, NURBS.pdf, Polygons.pdf http://www.3dlinks.com/tutorials_maya.cfm Utolsó látogatás: 2005.10.06. [14] Fej-modellező leckék. http://www.highend3d.com/maya/ Utolsó látogatás: 2005.05.12. [15] A Vicon Peak honlapja. http://www.vicon.com Utolsó látogatás: 2006.05.14. [16] Borghese, N. A. Sűrűn mozgó markerek követése. http://homes.dsi.unimi.it/~borghese/Research/LinesResearch/MotionCapture/Moti onCapture.html Utolsó látogatás: 2006.05.14. [17] OpenCV levelező lista. http://groups.yahoo.com/group/OpenCV/ Utolsó látogatás: 2006.05.14. [18] OpenCV letöltés. http://sourceforge.net/projects/opencvlibrary/ Utolsó látogatás: 2006.05.14. [19] OpenCV az Intel honlapján. http://www.intel.com/technology/computing/opencv/index.htm Utolsó látogatás: 2006.05.14. [20] Wikipédia, a szabad enciklopédia. Pinhole kamera-modell. http://en.wikipedia.org/wiki/Pinhole_camera Utolsó látogatás: 2006.05.14. [21] A Logitech honlapja. http://www.logitech.com Utolsó látogatás: 2006.05.14. [22] Vámossy Zoltán. Kamera kalibráció. http://ultra.obuda.kando.hu/~vamossy/Kepfeldolgozas/2kamera/KameraKalibracio 4.ppt Utolsó látogatás: 2006.05.14.
- 101 [23] Camera Calibration Tool. http://w3.impa.br/~pcezar/3dp/original/CVL_html/appPage/doc_calib.html Utolsó látogatás: 2006.05.14. [24] Camera Calibration Tool. Camera Model. http://w3.impa.br/~pcezar/3dp/original/CVL_html/appPage/cam_model.html Utolsó látogatás: 2006.05.14. [25] Microsoft Platform SDK. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ Utolsó látogatás: 2006.05.14. [26] Simon, D. A Kalman-szűrő. http://www.innovatia.com/software/papers/kalman.htm Utolsó látogatás: 2006.05.14. [27] Tech Systems. A Kalman-szűrő. http://www.techsystemsembedded.com/Kalman.html Utolsó látogatás: 2006.05.14. [28] Maya DevKit Documentation. Motion Capture API / Design Philosophy [29] Maya DevKit Documentation. Motion Capture API Guide
6.2.
Ajánlott irodalom
‘A legkiválóbb 3D-grafikai oldal’ (technikai szempontból). http://www.highend3d.com Utolsó látogatás: 2006.05.14. ’A legkiválóbb 3D-grafikai oldal’ (művészi szempontból). http://www.raph.com Utolsó látogatás: 2006.05.14.
- 102 -
7. 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://www.bmfnik.hu/iar/2005_2006/tm/ http://transmotion.no-ip.org/
