és most tisztelt uraim, a heti ATi-fikázás:

Az ATi 10.2 legacy driverekkel a GENERATE_MIPMAP_SGIS autómatikus mipmapgenerálás NPOT textúrákra r(v)3xx kártyákkal misztikus pixelmaszatokat és elfeketedéseket varázsol be az összes mipmapszintre az adott textúrához.

(de durva már vazze hogy az ati nem bír megírni egy képátméretezést)

Idézet

---

Seeting :

Idézet

---

Joga :
no igen, végülis megvizsgálni, hogy melyik test van közelebb szebb és jobb megoldást ad, mint a depth bufferes trükközés és még helyes is

---

De nem akar fölöslegesen lassítani a renderelést azzal, hogy mindig rendezem a modelleket rajzolás előtt.

---

Kétlem, hogy nagyon belassítaná egy egyszerűbb rendezés, egy bsp-vel pl egész szépen meg lehet ne oldani

És akkor nyugodtan bekapcsolva hagyhatom a depth test-et? - bekapcsolva kell hagynod, különben mindig rárajzolnál a már kirajzolt átlátszatlan objektumokra, még akkor is ha azok takarnák az átlátszó objektumodat

Idézet

---

Joga :
no igen, végülis megvizsgálni, hogy melyik test van közelebb szebb és jobb megoldást ad, mint a depth bufferes trükközés és még helyes is

---

De nem akar fölöslegesen lassítani a renderelést azzal, hogy mindig rendezem a modelleket rajzolás előtt.

Idézet

---

Joga :
de egyébként egy glDepthMask az egész

---

És akkor nyugodtan bekapcsolva hagyhatom a depth test-et?

no igen, végülis megvizsgálni, hogy melyik test van közelebb szebb és jobb megoldást ad, mint a depth bufferes trükközés és még helyes is

Idézet

---

Seeting :
Nekem a második megoldás jobban tetszik. Majd kipróbálom. Köszi!

---

Hát csak itt se teljesen pontos, mert ha magas az alpha értéke, akkor már eléggé feltűnő, hogy a távolabbi testet rárajzolod a közelebbire
de egyébként egy glDepthMask az egész

Nekem a második megoldás jobban tetszik. Majd kipróbálom. Köszi!

átlátszó testeknél csak olvasod a depth buffert, de nem írod - de akkor először az átlátszatlan testeket kell kirajzolni, és utána az átlátszóakat, így ahogy mondtad. De elvileg a profibb megoldás az első dolog, amit írtál.

vagy sorbarendezed távolság szerint csak az átlátszó háromszögeket, vagy pedig még lehet azzal kísérletezni, hogy átlátszó testeknél csak olvasod a depth buffert, de nem írod( ez többnyire akkor jó, ha alacsony az alpha érték )

Létezik valami megoldás alpha blending-re depth test-el?

Köszi!

Szerintem kizárt, mivel wgl... a cucc. A függvény glx ekvivalense a http://www.opengl.org/sdk/docs/man/xhtml/glXUseXFont.xml

Ez linuxra is van?

A legegyszerûbb és leggyorsabban megvalósítható a wglUseFontBitmaps ill. a wglUseFontOutlines. Mindkettõ display listek tömbjét hozza létre, amelyet a sztring karaktereivel, mint számokkal tudsz indexelni.

Mi a legegyszerûbb módja annak, hogy szöveget rajzolhassak ki a képernyõre?

Erre a fajta fényforrás pozícionálásra milyen hatással van az ha forgatom a transformációs mátrixot?



Ja megvan, minden frame-nél újra kell õket pozícionálni a Modelview mátrixhoz.

Mindenhol kerestem csak itt nem.

opengl.org

Tudtok olyan oldalt, ahol fel vannak sorolva a GLSL beépített függvényei?

glTexEnv() ?

Hogy lehetne elérni azt, hogy a modell materialja (színe) ne színezze át a textúrát is?

