Betekintés a VGA-jövőbe

A most következő cikk szerzője Abu85 aki talán a legjobb "GPU" szakíró kis hazánkban. Írása 2008-ban jelent meg először, de aktualitásából szinte semmit sem vesztett így célszerű elolvasnia mindenkinek akit csak kicsit is érdekel a számítógépes grafika fejlődése.

[Prohardver] A jelenkort meglehetősen komoly kompatibilitási problémák és általános szétszórtság jellemzi. Az új DirectX 10 API – elődjeivel ellentétben – nem tudta egyértelműen kijelölni a grafikai fejlődés zavartalan ösvényét. Az interfész alkalmazását az esetek többségében gazdasági szempontok ellenzik, melynek gyökerei kifejezetten a PC-s játékipar helyzetére vezethetőek vissza. A reformok kora című cikkben részleteztük a Microsoft új API-jának forradalmi újításait. Röviden összefoglalva a DirectX 10 legfontosabb előnye, hogy az egyszerűsített alapok mellett a programok fejlesztése is könnyebbé válhat. Problémát vet fel azonban, hogy egy multiplatform játék a konzolokon nagyságrendekkel magasabb eladásokat produkál. Ennek köszönhető, hogy a fejlesztők nagy többsége az aktuális projekt konzolos változatára koncentrál. A program PC-s verziója jobb esetben egy igényes konzolport lesz. A rosszabb esetet pedig nem érdemes részletezni.

A Xenos kompatibilis tesszellátor

A fenti bekezdésből már kitalálható, hogy a PC-s játékok grafikai fejlődését inkább a konzolok képességei fogják meghatározni a közeljövőben. Ez persze messze nem azt jelenti, hogy a DirectX 10 és a 10.1-es API egyes újításait senki sem fogja használni, viszont a költségek kímélése érdekében a többség nem fog élni ezzel a lehetőséggel. Innentől kezdve érdemes a Microsoft Xbox 360 és a Sony PlayStation 3 képességeinek az irányából vizsgálni a PC jövőjét. A Sony rendszere eléggé kötetlen lehetőségeket teremt hat darab, egyéni igényeknek megfelelően felhasználható SPE magjának köszönhetően. A fejlesztők képzeletének csak a teljesítmény szab határt. Meglehetősen nehéz megmondani, hogy a programozók a PlayStation 3 exkluzív programoknál milyen csapásokon közlekednek majd, de alapvetően ez a PC szempontjából szerencsénkre teljesen irreleváns.Az Xbox 360-nak viszont sokkal kötöttebb lehetőségeket rejt a hardvere, ami előrevetíti a fejlesztők lehetőségeit a használható eljárások tekintetében. A Microsoft gépének egyik adu ásza az Xenos nevű grafikus processzorban megbúvó, úgynevezett programozható tesszellátor. Ez az egység az első lépésben az eredeti modell poligonjait kisebbekre bontja fel, majd a Displacement Map segítségével pozicionálja a vertexeket. A programozható megnevezés is innen ered, a vertexek helyét egyénileg lehet definiálni. Maga az egység azonban a beégetett, fix funkciós algoritmusok alapján bontja fel a felületet. A tesszelláció maximum tizenötszörös lehet. Ez azt jelent, hogy egy tetszőleges modellt az eredeti állapothoz képest tizenötször lehet tesszellálni. Példával szemléltetve a dolgot, az egyik legegyszerűbb beépített algoritmus segítségével egy háromszög alakú patchet fel lehet bontani úgy, hogy oldalainak felezőpontjait összekötjük. Ennek köszönhetően máris négy háromszög keletkezett. A Xenos GPU ezt a folyamatot tizenötször tudja egymás után végrehajtani. Könnyen ki lehet találni, hogy ez az egység számtalan erőforrást szabadít fel az Xbox 360 központi processzoráról és memóriájáról, mivel a rendszer erőforrásait az alacsony részletességű modell terheli. Emellett a fejlesztés is könnyebb, hiszen elég az alacsony részletességű tárgyakat elkészíteni, amit a tesszellátor majd a megfelelő minőségi szintre javít.Multiplatform fejlesztés esetén nagy valószínűséggel az Xbox 360 képességeinek feleltetik majd meg a játékot a programozók, így a tesszellációs egység használata reális fejlődési irányt sejtet. A PlayStation 3 sem probléma, mert befoghatók az SPE magok tesszellálni, vagy el is készíthetők a magas poligonszámú modellek. A PC helyzete már közel sem ilyen rózsás. Ha a projekthez csak alacsony poligonszámú modellek készültek, akkor pusztán a PC-s port végett nem fognak annyi erőforrást befektetni, amennyi szükséges a jobban kidolgozott tárgyak használatáért, ellenben a Radeon HD2000/HD3000/HD4000-es széria rendelkezik Xenos-kompatibilis tesszellátorral, így azok használata lehetséges.

A DirectX 11 kompatibilis tesszellátor

A szélesebb látókör kedvéért rögtön az elején érdemes tisztázni, hogy a Xenosban és a DirectX 11-ben használt tesszellátor nem kompatibilis egymással. A Xenos tesszellátora logikai szinten rögtön az Input Assembler mögött helyezkedik el. A rendszer használatához direkten kell címezni az egységet. A PC-n is hasonlóan kell majd eljárni a megfelelő eredmény elérése érdekében, mivel csak az AMD rendelkezik kompatibilis kártyákkal, így nem szükségesek egyéni rutinok az optimalizált működéshez. A DirectX 11-ben viszont egy masszívan felépített struktúra kapott helyett. Ez a rendszer három, szorosan összefüggő logikai szintre osztható: Hull Shader, Tesszellátor, Domain Shader. A Hull Shader szintjére érkeznek meg a feldolgozásra váró adatok. Itt lesz beállítva a testekre vonatkozó tesszellálás mértéke, illetve kijelölésre kerül az előre beépített módok közül a fejlesztő által kiválasztott algoritmus. Ezután az adatok patchként lesznek továbbítva a fix funkciós tesszellátorba.

A patchek tulajdonképpen vertex tömbök, amiket az adott objektum geometriai vázának szétszeletelésével lehet előállítani. Nagyon fontos azonban, hogy ezek nem jelentenek szükségszerűen poligonokat. Egy példával élve három vertex képezhet egy olyan a térbeli alakzatot is, ami tulajdonképpen két szakasz. Ezeket is tökéletesen lehet tesszellálni. A Hull Shader ezen kívül minden patchhez megjelöl egy kontroll pontot, amely a Domain Shader szakaszban kerül majd felhasználásra. A második szinten a tesszellátor elvégzi az utasításoknak megfelelően a feladatát, és az úgynevezett területi pontokat a harmadik szintre irányítja, amiből a Domain Shader a displacement map, a kontrollpont és a tesszellációs mérték segítségével kialakítja a végleges felületet.

A DirectX 11 tesszellátora egy tökéletes kiterjesztése a Xenosban helyet foglaló egységnek. Minden változtatás csak az előnyére vált, emellett a tesszelláció maximális mértéke már akár hatvannégyszeres is lehet. Megjegyzendő azonban, hogy hagyományos értelemben még mindig nem programozható a rendszer, így a fejlesztők nem kapták meg az egyénileg definiált tesszellációs algoritmusok kreálásának a lehetőségét.

A DirectX 11 újításai

Az elmúlt verziókban elképesztő mértékű fejlődésen ment keresztül a Shader Modell szabvány és a HLSL (High Level Shader Language) programnyelv. Az 5.0-ás verzió nem igazán bővíti tovább a lehetőségeket, hiszen a mérce már amúgy is igen magasra lett tolva. Ellenben egyszerűsíti a programozók feladatát, hiszen objektumorientált lett a nyelv. Ez a változás a felhasználóknak jelentéktelennek tűnhet, de érdemes belegondolni, micsoda előrelépés a fejlesztőknek. A mai programok rengeteg eltérő kódot alkalmaznak az adott fényhatást figyelembe véve a különböző paramétereknek megfeleltethető felületekre (legyen az virtuális fém, műanyag, fa, üveg vagy szövet). A szekvenciális alapokon nyugvó, korábbi verziójú HLSL nyelvekben ezeket a fény-anyag kölcsönhatásokat kétféleképpen kódolhatták le a programozók. Az egyik megoldás, hogy a grafikus motor összes lehetséges árnyalási metódusára egy külön shader programot kell futtatni. A mai, korszerű grafikát kezelő rendszerek mellett azonban ez nagyon sok kis programot eredményez, hiszen tucatnyi megkülönböztethető felület létezik, emellett az eltérő fényhatásokból is bőven akad.

Shader Modell 5.0

A fentebb említett öt, anyagokra vonatkozó példa három fénytípussal kiegészítve (például: körsugárzó, pont és direkt) rögtön 15 darab programot generál, ami már elég ahhoz, hogy az esetleges hibák kereséséhez és javításához aránytalanul magas időigény járuljon. Arról sem szabad megfeledkezni, hogy shader programok folyamatos generálása a hardver szempontjából is időbe telik. Ennek elkerülésére alkalmazták eddig a fejlesztők az übershadernek gúnyolt programokat, mint alternatív megoldást. A helyzet azonban alig átláthatóbb, mivel egy shader programba kell az összes kódot írni, nem kevés feltételes elágazás használatával. Az objektumorientáltság azonban jelentősen egyszerűsíti a fejlesztők dolgát, hiszen a programegységeket egy előre megtervezett hierarchiának feleltethetik meg. Interfészként megadható a felület és a fényhatás, melyben a tagfüggvények, azok tulajdonságai és bemenő paraméterei találhatók. Az osztályok pedig a függvényeket és a változókat tartalmazzák. Ennek megfelelően a hibakeresésre fordított idő jelentősen redukálódhat.

Textúratömörítés

