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]
syam - Törzstag | 1491 hsz       Online status #206987   2015.03.11 17:55 GMT+1 óra  
A shader compiler gyártónként változik vagyis egyik jobban optimalizál, mint a másik vagy egyáltalán nem.
Ha shadert generálsz akkor mindenképp érdemes saját kódoptimalizálót szerezni/írni, hogy ne bízd magad a véletlenre.
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #206986   2015.03.11 17:27 GMT+1 óra  
Nem, generálok node-okból, mint az UE4 Material editorja. Tudom, hogy vannak többféle konstruktorai, csak az a kérdéses, hogy ezek között (illetve aközött, hogy beírod a konstans értéket, vagy változóból olvassa ki) van-e sebességbeli különbség.

   
Asylum - Törzstag | 5484 hsz       Online status #206985   2015.03.11 17:14 GMT+1 óra  
Vektor konstruktor lehet egyelemű is:

Kód:
vec2 a = vec2(0.5);


Automatikus generálás alatt pedig mit értesz konkrétan? Fordítást egy másik nyelvről?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #206983   2015.03.11 16:04 GMT+1 óra  
Van valami performance drawback-je a változók használatának (GLSL version 110)?
Kód:
vec2 a = vec2(0.5, 0.5);

vs
Kód:
float a = 0.5;
vec2 b = vec2(a, a);

Nyilván ép ésszel nem írnék le olyat, mint a második, de most shader auto-generáláson dolgozok, és ha az ilyesmi nem lenne gond, az nagy könnyítés lenne.

Illetve ehhez hasonlóan az alábbi is felmerült:
Kód:
vec2 a = vec2(1.0, 2.0);
vec3 b = vec3(a, 3.0);

vs
Kód:
vec2 a = vec2(1.0, 2.0);
vec3 b = vec3(a.x, a.y, 3.0);

   
Asylum - Törzstag | 5484 hsz       Online status #206933   2015.03.06 18:34 GMT+1 óra  
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch40_deferred.html
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch52_compute.html

A png egy vicces állat, mert úgy tudom külön be lehet állítva neki gamma érték (de feltételezheted, hogy 2.2). Ha srgb textúrába töltöd be, akkor a textúra olvasás automatikusan degammázza (pow(x, 2.2)). A gamma korrekciót viszont én mindig egy külön shaderrel oldom meg (pow(color.rgb, 1.0 / 2.2)). Van srgb framebuffer is de az nekem mindig furán működik... Nézd meg a forward+ kódot.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #206920   2015.03.06 08:58 GMT+1 óra  
Most akkor hogy van ez a gamma korrektálás?

Van egy input png textúrám, ezt dekódolom RGBA-ba, ezt töltöm fel a GPU-ra (GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE)

Vannak FBO-k. Nevezetesen (deferred shading) egy GBufferem és Lighting bufferem, a következő textúrákkal:
GBuffer: GL_RGBA8, GL_RGBA8
Lighting: GL_RGBA16F

A geometriát renderelem a gbufferbe, az abban eltárolt adatokat használom fel a lighting buffer előállításához, majd azokat az információkat renderelem a back bufferbe (egyelőre, később az is egy FBO lesz, hogy lehessen ügyesen postprocesselni). A backbufferem gondolom RGBA8.

Most akkor mikor melyik irányba kell mit csinálni? Esetleg SRGB textúra? Próbáltam felfogni, hogy mi hogy van, de ahogy kipróbáltam, úgy elég furcsa eredményt kaptam.

   
Instalok - Tag | 607 hsz       Online status #206593   2015.02.12 06:17 GMT+1 óra  
A 100 szerintem jóval 60 fölött van. De ezek szerint ez természetes jelenség, jól van.

   
Asylum - Törzstag | 5484 hsz       Online status #206588   2015.02.11 21:22 GMT+1 óra  
Mert a játék nem 60 fps felett megy hanem valszeg jóval alatta
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 530 hsz       Online status #206587   2015.02.11 20:13 GMT+1 óra  
valszeg véletlenül pont annyi fps-ed van azokban a játékokban, hogy vsync nélkül sincs feltűnő tearing.
   
