Az id Tech 4 videójáték-motort az id Software fejlesztette ki az 2004. augusztus 3-án kiadott Doom 3 videójátékhoz, amely az id Tech-sorozat negyedik része. Azóta számos más játékhoz is licencelték a John Carmack által kifejlesztett motort.
Célkitűzések
A Quake III Arena kiadása után, 1999 novemberében kezdett el Carmack ismét kutatással foglalkozni egy új 3D-s engine kifejlesztése érdekében. A viszonylag rövid fejlesztési idők miatt előző három játékuk esetében nem állt módjában minden alkalommal újból az alapoktól elindulni, és bár a kód nagy részét teljesen újraírta, az engine működési elve lényegében változatlan maradt. Kezdetben azonban mégis a Quake 3-ra támaszkodott és csak a grafikával foglalkozó részt cserélte le, így sokkal könnyebb dolga volt az első lépésnek megtételekor (ezalatt az id csapata dolgozhatott a Team Arenán). Ez tette lehetővé azt is, hogy Carmack kapásból több, különféle megközelítésre épülő teszt-motor megírásával foglalkozhasson és így a gyakorlatban legjobban működő technológiát választhassa. A kutatás másik fontos területe az emberi látás volt, ennek jellegzetességeit kiismerve lehetett meghatározni az új motorral kapcsolatos legfontosabb elvárásokat és irányelveket.[1]
Az első célkitűzés a megvilágítási rendszer egységesítése volt. Mostanában két fő eljárás állt rendelkezésre a 3D-s motorokban:
- Vertexalapú árnyalás: lehetővé tette a fényviszonyok változásának követését, viszont csak részletesebb modelleken mutatott jól. Így általában csak a játékokban szereplő karaktereken, szörnyeken és NPC-ken (Non-Player Character) használták, valamint a mozdítható tárgyakon, járműveken.
- Lightmap megoldás: egy második textúra minden egyes felülethez, amely a megvilágítottságot tartalmazza. Ezzel a módszerrel a vetett árnyékokat is meg lehetett jeleníteni, ugyanakkor a textúrákat valós időben frissíteni szinte lehetetlen feladat volt, hiszen ennek számítási igénye a jelenet komplexitásával arányosan növekszik. A legtöbb motor (így a Quake 3 is) tehát valamilyen hibrid megoldást használ: a pályák fényellátottságát lightmapekkel oldják meg, a karakterek és a tárgyak, pedig vertex alapú megvilágítást kapnak. A dinamikus fényforrások (reflektorok) és a karakterek vetett árnyékainak megjelenítéséhez viszont különféle trükkökre (például projektált textúrák) kell hagyatkozni, ami csúnyán lerontja a látvány egységességét.[1]
A második gond összefüggött a lightmapek használatával. Ezek leszámoltatása, valamint a motor sebességét jelentősen megnövelő láthatóság-információk eltárolása, ugyanis jelentős feldolgozási idővel járt. A Quake 3 egyes pályái 30-60 percnyi előkészítést is igényeltek az id 16 processzoros SGI szerverén – egyszerű PC-ken ez az idő napokban volt mérhető, ráadásul a folyamatosan gyorsuló 3D-s kártyák egyre összetettebb pályák megjelenítését tették lehetővé.
Carmack végül olyan megoldást dolgozott ki, amellyel egyszerre oldhatta meg mindkét kérdést. A Doom 3 motor legfontosabb újítása tehát az, hogy a megvilágítás szempontjából minden felület egyenrangú – a pálya minden eleme, az összes tárgy és karakter ugyanazokat az eljárásokat használja. Emellett az egész játéktér teljesen dinamikus, bármikor elmozdítható akár egy komplett fal vagy szoba is.[1]
Fények és árnyékok
A fényviszonyok megjelenítéséhez a Doom 3 stencil-es shadow volume-okat használ. Egy-egy ilyen idom lényegében az adott fényforrás árnyékában lévő terek összességét jelenti; nagyon egyszerű példával élve egy sík négyszög shadow volume-ja csonka gúla lesz. Ezeket az idomokat a motor valós időben képes létrehozni a jelenetben található tárgyakból, így a megvilágítás és az árnyékok teljesen valósághűek és szabadon változtathatóak.
A shadow volume-ok generálása azonban már elméletben sem egyszerű feladat: első lépésben a fényforrás szemszögéből nézve azonosítani kell az árnyékvető tárgyakat, és meg kell keresni azoknak a körvonalait. Ezeket a sziluetteket a térben a fényforrástól eltolva jönnek létre a shadow volume-ok. A gyors és megbízhatóan működő algoritmus kidolgozását tovább nehezítik olyan korlátozások, hogy például ez az idom nem nyúlhat a végtelenségbe; bár szerencsére minden fényforrás hatása elenyészik egy bizonyos távolságon túl. Az eljárás másik fontos jellemzője pedig az, hogy a tárgyak poligonszámával arányos a sebessége – tehát az elviselhető fpshez igen szűkmarkúan kell adagolni a poligonokat, és nincs lehetőség sem a Truform, sem a displacement mapping használatára. További hátrányt jelent az, hogy az árnyékok szélei mindig pengeélesek, ami egyáltalán nem valósághű. A lágy szélű árnyékokhoz tárgyanként 6-8 shadow volume-ot kellene számoltatni és ehhez bizony a mai videókártyák teljesítménye túlságosan kevés – bizony, van olyan feladat, amelyik még a GeForce 4-et is játszva két vállra fekteti.[1]
Pályák és ellenségek
A fények szempontjából minden tárgy egyen rangúnak számít, legyen az a pálya része, a játékos fegyverét markoló kéz, vagy az éppen szembejövő zombi. A vertex alapú árnyalás alkalmazását emiatt Carmack kezdettől fogva elvetette, és inkább a GeForce és Radeon-alapú videókártyákban bemutatkozó pixelenkénti árnyalással igen komolyan kezdett foglalkozni. Ezzel a módszerrel viszonylag alacsony poligonszámú tárgyak esetében is szép és látványos eredményeket tudott elérni, ráadásul lehetővé tette a bump mapping használatát. Itt jött az újabb zseniális megoldás Carmack-tól – a bumphoz szükséges normal map segítségével a shadow volume-ok miatt kényszerűen low poly modellek megjelenítését jelentősen fel lehet javítani. Ehhez minden egyes tárgynak és szörnynek el kell készíteni egy igen részletes, akár 5-6000 ezer poligon-ból (!) álló változatát, majd erről a részletes felületről mentették le az információkat egy textúrába.[1]
Az eredmény a gyakorlatban a várakozásnál is jobban néz ki, ugyanakkor van néhány hátránya is. Ezek közül a legnagyobb az, hogy a tárgyak körvonalai szögletesek maradnak, hisz a hasonló jellegű displacement mappinggel ellentétben ez a módszer nem növeli meg a geometria részletességét. A másik járulékos nehézséget pedig az jelenti, hogy minden tárgyat kétszer is el kell készíteni: egy minél optimálisabb low poly modellre, és egy nagyon részletes, igen sok munkaórát igénylő változatra is szükség van.[1]
Menetek
Carmack a GL Quake motor esetében is elsőként vállalkozott radikális lépés megtételére: az egész pályát kétszer számoltatta le a videokártyával, először a sima textúrák, másodszor a megvilágítást tartalmazó lightmapek használatát. Ezáltal lényegében dupla munkát kellett végeznie, bár idővel megjelentek a multitextúrázásra képes videókártyák (például a legendás Voodoo 2), amelyek esetében ez már nem járt teljesítménycsökkentéssel.[1]
A Doom 3 ismét bevállal egy fontos lépést, mivel napjaink sokkal fejlettebb hardverén is több menetben rajzolja ki a 3D-s jelenetet. Az egyes menetek tartalma a frame bufferben kerül összekombinálásra, ezek a számítások okoznak a 32 bites színmélység miatt minőségvesztést a mai videókártyákon. A motor az első menetben textúrák és fények nélkül számolja ki a sima poligonokat, valamint a tölti fel a Z-buffert – ennek tartalmát a további menetek már nem fogják felülírni. Ez az első kör viszonylag gyors, kevés memória-sávszélességet igényel a textúrák hiánya miatt. Ezután minden egyes fényforrásra megismétli a következő két menetet. Először kiszámítja a shadow volume-okat és a renderelés során a stencil buffer tartalmát megnövel azoknál a pixeleknél, amelyek árnyékba kerültek. Utána „ráfesti” a fény hatását a tárgyakra, de csak azokra a pixelekre, amelyeknél a stencil buffer értéke nulla. Ebben a menetben kerülnek fel a textúrák és a bump mapping is.[1]
A stenciles menet az egymást igen gyakran átfedő shadow volume-ok miatt igen sok poligonból állhat, amelyek nagy része ráadásul takarásban van. Ezért azután kifejezetten nagy szerep jut az optimalizálásoknak, a nem látható felületek kiiktatásának – bár lényegében az egész stenciles menet láthatatlan, hiszen a frame buffer tartalmát nem változtatja meg. A textúrák hiánya miatt ez sem igényel nagy sávszélességet, viszont nagymértékben fogyaszthatja a fill rate-et. Fordított a helyzet a "fényező" menetekkel, ahol ugyanis a motor pixelenként 6-7 textúrát igényel. Egy órajel alatt a legtöbb mai videókártya nem is képes végrehajtani ezt a menetet, mivel nem rendelkeznek a szükséges memória-sávszélességgel.
|
|
Ez a lap vagy szakasz tartalmában elavult, korszerűtlen, frissítésre szorul.
Frissítsd időszerű tartalommal, munkád végeztével pedig távolítsd el ezt a sablont! |
|
A fentiekből már sejthető, hogy a Doom 3-nak igen erős grafikus hardverre lesz szüksége: a minimum követelmény GeForce 1 vagy Radeon 1-es kártya, de ezeken a játék csak 640×480-as felbontásban és alaposan lebutított képminőséggel tud majd eldöcögni. Minden feature bekapcsolásához GeForce 3-ra lesz szükség, de ekkor is csak 800×600-as felbontás körül reménykedhetünk majd a 30 fpsben. Ezek az adatok elsőre nagyon ijesztőnek tűnhetnek, de ne feledjük, hogy a játék megjelenéséig még legalább egy év lehet hátra és addigra a GeForce 4 lesz a középkategória.[1]
Animáció és egyebek
A látványvilág ugrásszerű minőségjavulásának van még néhány igen fontos következménye. A valóság hűbb megjelenítésű 3D-s világban magasabb szintre kellett hozni a karakter animációt, a fizikát, vagy éppen a hangot is, különben könnyen lerombolhatnák a grafika által megteremtett illúziót.[1]
Ezek az új rendszerek azonban már nem Carmack munkái – ő ezúttal főleg a grafikára koncentrált. A teljes Dolby Digital 5.1-s surround hangzást produkáló hang motort Graeme Devine írta, az idnek ugyanis eltökélt szándéka ezen a téren is megemelni a PC-s játékok mércéjét. A játék fizikája is saját fejlesztés és a bemutatók alapján igen komolynak tűnt – például pár pisztolylövéssel odébb lehet lökdösni az apróbb tárgyakat. Az animációs rendszer is kibővült a „rongybaba”-fizikával: a lelőtt szörnyek mozgását a fizika törvényei vezérlik, így a hullák leeshetnek, legurulhatnak és remélhetőleg nem fognak belelógni a falakba sem.[1]
A motort használó játékok
Jegyzetek
Külső hivatkozások
