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

Mivel teljesen holtpontra jutottam a modellek kezelése kapcsán ill. a téma előhozta a szereplők osztályozásának problémakörét is. Alapvetően 3 részre oszlik a szereplők "main" függvénye: döntés, reakció, animáció.

A döntés származhat a játékostól, aitól és távoli játékostól. A reakció függ a szereplő típusától, az animáció pedig a reakciótól.

Mára ennyit...

Folytatás:

Jelenleg létezik: humanoid, animal, vehicle, object. A humanoid és animal rendelkezik "beépített" intelligenciával. A humanoid irányíthat vehicle-t és használhat object-et. A felhasználó pedig átveheti az irányítást a humanoid és animal felett.

Ezzel együtt talán dűlőre is jutottam a meshkezelés ügyében. A humanoid és animal biztosan nem lehet nem-animált modell, a többinél pedig esetleges. Animált modell esetén fizikai formához kizárt a konvex mesh (esetleg még lehetne animált trimesh, de az brrr) inkább csontokhoz csatolt kapszula. Nem-animált esetben összetett/konkáv formák is lehetségesek.

Pontosabban animált mesh esetén az alap fizikai forma kötelezően a csontváz míg statikus mesh esetén közvetlenül használható a geometria. Természetesen a fizikai formákhoz csatolható statikus, animált, softbody és emitter mesh is. A csontváz irányítás nélkül ragdollként működik majd.

Bizonytalan kérdés az animált vehicle és object kérdése...

1.  Elmúlt pár napban sokat gondolkoztam a szerkesztőmön ill. annak leíró nyelvén és számos helyen átalakítottam, de még most sem érzem teljesen stabilnak a felépítését. Egy bizonytalanságot már kiderítettem miszerint teljesen felesleges külön fizikai formákat és geometriai formákat megkülönböztetnem.

Statikus mesh esetén a fizikai forma a geometria konvex befoglalójának felel meg.

Aninált mesh esetén a fizikai forma valószínű egy ragdoll lesz, de egyelőre egy kapszula.

A probléma az emitterekkel és a softbodykkal lehet, mivel azokat mindenképp érdemes egy shape-hez csatolni. A megoldás azt hiszem az lesz, hogy ha a modell nem tartalmaz semmilyen egyéb geometriát (,amihez a csatolás történne) akkor létrehozok egy v több dummy shapet, amihez lehet csatolni. Természetesen ezek a shapek az ütközésvizsgálatból kimaradnak.

Ennek megfelelően a szerkesztő nyelvét átírom azonban a belső kezelés marad ugyanaz...

2. Már meg is találtam ennek a megoldásnak a gyenge pontját: igen nehéz így konkáv testeket megadni szóval más megoldást kell találnom.

3. Ismét egy régi probléma az, hogy valamilyen szinte összefügg az adott szereplő ai-ja az általa használt modellel. Kérdés, hogy mennyire függ össze. Ahogy látom, alig függenek össze, hiszen lehetséges nem animált modell a főhős (pl. űrhajó) és lehet animált objektum egy tereptárgy (pl. robotkar).

1/0... majd legközelebb...

Ismét egy fordulópont után...

Átnéztem az OpenCL specificikációját és nagyon-nagyon szimpatikus programozói felületnek tűnik. Olyannak érzem, mintha az OpenGL-t (ill. az azt kiszolgáló hardvert) látnám belülről. Hasonló gondolkodást igényel, mint a névrokona viszont nincsen a "renderelés" korlátai közé szorítva így jóval szabadabban használhatjuk (garázdálkodhatunk benne). Remélem hamarosan kijön egy release driver nvidiától...

A munka ünnepét sikeresen kihasználva ismét haladtam és remélem, hogy előre. Talán a leghangsúlyosabb dolog az, hogy a szerkesztőm nyelvét "openglesítettem" vagyis a szintaktika és a szemantika is nagyjából hasonló. Minden ami a szereplőkkel kapcsolatos opengl objecthez hasonlóan viselkedik azaz skGen-nel lehet létrehozni, skBind-dal aktualizálni és skParameter-rel beállítani a tulajdonságait. A különböző összetevőket skActorXXXX névvel lehet a szereplőhöz kapcsolni.

A függvények a klasszikus target, param, value argumentumokat használják:

• az skGen egy targetet vár és valuet ad vissza
• az skBind egy targetet és egy valuet vár(, amelyet értelemszerűen már korábban létrehoztunk)
• az skParameter pedig egy targetet, egy paramot és egy vagy több valuet
• az skActorXXXX függvények nem várnak argumentot, hanem az éppen aktuálisan bind-olt XXXX-t kapcsolja az éppen aktuálisan bind-olt szereplőhöz.

Jelenleg a target actor, shape és emitter lehet, de ezek még kiegészülnek a későbbiekben. A paramból már most nagyon sok van és jó pár target specifikus.

Valószínűleg a jeleneteket scriptként fogom tárolni és lehet érdemes konzolt írnom a szerkesztőhöz...

Másik jelentős változás, hogy a scenegraph most már majdnem teljeskörűen kezeli a szereplőket:

• a body, shapek és emitterek kezelése majdnem kész (konvex shapek majd a modell betöltéssel együtt)
• jelenleg még nincs modell betöltés
• az aktív és inaktív szereplők+környezet kiválogatása és kölcsönhatás kezelése tökéletesnek tűnik
• és ezzel együtt elkészült a közeli szereplők "ingyen" összegyüjtésének lehetősége is

Azt hiszem most jön a meshkezelés átalakítása.

Végezetül pedig az első "élesben" használt jelenet leíró script:

player0_a=skGen("actor");
player0_s0=skGen("shape");
sparkle0_a=skGen("actor");
sparkle0_s0=skGen("shape");
sparkle0_e0=skGen("emitter");

skBind("actor",player0_a);
skBind("shape",player0_s0);

skParameter("actor","name","PLAYER0");
skParameter("actor","AI_index","player");
skParameter("actor","position",0,0,1);
skParameter("actor","is_rotation_frozen",true,true,true);
skParameter("actor","half_extent",1,1,1);
skParameter("shape","type","sphere");
skParameter("shape","scale",1,1,1);
skParameter("shape","density",5);
skActorShape();

skBind("actor",sparkle0_a);
skBind("shape",sparkle0_s0);
skBind("emitter",sparkle0_e0);

skParameter("actor","name","EMITTER0");
skParameter("actor","AI_index","object");
skParameter("actor","position",2,2,1);
skParameter("actor","is_static",false);
skParameter("actor","half_extent",1,1,1);

skParameter("shape","type","sphere");
skParameter("shape","scale",.5,.5,.5);
skParameter("shape","density",1.5);

skParameter("emitter","scale",.1,.1,1);
skParameter("emitter","type","line");
skParameter("emitter","max_particles",100);
skParameter("emitter","lifetime",.5);
skParameter("emitter","emitting_rate",50);
skParameter("emitter","emitting_velocity",4);
skParameter("emitter","color",1,0,0);
skParameter("emitter","random_angle",3);

skActorShape();
skActorEmitter();

i_a=skGen("actor");
i_s=skGen("shape");

skBind("actor",i_a);
skBind("shape",i_s);
skParameter("actor","name","OBJECT0");
skParameter("actor","AI_index","object");
skParameter("actor","position",-4,-4,2);
skParameter("actor","velocity",1,0,0);
skParameter("actor","half_extent",2,2,2);

skParameter("shape","type","box");
skParameter("shape","scale",1.5,1.5,1.5);
skParameter("shape","density",5);
skActorShape();

--skImport("q3bsp","bsp/test1/test1.bsp");
skImport("q3bsp","bsp/borg/1.bsp");
skCompile();

 Lehet érdemes lenne a sztringek nagy részét konstansokkal helyettesítenem.

Találtam egy érdekes olvasmányt a humuson, amely a fragmens feldolgozással kapcsolatos. Íme egy rövid, tömör összefoglaló:

Mindenki tudja, hogy a hi poly modellek a vertex feldolgozást erőteljesen megterhelik, azt viszont valószínűleg kevesebben, hogy a fragmens processzorra is nagyobb terhet ró mindez. Mivel a fragmenseket négyesével (2x2) dolgozza fel a processzor, ezért ha egy él kettévág egy ilyen blokkot akkor erre a blokkra kétszer fut le a fragment program (néhány gpu még nagyobb fragmens egységekkel dolgozik). Emiatt az az optimális, ha a háromszögek élei minél rövidebbek és minél nagyobb felületet renderelünk egyszerre.

Ilyen szempontból a legrosszabb eset a háromszög legyező, ahol elég sokszor előfordulnak hosszú és vékony háromszögek. Sajnos a szalag sem igazán felel meg erre a célra. Jelenleg egy "programot" emlegetnek, amely képes ilyen optimalizáció elvégzésére: sourceforge.net/projects/pyffi

