[Članak] 3D stuff : Arhiva

Mip-mapping

Mip-mapping je tehnika koja se primjenjuje kod teksturiranja (iscrtavanja tekstura) na poligone u 3D prostoru. Bavi se rješavanjem problema over-sampleovanh tekstura.

Kakav je problem u pitanju i kako nastaje?

Godinama evolucije 3D grafike povećale su se teksture (tj. njihove rezolucije), a i rezolucije prikaza (ekrana), te je problem oversamplovanih tekstura postajao sve uočljiviji. O čemu se radi? Tehnički gledano, to oversamplovanje znači previše slikovnih informacija na jednom mjestu. Kako li ih može biti previše, pitate se? Biće objašnjeno na primjeru : zamislite jednu teksturu sa crnim i bijelim kvadratićima, poput šahovske table. Ta tekstura je "zalijepljena" na jedan poligon na koji ravno gledamo. To bi izgledalo ovako nekako :

http://img224.imageshack.us/img224/4022/mipmaps1pj3.png

Slika je ok, sve super. Međutim, ako se taj poligon nalazi pod nekim drugim uglom u odnosu na kameru (posmatrača), već možemo uočiti probleme...

http://www.c-unit.com/tutorials/mdir...ointFilter.jpg

Primjećujete kako ružno izgleda gornji dio slike? Sve te crne i bijele linijice jedva da podsjećaju na originalnu sliku. A zašto je to tako? Zato što je originalna slika na tom mjestu udaljenija od kamera, pa je, mogli bismo reći - "mala". Tako da po jednom pixelu ekrana dolazi više od jednog pixela teksture (texel), i sada je problem - kojeg odabrati. Odabire se onaj najbliži, jer je tako programirano. Ali bez obzira koji da se odabere - nekog "ispravnog" odabira nema, jer ni jedan pojedini pixel ne može predstaviti sliku koju sačinjava više njih. Ako vam ona slika izgleda ružno, to nije ništa. Pravi horor nastaje kada sve to vidite u pokretu. Taj gornji dio slike bi samo treperio između nekih, naizgled nasumičnih, hrpa crnih i bijelih linija koje ni u jednom trenutku ne bi predstavljale "stvarnu" sliku. Pixeli bi se cijelo vrijeme "borili" međusobno za svoje mjesto na ekranu. Dakle, zaključili smo - previše ih je na jednom mjestu. Rješenje? Smanjiti broj pixela.

Kako to riješiti?

Možemo jednostavno otvoriti Photoshop i smanjiti teksturu 2 ili 3 puta uz neki bilinearni ili bikubični filter da zagladi rubove - i više ne bi bilo treperenja jer bi tekstura bila znatno niže rezolucije. Naravno, iz aviona se vidi da ovo rješenje uopšte nije idealno jer time gubimo detalje tamo gdje nam trebaju - na dijelovima bližim posmatraču. Znači, bilo bi dobro kada bi nekako mogli imati veću rezoluciju gdje nam treba detalja, a manju tamo gdje ti detalji prave probleme? E, tu uskače mip-mapping.

Da bi mip-mapping ispravno radio, treba nam unaprijed pripremljena tekstura. Takva tekstura se najčešće sastoji od slike u punoj veličini, nakon koje slijedi ista slika, samo smanjena (uz odgovarajući filter) na jednu četvrtinu prethodne i tako sve dok se ne dođe do 1x1 slike, tj. jednog jedinog pixela. To jako lijepo možete vidjeti na slijedećoj slici :

http://www.c-unit.com/tutorials/mdir...es/mipmaps.jpg

Dakle, tu vidimo originalnu sliku veličine 256x256 sa svojim mip-mapama veličina redom 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Uz toliko različitih varijanti imamo za svaku situaciju po nešto. A od čega zavisi koja će se varijanta odabrati? Problem oversamplinga je najuočljiviji kod udaljenih tekstura i tekstura na koje se gleda pod malim uglom, pa od toga upravo i zavisi koja će se varijanta odabrati (mip-level) - od udaljenosti i ugla. U preciznu matematiku vezanu za ovo neću ulaziti. Vjerovatno ste u nekim tweaking alatima vidjeli nešto što je nosilo naziv "Mipmap LOD bias" ili nešto slično, pa ste imali neki opseg od -3 do +3. E, to je podešavanje mipmapinga koje određuje da li će on biti naklonjeniji manjim ili većim varijantama teksture, tj. direktno utiče na odabir mip-levela za pojedini dio slike. Da ne tupim previše, evo kako bi ona slika izgledala s mip-mappingom (u kombinaciji s bilinearnim filterom) :

