:

Szerző: Bőle György

2000. július 10. 00:00

Reflektorfényben az FSAA

FSAA. Ez a rövidke négy betűs kifejezés hónapokig szinte napi rendszerességgel megjelent a híroldalak hasábjain. A 3dfx erre a négy betűre alapozta új Voodoo5 termékcsaládjának marketingjét, ezzel hirdetvén az új eljárás és kártyái "dicsőségét". Végletekig részletes cikkünk annak jár utána, hogy vajon mit is fed ez négy betű valójában, illetve életképes-e a rövidítés által takart 3D-s eljárás.

Írta: Soós Árpád

A videokártyák gyors fejlődésével nemcsak a sebesség növekszik rohamosan, de a gyártók a képminőség javításával is megpróbálják elnyerni a vásárlók kegyeit. Ennek egyik útja, hogy a hardverek lehetőséget biztosítanak a programozóknak a grafika kidolgozottságának, részletességének, valamint a 3D felületek élethűségének növelésére. Ezt a fejlődést azonban egyelőre alig érzékelhetjük, hiszen az új kártyák ezzel csak a lehetőséget biztosítják, aminek kihasználásához új, ezeket támogató játékokra van szükség, ezért ez mindenképpen egy lassú folyamatot jelent. Van azonban egy mód arra, hogy a képminőség a régi játékok esetében is javuljon: ez pedig a mostanában sokat emlegetett teljes képernyős antialiasing, vagy elterjedt rövidítéssel FSAA. Ez utóbbi a számítógépes grafikával foglalkozók számára eddig is jól ismert fogalom volt, de lassan kénytelen lesz megismerkedni vele minden "mezei" játékos is. Éppen ezért itt az ideje, hogy egy kicsit körüljárjuk a témát.

Az aliasing problémája

Az FSAA rövidítés a Full Scene Anti-aliasing-ból, vagyis a teljes képernyős antialiasing-ból ered. Ebből következően talán nem meglepő, hogy ez az eljárás az ún. aliasing jelenség csökkentését hivatott elvégezni. De mi is az az aliasing?

Ez a jelenség a mintavételezési eljárásoknál lép fel. Mintavételezéssel a számítástechnikában gyakran találkozunk, hiszen a számítógép csak digitálisan képes adatokat eltárolni, ezért az eredetileg analóg adatokat csak megfelelő sűrűséggel vett minták segítségével képes rögzíteni. Erre talán a legegyszerűbb példa a hangrögzítés. A hang a légnyomás időbeli változása. Ha ezt számítógéppel rögzíteni szeretnénk, bizonyos időközönként meg kell mérnünk a nyomást (mintavétel) és ezt bizonyos pontossággal rögzítenünk kell. Az erre kialakult (CD) szabvány 44,1 kHz-es sűrűségű (másodpercenként 44100 minta) mintavétel a nyomásadatok 16 bites pontosságú rögzítésével. Ezt a mintavételezést mutatja be az ábra egy középmagas, kb. 1500 Hz-es szinuszhullám esetében.


Láthatjuk, hogy a közelítés meglehetősen pontos marad. De mi történik, ha tovább növeljük a hang magasságát (frekvenciáját)? Egy 44,1 kHz-es hang esetében a következő eredményre jutunk.


Láthatjuk, hogy akárhol is kezdődik a mintavételezés (fehér körök vagy sárga háromszögek) a mintavétel nem képes reprezentálni az eredeti hullámot. Ha azonban dupláznánk a mintavételezést (körök és háromszögek együtt), akkor már egy durva közelítést kapnánk. Ezt a sejtést az az elmélet is alátámasztja, ami kimondja, hogy adott frekvenciájú (részletességű) jel reprezentálásához legalább kétszer akkora sűrűségű mintavételezés kell. Ezek után gondolhatnánk azt is, hogy már egyszerű a dolgunk: a tárolni kívánt legnagyobb részletességű jelnél kétszer akkora részletességű mintavételezést kell alkalmaznunk. Sajnos ez nem ilyen egyszerű...

