UNDER CONSTRUCTION:
Tato cast FAQ je este stale velmi nekompletna, a preto si ju zatial, prosim, velmi nevsimajte. Vdaka...

Pre tych, ktori chcu aj trocha vediet ako to cele funguje:

Co je to Mip mapa, Mip mapping a naco je to cele dobre?
Mip mapa sa vzdy viaze na nejaku zakladnu texturu. Je to vlastne subor jej zmensenin - tieto vznikaju povacsinou downsamplingom 2x2 texelovych stvorcovych oblasti povodnej textury, ktore su blendnute do jedneho texelu 1. urovne Mip mapy (tzv. box filter). Nasledne mozeme cely tento proces zopakovat a dostavame 2. uroven Mip mapy, atd...

Mip mapping potom nie je nic ineho nez bezny texture mapping, ktory prihliada na Mip mapy. Teda texture samples sa neberu len zo zakladnej textury, ale aj z urovni jej Mip mapy, a to podla toho ako "daleko" (resp. "hlboko") je v danej scene polygon, ktory prave texturujeme (to aku uroven treba vybrat maju na starosti tzv. LOD (Level of Detail) kalkulacie). Zjavne, pokial nanasame velku texturu na dostatocne vzdialeny polygon, lahko sa nam stane, ze na jeden specificky pixel nam pripade velmi vela texelov. Ako vybrat vhodneho reprezentanta? Logicka odpoved je, zobrat dostatocny pocet samplov a blendnut ich. (Ak zoberieme maly pocet samplov, alebo nedajboze len jeden, potom minimalna zmena pozorovatela bude mat na svedomi to, ze nasmu inkriminovanemu pixelu zrazu "pripadnu" texely znacne vzdialene (v 2D priestore textury) od tych povodnych a vysledkom je neprijemny efekt "mravcenia" textury - texture aliasing, shimmering.) To je ale vypoctovo narocne... ledazeby sme velku cast tohto samplingu pre danu texturu spravili uz na zaciatku. Skutocne, staci zobrat vhodnu uroven Mip mapy a problem je uspokojivo vyrieseny.

Zaver: Mip mapping je dobra vec, ktora zlepsuje kvalitu obrazu (ciastocne aj zvysuje vykon) za cenu pamatovej narocnosti a je to v sucasnosti uz absolutne standardna zalezitost. (Ak niekoho zaujima preco "Mip" - z latinciny "multum in parvo" = "mnoho v malom priestore", lebo 1. uroven Mip mapy zabera 1/4 povodnej textury, 2. uroven zabera 1/16, atd... teda lubovolne vela Mip urovni sa da vzdy ulozit do priestoru mensieho ako 1/3 priestoru zakladnej textury.)

Na co je vlastne dobry filtering textur a co je to point sampling, bilinear filtering a trilinear filtering?
Potrebujeme riesit nasledujuci problem... v drvivej vacsine pripadov sa nam pri renderingu sceny (specialne texture mappingu) stane, ze na jeden pixel nam pripade nie jeden texel, ale cela oblast textury - subor texelov (a to i za pouzitia Mip mappingu, ktory nam dost pomaha tuto oblast zmensovat). (Staci si predstavit pixel monitoru ako "dierku" cez ktoru sa divame na virtualnu 3D scenu nachadzajucu sa "za" (resp. "v") monitorom. Popisovanu oblast potom dostavame prienikom pozorovacieho kuzela s polygonom ktory cez "dierku" vidime a naslednou transformaciou tohto prieniku z 3D do 2D priestoru textury.) Kedze rozlisenie zobrazovacieho zariadenia nemozeme len tak dynamicky menit, musime z tejto oblasti vybrat nejakych vhodnych reprezentantov (samples), ktore determinuju vysledny pixel. (Nie je to nahoda, ze o podobnom postupe sme sa bavili uz aj pri Mip mappingu - tento je totizto tiez svojim sposobom jeden z pristupov k filteringu textur.)

