Tovább tisztul a világunk:

kezd kristályosodni, hogyan fogom megoldani a bonyolultabb Mesh-eket.
Az alaposztály már kész, a heightmap-el teszteltem is .

Ha minden jól megy, akkor a Mesh-eink a következõ dolgokat fogják támogatni:

- MultiMesh
- Keyframe és Bone anim
- Material (diffuse, detail, normal, specular map, anyagjellemzõk)

A modelleken belül az egyes mesh-ek is lehetnek majd átlátszóak.

Mostanában sajnos kicsit kevesebb idõm volt a projektre, viszont most meg tudtam tenni azt, amire a múltkor nem maradt idõm:

Elkészült a 3D hang támogatás, és az ezt kihasználó Audió entitás - a világ objektumaihoz hozzáadható, a szülõobjektummal együtt mozog.

Idézet

---

Orphy :
A mai naptól fogva hangoskodunk is

A framework-be bekerült egy FMOD alapú hangrendszer - igaz, még alakulni fog kicsit, de már mûködik, és szemtelenül egyszerû használni...

Kód:

cAudio2D music = cAudio2D();
music.LoadStream("Spellforce - Cenwen.mp3");
music.Play();

FMOD rulez

---

Hehe, ez nálam is hasonlóan mûködik csak nem eszik meg MP3-at (van helyette Ogg Vorbis meg FLAC) és vagy két hetet szoptam mire a nulláról megírtam.

A mai naptól fogva hangoskodunk is

A framework-be bekerült egy FMOD alapú hangrendszer - igaz, még alakulni fog kicsit, de már mûködik, és szemtelenül egyszerû használni...



FMOD rulez

visszaszivom vmelyik korábbi állitásom ugyanis sikerült baromi gyorsan betöltetni heightmapbol a domborzatot (habár normalokat nem generáltattam neki) valszeg valamit elrontottam korábban és azért volt lassú.

nálam viszont mutlisample-el 2 x 128 x 128 vertexre csak ~100 fps (vfc nélkül)

A world system, mûködés közben:
A NeHe-s kocka az elsõ szülõ, gyermeke a láda, ennek pedig a holdas kocka

http://www.youtube.com/watch?v=pZdmpsDsGBU

A hierarchikus világot is átettem a framework-be.

Alaphelyzetben ez az alrendszer "csak" a hierarchiáért, és a benne szereplõ objektumok world mátrixának helyes beállításáért felel. A framework-be való átkerülésével valamennyire függetlenedett is az engine render részétõl - értsd: nem kötelezõ használni, de fogjuk.

További elõny, hogy pont a függetlenedés miatt bárhol felhasználhatjuk, akár egy modellen belül, bone animhoz...

A framework-öt végül sikeresen áttettem lib-be, a heightmap-es tesztprogit is átírtam az új, lib-es megoldásra, és feltöltöttem az egészet SVN-re.

A következõ lépés a Butterfly Engine, és meglevõ objektumainak átírása a framework-ös alapokra, a világrendszer kis tisztításával egybekötve. Ezt sorrendben az új modell osztályunk, és a fény-árnyék megoldások követik.

Idézet

---

DMG :
Nade elsõsorban nem a betöltést kell fürgébbé varázsoplni, hanem a realtime megjelenítést kell gyorsítani nem? Igaz ilyen 800 körüli FPS érték mellet lehet felesleges az optimalizálás, de sok kicsi sokra megy.

---

Igen, alapvetõen a megjelenítés jó ha gyorsan megy
Viszont a megjelenítés optimalizálása, vagy nem optimalizálása alapvetõen játékfüggõ. Késõbb még lehet, visszatérek rá, most a loader volt a lényeg - játék, és engine függetlenül.

Nade elsõsorban nem a betöltést kell fürgébbé varázsoplni, hanem a realtime megjelenítést kell gyorsítani nem? Igaz ilyen 800 körüli FPS érték mellet lehet felesleges az optimalizálás, de sok kicsi sokra megy.

Az underwater érzés a kék háttér, és az ugyanilyen színû köd miatt lehet - ez csak egy teszt volt, búváros játékot nem tervezünk

