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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2196
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]
TPG - Tag | 3402 hsz       Online status #66395   2007.08.09 13:28 GMT+1 óra  
Idézet
Gergo :
Az igaz. Ahogy látom külföldi fórumokon, ezzel nagy szenvedés van... Nem értek dx-hez, de ott úgy hiszem ez jóval egyszerübb.


DX alatt a Gef3-asomnál sem kellett ilyesmivel foglalkoznom.
Reality is almost always wrong. - House

   
Gergo - Tag | 67 hsz       Online status #66394   2007.08.09 13:20 GMT+1 óra  
Idézet
beast :
Miért, legtöbb pp effekthez kell blur, igy alapból megkapod.


Kössz!!
Viszont most futtattam egy opengl demot a gépemen amiben van hdr, tehát nekik sikerült vhogy megoldani, úgyhogy megnyugodtam LINK Iszonyatosan durva ez a demó...

   
beast - Törzstag | 1241 hsz       Online status #66393   2007.08.09 13:16 GMT+1 óra  
Miért, legtöbb pp effekthez kell blur, igy alapból megkapod.

   
Gergo - Tag | 67 hsz       Online status #66389   2007.08.09 12:17 GMT+1 óra  
Az igaz. Ahogy látom külföldi fórumokon, ezzel nagy szenvedés van... Nem értek dx-hez, de ott úgy hiszem ez jóval egyszerübb.

   
gaborlabor - Moderátor | 4449 hsz       Online status #66388   2007.08.09 12:09 GMT+1 óra  
Igen, ott már 2048*2048 kell. Nem tudom, ez mekkora pazarlásnak számít, de legalább működik minden videokártyán.

   
Gergo - Tag | 67 hsz       Online status #66386   2007.08.09 12:01 GMT+1 óra  
Ez is egy megoldás, igy nem torzul... csak nagyobb felbontásoknál van gáz, mert ott már 2048*2048 kell.

   
gaborlabor - Moderátor | 4449 hsz       Online status #66382   2007.08.09 11:56 GMT+1 óra  
Én még csak motion blur-t csináltam. Én úgy oldottam meg, hogy POT legyen, hogy egy 1024*1024-es textúrába mentettem le a front buffer tartalmát. (Mivel én 1024*768-t használok).
A következő kép renderelésekor ezt ráfeszítettem egy 1024*1024-es quad-ra és kész is.

   
Gergo - Tag | 67 hsz       Online status #66381   2007.08.09 11:53 GMT+1 óra  
Pont ezen gondolkozom...Én a post effekteket (pl bloom, motion blur, hdr) úgy képzeltem, hogy lerenderelem a világot egy textúrára (ami npot, pl 800*600), azon dolgozok valamit egy shaderrel, aztán kirajzolom egy quad-ra feszítve. De ha a világot 512*512-ben renderelem le pl, és azon csinálom meg a post effekteket, és aztán azt feszítem vissza 800*600-ra, az nem tűnik túl jó megoldásnak, torzulna a cucc. Biztos van erre valami normális megoldás... talán erre való a renderbuffer? Csak azt meg nem lehet textúraként használni...

   
gaborlabor - Moderátor | 4449 hsz       Online status #66374   2007.08.09 10:50 GMT+1 óra  
És akkor ezek szerint léteznek olyan feladatok amiket nem lehet megoldani POT textúrákkal?
Az oké, hogy NPOT-tal könnyebb/ideálisabb, de kompatibilitási szempontból azért még manapság sem előnyös NPOT textúrákat használni, nem?

   
Gergo - Tag | 67 hsz       Online status #66373   2007.08.09 10:35 GMT+1 óra  
Idézet
beast :
Idézet
Gergo :
LOL! A videókártyám nem támogatja az npot textúrákat Az GL_ARB_texture_rectangle-t elvileg meg igen...


Igen, irtam, hogy ez a helyzet vele.


Azt hittem modern a videókártyám

   
beast - Törzstag | 1241 hsz       Online status #66364   2007.08.09 10:07 GMT+1 óra  
Idézet
Gergo :
LOL! A videókártyám nem támogatja az npot textúrákat Az GL_ARB_texture_rectangle-t elvileg meg igen...


Igen, irtam, hogy ez a helyzet vele.

   
Gergo - Tag | 67 hsz       Online status #66362   2007.08.09 10:02 GMT+1 óra  
LOL! A videókártyám nem támogatja az npot textúrákat Az GL_ARB_texture_rectangle-t elvileg meg igen...

   
beast - Törzstag | 1241 hsz       Online status #66340   2007.08.09 08:48 GMT+1 óra  
Elvileg kompatibilis mindkettő.

   
Gergo - Tag | 67 hsz       Online status #66339   2007.08.09 08:46 GMT+1 óra  
Aha, köszi a felvilágosítást. Ha nagyon nemmegy akkor áttérek erre. És vajon a cg shaderekben a samplerRECT-el az is kompatibilis?

   
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 ::.

   
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]