gondolataim elsősorban játékfejlesztésről

Mindkét extension működése hasonló lévén ugyanarra az alapelvre épülnek.
A texture environment után és a köd számítás elé egy új lépés került, amely alapesetben le van tiltva. Ez a lépés egy másodlagos szín (secondary color) hozzáadását jelenti a fragment addig kiszámolt színéhez.
A különbség a két extension között nagyrészt nagyrészt az, hogy ez a szín honnan származik.

GL_EXT_separate_specular_color

Sok driver még ismeri ezt az extension-t azonban már nagyon visszaszorult a használata mivel a fixed-function pipeline-t egészítette ki. A registry-ben 1997-es évszámmal szerepel.
Működése:
Amennyiben engedélyezve van az árnyalás és ez a fajta spekuláris szín számítás, akkor a vertex oldali árnyalási egyenletből kimarad a spekuláris szín hozzáadása. Ehelyett az egy külön regiszterben fragment oldalra átkerül és a már említett lépésben hat a fragment színére.

GL_EXT_secondary_color

1999-re datált extension. Amennyiben ezt használni szeretnénk engedélyeznünk kell a fentebb említett lépést (color sum). Ezután már csak át kell adnunk a színt (megkötés, hogy csak RGB formában adhatjuk meg) a renderelésnek és az a külön regiszterében átkerül a raszterizáláshoz. Sajnos ezt a színt a texture environment nem tudja elérni.

Történeti jelentősége az, hogy mindmáig megmaradt ez a regiszter és a programmable pipeline-ban tetszőlegesen felhasználható (négykomponensűként).

Első vendégíróm első posztja a blogomon Gerié aki egy régi ATI extenion-ről írt egy rövid összefoglalót. Köszönet érte^^

A GL_ATI_pn_triangles lényegében egy nagyon primitív fixed-function geometry shader volt 2001 után, amikor a Radeon 8500 széria megjelent. Mivel az ATi levédette, csak az ő kártyái támogatták, sok korabeli játék ezért egyáltalán nem volt képes kihasználni. Volt pár nevesebb játék, ami igen, ilyen volt például az Unreal Tournament egyik verziója, illetve volt pár scene demó ami képes az extensiont kihasználni, de mivel mára már az ATi extension-jai nem támogatják, kihaltnak tekinthető. Ráadásul csak a 8500 széria támogatta hardverből, a későbbi Radeonokon emulált volt, ezért ha VBO-kal együtt volt használva, az egészből intermediate renderelés lett.

A funkcionalitása lényegében egy mesh smooth-nak felel meg, az iterációk száma pedig
kézzel állítgatható.

glPNTrianglesiATI(GL_PN_TRIANGLES_TESSELATION_LEVEL_ATI, tflevel);
glPNTrianglesiATI(GL_PN_TRIANGLES_NORMAL_MODE_ATI, GL_PN_TRIANGLES_POINT_MODE_CUBIC_ATI);

glPNTrianglesiATI(GL_PN_TRIANGLES_POINT_MODE_ATI, GL_PN_TRIANGLES_NORMAL_MODE_QUADRATIC_ATI);

Használata mindösszesen ennyi, többféle módon is el tudja látni a feladatát, mint a fenti példából is látszik, használata nagyon könnyű volt, és a smooth-t a normálok alapján végzi el. Szerintem a példában leírt paraméterekkel adta a legszebb képet.

GL_HP_occlusion_test

Úgy látszik az occlusion query (hogy konkrétan mi is ez lásd lap alján) első implementálása nem az nVidia nevéhez, hanem a Hewlett-Packardhoz fűződik.
A registry-ben nem szerepel hozzá évszám (és ráadásul preliminary-ként van bejegyezve), de kb. a 2000 év körül jelenhetett meg (én még találkoztam vele).

A megjelenése óta (és a cikk írásának idejében) három leszármazottja készült el:
GL_NV_occlusion_query, GL_ARB_occlusion_query és GL_ARB_occlusion_query2.