Két új textúratömörítési eljárás került az új API-ba. Ennek nagy jelentősége van a mai programok mellett, hiszen a nagyfelbontású textúrák komoly helyigénnyel rendelkeznek a memóriára nézve. Ezen kívül a DirectX 11 már megköveteli a hardveres kitömörítést is az összes támogatott formátumra. A BC6 (Block Compression) a HDR (High Dynamic Range) alkalmazása mellett használható. Ilyen esetekben ugyanis a fejlesztők sokszor alkalmaznak Tone mapet a kép színátviteli görbéjének állítása miatt. A BC6 6:1 arányban tömöríti a képkocka HDR adatait, ami némi veszteséggel jár ugyan, de a végső eredmény rendkívül meggyőző.

BC6 textúratömörítés a gyakorlatban

A BC7 az úgynevezett LDR (Low Dynamic Range) formátumú textúrák alkalmazása mellett lehet alternatíva. Nagyon jó képminőséget eredményez az eljárás 3:1-es RGB (vörös, zöld, kék), illetve 4:1-es RGBA (vörös, zöld, kék, átlátszóság) tömörítési arány mellett. A fenti két textúratömörítési eljárást lehetőség van a driver szintjén emulálni, így a támogatás kiterjeszthető a DirectX 10-es hardverekre is. Természetesen a hardveres kitömörítés itt nem lesz alkalmazható, így a sebességre nézve negatívan ható felárat kell majd érte fizetni.

Többszálúság támogatása

Nem nevezhető meglepetésnek, hogy a DirectX API is rálépett a Multi-Threading, azaz a többszálú feldolgozás kissé döcögősen járható útjára. Szerény véleményem szerint ennek már hamarabb meg kellett volna történnie, hiszen meglehetősen problémás, hogy a piac legelterjedtebb grafikus API-ja a többmagos processzorok korában még mindig csak egy programszálon renderel. Az új API-ban az objektum megrajzolásához szükséges rajzolási parancs és az effektek létrehozásánál bekövetkező állapotváltások már több szálon lesznek kezelve. Ahhoz, hogy ez működésben megfelelően ki legyen használva, a Direct3D 11-es erőforrást az azonnali és a halasztott tartalom szintjére kell felosztani. Az azonnali tartalom egy programszálat takar, és olyan kész objektumokat tartalmaz, melyek sorrendben átadhatók a grafikus processzornak. A halasztott tartalom központi processzor által történő feldolgozása már több szálon történik. Minden egyes ilyen szál tartalmaz egy listát a saját objektumairól, így lesz ellenőrizve, hogy a számítás elvégzése megtörtént-e. Amint kész a feladat, a halasztott tartalom behívásra kerül az azonnali tartalomba. Jó hír, hogy a rendszer működése az API szintjén változott meg, így nem szükséges hardveres módosítás a problémamentes feldolgozáshoz. Ez azt jelenti, hogy a Windows Vista operációs rendszerben bemutatkozó WDDM (Windows Display Driver Model) és a megfelelően felépített eszközmeghajtók mellett bármelyik, minimum DirectX 10-kompatibilis grafikus kártyával használható az új feldolgozási elv. Azt persze érdemes megemlíteni, hogy a fő feldolgozási szál továbbra is túlterhelhető, tehát a tökéletes eredmény eléréséhez a fejlesztőnek is optimalizált eljárásokat kell alkalmaznia.
További változás még a DirectX 11-ben, hogy a maximum alkalmazható textúraméret akár 16384x16384 pixeles is lehet. Ezenkívül a Conservative oDepth eljárás segítségével akkor is lehet a Depth Bufferbe írni, ha az Early Z check és más, úgynevezett Z gyorsítási funkciók nincsenek kikapcsolva.

General-Purpose GPU és a fizika

Az NVIDIA és az AMD jó ideje tolja a grafikus processzoron történő általános számítási feladatok szekerét. Az egész elképzelés azon a tényen alapszik, hogy bizonyos, nagymértékben párhuzamosítható számítási feladatokban a központi processzorok teljesítménye messze le van maradva a grafikus processzorokéhoz képest. Mindkét nagy GPU-gyártó cég rendelkezik a termékeik képességeihez igazított programozási interfésszel. A zöldek ezt CUDA-nak, míg a vörösek Stream SDK-nak nevezték el. A fejlesztőknek viszont sokkal fontosabb lenne egy olyan szabványos GPGPU API, amelyet mindkét cég maximálisan támogat. Ezzel a lépéssel jelentősen megkönnyíthető lenne a grafikus processzoron futtatható programok fejlesztése, hiszen nem kell két eltérő interfészre megírni a projektet. Jelen állás szerint a feladat betöltésére két versenyző esélyes. Az egyik jelentkező a Khronos Group által fejlesztett OpenCL (Open Compute Language), míg a másik a DirectX 11-ben bemutatkozó Compute Shader technológia.
Az OpenCL elsősorban az APPLE támogatását élvezi, és várhatóan a legtöbb operációs rendszeren elérhető lesz. Az NVIDIA-val ellentétben az AMD nagyon szoros kapcsolatban van a fejlesztőkkel, ami vélhetőleg annak köszönhető, hogy a riválisaihoz képest előnyösebb pozíciót akar kiharcolni a platform irányelveinek meghatározása szempontjából.

NVIDIA Cuda

A Microsoft Compute Shader a DirectX 11 része lesz, így nem nehéz kitalálni, hogy csak a Windows rendszereket fogják támogatni. A fejlesztés a főbb gyártók bevonásával zajlik. A Redmondi óriáscég nagy reményeket fűz a technológiához; a fő cél elsősorban olyan programok létrehozása, ami a játék fizikájára, mesterséges intelligenciájára és a grafikai minőséget nagymértékben javító effektekre van kihegyezve.
A jelenleg is elérhető GPGPU interfészek közül a CUDA a legkidolgozottabb. Az AMD azonban az esetleges támogatásra nemet mondott a zöldeknek, így borítékolható, hogy a rendszer a jövőben a szükséges támogatás hiányában nem fogja felvenni a versenyt az általános API-kkal szemben. Megjegyzendő azonban, hogy ha a Santa Clara-i cégnek sikerülne valamelyik következő generációs konzolba egy GeForce GPU-t passzírozni, akkor az a CUDA helyzetét meglehetősen pozitív irányba befolyásolná.

Fizika a játékokban

Ezen a területen nagyon kényes a helyzet. Ha a fejlesztők előre megírt rendszert akarnak használni, akkor két lehetőségük van. Választhatják az NVIDIA Ageiatól megvásárolt PhysX technológiáját, vagy az Intel Havokot, amelyet az AMD is támogat. Mindkét rendszer kellően nagy támogatottsággal rendelkezik, és ami a legfontosabb, elérhetőek Xbox 360 és PlayStation 3 konzolra is. A PC-n meglátásom szerint a PhysX némi előnyre tett szert, bár ez viszonyítás kérdése, de a GPU-alapú gyorsítás lehetősége semmiképp sem elhanyagolható tényező. Az Ageia felvásárlása után egy általános zűrzavar alakult ki, az NVIDIA ugyanis nem igazán magyarázta el, mi kell ahhoz, hogy a program a grafikus processzort használja a fizikai számításhoz.
A PhysX technológiát kétféle licensznek feleltették meg a karrierje kezdetén. A különbség abban merült ki, hogy a teljes licenszhez olyan speciális, Novodex API kiterjesztések tartoztak, amelyek lehetővé tették a fizika számítását az Ageia PhysX P100 elnevezésű gyorsírókártyán. Az elkészült programokat ebből a szempontból tehát két részre lehet osztani. Az egyik hányad csak a központi processzort használta a feladatok kalkulálására, míg a többi termék a fizikai gyorsító processzor segítségét is igénybe vette, amennyiben a felhasználó rendelkezett a szükséges hardverrel. A CUDA-kompatibilis NVIDIA termékek jelenleg csak azokat a programokat képesek gyorsítani, amelyek a teljes licenszes NOVODEX API-t használták a számításokhoz. Az éppen készülő projektekkel már más a helyzet, a PhysX technológia régóta ingyenes, így az adott cég megújíthatja meglévő korlátozott licenszét teljes támogatásúra. Minden fejlesztőnek mérlegelnie kell, hogy érdemes-e az előbbi lépést megtenni. Jelent-e komoly változást az ütemtervben az extra támogatás beépítése? Természetesen a felhasználókat az a kérdés érdekli a legjobban, hogy milyen esetekben tudják hasznosítani a GeForce grafikus rendszer fizikai számításra alapozó extra képességeit. Ha az adott program teljes licensszel rendelkezik, akkor lényegében mindig.

Az igazsághoz azonban hozzátartozik, hogy sok esetben nincs értelme a fizikát a grafikus processzoron számítani, egyszerűen nincs komoly haszna az eredményeket tekintve. Példának érdemes az Unreal Tournament 3-at felhozni. Ez a játék minden esetben kihasználja az NVIDIA PhysX lehetőségeit, ellenben nem árt megfigyelni, hogy csak akkor van komoly sebességnövelő hatása a technikának, ha a pálya fizikai komplexitása meglehetősen magas. Az eredeti, PhysX rendszert nem igazán használó pályákon a teljesítmény a grafikus rendszeren történő fizikai számítás hatására elenyésző mértékben növekszik. Ezen a ponton lépnek be a képbe a konzolok. Az Xbox 360 és a PlayStation 3 a PhysX technológiát csak a központi processzoron képesek futtatni, ami limitálóan hat majd a jövőben megjelenő játékok fizikai összetettségére. Emellett tovább rontja a helyzetet, hogy a fizika szerves része a játékmenetnek, így annak butítása, illetve feljavítása komoly aggályokat vet fel. Abban az esetben sem javulna a helyzet, ha az AMD belépne a PhysX-et erősítő cégek táborába, hiszen ha valami nem működik megfelelően konzolon, akkor jelenleg nagyon kicsi a PC-s támogatás esélye.

Voxel space és ray-tracing