http://www.c-unit.com/tutorials/mdir...nearFilter.jpg

Ljepše, uglađenije, i bez ikakvih treperenja i naglih prijelaza. No, naravno, možda već uočavate da tehnika nije savršena...

Koji su nedostaci?

Kao prvo i osnovno, čim se spominju dodatne varijante tekstura, logično je da i njih negdje treba spremiti - dakle, mip-mapping nameće dodatne memorijske troškove. Uz malo jednostavne matematike dobijamo da mip-mappovana tekstura zauzima 33% više memorije. Takođe, na slici možemo primijetiti da prikaz takvih tekstura ima tendenciju da bude previše mutan u pojedinim dijelovima. Ovaj problem se prilično efikasno rješava anisotropskim filterom, ali o tome ćemo drugom prilikom.

Neke od slika - ©2004-2007 Chad Vernon

Bilinear texture filter

Prilično trivijalna i ujedno toliko rasprostranjena i sveprisutna stvar da više niko i ne obraća pažnju na to. Najjednostavniji način da shvatite o čemu se radi je da pogledate teksture bilo koje igre na PSX i, npr., Quake 3 Arena, ili bilo koju noviju igru. Šta primjećujete? Na PSX su teksture "kockaste", tj. rubovi svakog texela se jasno ističu formirajući kvadratiće, što rezultuje "preoštrim" izgledom, dok je na (skoro) svakoj igri na PCu (a i konzolama, počevši od PS2 i DreamCasta) uključen bar bilinearni filter koji čini da teksture izgledaju uglađeno i bez onih stršećih "kockica". Uglavnom, ove dvije slike govore za sebe :

http://img382.imageshack.us/img382/7817/pointbirw6.jpgS

Kako radi? Ubitačno jednostavno. Da imate npr. brojeve 2 i 10, 3 prazna polja između njih i trebate učiniti prijelaz što "nježnijim" - kako biste to uradili? Pa ravnomijerno, naravno, popunjavajući polja brojevima 4, 6 i 8, tako da razlika između dva susjedna polja bude uvijek ista. E, upravo to se događa i sa vrijednostima boja kod bilinearnog filtera, s tom razlikom što se tu to događa u dva smijera (bilinearno - dva linearna), pošto je tekstura dvodimenzionalna. I upravo na taj jeftini fazon dobijamo uglađene teksture u današnjim igrama, ali taj fazon nije uvijek dovoljan...

Trilinear texture filter

Dakle, bilinearni filter se sastojao iz dvije linearne interpolacije - jedne horizontalne i jedne vertikalne, a sada imamo trilinearni filter, što će reći da imamo još jednu interpolaciju. Koja je treća? Treća je interpolacija između dvije mip-mape. Sjećate se šta sam pričao o mip-mapama? O tome kako se bira odgovarajući mip-level za svaki dio teksture na ekranu? E, pa prijelazi između dva mip-levela na istoj teksturi znaju nekada biti jako uočljivi. To pogotovo mogu primijetiti korisnici low-end grafičkih kartica koji su prinuđeni da smanje sve "detalje", tako da na kraju vjerovatno završe s mip-mapama fitrovanim bilinearnim filterom, pa ona mogu primijetiti jasnu granicu između dva mip-levela, tj. kako im tekstura naglo postaje mutnija. Najuočljiviji primjeri su teksture podova i sl., gdje je ugao gledanja mali, pa je i mip-mapping najagresivniji. E, tu uskače ona treća interpolacija kod trilinearnog filtera, koja, jednostavno rečeno, radi sa mip-mapama isto ono što bilinearni filter radi sa texelima - čini njihove prijelaze (skoro) neprimjetnima. Dakle, trilinearni filter neće učiniti da vam teksture budu manje mutne, ali će vas poštedjeti gledanja očiglednih granica između dva mip-levela.

http://img520.imageshack.us/img520/2466/bitrikz3.jpg

Anisotropic texture filter (AF)

