játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5471
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2525

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2194
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] > 55 < [60] [65] [70] [75] [80] [82]
beast - Törzstag | 1241 hsz       Online status #66336   2007.08.09 08:39 GMT+1 óra  
Hehe, azért nem ilyen szar a helyzet.
"
+ In ARB_texture_non_power_of_two:
* mipmapping is allowed, default filter remains unchanged.
* all wrap modes are allowed, default wrap mode remains unchanged.
* borders are supported.
* paletted textures are not unsupported.
* texture coordinates are addressed parametrically [0..1],[0..1]
+ In EXT_texture_rectangle:
* mipmapping is not allowed, default filter is changed to LINEAR.
* only CLAMP* wrap modes are allowed, default is CLAMP_TO_EDGE.
* borders are not supported.
* paletted textures are unsupported.
* texture coordinates are addressed non-parametrically [0..w],[0..h].
"
Az ARB_texture_non_power_of_two már egy jobb megoldás npot textúrák kezelésére, nem csak 2d-s textúrákat kezel, hanem 1d, 3d sőt, még cube mapokat is. Hátránya, hogy modernebb graf.kártya kell alá, mint a EXT_texture_rectangle-höz.

   
Gergo - Tag | 67 hsz       Online status #66332   2007.08.09 08:30 GMT+1 óra  
Hát elég szívás, de post effektekhez muszály szerintem.

   
gaborlabor - Moderátor | 4449 hsz       Online status #66329   2007.08.09 08:22 GMT+1 óra  
Idézet
beast :
"However, non-power-of-two sized textures have limitations that
do not apply to power-of-two sized textures. NPOTS textures may
not use mipmap filtering; POTS textures support both mipmapped
and non-mipmapped filtering. NPOTS textures support only the
GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_CLAMP_TO_BORDER wrap modes;
POTS textures support GL_CLAMP_TO_EDGE, GL_REPEAT, GL_CLAMP,
GL_MIRRORED_REPEAT, and GL_CLAMP_TO_BORDER (and GL_MIRROR_CLAMP_ATI
and GL_MIRROR_CLAMP_TO_EDGE_ATI if ATI_texture_mirror_once is
supported) . NPOTS textures do not support an optional 1-texel
border; POTS textures do support an optional 1-texel border.

NPOTS textures are accessed by dimension-dependent (aka
non-normalized) texture coordinates. So instead of thinking of
the texture image lying in a [0..1]x[0..1] range, the NPOTS texture
image lies in a [0..w]x[0..h] range. "

Itt az okosság.


Nah, hát ezek után még úgyse fogok NPOT textúrákkal foglalkozni, azt hiszem. Kivéve ha nagyon muszáj lesz...

   
Gergo - Tag | 67 hsz       Online status #66325   2007.08.09 08:11 GMT+1 óra  
Ezeket mind betartottam, de ígyse jó

   
beast - Törzstag | 1241 hsz       Online status #66324   2007.08.09 08:10 GMT+1 óra  
"However, non-power-of-two sized textures have limitations that
do not apply to power-of-two sized textures. NPOTS textures may
not use mipmap filtering; POTS textures support both mipmapped
and non-mipmapped filtering. NPOTS textures support only the
GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_CLAMP_TO_BORDER wrap modes;
POTS textures support GL_CLAMP_TO_EDGE, GL_REPEAT, GL_CLAMP,
GL_MIRRORED_REPEAT, and GL_CLAMP_TO_BORDER (and GL_MIRROR_CLAMP_ATI
and GL_MIRROR_CLAMP_TO_EDGE_ATI if ATI_texture_mirror_once is
supported) . NPOTS textures do not support an optional 1-texel
border; POTS textures do support an optional 1-texel border.

NPOTS textures are accessed by dimension-dependent (aka
non-normalized) texture coordinates. So instead of thinking of
the texture image lying in a [0..1]x[0..1] range, the NPOTS texture
image lies in a [0..w]x[0..h] range. "

