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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
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 | 532 hsz       Online status #209704   2016.06.04 22:30 GMT+1 óra  
Nos, szerintem ez driver bug lehet, mert eddig mindenki másnál működött a dolog.
3257-testapp.zip

   
Instalok - Tag | 532 hsz       Online status #209703   2016.06.03 10:31 GMT+1 óra  
Nem is igazán tudom, hogy ez most WinAPI, vagy OpenGL probléma, de a helyzet a következő:

Működik:
- window size change
- window style and size change

Nem működik:
- window style change

Tehát ha van egy 1280x720-as client area ablakom windowed módban (azaz maga az ablak 1296x758 a keret miatt), majd átváltok borderless módba, szintén 1280x720-as mérettel (nincs keret, szóval maga az ablak is ekkora), tehát a client area nem változik (1280x720), akkor teljesen rossz az egész.

Olyan, mintha az ablaknak lenne egy újrarajzolatlan része, pontosan ott, ahol előtte a caption és border volt. Egyelőre a teszt kedvéért minden frame-ben hívok egy glViewport-ot és egy glClear()-t, hogy biztosan ne ezekkel legyen a gond:
Kód:
glViewport(0,0,1280,720)
glClearColor(1.000000,0.000000,0.000000,1.000000)
glClear(GL_COLOR_BUFFER_BIT)
wglSwapBuffers(FF0117F9)=true

Ha az ablaknak változik a mérete is, akkor működik a dolog. Kell még OpenGL esetén valamivel trükközni, amikor ilyesmit csinálok, vagy ez inkább WinAPI dolog lesz?

szerk.:
Na itt van a dolog, ami nem csinál semmit, így könnyebb megnézni, hogy mi nem jó.
3257-windowstylechange.zip
Stílusváltás F1, F2 billentyűkkel.

Ezt a hozzászólást Instalok módosította (2016.06.03 10:43 GMT+1 óra, 441 nap)

   
Instalok - Tag | 532 hsz       Online status #209636   2016.05.22 08:46 GMT+1 óra  
Hehe, jópofa. Ha a shaderben egy define többször előfordul, akkor nem fog sírni, hogy multiple definition, vagy akármi, hanem simán lefordul. Azt hiszem írok egy saját preprocessort, úgyis kell az include-oláshoz.

   
Instalok - Tag | 532 hsz       Online status #209635   2016.05.21 19:10 GMT+1 óra  
De mondom, hogy kell, használom Olvasom a shaderben, meg használom hardwares tesztekhez. Amit küldtél képet, az már valószínűleg nem aktuális, legalábbis RenderDoc-ban nem láttam olyan esetet, hogy bindolva van a textúra és attacholva is van FBO-hoz, a lenti példát leszámítva. Az viszont jelenleg must have, mert kell. Ha nagyon nem lesz jó sok helyen, akkor jön a depth-copy és használom azt.

   
Asylum - Törzstag | 5441 hsz       Online status #209634   2016.05.21 14:46 GMT+1 óra  
bakker csak unbindold azt a szaros textúrát (akár létrehozol egy dummy 1x1-es feketét és azt használod 0 helyett)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #209633   2016.05.21 11:54 GMT+1 óra  
Igen, kicsit félek tőle én is, hogy úgy általánosságban mi lesz. Hibát nem dob rá, és csak egy bool-t kell átírnom, hogy a depth copyt használja, szóval egyelőre így marad, aztán a gyakorlatban majd kiderül.

   
Asylum - Törzstag | 5441 hsz       Online status #209632   2016.05.21 10:27 GMT+1 óra  
duplatap... ezt a süti bugot nem akarjátok javítani?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5441 hsz       Online status #209631   2016.05.21 10:27 GMT+1 óra  
És gondolod, hogy a drivert ez érdekli? Be van bindolva az fbo, ráhívsz egy drawelements-et, ergó írod. Teljesen jogosan dob invalid operation-t; vagy talán shader elemzést kéne csinálnia, hogy "á, biztos csak vicc".