gaborlabor:
Vannak módszerek, amik a heightmap-ek renderelését hivatottak támogatni. A Teljesség igénye nélkül:
- Quadtree
- Octree
- Geomipmapping
- Roam

Amit te írtál, az kicsit szokatlan: ha a játékban több vertex kell, valószínûleg kérek egy nagyobb heightmap-et a grafikustól A javaslat második felét használom: csak nem minden x-edik pixelt kihagyom, hanem minden x-edik pixelt dolgozom fel

Esetleg még annak lehetne valami értelme, hogy olyan területeket keresünk a heightmap-en belül, ahol azonosak a magasságok, és akkor azt kevesebb háromszöggel le lehetne írni. Csak ez meg nem biztos, hogy megéri - egyrészt valószínûleg nem érint annyi háromszöget hogy megérje a plusz munkát, másrészt a betöltés amúgy sem túl fürge...

Még sosem próbáltam heightmap loadert, de már agyaltam rajta egy keveset én is.
Mi lenne, ha te adnád meg a framework-nek/engine-nek, hogy hány darab vertexet akarsz? És akkor, ha mondjuk van egy 256*256-os képed, de neked több vertex kell, mert a játékban a táj nagy területet fog lefedni, akkor a pixelek értékei között lehetne interpolálni és az így kapott értékbõl újabb vertexet generálni. Ha meg kisebb részletességû táj kell, akkor meg egyszerûen kihagyod a feldolgozásnál minden x-edik pixelt.

Szép. Kicsit olyan Under Water érzésem támadt tõle, búváros játék lesz?

Lehet ezt még optimalizálni, ahol nincs szükség annyi vertex-re mert sík a táj ott lehetne csökkenteni a vertexek gyakoriságát, ahol meg változó a felszín ott meg növelni.

Jah, igen:

A heightmap 512x512-es.


Asylum:
Úgy tûnik, az a megoldás a követendõ, amikor egy nagy heightmap-bõl nem minden pixel esetén készítesz vertexet, hanem pl minden 8-ikból.
Ezzel lehet játszani, ha növeled az értéket, gyorsabban betölt, de kockásabb lesz a terep.

No, elkészült a heightmap loader is

Szintén a framework-be került, önmagában nem renderel, csak elkészíti a heightmap-bõl a renderelendõ vertexeket triangle list-be pozícióval, normállal, textúra és detail textúra koordinátával.

A renderelõ osztály dolga mindössze annyi, hogy a kapott vertex-listából vertexbuffert készítsen, és azt renderelje a megfelelõ anyagokkal, textúrákkal, effektekkel...

A képen látható tájat a Monster3D tutorból vettem kölcsön, egész szép

V marad textúrában, és akkor VS3-mas kártyákon akár vertex shader segítségével egy statikus index/vertex buffer-bõl is meg lehet csinálni a terepet, akár úgy is, hogy folyamatosan változik (terrain morphing). Ez már a Gef6600-omon is szépen teljesített. Ha valakit érdekel itt talállhat róla képeket:
http://shadevampire.extra.hu/gallery/print_gallery.php?dir_name=TerrainRender

Azért ez a konvertálás nem rossz ötlet, csak nem OBJ-ba hanem valami HighMap specifikus saját formátumba, ami mindent tárol amire neked szükséged van.

Idézet

---

Asylum :
szerintem lehetne külön csinálni egy generátort ami heightmapot mondjuk obj-be konvertál és akkor azt már gyorsabban be lehet tölteni

---

Nem hiszem, hogy gyorsabban lehetne úgy betölteni - attól még ugyanannyi vertexrõl beszélgetünk, amit be kell olvasni, fel kell dolgozni. Ráadásul az obj-ban ugye szövegesen vannak megadva, szóval az input file-od még nagyobb méretû.

Továbbá a heightmap egyik nagy elõnye, hogy le lehet tõle kérdezni a magasságot az adott pontja felett, és pl odapozícionálni a modellt. Ezt az eredeti módszerrel elég kis költséggel meg lehet tenni, de ha átkonvertáltad obj-ra, akkor bajban vagy...

szerintem lehetne külön csinálni egy generátort ami heightmapot mondjuk obj-be konvertál és akkor azt már gyorsabban be lehet tölteni

Hát igen, egy 256x256-os heightmap, az sok vertex

