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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
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]
Geri - Törzstag | 2198 hsz       Online status #209592   2016.05.13 20:11 GMT+1 óra  
framebuffer/fbo létrehozásakor el tudod dönteni, hogy lesz -e stencil buffered, vagy sem. onnantól minden beállítgatás irreleváns.

   
Instalok - Tag | 619 hsz       Online status #209591   2016.05.13 19:18 GMT+1 óra  
A stencil írásának kikapcsolásához amúgy elég a glStencilMask(0)? Vagy érdemes átállítani mindet KEEP-re? A stencil mask ugye csak azt mondja meg, hogy mely biteket írja (tehát effektíve a 0-val nem fog írni semmit), viszont lehet, h megpróbál. Ha meg KEEP-re állítom mindet, akkor meg sem próbál írni, nem?

Továbbá van-e jelentősége annak, hogy a state állításokat az FBO bind előtt vagy után teszem meg? Gondolom nem nagyon, mert ezek a state-ek (depth test, stencil test, stb.) globálisak.

   
Instalok - Tag | 619 hsz       Online status #209588   2016.05.13 07:40 GMT+1 óra  
Mondjuk furcsa, mert a dokumentáció szerint lehet a depthBits értéke 0. Sőt, ha lekérem az összes elérhető pixel formatot, akkor azok között van olyan, ahol 0. De mindegy végülis, így hagyom, csak soha nem használom.

Megpróbálom majd megszerezni a laptopot, ha megvan a hiba forrása, leírom.

   
Geri - Törzstag | 2198 hsz       Online status #209586   2016.05.13 00:21 GMT+1 óra  
,,Ezek szerint kötelező a contexthez depth és stencil buffert társítani?''

depthet valszeg kell, stencilt meg minek

   
Instalok - Tag | 619 hsz       Online status #209585   2016.05.12 23:35 GMT+1 óra  
Sikerült szűkítenem a problémán, pontosabban valahogy előhoztam nálam is. Vagyis csak félig. Szóval a lényeg, hogy nálam is megjelent egy error.

Az egész rendering jelenleg úgy néz ki, hogy
Kód:
* bind FBO#1 (color 0, 1, 2, depthstencil attachmentek)
* draw geometries
* bind FBO#2 (color 0 attachment csak)
* draw fullscreen quad
* bind backbuffer
* draw fullscreen quad

Na most nálam elkezdte azt csinálni, hogy az utolsó lépésnél a glDrawElements elkezdett GL_INVALID_OPERATION hibát dobni. Persze ettől függetlenül nálam még jó volt a renderelés, szóval gondolom a driverem lenyelte a békát.

No igen, kerestem egy ideig a hibát, és azt vettem észre, hogy amikor létrehoztam a contextet, nem adtam meg, hogy hány bites legyen a depth és a stencil buffer. Úgy gondoltam, hogy, ha nem akarom, hogy a contexthez tartozzon depth+stencil, akkor maradhat 0 biten. Amint kijavítottam 24+8-ra, eltűnt a hiba.

Ezek szerint kötelező a contexthez depth és stencil buffert társítani?

szerk.:
Bár a korábbi tesztekből az látszott, hogy az 1. "draw fullscreen quad" passnál dobta nála a hibákat, de sose lehet tudni, lehet, hogy innen gyökerezik a probléma. Megpróbálom majd rávenni, hogy jöjjön át, megosztom a build dirt hálózaton, és akkor tudok szinte realtime tesztelni.

   
Instalok - Tag | 619 hsz       Online status #209584   2016.05.12 20:34 GMT+1 óra  
Küldtem neki egy pár változatot:
1) maradt minden, csak kiszedtem az fbo-n belüli rajzolás
2) az előző megspékelve egy kis stencil állítással (dpass esetén is keep)
3) az előzőek megspékelve azzal, hogy egyáltalán nem csatoltam hozzá depth+stencil attachmentet
4) az egész visszacsinálva az eredetire, csak 16f helyett rgba8 használata
5) vissza rgba16f-re, semmi rajzolás és extra az fbo-n belül
6) az előző annyival megtoldva, hogy előtte nem rajzolok semmit (GBuffer <- deferred shading)