6 oldalú kocka GL_QUAD-okból, egy oldal 4 vertex egy vertex 3 poz (x,y,z):

6*4=24
24*3=72

Ha carlos könyvére gondolsz az pont meg is van, de az dx-szes. Azért a hardveres dolgokat majd átrágom, mivel az gondolom ugyanaz.

seeting :

Még új vagyok, de lehet hasznos a tanácsom. Elsõnek rágd át magad pár doksin, hogy is mûködik a videókártya, vagy az egész render pipeline, mert a kérdéseidbõl az jön le, hogy nagyon hiányzik neked pár alapvetõ koncepció.

Asszem van valami magyar csóka, aki írt játékfejlesztésrõl könyvet, ami kezdõknek jó, és elmagyarázza az alapokat. Azzal megpróbálkozhatnál (nem emlékszem pontosan a címére, valamilyen Károly írta), állítólag alapos (nekem is csak ajánlották).

A probléma valszeg az volt, hogy a depth test nem volt beállítva. Komplexebb geometriáknál a cull face meg nem oldja meg ugyanezt a problémát, és akkor megint fejvakargatás lesz.

A másik, az összes vertex mellett ott kell lennie az összes egyéb adatnak is (texcoord0-32). A 72 hogy jött ki neked? 6 Oldalú kocka, a legprimitívebb módszerrel is, oldalanként 2 tri, az 3 vertex strip nélkül. 6 * 3 * 2 = 36

Megoldva

glCullFace(GL_BACK);

Ilyen, most csak két oldalt definiáltam:


A képet a Képfeltöltés.hu tárolja. http://www.kepfeltoltes.hu

Vagy a backface culling, vagy a depth test, sok választás nincs

Rájöttem, hogy nem is átlátszó... Azt csinálja hogy a kocka elsõ lapja mögötti lapot (ami kocka hátoldala) az elsõ lap elé rajzolja.

Akkor bizony nem maradt más, nem lehetne egy kicsit hosszabb kódot kapni, vagy hogy mikhez nyúlsz hozzá?( textúra, bufferek, stb )

Nincs color arrayem. glMaterialfv-t használok. Az elsõ két ponthoz biztosan nem nyúltam. Poltergeist...

Nincs sok választási lehetõség:
1.: depth buffer/depth maskot megpiszkáltad
2.: A color arrayban piszkáltál valami, vagy a glColor4f-fel bûvészkedtél valamit, és elfelejtetted
3.: Stenciltesztel bûvészkedtél és az maradt benn
4.: Háromnap múlva belenézel a kódodra, és a fejedre csapsz, hogy "Hogyan nem vettem észre?!"

Értem. De szerintem nem ezért átlátszó mert a shotot kínomban ilyen állapotban csináltam:

glVertexPointer(3, GL_FLOAT, 0, ((*prModellsIt).second).Vertices);
glNormal3f(1.0f,0.0f,0.0f);
glDrawArrays(GL_QUADS,0,24);

Szóval elvileg minden vertexnek ugyanaz a normálvektora. Eszerint a kocka csak egy oldalán veri vissza a fényt teljesen, a többi sötét marad. De mitõl látszik át?

Nem, egy vertexhez tartozik egy normálvektor
( 72 vertexhez 72 normál )

egy face-hez pedig annyi normálvektor tartozik, ahány csúcsa van, triangle esetén 3, quad esetén 4, stb

mivel quadokat adsz meg, ezért egy face-hez 4 normál fog tartozni

Idézet

---

Joga :
azt, hogy a normálvektor array 18 elemû ugye úgy érted, hogy kockánként 18 elemû, ugye?

72 elemû vertex arrayhoz 72elemû normálvektor array tartozik

---

Azért gondoltam, hogy 18 elemû, mert a kockának 6 oldala van, 1 oldal 1 face és 1 face-hez 3 normálvektor pozíció tartozik.

6*3=18

Magyarázd már el kérlek, hogy miért 72 elemû normálvektor kell

