Előzetes: DirectX 9.0

A játékosok és játékfejlesztők valóságos megváltóként várták a DirectX 8.0 verzióját, amely a Microsoft által fejlesztett API (Application Programming Interface, alkalmazásprogramozási felület) történetében először tette lehetővé, hogy az addig fixen a grafikus chipbe huzalozott funkciókba a fejlesztők beavatkozzanak, a folyamatokat saját kényük-kedvük szerint alakítsák. Emlékezetes, hogy az első teljes DX8-gyorsítást kínáló videochip, az NVIDIA GeForce3 tavaly tavasszal jelent meg. A piaci premier óta csupán alig több, mint egy év telt el, és máris itt kopogtat az ajtón a DirectX legfrissebb verziója, a 9.0. Cikkünkben bepillantást engedünk ennek újdonságaiba, elsősorban a háromdimenziós grafikával kapcsolatos forradalmi megoldásokra koncentrálva.

Ebben a tekintetben a DirectX 9.0 legfontosabb újdonságai az alábbiak:

• Vertex Shader 2.0 és Pixel Shader 2.0
• 128 bites, lebegőpontos színábrázolás
• nagy pontosságú frame puffer mód
• több "leképezési célpont" (rendering target)
• displacement mapping és folyamatos tesszeláció

A DX8 kapcsán kerültek be először a köztudatba a shaderek. A shaderek (pixel shader, vertex shader) olyan programocskák, amelyek segítségével az alkalmazásfejlesztők leírhatják, mi történjen a három dimenziós világ objektumaival. Lássuk, miben hoz újat a DirectX 9.0-ban debütáló Vertex Shader 2.0 és Pixel Shader 2.0!

Mire képesek a DirectX verziók?

A háromdimenziós világ legkisebb építőegységei a vertexek. A vertex nem más, mint egy pont a térben, amelynek nemcsak x,y és z koordinátája van, hanem van normálvektora (a vertexben találkozó poligonok normáljainak eredője), textúrakoordinátái, szín- és fényességadatai is. Ezen felül tartozhat hozzá köd, meg még rengeteg adat. Annak ellenére, hogy a vertex a 3D-világ legkisebb építőeleme, nagyon sok adatot tárol.

A DirectX korábbi (értsd: 9.0 előtti) változataiban a vertex shader programok valójában nem voltak mások, mint rövid utasítássorozatok, a szó szoros értelmében vett programokról ebben az esetben nem beszélhetünk, ugyanis a specifikációk egyrészt csak rövid utasítássorozatokat engedtek, másrészt nem álltak rendelkezésre vezérlő utasítások, ciklusok, elágazások vagy szubrutinok. A DirectX 8.x esetében a vertex programok legfeljebb 128 utasítást tartalmazhatnak, a DX9 esetében pedig 1024-et.

Természetesen ez csupán egy elméleti érték, hiszen a ciklusok és szubrutinok miatt egy vertexen ennél lényegesen több utasítás is végrehajtható. Ráadásul ha a fejlesztő nem tudja 128 utasítással leírni az "akaratát", a vertex a program befejeződése után ismét bekerülhet a vertex shaderbe. Természetesen minél hosszabb a program, annál több idő kell a végrehajtásához.

Látható, hogy a DX9 sokkal nagyobb szabadságot enged a fejlesztőknek, bonyolultabb, ugyanakkor látványosabb effektusokat hozhatnak létre, ugyanakkor a munkájuk egyszerűbbé is válik: a Vertex Shader 2.0 lehetőséget ad arra, hogy egy programozó ciklusok és szubrutinok felhasználásával egy teljes megvilágítási modellt írjon meg, amely tetszőleges számú, színű, helyzetű és irányú fényforrást kezel. A Vertex Shader 2.0 új utasításokat is tartalmaz (pl. szinusz, koszinusz, hatványozás), amely egyszerűsíti a programok írását és bonyolult effektek (pl. folyadékok mozgása) valós idejű létrehozását teszi lehetővé.

[oldal:Pixel Shader 2.0]

A DirectX 8 megjelenésekor a programozók el voltak ragadtatva a Vertex Shader "nyelvtől", azonban a Pixel Shadert számos kritika érte, sokak szerint nem volt igazán hatékony, amolyan "félmegoldásnak" tartották. A Pixel Shader 2.0 számos tekintetben továbbfejlődött és méltán tarthat számot a fejlesztők elismerésére.

