HTML

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

Elsősorban játékfejlesztés magyarul: az enginem fejlesztése során felmerülő problémák, ötletek, tévutak stb dokumentálása, amely számomra és talán mások számára is hasznos lehet később Másodsorban gondolatok szavakban...

Kapcsolat:
aalberik 'at' gmail 'dot' com

Haletető

Galéria

Címkék

Összes

Linkblog

Naptár

május 2025
Hét Ked Sze Csü Pén Szo Vas
<<  < Archív
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

depth adaptive frustum cull

2009.04.25. 09:56 :: syam

12 órás alvás után, frissen és harmatosan tettre készen ideje implementálnom a "depth-adaptive frustum cull"-t. Nagyon remélem, hogy ez már beválik, mert elődje nem volt adaptív és emiatt csak bizonyos esetekben volt használható így összességében jelentősen rontott a teljesítményen belső terek esetén. Külső tereknél viszonylag jól be lehetett lőni és hatékonyan működött...

 

éééés iggeeeen, hi qualityben sikerült elérnem, hogy egy (igazán) nagy és összetett bsp esetén a fps 40 alá nem esik egy quadro fx570-n és ezzel együtt az égbolt láthatóság ellenőrzése is kész van.

Ha ezt még senki nem találta ki / valósította meg, akkor végre sikerült valami újat alkotnom^^.

Szólj hozzá!

ördögi terv

2009.04.24. 19:09 :: syam

Lelepleztem egy világméretű összeesküvést: hogyan befolyásolják a programozók tudatát...

C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\winnt.h(666) : fatal error C1189: #error :  Must define a target architecture.

Szólj hozzá!

lenni vagy nem lenni avagy hasonlítsunk nullával

2009.04.23. 19:14 :: syam

Vajon melyik megoldás a gyorsabb ha 32 bites integerekkel számolunk:

  1. result = (!a);
  2. result = (a == 0)

A választ disasm után kaphatjuk meg:

 

1.

005F775E xor eax,eax
005F7760 cmp dword ptr [ebp-18h],0
005F7764 sete al
005F7767 mov dword ptr [ebp-24h],eax

2.

005F7781 xor eax,eax
005F7783 cmp dword ptr [ebp-18h],0
005F7787 sete al
005F778A mov dword ptr [ebp-30h],eax

Vagyis MSVC++-szal fordítva, mindkét kód ugyanazt hajtja végre.

Most pedig nézzük ezt az esetet másképp:

  1. if( !i ) { ... }
  2. if( i==0 ) { ... }

1.

005F7747  cmp         dword ptr [ebp-18h],0
005F774B  jne         main+54h (5F7754h)

2.

005F7754  cmp         dword ptr [ebp-18h],0
005F7758  jne         main+61h (5F7761h)
Vagyis a két változat most is megegyezik.

 

Utoljára nézzük az utóbbi eset ellentétét:

  1. if( i) { ... }
  2. if( i>0 ) { ... }

1.

0044D4E1  cmp         dword ptr [ebp-18h],0
0044D4E5  je          main+5Eh (44D4EEh)

2.

0044D4EE  cmp         dword ptr [ebp-18h],0
0044D4F2  jle         main+6Bh (44D4FBh)

Az összes eset ugyanarra a kódra fordul vagyis nem érdemes trükközni.

Szólj hozzá!

váá

2009.04.22. 23:48 :: syam

Alapjaiban semmisült meg a frustum cullom kivitelezése. Itt van az ideje hatékonyabb dinamikus térvágás után néznem v kitalálnom...

Szólj hozzá!

"scene design"

2009.04.21. 22:27 :: syam

Azt hiszem most már elértem arra a szintre, hogy nagy méretű területet tudok optimálisan megjeleníteni megfelelő sebességgel (persze további optimalizálások még várnak rám). Következő lépés, hogyan lehet egy statikus környezetet "élővé" tenni. Vegyük szemügyre az alábbi képet:

Grafikailag körülbelül elfogadható a látvány azonban mégis sterilnek hat és a jelenet üresnek tűnik. Mondhatjuk azt, hogy nincsenek szereplők, de gondoljuk arra az esetre amikor rajtunk kívül senki nem tartózkodik a jelenet helyszínén. Hogyan csempészhetnénk bele azt a bizonyos "életet"?