Az utóbbi időben igen parázs vitákat vív egymással az Intel és az NVIDIA. Ennek elsősorban az Intel Larrabee nevű fejlesztése az oka. Ez a chip több általánosan programozható és viszonylag egyszerű felépítésű processzormagot tartalmaz, ami teljesen új koncepció a grafikus kártyák piacán. A kékek nyilvánvalóan termékük tökéletességét hirdetik, míg a zöldek elég negatív nyilatkozatokkal hívják fel a figyelmet az eszköz hibáira. Az AMD hivatalos véleményét nem lehet tudni, ők ebben a nyilatkozatháborúban inkább csak külső szemlélőként vesznek részt. A Larrabee megjelenéséig még legalább két év van hátra, de már most világossá vált a csatában résztvevő cégek vezetői számára, hogy a vesztes nagy árat fog fizetni. Az NVIDIA teljes mértékben kiáll a DirectX logikai futószalagja mellett, ami nem csoda, hiszen a felépített GeForce birodalomban majd egy évtized munkája van benne. Az Intel kvázi új szereplő lesz az önálló grafikus kártyák piacán, így alapvetően a befektetett pénzen kívül minimális a vesztenivalója. Az AMD egyfajta kakukktojásnak tűnik a harcban, ugyanis nekik alapvetően mindegy, merre halad tovább a kor, hiszen technológiáikkal mindkét irányvonal kényelmesen követhető. Az NVIDIA ellen tökéletes fegyvert jelentenek jelenleg az R600 mikroarchitektúrára épülő termékek, míg az Intel ellen egy megfelelően felépített Fusion rendszer vehetné fel a harcot. Nehéz megjósolni, hogy mit hoz a távolabbi jövő, de mindenképp kiindulhatunk egy-két vezető fejlesztő elképzeléséből, és a jelenlegi renderelő futószalag esetleges gyenge pontjaiból.

A render futószalag változásai

Érdemes a mellékelt képre vetni egy rövidke pillantást. Az ábra azt vázolja fel, hogy kezdetben minden grafikai program egy szoftveresen definiált renderelő futószalagot használt. A számítások teljes egészében a processzort terhelték. A DirectX futószalagja tulajdonképpen egy előre definiált render. Az alapjai az 1992-ben megjelenő IrisGL-re épülő OpenGL API-ban bemutatott szerkezetnek feleltethetők meg. A logikai felépítése modellezés esetén geometrikus traszformációkra épül, míg a leképzésre a raszterizálást használja. Ez a struktúra a mai napig nem változott, csak egyes elemei bővültek a kornak megfelelően. A DirectX 11 felépítése pedig már feszegeti a fenti két eljárás elméleti határait. A geometrikus transzformációkra épülő modellezés a tesszellátor bevezetésével gyakorlatilag elérte fejleszthetősége csúcsát. Talán egy apró lépcsőfokot jelenhet még az egyénileg definiálható tesszellációs algoritmusok bevezetése, de ez igazából nem számítana kiemelkedő ugrásnak a jelenlegi fix funkciós egységhez képest.
Persze nem feltétlenül kell a modellezésnek a geometrikus transzformációkra építeni, mert van más megoldás is, melynek neve Voxel Space. A közhiedelemmel ellentétben a messze nem újkeltű eljárást jelenleg elsősorban az orvosi képfeldolgozásnál használják. A játékok szempontjából régebben lehetet voxeles rendszerrel találkozni. Hogy példa is legyen szem előtt, az Outcast nevű játék ezt az eljárást használja, emellett érdemes megemlíteni Ken Silverman Voxlap nevű motorját is. De mi is a voxel definíciója? Tulajdonképpen a virtuális térfogat egyfajta elemi egysége, ahogy a pixel a kép területének a legegyszerűbb megközelítése. A név is innen ered: Volumized Pixel. Voxelnek a 3D-s motorban előre definiálhatót szélessége, magassága és mélysége van; minél kisebb ennek az egységnyi értéke, annál jobb lesz a grafika, viszont a teljesítményigény is ennek megfelelően növekszik. A technika nagy előnye, hogy a poligonhoz képest sokkal kevesebb adatmennyiséget kell tárolni. Nagyon jó alkalmazási területe a Voxelnek a terep kirajzolása, ugyanis tökéletesen leképezhetők vele a barlangok és más kiálló ívek, emellett a technológia alapjai miatt viszonylag kevés erőforrásigénnyel még rombolhatóvá is lehet tenni a virtuális térséget. Általános probléma azonban, hogy a közelben lévő voxelek esetenként nagy kockákat eredményezhetnek. Hasonló a jelenség az aliasing problémához, mely a pixelekből felépülő képeknél fedezhető fel. Ennek csillapítására számtalan kis trükk létezik. Legegyszerűbb megoldás, ha a pixel színének meghatározásához nem csak a hozzá tartozó, hanem a környező voxelek értékeit is figyelembe vesszük.

Sugárkövetés

Az Intel Larrabee bemutatók visszatérő anyaga. A sugárkövetés, idegen szóval ray-tracing a raszterizálás riválisának tekinthető. Technikailag a ray-tracing előnye, hogy nem csak poligon alapú felületekkel képes dolgozni. A számítás szempontjából csak az az információ számít, hogy a fényforrásból kiinduló sugár hol metszi az adott objektumokat. A ray-tracing lényege, hogy a virtuális térben leírt környezetből a fénytan törvényeihez hasonlóan történik a képkockák leképzése. A fénysugarak útját a fényforrásból kell addig nyomon követni, amíg az a nézőpont irányában át nem halad a kép egyik pixelén. Közben persze rengeteg interakció történhet a virtuális térben, így a számításnál figyelembe kell venni, hogy a sugár milyen objektumoknak ütközik neki, és azok a fény mely részét tükrözik vissza, nyelik el vagy eresztik át. Ezen a ponton rögtön található egy nagy probléma: közel sem biztos, hogy a fényforrástól követett fény valaha is eléri a képernyőt. Éppen ezért teljesítmény szempontjából sokkal kifizetődőbb, ha az egész eseménysorozatot visszafelé követjük, azaz a képernyő minden pixeléből a nézőpontnak megfelelően indítunk sugarakat. Ezt backward ray-tracingnek nevezzük.

A feldolgozás menete röviden úgy zajlik, hogy a nézőpontból az adott pixelen át kilőtt sugarat vagy sugarakat (bilineáris vagy jobb minőségű szűrés esetén) követjük az eltalált felületig, majd a beesési pontból újabb sugarak indulnak ki a tükröződések, a fénytörések, illetve a fényforrások irányába. Ha az új sugarak által eltalált felület tükröző vagy áttetsző, akkor megint újabb sugarak indulnak ki az előzőeknek megfelelően. Rögtön észrevehető, hogy rengeteg kis sugár lesz a jelenetben. A számítás legkínosabb pontja a pixel végső színének meghatározása, ami a fényhez irányuló sugarak felülettel bezárt szöge alapján történik. Itt bizony a mai rendszerek számítási teljesítmény szempontjából elhasalnak. Arról nem is beszélve, hogy a különböző virtuális anyagok másképp reagálhatnak a fényre, így az árnyalási modelleket sem szabad figyelmen kívül hagyni. Alapvetően elmondhatjuk, hogy a ray-tracing a raszterizálásnál jobb képminőséget állíthat elő, de nagyságrendekkel magasabb teljesítményigénnyel rendelkezik. A manapság használt raszteres grafika a shaderekkel kiegészítve ugyan az esetek többségében egyfajta utánzott (csúnyán fogalmazva fake) eredményt kelt, de összhatásban rendkívül ütőképes.

Példák, konklúzió

Példákkal előállva az alábbi képet 14 darab Sony Cell processzor számolja (egy ilyen processzor található a PlayStation 3-ban) épphogy folyamatos sebességben, Full HD felbontásban.

Érdemes még az NVIDIA demonstrációját is megnézni, egy Quadro Plex 2100 D4 rendszer eredményét, amelyben négy darab G92-es (a GeForce 8800 GT alapja) chip teljesít szolgálatot fejenként 1 GB memória társaságában. A sebesség szintén folyamatos Full HD felbontásban.

A fenti két példához még mindenképp hozzátartozik, hogy a jelenet minden esetben statikus volt, ami messze nem felel meg a játékok által támasztott igényeknek. Egy interaktív, háromdimenziós program dinamikus jelenetet eredményez, amiben az objektumok helyzete folyamatosan változik. Ez megköveteli a használt térrendező fa újragenerálását, ami további időveszteség.
A valós idejű sugárkövetés a fellelhető információk alapján bizony nagy falat lesz még a belátható időn belül megjelenő hardvereknek is. Természetesen a raszterizálásnak is vannak határai, hiszen az eljárás hatékonysága egyenes arányban csökken a jelenetben használt poligonszám növekedésével. Ez a távoli jövőben még a ray-tracing előnyét is eredményezheti. Ha azonban időponthoz akarjuk kötni ezt a dolgot, akkor még mindig minimum egy évtizedes időtávot érdemes feltételezni. A Larrabee dokumentációkon nagy valószínűséggel azért kapott a technika kiemelt figyelmet, mert a nagyméretű chip feltételezhetően raszterizálásban nehezen veszi fel a versenyt a konkurens GeForce és Radeon modellekkel. Ez persze messze nem azt jelenti, hogy az Intel projektje kudarc lesz. Számtalan területen megvillanthatja még tudását a rendszer. Talán érdemes megjegyezni, hogy az előzetes beszámolók birtokában John Carmack (ID tech 6) és Tim Sweeney (Unreal Engine 4) éppen fejlesztett motorjai bizony visszatérnek a szoftveres renderelés vonalára. Célplatformnak a 2012-2014 körül megjelenő, következő generációs konzolok vannak megadva, de biztosra vehető, hogy a PC-n is lehet majd találkozni a két rendszerrel. Márpedig a szoftveres render a Larrabee malmára hajtja a vizet.

Larrabee technikai demó

