|
|
|
|
én az khronos GL4 specet preferálom, mert egyben látom az összes GL és GLSL függvényt (és ha funkcionalitást keresek, akkor azt célszerűbb böngészni).
|
|
|
|
|
|
Köszi, ezer hála, megnézem! 
|
|
|
|
|
|
Idézet
Asylum :
A location-t le tudod kérdezni:
https://www.khronos.org/opengl/wiki/Program_Introspection
Ja, de valami alapján le kell kérdeznem. Most egyébként is gondban vagyok design szempontjából. Bár, ez nem egészen OpenGL, de ha már itt elkezdtem...
Egyrészt, van ugye a vertex buffer, amiben benne vannak a vertexek adatai (interleaved).
Ehhez ugye tudunk mondani egy "input layout"-ot, ami megmondja, hogy az adott szemantikához (pl. Posiion) hol van és milyen az adat (offset, type, stb.) a bufferben.
Ez szép és jó, de ugye valahogy a (vertex) shadernek is meg kell mondani, hogy az adott (vertex) inputot honnan szedje. Szóval az "input layout"-ban tárolt adatokat át kell küldeni (pl. glVertexAttribFormat).
Na és itt jön nálam a conflict:
- a buffer meg tudja mondani, hogy neki mije van
- a shader megkövetel bizonyos dolgokat, pl. vec3 position
Emellett ugye ezek N:M viszonyban állnak, hiszen:
- egy buffert több shaderrel is ki kell tudni rajzolni (pl. az adott geometriát shadow pass, gbuffer pass, stb.)
- egy shader több buffert is képes legyen kirajzolni, és ezek a bufferek eltérhetnek egymástól (pl. kliens oldalon procedurálisan generált mesh, aminek más lehet a vertex layout-ja)
Továbbá nem ártana egy minimális validáció, hogy a buffer, amit ki akarunk rajzolni egy adott shaderrel, az tartalmazza-e egyáltalán a megfelelő attribútumokat (megfelelő méretben, stb.)
Minden egyes draw call előtt ezt ellenőrizni, majd beállítani a megfelelő "mappelést" eléggé overfkillnek tűnik.
Arról nem is beszélve, hogy OpenGL-ben megoldani ezt egy dolog, de, ha efelé egy réteget akar húzni az ember (hogy lehessen OGL, DX, Metal, Vulkan, akármi), akkor még trükkösebb lesz az egész. Például DX11+ az input layoutot létre kell hozni, és "hozzákapcsolni" a vertex shaderhez.
Ez valószínűleg inkább engine design kérdés, de már napok óta rágom ezt, hogy hogy lenne célszerű megcsinálni. A vastaggal kijelölt rész a fontos számomra.
|
|
|
|
|
|
Idézet
Asylum :
https://renderdoc.org
Köszi, ezt néztem már. A tényleges rendereléshez hasznos, de valami olyasmit kerestem volna, ami már a device inittől kezdve elkapja a dolgokat (a gDebugger régen ilyen volt, ha jól emlékszek). Lehet, hogy csak beállítás kérdése, csak még nem találtam meg.
Más:
Shader vertex input layout megadására (legalább) 2 lehetőség van:
- GLSL-ben beállítom az adott inputhoz a megfelelő locationt, amik fix id-k, pl. a pozícióhoz: Kód: layout (location = 0) in vec3 pos;
- GLSL-ben előre rögzített neveket használok (pl. in vec3 inPosition), majd engine/CPU oldalon glBindAttribLocation segítségével megadom a "common nevekhez" tartozó id-t, pl. Kód: glBindAttribLocation(programId, "inPosition", ID::Position);
Előbbinek előnye, hogy kevesebb utasítás, utóbbinál pedig nem id-t, hanem neveket kell megjegyezni.
Harmadik megoldásként lehetne egy metadata a shaderekhez, ami megmondja a mappinget, de az sem biztos, hogy túl sokat segít.
|
|
|
|
|
|
Mit használtok OpenGL debuggolásra? Úgy emlékszek, hogy régen a gDebuggert használtam, de azt felvásárolta az AMD és AMD-only alkalmazássá alakította át, nekem meg egy GTX 1050-esem van...
|
|
|
|
Az ArchiCAD-ben úgy van, hogy a 2D -> 3D konverzió eleve háttérben fut (amennyire tudom), szóval a konkrét task csak szinkronizál ha változott az adat (pl. leraktam egy falat) és csak azt tölti fel újra a kártyára amit kell. Ez jelenleg egy map-memcpy-unmap és minimális overhead.
Az uniform adatoknál vannak vicces dolgok, mert pl. 2D rajzoláskor nincs előre meghatározott adat, gyűjtögetni kell őket (és az uniform adatokat is). Így ott pl. unsynchronized map-memcpy-unmap van és egy fence bevárja a rajzolást ha az előre allokált uniform ringbuffer betelt.
|
|
|
|
Ha jól néztem a kódot, akkor annyi történik, hogy a RenderingCore i ndít egy új szálat, ami vár egy taskra (popol a queue-ból), ha szükséges, akkor aktiválja az adott contextet, és végrehajtja a taskot.
Így, végső soron mindig csak a render thread-en van aktív context, ami végrehajtja a gl hívásokat. Segít ez jelen esetben bármiben is? Amennyire látom ez annyiban lehet jó, ha nem a task Execute() függvényében töltünk be pl. a lemezről egy textúrát, hanem a taskot létrehozó thread-ben (ami != rendering thread), akkor a rendering thread nem akad meg a lemezről való betöltés miatt. De például a textúrát ténylegesen feltölteni már gl hívásba kerül, ami azt jelenti, hogy aktív context szükséges hozzá, azaz ez már egy task Execute() függvényében lenne. Ha nem túl nagy a feltöltendő adat, akkor ez sem okoz problémát, mert gyorsan végrehajtja, de ha túl sok az adat, akkor egy ilyen gl hívás megakaszthatja a renderelést, ami által majdhogynem elveszik a külön szálak értelme.
Ezen felül - bár írtad, hogy máshol megvalósítottad, de - itt nincs context sharing, így egy adott textúrát, mesht, bármit újra és újra be kell tölteni ablakonként
|
|
|
|
Köszi, megnézem! Egyébként a https://m.blog.hu/da/darthasylum/tutorials/C++/ch51_moderngl.html cikket és az UE4 forráskódját vettem alapul. A cikket még nem olvastam végig, mert ugye már a legelején megálltam a context létrehozásos résznél. A folder neve alapján (MultiThreading) pedig valószínűleg választ fogok találni arra a kérdésre is, amit ezek után tettem volna fel. 
|
|
|
|
|
|
Mi a best practice lehetséges többablakos alkalmazásnál?
Jelenleg minden esetben először készítek egy contextet, ami nincs semmilyen ablakhoz kötve, ez lesz a "szülő" minden más contextnek (Windows-on ez működik, csinálok hozzá egy dummy ablakot, és kész... mi van a többivel?). Innentől kezdve alapvetően 2 lehetőséget látok:
1) Amikor létre kell hozni egy ablakba egy új felületet, akkor egy új contextet hozok létre, aminek a "parent" contextje a korábban létrehozott context. Windowson:
Kód: HGLRC createContext(HWND window)
{
HDC hdc = getDeviceContext(window);
// ...
return wglCreateContextAttribsARB(hdc, --> sharedContext <--, contextattribs);
}
2) Amikor létre kell hozni egy ablakba egy új felületet, akkor nem csinálok új contextet, hanem a meglévőt használom fel. Azaz a context aktiválásakor a "parent context"-et használom az albakkal. Windowson valahogy így:
Kód: wglMakeCurrent(windowDC, --> sharedContext <--);
|
|
|
|
Köszi, 3 hónapja volt az első kommit, de ha nettóben számolom akkor nyilván kevesebb.
A maradékos osztás, az maradékos osztás A mai GPU-kon már hardveresen implementálva van szal annyira nem vészes. Egy olyan ‘szabályról’ tudok, amit a cikkben leírtam, hogy ha az osztó kettőhatvány, akkor pozitív számokra a % m = a & (m - 1). De a 10 világos, hogy nem az.
Ilyenkor fel lehet tenni a kérdést, hogy ‘tényleg szükséges a 10?’ (vagy jó-e esetleg 16 is)
|
|
|
|
Hű...! Nagyon valósághű lett. Meg sem merem kérdezni, hogy mennyi időt forgattál bele.
Én még nagyon az alapoknál tartok, igaz most sok mindenre figyelek egy időben.
A maradékos osztást, hogy lehet megoldani vagy helyettesíteni?
Kód: gl_FragColor = finalColor;
if(pos.x % 10 == 0){
gl_FragColor *= vec4(0,1,1,0.7) * 3.0;
}
Ezt így nem lehet megoldani arra már rájöttem, de a 10-el maradék nélkül osztható ismétlődéseket kellene elkapnom.
Köszönöm előre is!
Ezt a hozzászólást full3nzo módosította (2018.09.24 10:23 GMT+1 óra, 492 nap)
|
|
|
|
|
|
|
|
A gl_position-t inkább ne olvasd a vertex shaderben (kimeneti attrib). A fordító ugyan feltehetőleg megoldja, de a szabvány nem rögzíti; szervezd át a kódot, hogy a varying-ot írd először és csak a végén a gl_Position-t.
Egyébként meg ajánlom a blogomon levő Modern OpenGL cikket (még ha nem is nulláról mutat be mindent).
|
|
|
|
Köszönöm a gyors választ! Hibát a következő ponton vétettem:
Kód: attribute vec4 a_position;
attribute vec3 a_normal;
attribute vec2 a_texCoord;
attribute vec4 a_color;
uniform mat4 u_MVPMatrix;
uniform mat3 u_normalMatrix;
uniform vec3 u_lightPosition;
varying float intensity;
varying vec2 texCoords;
varying vec4 v_color;
varying vec4 v_position;
varying vec4 v_mypos;
void main() {
vec3 normal = normalize(u_normalMatrix * a_normal);
vec3 light = normalize(u_lightPosition);
intensity = max( dot(normal, light) , 0.0);
v_color = a_color;
texCoords = a_texCoord;
gl_Position = u_MVPMatrix * a_position;
v_position = gl_Position;
v_mypos = a_position;
}
A v_position.y értékét használtam így nem csoda, hogy a képpozíciót értem csak el.
Persze az sem volt világos egészen, hogy már a vertex shaderben rendelkezésre áll...
|
|
|
|
Átpasszolod a vertex shaderből...
Normálokat meg úgy a legegyszerűbb debugolni hogy azokat rajzolod megvilágítás helyett. Ha rossz irányba mutatnak, akkor valszeg fordítva vektorszoroztál.
|
|
|
|
Sziasztok!
LibGDX/openGL: segítségével futásiidőben létrehoztam egy mesh objektumot, amit shaderezni szeretnék - ez egy plane alapú heightmap. Valami gond keletkezett, mert valószínű, hogy a normálok nem jó irányba tartanak.
Azt szeretném kérdezni, hogy tud valaki olyan módszert, amivel megtudnám jeleníteni a normálvektorokat?
Egy weboldal segítségével hoztam létre ezt a dolgot, de ott is a normálok helytelen irányáról beszélnek - igaz megoldást is írtak, de én nem igazán értettem. A végső cél a multitextúrázás lenne, de egyelőre gond van az alapokkal...
Köszönöm a fáradozást annak aki átnézi a forrást!
https://stackoverflow.com/questions/20337797/libgdx-mesh-heightmap-normals-and-lights
Sikerült megoldanom a problémát. Így utólag nem tűnik nehéznek, de sok idő ráment... műveleti jelet kellett váltanom a normálszámításnál.
Még annyit szeretnék kérdezni, hogy fragment shaderben, hogy lehet megszerezni a 3D-s pixelpozíciót? gl_FragCoord-al csak a képkoordinátákat érem el: a multitextúrázásnál lenne szükségem a magasság értékre, hogy 4 textúra között készíthessek átmenetet ennek függvényében.
Ezt a hozzászólást full3nzo módosította (2018.09.02 19:19 GMT+1 óra, 513 nap)
|
|
|
|
teljesen mindegy milyen driver (mindenfajta gpu-n jön), de én intelen nézem.
|
|
|
|
|
|
-----
Ezt a hozzászólást Geri módosította (2018.01.12 17:50 GMT+1 óra, 747 nap)
|
|
|
|
|
|
Köszi
|
|
|
|
Kiraktam.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
|
|
|
|
|
|
Na akkor tanulmányozd mélységeiben az első cikket.
Belépszintű megoldás az, ami le van írva (POM-al együtt számolt árnyék). Persze te nem ezt szeretnéd, na de.
Ha ki tudtál számolni egy depth-et a POM-hoz általában, akkor egy shadow map-hez is ki tudod számolni. Kérdés, hogy szükséges-e...
Szerintem általában nem...amikor a POM renderinget végzed, akkor a shadow map rendelkezésre állhat...akkor viszont megintcsak megfelelő módon tudsz árnyalni.
|
|
|
|
Hát én ezt nem egészen értem. POM-hoz kiszámolok egy magasságot, amit ha a normál vektor irányában levonok a fragment position-ből, akkor megkapom az új, POM-os pozíciót. De ehhez nem hasonlíthatom a shadow map-et, mert a shadow mapbe még az eredeti felület mélysége van, nem a POM-os. A POM-os számításokat meg nem akarom a shadow map meg a scene lerenderelésekor is kiszámolni, ha nem muszáj.
De még ha ezt meg is tenném, akkor se lenne jó, nem? Mert pont az a lényeg, hogy nem az adott pozícióhoz tartozó mélység kell, hanem annak a pontnak a mélysége, ami abban a pontban látszik, ez a POM lényege. Szóval a shadow map textura koordinátáihoz kéne még valami offset is, nem?
|
|
|
|
|
|
Sziasztok, valaki tud megoldást arra, hogy hogyan lehetne parallax occlusion mapping-et és shadow mapping-et együtt használni? Külön-külön működnek rendesen, de ha egy modell árnyékot vet egy olyan modellre, ami POM-ot használ, akkor árnyék az eredeti felületen jelenik meg, nem a benyomott felületen, tehát kb. a benyomott felület felett lebeg. Hogyan lehetne az árnyékot a megfelelő helyre igazítani?
|
|
|
Legutóbb frissített
project:
Maker4D
Friss kép a galériából:
|