Instalok - Tag | 607 hsz       Online status #206585   2015.02.11 18:21 GMT+1 óra  
Most lettem csak arra figyelmes, hogy (csak és kizárólag) fullscreen módban, ha mozgok a kamerával, hullámzik a kép. A vsync nyilván megoldja a problémát, de hogy lehet az, hogy a játékoknál, amivel játszom, nem tapasztalom ezt a jelenséget? Az update-ek 60x hívódnak meg másodpercenként, a rajzolás viszont egyelőre nincs korlátozva.

   
Asylum - Törzstag | 5484 hsz       Online status #206568   2015.02.10 14:25 GMT+1 óra  
Nem, simát is lehet (image-ként).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #206567   2015.02.10 13:56 GMT+1 óra  
Ha jól tudom compute shadernek csak immutable texturet lehet bekötni.
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #206566   2015.02.10 09:16 GMT+1 óra  
Nem jól fogalmaztam. Nyilván nem úgy értettem, hogy 1-nek, hanem, hogy olyan hívásoknak. Viszont a glTexImage2D OGL 2.0 óta van, míg a másik úgy látom, hogy egy új dolog, OGL 4.2.

   
Asylum - Törzstag | 5484 hsz       Online status #206565   2015.02.10 09:03 GMT+1 óra  
Nem azt írja...azt írja, hogy ez az egy hívás megfelel egy glTexImage2D ciklusnak (azaz a storage egy menetben tölti fel az összes mip szintet). DE utána többször már nem módosítható a formátum.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #206562   2015.02.09 15:43 GMT+1 óra  
Annyit olvastam róla, h immutable, de nem tudtam, hogy emiatt gyorsabb is lehet. Köszi!

szerk.:
Mondjuk a doksi szerint a glTexStorage2D GL_TEXTURE_2D paraméterrel való hívása megfelel a
Kód:
glTexImage2D(target, i, internalformat, width, height, 0, format, type, NULL);

hívásnak.
Idézet
The behavior of glTexStorage2D depends on the target parameter. When target is GL_TEXTURE_2D, GL_PROXY_TEXTURE_2D, GL_TEXTURE_RECTANGLE, GL_PROXY_TEXTURE_RECTANGLE or GL_PROXY_TEXTURE_CUBE_MAP, calling glTexStorage2D is equivalent, assuming no errors are generated, to executing the following pseudo-code:

   
Asylum - Törzstag | 5484 hsz       Online status #206552   2015.02.09 14:03 GMT+1 óra  
A storage egy módosíthatatlan textúrát csinál (immutable), ez rajzoláskor optimálisabb, mert a driver nem végez rajta ellenőrzéseket.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #206548   2015.02.09 11:35 GMT+1 óra  
Van valami értelme glTexStorage2D-t használni glTexImage2D helyett? Mikor melyiket?

   
Levente - Tag | 24 hsz       Online status #206407   2015.01.26 21:08 GMT+1 óra  
Sikerült megoldani. x64 es glew volt a lib-be. És ezzel szenvedtem 3 napig.
De végre működik, köszi a segítséget.

   
Levente - Tag | 24 hsz       Online status #206405   2015.01.26 20:31 GMT+1 óra  
szerintem megtalálja, mert ha megcserélem és a freeglut-ot includolom először akkor a glew jelez, hogy a őt kéne először includolni

   
Instalok - Tag | 607 hsz       Online status #206402   2015.01.26 20:25 GMT+1 óra  
Pedig ez a fordítási linkelési hiba arról árulkodik, hogy valami linkelés nem jó. Esetleg rossz libet fordítasz hozzá, vagy meg sem találja?

   
Levente - Tag | 24 hsz       Online status #206399   2015.01.26 19:48 GMT+1 óra  
Igen arról az oldalról csináltam meg, a linkelések is megvannak, de még mindig ugyan az. A glew-l van valami mert a freeglut-ot, os rész futtatom csak az lefut rendesen létre is hozza az ablakot, de ha glew-os rész hozzá csapom akkor nem megy.

   
Instalok - Tag | 607 hsz       Online status #206396   2015.01.26 16:55 GMT+1 óra  
Nem kellene a libet belefordítani? Úgy tudom, hogy attól, hogy van egy dll-ed, attól még egy libbel össze kell fordítani. No persze ez egy kicsi lib ilyenkor, mert alapvetően csak függvénypointerek vannak benne.

Gondolj csak bele, a fordító nem tudhatja, hogy mik vannak a dll-ben, amíg meg nem mondod. Van ilyenkor egy statikus libed, ami megmondja, hogy milyen függvényeid vannak milyen szignatúrával, és ezt oldja fel dinamikusan (dll-ből)

