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

Megjelent a GS BIMx új verziója mobil kütyükre

2013.03.22. 15:51 | darthasylum | Szólj hozzá!

Hosszas gyűrkőzés után a BIMx egy teljesen új grafikus engine-t kapott; az eredmény 3-5x ös gyorsulás mobil kütyükön. Amit a 3D vágás effektíve vissza is ront a pixel shaderben történő discard miatt (francnak kellett kivenni a user clip plane-t...), de még mindig élvezhető sebességgel fut nagy modelleken is. Az eddigi legnagyobb modell amit az új engine megzabált 3.2 millió poligon egy iPad 3-on (8-14 fps vágás nélkül).

Ingyenesen letölthető az App Store-ból (iOS) és a Google Play-ről (Android). Részletek itt. Modellek letölthetők a community site-ról.

bimx1.jpg
Vennesla bibliothek (160k polygon)

Pack file refaktoring

2013.03.02. 12:19 | darthasylum | Szólj hozzá!

Amióta létezik a packfile, azóta az engine minden content betöltési requestet képes abba irányítani (egy külön build configgal). Ha megtalálta a pack-ban, akkor onnan szedi be, ha nem találta meg, akkor megkeresi a megadott search directoryban és hozzáadja.

A probléma a következő: egy adott pathon elérhető effekt fájl beinkludál egy headert. Majd egy másik folderben levő effekt szintén, de más relatív hivatkozással:

#include "../alma.h"
#include "../../alma.h"

Eddig ez kétszer került volna be a packba, ami kicsit pazarlás. Az egyik feladat a packfile specifikációját lerögzíteni, a másik pedig az inkludok kigyűjtése és megfelelő elhelyezése.

A packfile-t a következőképpen módosítottam (valójában csak a formális paraméterek neve változott meg).

bool Add(const qstring& filepath, const qstring& packpath);

Tehát az első paraméter a fájl amit hozzá akarsz adni, a második pedig a célpath a packban. Ha a célpath már létezik, nem írja felül, de ha más helyre rakod, akkor még lehet duplikálva (de ez így jó).

A másik feladat a content managert érinti. A SearchDirectory member megfelel a pack file gyökerének, tehát ha egy betöltési kérelem jön, akkor ehhez relatívan keresi a fájlt, és az ettől való relatív elérési út lesz a pack-beli path. Ha a search directory-n kívülre történik hivatkozás, az hiba (de csak warningot dob).

A #include-okat először is ki kell gyűjteni. Ezt tudni kell akkor is, ha fájlból töltöd be, de akkor is ha memóriából. Az előfordító ezt vidáman meg tudja csinálni, egy fájlra. Tudhatná többre is, de akkor folyamatosan callback-eznie kéne, hogy lekérje az éppen aktuális fájlt a packból. A rekurzió ezért inkább a content managerben van.

Az inkludolt fájl pack-beli elérési útját úgy lehet kiszámolni, hogy kombinálod a szülő path-ját és az include relatív path-ját.

qEngineHelper::GetPath(str, parentfile);
qEngineHelper::ResolvePath(str, str + rel_include_path);

A parentfile itt már eleve relatív (a search directoryhoz). A pack természetesen tömörít is (ahogy eddig).

Quadron FX shader fordító

2013.02.15. 13:09 | darthasylum | Szólj hozzá!

Az utóbbi időben felmerült az igény arra, hogy az engineben használt shadereket valahogy rendszerezzem, ugyanis legalább két nyelven meg volt írva mindegyik (némelyik még mobilra is). Ez így kezelhetetlen ha sok shaderről van szó, ráadásul az újrafelhasználást is nehéz megoldani mert sok GLSL compiler nem tud pl. #include-ot...

Első gondolatom a CG volt, de az sokszor túlságosan megengedő, illetve vannak olyan dolgok (pl. struct) amit egyes androidos tabletek nem tudnak lefordítani. Akadályokat meg nem akarok magam elé állítani, mert naponta tapasztalom a hátrányait...