Hm... odakle da počnem? Mogao bih početi od toga što ću vam reći da je trilinearni filter isto što i 1X anisotropski. Kakve oni imaju veze? Pa, zapravo se svode na istu stvar - uzmu se sampleovi (uzorci) sa dva mip-levela i onda se vrši interpolacija između njih, kako bi se pogodila "prava vrijednost". Dakle, nigdje nećete vidjeti 1X AF, jer je to isto što i trilinearni filter. Već sa 2X AF imamo nešto novo - uzimanje više sampleova sa svakog mip-levela. Za trilinearni filter uzimamo ukupno 8 sampleova : gornji, donji, lijevi i desni texel prve i druge mip mape - 2 x 4 = 8. Već kod 2X uzimamo po 8 sampleova za mip-level, dakle ukupno 16. Za 4X AF uzimamo 2 x 16 = 32, itd. Dakle, veći kvalitet dobijamo korišćenjem više uzoraka, ali nije kvaka samo u uzimanju više njih - vrlo važno je i odakle ih uzimamo. Kod bilinearnog (a time i trilinearnog) je uvijek isto - uzimaju se 4 susjedna texela, bez obzira pod kojim se uglom gledala tekstura. Što često prouzrokuje situaciju u kojoj, npr. imamo vrlo malo texela po horizontali, a možda i previše po vertikali (ponovo, čest slučaj kod "podova" u igrama). Dakle, kod anisotropskog filtera se radi nešto pametnije - uzorci se raspoređuju po elipsi zavisno od ugla gledanja. Mislim da će vam biti jasno nakon posmatranja slijedeće slike :

http://img220.imageshack.us/img220/4649/samplesod8.jpg

Šta uočavamo? Na ovom primjeru samplovanja jednog mip-levela pri 2X AF uočavamo da se sampleovi teksture ravnomijerno uzimaju sa projektovane elipse koja zavisi od ugla gledanja na teksturu. Upravo to i jeste glavna prednost anisotropskog filtera - ima obzira prema uglu gledanja, te stoga proizvodi sliku optimizovanu za baš taj ugao iz koga posmatramo. U praksi je vrlo lako uočiti prednost AF nad običnim mip-mapama. Evo jednog primjera :

http://upload.wikimedia.org/wikipedi...ic_compare.png

Krenuvši od dna prema vrhu slike, vidimo kako obične mip-mape s trilinearnim filterom polagano gube kvalitet, dok ga AF zadržava. Dakle, vizualno, AF je superioran u odnosu na tradicionalne metode u svakom pogledu - slika koju dobijete sa 16X AF je vjerovatno najbolja koju možete dobiti. Jedini nedostatak je, naravno, njegova zahtjevnost, pogotovu što se tiče memorijske propusnosti. Naravno, potrebno i je procesorskog vremena da se sve to sračuna, ali usko grlo je memorijska propusnost, jer treba tu pretrpiti svo to zivkanje tekstura radi uzimanja sampleova. Uglavnom, do prije par godina AF je još uvijek bio egzotika, dok je to danas dobrim dijelom prešao u mainstream upotrebu.

Hvala na čitanju, nadam se da nije bilo previše nerazumljivo. Slijedeći put ćemo se vjerovatno baviti anti-aliasingom. Do čitanja.

Screenshot za bilinearni filter iz Half-Life by Valve Software; screenshoti za trilinearni filter iz Quake III Arena by id Software; primjer anisotropije sa Wikipedia-e

Malo teorije...

Da, da, znam da je svi mrzimo, ali treba i toga malo nekad. Dakle, mi cijelo vrijeme pričamo o tehnologijama vezanim za vizualnu prezentaciju, tj. pričamo o slikama. A šta je slika teoretski? Slika je skup informacija o boji i svjetlini, i ono što je najvažnije, slika u prirodi ima beskonačnu detaljnost. (zapravo, detaljnost je ograničena veličinom fotona, ali slobodno možemo pretpostaviti da je beskonačna) A svi dobro znamo da u informatici ništa nije beskonačno (osim frustracija), tako da kada želimo nešto beskonačno predstaviti u ograničenom okruženju - moramo neke stvari izostaviti i/ili praviti kompromise.

(Napomena : zbog opširnosti slijedećeg dijela teksta i njegove relativno male važnosti za glavnu temu, slobodno preskočite do Aliasing dijela, iako ni tekst o frame bufferu nije potpuno suvišan.)

Frame buffer

