játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5476
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:    2195
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]
Instalok - Tag | 590 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 | 590 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 | 2195 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 | 5476 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 | 2195 hsz       Online status #209577   2016.05.11 22:13 GMT+1 óra  
elmélet vs valóság

   
Instalok - Tag | 590 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 | 2195 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 590 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 5476 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, 1016 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 590 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 590 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 | 590 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 5476 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ő | 2526 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 | 590 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 | 590 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 | 5476 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 | 590 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 | 5476 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 | 590 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 | 5476 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/
   
Instalok - Tag | 590 hsz       Online status #208725   2015.11.29 19:31 GMT+1 óra  
Ez már nem az alacsony szint

Van egy base parameter osztályom, ezt tudja a user használni. Ebben tárolok egyéb dolgokat is, például, hogy ez milyen típusú (Float, Vec2, stb.) paraméter, és, hogy ne kelljen mindig lekérdezni, el van tárolva az adott effekthez tartozó location is.

Ezekből vannak konkrét típusok, mint pl. Vec2Param, stb., ami tárol egy értéket, van hozzá getter/setter, illetve egy adott Effekthez be tudja magát állítani (glUniformXY hívások).

Igen, mint mondtam, abban az esetben, ha csak a vertex shader tér el, úgy nincs probléma, mert a uniform location ugyan az lesz a fragment shadernél. Azonban, ha különböznek, akkor különböző location-ök tartoznak ugyan ahhoz a shaderparaméterhez.

Viszont így később lehetőség nyílik vertex-shader módosításra is user oldalról, ahol viszont már biztosan különbözni fognak a uniform location-ök.

Mondjuk a user létrehoz egy "alma" vec4 paramétert a shaderjéhez. Használni fogja statikus mesheknél, animált mesheknél, és egyéb dicsőséges helyeken. Tehát létrejön egy Vec4Param típusú objektum, aminek van egy Vector4 értéke, hozzá getter/setter, és be tudja magát állítani egy Effecthez.

Amikor egy paramétert létrehozok és eltárolom a Shaderben, akkor hozzá is rendelem a locationt. Itt jön a képbe a több location, mivel több effektem is van (statikus meshhez, animált meshhez, stb.), és nem tudhatom előre (de, egyébként de, mert én írom a shadert ), hogy melyiknél fognak különbözni, így eleve felkészülve a "legrosszabbra", több locationt tárolok, egyet minden egyes effekthez (avagy shader-variációhoz, ha úgy tetszik).

Pszeudo-c++-kód jelleggel valami ilyesmi:
Kód:
enum Usage { StaticMesh, AnimatedMesh, ... };
#define USAGE_COUNT 2

class Param
{
    enum Type { Vec2, ... };

    Type type; // a paraméter típusa
    Location loc[USAGE_COUNT]; // az adott shader-variácóhoz tartozó uniform location

    void Apply(Effect* effect, Usage usage); // a usage-et használva a loc indexeléséhez
};

template <typename T>
class ParamValue : public Param
{
    // get/set..

    T value;
};

class Shader
{
    Effect* effects[USAGE_COUNT]; // egy-egy effekt mindegyik variációhoz

    void ApplyParameters(Usage usage); // az összes paraméter beállítása
};

   
Asylum - Törzstag | 5476 hsz       Online status #208724   2015.11.29 18:07 GMT+1 óra  
Nem értem, hogy miért viszed le a problémát az uniform location szintjére (annak fel se kéne merülnie ebben a kontextusban). A skinnelés egyébként is vertex shader-hez kötődik, ahhoz pedig nem kötődik a material, szóval a két probléma teljesen "diszjunkt". A magas szintű modellt gondold át, mert ez sokkal inkább tervezési hibának tűnik.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 590 hsz       Online status #208723   2015.11.29 14:01 GMT+1 óra  
Nem, vagy rosszul fogalmaztam meg a felvetést, vagy csak nem értetted meg. Tisztában vagyok vele, hogy a uniform mihez tartozik, és hogy mi mit csinál, kinőttem már az ovit.

A problémám a paraméterekkel van. Akarom mondani volt, mert megoldottam közben.

Ha a júzer készít egy shadert, akkor ő főleg a materialt akarja definiálni (mint UE4-ben pl.). Létrehoz pl. egy vector4 paramétert, amivel majd állítgatja a színt. Innentől kezdve őt nem érdekli, hogy ez most éppen animated meshre vagy mire van alkalmazva. Amíg a fragment shader részben nem tér el a két shader, addig nincs gond a locationnel, mert ugyan azt fogja visszaadni. Azonban, ha más a fragment shader is, akkor különbözhetnek a locationök is. Meg ugye eleve két effect kell (ahogy Te is írtad itt lentebb a kódban).

Egyelőre úgy tűnik, hogy megoldottam a problémát. Csináltam egy shader usage enumot, ami kvázi egy shader variációt ír le. Van egy static meshhez, animált meshhez, stb. És egy paraméternek pontosan ugyan ennyi darab uniform location is van eltárolva, ami kvázi az i. effekthez tartozó uniform location. Na mind1, nehéz kicsit körülírnom most, az a lényeg, hogy megoldottam.

   
Asylum - Törzstag | 5476 hsz       Online status #208722   2015.11.29 12:52 GMT+1 óra  
wtf? oO miért kell két location? nem lehet, hogy te OOP szemszögből basztad el a dolgot? (az uniform a shaderhez tartozik nem a meshhez!!!)

Kód:
OpenGLEffect* renderstatic = 0;
OpenGLEffect* renderanimated = 0;

GLCreateEffectFromFile("render.vert", 0, "render.frag", &renderstatic, "#define ANIMATED 0\r\n");
GLCreateEffectFromFile("render.vert", 0, "render.frag", &renderanimated, "#define ANIMATED 1\r\n");

...

if (mesh->IsSkinned())
    renderanimated->Begin();
else
    renderstatic->Begin();

mesh->Draw();
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 590 hsz       Online status #208714   2015.11.27 18:18 GMT+1 óra  
Igen, define-okat én is használok. A probléma inkább azzal van, hogy ha user defined paramétert akarok beállítani, akkor ott valahogy figyelembe kell venni, hogy most static mesheket, vagy animated mesheket akarok rajzolni, de ezt majd valahogy megoldom.

Igen, egyébként a locationt én is egyszer kérdeztem le, de tekintve az alább glsl kódot:
Kód:
#ifdef ANIMATED

#define NUM_BONES 60
uniform     mat4    bones[NUM_BONES];

#else // ANIMATED

uniform     mat4    world;

#endif // ANIMATED

akkor az ezután következő uniformok helye más és más lesz. Azaz, ha lekérem az "alma" nevű uniform helyét, akkor ahhoz gondolom 2 locaiont tárolok, egyet a statikushoz és egyet az animálthoz. Amikor meg apply-olom a paramétereket, akkor megmondom neki, hogy ez most static vagy animated rajzolás, és a megfelelő locaiont használom. Eddig legalábbis valahogy így csináltam. Na de ez már nem OGL.

   
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]