|
|
|
|
Megvan!
glGet
NAME
glGetBooleanv, glGetDoublev, glGetFloatv, glGetIntegerv - return the value or values of a selected parameter
C SPECIFICATION
void glGetBooleanv( GLenum pname, GLboolean *params )
void glGetDoublev( GLenum pname, GLdouble *params )
void glGetFloatv( GLenum pname, GLfloat *params )
void glGetIntegerv( GLenum pname, GLint *params )
A pname értékeit nem sorolom fel, mert pont 195 van(a specifikáció és a word szerint  )
|
|
|
|
Idézet
syam :
az ogl mátrixai 16 eleműek ergo egy olyan pointert vár, ami 16 elemű lebegőpontos számból álló tömbre mutat; hogy a programnyelven hogy írod le édesmindegy ergo lehet float m[4][4], float m[16]; csak a tömb kezdőcímét kell átadni
Átadni így lehet, de lekérdezni hogyan lehet, hogy pl mi van a projection mátrixban?
|
|
|
|
az ogl mátrixai 16 eleműek ergo egy olyan pointert vár, ami 16 elemű lebegőpontos számból álló tömbre mutat; hogy a programnyelven hogy írod le édesmindegy ergo lehet float m[4][4], float m[16]; csak a tömb kezdőcímét kell átadni
alias aalberik
|
|
|
|
ehh... 
szóval...
deklarálsz egy 16 elemű vektort. aztán egyesével elemenként hivatkozol rá. kábé "ezt látom a képen".
az előbb 1ébként félreértettem, azt hittem az mind mind deklaráció.
így már logikus, csak az nem, hogy mit csinálsz azzal a 16 elemű vektorral.
na, arra akarok kilyukadni, hogy az OpenGL által kezelt 4x4-es mátrixból (azaz 16 elemű vektorból ) hogyan pakolod át az elemeket a te általad deklarált vektorba. szerintem Joga is erre gondolt eredetileg.
erre szerintem holnap visszatértek, mert most megyek aludni.
|
|
|
|
Bocs, az elejéről lemaradt vmi, szóval:
Kód: float m[16];
m[0] m[4] m[8] m[12]
m[1] m[5] m[9] m[13]
m[2] m[6] m[10] m[14]
m[3] m[7] m[11] m[15]
Remélem igy már logikus.
|
|
|
|
WTF? Ez nekem sok! Egyébként még csak pár oldalt tudtam elolvasni belőle 
De amit most írtál azt végképp nem értem. 
Minek csinálnék én 16 darab tömböt, különböző mérettel. Az m[0] meg végképp értelmetlennek tűnik.
Én abban a tudatban élek, hogy van néhány mátrix: transzformációs mátrix, modellnézeti, vetítési. (Meg persze van a mátrixverem). Ezek a mátrixok 4x4-esek, nem?
4x4 == 16. Szóval ha az OpenGL az értékeket 4x4-es mátrixban tárolja, és én azt át akarom tölteni egy általam deklarált mátrixba, akkor annak is 4x4-esnek kell lennie, nem? (Vagy 16 elemű vektornak).
Most akkor hogy is van ez? 
|
|
|
|
Te nem olvasod a könyvet?
Kód: m[0] m[4] m[8] m[12]
m[1] m[5] m[9] m[13]
m[2] m[6] m[10] m[14]
m[3] m[7] m[11] m[15]
Ha erre gondoltál.
|
|
|
|
gondolom így is jó: float m[4][4];
de szerintem Joga arra gondolt, hogy a mátrixok tartalma hogy kerül bele az általunk deklarált mátrixba. ezt én sem tudom.
|
|
|
|
|
|
Az OGL mátrixait, hogyan lehet berakni egy tömbbe?
|
|
|
|
Most, ismerkedek, de jól hangzik....
|
|
|
|
persze, érdemes mindenhol vektort használni, ahol csak lehet (pl szín beállításánál is).
de ha vertexekről van szó akkor még jobb teljesítményt nyújt a VBO (vertex buffer object). persze ha csak most ismerkedsz az OGL-lel akkor ráérsz még ezzel...
|
|
|
|
Köszi!
ok, akkor vektorosan csinálom...
|
|
|
|
Idézet
Joga :
Látom, a glVertexnek van olyan változata, hogy glVertex3fv(...);
Ha egy tömbben tárolom el a vertexeket, akkor kevesebb memória is elég, mintha a tömbből glVertex3f-fel raknám ki, mert így elvileg egy mutatót kell tárolnia, ami kisebb, mint 3db float, nem?
hát mit értesz az alatt, hogy kevesebb memória is elég? a 3 float változó akkor is 3*sizeof(float)-ot foglal ha vektorban van meg akkor is ha külön-külön. a különbség a sebességben van, mert egy pointert tényleg gyorsabban lehet átadni az opengl-nek mint 3 változót 
|
|
|
|
Látom, a glVertexnek van olyan változata, hogy glVertex3fv(...);
Ha egy tömbben tárolom el a vertexeket, akkor kevesebb memória is elég, mintha a tömbből glVertex3f-fel raknám ki, mert így elvileg egy mutatót kell tárolnia, ami kisebb, mint 3db float, nem?
|
|
|
|
ReshapeFuncban állítottam át pespektívbe, majd lerajzoltam, amit kell, aztán át Ortho-ba...Az elején még jó, volt, de nem vettem, figyelembe, hogy Idle-ben volt a glutPostRedisplay();....
Újra lerajzolta a perspektív részt(Vízszintes téglalap), de Orthoban
És már csak a függőleges téglalapot rajzolta ki....
Most vettem észre
|
|
|
|
hmm, némi forráskód mellékelődhetne....
alias aalberik
|
|
|
|
Ez ne,m jött be....A perspektív rajzot megjeleníti egy pillanatra, majd az ortografikus részt kirajzolja és az látszik
|
|
|
|
Joga:
vetítési módot váltasz:
1.
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
perspektiv vetítés();
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
kamera beállítás();
térbeli scene rendere();
2.
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
párhuzamos vetítés();
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
síkbeli scene rendere();
-
gluUnprojecttel tudsz lekérdezni, ha jol emlékszem( v lehet, h gluProject  )
alias aalberik
|
|
|
|
Hogyan lehet azt megcsinálni, hogy pl perspektíven rajzolok egy kockát, majd ortografikusban pl egy négyzettel letakarom, egy részét, stb...Szal röviden: Perspektív és ortografikus kép megjelenítése egyszerre....
Másik....Amikor Egy vertexet kirakok perspektíven a képernyőre, akkor hogyan lehet lekérdezni annak a 2d-s koordinátáit(leképzés után)?
|
|
|
|
Lehet, senki sem mondta, hogy eredetit alkotok a tutorialjaimmal... a szepseguk csak annyi, hogy magyarul vannak, meg az, hogy ha valami ohaj-sohaj van, csak dobsz egy mailt, en meg valaszolok
Mellesleg (sry a reklamert!) de fent van a tutorial DevC++hoz es Code::Blocks-hoz...
http://www.maniac.iceglow.com/
|
|
|
|
|
|
Néztem a glut specifikációjában a menükezelést, de nem nagyon értem....Nincs valakinek valami példaprogi hozzá, vagy egy leírás?
|
|
|
|
4500 huf.
|
|
|
|
Mibe kóstál 1 ilyen?
Mosolyogj! A holnap rosszabb lesz a mánál. Arthur Bloch
|
|
|
|
Pont amikor írtad a posztodat akkor vettem meg. Szegeden az Alexandrában még van belőlle pár darabb.
|
|
|
|
No [img] !
Programozz ne háborúzz!!!!
|
|
|
|
Megjött a könyvem, OpenGL Röviden. Még csak bele-bele kukkantottam, de szvsz a magyar nyomtatott anyagok közül a legjobb. Csak ajánlani tudom.
|
|
|
|
sikerült észhez térítenem a windowst!
hamarosan el is kezdek kísérletezgetni. mostanában elég sok anyagot szereztem az OpenGL-hez, meg a kedvem is megjött hozzá csak ilyenkor meg az a rossz hogy iszonyú idegesítő hogy nincs rá elég időm. most már jó lesz az a nyári szünet.
visszatérve a superbible-ra. van még ezen kívül pár könyv, amik alapműnek tekinthetők, nem?
ott van pl az OpenGL Programming Guide (red book), meg ott van a blue book, meg most már asszem van narancssárga könyv is. Mire ezt mindet kiolvassa az ember.. és akkor ez még csak OGL, programozás sehol pedig az sem árt fejleszteni.
|
|
|
|
Idézet
ShAdeVampirE :
Aham... Ez megfontolandó...
___________
A lelkesedés az, ami a tudásnak ízt ad...
|
|
|
|
|
|
"Meg ha nem is oglezel, biztos emlexel meg a dolgokra". Már csak azért is emléxem, mert most is ezeket használom, csak XNA alatt FBO-t RenderTarget-nek hívják, VertexArray-t VertexBuffer-nek. Egyedül azt kell megnézegetnem, h OGL alatt h kell használni. Vannak különbségek, de az elémelt ugyan az. Pont ezért nem érdemes 1ébként szidni 1iket másikat, mert majdnem az összes funkció megtalálható mind2 api-ban (DX / OGL), csak azt kell eldöntened, h melyik szintaxis tetszik jobban (nekem OGL-é, ezért kezdtem azzal, de XNA szintaxisa már megint más)
|
|
|
|
Persze, ilyen egyszerű. Mindíg csak azt kell jelezned, h épp hova akarsz renderelni. Ha épp nem FBO-ba, akkor megy alapból a BackBuffer-be.
|
|
|
|
Koszi a felvilagositast! Meg ha nem is oglezel, biztos emlexel meg a dolgokra. nekem xna kod kinai de az elmeletet megertettem a rovid irasod alapjan
Akkor a readpixels-es megoldast esetleg mentesnel fogom felhasznalni. Mar ertem hogy az FBO mire is jo szal csak annyiban kulonbozik az eljaras hogy nem a color bufferbe renderel hanem texturaba. Ez is jo lesz meg nekem, de a motion blur nem lesz olyan egyszeru mint kepzeltem. Azt olvastam h FBO-t olyankor hasznalnak pl ha egy szobaban van egy TV es azon megy vmi musor akkor annak a texturajaba renderelnek... otletes! Ha egy jatekban egy kameran keresztul latom a palya tobbi reszet akkor gondolom az is ilyesmi megoldast hasznal. Hogy mit akarok texturaba renderelni azt olyan egyszeru beallitani hogy gyakorlatilag csak a kamerat mozgatom el es a texturaba rendereles utan meg visszaallitom? (glPushMatrix - rendertotexture - glPopMatrix).
Remelem sikerul helyrehozni ezt a windozt aztan kiserletezhetek gyakorlatban is jeeez
Megegyszer koszi!
|
|
|
|
"Az Accumulation Bufferről azt írják, hogy ez is a színadatokat tárolja csakúgy mint a Color Buffer"
Hogy pontosak legyünk, ide át lehet még tölteni a már kész Color Buffer adatokat, a-buffer-ben változtatni rajtuk, majd vissza tölteni.
"Azt írja, alapértelmezés szerint duplán pufferelt ablak esetében a hátsó pufferből olvas azaz nem abból amelyikbe éppen rajzolok..." Pont h nem az első (Frame) bufferbe, hanem a hátsó (Back) buffer-be renderelsz, majd ha kész, megfordítod a 2-t, és akkor az addigi Frame lesz a Back, és onnantól kezdődik minden előről
glReadPixels() sokkal sokkal lassabb mint az FBO-s megoldás FBO-nak nagyon is van köze ehhez, mivel FBO-hoz hozzá tudsz kötni egy textúrát, és FBO tartalmát azzal lekérdezni. Olyan ez, mintha átállítanád a render célját; nem a normál Frame (Back) buffer-be renderelsz, hanem egy másik helyre. EZ XNA-ban pl. a RenderTarget (talán jobban fedi a neve h mire is jó). Ja és pont ezzel a sorral lehet hozzákötni: glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, my_fbo_tex_id, 0);
Már csak azért is gyorsabb, mert itt nincs semmi másolás, ami az 1ik leglassabb op. Itt egyből arra a területre renderelsz (FBO-val), így nem kell másolgatni az adatokat.
Motion blur: igen, sokan csinálják így, még ha nem is a-buffer -rel, de elvileg működnie kell. De ez sem a leggyorsabb megoldás, valamint nagyban függ a szépsége a tárgyak gyorsaságától / elmozdulásától (gép gyorsaságától). DX SDK-ban van egy nagyon jó 5let, aminek Pixel Motion Blur a neve, én most ezt használom a GP-mben (Nice Looking Pong: NE). Ezt igazából shader nélkül nem tudom hogy meg lehet e csinálni, de a lényege, h először kirajzolod az objektumokat a színükkel egy FBO-ba, majd következő lépésben minden pixelnek megnézed, hogy mennyit mozdult el (ezt úgy tudod megcsinálni, h lemented előző worl view projection mátrixot és összehasonlítod az aktuálissal) majd ezt egy ugyan akkora méretű Vector (v HalfVector) textúrába mented -> utolsó lépésben pedig cisnálsz egy gaussian blur-t ennek a mértékében. AZaz az első kép tárolja a kép színeit, a második lebegőpontos kép pedig azt, hogy merre kell elmosni és mennyire; minden egyes pixelre!
Lehet kicsit tömör lett, de sztem lényegét meg lehet érteni, ha pedig forrás is kell akkor DX SDK. Sry, mostanában már nem sokat OGL-ezek, de XNA-ban meg tudom mutatni a kódot
|
|
|
|
OpenGL superbible mindenképp kelleni fog, ez minden jobb OpenGL programozónak megvan, úőgy hallottam. Majd meglesz nekem is, de egyelőre el vagyok halmozva. Pontosabban be vagyok táblázva, mert úgy terveztem hogy nyárom C++t tanulok (de addig a K&R féle C könyvet midnenképp ki akarom végezni) + OpenGL, ahhoz van most ez az OpenGL röviden, plusz ebookban a Beginning OpenGL Game Programming. Az OpenGL superbible is megvan ebookban, de ha már leszek olyan szinten angolból is és OGL-ből is hogy megérje megvenni akkor meg is fogom. Egyelőre azon vagyok hogy minél többet olvassak, tanuljak.
|
|
|
|
Én is most olvastam utána! Az Accumulation Bufferről azt írják, hogy ez is a színadatokat tárolja csakúgy mint a Color Buffer. Számomra ez most talán nem is érdekes, mert most találtam meg a könyvemben, hogy a glReadPixels()-szel ki lehet olvasni a képkockatár egy adott részét. Itt azt írják, hogy legtöbbször ezt használják printscreen mentéséhez. Akkor ezek szerint nem lehet olyan lassú, nem?
Azt írja, alapértelmezés szerint duplán pufferelt ablak esetében a hátsó pufferből olvas azaz nem abból amelyikbe éppen rajzolok, de ezt lehet módosítani a glReadBuffer() függvénnyel.
Ha ez elég gyors, akkor nekem pont jó is lesz. Nemrég az jutott eszembe, hogyha meglennének a régebbi képkockáim, akkor 2D-ben tudnék csinálni motion blur-t vele. Tehát mikor ki van renderelve az egész kép akkor egy textúrát készítek a mondjuk 10 frame-mel ezelőtti képről, alfát 0.2-re állítom és ezt kifeszítem az egész képernyőre. És ezt persze mindig elvégzem így midnig ott lesz az x frame-mel ezelőtti kép. Az alfa értékkel illetve hogy mikori képet rajzolok ki azzal kísérletezni kell. Ezt még csak elméletben dolgoztam ki és fogalmam sincs, hogy működne-e. Lehet, hogy ahhoz hogy látható legyen nem elég egy képet elmenteni hanem mondjuk az utolsó tizet kirajzolni egymásra, úgy hogy a legrégebbinek a legkisebb az alfája. De akkor meg már 10 textúrát kell módosítani minden renderelésnél. Az lassú?
Ha megvannak a képpontadatok és abból készítek egy textúrát, az mennyivel lassabb, mintha textúrába renderelnék? Az FBO az Frame Buffer Object, nem? Annak mi köze a textúrákhoz?
Köszi a válaszokat, addig is utánaolvasok a textúrába renderelésnek!
|
|
|
|
Ja és ha komolyan érdekel a téma, és nem rettensz meg az angoltól, akkor mindenképp vedd meg az OpenGL Superbible-t, mert ebben tényleg minden benne van, amit csak tudni akarsz. Ha felvetődik egy OGL-es kérdés, akkor mindíg abban nézem meg először, és majdnem biztos h meg is találom benne a választ. Ez 1etlen baj vele, hogy ~15k HUF, én is karácsonyra kaptam a jézuskától
De ha valakit érdekel, akkor tudok egy honlapot, ahonnan be lehet szerezni (magyarországról), diák kedvezmény is van és lehet postai utánvétellel is rendelni (kb. 1-2 hét mire megjön).
|
|
|
|
Idézet
gaborlabor :
Azt meg lehet oldani valahogy, hogy még mielőtt a pufferek felcserélődnének, tehát mielőtt kirajzolná a képet, manuálisan módosítom a színpuffer tartalmát?
Persze, hogy meg lehet A legegyszerűbb és legkézenfekvőbb megoldás a Pixel Shader, de ha ragaszkodsz a Fixed Pipeline-hoz, akkor RenderToTexture (vagy r2t). Én ezt anno FBO-al oldottam meg, itt egy kódrészlet: http://rafb.net/p/8J09Mt33.html Ezzel az osztállyal nem túl nehéz, 1x kell egy init-et hívni, aztán pedig begin-end közé rakni azokat, amiket a textúrába akarok rakni. Ha gondolod elküldhetem a kódot, nem olyan átlátható, vannak a neten sokkal jobb tutorok is, csak keress rá h render to texture.
Mellesleg megemlítem, h ezt nem érdemes színek megváltoztatásához használni, mert az iszonyat lassú (berakni tex-be, ott babrálni a színekkel, aztán egész képernyőre vissza dobni), a leggyorsabb / jobb módszer a Pixel shader, de az Accumulation Buffer (A-Buffer) is valami ilyesmire való, bár ott nem tudod külön külön elérni a pixeleket (ha jól emléxem), de ezt nem igazán használtam, aztán meg már váltottam shader-re...
|
|
|
|
|
|
Miközben válaszokat kerestem az előző kérdésemre, találtam egy oldalt, ami hasznos lehet a kezdőkenk! Csak pár darab lecke van rajta, de elég jól magyaráz, képekkel, szóval érdemes ellolvasgatni:
http://jerome.jouvie.free.fr/OpenGl/Lessons.php
Persze az előző kérdésem továbbra is él!
|
|
|
|
Azt meg lehet oldani valahogy, hogy még mielőtt a pufferek felcserélődnének, tehát mielőtt kirajzolná a képet, manuálisan módosítom a színpuffer tartalmát? Tehát el szeretném érni a színpuffert, amiben már a végleges kép van, és írni/olvasni szeretnék bele/belőle. Tartalmaz az OpenGL ehhez szükséges függvényeket? Olyanokhoz kellene mint pl kimenteni az egészet egy mátrixba, és akkor azt már fájlba is írhatom printscreen gyanánt, vagy módosíthatom újbóli felhasználáshoz, tehát textúrát készítenék az előző képkockákból, vagy hasonlók. A lényeg, hogy ki tudjam másolni a tartalmát.
Megoldható?
|
|
|
|
joga:
Fejlác alatt mit értesz? Az ablak címsorát? Azt sehogy. Jobban jársz ha a GameMode-ot használod (fullscreen). pl.:
glutGameModeString("1024x768:32@75" ;
glutEnterGameMode();
shadevampire:
igen, olyasmi kéne nekem, pl apró lövésnyomok egy nagy falon. köszi a linket, átbogarászom! 
|
|
|
|
Glutban ablakos proginál el lehet tüntetni a fejlécet valahogy?
|
|
|
|
gaborlabor: ha koszt akarsz megjelenítni, akkor sztem a legjobb ha mondjuk mondjuk egy 256x256-os textúrán középen elhelyezed a koszt majd betöltéskor módosítod, h ne a közepén jelenjen meg (maga a kosz mondjuk 64x64 pix). Így megy a sima multitex és ha gondolod akkor véletlenszerű elhelyezkedést is tudsz vele csinálni.
Ha viszont mondjuk egy golyó által ütött lyukat akarsz textúrával utánozni (azaz megvan a textúrád ami ezt a lyukat jelképezni, csak nem tudod hogy hova is rejzold), vagy lábnyomot, stb. akkor ProjectiveTextureMapping. Ez olyan, mintha kivetítenéd a textúrát a falra. Erről itt: http://developer.nvidia.com/object/Projective_Texture_Mapping.html találod a legjobb infókat.
|
|
|
|
0.0000000000000000000001 z koordinátával előrébb teszem
|
|
|
|
Ha kikapcsolom a DEPTH_TEST-et akkor elvileg az utólag kitett téglalap fog látszani, amásik meg ott, ahol megelgedi neki az alpha komponens nem?
|
|
|
|
Joga ha így teszel, akkor elég fúrcsa dolgokat fogsz látni Na jó, lehet nem lesz olyan fúrcsa, de azt fogod látni, hogy néha az egyik tex tűnik fel, máskor a másik...
|
|
|
|
Úgy lehet, hogy kétszer rajzolom ki a téglalapot egyszer az egyik, egyszer a másik textúrával.....glDisable(GL_DEPTH_TEST);-tel?
|
|
|
|
Ha már multitextúrázás... bár még nem tartok ott de kérdeznék róla egyet.
Tehát olvastam hogy többek között arra jó hogy pl házfalakra vagy más felületekre koszt lehet vele renderelni úgy hogy élethű legyen. Namost.. lényegében amultitextúrázás az csak annyi, hogy egy poligonra kettő (vagy több) textúrát feszítek, nem?
De mi van akkor, ha én úgy akarom, hogy a második azaz a felső textúra ne fedje be az egész poligont hanem mondjuk csak a közepén legyen egy kis részen? Akkor hogy van ez? Multitextúrázásnál minden egyes textúrának külön meg lehet adni a vertexeket? Mert ha igen akkor kb ugyanott vagyok hogy 2 poligont renderelek 2 különböző textúrával + alpha blending és kész.
Akkor hogy is van ez?
Szerk.: OpenGL röviden-t én is elkezdtem olvasni.
|
|
|
Legutóbb frissített
project:
Maker4D
Friss kép a galériából:
|
