játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5440
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491

Butterfly Engine
Kategória: FPS, TPS, RPG, RTS
A projectről:
A Moonlight Studios C++/DirectX alapú játékmotorja, újratervezve, új alapokra építve.

Feautre-ök eddig:
------------------------
- Html log
- ZIP PackFile
- Hierarchikus világ
- MultiCam rendszer
- Bounding Sphere
- View Frustum Culling
- Material System
- HeightMap
- 3D hangrendszer
- Input (billentyű, egér, gamepad/joystick)

Feature-ök tervezve (egyelőre):
-----------------------------------------
- Saját Modell struktúra (multimesh, keyframe és bone animmal)
- Billboard, Particle System, SkySphere átírása a régiről
- X, OBJ, MD2, MD3 Importer
- Parallax Bump mapping
- Specular mapping
- Shadow mapping
- Reflection, Refraction
- Lens Flare
- LightBeam
- Occlusion Culling
- Octree
- Sprite-ok
- Bitmap font
- 2D, 3D Tile map
- LUA Scriptelés
- TCP/IP hálózat
- Konzol
- GUI
A project honlapja, letölthető verzió:
Fejlesztőeszköz, segédeszközök:
Visual C++ 2005, DirectX9, FMOD, LUA;

Fejlesztés kezdete: Tervezett befejezés:
2007 Szeptember 29
Beküldve:
2007.11.15 05:02
Fejlesztő:
Moonlight Studios (3 fő)
Elérhetőség:
A csapat honlapja
e-mail: orphy@moonlight-studios.hu
Tagok:
beküldő: Orphy
regisztrált tagok: ShAdeVampirE, Latka X-treme



Fejlesztés állapota:
Fejlesztés alatt
Fejlesztés alatt
Készültség: 20%

Képek - Butterfly Engine
Hierarchikus világ...
Hierarchikus világ...
2008.03.08. 04:58
Detail textúrával
Detail textúrával
2008.03.01. 09:48
Ne ködösíts...!
Ne ködösíts...!
2008.03.01. 08:12
A távoli hegycsúcs ködbe vész... Méghozzá 6x-os multisample-el.
A távoli hegycsúcs ködbe vész... Méghozzá 6x-os multisample-el.
2008.03.01. 07:23
Ugyanez a heightmap fullscreen-en...
Ugyanez a heightmap fullscreen-en...
2008.03.01. 05:55
Heightmap is ready to rock! :)
Heightmap is ready to rock! :)
2008.03.01. 05:46
Szép, új log :)
Szép, új log :)
2008.02.26. 14:23
Egy dal, s Te újra mellém ülsz...
Egy dal, s Te újra mellém ülsz...
2007.12.06. 13:06
Részecskerendszer - Füst - The God Of The Cows...
Részecskerendszer - Füst - The God Of The Cows...
2007.11.29. 12:12
Engine verseny 3 Detail - 550.000 Poly
Engine verseny 3 Detail - 550.000 Poly
2007.11.15. 05:09

Fejlesztési napló - Butterfly Engine
Orphy 2008.03.08. 05:29
Regisztráltunk YouTube-ra, így pár dolgot már mozgás közben is megmutatunk. :)

A hierarchikus világ, működés közben:
A NeHe-s kocka gyermeke a láda, a láda gyermeke a holdas kocka.

http://www.youtube.com/watch?v=pZdmpsDsGBU
Orphy 2008.02.03. 00:21
Végre elkészült a saját domain, így megváltozott a honlapunk címe is:

http://moonlight-studios.hu/
Orphy 2008.01.17. 12:43
Elkészült az új, a réginél jóval "okosabb" renderer.
ShAdeVampirE 2007.12.23. 12:16
Megvan az input kezelés is: win message-gel billentyűzet (irányítás és szöveg gépelés is van, irányításnál normál, egyből reagáló), egér (high res), gamepad/joystick (direct input és xinput támogatás, automatikus választással).
Orphy 2007.12.08. 09:21
Működik a View Frustum Culling!
Orphy 2007.12.02. 23:33


A részecskerendszeren a tervezett változtatásokat elvégeztem - a régi, C#-os sample update része teljesen kikerült, és felváltotta egy új, (szerintem) jobban átlátható rendszer.

A részecskékre most a következő erőket lehet megadni:
- Kezdeti sebesség
- Felhajtóerő
- Szél
- Gravitáció

Továbbá van egy Opposition nevő változó, amivel szabályozni lehet (a gravitációt kivéve), hogy a részecske korától függően mennyire álljon ellen a rá ható erőknek.
Orphy 2007.11.25. 09:34
Elkészült a részecskerendszer első működőképes verziója.
Ami nagyon tetszik benne, hogy NEM örökléses, hanem paraméterezhető, csupán egy ini file-t kell átírogatni...

