Potentially Visible Set (PVS)

HELSINKI UNIVERSITY OF TECHNOLOGY 5.5.2003 Telecommunications Software and Multimedia Laboratory Tik-111.500 Tietokonegrafiikan seminaari Spring 2003: Reaaliaikainen 3D grafiikka Potentially Visible Set (PVS) Marko Lastikka 47178B

Potentially Visible Set (PVS) Marko Lastikka marko.lastikka@hut.fi Johdanto Tämä paperi käsittelee Potentially Visible Set (PVS) tekniikoita. Tarkemmin paneudutaan näytteenottoratkaisuun ja siihen liittyviin ongelmiin, dynaamisiin objekteihin, sekä exact from-region visibility -ratkaisun tekniikkaan ja ongelmiin. 1 POTENTIALLY VISIBLE SET: TARKOITUS JA KÄYTTÖ Potentially Visible Set (PVS) tarkoittaa tietokonegrafiikassa potentiaalisesti näkyvää joukkoa. Potentiaalisesti näkyvä joukko on joukko grafiikkaobjekteja, jotka on piirrettävä näkyviin, niin että graafinen toteutus vastaisi ohjelmallista toteutusta. PVS-tekniikan käyttötarkoitus on graafiset ohjelmat, jossa liikutaan kolmiulotteisessa maailmassa. Kolmiulotteisessa maailmassa liikkumista käytetään enimmäkseen first person -ampumispeleissä (Kuva 1), jossa reaalisessa 3D-maailmassa liikutaan pelin hahmon silmien läpi, sekä autopeleissä (Kuva 2), jossa pelin maailma kuvaa formula- tai rallikilpailua ajajan silmistä. Tämänlaisten reaalisten maailmojen näyttäminen kuvaruudulla edellyttää jokaisen maailmassa näkyvän objektin renderointia, joka vaatii suuren määrän prosessoriaikaa. Kaikkien ohjelmien, varsinkin tietokonepelien tarkoituksena on minimoida prosessointiaika, jotta ohjelma toimisi ilman nykimistä. John M. Airey mainitsi PVS-tekniikan ensimmäisenä vuonna 1990 artikkelissa: Towards Image Realism with Interactive Updates in Complex Virtual Building Environments. Suurelle pelaajamassalle PVS-tekniikan teki tutuksi John Carmack työskennellessään id Software:n silloisen projektin, Quake parissa (v.1996). Quake oli ensimmäinen first person - ampumispeli, joka tekniseltä toteutukseltaan muistuttaa nykyaikaisia pelejä. Quake:n uutta tekniikkaa olivat tarkemmin kuvattu maailma, mahdollisuus katsoa ylös ja alas, yksityiskohtaiset valot ja varjot ja 3D-viholliset. Id Software:n edellinen first person - ampumispeli oli Doom. Siinä viholliset oli kuvattu yhdellä 2D-tasolla, joka ainoastaan kääntyi kohtisuoraan pelaajaan nähden. Kaikki nämä tekijät aiheuttivat sen, että Quake ei pyörinyt tarpeeksi nopeasti, kun maailman näkymiä käsiteltiin reaaliajassa ja pakotti John Carmack:in ottamaan käyttöön PVS-tekniikan, joka tutkii objektien näkyvyyden ennen ohjelman ajamista (eng. pre-process). 1

Kuva 1: Unreal 2-The Awakening, 2003 Epic Games Inc. Esimerkkikuva tyypillisestä first person -ampumispelistä. Kuva 2: Need For Speed-Hot Pursuit 2, 2002 EA Games. Esimerkkikuva tyypillisestä autopelistä. PVS-tekniikan pääidea on se, että aikaavievä kuvien prosessointi, eli näkyvien objektien näyttäminen ja näkymättömien objektien poistaminen, suoritetaan etukäteen (eng. pre-process) ja tallennetaan tiedostoon. Syntyvää tiedostoa kutsutaan PVS-listaksi. Pelin aikana (eng. runtime) näkyvät objektit ainoastaan luetaan etukäteen lasketusta PVS-listasta ja piirretään kuvaruudulle. Tämä vähentää reaaliaikaista prosessointiaikaa ja nopeuttaa pelin kulkua huomattavasti. Pelin nopeaan etenemiseen ei riitä ainoastaan se, että pelin näkymät luetaan etukäteen luodusta listasta. Jos kuvat pitävät sisällään liikaa informaatiota, kestää kaiken sen informaation piirtäminen liian kauan. Kuvien optimoimiseksi ja prosessointiajan säästämiseksi on kehitetty tekniikoita, jotka nopeuttavat 3D-maailman graafista esitystä. Tekniikoiden päätarkoitus on 2