Elmúlt két napban ismét ssaoval foglalkoztam. Igyekeztem minél több forrást felderíteni a témában és úgy tapasztaltam, hogy a legtöbben a crysisban használt eljárást használják. Találkoztam a hybrid ambient occlusionnel is, de nem volt túlzottan megnyerő számomra. Kiötlöttem egy saját megoldást is, aminek ez a végeredménye blur nélkül

A megoldás persze még nem tökéletes viszont nagyon kevés utasítást használ.

Remélem eljut valamikor olyan fázisba, hogy ingame is használni lehessen. Bár van egy másik technika, amely a fragmens normáljából és poziciójából számol vagyis jóval részletesebb képet eredmény deferred shadinggel.

Vagy pedig az Ambient Occlusive Crease Shadinggel próbálkozom majd...

Egy hirtelen ötlet az éjjeli "fázisom" előtt: a távoli fényekre felesleges spekulárt számolni és majd később árnyékot is sőt talán a diffúz árnyalást is meg lehet spórolni, de majd a gyakorlat eldönti melyik elhanyagolással lehet élni...

A mai nap során kipróbáltam néhány olyan bspt, amelyet nem hivatalos játékhoz készítettek (egész pontosan innen szereztem www.fpsbanana.com). Megdöbbenve tapasztaltam, hogy az összes(!) felület rosszul jelenik meg. Megnéztem más bsp betöltőkkel is, azok is rossz eredményt mutattak. Elkezdtem debugolni és kiderült, hogy az összes felület 1-s típusú (planar) vagyis háromszög legyezőként kell renderelni. Kipróbáltam átindexelni a felületeket (én csak drawelements-sel rajzolok vagyis fel kell bontanom az vertex array vertex index arrayra), de az sem segített. Ekkor megnéztem a facek paramétereit és csodálkoztam, hogy értelmes és használhatónak tűnő adatokkal van feltöltve így hát kiprobáltam a legyezőket háromszög halmazként felhasználni és most jön a poén, mind korrektül jelent meg. Szóval minden az 1-s és 2-s face típust ugyanúgy lehet kezelni!

Vajon miért nem törődnek a legyezővé alakítással, ha már egyszer külön face típus van hozzá rendelve...

Megjegyzés:

a régi bspk is tökéletesen működnek így (vagyis szerintem a teljesítmény miatt tárolták el legyezőként is a faceket) és a "régi" és "új" bsp-k verziószáma is 0x2E.

A "scene designhoz" kapcsolódó első shotok egyike. Nagyító használata javasolt...

Tegnap egész jól összehoztam a szikra emittert és maguknak a szikráknak a megjelenítése is egész tűrhető. Ezzel a lépéssel viszont aktuálissá vált rengeteg megoldandó kérdés, amiket most megpróbálok összegyűjteni.

1. A legjobban talán az editor scriptelhetősége hiányzik, hogy ne kelljen folyton ugyanazokat a szerkesztési lépéseket elvégeznem minden egyes tesztelésnél. Ehhez át kell néznem, hogy lua-c függvény bindot készíteni és paraméterezni.
2. Át kell néznem a részecskerendszer paramétereit és hogy ezek közül melyeket kell szerkeszthetővé tennem.
3. Kérdés, hogy a részecskerendszert mihez lehet csatolni. Lehet-e / érdemes-e vertexhez vagy csak shape-hez? - csak shapehez érdemes (a shapet érdemes kivonni a szimulációból ha nincs hozzá modell) és így szerkeszteni is könnyebb.
4. Hogyan integráljam a fényeket? Pl a szikra esetén, mert a szikra egyszerre részecske és fényforrás is.
5. Milyen típusú "elemeket" lehessen csatolni egy szereplőhöz és hogyan?
6. Ezeket az "elemeket" hogyan lehessen szerkeszteni?
7. Skydome-hoz szeretném használni a z-cullt, de ahhoz valahogy a vertex programmal kellene a végtelenbe vetítenem és nem fragment programmal.
8. A szereplők fizikai és grafikai cullja!

jajjj....

Vááá, nagyon jó, délután már megcsináltam életem első c függvény hívását luából:]

vagyis gyakorlatilag most már luán keresztül programozhatóvá vált az engine szerkesztője...

még egy kérdés, a különböző renderelési fázisok és szereplők renderelése hogyan....