Egy érdekes dologról szeretnék most írni, ami nagyban befolyásolja a modellek megjelenítésének a sebességét. Ez a testháló megjelenítésének módjáról szól. 

Vegyünk a szemléletesség kedvéért egy sík rácsot, az egyszerűség kedvéért egy 10x10 négyzetet tartalmazó rácsot. Ennek a rácsnak a vertex sorainak és oszlopainka a száma 11 x 11 csúcs. Összesen így 121. Ezek rácsmezőnként 2 háromszögből épülnek fel, vagyis összesen, 200 háromszög. Ahhoz, hogy 1 háromszöget megjelenítsünk 3 csúcs koordinátájára van szükségünk, így 1 rácsmező kirajzolása 6 csúcsot jelent. Igen ám itt mondhatnád, hogy de ebből a hat csúcsból 2 megegyezik a két háromszög rajzolásakor. És valóban.

A videokártya alapvetően úgynevezett vertex indexek alapján rajzol ki háromszögeket, vagyis ténylegesen 4 csúcsot kell elküldenünk a kártya számára, de 6 index-et, hogy tudja melyik csúcsot melyik után kívánjuk érinteni. 

Ezek után beláthatjuk, hogy miután elküldtük az összes csúcsot (121) a videokártyának, azt követően az indexlistát is el kell küldenünk és ez bizony már 200x3 = 600 adat. Adatméretét tekintve amúgy az indexek mérete lényegesen kisebb (2-4 bájt) mint egy csúcs poziciójának adatmérete, ami általában (3x8) 24 bájt. (Ezért is jó az olyan model, ahol kevés csúcsból sok háromszög kerül megrajzolásra, hiszen a csúcsok adatmére csökken, a modell részletessége nő, az indexek mennyiségének terhére).

Na de a hardver fejlesztők nem az ellenségeink, ezért ők is gondolták, hogy ezt a 600 adatot (ami amúgy elenyésző méretű adat, de most tekintsük soknak), le lehetne csökkenteni, ha a videokártya, nem pusztán háromszögekből, hanem úgy nevezett "Strip"-ekből, szallagokból építkezne. Tehát egy háromszög szallagot fel lehet úgy építeni, hogy csak az első 3 csúcs indexére van szükségünk, és minden további index a szalag egy újabb háromszögének az ismeretlen csúcsúnak indexe. Így egy négyszög kirajzolásához már nem 6 csúcs indexére van szükségünk, hanem csak 4. És innentől kezdve minden újabb háromszög esetében +1 index. Tehát egy olyan szalag, ami ami 20 háromszögől áll, a kártya számára leírható 3+19 (vagyis háromszögek száma+2) index megadásával, az eredeti 60 helyett.

Önamgánaka háromszögek rajzolásának a strip csak az egyik formája, a normál háromszög rajzoláson túl. Az OpenGL régebben ismert még Quads (négyzögek), Quad Strip (négyszög szalag), Triangle Fun, stb. Ezeket geometriai primitíveknek nevezzük. (lásd az ábra).

Elviekben a fent leírt módon, ugye mód volna arra, hogy a 100x100-es rácsunkat, ami eddig 600 index volt, megrajzoltassuk, 202 (3+199) index adat elküldésével. Ez testvérek között is, 3x kevesebb adat mozgatását jelenti.

Igen ám, de figyeljük meg, hogy az elnevezés is és az elmélet is szalagokról beszél, magyarán egymást követő háromszögekről, amelyek ugyan azzal a logikával épülnek fel, ugyan azzal a körüljárási iránnyal ami a rajzolást illeti. Tehát ha a képzeletbeli rácsunkat akarjuk ilyen szalagokból felépíteni, akkor 10 szalagra lesz szükségünk, amely 3+19 adatot jelent szalagonként, vagyis összesen 220 index. mondhatnánk, hogy ez nem sokkal több mint a 202 index, viszont pontosan 10x annyi adatküldési utasítást jelent mintha az elméletünk szerinti legoptimálisabb módon rajzolnánk. Viszont még mindig lényegesen gyorsabb ez, mint 600 index egyidejű elküldése a kártyának és azok feldolgozása.