Egészen pontosan 255*255*6 = 390.150

Ezt mind egyesével fel kell dolgozni, ki kell számítani a pozíció, textúra, és normál értékeket...

A monster3D tutor azt csinálja, hogy egy 512x512-es heightmap esetén csak minden 8-ik vertexet dolgozza fel: Monster3D tutor
Ezáltal gyakorlatilag olyan, mintha egy 64x64-es heightmap lenne. Mondjuk nem értem, hogy akkor meg miért nem 64x64-eset használ alapból...

Én inkább a normál számítást érzem cikisnek:
ugyanis ha nem mindenhol face normált akarok használni, és ezáltal háromszöges képet kapni, akkor sajnos nem elég betöltésnél egy ciklus...

ööö nem, a betöltésre értettem

Idézet

---

Asylum :
Elõbbi kib*szott lassú volt (256 x 256 os heightmapra).

---

Ha itt fps-t értesz, akkor az valószínûleg azért van, mert a heightmap vertexeinek száma meghaladja a videokari maximum egyszerre megjeleníthetõ vertexeinek a számát.
Próbáltad több részletben kirajzolni a heightmap-et?

hehe igen ezt már én is próbáltam csak felmerült egy kérdés, hogy egy pixel = 1 vertex vagy mondjuk több pixelenként csinálnál egy vertexet. Elõbbi kib*szott lassú volt (256 x 256 os heightmapra). Szerintem inkább a második verzió és kicsit lecsiszolni bár most még nincs meg.

A framework-öt leteszteltem, az effektek is mennek.
Ezzel az elsõ verzió készen van, hétvégén átépítem rá az engine-t.

A framework természetesen még bõvülni fog, ha közben még eszünkbe jut valami.

Tegnap pl nekem egy heightmap loader ugrott be:
ez betöltené a képet, és elkészítené belõle a vertex-, és index adatokat: pozícióval, normállal, és tex koordinátákkal. Ezt aztán visszaadná az engine-nek, aki ebbõl elkészítené a vertex és index buffereket, és a saját módszere szerint renderelné...

multkor beast linkelt egy igen jó kis pdf-et színtérgráfokra. Assszem az engine programozás topikban van.

hát akkor én kicsit túláltalánosítottam a dolgot köszi
bár nagy n ekre a lista esetleg lassú lehet ezért gondolkoztam inkább fában / gráfban. próbálok keresni valami középutat.

Örülök, hogy ennyivel is hozzá tudtam járulni a fejlesztéshez.

Na jó ez azért erõs volt.

Valószínûleg ebbe futottam bele én is, most már a cégnél újrafordítva is megy.
Jó tudni, hogy ilyenek is elõfordulhatnak...

Idézet

---

Orphy :
Elképzelhetõ, holnap megnézem, hogyan reagál a céges gép az új kód fordítására...

---

Én Dev C++-t használok ott ezt csinálja, csak akkor fordítja újra az egész header részt, ha belemódosítok a main cpp-be, ott is elég egy betû meg egy visszatörtlés, vagy ha a .o kiterjesztéseket és a make file-t törlöm. Lehet, hogy a VC++ esetében nem ez a hiba, én ezzel már sokat szívtam, de már rutinos vagyok.

A scenegraph saját tervezés.

Vannak általános megoldások a scenegraph-ra, a teljesség igénye nélkül:
- láncolt lista, std::vector
- Maya hiperGraph
- Java3D scenegraph

Ezek közül talán a Java3D-ben található scenegraph a legkiforrottabb.
Általános, rövid ismertetõ található a Szirmay-Kalos könyvben is, de biztos vagyok benne, hogy neten is lehet egy csomó mindent találni.

Az irányítatlan körökhöz annyit tennék hozzá, hogy amíg egy hierarchikus scenegraph-ban rekurzív bejárást, és a gyermekekre mutató pointereket használsz, addig elõfordulhat ilyen.
Ellenõrzést persze lehet beépíteni - pl eltárolod a meglátogatott csomópontok címét, és minden újnál ellenõrzöl, hogy voltál-e már ott.

Más kérdés, hogy megéri-e.