A Pixel Shader korábbi változatainak legfőbb hibájaként az egyszerre kezelhető textúrák számának alacsony mivoltát, illetve a programok maximális hosszát tartották. Látható, hogy a DX9 Pixel Shader 2.0 mindkét tekintetben messze felülmúlja elődjét, hiszen az eddigi 6 textúra és legfeljebb 128 utasítás helyett eg menetben már akár 16 textúrát és 160 utasítást is fel lehet dolgozni. A cél természetesen itt is az volt, hogy minél komplexebb, a valóságot minél inkább megközelítő effektusokat lehessen létrehozni.

A 160 utasításos korlát első látásra nem tűnik nagy ugrásnak a 128-hoz képest, azonban a Vertex Shader 2.0-hoz hasonlóan a Pixel Shader 2.0-ban is lehetőség van elágazások, ciklusok és szubrutinok használatára, így bonyolultabb effektek is egyszerűbben írhatók le, mint korábban. A Vertex Shaderhez hasonlóan a Pixel Shader is képes több menetben dolgozni, azaz egy pixelt egymás után akár több program is formálhat, alakíthat. Így gyakorlatilag végtelen számú utasítás hajtható végre a pixeleken. A Pixel Shader 2.0 is bővült új utasításokkal, például gyökvonással.

Bizonyára minden olvasónk tudja, hogy a számítógépes grafikában az egyes képpontok színeit a három alapszín (vörös, zöld, kék) árnyalataiból keverik össze. Jelenleg a 32 bites színábrázolás a legelterjedtebb, ami azt jelenti, hogy egy képpont színét egy 32 bites egész szám írja le. Gyakorlott fejszámolók és a kettes számrendszert ismerők most valószínűleg rávágják, hogy ez 2³², azaz közel 4,3 milliárd különféle árnyalatot jelent.

Sajnos ez nem ilyen egyszerű, ugyanis 32 bites színábrázolás esetén az egyes alapszínek árnyalataira csupán 8-8 bit jut, 8 biten pedig az ún. alpha csatornát ábrázolják, ez mutatja meg, hogy az adott pixel mennyire átlátszó, áttetsző. Látható, hogy 8 bites ábrázolás esetén egy alapszín legfeljebb 2⁸=256 különféle árnyalatot vehet fel és összesen 2^3x8, azaz 16,8 millió szín ábrázolható. A 32 bites színábrázolásnak azonban nem ez a legnagyobb rákfenéje, hanem az, hogy az értékeket egész számokkal írják le.

Képzeljünk el egy bonyolult shader programot, amelynek futása során egy adott pixel színét összeadással, kivonással, szorzással, osztással, hatványozással és gyökvonással határozzák meg. Egész számok esetében az osztás és gyökvonás gyakran tört végeredményhez vezet, azonban mivel a színek komponenseit fixpontos formátumban ábrázolják, kerekítést alkalmaznak. Emiatt egy bonyolultabb pixel program végére már jelentős lehet a kerekítésekből adódó pontatlanság. A DX9 ezt úgy kerüli meg, hogy lehetőséget ad 64 vagy akár 128 bites lebegőpontos ábrázolásra is.

Balra 32 bites fixpontos színábrázolás, jobbra 128 bites lebegőpontos

128 bites lebegőpontos ábrázolás esetén a színkomponensek ábrázolása a következőképp történik: x = m*2^e , ahol x az adott színkomponens értéke, m egy 23 biten ábrázolt mantissza, e pedig egy 8 biten (7 bit+1 bit előjel) ábrázolt kitevő. Ezzel 2^-128 (0,00000000000000000000000000000000000000294) és 2¹²⁷ (170,000,000,000,000,000,000,000,000,000,000,000,000) között gyakorlatilag tetszőleges számot lehet leírni. Ráadásul mivel törtek ábrázolására is léhetőség van, igazából nincs szükség kerekítésre és feldolgozás közben nem veszik el értékes színinformáció. Természetesen 128 bites lebegőpontos ábrázolás esetén a felhasznált memória-sávszélesség drámaian, négyszeresére növekedik.

Fentebb már írtuk, hogy 32 bites színábrázolás esetén a vörös, zöld és kék alapszíneknek 256 különféle árnyalata áll rendelkezésre a megjelenítéshez, ami az emberi szem érzékenységét figyelembe véve elegendőnek mondható. Azonban csak 256 különböző árnyalat áll rendelkezésre a fényesség leírásához, vagyis a vaksötét és a vakítóan világos fény között csupán 254 átmenet létezik, ennél az emberi szem nagyságrendekkel többet képes megkülönböztetni. Az erősen változó fényességű jelenetek a számítógépen ezért alulexponáltnak vagy túlexponáltnak, azaz túl sötétnek vagy túl világosnak tűnnek. A DX9 lehetővé teszi egy 32 bites nagy pontosságú frame puffer mód használatát, amelynek segítségével négyszer több fényességértéket lehet ábrázolni, így sokkal természetesebbnek tűnő látvány hozható létre.