Najjednoduchsi vyber reprezentantov prinasa tzv. Point sampling, ktory jednoducho zoberie jediny texel sample v strede tejto oblasti a tento urci farbu vysledneho pixelu. Vyhoda spociva v rychlosti, nevyhoda spociva v tom, ze sme s velkou pravdepodobnostou undersamplovali (teda zobrali malo vzoriek) a dochadza k texture aliasingu (popisany pri Mip mappingu).

Lepsiu kvalitu ponuka Bilinear filtering, ktory zoberie 4 texel samples (2x2 stvorec) zo stredu tejto oblasti a blendne ich do vysledneho pixelu (pomocou dvoch linearnych interpolacii). Tento pristup zmiernuje texture aliasing co je dobre, no na druhej strane oblasti texelov pripadajuce na jednotlive pixely su malokedy kruhoveho tvaru (a teda 2x2 stvorec v strede oblasti nie je idealna aproximacia) - v drvivej vacsine su to elipsy roznych tvarov. Zvysenie kvality samozrejme prichadza ruku v ruke s narastom vypoctovej narocnosti, kedze potrebujeme 4 samples na pixel (nastastie texturovacie jednotky drvivej vacsiny sucasnych kariet su schopne ziskat jednu bilinear texture sample v jednom clocku).

Trilinear filtering spaja filozofiu Mip mappingu a Bilinear filteringu. Pre danu oblast texelov sa zoberu 2 bilinear samples z 2 najvhodnejsich urovni Mip mapy prisluchajucej zakladnej texture (vhodne urovne opat urcuje LOD kalkulacia) a tieto 2 samples su blendnute dokopy (dodatocnou linearnou interpolaciou). Toto ma za nasledok jeden velmi pekny efekt. Totizto samotny Mip mapping bez Trilinear filteringu ma jeden vazny vizulny nedostatok - v renderovanej scene je vidno prechody medzi jednotlivymi susednymi Mip urovnami. (Btw., tieto su dobre viditelne najma v dynamickych scenach...) Trilinearny filtering vdaka interpolacii medzi tymito urovnami tieto prechody spolahlivo eliminuje.

A o com je anisotropicky filtering?
Todo...

Co znamena double & triple buffering?
Kazda graficka karta musi mat vo svojej pamati vyhradeny priestor (buffer) pre obrazovu informaciu, ktora je prave zobrazovana na monitore. Tento usek pamati sa nazyva front buffer a jeho obsah je prenasany bud digitalne alebo analogovo (po konverzii prechodom cez RAMDAC) do zobrazovacieho zariadenia (v zavislosti od jeho typu). No grafickej karte chvilu trva, nez vytvori (zrenderuje) obraz nejakej 3D sceny, rovnako ako monitoru nejaku tu chvilu trva kym "premietne" obsah front bufferu na obrazovku. Preto je neziaduce renderovat priamo do front bufferu, kedze takto by sme s velkou pravdepodobnostou mohli na monitore zhliadnut ciastocne (resp. neuplne) vyrenderovane obrazky. A to nie je to prave orechove.

Preto sa uz v sucasnosti pouziva standardne pristup zvany double buffering. Ako uz nazov napoveda, v pamati grafickej karty sa vyhradi miesto pre druhy buffer (velkostou ekvivalentny front bufferu), tzv. back buffer. Rendering potom prebieha nad tymto back bufferom a akonahle je obrazova informacia kompletna dojde k "prekopirovaniu" obsahu back bufferu do front bufferu (v skutocnosti sa ale fyzicky nic nekopiruje, dojde len k vymene memory pointerov, teda takpovediac premenovaniu alebo vymene funkcii front & back bufferu).

Filozofia triple bufferingu je snad po tomto vysvetleni jasna uz z nazvu. Namiesto jedneho back bufferu budeme mat dva. Toto moze mat zaujimave dosledky v kombinacii s tzv. VSyncom...