Frame je u bukvalnom prevodu okvir, a u grafici/animaciji predstavlja jednu sličicu iz serije istih koji stvaraju iluziju kretanja (hence, jedan statičan screenshot). Buffer je međuspremnik/privremeni spremnik. Dakle, kada spojimo te riječi dobijamo pojam koji označava dio grafičke memorije posvećen čuvanju trenutne slike koja se treba prikazati na monitoru. Usput da pojasnim i šta je double buffering. Taj pojam se često spominjao u ranim stadijima razvoja kompjuterske grafike, a sada je već postao standard, pa se više i ne priča o tome. Naime, radi se o pametnom triku koji uključuje dva frame buffera. Šta se time postiže? Znamo da za iscrtavanje slike treba vremena i da se ona crta postepeno, poligon po poligon. Sad zamislite kako bi bilo ružno da cijelo vrijeme gledamo gledamo kako se svaki frame iscrtava - slika bi treperila, a i objekti iz pozadine bi se vidjeli na trenutak dok ne bi bile "precrtani" objektima ispred njih. Jako ružno, ali na sreću, od toga smo pošteđeni jer 99% iole grafički zahtjevnijih aplikacija koristi double buffering. Čemu dva buffera? Najjednostavnije rečeno - zato da u jedan gledamo dok se drugi crta. Znači, efektivno, mi nikada ne gledamo u frame koji se upravo crta (back buffer), već u gotovu sliku prethodnog (front buffer). Kada se završi crtanje, back buffer postaje front buffer (dakle, sada gledamo u upravo nacrtanu sliku), a bivši front buffer se čisti, postaje back buffer i na njemo ponovo počinje crtanje i tako u krug... Ovu tehniku ćete ponekad vidjeti i pod nazivom "page flipping". Ovo se koristi kod full-screen aplikacija. Kada crtamo u prozoru, ne možemo samo tako mijenjati buffere, jer ne posjedujemo cijeli ekran, već su u tom slučaju back i front buffer stalni, i na kraju crtanja se sadržaj back buffera kopira ("bltuje") u prozor. Proces je za nijansu sporiji, ali opet prihvatljivo brz. Takođe, vjerovatno ćete vidjeti i triple buffering. Stvar je vrlo slična double bufferingu, samo sa jednim bufferom rezerve više. Neću u detalje o tome, jer sam već dosta skrenuo s teme.

Sada nazad na temu uz malo tehničkog razmatranja. Govorili smo o slici i njenoj beskonačnoj količini informacija. Količina memorije na grafičkoj kartici i količina pixela na ekranu su sve drugo samo ne beskonačne. Sigurno svi znamo šta su rezolucije ekrana - broj pixela po horizontali i vertikali koji pomnoženi daju ukupan broj vidljivih pixela. Npr. 1024 x 768 = 786432 pixela. Još jedan važan faktor je broj bita po pixelu (bpp - bits per pixel). Pa smo tako vidjeli stvari tipa 640x480x8, 1024x768x16, 1600x1200x32... Dakle, horizontala x vertikala x bpp. Šta nam taj broj bita znači? On određuje koliko binarnih cifara (1 i 0) određuje svaki pixel, tj. direktno utiče na broj različitih boja koje pixel može imati. Npr. najčešćih 24 bita* (po 8 bita za crvenu, zelenu i plavu) nam daje 2 ^ 24 = 16777216 različitih boja. Pri postavljanju rezolucije, frame buffer automatski rezerviše dovoljno memorije za sebe, tako da u njega mogu stati svi bitovi svih pixela pri toj rezoluciji. Npr. za 800x600x16 nam treba 800 x 600 x 16 = 7680000 bita. 7680000 bita = 960000 bytea = 973,5 kB memorije na grafičkoj kartici.

Aliasing

Ponovo se vraćamo na onu našu teoriju o slici. Dakle, došlo je vrijeme da beskonačan skup informacija nekako predstavimo u ograničenom frame bufferu. Naravno, ne možemo sve informacije uzeti, već ćemo morati da biramo. Najjednostavnije je uzeti vrijednost iz slike koja se nalazi u centru pixela.

http://img223.imageshack.us/img223/5281/samplinguo4.png

