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
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]
Asylum - Törzstag | 5511 hsz       Online status #212384   2019.03.28 10:17 GMT+1 óra  
é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).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #212383   2019.03.26 15:00 GMT+1 óra  
Most találtam, nem tudom ismeritek-e: http://docs.gl/

   
Instalok - Tag | 619 hsz       Online status #212367   2019.02.28 18:13 GMT+1 óra  
Köszi, ezer hála, megnézem!

   
Asylum - Törzstag | 5511 hsz       Online status #212360   2019.02.27 14:14 GMT+1 óra  
Nem tőlem kaptad, néhány héten belül törlöm. Először nézd meg a példakódot, utána ásd bele magad az implementációba.

https://www.dropbox.com/sh/grfukwcqdwfrfb1/AACjKMWLtRXsFmRFO_gbDnmRa?dl=0
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #212348   2019.02.23 09:03 GMT+1 óra  
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.

   
Asylum - Törzstag | 5511 hsz       Online status #212341   2019.02.15 14:01 GMT+1 óra  
Instalok - Tag | 619 hsz       Online status #212339   2019.02.14 10:33 GMT+1 óra  
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.

   
Asylum - Törzstag | 5511 hsz       Online status #212334   2019.02.11 06:46 GMT+1 óra  
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #212333   2019.02.09 12:21 GMT+1 óra  
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...

   
Asylum - Törzstag | 5511 hsz       Online status #212299   2019.01.04 20:12 GMT+1 óra  
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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #212298   2019.01.03 16:32 GMT+1 óra  
Ha jól néztem a kódot, akkor annyi történik, hogy a RenderingCore indí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

   
Instalok - Tag | 619 hsz       Online status #212289   2018.12.29 07:46 GMT+1 óra  
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.

   
Asylum - Törzstag | 5511 hsz       Online status #212288   2018.12.29 06:10 GMT+1 óra  
van egy példaprogim ehhez (egy teljesen hasonlót implementáltam az ArchiCAD-ben is annyi különbséggel, hogy ott be van kapcsolva a context sharing)

https://github.com/asylum2010/Asylum_Tutorials/tree/master/ShaderTutors/51_MultiThreading
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 619 hsz       Online status #212286   2018.12.26 07:59 GMT+1 óra  
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 <--);

   
Asylum - Törzstag | 5511 hsz       Online status #212184   2018.09.25 09:33 GMT+1 óra  
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)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
full3nzo - Tag | 53 hsz       Online status #212183   2018.09.24 10:03 GMT+1 óra  
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, 441 nap)

   
Asylum - Törzstag | 5511 hsz       Online status #212175   2018.09.17 18:55 GMT+1 óra  
Végre elkészült... Bár nem az eddigi legnehezebb munkám, mégis büszke vagyok rá:

https://darthasylum.blog.hu/2018/09/17/ocean_rendering
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
full3nzo - Tag | 53 hsz       Online status #212166   2018.09.03 19:57 GMT+1 óra  
Köszönöm!

   
Asylum - Törzstag | 5511 hsz       Online status #212165   2018.09.03 17:03 GMT+1 óra  
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).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
full3nzo - Tag | 53 hsz       Online status #212164   2018.09.03 09:33 GMT+1 óra  
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...

   
Asylum - Törzstag | 5511 hsz       Online status #212163   2018.09.03 00:34 GMT+1 óra  
Á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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
full3nzo - Tag | 53 hsz       Online status #212161   2018.08.31 19:47 GMT+1 óra  
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, 463 nap)

   
Asylum - Törzstag | 5511 hsz       Online status #211783   2018.01.12 18:22 GMT+1 óra  
teljesen mindegy milyen driver (mindenfajta gpu-n jön), de én intelen nézem.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
versio - Tag | 673 hsz       Online status #211782   2018.01.12 18:16 GMT+1 óra  
amd vagy intel driver?
   
Geri - Törzstag | 2198 hsz       Online status #211781   2018.01.12 17:28 GMT+1 óra  
-----

Ezt a hozzászólást Geri módosította (2018.01.12 17:50 GMT+1 óra, 696 nap)

   
Asylum - Törzstag | 5511 hsz       Online status #211780   2018.01.12 16:37 GMT+1 óra  
Nagyon komoly problémába ütköztem opengl-ben, ha bárki tud segíteni azt nagyon megköszönöm:

https://stackoverflow.com/questions/48226659/opengl-framebuffer-attachments-leak-gpu-memory
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5511 hsz       Online status #211651   2017.11.04 18:18 GMT+1 óra  
Köszi
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2529 hsz       Online status #211650   2017.11.04 13:05 GMT+1 óra  
Kiraktam.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5511 hsz       Online status #211643   2017.10.31 12:05 GMT+1 óra  
Megjelent az új cikkem, amiben részletesen foglalkozok az OpenGL képességeivel (kivéve amikről már írtam külön).

http://darthasylum.blog.hu/2017/10/25/modern_opengl

Ha úgy gondoljátok ti is, akkor szerintem érdemes lenne kitenni a Blogszemlére.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5511 hsz       Online status #211434   2017.06.02 21:19 GMT+1 óra  
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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
racz16 - Tag | 4 hsz       Online status #211430   2017.06.02 16:01 GMT+1 óra  
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?

   
Asylum - Törzstag | 5511 hsz       Online status #211423   2017.06.01 21:28 GMT+1 óra  
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch36_relief.html
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch43_shadowmaps.html

Egyébként baromi egyszerű: a shadow mappinghez mi kell? Egy depth érték, amihez hasonlítasz. De hát azt a POM-ban amúgyis kiszámoltad... Akkor meg mi a probléma?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
racz16 - Tag | 4 hsz       Online status #211421   2017.06.01 18:40 GMT+1 óra  
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?

   
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]