Az elmúlt években sok változáson ment keresztül a számítógépes grafika fejlődése, és az elkövetkező időszakokban várhatóan hasonló ütemű fejlődésre lehet számítani. Egyértelműen látszanak egyes cégek úgymond reformtervei. Ettől függetlenül fontos szem előtt tartani azt, hogy a felhasználók többsége elsősorban nem a vásárlandó kártya mögött rejlő technológiát nézi, hanem a jelenben felmutatott értékeket. Ennek ékes példája volt az AMD Radeon HD 2900 nevű próbálkozása, mely közel másfél évvel megelőzve korát technológiailag fasírtot készített a GeForce 8800 sorozatból. A termék azonban mégsem lett sikeres, ami annak köszönhető, hogy nem tudott megfelelni az akkoriban támasztott követelményeknek. Persze az architektúra fejlettségére alapozó AMD az új termékcsaládokkal most kamatostul kapja vissza azt, amit akkor elveszített. Ha egy elvont párhuzamot vonunk a Larrabee rendszerére nézve, akkor láthatjuk, hogy az Intel grafikus elképzelése bizony négy évvel is megelőzheti korát, már ha a 2010-re ígért megjelenés valós adat. Ez nagyon meg fogja nehezíteni a kékek szereplését a GPU-piacon. Szerencsére a Larrabee kellően univerzális termék ahhoz, hogy több piacon is szerepeltessék. Érdemes megfigyelni, hogy az Intel elképzelései mennyire újszerűek, és az eddigi megoldásokkal összehasonlítva komolyan megváltoztathatja a jelenleg elterjedt logikai futószalagot. Ha a piac a kékek terveinek megfelelően formálódik, és kedvező körülmények alakulnak ki az eszközük képességeihez, akkor komoly sikerekre számíthatnak. Fennáll azonban annak az esélye, hogy megosztott lesz az új technológiákról a fejlesztők véleménye.

Abu85 | 2008

Újszerű élsimító eljáráson dolgozik az NVIDIA

[ProHardver] Régóta ismert probléma, hogy az eddig kiválóan működő multisampling élsimítás már nem felel meg a kor követelményeinek. Bár kétségtelen, hogy kifejezetten jó a képminőséghez mért erőforrásigénye, a manapság alkalmazott renderelő motorok olyan eljárásokkal dolgoznak, ahova már a fejlesztői kontroll szükséges a technika megfelelő alkalmazásához, ezt azonban sokan inkább kihagyják, aminek többnyire az az eredménye, hogy a játék nem tartalmaz majd élsimító algoritmust. Ilyenkor az AMD és az NVIDIA a driverben keres valamilyen utat az MSAA aktiválására, ez azonban messze nem egyszerű feladat, mivel a renderkódot nem tudják befolyásolni, így a kényszerítés sokszor csak részlegesen, vagy rosszabb esetében egyáltalán nem ad értékelhető eredményt.

Az AMD a fenti problémák miatt dolgozta ki az MLAA-t, vagyis a morfologikus élsimítást. A közhiedelemmel ellentétben az algoritmus alapjait nem az AMD fektette le, ők csak továbbgondolták azokat, és előálltak egy DirectCompute felületre alapozó megvalósítással. Az MLAA előnye régóta ismert. A technika minden felülettel kompatibilis, vagyis nem csak a poligonok éleit szűri, hanem képes a textúrák, az átlátszó felületek, illetve a shaderek recés torzulásait is javítani. Mivel a teljes megvalósítás post-process effekt formájában működik, a végleges képkockán fut le, ami azt eredményezi, hogy minden renderelőn ugyanúgy fog működni. Kétségtelen, hogy az MLAA nem az élsimító technológiák Szent Grálja, de az MSAA egyre több hibát generál, a mai deferred render motorokkal, és ennek kivédésére csak a supersampling megvalósítás jelentett megoldást, de az olyan túlzott erőforrásigényt követel, hogy lényegi haszna csak a csúcskategóriás termékeken van.

Dead Space AA nélkül és MLAA-val

A morfologikus szűrés gyakorlatilag csak a számítási teljesítményre érzékeny, de az algoritmus elképesztően jól párhuzamosítható, vagyis az 1-2 TFLOPS-os kapacitással rendelkező GPU-k már megbirkóznak vele. A technológia lényegében olyan szomszédos pixeleket keres, ahol nagy az eltérés a színinformációkban. A kiválasztott képpontokat csoportosítja, majd egy előre definiált alakzatot rendel hozzájuk. A lényegi munka itt kezdődik meg. A környező pixelek adatai alapján az algoritmus korrigálja a vizsgált alakzathoz tartozó pixelek színét, annak megfelelően, hogy a szomszédos képpontok mennyire eltérőek. Az algoritmus nagymértékben skálázható, hiszen a számításba vett pixelek száma tetszőlegesen állítható be, ugyanakkor problémák is előfordulnak. A vízszintes és függőleges állapothoz közeli vonalakra egyetlen minta sem alkalmazható tökéletesen, ami azt eredményezi, hogy ezek az élek nem lesznek kifogástalanul szűrve. Itt jön az a pont, ahol mindenképpen szükséges az MSAA vagy az SSAA alkalmazása. Szerencsére az MLAA post-process szűrő, így tökéletesen kompatibilis minden más képminőség-javító technológiával.

MLAA működése

Az NVIDIA egyelőre az MSAA és az SSAA alkalmazhatóságáért küzd, de nem kérdéses, hogy szükséges egy újszerű megvalósítás bevezetése. Az MLAA, ahogy fentebb kiderült egy értékelhető opció, de nem biztos, hogy a GeForce-ra történő implementálás hatékony lenne. Mivel az algoritmus csak a nyers számítási teljesítményre érzékeny a Radeonok komoly előnyben vannak itt, hiszen a legerősebb fermis GPU 1,58 TFLOPS-os teljesítményre képes, szemben a Cayman 2,7 TFLOPS-os tempójával. Ebből rögtön lehet látni, hogy ugyanaz a kód – a jól párhuzamosítható jellegből adódóan – a hasonló árú GeForce termékeken nem lenne túl gyors, vagyis az MLAA alkalmazása nem célszerű, és lényegében ezért nem lett eddig bevezetve. Van azonban más megoldás is, mint például a Subpixel Reconstruction Anti-Aliasing.

Practical Morphological Anti-Aliasing (UZ MLAA)

A subpixel alapú élsimítás alapjai szintén nem mondhatók újnak, mivel az Apple is ezt alkalmazza a termékein. Természetesen az NVIDIA csak az alapokat használta fel, így az eredmény eltérő is lehet, sőt annak kell lennie, hiszen a cél a 3D-s játékokon való alkalmazás. A monitoron megjelenő pixelre úgy gondolunk, hogy az a legkisebb megjeleníthető elem. Alapvetően ez igaz is, meg nem is. A szemünk valóban a pixelt látja a legkisebbnek, de valójában egy képpont három úgynevezett subpixelből áll (RGB). Ezek a vörös (Red), a zöld (Green) és a kék (Blue) árnyalatok, és lényegében a végső pixel színe is innen származik. Amennyiben az árnyalatok közül csak egyet is megváltoztatunk, úgy a képpont végső színe is módosul. Az SRAA gyakorlatilag itt próbál eredményt elérni.
Az NVIDIA algoritmusa az előzetes adatok szerint kifejezetten a deferred render motorokhoz alkalmazkodik, és alapvetően mélységpufferre építkezik. Pontos leírás még nem látott napvilágot, de a mintavételezést itt lehet végrehajtani, majd a kinyert adatokat felhasználva egy nagyfelbontású mélységpuffert kell létrehozni. A minőség itt skálázható lesz, mivel pixelenként több mintát is ki lehet nyerni. Természetesen a több adat nagyobb teljesítményveszteséggel jár, de az eredmény is jobb lesz. A deferred rendering fázisainál az összemosás a szokott módon megy végbe, de a képminőség összességében jobb lesz, mivel a mélységpuffer a szükségesnél több információt tartalmaz, vagyis ezeket fel lehet használni a subpixelek színinformációinak korrigálására, azaz az élsimításra. Ezt szintén el lehet játszani a normal buffer esetében, ami még tovább javítja az eredményt. Utóbbi esetben valószínűleg az alkalmazásprofilokkal testre is lehet szabni a megvalósítást. Az eljárás a teljesítményigény tekintetében teljesen kötött, mivel pixelenként ugyanaz a számítás fut le. Az előzetes adatok szerint 720p-s felbontásban a készülő algoritmus 1,8 ms-os időigénnyel rendelkezett, ami jónak mondható, bár a minőségről nem nyilatkoztak a fejlesztők. Lényegében az eredmény a minták számával befolyásolható, vagyis az SRAA az igények szerint skálázható.
A Subpixel Reconstruction Anti-Aliasing algoritmusról február végén beszél bővebben az NVIDIA. Természetesen az elméleti alapok lefektetése mellett gyakorlati implementációra is szükség van, vagyis meg kell várni, míg elkészül a driveres implementálás, mely bármely GPGPU platformon alkalmazható. Hogy ez mikorra lehetséges, arról nincs információ.

A pixelek geometriája eltérő paneleken

Érdemes megjegyezni, hogy a subpixel alapú megvalósítások általános hátrányokkal is küzdenek. Elsősorban fontos tényező a monitor képpontjainak geometriája. Ebből a szempontból nagyon sok eltérő megvalósítás létezik. Valószínűleg az LCD panelek élveznek prioritást, ám ezen belül is léteznek RGB és BGR kialakítású panelek, ahol az egyes pixelekhez tartozó subpixelek ugyan megegyeznek, de a lineáris sorrendjük más. Gyakorlatilag számítani kell arra, hogy az eredmény monitoronként változó lesz, mivel a subpixelek geometriai elhelyezkedését és sorrendjét a driver képtelen ellenőrizni, vagyis az adott algoritmus, csak egy bizonyos előre kiválasztott paneltípuson lesz tökéletes. Érdemes lesz tehát több paneltípusra is elkészíteni az SRAA-t, majd egy adatbázis alapján alkalmazni a legjobb eredményt nyújtó megoldást.