Itt az okosság.

   
beast - Törzstag | 1241 hsz       Online status #66322   2007.08.09 08:03 GMT+1 óra  
GL_TEXTURE_RECTANGLE_ARB nem kezeli a mipmap-et. Meg még pl. a repeat-et sem szereti.

Szerk.: remélem észrevetted, hogy rect-tex-nél nem 0..1 tartományban adod meg a texkoordinátákat, hanem 0..width, 0..height, ahol width/height az eredeti kép szélessége, ill. magassága.

   
Gergo - Tag | 67 hsz       Online status #66321   2007.08.09 08:00 GMT+1 óra  
Sziasztok!
Ismét elakadtam. A rectangle texturákat szeretném beüzemelni, de vmi furcsa hibát kapok. Ilyen eredményt ad:

A kép alapján olyan, mintha rosszul adtam volna meg a formátumot a glTexImage2D-nek, de ugyanígy hívom hagyományos textúrák esetében is, és ott nincs gond. Részeletek a kódból:
Betöltés:
glGenTextures(1,&id);
glBindTexture(target,id); //a target vagy GL_TEXTURE_2D, vagy //GL_TEXTURE_RECTANGLE_ARB

glTexParameteri(target,GL_TEXTURE_MAG_FILTER,magfilt);
glTexParameteri(target,GL_TEXTURE_MIN_FILTER,minfilt);
glTexParameteri(target,GL_TEXTURE_WRAP_S,GL_CLAMP);
glTexParameteri(target,GL_TEXTURE_WRAP_T,GL_CLAMP);
glTexImage2D(target,0,type,f_width,f_height,border,type,GL_UNSIGNED_BYTE,img->Pixel(0,0));
if (minfilt==GL_LINEAR_MIPMAP_LINEAR) glGenerateMipmapEXT(target);

A targetet a kép méretéből határozza meg. Ha kettőhatvány, akkor hagyományos, ha nem akkor rectangle texture.

Használat:

arc->Bind(); //arc a rectangle texture. A bind engedélyezi a rectangle textúrákat, és bindeli

glBegin(GL_QUADS);
glVertex2d(0,0); glTexCoord2f(0,0);
glVertex2d(800,0); glTexCoord2f(500,0);
glVertex2d(800,600); glTexCoord2f(500,500);
glVertex2d(0,600); glTexCoord2f(0,500);
glEnd();

arc->UnBind(); /letiltja a rectangle textúrákat