Csak érdekesség kép jegyzem meg, hogy az openGL fejlődésével a quads ás quadstrip használata elavult, viszont a modellező programok a mai napig a négyszöget tartják alap poligonnak.

Egy nagyon izgalmas témakör az, amibe most bele szeretnék kapni, néhány bejegyzés erejéig, nevezetesen az ütközés vizsgálat témaköre.

A számítógépes játékfejleszés terén az egyik talán legnehezebb, de egyben legnagyobb sikerélményt kínáló részterületek eggyik, amint két ütköző test a valóságot szimulálva hatást gyakorol egymásra, elfordul, pördül, pattan, csúszik vagy gurul.

A szimulációk során túlnyomórészt úgynevezett közelítő formákkal dolgozunk. Ennek az az egyszerű oka, hogy a valóságban létrejövő kölcsönhatások részletes, mindenre kiterjedő számolása hatalmas kapacitásokat emésztene fel. Nem volna lehetséges, hogy a valósidőben képesek legyünk feldolgozni minden információt, amely pillanatról pillanatra leírják a testek helyzetét, mozgását. Ebből kifolyólag, olyan befoglaló testekkel zárjuk körül az adott objektumot, amelynek vizsgálata lényegesen kevesebb erőforrást igényel.

Ha egy egyszerűbb formájú hétköznapi test, például egy labda mozgását, kölcsönhatásait szeretnénk megjeleníteni, kézenfekvő dolog, ha közelítő testként (vagyis olyan formaként, amely leginkább pontosan veszi körül az objektumunkat) egy gömböt választunk. A labda esetében ez egy nagyon pontos körülhatárolást jelent.

Tehát adott egy gömb, mint befoglaló forma, amelynek a térbeli elhelyezkedésén kívül egyetlen inforációval leírhatjuk a kiterjedését, ez pedig a sugár. 

Ha nagyon egszerűen tekintjük - ez esetben - az ütközés vizsgálat mibenlétét, akkor azt mondhatjuk, hogy két labda akkor ütközik össze, ha kettejük középpontjának a távolsága kisebb vagy egyenlő mint a két labda sugarának az összege. Remélem nem hangzott túl bonyolúltan, mert a továbbiakban ettől csak lényegesen bonyolultabb esetek fognak következni.

Ha viszont egy faláda ütközését szeretnénk vizsgálni, akkor a legkézenfekvőbb befoglaló forma a téglatest, vagy ahogy programozás során leginkább nevezzük doboz (Box). Itt már bonyolódik az ütközés vizsgálat számítása és saját véleményem szerint, a doboz a legegyszerű konvex forma (a gömb után), amelyet vizsgálni fogunk, de a legbonyolúltabb primitív befoglaló test.

Itt hirtelen két fogalmat meg is kell magyaráznom. A konvex és konkáv formák fogalmát. Nézzük először a hivatalos megfoglamazását a konvex testnek: nem homorú (síkidom, mértani test, alakzat, ponthalmaz), amelynek jellemzője, hogy a rajta áthaladó bármely egyenes csak kétszer metszi a felületeit.
Vagyis ha húzni akarunk egy olyan egyenest, amely áthalad a testen, az csak két ponton fog áthaladni a körvonalon. A primitív testek ütközés vizsgálatakor, mindig ilyen konvex alakzatokat vizsgálunk.

A konkáv formák ebből eredően már sejthető, hogy a fenti megfogalmazás jelentésének ellentéte, vagyis égészen pontosan: a konkáv sokszögnek mindig van egy homorú belső szöge. 

A továbbiakban csak konvex formákkal fogunk foglalkozni, leszámítva a testhálók és magasságtérképek ütközés vizsgálatát. Ez utóbbiak lehetnek konkáv formák és ezek vizsgálata ebből adódóan eltér a konek testekétől.

A jövőben kitárgyalni kívánt egyszerűbb térbeli ütközőési formákat, ütköző primitíveknek fogom nevezni. A teljesség igénye nélkül egy rövid felsorolás ezekről: gömb, téglatest (doboz), henger, kapszula, gúla, csonkagúla.

Az összetettebb formák lesznek: a konvex burok, a testháló és a domborzati felszín.

