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

Mivel lightmap generálásakor a kapott lumelek színtartománya túlmutat a megszokott 0...1 értékeken (LDR helyett HDR), ezért mindenképp növelni kell a tároláshoz szükséges bitmélységet azaz nem lehet a végeredményt (egy lépésben) egy mezei png fileba kimenteni.

Legkönnyebbnek látszó megoldás float tömbként elmenteni a lightmapeket, de ezenkívül még foglalkoznunk kell a járalékos adatok mentésével, mint a textúra mérete, csatornák száma ill. néha igény támadhat, hogy képnézegető programmal is közvetlenül megtekinthető legyen.

Mivel a nagy értéktartományú (és lebegőpontosan tárolt) színeket tartalmazó képek mentése már másoknak is fejtörést okozott, ezért szerencsére már léteznek többé-kevésbé általános megoldások. Egyik ilyen pl. a Lucasfilm OpenEXR formátuma, amely első (és sokadik) olvasásra is túl soknak tűnik vagy pl. a TIFF ill. a JPEG XR.

A megoldások közül a legegyszerűbb változatnak az RGBE tűnik, amely négy byteon tárolja el a HDR színt.
A be- ill. kitömörítő algoritmusa is gyors és egyszerű valamint az adatveszteség is minimálisnak tűnik.

A téli szünetben gondolkoztam azon, hogy a lightmap lumeljeihez lehetne rendelni irányt is. Szerencsére ez a technika már létezik (többféle) néven: directional lightmap.
A módszer azon alapszik, hogy minden lumelhez hozzárendelnek három, a tangens térben megadott konstans irányt majd a generáláskor ezt a három irányt felhasználva készítenek három lightmapet.

Ennek az a nagy előnye, hogy három, egy helyről mintavételezett lumel egy egyszerű képlettel (mivel az irányok konstansak a tangens térben) kombinálható a normal mappel. Ha az adott normál mindig felfelé néz megkapjuk a klasszikus lightmapot.

Azonban ha a normál vektor változik a tangens térben:

Láthatjuk, hogy a lightmap mellett a normal map felhasználásával visszaadhatjuk az apró, helyi részleteket is, amire csak nagyon nagy felbontású lightmap lenne képes, aminek memóriaigénye már igen jelentős lenne.

Végezetül néhány kép hagyományos és directional lightmappel.

A gpuval történő radiosity számítás legkényesebb része a félgömb renderelése. Ennek legkézenfekvőbb megoldása a halszem nézet használata. Gyakorlatban erre nagyon jó közelítést ad a paraboloid vetítés, amelynek van egy nagyon nagy hátránya. Mivel ez egy igen jelentős torzulással járó nem lineáris vetítés a gpura történő implementálást ez igen megnehezíti.
Egyedüli megoldás ha a felhasznált tartalom igen jól tesszellált. Amennyiben ilyen eset áll fenn, akkor érdemes igénybe vennünk a gpu hardveres tesszellátorát. A lenti eredményen jól látszik a vetítés okozta torzulás és a tesszellálás foka közti összefüggés:

Ezt a technikát alkalmazva a következő eredményt érhetjük el a radiosity generáláskor (a textúrázásban és a számításban még akadnak pontatlanságok ^^ ) :

Néhány példa a paraboloid vetítésre a kapott jelenettel:

A fenti képen látható, hogy még ez a nagyfokú háromszögesítés sem mindig nyújt tökéletes eredményt.

Ismét némi nyomozás (és a téli szünet) után megtapasztaltam, hogy a lightmap bizony nem az ördögtől való fogalom és egy kis trükkel "olcsón" kombinálhatók normal mappel.

Ennek fényében kutattam a lightmapkészítés témakörében és meg is született az első értékelhető változat. A lightmap unwrap után az árnyalás előállításához alig használtam matekot: egyszerű radiosity "számítás" raszterizálás segítségével. A lightmap nagyon alacsony felbontású és 2 iteráció futott le.

