játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5478
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
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 | 5478 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 | 602 hsz       Online status #212383   2019.03.26 15:00 GMT+1 óra  
Most találtam, nem tudom ismeritek-e: http://docs.gl/

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

   
Asylum - Törzstag | 5478 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 | 602 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 | 5478 hsz       Online status #212341   2019.02.15 14:01 GMT+1 óra  
Instalok - Tag | 602 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 | 5478 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 | 602 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 | 5478 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 | 602 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 | 602 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 | 5478 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 | 602 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 | 5478 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 | 48 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, 209 nap)

   
Asylum - Törzstag | 5478 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 | 48 hsz       Online status #212166   2018.09.03 19:57 GMT+1 óra  
Köszönöm!

   
Asylum - Törzstag | 5478 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 | 48 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 | 5478 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 | 48 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, 231 nap)

   
Asylum - Törzstag | 5478 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 | 2195 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, 464 nap)

   
Asylum - Törzstag | 5478 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 | 5478 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ő | 2526 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 | 5478 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 | 5478 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 | 5478 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?

   
Lord_Crusare - Törzstag | 1312 hsz       Online status #211187   2017.04.13 10:28 GMT+1 óra  
Ja oké, valamiért nem jutott eszembe jobbra görgetni

   
Asylum - Törzstag | 5478 hsz       Online status #211186   2017.04.13 10:24 GMT+1 óra  
Idézet
Lord_Crusare :
A cikk végén a két kép a randomizálás/rekonstrukcióról nálam ugyanarra az egy képre mutat.



Ami két kép egymás mellett (könnyebb összehasonlítani).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Lord_Crusare - Törzstag | 1312 hsz       Online status #211185   2017.04.13 09:46 GMT+1 óra  
Idézet
Asylum :
Kiraktam a GTAO cikket:

http://darthasylum.blog.hu/2017/04/12/ambient_occlusion



A cikk végén a két kép a randomizálás/rekonstrukcióról nálam ugyanarra az egy képre mutat.

   
Asylum - Törzstag | 5478 hsz       Online status #211184   2017.04.12 21:59 GMT+1 óra  
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #210939   2017.02.04 07:06 GMT+1 óra  
Én azért használom, mert elmászna a beállított dir fény. Abból is csak egyet. De pl ha az ambient mondjuk lilás, a diffuse meg fehér, akkor az átmeneten szépen látszik is, meg az ambient nem szól bele a diffuse-ba, mert ugye a max miatt csak addig érvényesülnek a színek (egyesével), míg a diffuse fölé nem megy. Ha hozzá adjuk, akkor mindig lilásra színezi, és nem a hátoldalra fisszapattanó fényt "szimulálja".
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5478 hsz       Online status #210937   2017.02.03 22:51 GMT+1 óra  
Ez is leírja, hogy mivel lusta disznó tone mappelni inkább a [0, 1]-be skálázza. Egyébként jó nagy baromságot ír, szóval ha ez új cikk, akkor egyes.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #210935   2017.02.03 19:16 GMT+1 óra  
Megkeresem, mert "új"abb shaderről van szó, nem annyira régiről.

Mivel ambient, a directional fényről van szó konkrétan.

http://www.lighthouse3d.com/tutorials/glsl-tutorial/directional-lights/

(bár pontfényhez is ezt írják)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5478 hsz       Online status #210934   2017.02.03 19:12 GMT+1 óra  
Ezt _azért_ alkalmazták annakidején mert nem volt még hardveres sRGB support (a pow pedig baromi drága volt). De ez csak egy része a megoldásnak, mert amint additív blendinget használsz elkerülhetetlen a _tone mapping_ is.

De ilyen max sosem volt. Az ambient + ndotl*diff-et skálázták be a [0, 1] intervallumba.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #210933   2017.02.03 19:07 GMT+1 óra  
Jó, én hagyományos fénykezelésben gondolkodtam, a gtao meg ezek szerint PBR-es. Az viszont, hogy a fény mindig additív, csak részben igaz, mert hagyományosban a "szebb" az az, amit már említettem.

teljesen kiírva
Kód:
finalcolor=max(ambient*color, diffuse*color+specular);


itt az ambient az ambientek összege, már ha több lenne vhogy, a diffuse meg a diffuse-ok összege és a specular a specularok összege. a color a textúra példa kedvéért.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5478 hsz       Online status #210931   2017.02.03 18:34 GMT+1 óra  
Te abszolút nem vagy tisztában a PBR-el (olvasd el a cikkemet...). A fények _mindig_ additívek.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #210929   2017.02.02 20:58 GMT+1 óra  
Az ambient color minimum color, nem additív a fényhez. ezért a kettő közül a max érvényesül. Legalábbis úgy a szebb, meg a szín tartomány túlzottan fel menne.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5478 hsz       Online status #210923   2017.02.02 18:51 GMT+1 óra  
?????

Kód:
outColor = ambient * ao + color / pi * dot(n, l);
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #210916   2017.02.02 13:32 GMT+1 óra  
Ja hogy ja. Akkor ezt
Kód:
max(AO*color, color*diffuse)

-nál kell használni? ... Meg úgy általában az ssao-t is?
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5478 hsz       Online status #210914   2017.02.02 12:50 GMT+1 óra  
1) árnyékolt textúra a PBR óta TILOS
2) a lightmap az csak far field occlusion, a GTAO akkor is segít (vagy nem is kell)
3) direkt megvilágításba TILOS AO-t rakni (csakis az ambiens fénybe)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #210911   2017.02.02 11:45 GMT+1 óra  
Igen, a közeli függönyökön szépen mutat, de jobb helyeken a függöny textúrája tartalmazná az árnyékot, vagy éppen hagyományos fényekkel és monokróm textúrákkal sem lenne ekkora különbség.
Általános jelenetekben árnyékolt textúrákat alkalmaznak és lightmapet.

De azért szépen működik.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Asylum - Törzstag | 5478 hsz       Online status #210910   2017.02.02 11:12 GMT+1 óra  
Itt egy összehasonlító kép (GTAO). Annyit megjegyeznék, hogy a Sponza pont rossz ehhez, mert pre-bakelt AO-t tartalmaz sok helyen (pl. oroszlán).

C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5478 hsz       Online status #210900   2017.02.01 20:22 GMT+1 óra  
...

A gauss blur szeparálható (külön x, külön y).
A képlet pedig ott van wikipédián (normal distribution).

De a blogomon is: http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch39_hdr.html
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
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]