Abu85 | 2011-01-31 10:55

Aliasing és Anti Aliasing

Mi is az az Alisaing? Eredendően egy mintavételezési hibáról beszélhetünk. Van a mi kis analóg világunk a maga majdnem végtelen (szemünk számára végtelen, mert nem látunk molekuláris szinten) részletességével, és ezt szeretnénk minél jobban megközelíteni a monitoron (valósághű). Mivel a számítógép digitális, van egy részecskeméret (pl. egy pixel a monitoron) ami alá nem tud menni, azok a részletek, amik a való világban kisebbek ennél a részecskeméretnél nem - vagy csak nagyon nehezen - jeleníthetőek meg. Ezt a problémát hívják aliasingnak. A gyakorlatban két megjelenési formája van:

1. töredezett élek (ezzel gondolom mindenki találkozott)

2. megjelenő majd eltűnő részletek

Felmerül a kérdés, hogy miért nem lehet ezt gondos tervezéssel (nem tervezek túl kis objektumokat) elkerülni. Sajnos nem lehet, mert egy hatalmas objektum is összemehet apróra, ha távol kerül a kamerától.

Hogyan lehet védekezni ellene? - Anti Aliasing

Valamilyen módon finomítani kell a felbontást, persze ez további számolással és memória valamit memória sávszélesség zabálásával jár. Persze semmi sincs ingyen még a virtuális világban sem. Akkor hogyan? Túlmintavételezéssel! Növeljük kétszeresére a felbontást mindkét irányba, ezzel megnő a kép részletessége viszont drasztikusan nő a feldolgozás összetettsége is. Így egyetlen pixelt már 4 pixel fog reprezentálni a megnövelt képünkön. Ezen a duplázott képen számoljuk ki a rendereléseket, majd visszaméretezzük a képet úgy, hogy 2×2esével kiátlagoljuk (összeadjuk, majd elosztjuk négyel) a pixeleket. Ezt a kétszeres növelést (kétszeres túlmintavételezés) hívják Nyquist mintavételezési törvénynek.

A túlmintavételezést megcsinálhatjuk többféleképpen is. A legegyszerűbb a duplázás x és y irányba OGSS (Ordered Gird Super Sampling), de használható elforgatással kapott mintavételezés RGSS (Rotated Gird Super Sampling) amikor a 4 (vagy több) szubpixel az eredeti kép elfogatásával jön létre.

OGSS mechanizmusa

Szintén használható valamilyen fajta multi sampling, ahol nem a kép duplázásával nyerünk újabb mintavételi részleteket hanem valamilyen más transzformációval. A multisampling általában gyengébb képet ad mint a supersampling de jóval gyorsabb.

Akkor most lássuk a hatást gyakorlatban

Egy egyszerű mintavételezési példa. Rajzoljunk pár fekete sávot fehér háttérrel és ezeket nézzük meg 110, 133 és 200 százalékos nagyításban.

100% - 110% - 133% - 200%

Látható, hogy csak 200%-nál maradt töredezés mentes a sáv felülete, mert itt jött ki kétszer annyi (egész számszor) mintavevő hely.

mrudi

Bevezetés a shaderek világába

Már régóta szerettem volna foglalkozni a shaderekkel. Sajnos a bevezetők írása nem az én műfajom, így most is egy nagyszerű írást hívok segítségül TheProGamer tollából. Remélem segíteni fog mindenkinek ráhangolódni a témára. Amint lesz egy kis időm a példaprogram is érkezni fog...

Bevezetés

Mik is azok a shaderek, hogy működnek és miért jelentenek fejlődést? Ezen kérdésekre próbálok ezzel a cikkel választ adni. Kezdjük is rögtön azzal hogy mik is ezek? Hogy ezt megértsük először nézzük meg hogy néz ki a Direct3D Pipeline.

Mint a képen is látható a shaderek két részre oszthatók: Pixel Shader és Vertex Shader. Ez a két shader típus két ezelőtt teljesen merev automata folyamatot vált le. A Vertex Shader-ek a T&L leváltására készültek, a Pixel Shader-ek pedig a textúra mintavételezés és a képernyőre kerülő képpontok színének előállításának merev önműködő folyamatát hivatottak rugalmasabbá tenni.

De mik is ezek a shaderek konkrétan?

Kis, önálló nyelven a programozó által írt mini programocskákról van szó, amik alapvetően arra hivatottak, hogy a idáig automata folyamatokat elvégezzék. Kérdezhetitek hogy ez akkor miért jó, hisz ugyanazt csinálja és még ezt is kódolni kell. Mert nem csak helyettesíteni lehet vele ezeket az a folyamatokat, hanem tovább fejleszteni, bonyolultabbá és összetettebbé tenni, ezáltal sokkal élethűbb képet előállítani. Mert ugye ha valamilyen új, rugalmasabb eszközt adunk a programozók kezébe egy régi helyett, akkor ők nem arra fogják ezt használni hogy csak a régit helyettesítsék vele. :) Ez idáig gondolom érthető.

De akkor most ezek konkrétan hogyan is működnek?

Kezdjük az egyszerűbbel, a Vertex Shader-rel. A Vertex Shader minden egyes vertexre lefut, nem számít hogy hol van, milyen messze, milyen irányban. Legelőször is meg kell adnunk hogy a vertexek mely adataira van szükségünk (pl.: Helyzet, Normál Vektor, Tangens Vektor, Bitangens Vektor, Vertex Szín, Textúrakoordináta stb.). Ezeken az adatokon tudunk műveleteket végezni. Viszont ha nekiállunk Vertex Shader-t használni egy modellen, akkor a T&L egység már nem fogja a beállított mátrixokat „végrehajtani”, mivel maga a T&L egység ilyenkor le is áll. Tehát nekünk kell kézbe venni a dolgokat és a mátrixokat a vertexeken végrehajtani. Ezt szerencsére meg lehet oldani Vertex Shader-el, viszont felmerül a kérdés, hogy hogyan tudjuk a Vertex Shader-ben a mátrixokat használni mikor azokat nem tudjuk a vertex adatoknál lekérni. Szerencsére erre is van megoldás, a program, ami a Vertex Shader-t használja képes arra hogy speciális függvényekkel változókat adjon át a shader-nek, így simán át lehet már passzolni a mátrixokat is a szorzásokhoz. Tehát egy alap Vertex Shader annyit csinál hogy az átadott három mártixal (Világ, Nézeti és Projekciós) megszorozza a vertex pozícióját. De ez még csak a kezdet, innen már csak a képzeletünk (és a maximális utasítás szám) szab határt annak, hogy mit csinálunk a vertexek adataival. Ha kész vagyunk a vertex adatok számolásával akkor már csak ki kell választani hogy mit akarunk tovább küldeni.
Ezzel nagyjából végig is értünk a Vertex Shader-eken. Most következzen az érdekesebb és kissé bonyolultabb rész, a Pixel Shader. A Pixel Shader minden egyes pixelre lefut és végrehajtja a megadott műveleteket (mint ahogy azt a Vertex Shader is tette a vertexekre). És akkor itt most oszlassunk el egy tévhitet, ugyanis sokan hiszik azt, hogy a Pixel Shader a textúra képpontjain halad végig. Pedig nem így van. Eleve a textúra képpontjait nem pixelnek hanem texelnek hívjuk (pixel = picture element ; texel = texture element ). Tehát a Pixel Shader a képernyőre kerülő képpontokon fut végig, azoknak a színét számolja ki a textúrából vett minta és a megadott számítások alapján.
Itt már kevesebb adattal dolgozunk, csak az adott képponthoz tartozó textúrakoordinátát és ha van akkor vertex színt kapjuk meg. Ezek alapján tudunk a texturából mintát venni és azt tovább küldeni a képernyőre. És itt jön egy újabb kérdés: Akkor hogyan tudunk megvilágítást számolni Pixel Shader-ben, hiszen ahhoz kell az adott pont Normál Vektora.
Az egész egy kis trükkel megoldható. A trükk lényege az, hogy a Vertex Shader-ben fogjuk a Normál Vektort és textúrakoordinátának „álcázva” tovább küldjük feldolgozásra. Így már tudjuk használni a Pixel Shader-ben is a Normálokat. De ennek a módszernek van még egy igen kellemes előnye, mégpedig az, hogy raszterezéskor a videokártya lineáris interpolálással minden egyes ponthoz amit a Pixel Shader később kezelésbe vesz kiszámolja az adott textúra koordinátát a környező 3 vertex textúrakoordinátájából. Magyarul a háromszög felületén végigátlagolja a textúra koordinátákat annak függvényében hogy az adott pont milyen messze van az adott vertexektől. És mivel mi a Normál Vektort is textúra koordinátaként küldtük tovább az is szépen végigátlagolódik, lényegében minden egyes ponthoz kiszámolódik az adott Normál Vektor. Innen bár semmi akadálya annak hogy hogy megvilágítást számoljunk.
Ezzel körülbelül minden a cikkben felvetett kérdésre sikerült (remélem kielégítő) választ adni, remélem hasznát veszitek. Folytatások tervben, ha van rá igény akkor meg is írom őket.

TheProGamer

Textúrák szűrése

Miután felépítettünk egy 3Ds jelentett a virtuális világban el kell tudni döntenünk, hogy a képen megjelenő pixeleknek milyen színük legyen. A keresett színnek az alapja egy textúra térképen (texture map) található, ami egy 2D leképezése a textúrázott 3D világnak. A textúra térkép pixeleit texeleknek hívjuk. A nagy kérdés az, hogy melyik texelek határozzák meg a képernyőnk egyes pixeleinek a színét. A textúratér és a képernyő-koordinátarendszer közötti leképzés a textúratér egyes részeit nagyíthatja, más részeit pedig összenyomhatja. Az előbbi esetben nagyításról, az utóbbiban pedig kicsinyítésről beszélünk. Azért, hogy a problémát jobban megértsük, most képzeljünk magunk elé egy 1024×768-as felbontású képet, aminek a pixelein át, mint egy rácson keresztül szemléljük a 3Ds jelenetet.

