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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
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 | 543 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 | 5448 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 | 543 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 | 543 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 | 543 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 | 5448 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 | 543 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 | 5448 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 | 543 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 | 5448 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 | 543 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, 694 nap)

   
Asylum - Törzstag | 5448 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, 719 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2520 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 | 543 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 | 543 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 | 5448 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 | 543 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 | 5448 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 | 543 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 | 5448 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 | 543 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 | 5448 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 | 543 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 | 5448 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 | 543 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.

   
Asylum - Törzstag | 5448 hsz       Online status #208711   2015.11.27 14:34 GMT+1 óra  
Az uniform locationt csak betöltéskor kell lekérdezni (ld. opengl kódjaim a githubon).

Duplikálás: én pont ezen probléma miatt írtam saját shader fordítót, ami képes template-eket is fordítani (konstans kifejezés paraméterekkel). Így végeredményben egy shadert írok csak meg, persze aztán kettő lesz belőle betöltés után.

Ha ilyet nem akarsz, akkor szintén a PBR demómban használtam olyat, hogy egy #define-t adok meg betöltéskor és aszerint forrdul más shader.

Ezt a hozzászólást Asylum módosította (2015.11.27 14:40 GMT+1 óra, 722 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 543 hsz       Online status #208710   2015.11.27 14:15 GMT+1 óra  
Bár ez már csak részben kapcsolódik ide, materialkezelés:

Unity esetén a material egy adott shadert használ, azoknak módosíthatjuk a paramétereit, de maguk az elérhető paraméterek a shaderben definiáltak.

UE4 esetén pedig maga a material definiál egy shadert is, így minden egyes materialhoz külön shader készül. Mármint amelyek nagyon különböznek, mert ott van az instancing materialok esetén is.

Végső soron a kettő elég hasonló, van egy base (shader), és van hozzá lehetséges override (material). A problémám ott kezdődik, hogy GPU skinning esetén máris duplázni kell a shadert, mert más a vertex transform, mások lesznek a uniform location-ök is, stb.

Apropó, a uniform helyét lekérni (glGetUniformLocation) költséges dolog?

   
Instalok - Tag | 543 hsz       Online status #208701   2015.11.26 14:50 GMT+1 óra  
Na igen, mondjuk az is kérdéses, hogy ez szokott-e a szűk keresztmetszet lenni. Nagy híve vagyok a deferred shading rendszereknek, és ott általában a textúrák írása a megterhelő, nem a bemenő adatok átpasszírozása.

   
Asylum - Törzstag | 5448 hsz       Online status #208699   2015.11.26 13:45 GMT+1 óra  
Külön VBO-ba ne pakolj...ezen speciel nincs ertelme sporolni...inkabb hasznald ki optimalisan a memoriat es a shader egysegeket (vcache optim, static batching ahol lehet, state management, stb.). Azok hoznak lényeges teljesítményjavulást.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #208698   2015.11.26 13:26 GMT+1 óra  
Én teljesen kihasználom a shader reflectiont - erre épül a saját API-m is.

Az alkalmazás létrehoz N db VBO-t megmondja milyen attribok vannak benne (név, méret).
A shader pedig megmondja milyen attribokra van szüksége (név, méret).

Amikor először találkozik a shader a mesh-sel a shader megnézi a mesh VBO-it és hogy azok tartalmazzák-e a neki szükséges attribokat. Ha több attrib van a VBO-kban az nem baj ill. mindegy melyik attrib melyik VBO-ban van.
alias aalberik
   
Instalok - Tag | 543 hsz       Online status #208697   2015.11.26 13:09 GMT+1 óra  
Szerintem ilyenekkel nem fogok trükközni, maradnak a külön VBO-k.

Az eddigi rendszer annyi volt, hogy, ha volt egy Mesh, akkor készítettem hozzá egy VBO-t. Azt, hogy abban milyen adatok vannak, maga a Mesh döntötte el. Tipikusan csak 2 fajta volt: egy a lentebb említett struktúrával, meg egy másik, amiben a csontanimhoz tartozó információk is voltak. Illetve volt egy külön is, amit full-screen quad rendereléshez használtam, abban csak pozíció és uv volt.

Ezután rajzoláskor átadtam paraméterként, hogy jelenleg melyik shader az aktív, és az milyen attribútumokat vár. Ez alapján beállítottam az attribútumokat. Régi kód:
Kód:
void DrawBuffer::beginDraw(const Effect* const _effect) const
{
    glBindBuffer(GL_ARRAY_BUFFER, vbo);
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);

    for (Effect::Attributes::const_iterator it = _effect->getAttributes().begin();
         it != _effect->getAttributes().end(); ++it)
    {
        VertexElement* const v = elements[it->first];
        glVertexAttribPointer(v->usage, GL::VertexAttribSize[v->type], GL::VertexAttribType[v->type],
                              GL::VertexAttribNormalized[v->type], vertexSize, GL_OFFS(v->offset));
    }
}