A pixel shader korábbi változatai egyszerre csak egyetlen egy színértéket tudtak magukból kiadni, a DX9 pixel shaderek ezzel szemben akár négyet. Ez számos területen hasznosítható, például valós időben lehet egy három dimenziós jelenteten szűrést vagy utómunkát végezni.

Valós idejű élszűrés a Pixel Shader 2.0 több renderelési célpont funkciójával

[oldal:Displacement mapping]

A DirectX 8-ban vezették be először az ún. N-patch felületeket, amelyek révén az alacsony részletességű, darabos objektumokat részletesebbé, gömbölyűbbé, természetesebbé lehetett tenni. Az N-Patchelést (Normal Patch) mind a DirectX 8, mind az OpenGL támogatja. Az eljárás lényegében a három dimenziós objektumokat alkotó háromszögeket az oldalak osztásával több kisebb háromszögre bontja fel. Az eredeti objektumot alkotó háromszög csúcspontjainak normálisa az adott csúcspontban találkozó háromszögek normálisainak eredője. Ez alapján megállapítható, hogy az a háromszög egy ív része volt-e, és ha igen, az ív hogyan görbült. Az N-Patchelés után létrehozott új háromszögeket ezen ív mentén már térben rendezi a videochip, ezzel részletesebb és finomabb objektumot hozva létre.

A DX9 természetesen itt is továbbmegy egy lépéssel: az ún. displacement mapping révén a háromszögek felbontása, darabolása és mozgatása nem geometriai egyenletek alapján történik, hanem egy textúra alapján, ez a textúra a displacement map. A technológiát elsőként a Matrox alkalmazta a Parhelia chipben, és bekerült a DirectX 9.0-ba is. A displacement mapping lényegében hasonlít a bump mappingre, azonban a bump mapping esetében csak a felület normálvektora módosul annak érdekében, hogy az másképp verje vissza a fényt, így becsapja a nézőt, aki azt hiszi, érdes felületet lát, holott valójában a felület továbbra is sík.

A fenti képen látható, hogy míg DOT3 bump mapping használatával a gumi éle továbbra is egyenes marad, displacement mapping esetén már a kontúrja a futófelület barázdáihoz igazodva változik, mivel a displacement mapping magát a test geometriáját változtatja meg. A folyamatos tesszeláció azt jelenti, hogy az N-patchelt, illetve displace mappelt felületek valós időben a grafikus chipen számítódnak ki, és folyamatos az átmenet a részletes, illetve kevésbé részletes modellek között. Például ha megközelítünk egy objektumot, az először még csak kevés háromszögből áll, nem túl részletes, azonban mire közel érünk hozzá, minden apró részlet láthatóvá válik, a tárgy részletes, és finoman ívelt. A displacement mapping technológia nagy előnye, hogy segítségével alacsony poligonszámú modellek és kis méretű textúrák segítségével igen bonyolult felületek hozhatók létre, ráadásul valós időben, hardveres gyorsítással.

Azt hiszem, rövid írásunkból kiderül, a fejlesztők miért is várják annyira a DirectX 9.0-t. Számos esetben egyszerűsödik a munkájuk, miközben a korábbiaknál lényegesen hatékonyabb eszközöket kapnak a kezükbe, amikkel bonyolult, részletes és valósághű effektusokat képesek programozni -- a felhasználók legnagyobb örömére. Bár a DX9 végleges változata csak októberben jelenik meg, egy videochip máris van a piacon, amely teljes körűen támogatja azt, ez pedig az ATI Radeon 9700. Aki azonban máris rohanna a boltba, annak el kell mondjuk, hogy a jövő év eleje előtt szinte biztosan nem jelenik meg olyan játék, amely DirectX 9.0-ra épül. Az őszi hónapokban az ATI Radeon 9700 mellett újabb versenyző lép majd a piacra, az egyelőre NV30 néven ismert NVIDIA chip, véleményünk szerint ha valaki DX9 gyorsítót szeretne vásárolni, mindenképp várja meg, mivel jelentkezik piacvezető kaliforniai cég.

Szólj hozzá a fórumban!