Alapvetően eltér azonban a többiektől az alábbiakban:

• Csak azt képes megmondani, hogy a renderelt primitívek fragmentjei közül átment-e legalább egy a depth test-en vagy sem (vagyis egy boolean a végeredmény).
• A GPU egyszerre csak egy tesztet tud futtatni. Ahhoz, hogy egy következő tesztet lehessen kezdeni meg kell várni az előző mérés végét.
• Szinkronizálja a CPU-GPU kommunikációt.

Ezek után érthető miért nem terjedt el.

Megjegyzés:

A GL_ARB_occlusion_query2 extension annyiban hasonlít ehhez, hogy szintén annyit mond meg a renderelt primitívekről, hogy a mélység teszten átment-e belőlük legalább egy fragment. Valószínűleg az első átjutott fragment után leállítja a számolást vagyis nem kell megvárni a renderelés végét. Emiatt jelenleg ez a leggyorsabb hardveres occlusion query.

Röviden mi is az occlusion query.
A GPU képes számolni, hogy mennyi fragment megy át a depth test-en. Ezt jobbára láthatósági vizsgálathoz használják - ha akad legalább egy fragment ami átmegy a depth test-en akkor azt már láthatónak tekinthetjük.

GL_EXT_cmyka

Egy - a kijelzőkön speciálisnak számító - színformátum; elsősorban nyomtatásban használatos. Játékos körökben (valószínűleg) elenyésző azon emberek száma, akik bármikor is találkoztak volna ezzel. A registry-ben 1997-es dátummal szerepel. Érdekesség azonban, hogy -mint látható- a CMYKA formátum ötkomponensű. Hogy ezt hogy tárolják négy byte-on arra a dokumentáció is csak "black-box"-ként utal. Mindenesetre teljeskörű (pack, unpack és histogram) támogatást kapott és konverziók csak host<->client adatmozgatáskor zajlanak.

Szeretnék indítani egy sorozatot, amelyben összegyűjtenék régen (vagy talán soha) nem használt extension-öket. Íme az első:

GL_EXT_clip_volume_hint

Nevéből látható, hogy egy hint-ről van szó. 1996-os dátummal szerepel a registry-ben.

Az OpenGL amennyiben szükséges megvágja a primitíveket a látótér (esetleg a felhasználó által megadott) síkjával/síkjaival. Természetesen ennek szűrése (különösen a kezdeti időkben lásd 1996) körülményes, de sok esetben elkerülhető lépés hiszen ha biztosan tudjuk, hogy egy primitív biztosan és egészében a látótér belsejében helyezkedik el akkor szükségtelen a vágás szükségességének vizsgálata.

Ez az extension azt teszi lehetővé, hogy ezt a vizsgálatot kiiktassuk vagyis sosem fog vágás történni. Ha mégis kilóg, akkor az eredmény (szokás szerint) "undefined"...

Körülbelül a 3D renderelés gondolatával együtt születhetett meg a kérdés, hogy hogyan lehet elfedni/megtalálni (és esetleg kihagyni a számításokból) a nem látható háromszögeket egy adott jelenetből ill. hogyan lehet megtalálni a láthatóakat (hidden surface determination, visibility determination).

Természetesen rengeteg megoldás született ezen kérdés megválaszolására. Legtöbbjük a vertex szintű feldolgozás előtt (VSZFE) eldobja a háromszögeket azonban akad olyan is, amely vertex feldolgozás után (VSZFU) avagy fragment szinten (FSZF) végzi eldobást.

Face culling

Ez a legegyszerűbb esete az eldobásnak. VSZFU típusú vagyis (általában) hardver végzi és csak fillrate-t lehet megtakarítani. A háromszög orientációját alapul véve dobja el azt-hagyományos esetben ez back face cullingot jelent.

Z-buffer és depth test