A mintavételezés problémája

Belesünk egy lyukon át és amilyen színt látunk, az lesz a képpont színe. De mi van, ha több színes pontot (texelt) látunk a lyukon keresztül (ez az eset fordul elő gyakrabban)? Ha a térbeli alakzat, amire rálátunk a lyukon keresztül merőleges a rácsunkra akkor „kör” (négyzet) alakban látunk egy pixelcsoportot, ha nem merőleges (elég gyakran) akkor pedig „ellipszis” (téglalap) alakban látunk egy pontcsoportot. Ez azt jelenti, hogy a képernyőtérben egyenletes sűrűséggel kiválasztott pixel középpontok igen egyenlőtlenül mintavételezhetik a textúrát, amely végső soron problémákat okozhat. Ezért a textúra leképzésnél a mintavételezési problémák elkerülését célzó szűrésnek különleges jelentősége van. A textúra szűrés nehézsége abból fakad, hogy a textúratér és a képtér közötti leképzés nemlineáris. Például, ha doboz szűrést szeretnénk alkalmazni, azaz a pixel textúratérbeli képében kívánjuk a texeleket átlagolni, akkor szabálytalan, általános görbék által határolt területtel kell dolgoznunk.

Textúra szűrő eljárások

A szokásos eljárások ezt az általános területet egyszerű területekkel, például ellipszissel, négyszöggel, téglalappal vagy négyzettel közelítik. A leggyakoribb szűrési módok a következőek:

1. Point Sampling:
   Egyszerűen kiveszi a középső pixelt, figyelmen kívül hagyva a többit és a "rácson keresztül látott" alakzat formáját. Ez a módszer kis memóriaigényű, de nem valami szép megoldás. Ha egy nagy objektum nagyon közel kerül a kamerához, akkor borzasztóan kockás képet eredményez, mivel több pixelhez is ugyanaz a texel tartozhat, ugyanazzal a színnel.
   
2. Bi-linear Filtering:
   Négyzettel történő közelítés esetén egyetlen pixel színét úgy határozhatjuk meg, hogy megkeressük a pixel sarokpontjainak megfelelő textúratérbeli pontokat, előállítjuk a négy pontot tartalmazó legkisebb négyzetet, majd átlagoljuk a négyzetben lévő texelek színeit. A közeli objektumok így szépen elmosódnak (gyengülnek az élhibák és textúrazajok lásd AA), igaz ez csak egy mellékes hatás. Ennek a szűrésnek két hátránya van: négyzet (vagyis 2×2pont) formájú alakzattal dolgozik, ami az esetek többségében pontatlan (kamera irányára nem merőleges poligonok), valamint négyszeres sávszélesség igénye van a Point Samplinghoz képest.
3. Tri-linear Filtering:
   A Mip-Mapping (lásd később) ötletét adja hozzá a Bi-linear-hoz. Mindkét Mip szinten végrehajtunk egy Bi-linear szűrést és a két értéket átlagoljuk. A memóriaigény megint duplázódik és még mindig négyzet alakzattal dolgozunk.
4. Anisotropic Filtering:
   Az eddigi szűrési eljárások valójában csak arra voltak jók, hogy a közeli alakzatokat elmossák (ez valójában mellékhatás) a távoli alakzatok még mindig pixel összevisszaságok maradnak az alul mintavételezés miatt. A legjobb minőség akkor érhető el, ha minden egy rácspontból látható texelt felhasználunk a szín meghatározásához és figyelünk a textúratérképen látható alakzat formájára is. Persze ezek az eljárások nagyon komoly memóriaigénnyel rendelkeznek. Általában 16-32 texelt vesznek figyelembe pixelenkét és ügyelnek az alakzat elfordulására is. Anizometrikus szűrést többféleképpen meg lehet valósítani. Az egyik lehetőség a Rip-Mapping, ami egyfajta elforgatott Mip-Mapping. Nem csak az egyes Mip szinteket számolja ki a kártya, hanem bizonyos szögelforgatott textúrákat is. Ezeket az elforgatott textúrákat használja, miután megállapította az éppen renderelt poligonlap elfordulását a kamerához képest. Az eljárás gyors mivel nem kell minden pixelnél elforgatni a textúrát csak egyszer a Rip-mapok képzésekor, de nem teljesen pontos minden szögre.

Felhasznált irodalom:

1. Dr. Szirmay-Kalos László, Antal György, Csonka Ferenc: Háromdimenziós grafika, animáció és játékfejlesztés
2. http://vganfo.uw.hu/
   

Mit tud majd a DirectX 11

Akármilyen géppel vagy konzollal rendelkezzünk is, elvárjuk, hogy évről évre szebb játékok lássanak napvilágot. Egyre divatosabban használjuk a "shader" és "szűrés" kifejezéseket, minden eltelt nappal kritikusabbá válunk, és csak reméljük, hogy lassan eljön a nap, amikor már meg se lehet különböztetni a valóságot a játéktól. De vajon ez mikor következik be?

Mielőtt még elmerülnénk a DirectX 11 mélységeiben, nem árt egy kis technikaóra, hogy könnyebben érthető legyen, miért is várunk olyan sokat a Microsoft legfrissebb üdvöskéjétől. A videokártyák grafikus processzorai (GPU-i) abban különböznek a számítógép agyának is nevezett processzoroktól (CPU-któl), hogy míg utóbbiakat már évek óta szigorú szabványok alapján kell felépíteni, addig előbbiekre mindez nem igaz. Akármilyen architektúrát alkalmazhatunk, a lehetőségek határa a csillagos ég. Ahhoz viszont, hogy mindez működjön, szükség van egy alkalmazási felületre (API-ra), ami bármilyen videokártyát képes felismerni, s mellyel kommunikálva annak meghajtó programja kihasználhatja az eszközben rejlő lehetőségeket. Ez az API tehát létfontosságú a gyors és mindenki számára elérhető 3D-s grafika kiszámításában. Jelenleg két uralkodó típus osztja meg egymással a piacot. Az egyik az OpenGL, melyet az egyszeri játékosok főként az id FPS-eiből ismerhetnek (az összes teljesen 3D-s id motor arra épült), a másik pedig a tortából jóval nagyobb szeletet kivágó DirectX.

Mivel utóbbi nem szorul különösebb bemutatásra, legyen elég annyi, hogy ez manapság a legelterjedtebb platform. A forradalmi 8.1 után (Az übergéniusz, John Carmack szerint se készült azóta innovatívabb felület.) megérkezett a 9, mely bár koránt sem volt akkora durranás, mégis átvette a korábban uralkodó 7 helyét a játékvilágban. A DirectX 10-re a Windows Vista megjelenéséig várnunk kellett, ám mikor végre kijött, nagyon megosztotta a közönséget. Kihasználni a mai napig nem tudta senki, holott lényege nem is a grafikai tupír, hanem a programozást leegyszerűsítendő felépítésében rejlett. Ennek ellenére még most is a DirectX 9 a vezető, s még egyetlen olyan játék sem látott napvilágot, mely kizárólag a DirectX 10-re épült volna.

A Microsoft látva a kvázi sikertelenségét, nem is oly rég bejelentette API-ja 11. generációját, ami a 10-hez hasonlóan most is egy új operációs rendszer keretében érkezik majd (Windows 7). De vajon jó lesz-e ez nekünk? Szükségünk van-e még egy kihasználatlan felületre, avagy komoly forradalom készül? Bemutatómban igyekszem közérthetően megismertetni a DirectX 11 legfontosabb tulajdonságait és újdonságait.

Szebb jövőt

A DirectX 10 legnagyobb buktatói pont az őt teremtő cég ostobaságaiból fakadtak. Csak és kizárólag Windows Vista operációs rendszer mellett volt elérhető, egyetlen játék sem használta ki, a driverek nem támogatták rendesen, és a tetejébe még a beígért Flight Simulator patch sem érkezett meg időben. Szerencsére az óriás tanult a hibáiból, így a DX 11 Vista alatt is elérhető lesz, jóval nagyobb táborra szert téve már rögtön a megjelenésekor. Mindez persze mit sem érne, ha nem lehetne rendesen programot írni rá, de a birtokunkban lévő eddigi információk és a novemberben elérhetővé tett DirectX SDK DX 11-et is tartalmazó elemei kellően meggyőzőek. A legnagyobb előnye a DX 11-nek a DX 10-zel szemben, hogy míg utóbbi egy abszolút új irányba terelt fejlesztés volt, addig a 11 nagyon sok elemében hasonlít a DX 10-hez.

Ahhoz, hogy ezt megértsük, tudnunk kell, hogy is működik egy átlagos API. Legfontosabb feladata természetesen nem más, mint megmondani a hardvernek, hogyan számolja ki a 3D-s világ szintén 3D-s elemeit és miként rajzolja ki őket a képernyőre. Ezt a folyamatot hívjuk pipeline-nak. A DirectX 10 sok forradalmi lépést tett a dolgok egyszerűsítése érdekében, s utódja mindezeket egy az egyben át fogja venni. Amiben mégis más lesz, az a vertex számítások után beiktatott három új tesszellációs lépcsőfok. A tesszellátor feladata a térgeometriai formák apró elemekre bontása, hogy valami bonyolultabb épülhessen fel belőlük, alapanyagot, azaz számítási kapacitást spórolva ezzel. Továbbá megjelenik még a Compute Shadernek nevezett, minden tekintetben forradalmi eljárás, mely lehetővé teszi a fejlesztők számára, hogy magát az API-t megkerülve sajtoljanak ki extra erőforrásokat a GPU-ból. Ennek részletezésébe most nem mennék bele, de mindez magyarra lefordítva annyit tesz, hogy sokkal kevesebb munkával jóval nagyobb teljesítmény érhető el a DirectX 11 használata közben, egyre közelebb hozva a valóságos grafika álmának megvalósulását.