Itt le is van írva, hogy hozzá kell fordítanod.
Idézet
Remember to link your project with glew32.lib, glu32.lib, and opengl32.lib

   
Geri - Törzstag | 2196 hsz       Online status #206393   2015.01.26 16:07 GMT+1 óra  
inkludáld be kézzel

   
Levente - Tag | 24 hsz       Online status #206392   2015.01.26 15:44 GMT+1 óra  
MSVC-t használok.
GLEW_STATIC csak annyit változtat hogy __imp__-et lehadja a hibaüzenetből.

   
Elodin - Tag | 184 hsz       Online status #206387   2015.01.26 11:19 GMT+1 óra  
Nekem is volt vmi. ilyesmi régen, asszem egy #define GLEW_STATIC megoldja a problémát, ha az include-ok elé rakod.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #206385   2015.01.26 10:16 GMT+1 óra  
Idézet
Asylum :
Ne szórakozz lib-el, a glew egy darab c fájl...

Már amennyiben be akarod fordítani a projectedbe a cuccot. Én pl. nem szeretem az ilyesmit.

Levente, milyen C++ fordítót használsz? MSVC? GCC?
Dare to imagine!
http://www.insaneidea.hu
   
Asylum - Törzstag | 5484 hsz       Online status #206375   2015.01.24 21:52 GMT+1 óra  
Ne szórakozz lib-el, a glew egy darab c fájl...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Levente - Tag | 24 hsz       Online status #206373   2015.01.24 16:05 GMT+1 óra  
Köszönöm a tippeket!

De lenne egy kérdésem a GLEW-t próbálom beállítani, de fordításnál állandóan elakad és ezt írja ki error LNK2019: unresolved external symbol __imp__glewInit@0 referenced in function _main és ennek társait. Beállítottam az include és lib mappát is, a DLL-t is megkapja, de csak nem akar jó lenni. Vagy a kódba lehet a hiba?

   
Asylum - Törzstag | 5484 hsz       Online status #206363   2015.01.23 14:07 GMT+1 óra  
Rövid időn belül ezek is elvaultak lesznek, ha kijön az opengl next. Nem az a lényeg, hogy melyik tutoriálból tanulod meg az opengl-t, hanem hogy melyikből szerzed meg a megfelelő szemléletet. Én pl. sokáig csak directx-el foglalkoztam, aztán egy állásinterjú kapcsán volt 1 hetem megtanulni az opengl-t is.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #206361   2015.01.23 09:21 GMT+1 óra  
Nehe cikkeivel az a gond, hogy már nagyon elavultak, ezért nem mertem linkelni őket. Pont, ahogy az enyémek is azok sajna

Akkor már inkább ez:

http://www.opengl-tutorial.org/

Btw tavaly írtam ezt egy barátomnak, aki akkor kezdte az OpenGL-t - szerintem ennek nagy része még mindig helytálló infó:

http://www.insaneidea.hu/?p=1357
Dare to imagine!
http://www.insaneidea.hu
   
Asylum - Törzstag | 5484 hsz       Online status #206345   2015.01.22 10:31 GMT+1 óra  
http://nehe.gamedev.net/

De nekem is van pár opengl cikkem, de azok kicsit advancedebbek.

http://darthasylum.blog.hu/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Levente - Tag | 24 hsz       Online status #206343   2015.01.21 23:31 GMT+1 óra  
Köszi. Pont ilyesmi tutorialt keresgéltem.

   
Elodin - Tag | 184 hsz       Online status #206342   2015.01.21 22:30 GMT+1 óra  
Én ezt a tutorialsorozatot találtam a legértelmesebbnek:
http://ogldev.atspace.co.uk/

Freeglut ablakkezeléshez és az operációs rendszerrel való egyéb kommunikációkhoz kell, mint input handling.

Könyv esetleg:
http://it-ebooks.info/book/2138/

A könyvnek csak az elejét olvastam. Elég korrektnek tűnt, kb. mindent részletesen ír le, de szerintem lehet érdemesebb először tutorialokat csinálgatni, hogy legyen egy gyakorlati szemléleted az egészről, és utána olvasni az elméletet - szerintem úgy több megy majd át.

   
Levente - Tag | 24 hsz       Online status #206341   2015.01.21 21:40 GMT+1 óra  
Sziasztok!