Egy fejlesztő kolléga oldalán azt olvastam, hogy az ütközésvizsgálat elvégzéséhez a számításoknak és az adatszerkezetek felhasználásának villámgyorsnak kell lennie, így nem célszerű Java, vagy Pyton közvetlen használata erre a célra. A kolléga a C++ favorizálta, de mindenkit meg tudok nyugtatni, hogy a Delphi, Object Pascal vagy leszármazottjai épp úgy alkalmasak a feladat elvégzésére. Sőt! Én, mint Delphi rajongó hiszem, hogy Windows platformon ez a legjobb választás minden szempontól.

Ezzel együtt teljesen igaz, hogy az ütközésvizsgálatnak minden lépésében a lehető leggyorsabbnak kell lennie, hogy a megfelelő számítások elvégzése után használató eredményt kapjunk.

Sokat töprengtem azon, hogy a játékfejlesztés kapcsán van e létjogosultsága  mind annak, amit én meg tudok fogalmazni, illetve, hogy a 21. században egyáltalán van e értelme leírni ezeket.

Hogy miért merült fel bennem a kétely és hogy mire jutottam?

Manapság, amikor gyakorlatilag mindent úgy képzelünk el, hogy néhány kattintást követően automatikusan létrejön mind az, amit szeretnénk látni, hallani, megteremteni, sokan gondolhatják úgy, hogy bizonyos ismeretek már feleslegessé válták, hiszen az újabbnál újabb szoftverek és alkalmazások mindent elvégeznek helyettünk.

És igen, egyfelől azt kell mondjam, hogy aki gyors eredményekre vágyik, már régóta léteznek azok az eszközök, amelyekkel hamar célt érhetünk és amelyek jól elfedik a mögöttes munkát, tartalmat és időt energiát takarítanak meg a számunkra.

Sőt a mesterséges intelligencia megszületésével és elterjedésével lassan már csak álmodnunk kell és a gépek, a programok megvalósítják az álmainkat. Vagy mégsem?

Én jómagam a régi iskolák növendéke és rajongója vagyok, hiszem azt, hogy a fentiek ellenére - vagy éppen a használatukhoz - szükség van egy jól megalapozott tudásra, hogy valódi alkotóvá, ne csak használójává váljunk a technikának. Azt gondolom, hogy a 21. század rákfenéje, hogy mindent azonnal és gyorsan akarunk létrehozni, a cél mindent szentesít és nem fontos, hogy amit megteremtünk, valóban a mi tudásunkból, belőlünk születik e, vagy csak kommersz felhasználók maradunk.

Minden esetre, aki gyorsan és hatékonyan szeretne játékot létrehozni, annak a lehetőségek tárházát kínálják, a különböző stúdiók és engine-ek. Például, ha van megfelelő erőforrás hozzá az Unreal engine olyan lehetőséget nyújt, amit a magamfajta alkotó, soha nem fog tudni utolérni! 

Amit viszont nem lehet megspórolni egyetlen szoftver esetében sem, az a "játékszabályok" megismerése és megtanulása. Igen, mivel minden rendszer így a játékkészítő eszközök működésének is megvannak a maga szabályai. Biztos vagyok benne, hogy bármilyen környezetet is válasszunk az valamilyen programozási nyelvet használ, amelyben nélkülözhetetlen bizonyos dolgok kódolása, még ha csak "copy-paste" módszerrel is, de szükséges valamilyen kód létrehozása és futtatása. (Bár ha egy MI-nek diktáljuk az igényeinket, még ez a lépés is elhagyható :) ).

Az ebben a blog-ban található cikkek elsősorban azoknak szólnak, aki megszeretnék ismerni és érteni a dolgok okait, miértjét és hogyanjait. Ez időigényes és embert próbáló feladat. Aki úgy érzi, nem szeretné ilyenfajta ismeretekkel fárasztani magát, az talán jobban teszi, ha az idejét konkrétan valamilyen fejlesztésre fordítja és belecsap a sűrűjébe, menet közben úgy is megtanúlja, amit kell.

Mielőtt bárki úgy gondolná, hogy fog egy könnyen használható fejlesztő eszközt, összeszedi a netről a szükséges "asset"-eket és össze dob egy profi kis játékot, azt el kell hogy szomorítsam. Sajnos ez nem lesz ennyire egyszerű!