Ez hardverekben történő megjelenésekor igen nagy újításnak számított. FSZF típusú. Lényege, hogy a fragment generálásakor képződő mélységértéket is figyelembe vesszük rendereléskor. Ehhez szükséges egy mélység buffer, amely minden egyes pixelhez eltárol egy mélységértéket is.

Rendereléskor a bejövő fragment mélysége összehasonlításra kerül a mélység buffer azon értékével, amely a fragmentnek megfelelő helyről származik és csak azon fragmentek kerülnek kirajzolásra (vagyis a szín és mélység tárolására), amelyekre igaz lett az összehasonlítás eredménye. A mélységérték és mélységbuffer precizitásától függően ez az összehasonlítás vezethet z-fightinghoz.

Ezzel az eljárással elérhetjük azt, hogy a közelebbi fragmentek kitakarják a távoliabbakat a háromszögek renderelési sorrendjétől függetlenül.

A most következő megoldások mindegyike VSZFE típusú vagyis ezek az igazán alkalmasak nagy terek valósidejű rendereléséhez. Ezen eljárásokkal kiválogatott háromszögeket már cpu oldalon eldobjuk.

View-frustum culling

Az általános működési elve: a látótérből kieső háromszögeket eldobjuk. Önmagában csak kisebb jelenetekre alkalmazható megoldás. Ennek hierarchizált térfelosztással kombinált esete a

Hierarchical view-frustum culling

Ennek feltétele (vagy legalábbis a hatékonyság miatt igencsak ajánlott) egy olyan térfelosztó hierarchia, amelyben az elemek nem fedik át egymást. Ez biztosítja azt, hogy ha egy elem teljes mértékben látható akkor az összes gyermeke is ill. fordítva. Ha egy elem teljesen kiesik a látótérből akkor az összes gyermeke is.

Occlusion culling

A view-frustum culling ellentétének is tekinthető abból a szempontból, hogy ilyenkor nem a látható, hanem a kitakart háromszögeket keresünk. Feltételezi, hogy ki tudjunk választani olyan háromszögeket/felületeket (occluder), amelyek biztosan kitakarják a mögöttük lévő teret. Minden egyes olyan háromszög, amely biztosan ebben a térben helyezkedik el eldobható. Tetszőlegesen kombinálható mindkét view-frustum culling-gal.

PVS

A rövidítés a potentially visible set-ből származik. Feltételez egy olyan térfelosztó módszert, amely egyértelműen körülhatároló részekre darabolja a teret. Később ezen részek közötti láthatóságot tárolja el egy "tömbben" (innen ered a set elnevezés). Előre is kiszámítható, de futás időbeni megoldások is léteznek.

Portal culling

Az elnevezés (legalább) két dolgot takar.
Elsőként a portált tekinthetjük az occluder (ilyen összefüggésben az occludert nevezhetjük antiportálnak) ellentétének vagyis olyan felület/háromszög ami mögött lévő háromszögek biztosan láthatók.
Másodsorban egy térfelosztó technika része, amelyben a térrészek egymással a portálokon keresztül állnak összeköttetésben. A térrészek láthatóságát a portálok segítségével vizsgáljuk.

Léteznek még olyan technikák, amelyek segítségével z-buffer hiányában a mélységi takarást megoldható. Ezek jobbára VSZFE megoldások.
Bizonyos algoritmusok mélységi sorbarendezés elvén működnek. Ehhez kiváló segítség a BSP-fa, amelyben a háromszögek egyértelműen sorbarendezhetők.
Más algoritmusok a képernyőn megjelenített háromszögekkel végeznek el vágást. Ezekhez már kiegészítő buffer szükséges, melyek némileg hasonlóan működnek, mint a z-buffer azonban nem per-pixel tárolják a szükséges adatokat. Ilyen például a coverage-buffer és a surface-buffer.
Megjegyzendő, hogy ma már gyakorlatilag nem létezik olyan hardveres renderelő, amely nem biztosítana z-buffert.