Csak és kizárólag a 6)-os esetben látta a (várt) kék képernyőt, az összes többi esetben fekete volt. Azt nem tudom, hogy ennek ellenére tolja-e a hibákat, mert GLInterceptet most nem adtam mellé.

Viszont furcsa mód úgy rémlik, hogy amikor a legelső binárist küldtem neki, és a GLIntercept is ott volt, ami kimentette a textúrákat is, akkor úgy tűnt, hogy a GBuffer generálásnál nincs hiba, mert abban az FBO-ban lévő textúrák jól néztek ki.

Már csak azt nem értem, hogy mi befolyásolhatja a 2. FBO-t annyira, hogy még a clear sem sikerül, amint rajzolok a GBuffer-be (3 textúra + depth + stencil), amit aztán nem használok fel, mert csak egy glClear()-t hívok az új FBO-ra.

   
Instalok - Tag | 619 hsz       Online status #209583   2016.05.12 20:12 GMT+1 óra  
GeForce GT 520MX van neki, ami már OGL 4.5-öt is tud. Nem hiszem, hogy nem támogatná a floating point textúrákat.

   
Geri - Törzstag | 2198 hsz       Online status #209582   2016.05.12 18:13 GMT+1 óra  
ha jól értem, azt mondja, hogy máshol megy. más furcsaságot pedig nem látok, ez inkompatibilitásra utal

   
Asylum - Törzstag | 5511 hsz       Online status #209578   2016.05.12 09:11 GMT+1 óra  
Idézet
Geri :
szerintem a 16F? ne viccelj, ez nem standard adattípus, meg kell nézni extensionnal, hogy támogatva van -e, de a legjobb, ha nem is használod.



Ha az lenne a gond, akkor invalid enum-al szállna el.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2198 hsz       Online status #209577   2016.05.11 22:13 GMT+1 óra  
elmélet vs valóság

   
Instalok - Tag | 619 hsz       Online status #209576   2016.05.11 21:30 GMT+1 óra  
@Asylum:
Köszi, küldök majd

@Geri:
Eszerint az RGBA16F is required format, de azért mindenképpen megnézem majd, hogy támogatja-e a kártya.

   
Geri - Törzstag | 2198 hsz       Online status #209575   2016.05.11 16:21 GMT+1 óra  
szerintem a 16F? ne viccelj, ez nem standard adattípus, meg kell nézni extensionnal, hogy támogatva van -e, de a legjobb, ha nem is használod.

   
Asylum - Törzstag | 5511 hsz       Online status #209574   2016.05.11 15:53 GMT+1 óra  
Na akkor adj nekem egy exet es megnezem a gtx 650-en, hatha itt is elszall.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209573   2016.05.11 13:50 GMT+1 óra  
Hm, elfelejtettem jól felconfigolni a GLInterceptet, de azért átküldtem neki, végeredményben pedig lett 2-3 helyen is error. Mivel nála ???-ek vannak (rossz config), így a sajátommal vetettem össze:
Kód:
glBindFramebuffer( ??? )
glViewport( ??? )
glDisable( ??? )
glDepthMask( ??? )
glStencilMask( ??? )
glClearColor( ??? )
glClear( ??? ) glGetError() = 0x0506

amely valójában:
Kód:
glBindFramebuffer(GL_FRAMEBUFFER,2)
glViewport(0,0,1280,720)
glDisable(GL_DEPTH_TEST)
glDepthMask(false)
glStencilMask(0)
glClearColor(0.392157,0.576471,0.968628,1.000000)
glClear(GL_COLOR_BUFFER_BIT)

A hibakódra rákeresve:
Kód:
#define GL_INVALID_FRAMEBUFFER_OPERATION  0x0506