Kifogytam az ötletekből mi lehet a baja....

   
Gergo - Tag | 67 hsz       Online status #66099   2007.08.07 14:08 GMT+1 óra  
Jaja, köszi mkinek a segítséget! Ultra aktív ez az oldal érdemes ide irni

   
gaborlabor - Moderátor | 4449 hsz       Online status #66097   2007.08.07 14:04 GMT+1 óra  
Aha, akkor már én is értem, pompás!

   
Gergo - Tag | 67 hsz       Online status #66096   2007.08.07 14:01 GMT+1 óra  
Jaa értelek... De az a helyzet, hogy most jöttem rá, félreértettem az egész technikát. Szóval nem a képernyőre renderelek, hanem egy off-screen bufferbe, és az most beast jóvoltából kiderült, lehet akármekkora.

   
gaborlabor - Moderátor | 4449 hsz       Online status #66094   2007.08.07 13:57 GMT+1 óra  
hát valószínűleg még mindig én értettelek félre...
szóval én csak azt mondom, hogy mindegy hogy egy képet mikor nagyítasz fel, a végeredménye ugyanaz lesz. tehát ha a képernyőfelbontás mondjuk 1024*768 és abból készítesz egy 2* akkora textúrát akkor úgyis romlik a minősége, nem? akkor meg mit értél el vele?

   
Gergo - Tag | 67 hsz       Online status #66089   2007.08.07 13:43 GMT+1 óra  
Hmm Gaborlabor ezt most nem egészen értem...

   
Gergo - Tag | 67 hsz       Online status #66088   2007.08.07 13:41 GMT+1 óra  
Pontosan! És müködik!!!! Azt hittem korlátoz a frame buffer mérete, de úgyláccik nem

   
gaborlabor - Moderátor | 4449 hsz       Online status #66087   2007.08.07 13:37 GMT+1 óra  
De mi értelme van nagyobb textúrába renderelni, mint maga a képernyő?
Az oké, hogy utána nagyobb méretű textúrára lesz szükséged, de a minősége nem lesz jobb, nem?
Tehát ha textúrába renderelésnél készítesz nagyobb textúrát mint a képernyő, akkor ilyenkor romlik a minősége, mivel felnagyítja, ha meg kisebb méretű textúrát húzol rá egy poligonra, akkor meg olyankor lesz felnagyítva, olyankor romlik a minősége. A végeredmény nem ugyanaz?

   
Gergo - Tag | 67 hsz       Online status #66081   2007.08.07 13:28 GMT+1 óra  
Köszi kipróbálom ezt a rectangle texture-t!

   
beast - Törzstag | 1241 hsz       Online status #66080   2007.08.07 13:28 GMT+1 óra  
Ja, most értem, te a képernyő méretétől akarsz nagyobb textúrába renderelni? Úgy nem működik, hogy fbo-ba render előtt glViewport-tal pl. 1024*1024-be (vagy nagyobba) váltod a renderterület méretét, majd mikor már a screenquad-ra renderelnéd a végső textúrát, akkor visszaállitod a viewportot az ablak méretére? Nem emlitenek sehol kikötést a viewport méretét illetően...

   
Gergo - Tag | 67 hsz       Online status #66077   2007.08.07 13:23 GMT+1 óra  
Fbo-val egyből a textúrára

   
beast - Törzstag | 1241 hsz       Online status #66075   2007.08.07 13:22 GMT+1 óra  
Mivel másolod a framebuffert textúrába (glCopyTexImage2D, glCopyTexSubImage2D) vagy egyből textúrába rendereled (FBO, pbo)? Esetleg a GL_ARB_texture_rectangle-lel már nem köt a pot méret.
Itt egy leirás a textúrákról és a render to texture megoldásokről a végén.

   
Gergo - Tag | 67 hsz       Online status #66074   2007.08.07 13:22 GMT+1 óra  
Az nem lényeg mit renderelek, hanem hogy utána lementem textúrának...Csakhogy nagyobb felbontású textúrát szeretnék, mint a képernyő

   
gaborlabor - Moderátor | 4449 hsz       Online status #66073   2007.08.07 13:19 GMT+1 óra  
öö én nem egészen értem a problémát. mármint, hogy mit akarsz renderelni, hogyan merre meddig
mit is szeretnél pontosan?

   
Gergo - Tag | 67 hsz       Online status #66070   2007.08.07 13:12 GMT+1 óra  
Sziasztok! Újra belevágtam az engine irás véget nem érő küzdelmébe Most éppen procedurális textúrákon és utóeffekteken dolgozom, shaderekkel renderelek valamit a frame bufferbe, aztán lementem textúrának. Ezzel csak az a gond, hogy a kép felbontása korlátozza a textúra felbontását is. Szóval 512*512-es textúránál nem nagyon tudok nagyobbat renderelni...Ez mondjuk egy felhőzet textúrának már határeset, jó lenne nagyobb. Van valami ötletetek hogy tudnék nagyobb textúrát renderelni?

   
gaborlabor - Moderátor | 4449 hsz       Online status #65738   2007.08.03 12:03 GMT+1 óra  
OMFG!

ez..hihetetlen!!!

ezt érdemes megnézni mindenkinek:

Ez a kód:
Kód:
glBegin(GL_POINTS);
for( i = 0; i < 1024; i++ )
for( j = 0; j < 768; j++ )
if( screen[j][i] )
glVertex2i(i, j);
glEnd();
18-20 fps-t produkál!

Ez a kód:
Kód:
glBegin(GL_POINTS);
for( i = 0; i < 768; i++ )
for( j = 0; j < 1024; j++ )
if( screen[i][j] )
glVertex2i(j, i);
glEnd();
ez meg ~400-450-et!!!