A játékfejlesztés általában nem egy egyszemélyes kaland. Túlnyomórészt több, nélkülözhetetlen területre bontható a munka, amelynek eredménye és összessége ként megszületik a nagy mű.

Általában milyen alapvető területekről is van szó?

Mivel valamilyen látvány világot szeretnénk megteremteni, így nélkülözhetetlen egy grafikában jártas kolléga. A játék-grafikusok munkája is további számos területre bontható fel. A teljesség igénye nélkül felsorolok néhány "szakterületet" és részfeladatot:

• Concept Art és Design: Először is, a játékterv kidolgozása, karakterek, környezetek, tárgyak és egyéb grafikák előzetes tervezése. Ez magában foglalhatja a karakterek és világok megjelenésének koncepcionális tervezését, színek, formák és hangulatok vizsgálatát.

• Sprite Grafika: A játékban használt karakterek, objektumok és hátterek készítése. Ezek lehetnek 2D-s képek vagy animációk, amelyek különféle méreteket és felbontásokat vehetnek fel a játékbeli használat céljából.

• UI (User Interface) Grafika: A felhasználói felület tervezése és grafikáinak készítése, mint például menük, gombok, ikonok, stb. Fontos szempont a használhatóság és az esztétika.

• Effektek és Animációk: 2D-s effektek, mint például robbanások, varázslatok, füst, vagy animációk készítése karakterek és tárgyak mozgatásához vagy interakcióhoz.

• Tileset és Background Design: A játék háttérképeinek és térképek részeinek tervezése, amelyeket tileset-ekként használnak a játék területeinek létrehozásához.

• Font és Tipográfia: A játékban használt betűtípusok és szövegek tervezése és implementálása.

• Cutscene Grafika: Egyes játékokban előre elkészített képek vagy animációk jelennek meg a történetmesélés során, ezeket a képeket, videókat, vagy animációkat kell elkészíteni.

• Optimalizálás és Textúrázás: A grafikusoknak érdemes az optimalizálásra is figyelniük, hogy a játékban használt textúrák és grafikák megfelelő méretűek és formátumúak legyenek a hatékonyság érdekében.

Természetesen egy garázs-projekt keretében valószínüleg nincs lehetőség ennyi féle területet, külön személynek betöltenie, de nem árt ha legalább egy csapattag ért a grafika elkészítéséhez.

Aztán nem árt az sem ha valamilyen hang hatásokkal rendelkezik a készítendő játék, egy komoly fejlesztés során ennek is több alterületéről beszélhetünk (szintén a teljesség igénye nélkül):

• Hangtervezés (Sound Design): Ez az a terület, amely magában foglalja a hangok létrehozását és összeállítását a játékban. Ide tartoznak a karakterek hangjai, különböző tárgyak vagy események hanghatásai, környezeti hangok és zenei elemek.

• Zeneszerzés és Zenei Hangtervezés: Az eredeti zenék és zenei hanghatások létrehozása és beállítása a játék különböző részeihez. Ez magában foglalja a hangulatnak megfelelő zenék készítését a játékhoz, hangulatos zenei aláfestést biztosítva a játékmenethez és az egyes jelenetekhez.

• Hangszerelés és Hangmix: A különböző hangok, effektek és zenék keverése és egyensúlyozása, hogy megfelelően illeszkedjenek a játékmenethez és a játék atmoszférájához. A dinamikus hangok és zenék beállítása is ide tartozik, hogy a játék élménye még inkább befolyásolja a játékost.

• Hangimplementáció és Technikai Munka: A hangok implementálása a játékba, a motorok és keretrendszerek használata, illetve a hangfájlok formátumának és méretének optimalizálása, hogy megfeleljenek a játék követelményeinek és korlátainak.

• Hangmotorok és API-k használata: A hangmotorok és audio API-k (Application Programming Interface - Alkalmazásprogramozási Felület) használata, mint például az FMOD vagy Wwise, amelyek lehetővé teszik a különböző hangok és effektek interaktív kezelését és vezérlését a játékban.

• Hangminőség és Hangélmény: A hangmérnökök és hangdizájnerek felelőssége a hangminőség biztosítása és a játékhangok által nyújtott élmény javítása.

Szintén egy olyan terület, ahol egy garázs-projekt keretében sem nélkülözhetetlen legalább egy zenei vénával megáldott csapattárs jelenléte.

