void gluPerspective( GLdouble fovy, GLdouble aspect, GLdouble zNear, GLdouble zFar ) fovy Specifies the field of view angle, in degrees, in the y direction. aspect Specifies the aspect ratio that determines the field of view in the x direction. The aspect ratio is the ratio of x (width) to y (height).
Nuo openGL oppaasta. Eli käsittääkseni tuo fovny kuvaa siis ylös ja alas suunnilla ja aspect kertoisi sivuttaisen suhteen width/height laskulla. Eli jos nyt olettaisi että fovny on 45 astetta ja näytön resoluutio vaikka 800x600 niin aspect olisi 800/600=1.3333... ja katselukulma olisi 60 astetta?
Joten esimerkiksi seuraavassa kuvassa:
www.tneva.net/pics/piirtoalue.jpeg
(ja juu kuvan laatu on surkea. En ole koskaan väittänykkään olevani artisti :D Osaan piirtää tikku-ukkoja ja siinä se...)
Jos tiedän A:n ja kulman(tuossa tuo 60) voin laskea C:n trigonometrisesti ja ottamalla A:n päätepisteen koordinaatit(plus lähtöalueen) laskea alueen joka kattaa koordinaatit joka ei jätä piirrettäviä ulos(kuvassa katkoviivojen rajaama alue. Juuh ei jätä kaikkea piirtoalueen ulkopuolelle mutta yritän keksiä optimoidumman kaavan mutta alkuun mahdollisimman simppeli).
Ideanahan siis on rajata openGL:ssä piirrettävää aluetta mahdollisimman paljon. Jos piirrettävä kartta sisältää tuhansia verteksejä turha niitä kaikkia piirtää. Käy myös turhan hitaaksi tarkistaa onko yksittäinen verteksi näköetäisyydellä(tai kulmassa) joten yritän kehitellä systeemiä jolla rajataan kartasta iso osa veks ja jätetään vain pieni osa for loopin piirrettäväksi. Samaa tekniikkaa käytetään rajaamaan valtaosa objekteista(olennot etc) veks ettei niihin käytetä edes senkäänvertaa aikaa että lasketaan onko etäisyydellä(mikä taitaisi muuteskin olla hidasta kiitos neliöjuurien etc).
Vai olenko täysin hakoteillä ja ongelmaan olisi helpomikin ratkaisu?-)
Ja pieni korjaus. Luvun pitäisi käsittääkseni siis olla 30 eikä 60 joka on siis kokonaiskulma.
Ei, nyt et osaa laskea.
fov_x = asin(sin(fov_y) * aspect)
asin(sin(45°) * 4/3) = 70,5° pyöreästi.
Muutenkin olet täysin hakoteillä ideasi suhteen. Ensinnäkin myös trigonometria on "hidasta", pikainen testi osoitti sinifunktion vievän moninkertaisesti aikaa neliöjuureen nähden. Toiseksi et edes tarvitse trigonometriaa vaan voit tehdä tarkistukset paljon tehokkaammin pistetulon avulla; voit myös määritellä perspektiivin glFrustum-funktiolla, jolloin kulmat eivät ole tuossa johtamassa harhaan.
Tämänkään jälkeen ratkaisumalli ei ole tehokas itse ongelmaan, koska joudut yhä käsittelemään jokaisen pisteen. Oikea tapa on tietorakenne nimeltä octree.
Metabolix kirjoitti:
pikainen testi osoitti sinifunktion vievän moninkertaisesti aikaa neliöjuureen nähden.
Neliöjuuri tarvittaisiin 1 per objekti(ja kartan tapauksessa verteksi). Trigonometriaa tarvitaan vain neljän rajapisteen selvittämiseen ja senjälkeen voi heittää häränpyllyä sille. 4 vs satoja? Tuhansia? Kymmeniä tuhansia? Enemmän? Kumpi vie kauemmin?
lainaus:
Tämänkään jälkeen ratkaisumalli ei ole tehokas itse ongelmaan, koska joudut yhä käsittelemään jokaisen pisteen. Oikea tapa on tietorakenne nimeltä octree.
Enkä joudu. Joudun vain käymään läpi tuon neliön sisällä olevat mikä on vain murtoosa(jopa alle prosentti) kaikesta mahdollisesta mitä siellä tulee.
Käsitin, että laskisit sillä trigonometrialla, onko piste alueen sisällä. Selityksesi ei nimittäin ole kovinkaan selvä (ja kaipaisi yhä täydennystä).
Tarkoitan pisteen käsittelyllä nyt tosiaan sitä pisteen näkyvyyden laskemista enkä itse piirtämistä. Vai miten sitten ajattelit selvittää ne piirrettävät pisteet, jos et tarkista kaikkia (etkä käytä octreen kaltaista tietorakennetta)?
Metabolix kirjoitti:
Käsitin, että laskisit sillä trigonometrialla, onko piste alueen sisällä. Selityksesi ei nimittäin ole kovinkaan selvä (ja kaipaisi yhä täydennystä).
Sillä lasketaan(mahdollisimman pieni sellainen) alue joka piirretään kartasta joka on julmetusti isompi. Jos esimerkkikuvan valkoista aluetta laajennat niin pitkälle kuin huvittaa ajatella ja kuvittelet sitä sitten kartaksi josta piirrän vain mainitun alueen koordinaatit niin olet oikealla jäljellä.
On tuossa pieni alue laitojen välillä joskin pitäisi olla mahdollista keksiä nopea algoritmi rajata for looppeja senverran että pienentää aluettansa.
Eli siis rajaan pienen neliön kartasta joka kattaa mahdollisimman tiukasti näkökentän.
Ja varmasti octree on kätevin mutta vaikuttaa myös vaikeimmalta toteuttaa niin että päivittyy dynaamisesti ohjelman aikana ja ei vaadi .OBJ tiedostoa monimutkaisempaa 3d-malli tiedostoa. Kun en käytä julmetusti polygoneja objekteihini ei tarvitse edes olla state-of-the-art moottori kunhan vain ei koko pahuksen karttaa ala piirtämään.
Yksi heikkous tässä tulee olemaan Y komponentti. En ole viellä funtsinut miten tuon ratkon mutta toisaalta ei kartat tule olemaan tuossa suhteessa monitasoisia. Ei kerrostaloja etc nykyaikaisen kaupungin elementtejä joten ei pitäisi tuottaa mahdottomia ongelmia(ainakaan niin pahoja etten voisi saada jonkinsortin raakaversiota toimimaan. Optimoinnille on aikaa kunhan saan edes summittain toimimaan).
3D-kortit on aika tehokkaita kyllä jättämään tarpeettomat kolmiot piirtämättä. Jos pystyt rajaamaan jo tuollasen nelikulmasen alueen jonka piirtää niin se on jo hyvä optimointi, ainakin alkuun.
Itsellä on korttina Geforce 8600GT joka on jo suht vanha. Pieni testiohjelma jossa oli skrollaava kartta ja ei mitään piirtoalueen optimointeja. Laitoin kauheen massan yksiköitä pienelle alueelle (satojatuhansia polygoneja ilmeisesti) ja hidastu aina sen kohdalla, skrollaa kuvan muualle niin piirtää yhtä nopeesti kun ei mitään olis.
User137 kirjoitti:
3D-kortit on aika tehokkaita kyllä jättämään tarpeettomat kolmiot piirtämättä. Jos pystyt rajaamaan jo tuollasen nelikulmasen alueen jonka piirtää niin se on jo hyvä optimointi, ainakin alkuun.
Itsellä on korttina Geforce 8600GT joka on jo suht vanha. Pieni testiohjelma jossa oli skrollaava kartta ja ei mitään piirtoalueen optimointeja. Laitoin kauheen massan yksiköitä pienelle alueelle (satojatuhansia polygoneja ilmeisesti) ja hidastu aina sen kohdalla, skrollaa kuvan muualle niin piirtää yhtä nopeesti kun ei mitään olis.
Jooh vähän samat huomiot ja juuri tuontakia tuo oli ainakin alkuun ideana. Octree kyllä vaikutti kätevältä(olen ennenkin tuohon törmänny :D) mutta myös selvästi vaikeammalta toteuttaa. Alan miettiä myöhemmin jos tulee ongelmia nopeuden suhteen mutta huomioiden polygonimäärä josta puhutaan(=ei iso per objekti. Olen karmea artisti mikä pätee myös 3d-mallintamiseen :D) veikkaan että isoimmat pullonkaulat on ihan muualla.
Nyt pitää vain funtsia geneerinen algoritmi jolla selvittää tuon neliön koordinaatit. Vaatisi X akselilta vasemman ja oikean laidan ja Z akselilta ylä ja ala laidan. Joku noista on satavarmana 0(mutta mikä) ja loput pitää jollain tavalla sumplia(yksi iso ongelma on tuo katselukulma joka muuttuu resoluution vaihtuessa, ts. pitäisi tuokin ottaa huomioon).
User137 kirjoitti:
Itsellä on korttina Geforce 8600GT joka on jo suht vanha.
Minusta taas tuo on mahdollisimman huono perustelu sille, että tekee hitaan pelin. Jos grafiikka on samaa tasoa kuin vuoden 1998 Unrealissa, pelin pitää minusta toimia suunnilleen vastaavilla laitteistoilla. Toki harrastelijalle sallitaan hieman heikompi lopputulos, mutta kyseinen peli kuitenkin toimii vallan mainiosti muinaisilla NV:n TNT-näytönohjaimilla, joten harrastelijan versio saisi minusta tällöin vaatia enintään GF2:n tehotason, joka on jo aika paljon enemmän.
Metabolix kirjoitti:
Minusta taas tuo on naurettava perustelu sille, että tekee hitaan pelin.
Joten aloittelijan pitäisi heti mennä tekemään 3d-moottori kaikilla herkuilla kun ei edes pysty tekemään 3d-malleja jotka edes HYÖDYNTÄISI kaikkea sitä tehoa :D Ja kun kiinnostuksen aihe ei varsinaisesti ole edes 3d-moottori vaan se on vain yksi elementti joka on oltava jotta lopussa on mitään järkeä.
Octree on varmasti kiva ratkaisu mutta sanoppa. Kuinka helppoa tuo on toteuttaa niin että se myös päivittää itse itsensä dynaamisesti? Objektit liikkuu, objekteja ilmestyy keskenkaiken(isojakin objekteja. Periaatteessa voidaan puhua kokonaisesta linnasta joka ilmestyy keskenkaiken ja pitäisi siis pystyä sisällyttämään octreehen lennosta).
Kun en ole edes staattista octreetä ymmärtänyt niin miten helppoa olisi toteuttaa tuollainen?
Ja jälleen: Miksi nähdä ylimmääräistä vaivaa ennenkuin se on tarpeen/on enemmän aikaa pakerrella sen kanssa? Jos nyt alkaisin tuota väsäämään en pystyisi varsinaista hauskuutta päästä kasaamaan ties kuinka kauan. Ja ainut hyötyä siitä käytännössä olisi(poislukien tietty oppi mikä olisi syy minkätakia tutkisin sitä myöhemmin) että jotkut ikivanhat koneet ehkä piirtäisivät homman kyllin nopeasti vs ilman tuota(olettaen siis ettei mallit ole niin yksinkertaisia että vanhatkin piirtävät ongelmitta). Kun ei mallit ole monimutkaisia(3d-vastineita tikku-ukoille lähinnä :D) ei piirtonopeudesta pitäisi tulla ongelmia alkuun.
Tuon ehtii toteuttaa myöhemminkin. Jos tästä tulisi nyt jotain valmiimpaa jonka haluaisin levittää pitäisi uudelleenkirjoittaa koko roska pari kertaa uusiksi jokatapauksessa. a) yleinen algoritmien nopeutus b) UDP eikä TCP c) monisäikeinen d) monikoneinen(ts. useampi kone tekee samaa hommaa). Nuo nyt olisi minimivaatimuksia jos tämä olisi jotain muutakin kuin oppimisprojekti. Enkä näe mitä hyötyä on toteuttaa heti vaikeimman kautta toteuttaakseen vain välttämättömän pahan.
tneva82 kirjoitti:
Joten aloittelijan pitäisi heti mennä tekemään 3d-moottori kaikilla herkuilla
Ei, vaan aloittelijan pitää tehdä se yksinkertainen 3d-moottorinsa niin, että kun se kerran vain piirtää yksinkertaisia malleja, niin ei sitten tarvitse niiden piirtämiseen GeForce 715517 STFU:ta vaan pärjää vaikka sitten GF2:lla.
tneva82 kirjoitti:
kun ei edes pysty tekemään 3d-malleja jotka edes HYÖDYNTÄISI kaikkea sitä tehoa
No parempi sitten jättää se teho käyttämättä eikä tuhlata sitä turhaan. eihän sitä kukaan ole käskenyt käyttääkään.
tneva82 kirjoitti:
Octree on varmasti kiva ratkaisu mutta sanoppa. Kuinka helppoa tuo on toteuttaa niin että se myös päivittää itse itsensä dynaamisesti?
Ei ole helppoa muttei kyllä tarkoituskaan. Ideana ei ole tunkea samaan puuhun kaikkia objekteja. Esimerkiksi taso, joka pysyy staattisena, laitetaan yhteen octreehen, jolloin sitä ei tarvitse päivittää lainkaan. Se kuitenkin sisältää jo hyvin suuren osan piirrettävästä materiaalista. Varsinaisten yksiköiden ja muiden tarkistus voidaan tehdä riittävän tarkasti vaikka sitten keskipisteen mukaan, jolloin siitä tuhannen polygonin mallista tarvitsee tarkistaa vain keskipisteen sijainti eikä kaikkia tuhatta polygonia erikseen.
tneva82 kirjoitti:
Periaatteessa voidaan puhua kokonaisesta linnasta joka ilmestyy keskenkaiken ja pitäisi siis pystyä sisällyttämään octreehen lennosta.
Ei, vaan sillä linnalla voi olla oma, staattinen octree (eihän se linna sentään muutu kovasti?), jolloin siitä voidaan helposti piirtää vain näkyvä osa.
tneva82 kirjoitti:
Ja jälleen: Miksi nähdä ylimmääräistä vaivaa ennenkuin se on tarpeen/on enemmän aikaa pakerrella sen kanssa?
Eipä miksikään, siksi kannattaakin harkita vakavasti myös valmiin grafiikkamoottorin käyttöä. Mutta siinä vaiheessa, kun aikoo jotain julkaista yleisölle, kannattaa kyllä hieman vaivaakin nähdä. Ei montakaan taida kiinnostaa 2D-tetris, joka vaatii uutta, kallista rautaa.
Metabolix kirjoitti:
Varsinaisten yksiköiden ja muiden tarkistus voidaan tehdä riittävän tarkasti vaikka sitten keskipisteen mukaan, jolloin siitä tuhannen polygonin mallista tarvitsee tarkistaa vain keskipisteen sijainti eikä kaikkia tuhatta polygonia erikseen.
Tuokin ikävää jos objekteja on vimmatusti. Jo pelkkä läpikahlauksessa läpitarkistuksen kohdalla menee oma tovinsa. Kiva yrittää tehdä se 40+ FPS. Tässä rajataan objektien määrää automaattisesti pienempään määrään.
lainaus:
Ei, vaan sillä linnalla voi olla oma, staattinen octree (eihän se linna sentään muutu kovasti?), jolloin siitä voidaan helposti piirtää vain näkyvä osa.
Miten tuo siis toteutetaan jos linna ilmestyy kartalle keskenkaiken tyhjästä? Siis hetkellä X linnaa ei ole, seuraavalla loopilla linna on ja pitäisi piirtää.
lainaus:
Eipä miksikään, siksi kannattaakin harkita vakavasti myös valmiin grafiikkamoottorin käyttöä.
Tappaisi tarkoituksen ;-)
lainaus:
Mutta siinä vaiheessa, kun aikoo jotain julkaista yleisölle, kannattaa kyllä hieman vaivaakin nähdä. Ei montakaan taida kiinnostaa 2D-tetris, joka vaatii uutta, kallista rautaa.
Noh tuskin tämä nyt edes vaatii uusinta rautaa ja jos vaatii niin a) pullonkaula ei ole grafiikkamoottorissa b) pullonkaulan ratkominen on jossain ihan muualla kuin miten tämä tieto tallennetaan. Vanhakin näytönohjain riittänee mainiosti.
Mutta kuka sanoi että tästä tulee jotain mitä julkaistaan?-) Ei mulla ole resursseja tehdä tästä sellaista joka kannattaisi julkaista. Puhumattakaan erillisistä palvelimista nopeilla nettiyhteyksillä joka olisi tarpeen. Puhumattakaan halua alkaa kilpailemaan kaupallisten ratkaisujen kanssa 3d-tikku-ukoilla(vai mistä mie ne paremmat mallit taion :D)
tneva82 kirjoitti:
Jo pelkkä läpikahlauksessa läpitarkistuksen kohdalla menee oma tovinsa.
Millä tavalla tämä läpikahlaus on hitaampi kuin se, jonka itse joudut tekemään? :D Samoja optimointeja voi käyttää edelleen, ja nythän tarkistus on nopeampi, kun se tehdään joka objektille vain kerran eikä joka polygonille erikseen (vai miten ajattelit?).
tneva82 kirjoitti:
Metabolix kirjoitti:
Ei, vaan sillä linnalla voi olla oma, staattinen octree.
Miten tuo siis toteutetaan jos linna ilmestyy kartalle keskenkaiken tyhjästä?
No mistä tyhjästä se linna sitten ilmestyy? Samassa paikassa sen octreenkin voi pitää (ts. sen voi laskea jo, kun malli ladataan). Octreen koordinaatit ovat silloin tietenkin suhteessa linnan keskipisteeseen.
Jospa nyt vain jatkaisit sitä opettelua, niin jatketaan juttua sitten parin kuukauden kuluttua? ;)
Metabolix kirjoitti:
ja nythän tarkistus on nopeampi, kun se tehdään joka objektille vain kerran eikä joka polygonille erikseen (vai miten ajattelit?).
Eihän tässäkään systeemissä objektia tarkisteta kuin kerran eikä joka polygonille.
lainaus:
No mistä tyhjästä se linna sitten ilmestyy? Samassa paikassa sen octreenkin voi pitää (ts. sen voi laskea jo, kun malli ladataan). Octreen koordinaatit ovat silloin tietenkin suhteessa linnan keskipisteeseen.
Se ei vain ilmesty tyhjästä vaan ennalta määräämättömään paikkaan. Siis yksinkertaisimmiten: Joku käyttäjä sanoo että tähän tulee nyt linna. Bang. Linna on siinä. Ja tämän pitäisi näkyä kaikille samantien.
Mutta jälleen: Miksi tehdä tuo vaikeimman kautta kun jokainen markkinoilla oleva näytönohjain riittää tarkoituksiin? Hitaimmasta ei ole haittaa, nopeimmasta ei ole hyötyä. Mitä käytännön haittaa siitä siis on että en toteuta monimutkaista octree systeemiä kun vanhinkin myytävänä oleva näytönohjain omaa ylijäämätehoa tarpeisiin nähden kunhan en nyt koko maailmaa kerralla ala piirtämään?-) Ja maailman nyt rajaan pienempään tälläkin systeemillä. Plus saletisti helpompi toteuttaa. Mieluummin otan ratkaisun jolla saan homman edes jonkinlaiseen pisteeseen valmiiksi järjellisessä ajassa kuin sellaisen jolla pääsisin ehkä testaa raakaversiota joskus ensi vuonna ;-) Vaikka sitten tarkoittaisi että olisi vähemmän optimoitu. Jos hitainkin markkinoilla oleva 3d-kortti pyörittää niin kyllin hyvä tarpeisiini. Murehditaan octreetä sitten kun on aikaa tai jos jostain taivaallisesta lahjasta opin tekemään sellaisia 3d-malleja että optimoidumpi moottori on tarpeen.
Aihe on jo aika vanha, joten et voi enää vastata siihen.