Ugyan ezt a hibát dobja később egy drawElements is
Kód:
glDrawElements( ??? ) GLSL=6  Textures[ (0,3) (1,4) (2,5) ]  glGetError() = 0x0506

Furcsa egyébként, hogy nálam gond nélkül működik. Az FBO maga egyébként egy RGBA16F texture attachmenttel rendelkezik. Másik FBO-ba rajzolás működik.

Az opengl.org szerint
Idézet
GL_INVALID_FRAMEBUFFER_OPERATION, 0x0506
Given when doing anything that would attempt to read from or write/render to a framebuffer that is not complete.

Ami viszont csak azért furcsa, mert én ellenőrzöm:
Kód:
bool result = (glCheckFramebufferStatus(GL_FRAMEBUFFER) == GL_FRAMEBUFFER_COMPLETE)

és ha ez hamis, akkor a progi el sem indul.

   
Asylum - Törzstag | 5511 hsz       Online status #209572   2016.05.11 12:47 GMT+1 óra  
Nem dob hibát, ezt sajnos ki kell debugolni. Pl. D24S8-at adtál meg és nincs stencil attachment. Bármi megtörténhet. Core profile-ban van debug output, az kiiírja ha fasságot csinálsz (nvidián... ati-n még nem láttam működni).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209570   2016.05.10 15:15 GMT+1 óra  
Mi a francot csinálhattam, ha egy laptopon (nvidia káryta) fekete minden? Shaderek lefordulnak, FBO-k létrejöttek (ellenőrizve is van). Sajnos egyelőre nincs hozzáférésem a lapihoz, de nem is feltétlen tudom, hogy hol induljak így el.

Első tippre az FBO lehet a ludas, esetleg olyan textúraformátum, amit nem jól kezel (pl. D24S8 textúraként a DS attachmenten). De akkor erről azért dobna hibát, nem?

   
Instalok - Tag | 619 hsz       Online status #209566   2016.05.10 10:21 GMT+1 óra  
Igen, egyébként gondolkoztam rajta, hogy az OGL 2.0 és a DX9 kicsit elavult már, de egyelőre jó ez. Majd ha már nagyon hiányzik egy feature, akkor feljebb tolom a minimum szintet, aztán írhatom át a felét.

   
Asylum - Törzstag | 5511 hsz       Online status #209564   2016.05.10 09:53 GMT+1 óra  
Jé tényleg...de ha nem akarod szopatni magad, akkor OpenGL core profile (3.2) és DX11-re gyúrj.

(én a saját enginemet át fogom írni DX12/Vulkan/Metal-ra, de mondaom sem kell, hogy ez mekkora fejlesztés)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209563   2016.05.09 21:46 GMT+1 óra  
DX9-ben nem lehet shaderből olvasni a depth-et, csak ha külön kirendereled egy color bufferbe.

   
Asylum - Törzstag | 5511 hsz       Online status #209562   2016.05.09 13:49 GMT+1 óra  
Miért ne lenne kompatibilis?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209560   2016.05.08 18:02 GMT+1 óra  
Igen, mindezt nagyon jól tudom, a kérdés nem is erre vonatkozott. De azóta már úgy döntöttem, hogy a depth attachmenten használok textúrát, csak így dx9-el nem 1:1 kompatibilis. De nem baj, az úgy sincs implementálva.

   
Asylum - Törzstag | 5511 hsz       Online status #209559   2016.05.08 17:03 GMT+1 óra  
A depth-et utólag is lehet linearizálni (max nem olyan pontos), szóval nem értem a problémát...
De nemlineáris depthből is visszakapható a world space pozíció:

Kód:
vec4 WorldPosition(vec2 tex, float depth)
{
    vec4 spos = vec4(tex.x * 2 - 1, tex.y * 2 - 1, depth * 2 -1, 1);
    spos = matViewProjInv * spos;

    return spos / spos.w;
}