Ismét egy kis játékanatómia ezúttal Quake2 engine.

Amire kiváncsi voltam, hogy a dinamikus modellek árnyalását hogyan oldották meg. Jelen esetben azonban egy igen leegyszerűsített árnyalásról van szó, amivel nem is nagyon érdemes foglalkozni. Sokkal inkább azzal, hogy a modellre ható fény színét hogyan határozza meg az engine.

Kicsit elmélyülve a forráskódban a következőt találjuk:

void R_DrawAliasModel (entity_t *e)
{
  ...
  R_LightPoint
  GL_DrawAliasFrameLerp
  ...
}

ebből ami nekünk kell az az R_LightPoint

void R_LightPoint (vec3_t p, vec3_t color)
{
  ...
  RecursiveLightPoint
  ...
}

aminek az egyik lényegi része a RecursiveLightPoint függvény, amely a statikus fényt számítja ki / határozzza meg az adott ponthoz.
Ami pedig úgy történik, hogy

• bejárja hozzá a BSP fát
• megkeresi, hogy a pont melyik surface felett van
• meghatározza az így kapott ponthoz tartozó lightmap textúra koordinátákat
• kiolvassa a lightmapból a színt és ezt adja vissza végeredményül

A dinamikus fényekkel úgy tűnik sokkal kíméletlenebb: lineáris kereséssel ellenőrzi a fényforrásokat, hogy elég közel vannak-e és ha igen, akkor hozzáadja a végeredmény színhez a fényforrás modulált színét.

Kissé brute force-nak tűnik, de mint tudjuk ez már működött 200 MHz magasságában is...

A napokban elértem a 800. revíziószámot mivel ismét tettem egy kitérőt Q3 irányba. Egész pontosan a bsp-t vettem elő megint ill. annak a Q3-s megvalósításának Raven software által módosított verzióját.
Szerencsére csak pár (nem lényeges) különbség van az eredeti, Q3 verzióhoz képest így mindkettő támogatása ugyanazon kóddal megoldható. A Bullet hivatalos példáiban pedig megtalálható egy kimondottan Q3BSP-hez készült konvertáló, amely a brushok fizikai testekké való átalakítását valósítja meg.

Egyszóval minden adott a bsp újra-integrálásához, aminek az eredménye már látható is - ráadásul a nagy számú, Disney Star Warshoz készült mapoknak köszönhetően rendkívül sok helyszín válik elérhetővé és játszhatóvá: alant látható a chandrilai kanyon egy részlete.

Végre... Az első, 3D akciójáték jellegű szoftver ami kikerül a kezeim közül. Ahogy számoltam kb. 20 perc játékidőt nyújt a felhasználónak és háromféle játékstílust (találd meg, vidd oda, harc és túlélés) igyekszik megmutatni.

Még hátra van apróbb hibák javítása ill. készítek még egy statisztikát a játékben felhasznált elemek (szereplők, tárgyak, meshek, materialok stb) számosságáról.

Végső lépésként pedig egy "szabványos", érintőképernyőn megvalósított irányítás megvalósítása kerül sorra, hogy androidon is lehessen vele játszani.

Ezután pedig egy új projekt :)

A legutóbbi verzió már tartalmaz OpenAL támogatást vagyis nyomokban audio engine-t tartalmaz a rendszer. Egyelőre még a hangok / hangforrások különböző típusait kell összegyűjtenem ill. a fizikai engine-nel történő integrálás hiányzik.

Közben néhány optimalizációt alkalmazok elsősorban a térfelosztásban pl. lineáris keresés helyett logaritmikus ill. egyszerűsített konvex befoglalók.

Ezt követően Android update és talán iOS portolás.

Végül pedig az 1., 2. és 3. rész összevonása egy játékká.

Kb. ezeket fogja tartalmazni a 0.9.9 verzió.