Nekem eddig igazából viszonylag kevés esetben volt szükségem magára a hierarchiára, és akkor sem volt nagyon mély - nagyrészben listaként mûködött a scenegraph. Ehhez persze hozzá kell tenni, hogy a világban észlelhetõ objektumokat egységként kezelem benne - tehát, ha van egy több mesh-bõl álló modell, akkor az a scenegraph szempontjából egy modellnek számít, a modellen belül a több mesh lekezelése a modell osztály feladata...

Nálunk alapvetõen úgy mûködik a dolog, hogy tényleg MINDEN világban szereplõ objektum bekerül a scenegraph-ba. A kamera, és a fények is. MINDEN világban szereplõ objektumnak lehet gyermeke, és hozzá is kapcsolható egy másik világbeli objektumhoz - ekkor a hozzá képesti pozíciót tartva vele együtt mozog.

Pl az egyik tipikus hierarchia-kihasználás az, amikor van egy mozgatható pontszerû, vagy spot fényem - aminél ugyebár nehezen nyomonkövethetõ, hogy éppen hol is van a középpontja. Viszont, ha hozzáadok gyermekként egy billboard-ot, akkor mindjárt más a helyzet.
A fenti, "shaderes fény" képen egy ilyen megoldás látható.

A világhoz kamerából is tetszõleges mennyiség adható - viszont ki kell választani közülük egyet, amin keresztül renderelni akarunk. A képszintézis folyamán ennek a kamerának a beállításait használjuk, a többivel nem foglalkozunk.

Ez azért jó, mert viszonylag könnyû így különbözõ kameraállásokat csinálni - pl egy autómodellhez hozzá lehet rendelni egy kamerát a motorház fölé, egyet a kocsi mögé, egyet a vezetõülésbe, és utána ezek automatikusan mozognak a kocsival együtt. A kameranézet-váltás meg ezután mindössze annyi, hogy más-más kamerát jelölünk ki render-kameraként...

Hmm asszem megkérdezem, hogy használtatok-e valami doksit a scenegraphoz/hierarchiához, mert eddig nem sikerült normálisat/érthetõt találnom. Konkértan az a probléma, hogy lehet benne irányítatlan kör és így a fa bejáró algoritmusok csõdöt mondanak. (pl. irrlichtben ilyen nincs ahogy nézegettem mert ott csak egy aktív kamera lehet és onnantól indul a bejárás kb.)

Idézet

---

Lord_Crusare :
Mindig meglepõdöm azon, hogyha azt hallom, hogy a C nyelv valamely változata ökörségeket csinál. Ráadásul számomra elképzelhetetlen, hogy egy fordítás mondjuk egy pillanatnál tovább tartson...meg is õrülnék, ha C-t használnék, és minden fordításkor nekiállna szöszmötölni...
Sorry az offért.

---

Hmm, hát az általam eddig használt nyelvek közül a C++nél voltak a leghosszabb fordítási idõk...

Amúgy ez egyre jobbnak tûnik, a kockás képek kifejezetten jók, csak így tovább.

Köszi, igyekszünk

Idézet

---

DMG :
VC++ esetlegn nem csinál olyan marhaságokat, hogy a .h headerek változásait nem fordítja újra, csak ha a törlöd a fordított file-okat, vagy ha az adott header c-jébe belemódosítasz?

---

Mindig meglepõdöm azon, hogyha azt hallom, hogy a C nyelv valamely változata ökörségeket csinál. Ráadásul számomra elképzelhetetlen, hogy egy fordítás mondjuk egy pillanatnál tovább tartson...meg is õrülnék, ha C-t használnék, és minden fordításkor nekiállna szöszmötölni...
Sorry az offért.

Amúgy ez egyre jobbnak tûnik, a kockás képek kifejezetten jók, csak így tovább.

Elképzelhetõ, holnap megnézem, hogyan reagál a céges gép az új kód fordítására...

VC++ esetlegn nem csinál olyan marhaságokat, hogy a .h headerek változásait nem fordítja újra, csak ha a törlöd a fordított file-okat, vagy ha az adott header c-jébe belemódosítasz?

Jah, de minden rosszban van valami jó - gyengébb gépen is tudom tesztelni a dolgokat

Egyébként a közben teszteltem a fényeket és a ködöt is, ezek is rendben vannak, valószínûleg az effekt-tel sem lesz gáz.