Ezt a hozzászólást Asylum módosította (2016.05.08 17:17 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209553   2016.05.06 14:43 GMT+1 óra  
1)-es:
glGenRenderbuffers
glBindRenderbuffer
glRenderbufferStorage
glFramebufferRenderbuffer

Ebben az esetben a depth így nem érhető el, csak, ha egy külön textúrába renderelek lineáris depth-et (GL_COLOR_ATTACHMENTX). Ez esetben használható az 1.2-ben leírt módszer.

2)-es:
Nyilván külön textúra, és a textúra van a GL_DEPTH_ATTACHMENT pontra kapcsolva. Ekkor viszont nem használható az 1.2-ben leírt módszer, mert ez a textúra == a depthbuffer tartalma, amit nem akarok módosítani (z-cull)

   
Asylum - Törzstag | 5511 hsz       Online status #209551   2016.05.06 12:34 GMT+1 óra  
Az 1-et nem is értem (hh renderbuffer...?).
A 2-nél meg nem írtad le a célplatformot...desktopon a default depth buffert nem tudod elérni, szóval evidens, hogy külön textúra kell.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209549   2016.05.06 09:46 GMT+1 óra  
Ha a depth buffer tartalmát később fel szeretném használni (deferred shading), akkor melyik az olcsóbb módszer?

1) csinálok egy render texture-t, az lesz az n+1 target, és a shaderben ebbe kiírom a linear depth-et
1.1) a depth buffer ekkor egy renderbuffer, amit az "OpenGL tölt fel automatikusan"
1.2) ekkor a world position visszaszámolásához elég csak egy összeadás és egy szorzás

2) nem használok külön textúrát, helyette a depth buffert állítom be úgy, hogy textúrába rendereljen
2.1) ekkor nem használhatok lineáris depth-et (ha nem módosítok a projection mátrixon), hiszen nem akarom módosítani a gl_FragDepth-et, mert akkor oda a z-cull.
2.2) a world position visszaszámolása pedig egy vec3-mátrix-szorzássá (invViewProj) módosul

   
Asylum - Törzstag | 5511 hsz       Online status #209118   2016.02.29 11:08 GMT+1 óra  
A zbuffer azért van, hogy ezt hardveresen megoldja...minek pazarolnád a CPU idejét olyan dolgokkal amit még csak nem is tudsz jól megcsinálni... pl. ha van 100 ezer objektumod azt framenként berendezed? Hát az jó lassú lesz...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209115   2016.02.28 20:27 GMT+1 óra  
Z-only pass esetén nem kell rendezni, egyébként meg sima forward renderingnél, vagy akár deferred shading gbuffer részénél is érdemes. Főleg, ha tényleg 1-nél több fényed van (forward). Z-only passhoz nyilván nem muszáj, ha kevés a CPU, vagy ilyesmi.

Egyébként meg a sorrend az renderertől is függ szerintem. Bizonyos esetekben szerintem érdemesebb előbb shader szerint, majd úgy vbo szerint rendezni/csoportosítani. Főleg régebbi kártyákon (< OGL 3), ahol még nincs se Uniform Buffer, meg semmi ilyesmi.

szerk.:
Egyébként pont mostanában olvastam ilyesmi dolgokat, itt van például ez kiindulásnak.

   
Asylum - Törzstag | 5511 hsz       Online status #209113   2016.02.28 15:30 GMT+1 óra  
Batching priority:
1) vbo váltások minimalizálása (static/dynamic batching)
2) shader váltások minimalizálása (übershader)
3) textúra váltások minimalizálása (textúra atlasz)

CPU-n nem rendezünk telített objektumokat, mert akkor mi a francért van zbuffer... Z-only pass ajánlott, ha egynél több fényed van.