renderoida kaikki sellainen grafiikka, joka näkyy yksittäisissä pelitilanteissa, mutta jättää se osa grafiikasta käsittelemättä, joka ei ole näkyvissä kyseisellä hetkellä. PVS-tekniikka jakaa pelimaailman kolmiulotteisiin soluihin (eng. view cell). Pelin hahmon täytyy aina olla näiden solujen sisällä. Jokaiselle solulle lasketaan oma PVS-lista, joka pitää sisällään kyseisestä solusta näkyvät objektit. Näytepiste (eng. sample point) on piste solun sisällä, joka kuvaa mahdollista kameran sijaintia ja kulmaa. Pelin tilanteessa kameran sijainti on hahmon sijainti ja kameran kulma on hahmon silmien katseen suunta. Kaikki näytepisteistä näkyvät objektit tallennetaan PVS-listaan. Lista pitää siis sisällään suuren määrän pelimaailman esineitä muodostavia polygoneja, jotka pelin henkilöllä on mahdollista nähdä liikkuessaan 3Dmaailmassa. PVS-listassa on kaikki pelimaailman objektit, joiden kuuluu kyseisestä solusta näkyä. Pelin ajon aikana valitaan solu, jonka sisällä pelin hahmo on, ja piirretään sen solun PVS-listan objektit näkyviin. Kuva 3 esittää kuvattua tilannetta pelimaailmassa. Vasemmanpuoleisessa kuvassa on esitetty koko maailma ja oikeanpuoleisessa kuvassa on esitetty tilanne, jossa näytepiste, eli pelin hahmo, on tunnelin sisällä. Kaikki turha grafiikka jätetään prosessoimatta ja renderoidaan ainoastaan objektit, jotka näkyvät tunnelin sisältä. Molempiin kuviin on piirretty solut, joissa pelin hahmo voi liikkua. Soluja on ainoastaan pelin ajoradadalla ja sen välittömässä läheisyydessä. Pelin hahmo ei siis voi liikkua kovin kauaksi ajoradasta. Kuva 3: Pelin 3D-maailma. Vasemmanpuoleinen kuva esittää koko pelin maailmaa. Oikeanpuoleisen kuvan säteet kuvaavat maailman nähtävää osaa, kun pelin hahmo on tunnelissa. [1] PVS-tekniikan käyttö on hyödyllistä peleissä, joissa ilmenee kuvan 3 kaltaisia tilanteita. Kun hahmo on tunnelissa, huoneessa, käytävillä tai suurten peittävien objektien takana, on kannattavaa jättää peitossa olevat objektit prosessoimatta. Peleissä, joissa ei ole toistensa peittäviä objekteja kuten lintuperspektiivistä tarkkailtavissa jalkapallopeleissä, ei ole hyötyä käyttää PVS-tekniikkaa. 2 PVS: LAATU Potentially Visible Set-tekniikan laatua kuvataan kahden kriteerin avulla. Kriteerit ovat artefaktien (eng. artifacts) ilmeneminen sekä konservatiivisuus (eng. conservativiness) eli oikeallisuus. Artefaktit ovat virheitä, jotka syntyvät kun graafisesti esitetty pelin maailma ei 3