Kezdőként már másfél éve ismerkedek C++ nyelvvel és most elkezdtem nézegetni az OpenGL-t is, de nem találtam egybefüggő anyagokat, hogy mivel kezdjem. Gondolok itt arra, hogy valahol GLU - al valahol freeGlut- al ,stb. mutatják be és nem nagyon értem, hogy ezek külön függvénytárak és mind másra jó vagy hogy van ez? És melyikkel kellene kezdenem valami egyszerű megalkotására?

   
Geri - Törzstag | 2196 hsz       Online status #206262   2015.01.14 14:56 GMT+1 óra  
proof - ilyesmire hagyatkozni hiba. nem is biztos, hogy a textúrát letömöríti akkor, amikor feltöltöd. nem is biztos, hogy letömöríti.

jó ötlet a GL_COMPRESSED_RGB-t használni, mert ha van textúratömörítés támogatás, akkor az működni fog - de megkérdezni, hogy mit kompresszált össze belőle nem determinisztikus dolog, pusztán az érdekesség kedvéért lehet megnézni, de erre hagyatkozni hiba.

   
Asylum - Törzstag | 5484 hsz       Online status #206259   2015.01.14 09:25 GMT+1 óra  
Internal formatnak lehetőleg mindig explicit formátumot adj meg (GL_RGBA8, GL_COMPRESSED_RGBA_S3TC_DXT1_EXT, stb.). Nem szabad a driverre bízni SEMMIT.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 530 hsz       Online status #206257   2015.01.13 22:47 GMT+1 óra  
ATi megint alkotott az OGL driverben.
Ha eddig GL_COMPRESSED_RGB-t vagy GL_COMPRESSED_RGBA-t adtam meg internal formatnak a glTexture2D()-nél, akkor elvártam hogy a driver válasszon egy módot magától és tömörítsen annak megfelelően. Utána lekérdeztem a választott módot a glGetTexLevelParameter(GL_TEXTURE_INTERNAL_FORMAT)-tal. Eddig minden gépen király volt.
Most viszont a legfrissebb driverrel már meghalt a tesztem, ugyanis mit kaptam vissza választott módként? Hát GL_COMPRESSED_RGB-re GL_COMPRESSED_RGB-t, GL_COMPRESSED_RGBA-ra meg GL_COMPRESSED_RGBA-t.

Márpedig ilyen esetben neki kell választania, mert:
If the internalFormat parameter is one of the generic compressed formats, GL_COMPRESSED_RED, GL_COMPRESSED_RG, GL_COMPRESSED_RGB, or GL_COMPRESSED_RGBA, the GL will replace the internal format with the symbolic constant for a specific internal format and compress the texture before storage.
Valszeg választott is, csak mondjuk szeretném tudni hogy mit is választott. Na nem mintha annyira érdekelne, de azért elmondhatná.
   
Hamu - Tag | 19 hsz       Online status #204878   2014.09.24 20:04 GMT+1 óra  
Köszi a tippeket!

   
Asylum - Törzstag | 5484 hsz       Online status #204873   2014.09.24 13:29 GMT+1 óra  
polygonoffsettel nem érdemes hülyéskedni, mert az eredmény rosszabb lehet mint eredetileg...a kockákat helyezd el úgy, hogy legyen köztük 0.5-1 mm távolság, a near/far-t pedig optimalizáld ki ahogy syam mondta.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #204866   2014.09.24 00:36 GMT+1 óra  
Ha nagy a tér, akkor több részre szokták osztani depth alapján a részek között pedig hívnak depth cleart és így értelmes tartományban lehet tartani a near-far tartományt.
alias aalberik
   
Hamu - Tag | 19 hsz       Online status #204865   2014.09.24 00:27 GMT+1 óra  
Syam

Köszi a tippet.
A problémát az okozza, hogy gyakran nagy teret lehet (muszáj) belátni.
Ráadásul az elemek dinamikusak is (több állapotuk lehet és LOD is lesz).