Joggal tehetjük fel a kérdést, hogy miért is jó nekünk mindez, ha olyan 70-30%-os arányban még mindig a DirectX 10.1-et kapjuk meg új köntösben? A válasz egy üzletileg kétségkívül zseniális ötletben rejlik. A 11-es Microsoft API megjelenésével nem csak az új csúcskártyák tulajdonosai jutnak előnyökhöz, hanem a mostani, DX 10.1-es VGA-k felhasználói is! Köszönhetően a 11 operációs rendszerhez és driverekhez szorosan kötődő programozási hátterének, megfelelő támogatással a mostani kártyák teljesítménye is nő. A legszebb az egészben, hogy ez még a meghajtókat programozó csapatoktól sem kíván túl nagy megerőltetést, mert a két platform közti átjárásnak hála pofonegyszerű lesz 10-ről 11-re, vagy épp fordítva portolni. Aki tehát nemrégiben vette meg HD4870 X2-esét, nem kell elkeseredjen, mert jó ideig szórakozhat még vele, különösebb kompromisszumok nélkül is. Meg kell még jegyezni, hogy a DX 11 a 10-től eltérően az összes régebbi kártyával együttműködik majd.

Nem csak gyorsabb, sokkal szebb is!

Ugyan a több szálon futó (angolul csak multi-threaded) programozás lehetősége már évtizedek óta adott, a fejlesztők csak nemrégiben kerültek vele konkrét kapcsolatba, hála a többmagos processzoroknak. A Microsoft felismerte az ebben rejlő lehetőségeket, s most végre úgy tűnik, élnek is velük. A DX 11 nem csak a grafikus engine több szálra való installálását támogatja, de maga a játék belső motorja, forráskódja is profitálhat belőle. Mi több, ez működik majd DirectX 10-zel felszerelt, de DX 11-et telepített gépeken is, noha elképzelhető, hogy egyes esetekben a gyorsulás helyett lassulást eredményez. Manapság még nem nagyon létezik olyan motor, ami komolyan szükségessé tenné ezt a felhasználási módot, de a jövő megpróbáltatásai (CryEngine 3.0, vagy a már régóta készülő Unreal Engine 4.0) napról napra közelebb vannak, így nem árt a felkészülés.

Ha pedig már a jövő, akkor új shaderek. A Microsoft's High Level Shader Language (azaz HLSL) a DirectX 11-gyel az 5.0-ás verziószámhoz érkezik. Mivel a HLSL felépítése mindig emlékeztetett a C programnyelvére, már épp ideje volt az osztályok és interfészek beimplantálásának. Akik egy kicsit is ismerik a programozást, tudják, hogy milyen nehéz nagy adategységekkel dolgozni, ha nincs objektumorientált háttér. Ez a helyzet a mai játékok shaderigényeivel is. A kódsorok nagyok, újra és újra be kell illeszteni őket, ami lassítja a motort és elnyújtja a fejlesztés fázisait. Az új megoldásnak hála viszont minden egyes fontosabb shader leírható lesz egy osztályban, mely később bármikor meghívhatóvá válik a forrásból. Ezzel együttvéve a mutatókat is száműzik a nyelvből, így a memória sem kap felesleges terhelést.

Végszó

Ugyan sok dologról nem ejtettem szót, és lenne még bőven írnivaló a DirectX 11-ről, de szándékosan fogtam vissza magam. Egyrészről már így is picit túl technokrata lett a megközelítés, továbbá pedig úgyis csak az elméletek és elképzelések vizein eveznénk, mert ettől fogva az ismereteink már nem mind bizonyítottak. Nincs tehát jobb dolgunk, mint várni, hogy a Windows 7 elvileg jövő év eleji premierjekor az új API berobbanjon a köztudatba. Ami viszont mindenképp biztos, az a DX 11 innovációja. Ilyet már a 8.1 óta várunk, s ha csak nem rontanak el valamit nagyon a Microsoft fejlesztői, nem is fogunk csalódni. Csak jelenjen már meg a Crysis 2, hogy láthassak egy multi-threaded dzsungelt!

Chocho

Képszintézis lépései

Végül is akkor, hogyan alkotunk képet a képszintézis során? A kérdés, jogos. A válasz elméletben nagyon egyszerű. Van ugye nekünk egy modellterünk (benne a világ koordinátarendszer), mibe a képszintézis során egy általános helyzetű téglalapot helyezhetünk el. Ezután mögéje egy szemet vagy kamerát állítunk fel, és a világnak a szemből az ablakon keresztül látható részéről készítünk képet. Amit végül a képernyő nézetében jelenítünk meg.

Ehhez valahogy meg kell valósítani azokat a felületeket, amelyekről a fény a képre juthat. Erre az eszköz a térgeometria, ami során a tárgyakat geometriai objektumokkal fogjuk ábrázolni. A képszintézis során a program által kezelt alapobjektumok általában a geometria primitívek, mint például a poligon, gömb, fényforrás, stb. Manapság az elterjedt módszerek minden tárgyat háromszögekre (poligonokra) bontanak fel, mivel ez az a síkidom, ami szükségszerűen mindig konvex, vagyis alkotópontjai mindig egy síkban vannak. Ellenkező esetben ugyanis hibák és torzulások keletkezhetnek a képen. A háromszögünk meghatározásához kell három pont és az azokat összekötő élek, valamint egy normálvektor, ami a felületre merőleges, és megmutatja, hogy az objektum melyik irányból látható (lásd később). Erről egyelőre csak annyit, hogy gyorsasági okokból a 3D-s programok a tárgyakat mind üregesnek tekintik, és a felületüknek mindig csak az egyik, látható oldalát számítják. Még azt is elmondhatjuk, hogy kellő mennyiségű polinomból bármilyen görbe felület utánozható annyira, hogy a különbségek teljesen elvesznek. Gondoljunk csak bele, hogy egy 32 szöget milyen közelről kell megnéznünk, hogy ne kört lássunk belőle. Láthatjuk, hogy az emberi szem korlátait itt a magunk hasznára fordítottuk. Ezek a felületek, objektumok, amikről a fény a képre juthat, az általunk létrehozott virtuális világunkban foglalnak helyet. Ezért a képszintézis első lépése a virtuális világmodellnek a képszintézis program számára történő lefordítása. A világ-koordinátarendszerben rendelkezésre álló primitívek alapján, a képernyőn, azaz egy másik koordinátarendszerben kell képet készíteni. A koordinátarendszer váltáshoz szükségünk lesz a geometriai transzformációkra. 3D grafikában ez a transzformáció vetítést is tartalmaz, hiszen a modell 3 dimenziós, míg a kép mindig 2. Ezek után röviden átvesszük a képszintézis főbb részeit, természetesen később bővebben is tárgyaljuk azokat.

A képszintézis lépései