Szóval különbség az van, pedig első ránézésre tök ugyanaz a kettő!
Ha jól sejtem ahhoz van köze, hogy C-ben sorfolytonosak a mátrixok, én meg pont hogy oszlopfolytonosan jártam be és ez látványosan belassította a cuccot.

Nem gyenge... Soha nem gondoltam volna, hogy ekkora különbség adódhat ilyen apróság miatt...

   
gaborlabor - Moderátor | 4449 hsz       Online status #65737   2007.08.03 11:48 GMT+1 óra  
eddig lokális statikus változó volt, azaz minden eleme 0 volt. most áthelyeztem a global scope-ba, így meg aztán végképp nulla minden eleme.
(vicces is lenne 1024*768 elemet kézzel feltölteni konstansokkal )
de ha bárhol nem nulla lenne, akkor meg úgy is észrevenném, mert ott kigyújtaná a pixeleket.

ezt tényleg nem értem, hogy miért fogja vissza az alkalmazást, ha egyszer sem hívódik meg.

   
Hacker - Törzstag | 567 hsz       Online status #65735   2007.08.03 11:36 GMT+1 óra  
Hmm be van valami kezdőérték állítva a tömbben lévő elemeknek? Mert nem minden esetben 0 a kezdőérték (ezért is javasolják, h minden változónak legyen valami kezdőértéke használat előtt).
No [img] !
Programozz ne háborúzz!!!!

   
gaborlabor - Moderátor | 4449 hsz       Online status #65734   2007.08.03 11:18 GMT+1 óra  
Azt értem én, hogy a rajzolás lassú, de elvileg csak lenne, mert a feltétel SOHA nem teljesül!

Mindegy, azért megpróbálom display listtel, utána meg vertex array-el, mert az én vga-m még nem támogatja a buffer objecteket.
(Ha jól tudom vertex array ogl1.3 óta van, az én kártyám pont olyan)

   
Hacker - Törzstag | 567 hsz       Online status #65729   2007.08.03 11:01 GMT+1 óra  
Az utóbbival még nem volt alkalmam nagyon foglalkozni így ebben nem is tudok segíteni, de a lassulás oka az lehet, h nagyon sokszor van meghívva a glVertex2i függvény. Ez az egyik leglassabb módja a kirajzolásnak, így mindenki azt javasolja, h más technikákat alkalmazzunk a kirajzolásnál (mint pl. a glVertexPointer használata vagy a Display List bevezetése).
No [img] !
Programozz ne háborúzz!!!!

   
gaborlabor - Moderátor | 4449 hsz       Online status #65721   2007.08.03 09:25 GMT+1 óra  
Hmm, sejtettem
DE ami még fontos lehet: szerintem nem a ciklus tesz be neki, mert kipróbáltam úgy, hogy üres operátort raktam a feltétel után. Tehát:
Kód:
glBegin(GL_POINTS);
for( i = 0; i < 1024; i++ )
for( j = 0; j < 768; j++ )
if( screen[j][i] ) ;
glEnd();


Az rendben van, hogy ez így használhatatlan, azonban a progi tartotta a 650-700 fps-t. Ez azért érdekes, mert ha üres operátor helyett a glVertex utasítás áll ott, akkor a progi belassul - még akkor is ha a tömb üres! Na, és ez az amit nem értek - hogy minek lassul be az egész, ha gyakorlatilag egyszer sem hívódik meg!