Idézet

---

fpeti :
Lehet hülyeség, de nem backface-eket rajzolod? az is így néz ki.

---

glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, material);

és counter clockwise-ban rajzolok.

Lehet hülyeség, de nem backface-eket rajzolod? az is így néz ki.

azt, hogy a normálvektor array 18 elemû ugye úgy érted, hogy kockánként 18 elemû, ugye?

72 elemû vertex arrayhoz 72elemû normálvektor array tartozik

Mitõl lehet az, hogy az objektumaim átlátszanak?


A képet a Képfeltöltés.hu tárolja. http://www.kepfeltoltes.hu

A fényeket állítottam be rosszul? Vagy talán hibás a vertex array? Esetleg a Normalvector array?

Ha van egy 72 elemû vertex array-em, ami GL_QUAD-okat határoz meg, akkor a normálvektor array 18 elemû, igaz?

cplusplus.com rulez

Ez bejött, köszi!

Azt nem tudom, hogy ezek a fickók hogy nem jöttek rá:
http://stackoverflow.com/questions/535317/checking-value-exist-in-a-stdmap-c

mymap.count( index )
Ez visszaadja, hány darab index-szel jelölt elem van, ebben az esetben egy, ha van, nulla, ha nincs ilyen elem

Ebben meg lehet nézni valahogy, hogy létezik-e a keresett elem?

Én azt mondom az sdl::map jobb, ha index alapján tárolsz dolgokat

Ez a map így elsõ ránézésre pont úgy hangzik mint ami nekem kell. Lehetne a key az index, a mapped value meg a modell osztály példánya.

Akkor azt mondod, hogy dobjam az stl::vector-t?

Nem kellett volna boroznom tegnap.

Jó, de a program sorbarendezheti betöltéskor a modelleket, nem?

szerk.: vagy próbálkozhatsz std::map-pal az valszeg jól fogja bírni a strapát

De az index az tetszõleges, a szkripter adja meg. Egyfajta azonosítója a modellnek. Nem növekszik.

pl.

//file elérés, index
load modell "modell1.lwo",145
load modell "modell2.lwo",93

float szog=get modell angle x(93)

Most a vectorban a 93-as modell a második helyen van, de a lekérdezés nem ezt a helyet kéri hanem az indexet.

Asszem bináris keresésnek hívják:

Sorbarendezed a modelleket index szerint.
Van x modelled.
megnézed az x/2 dik modelled indexét, ha nagyobb, mint amit keresel balra, ha kisebb jobbra keresel, azt a részt is kettébontod, amíg meg nem találod

Hogy lehetne gazdaságosan tárolni a modell indexeket?

Úgy szeretném megírni a scenemanagert, hogy könnyen lehessen szkriptelni a scene-t. Azt akarom, hogy ha betöltök egy modellt, akkor a betöltõ eljárás bemenetében szerepeljen az adott modell indexe, amit a szkripter ad meg. Ez egy int.

Úgy tárolom a modelleket, hogy a modell osztálynak van egy id privátja, és egy vector-ba teszem magát a példányosított modellt.

Na most ez nem bizonyul gazdaságosnak: Ha például a játék loopjában le akarom kérdezni a modell pozícióját (a lekérdezõ fv. egy indexet kér be), akkor ahányszor meghívódik ez a fv, végig kell mennem a vektoron, hogy megnézzem hogy a benne lévõ modellek közül melyiknek azonos az indexe a bemenettel.

Egy játék loopban rengeteg lekérdezést kell végezni számos létezõ modellhez, ezért nem akarom hogy x milliószor végigmenjen ugyanazon a cikluson.

Úgy akarom megoldani, mint ahogy a darkBASIC-ben van. Vajon õk hogy csinálták?

Le tudom kérdezni GLSL-ben, hogy engedélyezve van-e a textúrázás, vagy a fények és ha az utóbbi igen, akkor azok közül melyikek?