3.2-től buffer és program nem lehet 0, a textúra az elvileg lehet (gyak viszont a gdebugger beszól).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #209629   2016.05.20 20:42 GMT+1 óra  
Ja, az valószínűleg csak "ott maradt", és mivel OGL 3.1-től nem lehet 0-t bindolni, az úgy is marad. De azokat a shaderben nem használtam, természetesen. Vagy lehet, hogy ott csak valamit elnéztem, megnézem majd én is még egyszer. Minden esetre olyat nem csinálok, hogy olvasok shaderben egy olyan textúrát, amit írok is. Az egyértelműen undefined behaviour a legjobb esetben is.

szerk.:
Átnéztem, most csak az említett depth attachmentes helyen fordul elő a dolog, de akkor sem írom az adott textúrát, csak olvasom a shaderben, és használom a hardware-teszteket.

Kicsit összevagdostam a dolgot, hogy 1 képen legyen:

Ezt a hozzászólást Instalok módosította (2016.05.20 21:13 GMT+1 óra, 455 nap)

   
Asylum - Törzstag | 5441 hsz       Online status #209627   2016.05.20 12:22 GMT+1 óra  
Amit küldtem neked gdebugger kép azon egyértleműen írsz egy olvasásra bebindolt textúrába.

https://www.dropbox.com/s/p9vb50wbpd97rvb/gdebu.png?dl=0
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #209626   2016.05.20 11:15 GMT+1 óra  
Az a baj, hogy renderelek az FBO-ba

Szóval nagyjából így néz ki a dolog:
Kód:
bind FBO#1 ([...] + depthstencil)
draw geometries -> fill depth + stencil

bind FBO#2 ([...] + depthstencil)
disable depth + stencil write
bind depthstencil texture
draw lights with depth and stencil tests

Szóval a gond az, hogy hardveres tesztekhez is kell, hogy ott legyen, meg a fragment shadernek is kell, mert abból számolom vissza a world-space pozíciót. De tulajdonképpen az adott textúrába nem írok, miközben olvasom. A spec. viszont erről pont nem ír rendesen, hogy ilyenkor mi van. De az eddig kipróbált kártyákon működött a dolog (még egy Intel 3000-n is )

   
Asylum - Törzstag | 5441 hsz       Online status #209625   2016.05.20 09:55 GMT+1 óra  
De miért kéne másolatot csinálni...abba az fbo-ba nem renderelhetsz amiből olvasni akarsz, szóval evidens, hogy be kell bindolnod egy másikat. Vagy pedig detacholod arra az időre.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #209624   2016.05.19 14:54 GMT+1 óra  
Idézet
Asylum :
Lehet attacholva meg bindolva is, persze. DE akkor az az fbo ne legyen aktív!


Az a baj, hogy nincs erről egyértelmű leírás, hogy mi van akkor, ha mégis aktív.

Idézet
syam :
Jól látod, csak akkor van gond, ha írsz az attachmentbe. Ez low-level API-kban már szépen látszik.
A cégnél már a legelső deferred pipeline-ban is ezt csináltuk. Bár volt belőle vita, mert a GL spec. nem fogalmazott egyértelműen erről a szituációról (sem)


Igen, pont ezért akadtam itt meg én is. És azért egy blitelést megspórolni egész jó. Oké, még kvázi üres a jelenet, de ebben a formában 100 FPS-t jelent az, hogy nem csinálok a depth-ről egy másolatot.

   
syam - Törzstag | 1491 hsz       Online status #209623   2016.05.19 11:18 GMT+1 óra  
Idézet
Instalok :
Van egy FBO, és egy textúra a depth attachmentre attacholva. Depth write kikapcsolva (glDepthMask). Az FBO bindolva. Majd fogom ugyan azt a textúrát, amit a depth attachmentre attacholtam, bindolom, hogy shaderben tudjam olvasni. Ilyet így szabad? Olvastam a feedback loopról itt, de csak arról ír, hogy, ha módosítom az adatot, akkor van gáz. Eddig ezt elkerültem egy bliteléssel másik textúrába, de az le is zabbant ~50 FPS-t. Logikailag nem látom akadályát, hogy egyszerre legyen bindolva meg attacholva is a textúra, amíg csak olvasok belőle, csak nem tudom, hogy a hardware-ek mennyire szeretik.