Mindkét engine több, mint 10 éves múltra tekint vissza és rengeteg játék, siker és tapasztalat áll mögöttük. Kezdetekkor a Quake engine volt népszerűbb azonban a Q3 sikersorozata után és az Unreal engine 3 megjelenésével megfordult a helyzet.
Mindennek több oka is lehetett, amelyek elemzéséhez nem értek.

Talán egyik közvetett ok lehet (a "miértet" lásd a legvégén), hogy a Quake4 engine (hivatalosan Doom3 engine-nek nevezik, de nevezhetnénk id Tech 4-nek is) és Unreal engine 3 alapvető különbségeket mutat térfelosztás és az abból következő renderelési optimizáció témakörében. A két kulcsszó: portál és antiportál.
A könnyebb megértéshez vegyük szemügyre mindkét engine pályajának felépítését.

A Q4E még mindig BSP-vel dolgozik mást nem is nagyon ismer ill. csak később lett kiegszítve külső tér rendereléssel. A BSP alapú térfelosztást - ahogy eddig is - kiegészíti portálokkal.

Az UE3 már csak korlátozott mértékben (vagy egyáltalán nem) használ BSP-t ily módon nincs is élesen megkülönböztetve a külső és belső tér emiatt itt portálok elhelyezésére nincs mód. Helyette antiportálokat használ a takarási feladatok elvégzésére. A térfelosztási módszere egyelőre ismeretlen.

És hogy mi is a portál és antiportál közötti alapvető különbség.
 

A portál segítségével

• végezhetünk térfelosztást vagyis
• gyorsan kereshetünk a térben adott pont körül avagy adott térfogattal
• azt a felület jelöli a térben, amelyen keresztül két térrész látszik egymásból és emiatt
• a takarási feladatok elvégzése gyors és egyszerű

A portál hátránya

• vagy speciális szerkesztőt igényel, ahol a portálokat a pálya szerkesztőjének kell megjelölni / generálni
• vagy egy hosszas utófeldolgozási lépés során kell megtalálni a lehetséges portálokat
• emiatt nehézkes ingame portálokat generálni
• csak belső terekre használható

Az antiportál tulajdonságai:

• azon felületet definiálja ami mögött biztosan nem látszik semmi
• nem igényel speciális szerkesztőt. Egyszerűen el kell helyezni a térben a pályaelemeket, amelyekből automatikusan elkészíthetőek egy antiportálok.
• teljesen dinamikus vagyis ingame bármikor áthelyezhetők (kivéve ha költséges hierarchiába vannak rendezve)
• minimális (vagy egyáltalán semmi) utófeldolgozást igényel
• külső és belső térben egyaránt használható

Az antiportál hátránya

• önmagában használva semmiféle térfelosztást nem biztosít vagyis szükséges mellé egy hatékony módszer, amely (többek között) gyors frustum vágást tesz lehetővé

Mindezekből elméletileg úgy tűnik, hogy az antiportál egy általánosabban és gyorsan alkalmazható technika a frustum cull gyorsítására azonban a térfelosztás hiánya nagy hátrány a portálokhoz képest.
A gyakorlat pedig majd eldönti, hogy tényleg így van-e...

PS:
Látható tehát, hogy a pályaszerkesztés UE3 alatt nagyságrendekkel egyszerűbben elvégezhető, mint Q4E esetén. Ez pedig, mint ahogy megtudtam (thx Askhandi^^) fontos tényező a játékkészítésben...
A technikai infókért pedig köszönet Tripx-nek^^

Eljött ennek is az ideje. Hogy mié is? Egy furcsa érzés... Olyasmi, mint amikor az ember befejez vagy befejezettnek tekint valamit és felszabadul - felszabadul rengeteg gondolat és kérdés alól, ezekre választ kap vagy csak értelmüket vesztik.