Ahol a v->usage egy olyan enum, amiben azt tárolom, hogy ez most pozíció, vagy normál, vagy miféle adat, a többi meg értelemszerű.

Mivel azt mondtad, hogy ezzel nem lehet spórolni, így a következő módosításon gondolkoztam:

A Mesh nem csak egy VBO-t tárol, hanem VertexLayout-hoz tartozó VBO-kat. Azaz, ha hozzáadok egy Mesh-t a jelenethez, akkor már tudnom kell, hogy az milyen shaderrel lesz kirajzolva, hogy annak lekérhessem az attribútumait. Miután ez megvan, megnézem, hogy van-e már ilyen VBO, ha nincs, akkor készítek egyet, ha van, akkor használom azt.

Maga a VBO létrehozása is trükkösebb, mert az adott layout alapján kell a megfelelő vertex struktúrát kiválasztani, abból elkészíteni az arrayt, és azt feltölteni a VBO-nak.

Ezzel viszont picivel jobban oda kell figyelni runtime material (vele együtt akár shadert) váltáskor, meg egyéb esetekben.

Valahogy így gondoltad? Valószínűleg std::map-et használnék, hogy rajzoláskor is gyorsan megtaláljam a megfelelő VBO-t a kívánt shader layout-ja alapján.

   
syam - Törzstag | 1491 hsz       Online status #208696   2015.11.26 12:38 GMT+1 óra  
Azon tudsz még spórolni, hogy amit lehet nem 4 hanem 2 vagy 1 byte-on tárolsz (ilyen tipikusan a normál v tangens). De minden adatot lehet kvantálni és eldönteni, hogy mennyi biten tudod tárolni. Emiatt is születnek a bizarrabbnál bizarrabb vertex attrib formátumok.
alias aalberik
   
Instalok - Tag | 543 hsz       Online status #208695   2015.11.26 12:02 GMT+1 óra  
Hát, akkor sajnos sávszélen nem lehet ezzel spórolni. Igen, gondolkoztam azon is, hogy akkor külön VBO-ban lesznek az adatok.

A külön VBO megoldásnak meg ugye annyi a hátránya, hogy előre ismerni kell, hogy a shadernek milyen attribute-jai lesznek. Ami nyilván nem megoldhatatlan, de az a megoldás nekem szebbnek tűnt, hogy elég csak rajzoláskor tudni, hogy éppen milyen shadert használunk.

Egyébként bonyolultabb technikáktól, illetve extrém körülményektől eltekintve, inkább pazarlok memóriát, mint sávszélességet. Az előbbiből több van.

   
syam - Törzstag | 1491 hsz       Online status #208694   2015.11.26 11:47 GMT+1 óra  
Tudtommal stride mennyiségű adat fog átmenni a buszon.
Ezt azzal tudod áthidalni, hogy több VBO-ban tároldod az attribokat, de abból meg kevésbé szeret olvasni.

Azt szokták javasolni, hogy különböző variációkban tárold a VBO-t.
Egyik leggyakoribb, hogy pl shadow renderhez sokszor elég a pozíció (+ néha UV) ehhez külön VBO. Egy másik VBO-t pedig "rendes" renderhez pozíció, UV, normál stb.
Memóriapazarló, de optimális a sávszélnek.

Ja és a pozíció mindig legyen az első attrib, mert sok gyártó erre optimalizál (pl. AABB számolás driver oldalon és egyéb agyrémek).

"Kirajzoláskor pedig fogom és az adott shadert figyelembe véve állítom be" - bizony mindig használd a shader reflectiont.
alias aalberik
   
Instalok - Tag | 543 hsz       Online status #208693   2015.11.26 11:16 GMT+1 óra  
Van egy struktúrám, amiben benne vannak olyan információk, mint a pozíció, uv, normal, tangent, és ebből van egy tömböm, ami leírja a vertexeket. Létrehozok egy VBO-t, majd feltöltöm az adatokat (glBufferData). Kirajzoláskor pedig fogom és az adott shadert figyelembe véve állítom be az attribute-okat (glVertexAttribPointer). Azaz, ha egy shadernek csak pozícióra van szüksége, akkor csak egyszer hívom meg ezt a függvényt.