Az elágazás akkor költséges, ha a feltétel egy futásidejű változótól függ. A fragment shaderek 2x2-es blokkokban futnak, tehát az ilyen (dinamikus) feltételek mindkét ága kiértékelődik (régebbi kártyákon). Uniformokon lehet ifelni, az nem költséges.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #209111   2016.02.28 01:18 GMT+1 óra  
Értem, pedig azt hittem volna hogy a shader váltás nagy munka a GPU-nak, de akkor a shaderenként rendezem majd, amíg valaki nem tud jobbat
Ezt a lehetőséget amit leírtál inkább hanyagolnám, mert bár CPU időm van bőven, de böngészőbe azért kicsit korlátozottak a dolgok.
Köszi a válaszokat!
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 619 hsz       Online status #209110   2016.02.27 12:41 GMT+1 óra  
Szerintem mindenképpen a shaderenkénti rendezés a jobb. No persze majd megmondják az okosok.

Esetleg csinálhatsz egy depth-only passt, amikor kirajzolod a modelleket front-to-back rendezéssel, egyetlen egyszerű shaderrel (ami nem ír colort, csak depth értéket). Ezután jön a shading pass, amikor a depth write-ot kikapcsolod, csak depth test marad. Ekkor pedig már shaderenként lenne rendezve, a kamerától való távolság pedig lényegtelen lenne.
Hátránya: a jelenetet 2x kell kirajzolni
Előnye: early-Z cull

   
peti634 - Tag | 148 hsz       Online status #209109   2016.02.27 11:55 GMT+1 óra  
Értem, viszont nekem gyorsabbnak tűnt az, hogy elsőnek a kamerától távolságától rendezem a modelleket, és így rajzolom ki őket sorba, de akkor itt is adódik a kérdés hogy melyik a gyorsabb?
Kamerától távolság alapján sorba rendezés, vagy shaderekénti rajzolás?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 619 hsz       Online status #209107   2016.02.27 07:16 GMT+1 óra  
Ja így már értem. Szerintem jobb lenne a shader váltás (#ifdef). Ehhez pluszban annyit kell tenned, hogy a modelleket, amiket ki akarsz rajzolni, rendezned kell (amit egyébként is érdemes megtenni) különböző tulajdonságaik alapján (pl. milyen shadert használ, távolsága a kamerától, stb.), így nem lesz sok fölösleges shader váltás, csak mondjuk 2 / frame. Először kirajzolod azokat, amiknek az a shaderjük van, amihez nem kell textúra, majd a textúrázottat. Vagy valami ilyesmi.

Itt is végül arra jutottak, hogy érdemes különszedni a renderelést, mint shaderen belül ifelni.

   
peti634 - Tag | 148 hsz       Online status #209106   2016.02.26 22:51 GMT+1 óra  
Köszi a választ, akkor ebben az esetben elvileg ki tudja optimalizálni a SM? Mivel az adott rajzoláskor az uniform ugye végig egy adott értékű lesz.

Egy egyszerű dolgot: Textúra alkalmazás, vagy simán fehér szín. Ha nem adok meg Texet akkor ne számoljon feleslegesen, és egy jó megoldás legyen a döntés.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 619 hsz       Online status #209105   2016.02.26 21:05 GMT+1 óra  
Amennyire én tudom, a shader kódon belüli elágazás alapvetően nem jó ötlet, hacsak nem nagy egybefüggő területekre ugyan az lesz a feltétel kiértékelése. Ekkor SM nemtudommennyi fölött tud már optimalizálni. Egyébként pedig olyan, mintha az if/else mindkét részét lefuttatná, csak a megfelelőt alkalmazná.

Pontosan mit szeretnél egyébként megcsinálni? Lehet, hogy van rá jó/jobb megoldás, másképp való szervezés, renderelés, stb.

   
peti634 - Tag | 148 hsz       Online status #209104   2016.02.26 20:16 GMT+1 óra  
Üdv mindenki.
Ti mit ajánlotok jobbnak?
Fragment shaderben szeretnék dönteni egy ponton (egy adott változó így vagy úgy számítódik ki).
Kérdés hogy if és uniform bool megoldás a helyesebb, vagy több kirajzolás esetén két shader között váltsak? (#ifdef megoldás)
Szóval a kérdés melyik a gyorsabb? (gondolom a kirajzolások száma, és a fragment programok lefutások száma jelentősen befolyásolja a dolgot)
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5511 hsz       Online status #209021   2016.02.01 20:15 GMT+1 óra  
Ne legyen úgy megírva...jobb esetben is elcrashel a driver.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209020   2016.02.01 18:13 GMT+1 óra  
Na megint én!

Szóval, van egy MeshVertex nevű struktúrám, amely az összes lehetséges vertex-attribútumot tartalmazza (pozíció, normal, stb.). Van továbbá egy Mesh osztályom, amely a vertexeket (és az indexeket) tárolja, továbbá flageket, hogy mely attribútumok vannak használatban (vagy éppen automatikusan számolandók; ilyen lehet a normal és a tangent).

Na most az egész problémám a shadereknél kezdődik. Tegyük fel, hogy egy shader úgy van megírva, hogy használja a color attribútumot is, de a mesh úgy van felépítve, hogy nincsenek valid adatok a color mezőkben, illetve a flag is úgy van beállítva, hogy nincs használatban a color.

Mi történik olyankor, amikor a shaderben egy olyan attribútumot akarok olvasni, amelyen nem olvasható valid adat, illetve nincs beállítva sem (glVertexAttribPointer)?

Esetleg valami okosabb megoldás erre az egészre? A gond igazából szerintem az, hogy függ is meg nem is egymástól a kettő. Maga a mesh leírás független kell, hogy legyen a shadertől, rajzoláskor azonban mégis fontos, hogy milyen adatok elérhetőek.

   
Asylum - Törzstag | 5511 hsz       Online status #209012   2016.01.30 11:24 GMT+1 óra  
A Doom 3 (BFG) pl. a végletekig összepackolja. A normálvektor nevében is bennevan, hogy normalizált, tehát elég neki a 8 bites precízió is.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #209011   2016.01.30 10:25 GMT+1 óra  
Itt írnak mindenféle trükközést, hogy hogyan érdemes / lehet packelni az adatokat. Ezt tényleg jó megtenni? Nálam eddig simán minden adat (kivéve a color) GL_FLOAT volt, ennek megfelelően n x 4 byte. Azért az nem kevés spórolás, ha vertexenként 12 byte helyett 4 byte a normal.

   
Asylum - Törzstag | 5511 hsz       Online status #208853   2015.12.27 11:04 GMT+1 óra  
Inkább ezt nézzed, mert itt minden függvényhez oda van írva, hogy mikortól van.

https://www.opengl.org/sdk/docs/man/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #208840   2015.12.25 08:35 GMT+1 óra  
Van itt egy csodalink:
https://www.opengl.org/registry/oldspecs//gl.spec
Itt van egy olyan szekció, hogy "OpenGL 2.0 commands". Amik ez alatt vannak felsorolva, azok ezek szerint ogl 2.0-tól elérhetőek, mint "core"? Szóval, ha 2.0 a target, akkor simán lekérhetem a függvény címét az opengl dll-ből? Mert, ha jól értem a (windowson) wglGetProcAddress az extensionökhöz kell.

szerk.:
Ok, közben leesett, kelleni fog a wglGetProcAddress, mert alap esetben Windowson talán 1.1-ig vannak a függvények az OpenGL32.dll-ben. Vagy valami ilyesmi. Viszont az FBO-n kívül ARB-t nem kell használnom. És szerencsére az FBO-hoz tartozó függvények neveinél nincs ott az ARB suffix.

Ezt a hozzászólást Instalok módosította (2015.12.25 14:37 GMT+1 óra, ---)

   
Asylum - Törzstag | 5511 hsz       Online status #208738   2015.11.30 15:06 GMT+1 óra  
Mint mondtam, a cikkes kódok között nincs user defined paraméter.

A qFX Editornak elérhető itt egy változata (nyilván kód nélkül).

https://www.dropbox.com/s/vw0kwhwmkje9yl4/qFXEd.zip?dl=0

Ezt a hozzászólást Asylum módosította (2015.11.30 15:12 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2529 hsz       Online status #208737   2015.11.30 14:30 GMT+1 óra  
Amit én láttam eddig céges engine kódban az az volt, hogy a shader betöltésekor lekérdezett vagy 1000 különböző paraméter locationt, akár ugyanazt több névvel is (pl: specular, spec, specpower, specpwr, specpower...). Az azonosokból valószínűleg úgyis csak egy volt a shader kódban. Amit nem talált, azt nem is vette át a materialból. Így a shader írásnál figyelni kell mik a limitációk, de úgyis 99%ban kb ugyanazokat használod, esetleg még lehet pár custom paraméter.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 619 hsz       Online status #208736   2015.11.30 14:23 GMT+1 óra  
Ezt a 3 file-t (1 2 3) nézegetve azt vettem észre, hogy túl sokban nem különbözik a gondolatmenetünk, csak még beleraktál egy kis runtime keresgélést, amit én inkább lerögzítettem init-time, mert úgysem fog változni.

Tulajdonképpen ugyan azt csináljuk, csak (még?) nem találtam nálad user-defined paramétert, ami belefordul a shader kódba. Úgy láttam, hogy fixen, előre elkészített shaderek vannak, és azoknak fix paramétereit tudod állítani. Amit egyébként én is valahogy hasonlóan csináltam volna meg.

Szerintem túl van tárgyalva a problémakör, ami nem mellesleg már csak alig-alig kapcsolódik az OpenGL-hez, így szerintem nem a megfelelő topicot járatjuk.

[off]
Látszik, hogy először DirectX-et tanultál, igen hasonló köntösbe ültetted, az OpenGL-t is. Ami nem baj, egyáltalán nem, csak gondoltam megjegyzem.

Egyébként hatalmas plusz pont, hogy mindig megosztod a kódot, szerintem nagyon sok embernek sok segítség. Ráadásul alapvetően igényes kódot láthatnak, nem úgy, mint a legtöbb elérhető online tutorialban, ahol össze van hányva az egész.
[/off]

   
Instalok - Tag | 619 hsz       Online status #208735   2015.11.30 14:01 GMT+1 óra  
Igen, tudom, hogy csavartam rajta egyet, azért is tisztáztam.

A jelenlegi design szerint a material nem lehet ezektől független, mert a shader határozza meg a paraméterek halmazát.

Természetesen nem én adom meg kézzel a paraméternek a locationt, hanem az effekttől kérem le. Azt, hogy ollózzam bele a shader kódba, nem teljesen értem, hogy mire gondolsz. Részben ezt is csinálom. Amikor fordítom a shadert, adottak a user-defined paraméterek is, és azok alapján egészítem ki a kódot, fordítom le, és kérem le a uniformok helyeit.

Lehet megnézem a kódodat, mert így továbbra sem látom, hogy hogy tudnád azt megoldani, amit én ezzel a módszerrel. Egyébként pontosan melyikre gondolsz? Gondolom ezek közül.

   
Asylum - Törzstag | 5511 hsz       Online status #208734   2015.11.30 13:34 GMT+1 óra  
Megkeverted a fogalmakat mert a klasszikus szemlélet szerint

effect = technikák (vs/ps párok) halmaza
shader = vs vagy ps, ez kvázi a GLSL kód
material = ezektől teljesen független, néhány paraméter (PBR-ben pl. basecolor, roughness, metalness)
(user defined) param = itt kezdődnek a bajok, de elmondom mégegyszer: ehhez nem rendelhetsz uniform locationt mert gigantikus szopás lesz a vége. Ollózd bele a shader kódba (ha mást nem) és bízd a driverre, hogy milyen locationt ad neki (amire te nem építhetsz semmit). Sőt még az is előfordulhat (Intel kártyákon), hogy a location nem is 0-tól induló természetes szám, hanem valami hexa hülyeség pl. 0xabcdefaa.

szerk.: nézd meg az implementációmat és rájössz (eltekintve a shader ollózástól mert olyat nem csináltam a samplekben).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #208733   2015.11.30 12:50 GMT+1 óra  
Semmi probléma nincs ezzel a megoldással, szuperül működik. Egyszerűen bővíthető, flexibilis, és absztraktált is. Gondolj bele: ha DirectX-ben is két effekted van, akkor ahhoz két különböző "uniformod" is lesz. Akárcsak OpenGL esetén. Ennél több grafikus API-val (már ha egyáltalán van) pedig nem akarok foglalkozni.

Sőt, mi több, a lentebbi példáddal is csak az én igazamat bizonyítottad, amikor is felsoroltál két különböző effektet ugyan ahhoz a shaderhez.

Na de tisztázom a fogalmakat, mert ez csak az osztályok elnevezése nálam:
Effect: low-level, a direkt kommunikáció a (GLSL) shaderrel.
Param: high-level, van egy értéke, amit a user be tud állítani, le tud kérni, illetve van egy direkt elérése a shaderhez, azon belül is az adott effektekhez tartozó uniform helyhez.
Shader: mid-level, tartalmazza az effekt-variációkat (azaz egy effektet a statikus meshekhez, egy effektet az animált meshekhez, stb.), illetve a high-level paramétereket.
Material: egy adott shadernek egy "override-olása", amikor a paraméterek értékeit módosíthatjuk.

Tehát elkészül egy "metal" Shader, néhány paraméterrel. Ebből készül n db Material, mint például alumínium, réz, stb. Az alap shadernek adottak a paraméterei, azonban egy Shaderen belül több Effekt is van (statikus meshhez, animált meshhez, stb.). Tehát egy paraméternek egyszerre több effekt uniformjának a helyére is referálnia kell. Ezért tárolok az adott Paraméter osztályon belül több locationt, ami egyébként el van különítve a grafikus API-tól.

Egyébként meg simán lehet, hogy elbeszélünk egymás mellett, vagy csak nem értem meg, amit mondasz.

szerk.:
Az a baj, hogy a megoldásodból (hogy nem tárolok location-t a paraméternél) nem látom, hogy miként tudnám ténylegesen használni a paramétert, azaz hogyan tudnám setelni az értéket az effektnek. Nyilván azon kívül, hogy a neve alapján runtime lekérem a locationt attól függően, hogy melyik effekt van bindolva.

   
Asylum - Törzstag | 5511 hsz       Online status #208732   2015.11.30 12:34 GMT+1 óra  
Fölösleges ez a struccpolitika; feltettél egy kérdést én pedig rámutattam egy komoly hibára az implementációdban. A terv azért terv mert azt még könnyű módosítani. Ha most ebbe a láthatóan rossz megoldásba mélyedsz bele, akkor egyre több probléma fog előjönni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #208731   2015.11.30 10:19 GMT+1 óra  
Rendben, akkor legyen neked igazad, ha ennyire erre a mondatra vágysz.

   
Asylum - Törzstag | 5511 hsz       Online status #208727   2015.11.29 20:20 GMT+1 óra  
Tervezési hiba. Egy absztrakcióba belekevertél GL specifikus fogalmakat. (így nem is absztrakció). A user által bütykölhető magas szintű shadert nem szabad közvetlen GL fogalmakra fordítani.

A magas szintű megfogalmazást kell GLSL shaderbe fordítani és azzal etetni az alacsony szintű renderert, ahol a location teljesen el van fedve (nálam a shader fordító pontosan ezt csinálja, ezért tudtam olyan absztrakciókat bevezetni, ami GLSL-ben nincs, pl. típus dedukció, típustalan sampler, implicit típuskonverzió stb.).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
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]