Co je to VSync (Vertical Synchronization)?
Tento pojem sa spomina v suvislosti s CRT monitormi. Elektronove dela vykresluju obraz na obrazovku postupne a ako sme uz spominali v predoslej odpovedi, toto zaberie trochu casu. Tradicne postupuje delo smerom zlava doprava, zhora nadol. Akonahle je obraz kompletne vykresleny, musi sa delo z praveho dolneho rohu obrazovky preorientovat na lavy horny roh, aby mohlo zacat pracovat na novom obraze. Pocas tohto casoveho useku teda dochadza k tzv. "vertikalnej synchronizacii" (VSync) dela. Tento casovy usek je zaujimavy preto, ze vysledny obraz je uz kompletny na obrazovke a zaroven este nedoslo k zapocatiu zobrazovania noveho obrazu. Toto je idealny okamih na hocake modifikacie front bufferu, napr. "prekopirovanie" obsahu back bufferu. Ak by sme totizto napr. necakali na VSync pri kopirovani back do front bufferu, na monitore by sme mohli zhliadnut situacie, kedy by bol vo vrchnej casti obrazovky zobrazeny stary obsah front bufferu a v dolnej casti novy obsah front bufferu. Tento efekt je dobre postrehnutelny najma v dynamickejsich hrach, kedy sa javi obraz akoby bol v strede "preruseny", "pretrhnuty" (screen tearing). Synchronizaciou buffer swapov s VSyncom sa da tento neziaduci efekt spolahlivo eliminovat.

Aky je suvis VSyncu s double & triple bufferingom?
Velmi zaujimavy. Kvoli nazornosti si predstavme situaciu, kedy pouzivame VSync spolu s double bufferingom (co uz je v sucasnosti minimalny standard). Buffer swaps teda prebiehaju len pocas VSyncu. Povedzme, ze monitor ma refresh rate 85Hz. Pokial je graficka karta schopna generovat stabilne viac ako 85 FPS je vsetko v poriadku a na monitore mame peknych stabilnych 85 FPS bez tearingu. Pokial ovsem nestiha, teda pocas jedneho vykreslenia obrazu na monitore graficka karta neukonci rendering dalsieho framu do back bufferu, mame tu problem. V back bufferi este nie je kompletna obrazova informacia, takze pocas VSyncu k swapu bufferov nedojde, a bude opat zobrazeny predosly frame. K swapu dojde az pocas jedneho z nasledujucich VSyncov, podla toho ako rychlo karta ukonci rendering. Teda na monitore sice budeme stale vidiet 85 FPS, niektore frames budu vsak zobrazene identicky viackrat za sebou. Skutocny framerate tak pada na celociselne podiely 85ky, teda 42.5, 21.25, atd... Toto samozrejme nie je to prave orechove a je to az privelka cena za "tearing-free" obraz, pokial graficka karta nestaci dost rychlo tlacit nove a nove frames.

Tento problem z velkej casti (ale nie uplne) eliminuje prave triple buffering. Vdaka dalsiemu dodatocnemu back bufferu sa totizto z velkej casti dari vyhybat sa situaciam, kedy je graficka karta idle kvoli tomu, ze uz vyrenderovala nasledujuci frame do back bufferu, no musi cakat na VSync aby jeho obsah mohla "preliat" do front bufferu a pokracovat v renderingu. Toto ale ma bohuzial malu (pre niekoho velku) nevyhodu v tom, ze sa zvysuje latencia celeho renderovacieho procesu. Skratka predlzenim "fronty" bufferov o jeden dalsi sa zvysuje cas, ktory uplynie od inputu (povedzme pohyb mysou) do outputu (vykreslenie framu monitorom). Pozorovatelnost tohto javu je silne individualna...

Zaver:
1. Ak nechceme screen tearing a graficka karta je po vacsinu casu schopna renderovat viac FPS ako je nas refresh rate v Hz, potom je najlepsim riesenim VSync spolu s double bufferingom. Pokial karta nestiha, je potrebne sa uchylit ku triple bufferingu (ak mame tu moznost).
2. Triple buffering bez VSyncu nema absolutne ziaden vyznam ani vyhody.

Kde najdem podrobnejsie a fundovanejsie clanky?
Napriklad v tomto zozname:


FSAA (SSAA, MSAA, TAA), PS, VS

Thanks to: Mirek, no-X, uberguru, VerteX, stanley