Ezért a scriptes tutoriálban ismertetett fordítót kezdtem el átalakítani/bővíteni. A különbség lényeges, mert nem assemblyre fordítom a kódot, hanem egy másik magas szintű nyelvre. Amíg a fogalmak nagyjából ekvivalensek, addig nincs is különösebb gond. Például a HLSL-es szemantika megfeleltethető a GLSL-es attribútumoknak.

OpenCL: jobb vagy rosszabb?

2013.01.05. 20:48 | darthasylum | 1 komment

Kísérletképpen megcsináltam a causticot OpenCL-el is, mert gondoltam hogy ez majd milyen jó lesz és talán lehetőséget ad olyan adaptív finomításra, mint amit geometry shaderrel csinált meg Wyman.

Először is: a használata baromira fapados, dehát ezt az ilyen OpenXX cuccoktól már megszokhattam volna. Nincs egyértelműen definiálva, hogy mit lehet átadni egy adott kernelnek, tipikusan minden bizbaszhoz memory objectet kell csinálni. Az se mindegy, hogy kernel argumentumnak mit adsz meg, például struktúrákkal baromira nem tud mit kezdeni (gondolok itt a vertex adatra). Konstansként működnek a structok is.

Egy kicsit a koncepcióról. Egy OpenCL képes eszköznek van n db compute unit-ja, ami alatt egy sokmagos processzort kell érteni. Pl. az én videókártyámnak van 16 db 8 magos procija. Tipikusan azt szeretnéd, hogy egy compute uniton több száz kernel példány fusson egyszerre, mert akkor használja ki megfelelően. Persze ez függ attól, hogy milyen kernelről van szó, és itt a legnagyobb probléma. OpenCL oldalon ugyanis a compute unitokra nincs egyértelmű leképezés.

Két fogalom van, amivel szabályozni lehet a teljesítményt: az egyik a global worksize, ami gyakorlatilag a munkaterület elemeinek számát kell, hogy megmondja (pl. egy 512x512-es kép feldolgozásához 512x512). Persze lehet kisebb, de akkor értelemszerűen többször kell lefuttatni a programot. Ez pongyolán mondva ennyi darab work item-et jelent (kernel példányt). A globális terület fel lesz osztva work group-okra, de egy ilyen csoport nem teljes egészében fed le egy compute unit-ot (és ez baj...). A másik logikai csoport így nyilván a local worksize, ami azt mondja meg, hogy egy csoport hány work itemet fog össze.

A probléma még nem lenne akkora, mert a compute unitok számát el lehet kérni. Azt viszont, hogy egy compute unitnak hány végrehajtási egysége van, azt már marhára nem, és nekem ezen a ponton halt meg az egész koncepció. Pontosabban ott, hogy a shaderes megoldás kenterbe veri az OpenCL-est (pedig sokféle variációt kipróbáltam). A másik dolog ami baromira zavart, hogy ez csak és kizárólag párhuzamos programozási problémákra használható, és szekvenciális outputot az életbe nem tud magából kiszenvedni (pedig pont ez kéne, mert geometry shaderrel ezt meg lehet csinálni).

Szóval senki ne rohanjon OpenCL-t tanulni, ez még nagyon messze áll a general purpose-től...

Real-time caustics

2012.11.03. 12:38 | darthasylum | 1 komment

A fotonok nyomonkövetése még viszonylag egyszerű (bár elég sok béna megközelítés van; végülis a Newton-Rhapson gyökkeresési módszer bizonyult a legegyszerűbbnek), viszont mivel sok foton ugyanabba a texelbe csapódik bele, a caustic mapben zaj keletkezik (ott ahova nem csapódott be semmi). Na ennek az eltüntetése viszont kínszenvedés...egyelőre nincs is semmi épkézláb ötletem (a létező megoldások meg vagy rondák vagy lassúak, vagy nvidia-only extensiönöket használnak).

caust2.jpg

Azon filózom, hogy vajon meg lehet-e fordítani a dolgot, és explicit lerenderelni a causticot. Valószínüleg nem, mivel ez a bizonyos függvény nem invertálható...

Mozgás közben nagyon jól néz ki (videó).

Címkék: directx graphics 3D caustics

süti beállítások módosítása