Na slici vidimo fiktivan slučaj predstavljanja beskonačno detaljne krivulje (kod nas će to najčešće biti rubovi poligona) u polju pixela (raster) sa vidljivim centrima pixela. Dakle, logika je jednostavna - pixel će imati vrijednost uzetu sa njegovog centra, tj. ako je centar pokriven pixel će biti crn, ako nije, biće bijel. I na desnoj strani vidimo rezultat - krivulja jeste predstavljena pixelima, ali slika ipak izgleda... "kockasto". Idealno bi bilo kada bi i monitor mogao prikazati beskonačno mnogo pixela - ona ne bi ni bilo ovog problema. Pošto je beskonačnost nemoguća, dobro rješenje bi bilo i povećati broj pixela na monitoru - ali, opet, sve dok ne počnu praviti 17" monitore rezolucije 40000x30000, mislim da ćemo pribjegavati drugim rješenjima.

Anti-aliasing

Ako se sjećate prethodnih članaka, vjerovatno uviđate da smo imali sličnih problema i s teksturama. Proganjala nas je ta "kockastost" i "nazubljenost", pa smo je rješavali kojekakvim interpolacijama i traženjem prosjeka od više uzoraka. Nešto dosta slično se i ovdje radi. Anti-aliasing je po principu rada relativno sličan anisotropiji - temelji se na uzimanju više uzoraka, te se traženjem prosjeka vrijednosti dobijaju "precizniji" pixeli. Eh, ali odakle uzeti uzorke? Znate šta se dobije kada se za svaki pixel upiše prosječna vrijednost njega i njegovih susjeda? Dobije se jednostavan box blur filter, a to je zadnje što nam treba - da nam slika bude mutna. Dakle, s trenutnom slikom u frame bufferu smo bespomoćni, od nje nikako ne možemo dobiti bolju sliku (kako i logika nalaže, ako malo razmislite). Prvo ćemo pogledati šta se radi u jednostavnoj vektorskoj grafici (najčešće kod fontova).

http://www.widearea.co.uk/designer/images/grid2.gifShttp://www.widearea.co.uk/designer/images/grid4.gif

Na lijevoj strani vidimo rub nekog geometrijskog oblika u mreži piksela u kojoj ga želimo prikazati, a na desnoj strani vidimo tu sliku prikazanu pixelima, ali znatno ugodnijeg izgleda od one krivulje u prvom primjeru. Kako smo dobili to? Prilično jednostavno, računajući koliki je dio površine pixela prekriven "crnilom". Npr. ako je 60% pixela crno, pixel će dobiti 60% sivu boju. Što je više površine pokriveno - to tamniji pixel. Tako da na kraju dobijamo vrlo preciznu predstavu objekta na ekranu. Na žalost, to rješenje ne možemo primijeniti u 3D grafici jer, kao što znamo, tamo stvari nisu samo crne i bijele, pa je stvar znatno kompleksnija.

E, a šta mi da radimo sa slikom svoje omiljene 3D igre? Ako je iscrtamo u rezoluciji ekrana, nemamo odakle uzimati dodatne uzorke. Stoga preduzimamo radikalan korak - sliku iscrtavamo u dvostrukoj veličini, tj. za svaki pixel ekrana crtamo 4 pixela. Već pretpostavljate, to je 2X AA, znači ako u rezoluciji 640x480 koristimo 2x AA, grafička kartica zapravo iscrtava sliku veličine 1280x960. 4x AA znači 4x veću sliku, itd. E, sad kad imamo 2x veću sliku, tj. 4x više pixela - sada imamo odakle uzimati uzorke, tj. sada će svaki pixel ekrana biti sačinjen iz informacija skupljenih iz 4 pixela. Ponovo, kao i kod AF, način sampleovanja dolazi u igru, jer kao što smo vidjeli, i mjesta s kojih uzimamo uzorke mogu činiti znatnu razliku. Najjednostavniji je Ordered Grid Super-sampling (OGSS), princip rada prvih implementacija AA (u GF1 i 2, npr.) koji je uzimao jednostavnu mrežu samleova, poput ove :

http://img261.imageshack.us/img261/8...egridsspq6.png

