Leírás

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Stuff

Anything related to game development.

Contact: darthasylum at gmail dot com

Nemlineáris cikkek

Mi ezeknek a célja?

Leginkább az, hogy magyarul is elérhető legyen programozási anyag, olvasmányos formában.

A cikkek kódja GitHub-ról is elérhető. (*)-al jelölöm azt a cikket ami nemrégiben frissült.

A színek a nehézséget próbálják jelezni, de az, hogy egy cikk piros nem azt jelenti, hogy csak a profiknak szól!

 

 

 

 

 

 

 

 

Hörcsög

The Asylum

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Friss topikok

Címkék

HTML

Utolsó kommentek:

darthasylum 2017.02.08. 16:46:11

@nexor: ilyen nincs, hogy "kiszámolom". Ez algoritmusfüggő. Például egy sima Gauss blurnál is végig kell gondolni, hogy milyen messze is szeretnék mintavételezni? Az AMD-nek van ehhez kapcsolódóan prezentációja (megemlítettem a cikk alján), de a lényeg az, hogy a feladattól függ, hogy mekkora lesz egy workgroup.

Bejegyzés: OpenGL compute shaderek

nexor 2016.11.02. 13:34:48

@darthasylum: Na erre sem találtam semmit. Hogyan kell kiszámolni a work group méretét? FullHD (1920*1080) képeket használok, kernel műveleteket is szándékozom használni: blur, edge detection, ilyesmik.

Bejegyzés: OpenGL compute shaderek

darthasylum 2016.11.02. 13:32:10

@nexor: shader debugoláshoz szinte semmi eszköz nincs GL-hez. Tippre rosszul számolod ki a workgroup méretét vagy a shader túlírja a céltextúrát.

Ha gondolod akkor ránézek a kódódra (email: darthasylum@gmail.com)

Bejegyzés: OpenGL compute shaderek

nexor 2016.11.02. 13:27:58

Én képfeldolgozásra próbálom használni a compute shader-t, eddig sajnos kevés sikerrel. Már stackoverflow-n is kérdezgettem, de nem sikerült megoldást találnom. A példakódodból sem derült ki számomra, hogy mit ronthatok el. OpenCV-s Mat-okat alakítok át OpenGL-es textúrákká, majd ezeket használom a shaderben a képfeldolgozásra (egyelőre egy sima színinvertáláson is elhasal), majd vissza cv::Mat-ba. A kimeneti képen az első (bal felső) pixel-t van, hogy nem írja, de más problémák is vannak. Van erre bármilyen trükk, hogy az OpenGL állapotát ellenőrizzem?
Köszönöm előre is!

Bejegyzés: OpenGL compute shaderek

Gerilgfx 2014.09.02. 13:32:32

@darthasylum: egyszerűbb lesz kicserélni a marketingeseket.

Bejegyzés: OpenGL compute shaderek

darthasylum 2014.09.02. 11:16:25

@Gerilgfx: csak a marketingeseknek kell elmagyarázni...szerintük ugyanis többen veszik a szoftvert, ha a user számára érthetetlen fogalmakat lehet leírni a feature listára.

Bejegyzés: OpenGL compute shaderek

Gerilgfx 2014.09.02. 03:47:49

mostanra én azt a filozófiát követem, mely szerint az olyan képességeket, amelyek kiszámítható, konzisztens működése nem garantálható, tilos implementálni.

Bejegyzés: OpenGL compute shaderek

Gerilgfx 2013.05.02. 16:53:34

én az animhoz nem használtam semmi ilyesmit, de nem volt belőle gond

Bejegyzés: Fixed time step refactoring

darthasylum 2013.05.01. 01:26:12

De aztán írtam, hogy az speciel független (bár az approximáció miatt más eredményt ad, de az nem érdekes). Eddig más dolgok gyorsabbak lettek (pl. GUI), most viszont azok is rendesen skálázódnak.

És de, kell az máshoz is, pl. a skeletal animation 24 fps-hez tartalmazza a frame infókat, ezek között viszont interpolálni kell (nem is feltétlenül lineárisan, hanem akár Hermite interpolációval).

Bejegyzés: Fixed time step refactoring

Gerilgfx 2013.04.30. 00:18:50

igen, a fizikához, de ez volt az alapfelvetésed. máshoz ilyesmi lényegében nem is igazán kell.

Bejegyzés: Fixed time step refactoring

darthasylum 2013.04.27. 16:20:02

Amit te mondasz, az a fizikához kapcsolódó dolog; a fix idököz a stabilitás miatt kell, a render közbeni interpoláció pedig a temporal aliasing miatt.

A jelenlegi fizika algebrai úton számolja ki az ütközést, tehát sosem tud átmenni a falon (így nincs szükség ilyen közbenső lépésekre). Persze ez valószínűleg nem mindig lesz megoldható.

Bejegyzés: Fixed time step refactoring

Gerilgfx 2013.04.27. 01:38:39

én a régi engineben erre frameskipet használtam, az új engineben a fizikai kód tudni fogja a testek régi és új helye közötti interpolálását, amit alapul véve több fázist tud ütköztetni, elkerülendő, hogy az objektum átessen a falon pl. ez még viszont nincs kész, tehát majd csak ha már megírtam, tudok beszámolni arról, hogy a gyakorlatban mennyire hatékony.

Bejegyzés: Fixed time step refactoring

darthasylum 2013.02.14. 22:17:40

Az elsö N tutoriál át lett fogalmazva (nem azonnal frissül sajnos), a kód javitva lett.

Bejegyzés: Tutoriálokkal kapcsolatos megjegyzések

Gerilgfx 2013.01.29. 02:26:42

egész jól néz ki

Bejegyzés: Real-time caustics

darthasylum 2013.01.23. 23:32:26

Elkezdtem átköltöztetni a dolgokat. Amint befejeztem töröltetem az eltés honlapot.

Bejegyzés: Tutoriálokkal kapcsolatos megjegyzések

darthasylum 2013.01.11. 00:59:41

Mivel nem tudom frissíteni a tutoriálokat, ezért minden hülyeség bent marad. Ami a legjobban piszkálja a csőrömet, hogy a rendezett tömb sablon baromira nem biztonságosan van megcsinálva. Persze a célja csak az volt, hogy példát adjon, de attól még nem kéne baromságnak lenni ott. A lényeg, hogy memcpy-t és memmove-ot tilos használni (majd kifejtem valamikor, hogy miért).

Bejegyzés: Tutoriálokkal kapcsolatos megjegyzések
süti beállítások módosítása