Következzen a személyes kedvenc területeim egyike a 3D megjelenítés világának részfeladatai madártávlatból:

• Modellkészítés és Animáció: A karakterek, tárgyak, környezetek és más objektumok 3D modellezése. Ezek lehetnek statikus modellek vagy animáltak, amelyek mozognak és interaktálnak a játékosokkal vagy a környezettel.

• Textúrázás: A 3D modellek felületének textúrákkal való ellátása, hogy részletesebb, valósághűbb és életszerűbb hatást érjenek el. Textúrák alkalmazása például a textúrakészítés, textúramapák alkalmazása és UV-mapping lehetőségek révén történik.

• Fényeffektek és Shader-ek: A megfelelő fények, árnyékok és effektek létrehozása a játék világában. Ebben a kategóriában találhatók az effektek, mint például a víz, tűz, füst, vagy a különböző fényjátékok és árnyékok létrehozása, valamint a shader-ek használata a látvány javítása érdekében.

• Környezet és Térképek: A játék világának tervezése és megalkotása, beleértve a térképek, pályák és környezetek kialakítását, amelyek később a játékosok felfedezésére és felfedezésre várnak.

• Effektek és Animációk: Az animációk készítése és implementálása a karakterekhez és tárgyakhoz, beleértve a mozgásokat, harci mozdulatokat, interakciókat stb.

• Optimalizálás és Teljesítmény: A grafikusoknak figyelmet kell fordítaniuk a játék grafikai teljesítményére, hogy a 3D modellek, textúrák és effektek megfelelően vannak optimalizálva a megjelenítéshez, anélkül, hogy túlzott terhelést jelentenének a hardvernek.

• Motorok és API-k használata: A grafikusok gyakran dolgoznak különböző grafikai motorokkal és API-kkal (pl. Unity, Unreal Engine), amelyek segítik a 3D grafikai tartalmak kezelését és integrálását a játékba.

Itt az utolsó pontban a motorok és API-k használtát is ide soroltam, hiszen számos modellező szoftver alapvetően kínál lehetőséget a játékfejlesztésre is. 

Ennek ellentmondani látszik a személyes jelenlétem, mivel mint szoftverfejlesztő-programozó határozom meg magamat a fejleszőcsapatban. Ennek megfelelően nézzük, hogy a hagyományos játékszoftervejlesztés, milyen területekre terjed ki, egy programozó esetében:

• Játékprogramozás: Ez a terület magában foglalja a játék logikájának és működésének kódolását. Ide tartozik a játék belső mechanizmusainak fejlesztése, például a karaktervezérlés, mesterséges intelligencia, fizika, ütközésdetekció, játékmenet stb.

• Grafikus Programozás: A grafikus motorok, API-k és keretrendszerek használata a 2D és 3D grafika létrehozásához és megjelenítéséhez a játékban. Ez magában foglalja a grafikus elemek integrálását, textúrázást, fényeffekteket, shader-ek használatát stb.

• Hang- és Zenei Programozás: A hangmotorok és audio API-k használata a hangok, zenék és hanghatások kezeléséhez a játékban. Ennek során hangok lejátszását, keverését, effektek alkalmazását stb. végzik el.

• UI és Felhasználói Élmény (UX) Programozás: A felhasználói felület (UI) tervezése és fejlesztése, beleértve a menürendszert, vezérlőket, animációkat és felhasználói interakciókat a játékban.

• Hálózati és Multiplayer Programozás: A multiplayer játékokhoz szükséges hálózati kommunikáció és kapcsolódások fejlesztése, az online játékélmény támogatása és a szerver-kliens architektúrák megvalósítása.

• Optimalizálás és Teljesítményprogramozás: A játék hatékony működésének biztosítása a hardveres erőforrások hatékony felhasználásával, az optimalizálás során a kód hatékonyságának növelése a jobb teljesítmény és gyorsabb futás érdekében.

• Tesztelés és Hibakeresés: A fejlesztőknek szükségük van tesztelési készségekre és hibakeresési képességekre a kódhibák, hibák és teljesítményproblémák felderítéséhez és javításához.