Jól látod, csak akkor van gond, ha írsz az attachmentbe. Ez low-level API-kban már szépen látszik.
A cégnél már a legelső deferred pipeline-ban is ezt csináltuk. Bár volt belőle vita, mert a GL spec. nem fogalmazott egyértelműen erről a szituációról (sem)
alias aalberik
   
Asylum - Törzstag | 5441 hsz       Online status #209621   2016.05.19 10:47 GMT+1 óra  
Lehet attacholva meg bindolva is, persze. DE akkor az az fbo ne legyen aktív!
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #209619   2016.05.18 16:30 GMT+1 óra  
Van egy FBO, és egy textúra a depth attachmentre attacholva. Depth write kikapcsolva (glDepthMask). Az FBO bindolva. Majd fogom ugyan azt a textúrát, amit a depth attachmentre attacholtam, bindolom, hogy shaderben tudjam olvasni. Ilyet így szabad? Olvastam a feedback loopról itt, de csak arról ír, hogy, ha módosítom az adatot, akkor van gáz. Eddig ezt elkerültem egy bliteléssel másik textúrába, de az le is zabbant ~50 FPS-t. Logikailag nem látom akadályát, hogy egyszerre legyen bindolva meg attacholva is a textúra, amíg csak olvasok belőle, csak nem tudom, hogy a hardware-ek mennyire szeretik.

   
Asylum - Törzstag | 5441 hsz       Online status #209611   2016.05.18 09:36 GMT+1 óra  
ARB_debug_output-ot még megpróbálhatod....
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #209608   2016.05.17 18:25 GMT+1 óra  
Azt hiszem lemondok a lentebbi hibának az elhárításáról. Igazából csak ott nem működik, és a lebuildelt Unity-s (OGL targetre beállítva) projekt is elreccsen induláskor, szóval betudom driver bugnak. Remélem tényleg az. Már kismilliószor átnéztem a kódot, és nem csinálok semmi rendkívülit.

   
Instalok - Tag | 532 hsz       Online status #209599   2016.05.17 10:19 GMT+1 óra  
Hm, ha van egy FBO-m 3 color attachmenttel (legyen most tex0, tex1, tex2), akkor mielőtt az FBO-ba rajzolok, meg kell győződnöm róla, hogy ezek nincsenek bindolva? Azt olvastam, hogy undefined behaviour ez az eset.

Mivel úgy néz ki a rajzolás, hogy:
Kód:
bind FBO_1
render geometries

bind FBO_2
bind FBO_1_textures
render lighting

ezért a következő frame-ben az FBO_1 textúrái bindolva lesznek.

szerk.:
A lentebbire visszatérve, a specifikáció szerint nem lenne muszáj depth és stencil buffert használni a backbuffernél. Nálam mégis hibát dob, ha nincs depth és stencil bit depth beállítva a context létrehozásakor.
OpenGL 2.0 specification
Further, an implementation or context may not provide depth, stencil, or accumulation buffers.

Ezt a hozzászólást Instalok módosította (2016.05.17 13:01 GMT+1 óra, 458 nap)

   
Geri - Törzstag | 2186 hsz       Online status #209596   2016.05.14 14:23 GMT+1 óra  
hát ha nem hozol létre stencil buffert, akkor elég nehezen írod. ha létrehozol, meg lefoglalódik neki a memória, meg fut vele kapcsolatban jónéhány algó feleslegesen, ami hát nem épp sebességnövelő tényező, bár manapság nem hiszem, hogy sokat lassítana, hisz arra vannak optimizálva a driverek, hogy úgyse használja semmi már 15 éve

   
Instalok - Tag | 532 hsz       Online status #209593   2016.05.13 21:03 GMT+1 óra  
Hát, azért nem irreleváns, mert meg tudom mondani, hogy írjam-e azt a stencilt, vagy sem. Csak ezt kétféleképpen is el lehet érni, lehet, hogy beállítom azt is, hogy GL_KEEP meg glStencilMask(0), és akkor tuti a hatás.

   
Geri - Törzstag | 2186 hsz       Online status #209592   2016.05.13 20:11 GMT+1 óra  
framebuffer/fbo létrehozásakor el tudod dönteni, hogy lesz -e stencil buffered, vagy sem. onnantól minden beállítgatás irreleváns.

   
Instalok - Tag | 532 hsz       Online status #209591   2016.05.13 19:18 GMT+1 óra  
A stencil írásának kikapcsolásához amúgy elég a glStencilMask(0)? Vagy érdemes átállítani mindet KEEP-re? A stencil mask ugye csak azt mondja meg, hogy mely biteket írja (tehát effektíve a 0-val nem fog írni semmit), viszont lehet, h megpróbál. Ha meg KEEP-re állítom mindet, akkor meg sem próbál írni, nem?