vastaa ohjelmallista toteutusta. Pelissä tämä ilmenee siten että joku tai jotkut nähtäväksi tarkoitetut objektit eivät ole näkyvissä. Kuva 4 esittää artefakti virheen pisteen X ja objektin A avulla. Jos pelin hahmo on pisteessä X, eikä näkyvää objektia A piirretä, on kyseessä artefakti-virhe. Konservatiivisuus on virhe, joka ilmenee kun graafisesti esitetty maailma ei ole optimointi ohjelmallisesta maailmasta. Pelin maailmasta ei siis puutu mitään objekteja, eli kuva on virheetön. Laadun aleneminen huomataan PVS-listan kasvamisena, kun turhia objekteja piirretään. Tämä hidastaa pelin kulkua sen pyöriessä. Kuva 4 esittää konservatiivisuus virheen pisteen X ja objektin B avulla. Jos grafiikka näyttää näköesteen takana olevan objektin B, on kyseessä konservatiivisuus virhe. Kuva 4: Artefakti- ja oikeallisuus-virheet. Jos objekti A jää käsittelemättä syntyy artefakti-virhe. Jos objekti B käsitellään syntyy oikeallisuus-virhe.[1] Mahdollinen virheiden syntyminen tulee ottaa huomioon myös ohjelmakoodissa. Oletuksena pidetään, että kaikki kolmiulotteisen maailman objektit on luotu kolmioista eli polygoneista. Jos kolmioiden väliin jää ohjelmakoodissa rako, syntyy niinsanottu t-risteys (eng. t-junction) (Kuva 5). Rako saattaa ihmissilmältä jäädä huomioimatta graafisessa esityksessä mutta PVS-laskenta huomaa raon ja luulee sitä tarkoitukselliseksi. T-risteys aiheuttaa konservatiivisuus-virheen, kun pienestä raosta näkyy sen takana olevia objekteja, joiden kuuluisi olla peitossa. Tämä tietysti kasvattaa PVS-listaa ja hidastaa koko peliä. Kuva 5: T-rako. Polygonien väliin jäävää rakoa kutsutaan t-raoksi. [1] 3 PVS: LASKENTATAVAT PVS-tekniikka voidaan jakaa kahteen osaan sen perusteella miten ratkaisu tuotetaan. Nämä tavat ovat näytteenotto (eng. sampling) ja analyyttinen (eng. analytic) eli laskennallinen. 4

Näytteenotto voidaan suorittaa lähettämällä säteitä (eng. casting rays) ja lisäämällä PVS-listaan ne objektit, joihin säteet törmäävät. Säteet kuvaavat aluetta, jonka pelin hahmo näkee. Näytteenotto-tekniikka saattaa aiheuttaa useita ongelmia. Jaan ongelmat kolmeen osaalueeseen: näytteenoton rajallisuudesta johtuvat artefakti-virheet, näytteenottosolujen lukumäärä ja sijoittaminen, sekä näytteenoton tarkkuus. Näytteenotto-tekniikka saattaa tuottaa artefakti-virheitä näytteenottojen rajallisen määrän vuoksi (Kuva 6). Mikään rajallinen määrä näytteitä ei voi taata virheetöntä tulosta. Jos yksikään näytteenottosäde ei törmää näkyvään objektiin, jää se renderoimattta lopullisesta graafisesta esityksestä. Tästä syntyy artefakti-virhe eli objekti, jonka kuuluisi näkyä ei näy. Näytteenotto-tekniikan tuottamat virheet eivät ole ennustettavissa, sillä jokainen näytteenottokerta tuottaa eri näytteet. Näytteenottopaikat sijoitetaan solun pinnalle, sillä kaiken mitä voi nähdä solun sisältä näkee myös solun pinnalta. Näytteenottopaikat täytyy sijoittaa mahdollisimman tasaisin välein maailmaan. Sijoituksen ongelman ratkaisussa voidaan käyttää Poisson disk distribution- tai stratified sampling-algoritmeja, mutta nekin antavat vain rajaarvon täydellisestä ratkaisusta. Täydellistä ratkaisua ei ole mahdollista toteuttaa äärellisellä määrällä näytteenottopaikkoja. Kuva 6: Artefakti-virheet 1. Solun sisällä olevasta näytepisteestä lähetetään säteitä. Säteiden rajallisen määrän vuoksi säteet löytävät ainoastaan objektit A ja C. Objekti B jää käsittelemättä, eli syntyy artefakti-virhe. Näytteenottosolujen lukumäärä ja niiden sijoittaminen aiheuttavat toisen ongelman. Solujen lukumäärän täytyy olla tarpeeksi suuri, jotta saataisiin minimoitua turhan grafiikan piirtäminen. Jos pelimaailma olisi jaettu vain yhteen soluun, täytyisi koko maailman grafiikka piirtää joka ruutuun. Solujen oikealla määrällä ja maailman järkevällä jaolla saadaan peli pyörimään tarpeeksi nopeasti. Lisäksi järkevästi jaettujen vierekkäisten solujen PVS-listat ovat keskenään hyvin samanlaisia, joten ne saadaan pakattua tehokkaasti. Pelimaailman jako soluihin on kuitenkin raskasta manuaalista työtä ja suuren solumäärän tuottaminen vaatii paljon aikaa. Solujen lukumäärä ja sijoittaminen tulee siis valita halutun laadun ja käytettävän ajan mukaan. 5