[oldal:Az aliasing jelenség #2]

Nézzük például a következő mintavételezést:


Ezt kapnánk, ha egy 15 kHz-es hangot (ami akkor is jelen lehet, ha mi csak a 11 kHz alattiakra vagyunk kíváncsiak) mintavételeznénk 22,05 kHz-en. Jól látszik, hogy a szabályos, túl magas frekvenciájú jel erős zajként szűrődik át a mintavételezésbe. Tehát hiába elegendő számunkra egy max. 11 kHz-es tárolás, a magas hangok zajként be fognak zavarni a felső frekvenciatartományban. Ez a "zajátszűrődés" az aliasing, ami a legtöbb gondot okozza a mintavételezéseknél. A hangrögzítésben ez egyszerűen megoldható: a CD minőségű mintavételezés legfeljebb 22,05 kHz-es hangot tud reprezentálni. Ez az érték azonban nem véletlen: ez ugyanis az emberi hallás felső határa (a határ egyéntől és életkortól függően 16-22 kHz között van). Vagyis az efölötti átszűrődő zajt már úgysem lehetne meghallani, ezért nem gond.

Amennyiben 22,05 kHz-es tárolásra lennénk korlátozva (tárolási hely vagy lejátszási képesség miatt), ki kellene szűrni a magas komponenseket. Ezt egyszerűen elérhetjük, ha pl. négyszer olyan sűrűn veszünk mintákat, majd ezeket négyesével átlagoljuk. A fenti példa esetében ez a következőképpen néz ki:


Látható, hogy az átszűrődés jóval alacsonyabb, az egyes (végleges, átlagolt) minták (narancssárgával jelölve) pedig kevésbé érzékenyek az egyedi értékekre. A magasabb mintavételezést és átlagolást túlmintavételezésnek nevezzük (supersampling, SS).

[oldal:Aliasing jelenség a számítógépes grafikában]

Mint látni fogjuk, a képek mintavételezésénél is nagyon hasonló problémák lépnek fel. A különbség itt csupán annyi, hogy nem időben (pontosabban ott is, de az egy más téma), hanem térben, két dimenzióban történik a mintavételezés. Vagyis a képernyő pixeljeinek megfelelő sűrűséggel veszünk a felbontástól függően "szélesség x magasság" mennyiségű mintát a képből, egyenlő térközönként, a képernyő pixeljeinek megfelelő helyeken. Ezt a következő ábra mutatja.


A szürke-fehér pepita minta az egyes pixelek területét jelentik, a fekete pont pedig az, ahonnét mintát véve az egész pixel megkapja a színét. A kék terület jelenti az "elméleti" képet, ahonnan a mintát vesszük. A jobb oldali kép a mintavétel eredményét mutatja.

Ahogy a hangoknál, itt is fellép az aliasing jelenség, ha a mintavételezés sűrűségéhez képest túl aprólékos részleteket akarunk megjeleníteni.


Amint látható, bizonyos részletek egyáltalán nem jelennek meg, bizonyosak pedig túl vannak reprezentálva. Ez önmagában nem nagy baj, ha elég kicsik a pixelek. Az igazi probléma akkor jelentkezik, ha mozgatni kezdjük a képet: ekkor az egyes kis részletek hirtelen hol felbukkannak, hol teljesen eltűnnek, nagyon zavaró vibrálást hozva létre (átszűrődő zaj). Ezt szokás pixel-ugrálásnak (pixel popping) nevezni. Talán ez a kevésbé zavaró jelenség, csak akkor fordul elő, ha valami nagyon messze van, mert jelenleg a 3D játékok geometriai kidolgozottsága igencsak elnagyolt, az egyes polygonok eléggé nagyok. Az igazi problémát a textúrák jelentik, hiszen a textúra részletei (pixelei), ha az adott tárgy távolodik, igen gyorsan kisebbek lesznek, mint egy képernyő-pixel. Lássunk erre ismét csak egy extrém példát.


A fenti textúra a mintavételezés után egyáltalán nem fog látszani, tiszta fehér területet kapunk. Ráadásul amint egy kicsit vízszintesen elmozdulunk, azonnal tiszta feketébe vált, majd vissza tiszta fehérbe és így tovább. Ilyen egyértelmű példával szerencsére ritkán találkozunk, de hasonlóan zavaró jelenséget tapasztalunk szinte minden textúrával, ha az egy kicsit is kontrasztos. A képernyőn egymás melletti képpontok a textúrában akár sok pixellel is odébb találhatók, ami egy fura kuszaságot hoz létre a képernyőn, ráadásul minden kis mozdulatra teljesen megváltozik, kissé hasonló hatást hozva létre, mint amikor a TV nincs megfelelő adóra beállítva. A túl finom részletek így szűrődnek át zajként. Ezt a jelenséget hívják texture-shimmering-nek, magyarul talán zizegésnek mondhatnánk.

[oldal:Mintavételezés a számítógépes grafikában]

Joggal merül fel a kérdés, hogy a jelenlegi játékokban miért nem találkozhatunk akkor ilyen zavaró jelenséggel. Ezzel nemsokára foglalkozunk, de van egy egyszerű mód arra, hogy megnézhessük, milyen zavaró is ez a zizegés. Ehhez csak egy quake motorra épülő játékra van szükség. Váltsunk alacsonyabb felbontásba (pl. 640x480), válasszunk lehetőleg magas textúrarészletességet, majd Q1 és Q2 esetében a konzolban írjuk be: gl_texturemode gl_linear. Soldier of Fortune esetében ezt nem csak a konzolban, hanem a grafikai beállításoknál is megtehetjük: F2, majd állítsuk a texturemode-ot none-re. A Q3-ban kissé más a szintaktika: /set r_texturemode gl_linear. Voilá, lehet "gyönyörködni" (visszaállítás lásd később). A jelenség természetesen akkor a leginkább zavaró, ha a képernyőfelbontáshoz képest a "háttérben" a textúrafelbontás magas. Ez akkor fordul elő, ha egy tárgy messze van, és/vagy ferdén látjuk. A képernyő-felbontás növelése természetesen segít, hiszen távolabb válnak csak túl részletessé a textúrák: magas felbontáson (1280*960, 1600*1200) már jóval kevésbé zavaró a jelenség, de továbbra is megvan.

A hatásra a megoldási lehetőség itt is hasonló, mint a hangok esetében. A jelenlegi megjelenítés-technika nem engedi meg, hogy a képernyőfelbontást a szem érzékenységének felére, vagy akár közelébe növeljük (még az adott monitor legkisebb pixelméretének alkalmazásával is jól érzékelhető az aliasing), ezért ez az út nem járható. Marad a magas frekvenciák szűrése túlmintavételezéssel és átlagolással. Lássuk erre a tipikusan bemutatott példát!


A fenti példáknál egy-egy pixel színének megállapításához nem csak egy, hanem több mintát veszünk a pixel területéről. A mintavételi pontok szabályosan, egymástól egyenlő távolságra vannak elrendezve. Négyszeres mintavételezés esetében ez a következőképpen néz ki:


Vagyis a mintavételi pontok szabályosan vannak elrendezve, majd négyesével átlagolva, hogy a végleges pixel színét meg lehessen határozni. Ez alapján az antialiasing értelmét egy másik, talán egyértelműbb módon is be lehet mutatni: ha már a fizikai jellemzők (monitorok megjelenítése) arra "kárhoztatnak", hogy négyzet alakú területek összességét jelenítsük meg, akkor a legjobb, amit tehetünk, ha egy-egy négyzet színét az egész "alatta" lévő kép határozza meg, nem csak annak egy-egy pontja. Ennek közelítését érhetjük el, ha több, a pixel területéről vett minta átlagát vesszük.

A fenti példa mutatja, hogy négyszeres mintavételezéssel már nagyon jó eredményeket érhetünk el. A túlmintavételezés legegyszerűbben úgy érhető el, ha magasabb felbontásban készítjük el el a képet, majd átlagolással visszakicsinyítjük (Photoshopban és Paint Shop Pro-ban bilinear resample). Ezért a 4, 9 és 16-szoros túlmintavételezés nem véletlen, az a 2, 3 és 4-szeres (egyik tengely mentén vett) felbontásnak felel meg. Ezért ezeket a túlmintavételezéseket szokás 2x2, 3x3 és 4x4-es mintavételezésnek is nevezni. Ezt fontos megjegyeznünk, mivel manapság óriási keverés van e tekintetben a két terminológia felcserélésével: sokszor pl. a 2x2-es (4x-es) túlmintavételezést keverik a 4x4-essel, vagy a 2x-est a 2x2-essel. A terminológia remélhetőleg lassan le fog tisztulni és egyértelművé válik.

A fenti példa ugyan szemléletes, de nem mutatja kellőképpen az antialiasing hatását, az ugyanis az apró részletek és mozgás közben látható igazán. Ennek demonstrálására írtam egy programot, amelyet itt tölthettek le. Ennek használatára kis gyakorlás után rá lehet jönni. A jobb alsó sarokban választhatjuk ki a kívánt antialiasing módszert. Ezekről részletesebben is szó lesz, egyelőre elég, ha csak a túlmintavételezés feltüntetett fokára figyelünk. Az RG rotation angle tolókát egyelőre ne változtassuk. A demo jól mutatja az eddig tárgyalt aliasing jelenségeket és azt, hogy a túlmintavételezés ezt hogyan szünteti meg. A programmal más képet is használhatunk: elég az image.bmp file-t kicserélni a sajátunkra. Nagyon fontos azonban, hogy ez 24 bites bmp legyen. Javaslom, hogy bonyolult, kontrasztos, és nem antialiasolt képen próbálkozzunk. Javasolt továbbá nagy felbontású, legalább 600x600-as képek használata.

Érdemes kipróbálni a "blur" módszert is, mivel sokan azt hiszik, hogy az antialiasing egyszerűen a kép elmosása. Ez nem igaz: az elmosás (blur) a szomszédos pixeleket átlagolja magasabb mintavételezés nélkül.

[oldal:A jelenlegi videokártyák antialiasing megoldásai #1]

Joggal merül fel a kérdés, hogy ha csak a videokártyák legújabb nemzedéke támogatja az antialiasingot, akkor eddig miért nem találkozhattunk ennyire zavaró jelenséggel. A válasz egyszerű: az aliasing jelentős részét már régóta meg tudják szüntetni a videokártyák. A megoldás igen egyszerű: mivel aliasing ott keletkezik, ahol a megjelenítendő ábra jóval részletesebb, mint a mintavételezés részletessége (képernyőfelbontás), meg kell próbálni a képernyőfelbontásnak közel megfelelő részletességű textúrákat alkalmazni. Mivel a képernyőn megjelenő textúra a távolsággal egyre kisebbé válik, a képernyőfelbontáshoz képest egyre részletesebb lesz. Ezért minden textúrának több változatát kell alkalmazni: minél távolabb kerül az adott textúra (pl. egy faldarab) annál kisebb és kisebb méretét alkalmazza a kártya a kirajzoláshoz, így kerülve el az aliasing megjelenését. A textúra kisebb méretű változatait (az un. mipmapeket) előre ki lehet számolni, átlagoló kicsinyítést alkalmazva, ezzel az adott textúra mintegy "előantialiasingját" hajtva végre. Ez a módszer az ún. mipmapping. Jól demonstrálja ezt a DirectX SDK mipmap példaprogramja (itt letölthető). A bal oldali faldarabon ezt nem alkalmazzák, ezért a távolban jól látható lesz az aliasing. A jobb oldalon láthatjuk a mipmapping hatását (a textúrán látszik, hogy éppen melyik változatát használja a kártya). A következő kép a Soldier of Fortune-ból való. Az első a mipmapping lekapcsolásával, a második mipmappinggal készült.


Bár az első kép nem is tűnik nagyon rossznak (kusza, de legalább éles), ne felejtsük, hogy a kuszaság minden mozdulatra "zizegni" kezd.

A mipmapping azonban egy új jelenséget hoz, amit a zöld körökkel jelöltem. Ez pedig a mipmap sávosodás. A kártyának ugyanis el kell döntenie, hogy mikortól alkalmaz alacsonyabb felbontású textúrát. A váltásnál egy (különösen mozgásban és kontrasztos textúráknál) jól észrevehető határvonalat generál, ami sokszor zavaró lehet. Ez nagyon jól érzékelhető például a Half-lifeban és a SoF-ban drótkerítéseknél.

Ennek megszüntetésére találták ki az ún. trilinear filteringet. Alaphelyzetben a bilinear filtering az aktív ma a legtöbb játéknál. Ennek feladata kissé ellentétes az antialiasinggal: ha a textúrák túl közel kerülnek és túl durva felbontásúvá válnak, e nélkül "elkockásodnak". A bilinear filtering az adott képpont környezetében lévő négy textúrapontot a képpont helyzetének megfelelően súlyozottan átlagolja, ezért a közeli textúra "kisimul". A trilinear az átlagolásba bevonja a szomszédos mipmap megfelelő pozícióit is, ezért a mipmap sávok gyakorlatilag nem látszanak. A következő kép így készült.


Ennek azonban egy újabb hátránya van: egyrészt bizonyos kártyák esetében érezhetően lassabb (ez manapság már nem probléma), másrészt csúnya színszórás, "recésedés" látható a korábbi mipmap sávhatárok környezetében, ráadásul még mosottabbá teszi a textúrákat.

[oldal:A jelenlegi videokártyák antialiasing megoldásai #2]

Ezeket a módszereket javaslom "munka" közben megfigyelni, mivel leginkább mozgás közben látható a hatásuk. A textúramódokat a korábban említett módon válthatjuk a konzolból. Az egyes beállítások:

Texturemode hatás
gl_nearest filter és mipmap kikapcsolva
gl_linear bilinear filtering, mipmap kikapcsolva
gl_linear_mipmap_nearest bilinear filtering, mipmapping-gel
gl_linear_mipmap_linear trilinear filtering

A kipróbáláskor a mipmapping-nek még egy üdvös hatását is észrevehetjük: bekapcsolásakor gyorsul a játék. Ez abból adódik, hogy a messzebb lévő tárgyak esetében kisebb textúrákat alkalmazhat a kártya, így a textúra-cache jobban kihasználható.

Mint láthattuk, a mipmapping segítségével igen jelentős javulás volt elérhető, de még mindig nem tökéletes az antialiasing: egyrészt a textúrák esetében sem tökéletes a megoldás (a felbontás sávosan változik, sok helyen elmosást eredményezve), a polygonok széleire pedig egyáltalán nem jelentett megoldást. Ezeken a bajokon a minőséget tekintve "mellékhatás" nélkül csak a túlmintavételezés segíthet. Az alábbi kép eredetileg 1280x960-ban lett kiszámolva, amit aztán visszaméreteztem 640x480-ra bilinear resample-val (átlagolással).


Jól láthatók az előnyök: a számításokhoz a túlmintavételezés miatt már kétszer akkora mipmapek használhatók aliasing megjelenése nélkül, aminek a következménye a mindenhol részletes textúrák mipmap-sávok nélkül. Érdemes a különböző módszerek egy-egy részletét kissé kinagyítva összehasonlítani.


Jól látszik az erőteljes javulás. Nincs mipmap sávosodás, részletesebbek, tisztábbak a textúrák, nincs aliasing (ez utóbbi inkább mozgásban látszana). Ez egy nagyon fontos adalék, amit a felülmintavételezés nyújtani képes, és ez az, amit sokszor el is felejtenek, csak az antialiasing másik hatását hangsúlyozva. Ez pedig az élek lépcsőzetességének (jaggies) csökkentése, eltüntetése. Hogy ezt látják fontosnak az emberek, az nem meglepő, hiszen míg a mipmapping sokat segített a textúrákon belül már eddig is, a poligonszéleken nem volt képes javítani, azok részletessége mindig magasabb, mint a képernyőfelbontás, ezért aliasing mindig jelentkezik. Itt csakis a túlmintavételezés segíthet, ezért is volt itt a legnagyobb a javulás. Ezt nem is akarom nagyon magyarázni, a képek magukért beszélnek. Hasonlítsuk össze az FSAA képet bármelyik korábbival: az élek kisimultak. Jól látszik ez minden kontrasztos él esetében: pl. a fegyveren, a gyertyatartón vagy a csilláron.

[oldal:FSAA a legújabb videokártya- generációval: 3dfx Voodoo5]

Ha az FSAA megvalósítása technikailag ilyen egyszerű (egy magasabb felbontás visszaátlagolása), akkor joggal merülhet fel a kérdés, hogy eddig miért nem alkalmazták a kártyákon. A válasz nagyon egyszerű: nem volt elegendő hozzá a teljesítmény. A kétszer akkora felbontás kiszámításához pontosan négyszer annyit kell dolgoznia a videokártyának, ami igen durván csökkenti a teljesítményt, egy régebbi videokártyát ez a játszhatatlanságig lassított volna.

Ennek ellenére nem teljesen igaz, hogy eddig nem támogatták: az nvidia kártyákban a riva 128 óta benn volt a lehetőség, be lehetett kapcsolni. Csak éppen gyakorlatilag használhatatlan, túl lassú volt. Az újabb driverekből ráadásul kivették a bekapcsolás lehetőségét a TNT és TNT2 kártyák esetében.

FSAA-ra ezért csak a megfelelő teljesítmény (fillrate) estében lehetett gondolni. Ezért először a most megjelent újabb videokártya-generáció esetében volt megvalósítható. A 3dfx az új Voodoo család tervezésekor már erre koncentrált a más gyártóknál már általánossá vált egyéb funkcionalitás (32 bites rendering, nagy textúrák támogatása) és az egyéb T-buffer effektek mellett. Az új Voodoo család tulajdonsága, hogy párhuzamosított feldolgozást tesz lehetővé: a Voodoo5-5500-as kártyán két VSA-100 egység dolgozik külön, saját memóriaterületek felhasználásával, ami a teljesítmény duplázását hozza. A chipek megvalósítják a T-buffer technikát: a képet köztes, belső bufferekbe számítják ki, amelyek kombinálásával különböző hatások valósíthatóak meg. Ezek közül a legfontosabb és jelenleg az egyedül használható az FSAA. Ennek megvalósítása a következő: a VSA-100 egységek négy képet számolnak ki: mindegyik az eredeti, kiszámítandó felbontású, de kicsit el vannak tolva egymáshoz képest, a mintavételezés kissé (közel fél pixellel) eltolva történik. Ez gyakorlatilag ekvivalens a magasabb felbontás kiszámításával: ha a módszert átgondoljuk és megnézzük a korábbi, 4x-es túlmintavételezés rácsának képét, láthatjuk, hogy a Voodoo5 által kiszámított egyik kép csak a bal felső almintákat tartalmazza az eredeti felbontáson, a második csak a jobb felsőt és így tovább. Ezzel előállnak a magasabb felbontás pixeljei, csak éppen négy különböző képben. Ezt a négy képet ezután kirajzolás előtt egymásra átlagolják, így érik el az FSAA-t.

Elméletileg és a teljesítményt tekintve tehát ez a módszer is ekvivalens a magasabb felbontásban való kiszámítással és visszaátlagolással, azonban két eltérés is található, ami a minőséget befolyásolja. Egyrészt a jelenlegi meghajtóprogramokkal a V5 mind a négy esetben az eredeti (kis) felbontás mipmap szintjeivel számolja ki a képeket, vagyis nem képes kihasználni azt, hogy az FSAA miatt a kétszer akkora mipmapek esetében sem lép fel aliasing és így nem lesznek tisztábbak a textúrák, ahogy korábban láttuk. A később megjelenő driverek segítségével ez várhatóan állítható lesz. Ebben az esetben azonban valamelyest lassulni fog a kártya a nagyobb mipmapek miatt.

A 3dfx azonban alkalmaz egy "trükköt": a mintavételezési rácsot kissé elforgatják az eredeti pozícióhoz képest, kb. 20 fokkal. Ez kb. a következő mintavételezési rácsot eredményezi (alul a vonal mintavételezése látható):



Ennek előnye akkor látható, ha összehasonlítjuk a hagyományos módszerrel:


Vagyis az elforgatott módszer jobb élsimítást eredményez a közel vízszintes (és függőleges) élek mentén. Ez abból adódik, hogy a mintavételezési pontok a vízszintes vagy függőleges tengelyre vetítve kétszer olyan sűrűn helyezkednek el (amennyiben a forgatás megfelelő szögű). A 3dfx valószínűleg erre alapozva hangoztatja, hogy az ő FSAA-juk egy 16x-osnak felel meg. Ebből persze tessék gyököt vonni: a szinte teljesen vízszintes vagy teljesen függőleges élek esetében az élsimítás minősége tart a 16x-oséhoz, minden más él esetében azonban rosszabb és ami a lényeg: a textúra-zizegés és pixelugrálás megszüntetésében semmivel sem jobb, mint a hagyományos 4x-es eljárás (lásd az FSAA demo programot). Ennek ellenére az nyugodtan kijelenthető, hogy élsimításra ez a legjobb 4 mintás FSAA módszer.

[oldal:3dfx Voodoo5: Rotated Grid Supersampling]

Semmi sincs azonban ingyen: a forgatás a közel átlós vonalak esetében rontja a simítást. Ez utóbbi azonban nem nagyon számít, hiszen a közel vízszintes és közel függőleges élek esetében sokkal feltűnőbb az aliasing, ezért összességében sokat tud javítani az élsimítás minőségén. A másik kisebb hátrány, hogy a pixel színpontossága a forgatás miatt kissé romlik, de ez sem igazán számít. A két módszerről és általában az FSAA-ról az angolul tudók kitűnő leírást találnak ebben a pdf file-ban. Ezt a Beyond3D készítette a 3dfx megbízásából.

A "hagyományos" módszert egyébként rendezett rácsú felülmintavételezésnek (Ordered Grid Supersampling, OGSS), a forgatottat talán nem meglepő módon forgatott rácsú felülmintavételezésnek (Rotated Grid Supersampling, RGSS) nevezzük. Ezzel a demo programban már tudjuk a legtöbb FSAA módszer jelentését (a 2.25x módszert később mutatom be). Az RG rotation angle a mintavételezési rács elforgatási szögét jelenti: alaphelyzetben ez 20 fok, érdemes vele kísérletezni.

A 3dfx két minőségi fokot kínál: az egyik a fent leírt 4x-es RGSS mintavételezés, a másik a kétmintás (2x) mintavételezés. Ennek mintavételi pontjai vélhetően az OGSS bal felső és jobb alsó pontjai lehetnek, hiszen a forgatás itt csak rontaná a minőséget (gondoljunk csak bele, hogy miért). Ez gyengébb minőséget ad, de a teljesítményigénye is csak feleakkora. Ez a mód ugyanolyan viszonyban áll a 4x OGSS-sel, mint a 4x RGSS a 16x OGSS-sel: vagyis extrém esetekben az élsimítás minősége megközelítheti a 4x OGSS-ét, de minden más vonatkozásban rosszabb.

A 3dfx FSAA megoldásának van még egy előnye: az FSAA megoldás teljesen transzparens, vagyis bármelyik régi játék esetében bekapcsolható, bármilyen API (DirectX, OpenGL, Glide) esetében. Ez a Voodoo5 esetében azért könnyebben megoldható, mert a kártyák nem egy nagy felbontású, hanem négy eredeti felbontású képet számolnak. Hogy ez előbbi miért probléma, azt lásd később.

Az OGSS és az RGSS módszerek összehasonlítása a következő ábrán látható:


A közel függőleges éleken az RGSS jobb simítást ad. Jól látszik az is, hogy a jelenlegi beállításokkal a Voodoo5 textúrái mosottabbak.

[oldal:Az nVIDIA GeForce család: Ordered Grid Supersampling]

Az nVIDIA a GeForce család őszi bevezetésével lépéselőnybe került a többi gyártóval szemben. A GeForce gyorsabb (DDR) memóriával rendelkező verziója volt talán az, ami először nyújtotta azt a teljesítményt, ami már elegendő lehetett az FSAA alkalmazásához. Az nVIDIA azonban ezt nem tekintette elsődleges prioritásának. Az idő múlásával azonban a 3dfx lassan elkészült a saját új generációjával, ami nagy teljesítményt ígért és az FSAA támogatását állította előtérbe. Hogy ezen a területen is felvehesse a versenyt, az nvidia úgy döntött, hogy újra visszarakja a drivereibe az FSAA támogatását (csak GeForce-on elérhető). Erre márciusban, az 5.08-as Detonator driverrel került sor. A támogatott megoldás először csak a 4x OGSS volt és csak OpenGL-ben volt elérhető. Azóta a driverek sokat fejlődtek és az első hivatalos frissítést a napokban adták ki Detonator 2 driver néven, ami tulajdonképpen a korábbi 5.22-es driver.

Az FSAA támogatása sokat fejlődött: végre Direct3D-ben is elérhető az FSAA és az OpenGL megoldás is új módokat kapott. Még az 5.16-ban sem volt D3D FSAA támogatás: bár lehetett választani, de nem volt aktív. Ez sokakat megtévesztett, ezért ne higgyünk az olyan teszteknek, ahol a D3D FSAA minőséget lehúzzák, ha nem legalább 5.22-es drivert használnak: ilyenkor ugyanis egyáltalán nem aktív az FSAA.

A megvalósítás a hagyományos: a kártya belsőleg magasabb felbontásban számol, majd visszakicsinyít, vagyis OGSS módszert használ.

OpenGL-ben új, hogy választható egy köztes megoldás, ami felveszi a versenyt a 3dfx 2x-es módjával: ez a 2.25x-ös felülmintavételezés. A képet 1.5x-ös felbontásban mintavételezik, majd ezt kicsinyítik vissza. Ez gyengébb minőségű, mint a 4x-es OGSS, de közel feleakkora teljesítményigényű.

Direct3D-ben nyolc minőségi fokozat található:

1 1x2-es felülmintavételezés, vagyis csak függőlegesen vesznek duplaannyi mintát
2 4x (2x2) FSAA alacsony felbontású mipmapekkel (a la 3dfx)
3 4x (2x2) FSAA magas felbontású mipmapekkel (a bemutatott szebb textúraminőség)
4 4x (2x2) FSAA magas felbontású mipmapekkel, speciális szűrővel. Erről egyelőre nem sokat tudunk, valószínűleg nagyobb elmosást eredményez a simább szélek érdekében
5 9x (3x3) FSAA alacsony felbontású mipmapekkel
6 9x (3x3) FSAA magas felbontású mipmapekkel
7 16x (4x4) FSAA alacsony felbontású mipmapekkel
8 16x (4x4) FSAA magas felbontású mipmapekkel

A 4 feletti minőség ugyan nem baj, hogy megvan, de nem igazán használható. Az egyik probléma a memóriaigény: mivel belsőleg 9x, illetve 16x akkora képet készít a kártya, nagyobb felbontáson gyorsan kifut a memóriából (a memóriaigényeket megtaláljuk a Beyond3D 5.22-es driverről szóló kimerítő és kitűnő cikkében). A másik gond a teljesítmény: a fillrate ekkor 1/9 illetve 1/16-od részére csökken. Ez utóbbival még a jelenleg leggyorsabb GeForce2 16 biten közel 1200 Mtextel/s effektív teljesítménye is 75 Mtextel/s-re csökken, a 32 bitről pedig ne is beszéljünk...

A memóriaigény miatt egyébként a driver egyébként "csendes visszakapcsolást" hajt végre, vagyis ha nem elég a memória, akkor anélkül visszaváltja az FSAA módot a lehető legjobb még elérhetőbe, hogy "szólna". Ez előrevetítem, hogy még sok problémát fog okozni, hiszen biztos sok tesztelő elsiklik e felett és levonja a következtetést: az nvidia 16x-os módja gyengébb minőségű, mint a 3dfx 4x-ese, vagy pedig fordítva, azt hiszik, hogy a maximális beállítás 2x2-es (ez most a leggyakoribb) és ezért lassúnak találják. Pedig normál módokban (>640x480) 4x-es a maximális elérhető minőség. Éppen ezért javasolt, hogy csak az 1-4-es módokat használjuk, afelett úgyis túl lassú.

Bár a GeForce FSAA megoldásának transzparenciája sokat javult (minden OpenGL játék és a legtöbb Direct3D-s), nem olyan mértékű, mint a 3dfx-é. A nagyobb belső felbontás ugyanis néha problémát jelent, ha a játék a kártya belső framebufferéhez közvetlen hozzáférést kér (általában státuszinformációk, szövegek kirajzolásához): ekkor ugyanis a játék úgy gondolja, hogy az eredeti felbontású a kép, így rossz pozícióban és rossz méretben férne hozzá. Korábban ezek a játékok egyáltalán nem működtek, most az új driverek segítségével automatikus felméretezés történik.

[oldal:Az FSAA teljesítmény- igénye]

Az FSAA alkalmazásánál a kártyának éppen annyiszor több pixelt kell kiszámolnia, ahányszoros a túlmintavételezés. Vagyis a "szokványos" módokban négyszer annyit, ami a kártyát közel annyira lassítja le, mintha kétszer akkor felbontást használtunk. Vagyis a kártyának pl. egy 800x600-as 4x FSAA kiszámításához annyi pixelt kell kiszámítania, mint egy 1600x1200-as FSAA nélküli esetében, ami a teljesítményt is ennek megfelelően csökkenti. Ez alapján a 4 mintás FSAA-k esetében negyedakkora teljesítményt várhatnánk el. Ez azonban csak akkor lép fel, ha az eredeti, nem FSAA-s kép esetében is a kártya a számítás szűk keresztmetszete, vagyis magasabb felbontásokban és főleg 32 biten. Amikor ugyanis a CPU-ra kell várnia a kártyának, van "fölös" ideje, ezért a plusz munka nem jelentkezik ekkora csökkenésben. Ez főként szimulátor, stratégiai és régebbi játékoknál fordul elő. De lássunk néhány számot is! Az alábbi táblázat adatait az Anandtech összehasonlításából "vettem kölcsön", ahol megtalálható a két kártya teljesítmény és minőség alapú összevetése is. A kártyákat egy 1 GHz-es PIII-mal hajtva Q3A-ban a következő eredményeket kapjuk (egyik kártya sincs overclockolva):

640x480 x 16bit 640x480 x 32bit 800x600 x 16bit 800x600 x 32bit 1024x768 x 16bit 1024x768 x 32bit
Geforce2 GTS 146,1 140,3 143,2 120,8 127,7 83,1
Geforce DDR 143,3 132,2 125 102,2 85,6 65,1
Voodoo5-5500 111,4 104,3 109,6 97,3 98,3 69,4
Voodoo5-5500 2x FSAA 108,5 87,3 89,4 56,6 58,5 37,4
Voodoo5-5500 4x FSAA 69,1 46,2 46,1 29,0 28,8 16,6
Geforce2 GTS 4x FSAA 96,2 54,3 63,7 29,6 40,2 16,6
Geforce DDR 4x FSAA 55,0 42,3 36,0 27,4 22,4 7,9

Az összehasonlításnál vegyük figyelembe, hogy a V5 alacsony felbontású mipmapekkel dolgozik 4x-es módban. Itt jól látszik, hogy a teljesítmény negyedelődése csak akkor jelentkezik, ha tényleg a kártya a szűk keresztmetszet. Ennél gyengébb processzorral a CPU limitáltság tovább "kitart". Egy Celeron 500 esetében például még 1024x768x16-os felbontásban sem vennénk észre jelentős lassulást egy Geforce2-vel a 4x-es FSAA bekapcsolásával, mivel a CPU amúgy sem nagyon tudja gyorsabban hajtani a Q3A-t 50 fps-nél.

[oldal:A régi kérdés: 16 vagy 32 bit?]

A modern videokártyák mindegyike képes kétfajta, 16 vagy 32 bites pontossággal számolni. A bitek száma azt jelenti, hogy egy-egy képpont, textúrapont színét milyen pontossággal, finomsággal tárolja a kártya. A kezdetekben 16 bites pontosság volt az általános, amely - különösen a kezdeti időkben - megfelelőnek bizonyult. A gond ugyanis alapvetően nem ott van, hogy 16 biten nem lehet kellő pontossággal eltárolni egy pont színét: erről bárki meggyőződhet, ha egy 32 bites screenshotot valamilyen képfeldolgozó programmal visszaalakít 16 bitesre színszórás alkalmazásával: a két kép a legtöbb esetben alig fog különbözni, amiben nagy szerepe van a színszórásnak (dither) is. Ez utóbbi az egymáshoz hasonló színek egymás melletti, váltakozó felhasználásával köztes színek illúzióját kelti.


A fenti ábrán jól látszik, hogy bár a 16 bites színpontosság már látható sávosodáshoz vezet, ez gyakorlatilag teljesen eltüntethető színszórás alkalmazásával és bár egy kártya színszórása ennél valamivel gyengébb minőségű, nem jelentene különösebb problémát.

A probléma ott van, hogy a legtöbb kártya nemcsak a végső megjelenítéshez, hanem a belső számításokhoz is 16 bites pontosságot alkalmaz. Ez azért gond, mert a mai játékok esetében egy pixel színe legtöbbször több menetben alakul ki: a tárgyon sokszor több textúra is található, melyek pontjai együttesen hatnak, ráadásul sokszor találkozhatunk áttetsző tárgyakkal, köddel, vízzel, ami tovább hat egy-egy pixel színére. A számítások során a többszörös színösszeadódás és többszörös színszórás során a színhibák egyre csak halmozódnak, ami a fentinél jóval szembeötlőbb pontatlanságokhoz vezet. Ez természetesen az említett effekteket előszeretettel használó játékoknál látszik igazán (pl. Q3A), míg másoknál nem igazán szembetűnő.

A 32 bites pontosság ezeket a problémákat megoldja. A 32 bit egyébként nem egészen igaz, ebből csak 24 bit (színkomponensenként 8 bit) szolgál a szín tárolására. Színszórásra azonban nincs szükség és a hibák halmozódása nem éri el azt a szintet, hogy látható lenne. Ha csak az utolsó fázisban kerül sor a 16 bites konvertálásra és színszórásra, akkor a 16 bites megjelenítés alig marad el a 32 bitestől. Ezt a belső 32, külső 16 bites pontosságot tudja például a napokban bemutatott KYRO kártya.

A következő két kép a Q3A-ból való. Egy TNT2-es számította őket, az első 16, a második 32 bites.


Közelebbről szemlélve láthatjuk a hibákat, különösen a köd esetében és alacsonyabb felbontásban (később lesz egy nagyított összehasonlítás is).

Lassan két éve tart a vita, hogy vajon melyik számítási pontosságot érdemes használni. A 32 bit mindenképpen szebb (hogy mennyivel, azt játékja válogatja), de általában komoly árat kell érte fizetni: a 32 bites számításokkor ugyanis a kártyának kétszer annyi adatot kell mozgatnia, amihez a ma alkalmazott RAM-ok általában nem szolgáltatnak megfelelő sávszélességet. Ebből következően a legtöbb kártyánál nagyobb felbontásban komoly teljesítménycsökkenéssel jár. Mára lassan eldőlni látszik a vita: a 32 bit úgy tűnik, egyre inkább standard lesz. Ez nagyban köszönhető annak is, hogy az utolsó, eddig csak 16 bitet támogató kártyákat készítő gyártó (a 3dfx) is kijött a 32 bitre képes kártyáival, ezért most egycsapásra 32 bit párti lett.

Kérdés, hogy mit tud ezen változtatni az FSAA. Első nekifutásra úgy érezhetjük, hogy nem sokat: a pontatlanabb képből úgy tűnhet, hogy az átlagolás után is pontatlan kép keletkezik. Szerencsére ez nem így van. Az a "szerencse" ugyanis, hogy a kártyák színszórása ún. rendezett színszórás, vagyis 2x2-es pepitamintában szórják a színeket. Az átlagolás (legalábbis az OGSS esetében) pedig éppen 2x2-es blokkokat átlagol. Ennek az lesz az egyik eredménye, hogy a színszórás jellegezes mintája az átlagolással teljesen eltűnik. Az átlagolás pedig éppen azt a hatást éri el, aminek az illúziójára a színszórást kitalálták: köztes színt eredményez: a négy 16 bites szín átlaga finomabb részletességet ad. Ez optimális esetben színkomponensenként plusz két bitet eredményez, ami összesen 22 bites pontosság. Ez az optimális eset, a valóságban gyakran vannak helyzetek, amikor ez nem elérhető, de a színpontosság mindig nagyban javul. Lássuk, mit is jelent ez a gyakorlatban. A következő képek úgy készültek, hogy egy 1280x1024-en vett screenshotot átlagolással negyedeltem. Az első 16 bites screenshotból készült, a második 32 bitesből.


Hogy az összehasonlítás könnyebben menjen, íme három részlet kinagyított képe a négy változatból.


Jól láthatóak a különbségek az FSAA nélküli 16 és 32 bites kép között. Az FSAA-s képek esetében azonban ez a különbség eltűnik. Eltérés csak az első részletnél (ami talán a lehető legrosszabb állapotot jelképezi: a ködön kívül a rakéta füstje is plusz rétegeket jelent) és csak nagyításban vehető észre, ráadásul az eltérés mértéke nagyságrenddel kisebb. A másik két részletnél gyakorlatilag nincs különbség. A második és harmadik részleten egyébként ismét megfigyelhetjük, hogy mennyire tisztább, részletesebb textúrákat eredményez az FSAA, amennyiben nagyfelbontású mipmapokat használunk.

Konklúzió lehet talán, hogy az FSAA felhasználásával a 16 bites mód pályafutása várhatóan jelentősen meghosszabbodik, mert az FSAA által a "külső" színpontosság közelít a 32 biteshez. A játékok és a valósághűbb textúrázás (több textúraréteg) elterjedésével ez a pontosság is elégtelennek bizonyulhat, de addig még sok időnk van.

[oldal:Mennyire használható az FSAA?]

Mint láthattuk, az FSAA jelentősen javíthatja a képminőséget de hatalmas a teljesítményigénye: négyszer annyi pixel kiszámítását igényli, amivel a teljesítmény akkora lesz, mintha kétszer akkora (2x2) felbontású módba váltanánk, ami önmagában is drasztikusan csökkenti az aliasing hatást. Az átlagolással mindenképpen sok pixelszín és -pozícióinformációt pazarlunk el, vagyis a nagyobb felbontás mindenképpen magasabb információtartalmú azonos teljesítmény mellett. Ezzel szemben áll az aliasing csökkentése elsősorban az éleken. Bár ez elég szubjektív, összeségében inkább a magasabb felbontás éri meg (kis pixelméretű monitorokon a legnagyobb felbontásban az él-aliasing már nagyon kicsi, a textúra-aliasing pedig nem látható nagy részletesség mellett).

Sokszor előfordul azonban, hogy a felbontás már nem növelhető és a kártyában még sok tartalék marad. Ez akkor lehetséges, ha a felbontás valamiért korlátozott (a monitor megjelenítési képessége, a játék korlátozottsága: pl. Darkstone) vagy ha nem nagy kártyateljesítmény (fillrate) igényű a játék, ezért még magas felbontáson is a CPU a korlátozó tényező (pl. sok szimulátor, stratégiai játék (Homeworld, NFS…) vagy régi játékok). Ekkor az FSAA alkalmazása akár jóval kisebb lassulást eredményez, így mindenképpen megéri. Bár az is igaz, hogy aki megvesz egy 80-90 ezres kártyát (vagy a V5-6000 esetében 160 ezreset (plussz a hozzá szükséges hűtőszekrényt... :) ), annak általában nem 15 inches monitorja van...

Alternatív megoldásként jelentkezik a 2x-es mintavételezésű módok használata.

[oldal:A jövő]

Várhatóan a jövőben megjelenő összes kártya támogatni fogja az FSAA-t. Az FSAA felhasználhatósága a fillrate-ek (a kártya "rajzolási" sebessége) növekedésével javulni fog, mert egyre több lesz a "fölös" fillrate. Ezzel szemben áll a fillrate más felhasználási lehetősége, mint a bonyolultabb, élethűbb felülettextúrázás, ami mindenképpen jobban meg fogja érni képminőség szempontjából és így csökkenti a "fölös" fillrate-et. Ez azonban program-támogatást igényel és a fejlődéssel párhuzamosan előbb-utóbb újraképződik a "fölös" teljesítmény. Ezért az FSAA várhatóan standard képesség marad egészen addig, amíg a pixelméret jelentősen nem csökken, szükségtelenné téve az antialiasingot.

A teljesítmény sok esetben már fontossá teszi az FSAA-t a mostani leggyorsabb kártyák esetében is (Geforce2, V5-5500, Geforce DDR) de igazán használhatóvá csak a jövőben válik (V5-6000, gyorsabb memóriájú Geforce2, ATI Radeon, Matrox G800 és főként a következő generáció: az új architektúrájú nvidia és 3dfx kártyák, az NV20 és a Rampage esetében).

A Gigapixel (amit a 3dfx nemrégiben megvett) jelentős lassulás nélküli FSAA-t ígér. Ez kisebb csúsztatás: a kis teljesítményigényt (eddigi információink szerint) úgy érik el, hogy csak a poligonszéleken alkalmaznak felülmintavételezést, mivel a textúrák esetében a mipmapping már úgyis sokat javít. Ez az ún. edge antialiasing, vagyis a szélek antialiasingja. Nem rossz ötlet, mivel kis teljesítményvesztéssel elérhető, sokat javít a minőségen, de semmiképpen sem FSAA: ez ugyanis Full Screen-t, vagyis teljes képernyőset jelent, ami minden pixel esetében túlmintavételezést jelent. Ez az edge antialiasing bár nagyon hasznos, a textúraminőséget nem fogja javítani.

Írta: Soós Árpád
A cikkel kapcsolatos észrevételeket kérjük a szerzőnek eljuttatni a sarpad@webmail.hu címre.

Milyen technológiai és munkaerőpiaci hatások érhetik a backendes szakmát? Május 8-án végre elindul az idei kraftie! meetup-sorozat is (helyszíni vagy online részvétellel).

a címlapról

Hirdetés

Security témákkal folyatódik az AWS hazai online meetup-sorozata!

2024. április 27. 04:35

A sorozat május 28-i, harmadik állomásán az AWS-ben biztonsági megoldásait vesszük nagyító alá. Átnézzük a teljes AWS security portfóliót a konténerbiztonságtól a gépi tanulásos alkalmazások védelmén át, egészen az incidenskezelésig.