Ha jól értem, te azt javasolod, hogy egyenest a bufferbe rajzoljak, és minden renderciklusban mentsem le textúrába, majd ott vizsgáljam a texeleket? Az első részét még meg is tudom csinálni, igaz, hogy csak glCopyTexImage2D-vel, de az még talán nem lassítja le nagyon.
De hogy lehet közveltenül hozzáférni egy textúrához? Van valami módja, hogy olvasni, esetleg módosítani is lehessen a rendszerben tárolt textúrákat?
Kipróbálnám, hogy mennyivel gyorsabb ez a módszer, ha egyáltalán gyorsabb...

   
Hacker - Törzstag | 567 hsz       Online status #65720   2007.08.03 09:00 GMT+1 óra  
Igen nagyon durva . Viszont elfelejted azt, h 2*1024*768 -szor használod a léptetés operátort, ami megint eléggé leterhelheti a rendszert. Ha jól értettelek nálad az lenne a megoldás, ha lementenéd egy textúrába magát a képernyőt és ott számolgatnál.
No [img] !
Programozz ne háborúzz!!!!

   
gaborlabor - Moderátor | 4449 hsz       Online status #65710   2007.08.03 06:59 GMT+1 óra  
Ez nagyon durva?

Kód:
glBegin(GL_POINTS);
for( i = 0; i < 1024; i++ )
for( j = 0; j < 768; j++ )
if( screen[j][i] )
glVertex2i(i, j);
glEnd();

(screen egy static unsigned char [768][1024] tömb.)
jó, jó, tudom hogy favágó, de megmagyarázom!
Azért tárolom a képernyőt tömbként mert pixel-alapú ütközésdetektálásra lesz szükségem, AABB-kkel nem lenne megoldható. glReadPixels-szel meg azért nem jó mert az alatta lévő háttértextúra bekeverhet.

Az az érdekes, hogy a progi akkor is mindössze 20 fps-sel fut, ha a tömb minden eleme nulla, tehát nem rajzol ki semmit!
Az oké, hogy a glBegin-glEnd() függvénypáros használata ellenjavallott mert nem optimális, de nem hiszem, hogy ez okozná a drasztikus sebességcsökkenést (700fps -> 18-20 fps)

Lehetséges, hogy 1024*768 darab feltételvizsgálat lassítaná le így a programot?
A renderciklusban semmi nincs ezen kívül.

   
gaborlabor - Moderátor | 4449 hsz       Online status #64883   2007.07.30 06:32 GMT+1 óra  
Köszi szépen!
(Már megint túl akartam bonyolítani )

   
syam - Törzstag | 1491 hsz       Online status #64882   2007.07.30 06:29 GMT+1 óra  
csak egy sima glreadpixel utasítás
alias aalberik
   
gaborlabor - Moderátor | 4449 hsz       Online status #64881   2007.07.30 06:25 GMT+1 óra  
Üdv!

Mi a legjobb/legegyszerűbb módja annak, hogy megtudjam egy adott pixel színét?
Arra gondoltam, hogy bemásolhatnám a képnek azt a kis részét egy textúrába a glCopyTexSubImage2D függvénnyel, de akkor utána hogy lehet elérni a texelek színét?
Vagy meg lehet ezt oldani valahogy a glGetFloatv függvénnyel (a színpuffer elérését)?

   
gaborlabor - Moderátor | 4449 hsz       Online status #64593   2007.07.27 10:32 GMT+1 óra  
Nah, letöltöttem a NeHe féle (46. lecke) multisamplingos leckét.
Mivel nálam az sem csinál semmit a multisampling bekapcsolására, ezért őszintén remélem, hogy az én progim is csak a vga kártyám miatt nem müxik rendesen nálam.

Ezért szeretném, ha rápillantana valaki a kódomra, illetve a lefordított progira, hátha másnál működik rendesen, vagy hátha valaki megtalálja a hibát/hiányosságot a kódomban.
59-multisampling_teszt.rar

Előre is köszönöm annak, aki kipróbálja és közli az eredményt!

szerk.:
elfelejtettem: alapból KI van kapcsolva a multisampling, M betűvel lehet ki/bekapcsolgatni, a konzolablakra írja is az aktuális állapotát. A vonal forgási sebességét q-val lehet növelni, a-val csökkenteni.
(Remélem, egy ilyen egyszerű példaprogi elég ahhoz, hogy észrevehető legyen, ha működik az antialiasing.)

   
gaborlabor - Moderátor | 4449 hsz       Online status #64569   2007.07.27 05:25 GMT+1 óra  
Hello