Kolmas ongelma liittyy näytteenoton tarkkuuteen (Kuva 7). Kun pelin maailma kuvataan graafisesti, on kuvan koko rajoitettu. Yleinen pelimaailman resoluutio on luokkaa 1024x768 pikseliä. Maailmassa saattaa olla pieniä objekteja, joihin näytteenottosäteet eivät osu. Ne jäävät PVS-listasta pois, jonka vuoksi niitä ei prosessoida lopulliseen kuvaan. Toinen syy objektien poisjäämiseen PVS-listasta on se, että ne näkyvät vain muiden objektien muodostamasta pienestä raosta. Pelimaailmassa saattaa olla niin pieniä objektien muodostamia rakoja, ettei näytteenottosäteet löydä niistä läpi. Tähän ongelmaan on kaksi osittaista ratkaisua. Pelimaailman kuva voitaisiin normaalin grafiikkakiihdyttimen sijaan laskea analyyttisellä rasterilla (eng. analytic rasterizer), jolla on ääretön tarkkuus. Tämä kuitenkin hidastaisi laskutoimituksia satakertaiseksi. Toinen ratkaisu on esittää objektit hierarkkisella mallilla. Suuret objektit, jotka koostuvat sadoista kolmioista, jaetaan pienempiin osa-alueisiin, esim. kymmenen kolmion joukkoihin. Jos jokin joukon kolmioista osuu näytesäteeseen, renderoidaan kaikki muutkin joukon kolmiot. Kuva 7: Artefakti-virheet 2. Näytteenottosäteet tavoittavat objektit A,C ja E, eli ne käsitellään lopulliseen kuvaan. Objekti B jää käsittelemättä, koska säteet eivät löydä sitä objektien A ja C muodostamasta raosta. Objekti D jää käsittelemättä, koska säteet eivät löydä sitä objektin pienen koon vuoksi. Objektit B ja D muodostavat artefaktivirheet. PVS-ratkaisu voidaan näytteenoton sijaan suorittaa analyyttisella laskennalla. Analyyttinen laskenta ei tuota arvaamattomia virheitä, sillä laskennan tulos on sama laskukerrasta riippumatta. Analyyttinen laskenta tuottaa matemaattisesti tarkemman tuloksen kuin näytteenotto, mutta se on huomattavasti raskaampi tekniikka. 4 PVS: STATIIKKA JA DYNAAMISUUS Pelimaailman objektien näkyvyyden laskenta ja PVS-listan luonti on raskasta ja aikaa vaativaa työtä. Tämän takia PVS-laskenta suoritetaan etukäteen (eng. pre-process) ja tallennetaan 6

tiedostoon. Pelin ajon (eng. run-time) aikana valmiiksi lasketut näkymät luetaan muistista kun pelin hahmo liikkuu solusta ja näytepisteestä toiseen. Staattisesti laskettu PVS-lista voi kuitenkin käsitellä ainoastaan staattisia objekteja eli paikallaanpysyviä objekteja. Jos pelissä on (usein onkin) dynaamisia, eli liikkuvia objekteja, on niiden näkyvyys käsiteltävä pelin ajon aikana. Pelien liikkuvia objekteja ovat esimerkiksi first person -ampumispelien viholliset, sekä autopelien kilpailevat autot. Yksi tapa saada liikkuvat objektit näkyviin olisi niiden piirtäminen joka kuvaan riippumatta niiden näkyvyydestä. Tämä yksinkertainen toteutus kuitenkin hidastaisia peliä, kun kaikki esteiden takana piilossa olevat objektit piirrettäisiin jokaiseen kuvaan. Parempi ratkaisu on täyttää staattinen maailma läpinäkyvillä alueilla, esimerkiksi kuutiolla (Kuva 8). Kuvan 8 kuutiot on kuvattu kaksiulotteisena yksinkertaistamisen vuoksi. Todellisuudessa kuutiot ovat kolmiulotteisia. Kuva8: Autopelin staattinen maailma on täytetty läpinäkyvillä kuutiolla. Läpinäkyvät kuutiot ovat staattisia, eli pysyvät paikallaan suhteessa muuhun maailmaan. Kuutiot käsitellään PVS-listan luonnissa kuin mitkä tahansa muutkin maailman staattiset objektit. Jokaisen pelimaailman solun PVS-listaan siis tallenetaan tavallisten objektien lisäksi kyseisestä solusta näkyvät kuutiot. Pelin aikana tutkitaan dynaamisten objektien näkyvyyttä kuutioiden sisällä (Kuva 9). Jos mikään dynaamisen objektin osa ei ole minkään näkyvissä olevan kuution sisällä, jätetään objekti piirtämättä. Jos taas joku dynaamisen objektin osa on näkysissä olevan kuution sisällä, piirretään objekti kuvaruudulle. 7