Mindenféleképp dinamikát, mozgást kell vinnünk a jelenetbe, de csak olyat, amelyet maga a környezet ill. annak "működése" hoz létre. Ehhez azonban ismernünk kell a környezetet és annak funkcióját a jelenetben. Vegyük hát ismét szemügyre a képet. Egy scifibe illő helyszínt (egész pontosan egy 8472-s faj által megszállt borg kocka belseje) látunk, amely tartalmaz organikus és fém felületeket is. Próbáljuk összegyűjteni milyen lehetőségeket nyújthat a környezet maga:

  1. atmoszféra effektek - egy a légtérben szuszpendált anyag megjelenítését jelenti. Ez legtöbbször pára vagy füst. Leggyakoribb megvalósítása leggyakrabban az űn. volumetrikus renderelés.
  2. textúra animáció - ebben az esetben a textúra koordináták manipulálásával érhetünk animációt, mint pl. áramlás, forgás, torzulás ill. streamelt textúrák lejátszása.
  3. fény effektek segítségével már meglévő fényforrások paramétereit módosítjuk, mint pl. irány, fényerősség, szín esetleg pozíció.
  4. részecskerendszerek - a részecskerendszerek ezen típusához a kis térfogatot igénylő folyamatok tartoznak. Ilyen lehet szikra ill. különféle anyagok szivárgása stb.

Ezen típusok kombinálhatók is egymással. Leglátványosabb az 1. 2. és 3. eset eredménye, amikor a fénysugarakat (és árnyakokat) jelenítjük meg gomolygó ködben.

Remélem továbbiakban még támad ötletem és hamarosan valamelyik variációt sikerül is megvalósítanom...

Szólj hozzá!

dpsm

2009.04.19. 21:41 :: syam

Pár kép a dpsmről:

 

Szólj hozzá!

mindenható árnyéktérképek harca

2009.04.19. 21:14 :: syam

Ez a (kissé idétlenre sikeredett) cím az omni fényekkel együtt használható shadow mapekről szól. És hogy miért érdemes erről írni... Szerintem joggal tekinthető ez a legbonyolultabb esetnek.

Az omni fényforrások egyik tulajdonsága, hogy a tér minden irányába indulnak belőlük fénysugarak vagyis a fényforrás a teljes 360 fokos térszöget látja a környezetéből. Ez a tény -szokás szerint- a textúrázást alaposan megnehezíti és némi kutatás után rájövünk, hogy ez a probléma közös a dinamikus environment mapping témakörével vagyis hogyan képezzük le a teljes környezetet. Több lehetséges megoldás közül kiemelnék hármat:

  1. sphere mapping - ezen esetet nem tárgyalom, mert a vetítés rendkívüli torzítást igényel. Bár kétségtelen előnye, hogy mindössze egy textúrára az egész környezet leképezhető.
  2. dual paraboloid mapping
  3. cube mapping

 Most pedig következzen a 2. és 3. pontban említett típusok összehasonlítása.

 Dual paraboloid mappingCube mapping

A környezetet 

Vetítés

Mintavételezés

Torzítás

Szűrés

2 textúrával fedi le 

paraboloid

"visszavetítés" + térfél választás

jelentős

a 2 textúra találkozásánál hiányzik

6 textúrával fedi le 

hagyományos perspektív

egyszerű cubemap

közepes, főként a texturák találkozásánál

cubemap szűrés

 

Eddig úgy tűnik, hogy a cube mapping áll nyerésre leszámítva a 6 textúrát. Sőt ha belegondolunk a sm4.0 nyújtotta lehetőségekbe, akkor még az sem okoz igazán gondot.

A leglényegesebb gond azonban az, hogy potenciálisan költséges nagy méretű cubemapből mintavételezni. Ennek kiküszöbölésére dolgozták az ún. virtual cube mapet. Az egész trükk azon alapul, hogy a cubemap textúráit egy egyszerű megoldással kiterítik egy 2d textúrába, ahonnan viszont már gyors a mintavételezés. A kiterítésért cserébe szűrési hibák lépnek fel ill. egy textúra indirekció válik szükségessé és plusz egy textúra mintavétel. Az első mintavételezés egy kisméretű cubemapből történik, amely textúra koordinátákat tartalmaz és ezekkel férünk hozzá a következő mintavételezés során a kiterített valódi adatokhoz. Vcm esetén természetesen elveszítjük a cubemap szűrést.