Az OpenGL röviden c. könyvben -ha jól emlékszem- a 222. oldalon írnak pár sort a multisamplingról.
Elolvastam, és nagyon egyszerűnek tűnt az implementálása, meg is lepődtem!
Ott azt írják, hogy a multisampling eljárás az OpenGL-nek az 1.3 verziótól a része. Nekem OpenGL 1.3.valamennyi -s kártyám van, szóval elvileg mennie kéne.
A könyv szerint, GLUT használata esetén elég, ha a glutInitDisplayMode() függvény paramétereihez hozzáírjuk a GLUT_MULTISAMPLE konstanst, majd az ablak létehozása után a
glEnable(GL_MULTISAMPLE);
függvényhívással engedélyezzük a multisamplingot, és utána minden simítva jelenik meg.

Én a glext.h-t használtam a GL_MULTISAMPLE konstans eléréséhez, de mégsem működik.
Semmi hatást nem vettem észre.

Mitől lehet ez?

köszi

   
Joga - Törzstag | 1791 hsz       Online status #64557   2007.07.27 02:05 GMT+1 óra  
Köszi mindenkinek!
(ಠ ›ಠ) Stewie!

   
Winoxish - Törzstag | 121 hsz       Online status #64550   2007.07.27 01:09 GMT+1 óra  
erre jó az anisotropic filter:
http://en.wikipedia.org/wiki/Anisotropic_filtering
.:: Blaises Games ::.

   
syam - Törzstag | 1491 hsz       Online status #64518   2007.07.26 08:17 GMT+1 óra  
probáld ki a detail mappingot vagy pedig saját magad generáld le a mipmap szinteket
alias aalberik
   
Joga - Törzstag | 1791 hsz       Online status #64508   2007.07.26 06:37 GMT+1 óra  
De a közelebbi részén szépen, meg jól megjelenik a textúra, viszont távolabb túl kicsi cuccot használ
(ಠ ›ಠ) Stewie!

   
gaborlabor - Moderátor | 4449 hsz       Online status #64503   2007.07.26 06:23 GMT+1 óra  
Hát pont ez a lényege a mipmappingnak.
Szvsz nincs ott semmi gond. (Bár egy képet bedobhatnál).
A mipmapping lényege pont az, hogy a textúrát mikor betöltöd, akkor abból több, kisebb felbontású változatot is eltárol. Pl 16x16 kép esetén lesz belőle 16x16, 8x8, 4x4, 2x2 méretű textúra.
Minél távolabb van a kamerától a textúrázott primitív, annál kisebb felbontású változatot fog hozzá használni a rendszer. Így erőforrást spórolsz meg, plusz néha jobban is néz ki. Pl egy focipályán a távoli részeken ha nagy felbontású fű textúra van akkor mozgásnál "zizeg" a textúra és az elég csúnya.
Amúgy -ha jól tudom- GL_LINEAR_MIPMAP_LINEAR-nál még az egyes textúraváltozatok között is interpolál a rendszer, hogy ne legyen olyan nagy különbség a különböző felbontású változatok között.
Ha nem akarod, hogy annyira elmosódott legyen, szerintem próbáld ki nagyobb felbontású textúrával. Mert ugye ha alapból kicsi a textúra, akkor azt lekicsinyítve alap, hogy csúnya lesz.
Vagy próbáld ki mipmapping nélkül, de szerintem akkor meg még csúnyább lesz.

   
Joga - Törzstag | 1791 hsz       Online status #64497   2007.07.26 06:01 GMT+1 óra  
Lenne egy kis gond.....Átváltottam mipmapping-os textúrába(GL_LINEAR_MIPMAP_LINEAR), mert amikor messze van az objectum, akkor mindig sz*rul jelent meg(Meg különböző minták rajzolódtak ki) , viszont amikor nincs szemben a fal(pl tőlem balra), akkor a közeli részeknél szép és jó, viszont minél távolabb van, annál jobban elmosódik.......
(ಠ ›ಠ) Stewie!

   
balogh9 - Törzstag | 801 hsz       Online status #64110   2007.07.22 05:27 GMT+1 óra  
megoldódott a probléma