• Platformspecifikus Programozás: A játékokat különböző platformokra (PC, konzolok, mobil eszközök stb.) való megjelenéshez specifikus kódolási készségek szükségesek, hogy az alkalmazás mindenhol megfelelően működjön.

A fentiek tükrében fogom kibontani az egyes területekről az ismereteimet, és ezek mélységét is az iméntiek fényében értelmezzétek. Mivel mint látható a játékszofver fejlesztés programozói oldala, szintúgy széjjelágazó és én, mint egyszemélyes hadsereg próbálok megbirkózni a feladattal, így nem csoda talán, hogy mindenhez - ami feljebb említettem - értenem kell annyira, hogy közös nyelvet beszélhessek a csapattársakkal. Természetesen ez azt is jelenti, hogy egy egy területnek nem én vagyok a legnagyobb szakértője, de az alapokat mindenképp megpróbálom átadni a kedves olvasónak a továbbiakban.

A következőkben, ahogy az a címből is kiderül, a 3D animációk világába vezetlek el kedves olvasó. A játékfejlesztés során gyakran nélkülözhetetlen, hogy a 2D tartalmon túl a 3D térben is mozgó, változó megjelenésű objektumokat, animált mesh-eket jelenítsünk meg. (A mesh jelentése egy tébeli háló, amelynek rácspontjait csúcsoknak, vagyis vertex-eknek nevezzük). Az alábbiakban olykor olyan fogalmakat fogok használni, amelyek talán nem egyértelműek egy laikus számára, de igyekszek közérthető maradni.

Amikor egy jelentben, amely megjelenik a képernyőnkön valamilyen előre leírható mozgás sorozat játszódik le, akkor beszélhetünk 3D animációról. Az animációra jellemző - ahogy azt az imént is próbáltam érzékeltetni - hogy előre elkészített és valamilyen módon leképzett és tárolt, majd megjelenített formája van.

Ha elképzelünk egy játékos karaktert, amint az egy szobában mozog, a térbeli megjelenítését leíró csúcsok folyamatos mozgásban vannak. Ahhoz, hogy a játékos mozgása a szobában élethűnek tűnjön, nem elegendő természetesen a teljes modellt elforgatni, elmozgatni a térben. Ezzel együtt kell járjon a részletek elmozdulása is, vagyis például a testrészeinek összehangolt mozgására van szükség.

Most elsősorban az ilyen és hasonló animációkra fókuszáljunk, hiszen általában az élőlények mozgását a legkörülményesebb megjeleníteni. Alapvetően a mesh-ek vagy komplett modellek (a modellek nálam több, de legalább egy mesh jelenlétét feltételező csoport neve) mozgatását, valamilyen animáció szerint 3 módon tudjuk megoldani: 

1. Transform Mesh Animation - összefoglalóan így nevezhetjük el, amikor egy teljes mesh valamilyen előre meghatározott mozgási útvonalon halad és jelenik meg a képernyőn. A merev testek animációját általában ilyen módon célszerű leképezni majd megjeleníteni. Ilyen például a gépek, járművek mozgása, ahol nincsen szükség a testháló részletekben történő megváltoztatására. Egy repülőgép, vagy űrhajó mozgása során jó eséllyel semmilyen olyan jellegű deformitás nem történik, amelyet feltétlenül meg kellene mutatnunk. Ez az animáció típus a térben a mesh pozicióját, irányát és méretét  (skálázottságát) képes kezelni. A lejátszás kapcsán nem történik más, mint az egyes képkockák leírják ezeket az összetevőket (általában elegendő egyetlen 4x4 dimenziós matrix ezen adatok tárolásához). Éppen eből adódik az egyszerűsége és nagyszerűsége hiszen mindössze 64 bájton leht tárolni a mozgás egy-egy pillanatát és a legéletszerűbb mozgások is leírhatóak így a merev testek vonatkozásában. 10 mp, 30 FPS-el lejátszott animáció tárolása, mindössze ~19 KB adatot igényel.