Még hátra van egy kis tesztelés + kommentezés, plusz a dll-esítés.
A framework elsõ verziója legkésõbb szombat reggel felkerül az SVN-ünkre.

Ez jelentõsen meg fogja könnyíteni a dolgunkat, fõleg az olyan új dolgok kipróbálásánál lesz egy gyorsan hasznosítható stabil alapunk, amiket nem akarunk azonnal az engine-be beletenni.

Sõt, igazából amit a framework-re fejlesztünk, az utána minimális átalakításokkal bekerülhet az engine-be is

A céges gépeden a labirintusos játékom is bedobta a törölközõt, pedig egy alap OpenGL program.

0.1 NearPlane, 1000 FarPlane

Érdekes.
Itthon is hülyéskedett, csak itt nem csíkozott, hanem Z-hibásan jelentek meg a kocka lapjai...

Nyomtam rá itthon egy full build-et, és most jó...
Azért fura, mert a cégnél is fullbuild volt.

Nemértem...


Olyan, mintha Z-írás nélkül renderelt volna.
Amit valamikor egy teszt erejéig ki is kapcsoltam, de aztán visszaírtam. És mintha nem vette volna észre.
Mindenesetre az érintett függvényeket kilakoltattam a .h-ból, és áttettem a .cpp-be, hátha javít valamit...

Ez ilyen tipikus z buffer hibának tûnik igy elsõre. Milyen near-far értékeket használsz a vetitésnél?

Mennek a fények és a timing is, viszont a céges gépen egy fura megjelenítési hiba fordul elõ néha.

http://kepfeltoltes.hu/080227/LunaFuraHiba_www.kepfeltoltes.hu_.jpg

Úgy vettem észre, hogy a kamera kockától való távolságától, illetve a kocka elfordulásától függ, hogy megjelenik-e (ugyanis vagy ilyen, vagy tökéletes). Ilyennel találkozott már valaki?

Kíváncsi vagyok, elõjön-e otthon is...

off:
Ja, fontos a minél kevesebb state állítás, de szerintetek a D3D-nek mint OOP-ed cuccos, nem kéne azt alapból megtennie, hogy nyilvántartja a beállításokat, az alábbi postokból is kiderül, hogy egyedül õ lenne képes erre teljesen megbízhatóan, lévén az interfészén keresztül megy minden. Baromira nem értem, hogy ilyen egyszerû dolgot mér is nem építenek bele legalább a 9 verzióba...
no off:
Amúgy jó sokat dolgozhattál vele, hogy már ennyi mindent tud, csak így tovább!

Ez igaz, a statemanager-nek ez a hátránya.
Viszont magát a statemanager-t simán ki lehet publikálni, és akkor használhatja a programozó.

A state manager alapkellék egy engine-ben, egyrészt gyorsít, másrészt gyorsabban és megbízhatóbban ki lehet nyerni belõle az aktuális állapotokat (nekem pl az otthoni ATI kártyámon egyszerûen nem mûködik jól a GetRenderstate).

A külsõs libek már más dolog, de ilyet meg nem tervezünk.
Illetve amit igen, az D3D-s state-eket tuti nem fog állítani

nekem olyan probléma volt csak a statemanagerrel, hogy ha vmi külsõ cucc átállitott valamit akkor inkonzisztens lett az egész (pl. id3dxsprite) de ezt ugy értve h a programozó használja nem az engine (mert abban pont ezért nem használom).

Tegnap este megvoltak az elsõ tesztek és bugfixek...

Ha valaki szintén ír saját StateManagert, különösen figyeljen oda arra, hogy DeviceLost esetén törölje a mentett állapotokat, mert különben meglepetések fogják érni...

A framework a FRAPS szerint eddig jól teljesít:
640x480 32 bit ( X8R8G8B8,D24S8 ), ablakos mód 1200 fps környéke
640x480 32 bit ( X8R8G8B8,D24S8 ), fullscreen mód 2100 fps környéke
( Konfig: AMD Athlon Xp 1700+, 1.5 GB RAM, ATI Radeon 9600 XT )

Amit teszteltem:
- Alap D3D framework
- State manager
- FileSystem
- Kamera osztály
- Texture osztály