összesen ennyi maradt ki: Gl.glMatrixMode(Gl.GL_MODELVIEW);
ez ugyebár elég volt, h ne működjön a kérdéses dolog
_____________________
C++ && OGL
   
balogh9 - Törzstag | 801 hsz       Online status #64107   2007.07.22 04:37 GMT+1 óra  
nah mégse akaródzik működni.

szóval valaki tudja, hogy alakítom át a 2D-s koordinátát 3D-s koordinátává? a 2D-s koordinátám az egerem, ebből szeretnék 3D-st kapni.

rengeteg kódot átnéztem, utánaolvastam, de hibásan működik a dolog.

valaki csinált már ilyet, és ha igen tudna segíteni ?
_____________________
C++ && OGL
   
balogh9 - Törzstag | 801 hsz       Online status #64103   2007.07.22 04:20 GMT+1 óra  
nah úgy néz ki sikerül megoldani
_____________________
C++ && OGL
   
balogh9 - Törzstag | 801 hsz       Online status #64094   2007.07.22 03:17 GMT+1 óra  
olyan problémán lenne, hogy van nekem az egerem, meg annak a két koordinátája
ebből a kettő koordinátából, hogyan határozom meg, a 3D-s z koordinátát?
sokat próbálkoztam, de eddig semmi eredmény
van ugye a
Kód:
glReadPixels(mousePos.x,mousePos.y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&z);

fv, de itt a z mindig 1.0f lesz. lehet én nem értek vmit...
_____________________
C++ && OGL
   
Joga - Törzstag | 1791 hsz       Online status #63384   2007.07.15 08:39 GMT+1 óra  
Kösz!
Régóta érdekelnek a shaderek.....
Na meg nagyy modell formátumos leírásában is az volt, hogy vertex shaderrel érdemes megoldani a csontos modellek megjelenítését......
(ಠ ›ಠ) Stewie!

   
gaborlabor - Moderátor | 4449 hsz       Online status #63382   2007.07.15 08:35 GMT+1 óra  
ezt nem lecseszés képpen mondom, hanem segítségképp:
szóval ha valami hivatalos, részletes leírás kell, azaz reference manual vagy hasonló, akkor nem kell kétségbeesni, hanem szépen felmész az opengl.org-ra és ott van ilyen részleg, hogy Documantation.
Onnantól meg nem okozhat nehézséget megtalálni a keresett cuccot. De ha ez nem jön be, akkor ott van a legjobb barátod is.

Mivel ide írtál, feltételezem, hogy a GLSL-re gondolsz:
http://opengl.org/documentation/glsl/
(még a link is magáért beszél, pontosabban igazolja a fent leírtakat )
Ha csak általánosságban pár szó a shaderekről:
http://en.wikipedia.org/wiki/Shader_%28computer_science%29

Ennyire egyszerű!

   
Joga - Törzstag | 1791 hsz       Online status #63379   2007.07.15 08:05 GMT+1 óra  
Nem tud valaki a shaderekről egy részletes leírást?
(ಠ ›ಠ) Stewie!

   
Joga - Törzstag | 1791 hsz       Online status #63243   2007.07.14 03:39 GMT+1 óra  
Köszi!
(ಠ ›ಠ) Stewie!

   
gaborlabor - Moderátor | 4449 hsz       Online status #63242   2007.07.14 03:38 GMT+1 óra  
glMultMatrix();

   
Joga - Törzstag | 1791 hsz       Online status #63240   2007.07.14 03:31 GMT+1 óra  
Arra gondoltam, hogy ha gluLookAt után csinálom, akkor elvileg nem lesz transzformálva, szóvalolyan, mintha a kamerához lenne rögzítve, nem?

Egy másik:
Nem tudja valaki, hogy a glMatrixmode-dal kiválasztott mátrixot hogyan lehet beszorozni egy sajáttal? Lehetőleg a leggyorsabb módszer kell.....
(ಠ ›ಠ) Stewie!

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] > 55 < [60] [65] [70] [75] [80] [82]