Tuollaisia kaipaisin. Erityisesti sellaisia joissa käsiteltäisiin kameraa ja objektien liikuttamista muuttuvilla sijainneilla, sekä objektin että "kameran"(lainausmerkeissä koska openGL:ssä ei ilmeisesti varsinaista kameraa ole. Ärrinmurrin. Mokoman simulointi sai aikaan perkuleen paljon työtä). Olen jo bongannut useamman joissa opastetaan kuinka piirretään yksittäisiä ja pyöritetään niitä paikallaan mutta en ole kunnon opasta löytänyt kuinka saada aikaan vaihtuvan "kameran" ja liikkuvan objektin.
Kaipaisin vähän apua parantaakseni koodiani. Nyt taitaa toimia mutta ei taida olla erityisen hyvä(ja resurssisyöppö taitaa olla useampia objekteja tehdessä kun "kamera" pitää alustaa kokoajan).
Tällanen vois olla 1 esimerkki:
// Alustus glClear(.. glLoadIdentity // Kamera (esim glTranslatef, glRotate, gluLookAt tai glMultMatrix käskyillä) // Avaruussimulaattori tarvitsis jo oman matriisin ... PiirraMaasto // Objektit for (jokainen objekti) glPushMatrix // Tallennetaan nykyinen sijainti glTranslatef(objektin sijainti) glRotate(objektin pyöritys) // TAI rotaten sijaan glMultMatrix jos haluat vapaamman pyörityksen // mutta suuremman resurssienkäytön PiirraObjekti glPopMatrix // Palautetaan edellinen sijainti end for
Ei se kamera mitään resursseja syö. Kannattaa yrittää hahmottaa, "miten OpenGL toimii". Tarkoitan tässä nimenomaan sitä, mitä glRotate, glTranslate sekä glPopMatrix ja glPushMatrix tekevät. Verrattuna siis siihen, että voit opetella ulkoa tai kopioida jostakin koodin, joka oikein käytettynä siirtää tai kiertää kameraa tai objekteja.
Hyvät OpenGL-tutoriaalit taitavat olla netissä aika kiven alla. Esim. NeHe on mielestäni vähän liikaa "koodataan yhdessä huonosti C:tä" -henkinen tutoriaali. Ehkäpä jokin kirja olisi hyvä.
os kirjoitti:
Hyvät OpenGL-tutoriaalit taitavat olla netissä aika kiven alla. Esim. NeHe on mielestäni vähän liikaa "koodataan yhdessä huonosti C:tä" -henkinen tutoriaali. Ehkäpä jokin kirja olisi hyvä.
Minusta NeHen tutoriaalit ovat oikein erinomaisia, sillä ne eivät sinänsä sekoita millään kielihienosteluilla - vaikkakin voivatkin aloittelijaa hämätä huonoilla ohjelmointityyleillään, se asia mitä se oikeasti yrittää opettaa, eli OGL:n käyttö, välittyy meikän puolesta suht tehokkaasti.
Osote niihin on http://nehe.gamedev.net/, mutta ainut homma on siinä, että ne eivät kata OGL:n versioita 3.0+ ja lähestymistapa asioihin on jäänyt vähän vanhaksi.
Joka tapauksessa - Siitä kyllä oppii ja paljon tietynlaisesta lähemystistavasta, vaikkei välttämättä kykene suoraan kääntämään sitä moderniksi ja hyödylliseksi osaamiseksi. Täysin turhaa tietoa ja taitoa ei juuri ole.. :)
User137 kirjoitti:
Tällanen vois olla 1 esimerkki:
Noh näköjään tekemäni versio oli melkolailla prikulleen tuo joten kaippa mie sen sitten oikein sain kasattua.
os kirjoitti:
Tarkoitan tässä nimenomaan sitä, mitä glRotate, glTranslate sekä glPopMatrix ja glPushMatrix tekevät.
Oletan että ytimeltään koostuvat matriisilaskuista(ainakin siinä käsityksessä olen) jolloin liiallinen käyttö saa aikaan liikaa laskuja=laskuaikaa menee.
Ja nehe:n olen jo löytänyt mutta ainakaan tähän mennessä en ole bongannu tuota kameran ja objektin liikuttelua käsittelevää opasta.
OpenGL ohjelmointiin assemblyllä löytyy 40 kpl hyvää esimerkkiä osoitteesta:
http://pagesperso-orange.fr/franck.charlet/Ogl_Asm.zip
Noista gluLookAt_Camera vosi olla mielestäsi mielenkiintoinen. Luulen, että C:llä normaalisti ohjelmoivakin voisi saada noista jotain irti.
tneva82 kirjoitti:
os kirjoitti:
Tarkoitan tässä nimenomaan sitä, mitä glRotate, glTranslate sekä glPopMatrix ja glPushMatrix tekevät.
Oletan että ytimeltään koostuvat matriisilaskuista(ainakin siinä käsityksessä olen) jolloin liiallinen käyttö saa aikaan liikaa laskuja=laskuaikaa menee.
Ja nehe:n olen jo löytänyt mutta ainakaan tähän mennessä en ole bongannu tuota kameran ja objektin liikuttelua käsittelevää opasta.
No siis, ei siinä mitään taikatemppua ole. Objekteja liikutetaan käänteiseen suuntaan siitä mihin "kamera"/katsoja liikkuu.
http://nehe.gamedev.net/data/lessons/lesson.asp?
Sen lisäksi glRotate yms ei todellakaan vie liikaa prosessointiaikaa. Turha niitten käyttöä on rajoittaa jos on tarvetta käyttää.
Polygonien normaalien kanssa tuli pieni ongelma. Käytän tälläistä systeemiä normaalin laskemiseksi(wikipediasta):
(a2b3 - a3b2) i + (a3b1 - a1b3) j + (a1b2 - a2b1) k
Laskeaksi vektorit annan kolme pistettä kuutiosta vastapäivää järjestyksessä. Ongelma: Mitkä kolme? Pitääkö oikeat pisteet määritellä käsin vai onko olemassa joku tapa laskea se? Vai pitäisikö kehitellä toinen kaava joka ottaisi neljä pistettä parametreina? Vai pitääkö suosiolla siirtyä kolmioiden käyttöön?
glRotate ynnä muut muuttavat kulloistakin matriisia (ks. glMatrixMode), jolloin jokainen tällaisen kutsuminen aiheuttaa yhden 4x4-matriisien kertolaskun. Pyöritysten ja siirtojen määrä ei siis vaikuta siihen, paljonko myöhemmät operaatiot vievät aikaa. Tilannetta voi verrata int-kertolaskuun: lasku a*b vie aivan saman ajan riippumatta siitä, montako operaatiota a:n kanssa on tehty ennen tätä.
Normaalin laskemiseen kelpaavat mitkä tahansa neliösi kolme pistettä, kunhan järjestys on oikea. Kuutiolla on tietenkin kuusi normaalia, joka sivulla omansa.
Kolmioiden käyttö kannattaa, ne ovat matemaattisesti helpompia esimerkiksi törmäyksissä ja muissa juuri siksi, että kolme pistettä muodostavat aina tason eikä niiden käsittelyssä tarvitse huomioida mitään erikoisuuksia. Esimerkiksi nelikulmiosta voi saada ongelman, jos kulmat järjestää väärin.
Kaavoja ei myöskään kannata kopioida ymmärtämättä, kuten olet taas tuossa tehnyt. Kyseessä on tavallinen vektorien ristitulo, ja tuon ymmärtäminen ja käsittäminen täysin on melkoisen tärkeää.
lainaus:
Normaalin laskemiseen kelpaavat mitkä tahansa neliösi kolme pistettä, kunhan järjestys on oikea. Kuutiolla on tietenkin kuusi normaalia, joka sivulla omansa.
Joo mutta keksin neljä eri kolmen pisteen yhdistelmää kuution yhdelle sivulle jotka menee vastapäivään ja ainakin pikaisesti testaamalla tunki erillaista normaalivektoria.
Jokatapauksessa siirryin suosiolla kolmioihin. Sillä tuota ongelmaa ei ole joten riittää että määrittelen polygonien pisteet oikein päin. Nyt sitten yritän saada mip-mappausta toimimaan. Kuva kyllä tulee mutta jossainvaiheessa värit katosivat :-/ Harmaa tekstuuri ei juuri silmiä hivele. Noh jossain joku typo varmaan tullut.
Normaalin suunta on pisteistä riippumatta sama, jos vain pisteet ovat todella tasossa. Jos haluat siitä yksikkömittaisen (kuten luultavasti haluat), joudut normalisoimaan sen eli jakamaan komponentit vektorin pituudella. Tämä täytyy tehdä yhtä lailla sen kolmionkin kanssa.
Aihe on jo aika vanha, joten et voi enää vastata siihen.