Hátra van még az effekt, a fények, a ködök, és az idõzítés tesztelése.

Ami eddig van, az egyelõre pure Fixed Function Pipeline, de a különbözõ osztályok fel vannak készítve arra, hogy a fontosabb paramétereiket át lehessen adni az effektnek.
Ez fõleg a különbözõ fényekre és ködökre igaz -> ezeket a Butterfly Engine-ben shader-esen fogjuk megoldani, de errõl Shade többet tud mesélni

Mindenesetre maga a framework támogatja az FFP-t is.

Idézet

---

kuzanth :
Kira a log-os kép. Milyen jó is lett volna tudni annó, hogy az Ati-k csak Pow2 textúrákat szeretnek...

---

Jaja, emlékszem, aanno belefutottam ebbe én is, csak C#-OGL alatt.
És persze nem értettem, hogy a tutur textúrájával miért 600 fps, a sajáttal meg miért 1...

Aztán Geri segített

Általános szabályként azóta igyekszem tartani mind a négyzetes, mind a kettõhatvány kritériumot

Köv. játékomban (...mintha lenne elõzõ, na mind1...) tuti, h pow2 helyett vmi tök órmótlan méreteket fogok használni, aztán odaírom, hogy "Designed for NVidia" (Bocs az off-ért, de ez nem maradhatott ki ezekután...)

OpenGL-lel lehet npow textúrákat is ati-val, bibibiiiiiii.
(gondolom r9600-zal)

Kira a log-os kép. Milyen jó is lett volna tudni annó, hogy az Ati-k csak Pow2 textúrákat szeretnek...

Szépen halad a framework.
Az elsõ kitûzött mérföldkövet már elérte, azonban úgy döntöttem, pár dolgot még beleteszek.

Rövid feature lista:
-------------------------
- Fájlkezelés - Lemezrõl, vagy pack fileból, egy file-t nem tölt be kétszer, hanem a memóriában már bent levõ referenciát használja.
- INI fájl olvasás - lemezrõl, vagy pack-ból
- HTML log - A Windows eventlog-ra hasonlító html log írása

- Math namespace

- Alap D3D váz - Alaposztály, amibõl származtatva automatikusan a rendelkezésünkre állnak a D3D és Windows event-ek, amikre rá lehet építeni bármit. Az inicializáláshoz szükséges dolgokat az osztály pOptions változóján keresztül lehet állítani, ezen belül minden szépen kategorizálva található.

- D3DStateManager - Duplikált hívások elkerülésére
- Textúra, Effekt wrapper, duplikált betöltés elleni védelemmel szintén.
- Ambient, Directional, Point, és Spot fényekre külön osztályok, a könnyebb kezelés érdekében
- Lineáris és exponenciális ködre szintén

Ez csak egy gyors lista volt a fontosabb dolgokkal, de persze van itt még más is: pl egy elég komoly eszközlekérdezés, kategorizálva, loggolva, stb...

Ami a legjobb benne, hogy kb bármikor, bármihez újrafelhasználható lesz - akár tool-okhoz, demókhoz, vagy más engine-ekhez is -> egy csomó dolgot nem kell ezeknél újra és újra megírni, ráadásul a projektek során teljesen stabilra lesz tesztelve és ki is forr.

Az elsõ tesztverzióig még egy kamera osztály fog bekerülni a napokban.

Régen írtunk ide.

A fejlesztés nem állt meg, viszont elérkezett az idõ, hogy kicsit rendszerezzük a dolgainkat. Ennek értelmében kettészedem a projektet.


Lesz egy framework, sok-sok hasznos dologgal - Az eddigi Core kb teljesen átkerül ide, egy code review kíséretében. Cél az is, hogy ez a framework független legyen a projekttõl, késõbb más projektekhez újra fel lehessen használni.

Maga az engine alapjaiban a framework-re fog épülni, a projektben csak a saját specifikus dolgai maradnak, segítve így az átláthatóságot.


Közben Shade dolgozik a shader-rendszerünkön, és a renderrel kapcsolatban is lesznek fejlemények - mostanában fog kialakulni, hogy hogyan oldjuk meg a fényeket, árnyékokat.
Az is elképzelhetõ, hogy a végén átállunk Deferred Renderer-re.