Azt hiszem az engine-mmel kapcsolatban valami ilyesmit érzek. A grafika, fizika, audio, logika, AI, net hatosfogatból "kész" van három, amelyek működnek is együtt. A legnagyobb előrelépést a logika formába öntése hozta el miszerint a scriptelhetőséget általánosítottam. Vagyis elméletileg az engine-n kívülről lehet minden eseményt lekezelni valamint sok eseményt kívülről is létre lehet hozni. Mindössze az a megkötés van "beégetve" az engine-be, hogy melyik esemény jelzi a "játék végét".

Következő lépésben a grafikát, fizikát és logikát ki kell egészíteni és tovább csiszolni, hogy az eddig ismert helyzetekben adott hibahatáron belül kifogástalanul működjenek. Ezután (ill. némileg már eközben is) a tartalom-generálás kerül előtérbe. Talán az is lehetséges, hogy ez utóbbi folyamat tervszerű lesz és használható végeredményt is nyújt:3

Dum spiro spero...

Az elmúlt pár hónapban az enginem annyi új képességgel bővült, hogy eljött az ideje készíteni egy állapotjelentést ill. egy listát arról aminek az alapjai már léteznek (de esetleg még hibás) és aminek még nem...

Tehát ami már létezik ("alulról - felfelé"):

1. Támogatott kép formátumok: DDS, JPG, PNG, TGA
2. Támogatott script formátum: LUA
3. Támogatott modell formátumok: 3DS, MD3, MD5, GLM/GLA, OBJ
4. OpenGL 1.1, OpenGL ES 1.x és OpenGL ES 2.0 támogatás
5. Scriptből összeállítható gui
6. DirectInput támogatás
7. OpenKODE támogatás
8. Scriptelhető materialok és decal-ok
9. Nem-animált, csontváz-animált meshek, soft body meshek és részecske emitterek
10. Animation blend
11. Kétféle fizikai engine: Bullet és PhysX
12. Játék logika és szereplők scriptelhetősége
13. Szereplők character controllere
14. A szerkesztő tartalmaz egy pályaszerkesztőt belső térhez és játékba történő exportálót és modell importálókat
15. Többszálúsított animáció
16. A belső tér portál alapú felosztása

Természetesen mindehhez bőséges tennivaló és hiba felsorolás tartozik:3

És ami a folytatásban következik:

1. Szerkesztő: különböző magasságú és talajszintű szektorok.
2. Szerkesztő: belső térhez statikus meshek hozzáadása
3. Szerkesztő: belső tér textúrázhatósága
4. Szerkesztő: szereplők pozíció-orientáció szerkesztése
5. Gui: teljes scriptelés- események lekezelése ne a natív kódból történjen.
6. Játék logika: szereplők összetetebb vezérlése

Hosszabb távú tervek is vannak, mint pl OpenAL támogatás, teljesebb AI és triggerelés ill. teljesen 3D pályaszerkesztő mind belső mind külső terekhez.

Szóval.... ora et labora ^^

Éééés hosszas vajúdás után elkészült a pályaszerkesztőm újabb verziója. Közel két hétig tartó tervezés eredmény egy kb. Doom1-2 színvonalú tervező:3

Belső tereket lehet létrehozni, amely a portál rendszer követelményeit teljesíti. Az alapelemek a szektorok, amelyek egy konvex befoglaló huroknak felelnek meg - jelenlegi állapotban ezek a 0 magasságú vizszíntes síkban 2D befoglaló hurkok, amelyekből adott magassággal készül el a valódi 3D mesh. Amennyiben konkavitást akarunk belevinni a belső térbe, egy egyszerű lépéssel új szektort hozunk létre a régivel szomszédságban egy új pont hozzáadásával. A közös pontokból pedig automatikusan portál keletkezik. Természetesen a szektor belseje benne elhelyezett statikus meshekkel is konkávosítható, de nyilván nem olyan mértékben, mintha szektor-szinten tennénk ezt.

Folyt. köv. :3