A távlat fogalma egyszerű: képzeld el, hogy a nézőpont nincs a képernyő felszínén, hanem bizonyos távolsággal mögötte helyezkedik el. Aztán konvertáld azt egy nézőpont-középpontú relatív koordinátarendszerré a következőképpen: a z koordináta a képernyő belseje felé nő. Most oszd el a koordinátáidat z-vel. Ennyi az egész. Persze nem kell az irányokat x, y és z-nek nevezned, ez a helyzethez illő leírástól függ. És persze el kell döntened, mi történjen a "képernyőből kifelé tartó irányú" dolgokkal - de ez már egy másik kérdés. Illetve még azt is el kell döntened, hány egységnyivel van a nézőpont a képernyő mögött (ezt kell hozzáadnod z-hez az osztás előtt). Sőt, ha talán még léptékezni is akarsz bizonyos dolgokat, hogy jobban nézzen ki az egész. Egyik sem túl nehezen megoldható. Ami viszont bosszantó, hogy nem akarsz osztást végezni minden a képernyőre rajzolandó pixelre. Ez például azt jelenti, hogy találkozhatsz olyan vonallal, amelynek mindkét vége a képernyőn kívül van, de bizonyos része látható. Ez viszont már az ütközések vizsgálatának problémája. Vagy még inkább a vágásé, ez csak egy előretekintés az arról szóló fejezetre. A háromdimenziós objektumok kétdimenziós képernyőre való rajzolása is fontos eleme a képszintézisnek. Sokféle módszer létezik ennek megoldására. Néhány megközelítés a látónégyszöget képezi le a helyszínre, minden pixelen keresztül sugarakat lövellve, majd a sugár által eltalált objektum szerinti színt kiválasztva. Más megközelítések a helyszínt képezik le a látónégyszögre, minden objektumot arra rárajzolva, és figyelembe véve melyik objektum melyik előtt helyezkedik el. A fenti leképezés tehát egyfajta levetítés, melyek közül a két legnépszerűbb a perspektív- és a paralell-projekció. A paralell-projekció elvégzéséhez például, csak el kell hagynod a z koordinátát és az objektumokat a látónégyszögre, kell vágnod. A perspektíva-projekció általános megközelítése szerint minden x és y értéket el kell osztanod z-vel, vagy annak valamilyen többszörösével. A képszintézis a modell azon részét fényképezi, amely a 2D ablakon belül, vagy a 3D ablak és a szem által definiált végtelen piramison belül van. Az ezeken kívül eső objektumokat, objektumrészleteket valamikor ki kell válogatni, és el kell hagyni. Ezt a folyamatot nevezzük vágásnak (clipping). A transzformációk több objektumot is vetíthetnek ugyanarra a képpontra. Ilyenkor el kell dönteni, hogy melyiket jelenítse meg, vagyis melyik takarja a többi objektumot. Ezt a lépést röviden takarásnak nevezzük. 3D grafikában nyilvánvalóan a szemhez közelebbi objektumot kell választani. Ha sikerült eldöntenünk, hogy egy képpontban melyik objektum látszik, akkor a képpontot ennek megfelelően ki kell színezni.
Először is, a tárgyaknak bizonyos felületi tulajdonságait kell meghatároznunk, például, hogy hogyan és mennyire veri vissza, illetve ereszti át a fényt, milyen színű és hasonlok. Ezek alapján lehet valamilyen módszerrel megállapítani, hogy milyen színű fény jut róla a kameránkba. Ugyanis a 3D grafikában a látható szín a térben fennálló fényviszonyoknak a függvénye, bár lehet egy szín is. Árnyalás a kép egyes pontjain keresztül a szembe jutó fény intenzitását határozza meg a hullámhossz függvényében. A hullámhosszfüggő intenzitás-eloszlás spektrumnak nevezzük. Ezen spektrum által keltett színérzetet kell a megjelenítőeszköz lehetőségeinek függvényében a lehető legpontosabban visszaadni, a spektrumot kell leképezni az eszköz által megjeleníthető hullámhosszokra és intenzitásokra (tone-mapping). Ezt az eljárást árnyalásnak nevezzük. Az árnyékoló algoritmusokra azért van elsősorban szükségünk, hogy egy tárgyat élethűen meg tudjunk jeleníteni. Ugyanis annál élethűbb egy tárgy minél több sokszögre tudjuk felbontani, ami viszont kezelhetetlen adatmennyiség. Itt jön be a csalás a dolgokba, az egyes poligonok felületet nem homogén színűnek ábrázoljuk, hanem egy árnyékoló algoritmussal módosítjuk. Így sokkal realisztikusabb képet kapunk. Azt próbáljuk kifejezni, hogy a természetben látható megvilágított felületek a fényforrástól, a felület térbeli helyzetétől, az anyag minőségétől, valamint a szemlélő helyzetétől függően különböző fényességűnek látszanak. Az árnyalt képet előállító algoritmusok, az előbb említett követelményeknek próbálnak eleget tenni. Természetesen minél élethűbb egy kép, annál hosszabb a kiszámításra fordított idő is.
A legtökéletesebb algoritmus a radiositys eljárás, ami teljesen valós fényszimuláción alapul. Hátrány az, hogy elméletileg végtelen számú visszaverődést kell kiszámítania. Ezek száma ugyan csökkenthető az élethűség rovására, de meg így is nagyon nagy a számításigénye. Sokszor nem is szükséges a grafikában, nagy erőforrásokat igénylő megjelenítést alkalmazni, például az oktatásban geometriai modellek bemutatására más algoritmus is kielégítő képet adhat. Viszont egy építész által megtervezett lakóház fotóminőségű képnek előállításra kiválóan használható, vagy gondoljuk a filmgyártásra. A ma használt legélethűbb módszer raytracing algoritmus, ami csak azokat a fénysugarakat követi végig, amelyek a kamerába jutnak (az árnyékokhoz is kellenek meg plusz fénysugarak), de ehhez fordítva kell haladnia a fény utján, a kamerából a tárgyakon át a fényforrásba elvégre máshogy nem tudható, hogy mely sugarak alkotják majd a képet. Ez az algoritmus is valós fizikai képleteket használ, de az ütközések száma itt is korlatozott egyébként két tükröződő tárgy között, a végtelenségig ugrálhatna a programunk. A raytracingnek igazából egyetlen nagy hátránya van, hogy még a mai nagyteljesítményű gépeken is időigényes a számítás. A nagy számításigény kiküszöbölésére számos alternatív eljárás született mára. Ezek közül a legegyszerűbb a Gouraud-árnyékolás (ő egy francia matematikus, aki kitalálta), ami főleg gyorsasága miatt kedvelt a játékokban. A lényege az, hogy egy egyszerű színátmenetet generál a poligon felületre, amit az átmenet irányának, valamint kezdő és végszínének gondos megválasztásával egész élethűre lehet hangolni. Ennél fejtettebb a Phong-algoritmus (vietnami matematikus). Ez mar a valós fényviszonyokat veszi figyelembe, és képes a felületi becsillanás (specular highlight) számítására is. A jelenség lényege az, hogy a fény a felület egy kis részéről nagyon erősen verődik vissza, nagyjából ott, ahol a fényforrás tükörképe lenne.
A grafikusok eszköztárak a fentieken kívül meg egy sor egyéb funkciót tartalmaznak általában. Füst, köd modellezése, a vetett árnyékok megjelenítése, a különféle, geometriai testekkel nem modellezhető tárgyak és jelenségek szimulálása, valamint a nem, vagy csak túl bonyolultan modellezhető felületi mintázatok megjelenítését szolgáló textúrázás. Számos példáját láthatjuk manapság a 3D-s játékokban is.

Felhasznált és ajánlott irodalom
Foley, van Dam, Feiner, and Hughes: "Számítógépes grafika: Alapelvek és gyakorlat" c.
Dr. Szirmay-Kalos László: Számítógépes grafika, 2001
Füzi János: Interaktív grafika, 1997

DirectX-ről érthetően 1-2.

Képzeld azt, hogy a számítógéped egy szendvics! A hardver az egyik szelet kenyér, a szoftver a másik. Ami a két szelet közé megy „tölteléknek”, azok a driverek és a programozási felületek (API). Ez a töltelék végzi a fordítást a hardver és a szoftver között. Így a programozónak nem kell a programját mindegyik hardverre külön-külön megírnia, ehelyett írhatja az operációs rendszer számára, amiben a driverek majd lefordítják azt a hardvernek. A programot írhatja egy programozási felületre (API) is, aminek ugyanez a szerepe. Ennek az az előnye, hogy a programozónak nem kell az összes eszközt ismernie, ami a piacon kapható; a driverei mindent lefordítanak, hogy a hardverek „megértsék”.
A DirectX és az OpenGL jelenleg a legtöbbet használt API a 3D-s programoknál. A játékot nem egyetlen videokártyára írják, hanem a DirectX, vagy az OpenGL parancsait használva, ami majd átkonvertálja a videokártyának a parancsokat.
A DirectX-nek már sok változata van. Ha azt mondjuk, hogy egy játék DX9-es, akkor ez azt jelenti, hogy a játék a DirectX 9 utasításait használja. Ahhoz, hogy játszani tudj ezzel a játékkal, szükséged van a DirectX 9-re és egy azt támogató videokártyára. Amennyiben neked csak DirectX 8-as utasításokat ismerő videokártyád van és a játék olyan utasítást akar végrehajtatni, amit a videokártyád nem ért, akkor megpróbálja azt emulálni. Ez természetesen nem tökéletes, így a látványvilág nem lesz olyan szép, mintha egy DirectX 9-es videokártyával játszanád.
Ajánlott, hogy mindig a legfrissebb DirectX legyen a gépeden. Ezt letöltheted a Microsoft oldaláról. Figyelj azonban, mert amit elsőként felkínál letöltésre, azt azonnal telepíteni is akarja! Ha más számítógépre akarod telepíteni a DirectX-et, akkor a lap alján található redistributable változatot kell letöltened. Ha szeretnéd megtudni, hogy milyen DirectX verzió van a gépeden a következőket kell tenned: Start menü : Futtatás : DxDiag Ha felugrik egy kérdés, válaszolj nemet! Majd a főablakban a System Info rész legalján lesz kiírva a DirectX Version.
Az előzőekben leírtuk, hogy mi az a DirectX és milyen verziói vannak, azonban azt nem, hogy ezek között mik a különbségek. Tehát mi teszi jobbá a DirectX 7-et a DirectX 6-nál?
Általában azért adnak ki új változatot, hogy a rendszer felismerje az új grafikus kártyák erőforrásait, tehát képes legyen ezeket kihasználni, ezzel növelve a 3D-s teljesítményt és javítva a képi világot. A DirectX 6 fő innovációja a bump mapping bevezetése volt. Ezzel a technológiával lehetséges egyenetlen felületeket létrehozni a tárgyakon, így növelve a valósághűséget. A GeForce 256 óta a grafikus chipek azzal is könnyítik a CPU munkáját, hogy a különböző tárgyak generálásához szükséges számítások egy részét a GPU végzi a processzor helyett. Ez a transformation and lighting technológia, melyet T&L-ként rövidítünk. A DirectX 7 azért lett kiadva, hogy ezeket funkciókat kiaknázza. A DirectX 7-es kártyák: GeForce 256, GeForce 2, GeForce 4 MX, GeForce PCX 4300, Radeon 7000, Radeon 7200 és Radeon 7500.

A DirectX 8-al érkeztek a ma jól ismert Pixel és Vertex Shader effektek, még valósághűbbé téve a 3D-s képeket: a 3D-s objektumok sok száz, vagy ezer poligonból (háromszög, vagy négyszög) épülnek fel. Ezekre „húzzák” rá a textúrákat, megalkotva így a 3D-s elemeket. A Vertex Shaderrel a program képes megváltoztatni minden egyes poligon minden egyes vertexét (vertex: a poligonok csúcspontja). A Pixel Shader programmal lehetséges minden poligon minden pixelét (azaz képpontját) megváltoztatni. Amíg ezek a programok meg nem jelentek ez nem volt lehetséges, tehát csak úgy lehetett a vertexeken és a pixeleken változtatni, hogy az az egész poligonra kihatott.
A DirectX 8.0-val a Pixel Shaderbe egyszerre 12 utasítást lehetett programozni, ám ez a limit nagyon alacsony volt, így hamarosan megjelent a DX 8.1, ami a határt 22 utasításra emelte. Az ezt támogató kártyák: GeForce 3, GeForce 4 Ti, Radeon 8500, Radeon 9000, Radeon 9100, Radeon 9200, és Radeon 9250.
A képi világ további javításának érdekében jelent meg a DirectX 9.0, amivel már 92 utasítást lehetett programozni a Pixel Shaderbe. Minden GeForce FX kártya és a Radeon 9500-as szériától egészen az X850XT-ig DirectX 9.0-s. A DirectX 9.0c pedig 65535-re növelte a Pixel Shaderbe programozható utasítások számát. Ezt a GeForce 6, GeForce 7 és Radeon X1*** sorozatú kártyák használják ki (valamint ennél újabb társaik).

Kolombusz | 2006-11-22