Továbbá van-e jelentősége annak, hogy a state állításokat az FBO bind előtt vagy után teszem meg? Gondolom nem nagyon, mert ezek a state-ek (depth test, stencil test, stb.) globálisak.

   
Instalok - Tag | 532 hsz       Online status #209588   2016.05.13 07:40 GMT+1 óra  
Mondjuk furcsa, mert a dokumentáció szerint lehet a depthBits értéke 0. Sőt, ha lekérem az összes elérhető pixel formatot, akkor azok között van olyan, ahol 0. De mindegy végülis, így hagyom, csak soha nem használom.

Megpróbálom majd megszerezni a laptopot, ha megvan a hiba forrása, leírom.

   
Geri - Törzstag | 2186 hsz       Online status #209586   2016.05.13 00:21 GMT+1 óra  
,,Ezek szerint kötelező a contexthez depth és stencil buffert társítani?''

depthet valszeg kell, stencilt meg minek

   
Instalok - Tag | 532 hsz       Online status #209585   2016.05.12 23:35 GMT+1 óra  
Sikerült szűkítenem a problémán, pontosabban valahogy előhoztam nálam is. Vagyis csak félig. Szóval a lényeg, hogy nálam is megjelent egy error.

Az egész rendering jelenleg úgy néz ki, hogy
Kód:
* bind FBO#1 (color 0, 1, 2, depthstencil attachmentek)
* draw geometries
* bind FBO#2 (color 0 attachment csak)
* draw fullscreen quad
* bind backbuffer
* draw fullscreen quad

Na most nálam elkezdte azt csinálni, hogy az utolsó lépésnél a glDrawElements elkezdett GL_INVALID_OPERATION hibát dobni. Persze ettől függetlenül nálam még jó volt a renderelés, szóval gondolom a driverem lenyelte a békát.

No igen, kerestem egy ideig a hibát, és azt vettem észre, hogy amikor létrehoztam a contextet, nem adtam meg, hogy hány bites legyen a depth és a stencil buffer. Úgy gondoltam, hogy, ha nem akarom, hogy a contexthez tartozzon depth+stencil, akkor maradhat 0 biten. Amint kijavítottam 24+8-ra, eltűnt a hiba.

Ezek szerint kötelező a contexthez depth és stencil buffert társítani?

szerk.:
Bár a korábbi tesztekből az látszott, hogy az 1. "draw fullscreen quad" passnál dobta nála a hibákat, de sose lehet tudni, lehet, hogy innen gyökerezik a probléma. Megpróbálom majd rávenni, hogy jöjjön át, megosztom a build dirt hálózaton, és akkor tudok szinte realtime tesztelni.

   
Instalok - Tag | 532 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 | 532 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 | 2186 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 | 5441 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 | 2186 hsz       Online status #209577   2016.05.11 22:13 GMT+1 óra  
elmélet vs valóság

   
Instalok - Tag | 532 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 | 2186 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 | 5441 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 | 532 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 | 5441 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 | 532 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 | 532 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 | 5441 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 | 532 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 | 5441 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 | 532 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 | 5441 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, 467 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 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 | 5441 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 | 532 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 | 5441 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 | 532 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 | 5441 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
   
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]