A rendszer kiindulási alapját a következő C#-os sample adta meg:
http://www.programmersheaven.com/download/28782/download.aspx
Orphy 2007.11.21. 04:53
A hétvégén végigteszteltem és javítottam a világ hierarchikus rendszerét, most pedig végre van normálisan működő texture és material alpha blending, akár együtt is.

A két új képen ezeket mutatom be, plusz a hierarchikus világot:

A kisebbik kocka a nagyobbik kocka "gyermeke".
A nagyobbik kockát bárhogyan forgatom, nagyítom, elmozdítom, a kisebbik kocka relatív ugyanígy transzformálódik hozzá képest: együtt mozog a szülőjével úgy, hogy a hozzá képesti relatív helyzetét megtartja!


Szerk:
A világgal kapcsolatban még 1 apró megjegyzés:
A camera a világ része - ugyanígy rárakható egy világbeli objektumra, képes azzal együtt mozogni.
A világban több camera is lehet, de egyszerre csak az egyik képét renderelem (multicam).
Orphy 2007.11.15. 05:12
A motor nevezett a 3-ik engine versenyre, összefoglaló itt:

http://legendgrafix.buzz.hu/archives/2007/11/12/3_engine_verseny/#comments
Orphy 2007.11.15. 05:10
Moonlight Studios - Butterfly Engine

Hozzászólások - Butterfly Engine
Orphy - Törzstag | 1893 hsz       Online status #83609   2008.03.21 00:32 GMT+1 óra  
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.
   
Orphy - Törzstag | 1893 hsz       Online status #83224   2008.03.14 09:44 GMT+1 óra  
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.
   
TPG - Tag | 3402 hsz       Online status #82870   2008.03.08 13:40 GMT+1 óra  
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.
Kód:
MusicSystem.LoadMusicFile("[09] Lifting Shadows Off a Dream.flac");
MusicSystem.StartMusic("[09] Lifting Shadows Off a Dream.flac");
Reality is almost always wrong. - House

   
Orphy - Törzstag | 1893 hsz       Online status #82869   2008.03.08 13:21 GMT+1 óra  
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
   
Asylum - Törzstag | 5440 hsz       Online status #82866   2008.03.08 12:28 GMT+1 óra  
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)

Ezt a hozzászólást Asylum módosította (2008.03.08 12:35 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82850   2008.03.08 05:25 GMT+1 óra  
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
   
Orphy - Törzstag | 1893 hsz       Online status #82848   2008.03.08 05:04 GMT+1 óra  
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...
   
Orphy - Törzstag | 1893 hsz       Online status #82643   2008.03.04 01:12 GMT+1 óra  
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.

   
Orphy - Törzstag | 1893 hsz       Online status #82565   2008.03.02 00:59 GMT+1 óra  
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.
   
DMG - Szerkesztő | 3172 hsz       Online status #82563   2008.03.02 00:39 GMT+1 óra  
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.
-----------------------------------------
Dont Listen to the Naysayers
   
Orphy - Törzstag | 1893 hsz       Online status #82562   2008.03.02 00:19 GMT+1 óra  
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...
   
gaborlabor - Moderátor | 4449 hsz       Online status #82557   2008.03.01 13:10 GMT+1 óra  
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.

   
DMG - Szerkesztő | 3172 hsz       Online status #82555   2008.03.01 12:10 GMT+1 óra  
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.

Ezt a hozzászólást DMG módosította (2008.03.01 12:15 GMT+1 óra, ---)
-----------------------------------------
Dont Listen to the Naysayers
   
Orphy - Törzstag | 1893 hsz       Online status #82536   2008.03.01 05:58 GMT+1 óra  
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.
   
Orphy - Törzstag | 1893 hsz       Online status #82535   2008.03.01 05:47 GMT+1 óra  
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

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #82528   2008.02.29 23:41 GMT+1 óra  
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

Ezt a hozzászólást ShAdeVampirE módosította (2008.02.29 23:55 GMT+1 óra, ---)
   
DMG - Szerkesztő | 3172 hsz       Online status #82526   2008.02.29 23:32 GMT+1 óra  
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.
-----------------------------------------
Dont Listen to the Naysayers
   
Orphy - Törzstag | 1893 hsz       Online status #82524   2008.02.29 22:58 GMT+1 óra  
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...
   
Asylum - Törzstag | 5440 hsz       Online status #82520   2008.02.29 16:24 GMT+1 óra  
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
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82514   2008.02.29 12:15 GMT+1 óra  
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...
   
Asylum - Törzstag | 5440 hsz       Online status #82513   2008.02.29 12:02 GMT+1 óra  
ööö nem, a betöltésre értettem
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82506   2008.02.29 11:07 GMT+1 óra  
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?
   
Asylum - Törzstag | 5440 hsz       Online status #82504   2008.02.29 10:36 GMT+1 óra  
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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82497   2008.02.29 02:11 GMT+1 óra  
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é...
   
ferchild - Törzstag | 815 hsz       Online status #82453   2008.02.28 08:25 GMT+1 óra  
multkor beast linkelt egy igen jó kis pdf-et színtérgráfokra. Assszem az engine programozás topikban van.
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Asylum - Törzstag | 5440 hsz       Online status #82450   2008.02.28 06:53 GMT+1 óra  
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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
DMG - Szerkesztő | 3172 hsz       Online status #82442   2008.02.28 03:27 GMT+1 óra  
Örülök, hogy ennyivel is hozzá tudtam járulni a fejlesztéshez.

Na jó ez azért erős volt.
-----------------------------------------
Dont Listen to the Naysayers
   
Orphy - Törzstag | 1893 hsz       Online status #82437   2008.02.28 01:53 GMT+1 óra  
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...
   
DMG - Szerkesztő | 3172 hsz       Online status #82436   2008.02.28 01:40 GMT+1 óra  
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.
-----------------------------------------
Dont Listen to the Naysayers
   
Orphy - Törzstag | 1893 hsz       Online status #82435   2008.02.28 00:00 GMT+1 óra  
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...
   
Asylum - Törzstag | 5440 hsz       Online status #82434   2008.02.27 15:48 GMT+1 óra  
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.)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82431   2008.02.27 14:52 GMT+1 óra  
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
   