2. Csont animáció - Ennek az animáció típusnak, ahogy az az elnevezéséből is gondolható, a különböző élőlények mozgásának leírásában van nagy szerepe. Úgy is felfoghatjuk, hogy az imén vázolt TM animációt alkalmazzuk egy merev csontvázra, amely valamilyen módon képes arra, hogy a rajta lévő bőrmozgását befolyásolja. Így már egy sokkal finomabb és részletesebb animációt kapunk. De hogyan? A csontanimáció jellemzője, hogy a rákerülő "skin", vagy is bőr, egyes területeinek mozgására van hatással, de csúcsonként változó mértékben. Ebből az következik, hogy bizonyos vertexek jobban, amíg mások kevésbé fogják követni egy adott csont mozgását. Azt hogy mekkora mértékben hat egy csont egy adott csúcsra, súlyozásnak, súlynak nevezzük. Képzeljük el a könyök hajlatunkban a bőr viselkedést. A térben az alkarunk egy nagy részére csak az alkar csontunk fejt ki hatást, a felkarunk ugyan így, viszont erre a kis területre egyidejüleg 2 csont van hatással, ezért nem mozdulhat csak az egyik, vagy csak a másik csont mozgásának megfelelően. Itt a bőrünk deformálódni fog, amikor behajlítjuk az alkarunkat, a bőr itt összetorlódik kissé, vagy épp megnyúlik. Ezt a csontanimáció során úgy érjük el, hogy a könyökhajlatot jelentő vertexekre egyforma arányban hasson a két csont (alkar-felkar) mozgása. Az ilyen és hasonló hatásokból keletkezik a csontanimáció működése a bőr deformitása és mozgatása. Ennek az animáció típusnak nagy előnye, hogy még mindig relative kevés memóriát igényel, hiszen csak a csontok adott pozícióját kell tárolnunk az animáció során, viszont a hátránya is ebből adódik, mert a bőr vertexeinek aktuális poziícióját a súlyok alapján, minden egyes képkocka lejátszásakor ki kell számolnunk.

3. Vertex animáció - Vagyis a csúcsok animációja. Az előző megoldást tovább gondolva megtehetjük, hogy nem számoljuk ki minden pillanatban újra és újra vertexek helyzetét, hanem eltároljuk azokat. Igen ám, de ahogy az elképzelhető, így az animáció tárolásához és lejátszásához szükséges memória mennyisége jelentősen megnő. Tehát a vertex animáció megjelenítése az egyik legegyszerűbb, ugyanakkor leginkább memória igényes megoldás. Egyszerű mert minden képkockában el van tárolva az aktuális állapota a mesh-nek, és nincs más dolgunk, csak az adott pillanatban megjelenítenünk azt. Memória igényes, mert ha egy mesh (például egy emberi test a játékban) 10 ezer darab csúcsból áll, az összes csúcsot aktuális pozícióját tárolnunk kell, ami azt fogja jelenteni, hogy egy 10 mp-es animció 30 FPS- sebességgel lejátszva 10 e (vertexek száma) * 12 (vertex adatméret) * 300 adat (30 FPS*10 mp), ami ~ 35 MB. Hogy most ez mennyire sok vagy kevés, mindenki döntse el maga, az biztos, hogy az eredeti TM animáció 19 KB méretéhez képes jelentős növekedés. Ennek a memóri fogyasztásnak a mérséklésére célszerű bevezetni a kulcs-képkockák foglamt (key frame), amely azt fogja jelenteni, hogy csak az adott, lényeges pillanatot tároljuk el, amelyből aztán a következő kulcskockáig a hiányzó képkockák már kiszámíthatóak. (Én általában minden 5. képkockát tekintek key frame-nek, és a köztes átmenetet úgynevezett interpolálással számítom ki, errő majd máskor bővebben írok). Így lényegesen csökkenthető a vertex animáció mérete, bár számolási igénye valamivel megnő, de minimálisan a csontanimációhoz képest.

Összefoglalva: Ha merev testek mozgását kell tárolnunk akkor ahhoz mindenképpen TM animációt célszerű használni, számításigénye kicsi, memória igénye kicsi. Ha élőlények részletes mozgásra van igényünk akkor midenképp célszerű a csontanimációban gondolkodni, bár számításigénye meglehetősen magas, de kevés memóriát igényel és szép végeredményt ad. Végül ha részletes mozgásra van szükségünk, pláne ha csontanimációval nem kivitelezhető (például egy zászló mozgása a szélben), akkor mindenképp vertex animációt kell használnunk. Számításigénye minimális, de meglehtősen sok memóriát igényel a tárolás miatt.