Megemlítendő még, hogy a paraboloid mappingnek is van egy komoly hátránya. Jól tesszellált modelleket, jól tesszellált felületekre lehet vele vetíteni komolyabb vizuális hibák nélkül. Ez a vetítés paraboloid jellegéből fakad hiszen két vertex között lineáris interpoláció megy végbe, amely helytelen eredményhez vezet. Természetesen a vetítés és a mintavételezés is átvihető fragment oldalra és ezzel a probléma megszűnik "némi" teljesítménycsökkenés árán.

Most vessünk pár pillantást a mintavételezésre közelebbről.

Ez a dpm egyik térfelének a mintavételezése:

DP3 len_pos, pos, pos;
RSQ inv.x, len_pos.x;
MUL pos, pos, inv.x;
RCP len_pos, inv.x;

ADD pos_tex, pos, hemi0;
RCP inv.z, pos_tex.z;
MUL pos_tex.x, pos_tex.x, inv.z;
MUL pos_tex.y, pos_tex.y, inv.z;
MUL pos_tex.z, len_pos.z, light_pos.w;
MAD result.texcoord[1], pos_tex, half1, half0;

A felső pár sorban lévő normalizálást leválthatjuk egy textúra mintavételezésre, de még így kb. 8*2 utasítás lesz összesen a mintavételezéshez szükséges textúra koordináták előállítása. A mintavételezés pedig kb. 2 db 1024es vagy nagyobb textúrából történik majd.

A cubemap mintavételezés jóval egyszerűbb. A fényvektort ilyenkor nem is szükséges normalizálni, amellyel majd mintát veszünk a cubemapből. Ezután jön a valódi mintavételezés. Összeszámolva ez kb. 3 utasítás a teljes környezet leképezésére. A kiterített cubemap azonban tekintélyes méretű lehet: 6 db 1024es textúra egy 3*1024 x 2*1024es textúrába csomagolva. Ráadásul még egy hibát is tapasztaltam: a cubemap nem lehet akármilyen kicsi, mert a lineáris interpoláció a textúra koordinátákat a face-k szélen elrontotta az esetemben.

Lehetséges még közvetlen cubemapbe renderelés is azonban ilyenkor a mélységi összehasonlítás nem fog működni vagyis nekünk kell fragment programból megoldanunk. Sm4.0 gpuk már hardveresen meg tudják ezt oldani.

Mindent összevetve számos pro és kontra szól mindkét megoldás mellett és ellen vagyis jelenleg nem tudok dönteni. A vcm mellett szól a kevés utasítás, ellene pedig a nagy textúra és a körülményes renderelés. A dpm mellett szól a kis textúra viszonylag egyszerű renderelés ellene a sok utasítás...

 

Kiegészítés junius 5-én:

kimaradt pár utasítás a vcm megvalósításból:

Elő kell állítani azt a bizonyos r komponenst a mélységi összehasonlításhoz. Ehhez szükség van 2 dp4-re, 1 rcp-re és 1 mulra vagyis 3 utasításból lesz 7, amiből 3 nem "olcsó". Még a végén kiderül, hogy a dpm a jobb...

 

2 komment

Címkék: shadow map dpsm sphere mapping cube mapping dynamic environment mapping virtual cube map

lövés

2009.04.19. 15:44 :: syam

Mielőtt elkalandozna bárki fantáziája a címmel kapcsolatban itt egy játék engine-ben szerintem használható lehetséges technikákat szedem össze.