Kuva 9: Haetaan dynaamisten objektien näkyvyys kuutioissa. Näkyvä dynaaminen objekti piirretään edeltäprosessoidun staattisen maailman päälle (Kuva 10). Lopputuloksena saadaan maailma, joka pitää sisällään staattisen taustan sekä dynaamisia objekteja, joiden kanssa voidaan olla vuorovaikutuksessa. Kuva 10: Näkyvä dynaaminen objekti piirretään ajon aikana PVS-kuvan päälle. On tärkeää huomata että kaikkien staatisten objektien esimerkiksi pelimaailman teiden, maastojen, puiden ja rakennusten näkyvyys on siis laskettu valmiiksi. Ainoastaan dynaamiset objektit käsitellään kuvakuvalta (eng. per-frame basis) pelinajon aikana. 5 EXACT FROM-REGION VISIBILITY On tärkeää että objektit, jotka eivät ole näkyvissä saadaan poistettua mahdollisimman tarkasti, jotta ei suoritettaisi turhaa renderointia. Tärkeää on myös että kaikki objektit, joiden kuuluisi 8

näkyä myös näkyvät. Exact from-region visibility -tekniikka on staattinen PVS-toteutus, joka täyttää edellämainitut kriteerit. Termin from-region -osa tarkoittaa, että pelin maailma on jaettu alueisiin tai soluihin. Termin exact -osa tarkoittaa, että ratkaisu tuottaa virheettömiä kuvia optimaalisesti. Virheettömyydellä tarkoitetaan, että kaikki tarkoitetut objektit näkyvät. Optimaalisuudella tarkoitetaan, että kaikki turhat objektit on jätetty pois. Exact from-region visibility -tekniikka laskee näkyvyyden kolmiulotteiselta alueelta, solusta, jossa pelin henkilö liikkuu. Tämä eroaa siis yksittäisestä näytteenotosta, jossa näkyvyys haetaan ainoastaan yhdestä näytepisteestä. Pelimaailman soluja saattaisivat olla esimerkiksi huoneet tai käytävät, joiden alueelta nähdään samat objektit. S. Nirenstein, E. Blake ja J. Gain käsittelevät aihetta artikkelissaan: Exact From-Region Culling. He esittelevät ensimmäisen exact from-region culling algoritmin, joka toimii realistisen kokoisissa maailmoissa (koostuu 1,5 miljoonasta polygonista). Heidän ratkaisunsa tarjoaa optimaalisen renderointi ajan käsittelemällä ainoastaan objektit, joiden kuuluisi näkyä. Ratkaisussa käytetään kahta uutta tekniikkaa, lokalisoitua tarkka näkyvyys algoritmia (eng. Localised Exact Visibility) ja tiedustelu arkkitehtuuria (eng. Query Driven Architecture). Lokalisoitu tarkka näkyvyys algoritmi hakee näkyvyyden kahden konveksin polygonin välillä. Tiedustelu arkkkitehtuuri käsittelee näkyvien objektien haun optimointia. Tarkoituksena on ryhmitellä polygonit niin ettei lokalisoidun tarkka näkyvyys algoritmin tarvitse hakea näkyvyyttä kaikkien polygonien välillä, vaan osa polygoneista voidaan jättää käsittelemättä. Näkyvyys konveksin polygonin alueelta saadaan laskemalla näkyvyys sen rajoilta. Lokalisoitu tarkka näkyvyys algoritmi lähettää näytteenottosäteitä solusta tutkittavaa polygonia kohden. Jos kaikkien säteiden eteen tulee este, eivätkä ne pääse tutkittavalle polygonille, on polygoni näkymätön kyseisestä solusta. Jos jokin säteistä pääsee tutkittavalle polygonille, on polygoni nähtävissä ja se lisätään PVS-listaan. Tutkittavien polygonien joukko muodostuu tiedustelu arkkitehtuurin antamasta polygoni joukosta. Tiedustelu arkkitehtuurin tehtävä on antaa lokalisoidulle tarkka näkyvyys algoritmille tutkittavien polygonien joukko. Näkyvyyttä kaikkiin maailman polygoneihin ei kannata tutkia, koska mitä todennäköisimmin suurin osa niistä ei ole näkyvissä. Tiedustelu arkkitehtuurin tarkoituksena on ryhmitellä polygonit tehokkaasti, jotta selvittäisiin mahdollisimman pienellä määrällä hakuja. Se käsittelee alueen kahden tason hierarkiana, polygonien ryhmänä ja yksittäisinä polygoneina. Ensimmäiseksi haetaan polygoni ryhmän äärialue (eng. bounding box). Jos äärialue ei ole näkyvissä, on selvää että myöskään sen sisällä olevat polygonit eivät ole ja ne voidaan poistaa käsittelystä. Jos äärialue on näkyvissä, ovat sen sisällä olevat polygonit potentiaalisesti näkyvissä, jolloin ne käsitellään erikseen. 6 YHTEENVETO PVS-tekniikan (tai muun vastaavanlaisen tekniikan) käyttö on edellytyksenä, että nykyaikaiset pelit saadaan toiminaan kunnolla. Pelimaailmat on muodostettu miljoonista polygoneista, joiden kaikkien kerrallaan piirtäminen vie liian kauan, eikä peli siten pyöri tarpeeksi nopeasti. Jo vuonna 1996 julkaistun Quaken 10 000 polygonin maailmat aiheuttivat pahimmassa tapauksessa yli kymmenkertaisen päällepiirron (eng. overdraw). 9