A kérdésem a teljesítménnyel kapcsolatban lenne. Mivel a videómemóriába fel van töltve a teljes adat (a normal meg a tangens is, akkor is, ha nem használom), így memória szempontjából nem túl takarékos, ezt értem. Viszont mi van a sebességgel? Nyerek egyáltalán valamit azzal, hogy csak bizonyos attribute-okat használok, vagy onnantól kezdve mindegy, hogy a videókártya memóriájában van? Gondolom az azért nem mindegy, hogy mennyi adatot passzírozunk át a csövön.

   
Lord_Crusare - Törzstag | 1290 hsz       Online status #208456   2015.10.13 19:00 GMT+1 óra  
A kiejtés egész pontosan "juniti". Ezért nincs olyan, hogy "az unity", hanem "a unity".

   
Asylum - Törzstag | 5448 hsz       Online status #208455   2015.10.13 18:25 GMT+1 óra  
Mi junity-nak mondjuk
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2188 hsz       Online status #208454   2015.10.13 13:44 GMT+1 óra  
mikroszoft, unití, jáva, vindovs

   
Instalok - Tag | 543 hsz       Online status #208452   2015.10.13 13:35 GMT+1 óra  
Ha már off: az is siralom, ha valaki a Unity-t "az Unity"-nek írja. Hogy ejted ki? Uniti? Egyébként örülök, hogy írtál erről is cikket, anno engem is foglalkoztatott a PBR. Elég tömény mateknak tűnik, szóval még nem ugrottam neki, na de majd egyszer.

   
zeller - Törzstag | 464 hsz       Online status #208451   2015.10.13 12:53 GMT+1 óra  
Na ja. Az unity egy siralom. De ez offtopic. Csak muszaj volt belerugnom

   
Asylum - Törzstag | 5448 hsz       Online status #208449   2015.10.13 07:59 GMT+1 óra  
Szerintem a PBR önmagában nem változtatja meg azt a tulajdonságot, hogy egy enginet ránézésre felismerj. Főleg a hibás implementációk miatt (Unity), vagy az ütős realtime GI miatt (Frostbite). Az UE4-nek is megvan a maga jellegzetessége (sok specular highlight).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
FZoli - Szerkesztő | 4892 hsz       Online status #208448   2015.10.13 06:22 GMT+1 óra  
Nem kívántam tovább érvelni ellened, mert a tapasztalat azt mutatja, hogy nincs értelme, de azért csak hozzászólom még ezt, tisztázandó, hogy nem azért nem írtam, mert pl. elakadt a szavam az elméd ereje felett, mint ahogy te gondolnád.

A kiindulópont az volt, hogy a PBR miatt vannak felismerhető hasonlóságok, erre jöttél h mióta van 3d gyorsítás, azóta a játékok kinézete ezen múlik. Erre mondtam h ez szerintem már túlzás, de ezt elvontan te is megfogalmaztad, magad cáfolva:

minnél közelebbi leszármazási vonalat vizsgálunk, annál jobban hasonlítanak, és minnél távolabbit vizsgálunk, annál kevésbé.

Legyen ennyi elég.
   
Geri - Törzstag | 2188 hsz       Online status #208445   2015.10.12 16:08 GMT+1 óra  
minnél közelebbi leszármazási vonalat vizsgálunk, annál jobban hasonlítanak, és minnél távolabbit vizsgálunk, annál kevésbé.

egy emlős gerinces, és egy nem emlős gerinces is máshogy néz ki, de valamennyire azért hasonlítanak.

egy gerinces, és egy gerinctelen állat is máshogy néz ki.

és pl egy oxigént lélegző, egy széndioxidot lélegző, és egy nitrogént lélegző életforma már teljesen máshogy néz ki.

egy másik bolygó élőlényeit pedig igencsak nehezen fogjuk tudni észrevenni, főleg, ha nem is szén-alapúak. a te példád is az én gondolatmenetemet igazolja.

   
FZoli - Szerkesztő | 4892 hsz       Online status #208444   2015.10.12 14:36 GMT+1 óra  
nah ezzel viszont nem értek egyet. Attól még, hogy ugyanaz az api, még nagyon messze vagyunk a kinézettől.

Ennyi erővel a raszterizált megjelenítők is meghatározzák a kinézetét a játékoknak, de így még sem kategorizálunk. Mintha azt mondanád, hogy minden földi életforma azonos, csak mert szénalapú.
   
Geri - Törzstag | 2188 hsz       Online status #208443   2015.10.12 14:11 GMT+1 óra  
fzoli: a 3d gyorsítás a játékok kinézetét egyértelműen meghatározza, mert ugyanazon apik alatt futnak, amik alapvetően ugyanúgy renderelnek. ~1996 előtt, tehát a 3d éra előtt sokkal nagyobb volt a grafikai diverzitás.

   
FZoli - Szerkesztő | 4892 hsz       Online status #208442   2015.10.12 13:42 GMT+1 óra  
Azért az én megfogalmazásomban is ott van, hogy hasznos, meg hogy csak picit öli ki Tényleg jobb vele dolgozni, viszont ma annyira minden rápörögtt a PBR-re, szinte csak post effektekben térnek el, pedig azért egy Sourceot egy Doom III enginetől mennyire meg tudtál különböztetni pl. hiába a festett hatású textúrák és a kontúros ábrázolás a Wowban, vagy a fotoreál textúrák BF3-ban, meg a teljesen más tonemapping ha a fényezési modell csattra ugyanaz, akkor ott motoszkál az érzés, mint amikor látsz egy játékot és "tudod" róla, hogy nna, ez Unity. Hiába más a model stíllusa vagy a textúra, süt róla, felismered. De persze lehetek egyedül a véleményemmel
   
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]