Ovo efektivno znači da se ti "dodatni" pixeli jednostavno, saberu, nađe se prosjek i to nam bude taj "finalni" pixel. Solidno rješenje, ali može i bolje. U ovom rasporedu jasno uočavamo horizontalu i vertikalu, što opet smrdi po aliasingu. Bolje rješenje bi bilo da se samplovi sa nasumičnih lokacija iz tog "polja pixela" koje trenutno obrađujemo. Ali i tu se može desiti da se dva sampleovanja izvrše vrlo blizu čime gubimo na preciznosti, jer tako previše važnosti pridodajemo jednom dijelu, a zapostavljamo drugi. Idealno bi bilo da imamo nasumičan raspored, ali da se pazi na blizinu. Samo... implementacije takvog algoritma je previše za današnji hardver, pa se koristi nešto jeftinije - rotirana mreža. Dakle, ponovo jednostavna mreža sampleova, ali ovaj put rotirana za određen ugao kako bi se izbjegle paralele s horizontalom i vertikalom ekrana.

http://img142.imageshack.us/img142/7056/rotgridzn5.png

Na većini današnjih grafičkih kartica s podrškom za AA se radi upravo na tom principu rotirane mreže. Za NxAA, narenda se N puta veća slika u zaseban frame buffer, uzme se 2 x N sampleova iz rotirane mreže, nađe se prosjek i rezultujući pixel se smjestu u "pravi" frame buffer. Kod ATijevih kartica sam uočio mogućnost "temporalnog antialiasinga". Radi se o tome da se raspored sampleova mijenja između frameova kako bi samplovanje "izgledalo" nasumičnije, te se time, prema njihovim riječima "efektivno postiže izgled dvostruko većeg AA bez cijene u performansama". Ne bih se baš kladio u to, ali tehnologija ima smisla, to je sigurno.

Nedostaci

Nedostaci su prilično očigledni. Od samog pomena rendanja scene u višestruko većoj rezoluciji i ne osjetite baš vjetar u kosi od brzine? Da, stvar zna biti prokleto spora, pogotovo kada se "odšarafi" AA, jer količina posla raste eksponencijalno. Takođe, starijim karticama je poprlilično smetala još jedna stvar - veličina frame buffera koji za AA treba biti nekoliko puta veći od "normalnog". Uz malo matematike dolazimo do podatka da pri rezoluciji 1024x768x16 sa 4xAA frame buffer zauzima zapanjujućih 24 MB. I to je sa 16 bpp, sa 32 bi bilo 48 MB - vrlo, vrlo veliki trošak memorije za karticu sa 64 MB VRAM, npr.

Optimizacije

U početku se AA radio "pošteno", pa zato i jeste bio toliko spor i moga se vidjeti samo u pokojem tech-demou. Od tada su ljudi malo razradili tehniku, pa se anti-aliasovanje malo drugačije sprovodi danas. Je li nam nužno da baš cijela scena bude iscrtana višestrukom rezolucijom? I nije baš. Aliasing se ionako ponajviše i primjećuje na rubovima poligona, pa se vodi računa i o tome - jedan od načina optimizacije je da se višestruko iscrtavaju samo zone oko rubova poligona, jer na teksturama baš i nemamo koristi od AA, štaviše, AA zna i zamutiti teksture. A treba li nam AA baš i na svakom rubu poligona ili nam je možda nekad potrebniji i na drugim mjestima? Tu je još jedan način optimizacije - adaptivan AA. Radi na principu da se prvo uzmu npr. 2 samplea i onda se oni ispitaju; ako su im vrijednosti dosta slične, preskaču se, a ako se znatno razlikuju (što ukazuje na neki oštar rub), onda se dalje povećava rezolucija tog segmenta zavisno od oštrine ruba koji treba zagladiti. Tako da danas već imamo AA sa prihvatljivim performansama upravo zbog tih par pametnih poteza koje grafička kartica pravi. Za kraj, evo i jednog real-life primjera :

http://img261.imageshack.us/img261/8...naljpegih2.jpg

* Kažem 24 bpp iako je danas uglavnom u ubotrebi zavaravajućih 32 bpp. I u 32 bpp i dalje su tu po 8 bitova za crvenu, zelenu i plavu, tj. broj boja je isti, a onih 8 bita što ostaje su rezervisani za alpha kanal (providnost), ali to je dosta daleko od današnje teme.

Primjer sampleovanja krivulje sa Beyond3D.com; primjer AA u vektorskoj grafici sa WideArea.co.uk; ilustracija rotirane mreže s Wikipedia.org; screenshoti iz Counter-Strike 1.6 by Valve Software.