Kun pelimaailman polygoneista muodostettuja objekteja piirretään näkyviin, tärkeintä on että kaikki minkä kuuluisi näkyä myös näkyy. Jos pelin aikana piirretään hiukan turhaa grafiikkaa (20-30%) se ei varmasti haittaa niin paljon kuin nähtäväksi tarkoitetun grafiikan puuttuminen. Kun turhan grafiikan piirto kasvaa moninkertaiseksi tarpeelliseen verrattuna, hidastaa se pelin kulkua huomattavasti. Kolmiulotteisissa peleissä on usein paljon päällekäistä grafiikkaa, josta kannattaa siis piirtää vain päälimmäinen. Kuvat 11 ja 12 näyttävät kuinka paljon pelimaailmoissa saattaa olla päällekäisiä objekteja. Kuvissa keltainen laatikko edustaa solua, jossa pelaaja kyseisellä hetkellä on. Maailman vihreät osat ovat objekteja, jotka näkyvät kyseisestä solusta. Nämä objektit ovat solun PVS-listassa. Punaiset osat eivät näy solusta, joten niitä ei lisätä PVSlistaan, eikä niitä piirretä näkyviin. Molemmat kuvat osoittavat, että tämänkaltaisissa pelimaailmoissa turhan grafiikan osuus on huomattava nähtävään grafiikkaan verrattuna. Kuva 11: Pelimaailman kaupunki. Keltaisesta solusta näkyvä grafiikka on kuvattu vihreällä ja näkymätön grafiikka on kuvattu punaisella [4] Kuva 12: Pelimaailman metsä. Keltaisesta solusta näkyvä grafiikka on kuvattu vihreällä ja näkymätön grafiikka on kuvattu punaisella [4] 10

LÄHTEET [1] Kalle Raita. Hybrid spvs. http://www.hybrid.fi/download/spvs_whitepaper.pdf (saatavilla 7.4.2003) [2] Airey, J., J. Rohlf, and F. P. Brooks, Jr., 1990: "Towards Image Realism with Interactive Updates in Complex Virtual Building Environments," Computer Graphics: Proc. 1990 Symposium on Interactive 3D Graphics [3] Timo Aila and Konsta Hansson. Potentially visible sets, Part one, 2002. http://www.hybrid.fi/articles/develop1.html (saatavilla 7.4.2003) [4] Shaun Nirenstein, Edwin Blake and James Gain. Exact From-Region Visibility Culling, 2002. Thirteenth Eurographics Workshop on Rendering. http://people.cs.uct.ac.za/~snirenst/nirenstein_se_1.pdf (saatavilla 7.4.2003) [5] Michael Abrash. Inside Quake: Visible-Surface Determination, 2000. http://www.bluesnews.com/abrash/chap64.shtml (saatavilla 7.4.2003) [6] Jiri Bittner, Jan Prikryl and Pavel Slavik. Exact Regional Visibility using Line Space Partitioning. To appear in Computers&Graphics, Vol. 27/4, 2003 http://sgi.felk.cvut.cz/~bittner/publications/cg02.pdf (saatavilla 7.4.2003) [7] Jiri Bittner and Peter Wonka. Visibility in Computer Graphics. To appear in Journal of Environment and Planning B, Pion Ltd., 2003 ftp://ftp.cg.tuwien.ac.at/pub/tr/03/tr-186-2-03-03paper.pdf (saatavilla 7.4.2003) 11