A felállás viszonylag egyszerű hiszen alapvetően két szempont szerint lehet osztályozni a lövedékeket: méret és sebesség alapján. Nézzük sorban a lehetséges kombinációkat:

  1. A legkönnyebb eset a kis méret és nagy sebesség. Gyakorlatban ez azt jelenti legtöbbször, hogy a lövedék annyira kicsi és nagy sebességgel mozog, hogy nem látjuk -csak az elsülés pillanatát vesszük észre- és lehetetlen kitérni előle -az elsülés pillanatában már be is csapódik. Tehát renderelni a lövedéket nem kell az ütközéshez pedig elég raycast (vagy sweep) vizsgálat.
  2. Második a sorban a nagy méret és (relative) alacsony sebesség. Ilyenkor azt feltételezzük, hogy egy frame alatti elmozdulás kisebb, mint a méret legkisebb dimenziója -vagyis elég nagy ahhoz, hogy mindennel érintkezni fog az útja során és nem ugrik át semmit. Rendelni ilyenkor a lövedéket szükséges. Ütközéshez a lövedék (konvex) befoglalóját érdemes használni esetleg egy mozgó, térbeli szakaszt mérettől és alaktól függően.
  3. A legbonyolultabb eset a (relative) nagy méret és nagy sebesség. Előző esetben a szimuláció diszkrét időközönkénti kiértékelése lassú mozgásnál gyakorlatilag folytonos mozgáspályát eredményezett itt viszont már akkora a sebesség, hogy a pálya térbeli pontokká esik szét vagyis a közbülső pontokat látszólag nem érinti a test. Ilyen esetben van szükség folytonos ütközésvizsgálatra (continuous collision detection, CCD). Renderelnünk itt is a lövedék modelljét szükséges.
  4. Gyanítom, hogy kis méretű, kis sebességű lövedékek nem léteznek. Speciális esetekben, mint pl bullet time a 2. eset jöhet szóba.

Megjegyzések:

1. esetben a kis méret legtöbbször az elhanyagolhatóan kis méretet jelenti ill. valamilyen nyalábot pl. lézer.

3. esetben pedig a méret már látható méretet jelenti, amely észrevehető sebességgel mozog. Lehetséges, hogy a CCD leváltható abban az esetben ha rendkívül kicsi mértékben léptetjük az időt. Valószínűleg a mai enginek már leginkább ezt, a 3. esetet preferelják.

 

Szólj hozzá!

deferred shading

2009.04.19. 14:27 :: syam

Eredményeimet dokumentálandó rakok fel néhány shotot is:]

 

Először egy kis technikai részlet - a gbuffer normal buffer része némi buggal:
A környezet a ST:VOY EF nevű kedvencemből származik...

 

  Itt pedig "sejtelmesen" (sötétre:)) árnyalva:

 

 És a 4. engine verseny angyala:
a környezet egy q3bsp olvasó teszt pályája

Szólj hozzá!

Címkék: deferred shading

happy hardcore + engine

2009.04.17. 18:39 :: syam

A fent említett két dolognak semmi köze nincs egymáshoz, csak a hangulatomat alapvetően befolyásolt eme zenei műfaj által...

 

Közeledik a hétvége és nem ártana előtte összeszedni a gondolataimat az engine-mmel kapcsolatban. Lassan elkészül a grafikai engine nagy része. Jelenlegi hiányosságai:

  • deferred occluder még mindig nincs kész
  • a tangent base nem tökéletes - 99%ban tökéletes
  • material kezelést befejezni
  • multi layer material
  • többféle fényforrás típus támogatása és ezzel kapcsolatban
  • árnyékok
  • transzparens felületek kezelése
  • light shaft
  • ssao, hdr
  • frustum cull, occlusion cull, rendezés javítása
  • env bump map

Ehhez kapcsolódó ötletek:

 

Akkor most jöjjön mit érdemes kezdeni a szerkesztővel:

  • Eltávolítani a gts-t, teljesen feleslegesnek tűnik, mivel saját 3d szerkesztő elkészítése teljesen értelmetlen. Tehát a támogatott tipusok a következők lennének: trimesh, terrain és mini-terrain. - kész
  • A renderelését kipofozni (textúrák!) és menüket rendberakni. - első menet kész
  • Importert írni a a half life bsphez.
  • Többi importerhez is megírni a material importot. - 3dshez már kész többi elvileg kész
  • Resource szerkesztő (ide tartozik a material is)
  • Szereplő szerkesztő - elsősorban a pozicio szerkesztés lenne hasznos.
  • SRI mentés és visszatöltés is jó lenne.

Mindezek után a modell kezelés jönne, majd animáció egybehangolva a fizikával...

 

javítva: 2009. április 19.

Szólj hozzá!

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