Lord_Crusare - Törzstag | 1286 hsz       Online status #82429   2008.02.27 14:46 GMT+1 óra  
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.

   
Orphy - Törzstag | 1893 hsz       Online status #82413   2008.02.27 12:21 GMT+1 óra  
Elképzelhető, holnap megnézem, hogyan reagál a céges gép az új kód fordítására...
   
DMG - Szerkesztő | 3172 hsz       Online status #82410   2008.02.27 11:51 GMT+1 ó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?
-----------------------------------------
Dont Listen to the Naysayers
   
Orphy - Törzstag | 1893 hsz       Online status #82409   2008.02.27 11:47 GMT+1 óra  
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
   
Latka X-treme - Törzstag | 311 hsz       Online status #82407   2008.02.27 11:39 GMT+1 óra  
A céges gépeden a labirintusos játékom is bedobta a törölközőt, pedig egy alap OpenGL program.
   
Orphy - Törzstag | 1893 hsz       Online status #82401   2008.02.27 10:22 GMT+1 óra  
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...
   
beast - Törzstag | 1241 hsz       Online status #82395   2008.02.27 08:42 GMT+1 óra  
Ez ilyen tipikus z buffer hibának tűnik igy elsőre. Milyen near-far értékeket használsz a vetitésnél?

   
Orphy - Törzstag | 1893 hsz       Online status #82394   2008.02.27 08:19 GMT+1 óra  
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...

Ezt a hozzászólást kicsy módosította (2008.02.29 06:44 GMT+1 óra, ---)
   
fpeti - Törzstag | 1280 hsz       Online status #82393   2008.02.27 08:18 GMT+1 óra  
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!
   
Orphy - Törzstag | 1893 hsz       Online status #82375   2008.02.27 04:29 GMT+1 óra  
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
   
Asylum - Törzstag | 5440 hsz       Online status #82366   2008.02.27 03:20 GMT+1 óra  
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).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82349   2008.02.27 00:04 GMT+1 óra  
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.
   
Orphy - Törzstag | 1893 hsz       Online status #82348   2008.02.26 23:50 GMT+1 óra  
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
   
Kuz - Törzstag | 4455 hsz       Online status #82346   2008.02.26 18:19 GMT+1 óra  
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...)
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
beast - Törzstag | 1241 hsz       Online status #82344   2008.02.26 17:10 GMT+1 óra  
OpenGL-lel lehet npow textúrákat is ati-val, bibibiiiiiii.
(gondolom r9600-zal)

   
Kuz - Törzstag | 4455 hsz       Online status #82340   2008.02.26 14:35 GMT+1 óra  
Kira a log-os kép. Milyen jó is lett volna tudni annó, hogy az Ati-k csak Pow2 textúrákat szeretnek...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Orphy - Törzstag | 1893 hsz       Online status #82276   2008.02.26 04:08 GMT+1 óra  
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.
   
Orphy - Törzstag | 1893 hsz       Online status #82038   2008.02.22 01:19 GMT+1 óra  
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.

   
> 1 < [2] [3] [4] [5]
Korábbi postok