Ezt a hozzászólást Hamu módosította (2014.09.24 00:32 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #204864   2014.09.23 22:56 GMT+1 óra  
Ötletek:
polygon offset használata, kamera near-far optimalizálása
alias aalberik
   
Hamu - Tag | 19 hsz       Online status #204863   2014.09.23 22:50 GMT+1 óra  
3D programozóktól kérdezném:

Szeretnék moduláris elemekből építkezni, ahol minden modul fix "cube" helyet tölt ki (a "kiszorításuk" voxeles, amúgy 3D modellek), de például egy random méretezhető ablaknál vannak a sarok elemek és az élek. Ezek találkozásnál, hogy lehet elkerülni, hogy ne legyen látható semilyen zizgő él, pláne, hogy a találkozó elemek "közös" átfedő vertexei ugyanabban a koordinátában vannak. Van erre valami módszer vagy ez is olyan 20 éves probléma, mint az alpha shortolás?

   
Asylum - Törzstag | 5484 hsz       Online status #204850   2014.09.22 15:03 GMT+1 óra  
Idézet

példásul a specular kiszámolását minden pixelre



Mert shadinggel azt hogy uszod meg, kiveve ha nem szamolod ki?

Idézet

subsurface scattering



Nagyon realis cel...de a Crytek is megoldotta. Sot, pont azert nem hasznalnak forward+ t mert az egy csomo hasonlo dolgot nem tud (pl. area light).

http://www.crytek.com/download/2014_03_25_CRYENGINE_GDC_Schultz.pdf
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #204847   2014.09.22 10:42 GMT+1 óra  
Ha jól értem, az csak annyi, hogy a GBuffer normal + shininess + depth értékeket ad. Ezután jön a lighting pass, ahol kiszámoljuk a szokásos értékeket (normal dot light vec, stb.), és ezeket tároljuk el a textúrában. Majd egy újabb geometry pass, ahol a mesheket a material tulajdonságaikkal rendereljük, felhasználva a lighting passban kapott textúrákat.

A problémám ezzel a következő: egyrészt nem spórol meg bizonyos dolgokat - példásul a specular kiszámolását minden pixelre -, illetve mi van akkor, ha nem elég a lighting passból kapott információ? Nem tudom pontosan, hogy mi kell hozzá, de pl. subsurface scattering?

Lehet, hogy jobban megérné egy komplexebb forward shadinget megcsinálni.

szerk.:
Korábban említettem a SM 2.0 targetet. Most nézem, hogy már a 3.0 sem egy nagyon vészes dolog.
Nvidia:
SM 2.0: Geforce 6-ostól
SM 3.0: Geforce 8-astól

AMD/ATI:
SM 2.0: Radeon R300-tól
SM 3.0: Radeon R600-tól

Ezt a hozzászólást Instalok módosította (2014.09.22 11:08 GMT+1 óra, ---)

   
Asylum - Törzstag | 5484 hsz       Online status #204846   2014.09.22 09:19 GMT+1 óra  
Úgy, hogy deferred lightingot használsz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #204845   2014.09.22 07:42 GMT+1 óra  
Úgy hiszem, hogy kelleni fog, ott vannak például a falevelek. Nem lenne jó, ha a levél egy egyébként nem látszódó része miatt eldobná a mögötte lévő pixeleket a depth test. Akkor marad a discard. Köszi!

szerk.:
Apropó, deferred shadingnél hogy érdemes a material ID-t megvalósítani? Gondolkoztam valami olyasmin is, hogy GBuffer passban fel kellene töltenem egy stencil buffert is - feltéve, ha tudok MRT mellett -, a shadingnek megfelelően, majd a megvilágítás kiszámolásakor annyi lépés, ahány ilyen group van. A stencil testet beállítom, hogy csak az adott értékű pixelekkel foglalkozzon, majd arra számolja ki a megvilágítást.

Ezt a hozzászólást Instalok módosította (2014.09.22 08:15 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #204843   2014.09.21 22:33 GMT+1 óra  
A discard arra kell, hogy ne írj a depth bufferbe és ezt máshogy nem tudod megtenni.
Ki kell derítened, hogy szükséged van-e arra, h ne írj a depthbe vagy elég ha csak a colorba nem írsz.
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #204842   2014.09.21 20:23 GMT+1 óra  
Nekem is olyasmi a cél. Újra deferred shadingnél kötök ki, és igazából a gbuffernél akarok spórolni, hogy ne legyen kötelező se normal mapet, se specular mapet megadni, stb. Viszont a nagy része ugyan az, így nekem is über-shader-szerű dolog lesz.

Discard helyett mit lehet, illetve érdemes használni?

   
syam - Törzstag | 1491 hsz       Online status #204841   2014.09.21 20:13 GMT+1 óra  
A discard viszonylag drága (mobilon különösen) pláne ha bonyolult feltételhez kötött. Mindenképp külön shader kell neki.
Azt nem fogod megúszni, hogy amennyi variáció annyiféle shadered lesz. Egyedül a forráskódot érdemes kontrollálható szintre hozni. Én pl define-olok orrvérzésig és kvázi übershadereket írok. De ez ízlés dolga.
alias aalberik
   
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]