játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5444
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:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] > 2 < [3] [4] [5] [6] [7] [8]
danó - Tag | 13 hsz       Online status #122006   2009.11.17 04:14 GMT+1 óra  
Sziasztok!

A segítségeteket szeretném kérni. Egy játékot írok (actionscript 3.0) a kérdésem a következő lenne: A hangokat a freesound.org oldalról töltöm és ha esetleg értékesíteni szeretném akkor kell-e fizetnem a használatért valamennyit? előre is köszi a választ!
   
Bitsculptor - Tag | 188 hsz       Online status #110788   2009.05.22 07:54 GMT+1 óra  
Én majd nemsokára felpakolok az új website-ra médiákat meg demót , meg majd csinálok vele music videót is youtube-ra promóciónak
De a 'RUSH' esetében nem kell nagy grafikára számítani, én tényleg a kecsapra meg a hatalmas létszámra gyúrok rá.

   
xanat - Tag | 489 hsz       Online status #110787   2009.05.22 07:50 GMT+1 óra  
ahogy igy olvasom ezek nemsemmi dolgok! legalabbis szamomra biztosan csak almodni tudok ilyenrol! esetleg majd valami kep/video/demo elerheto valahonnan?
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Bitsculptor - Tag | 188 hsz       Online status #110786   2009.05.22 07:45 GMT+1 óra  
Igen-igen de ez stílus függő FPS-en belül is. A COD azért mégiscsak egy komolyabb játék tartalmilag is meg egyáltalán. Én egy Crimsonland szerű játékot írok FPS-ben, és épp elég baja lesz a játékosnak amikor kifogy a minigun és már'csak' párszáz szörny veszi körbe

Nálam a fizika addig fog tartani amég kilehet használni. Pl: Ha beleugrasz a tömegbe akkor fellökheted a szörnyeket vagy akár össze is nyomhatod őket attól függően hogy milyen a karaktered. Nameg célzás: A karakter ereje dönti el hogy mennyire rángatózik a kamera egyes fegyvereknél pláne lövés közben.

Ezen túl még a rakétáknak és ballisztikus projectile-oknak lesz fizikájuk meg a repkedő testrészeknek

Ezt a hozzászólást Bitsculptor módosította (2009.05.22 08:02 GMT+1 óra, ---)

   
xanat - Tag | 489 hsz       Online status #110785   2009.05.22 07:35 GMT+1 óra  
az szerintem azert kell. En is meg fogom csinalni, mert most ami volt ugras (en is kiszedtem a terrain miatt, ujragondoltam ugyebar... ), hogy ahogy felugrottam, akkor ugye kozben nem lehetett a levegobe helyzetet valtoztatni, de ahogy megerkeztem, azonnal tudtam mozogni. Namost ha belegondolsz, ez akarhogy is probalkozol, lehetetlen. ez mar a cod1-ben is benne volt, hogy ugras utan egy nagyon pici ideig meg nem tudsz mozogni, szerintem kell.
(vagy nem erre gondoltal? )
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
gaborlabor - Moderátor | 4449 hsz       Online status #110784   2009.05.22 07:35 GMT+1 óra  
Hát szerintem ha alapvetően nem szimulátort írsz, hanem játékot, akkor a játszhatóság fontosabb, mint az, hogy túlságosan valósághű legyen. Csak addig próbáld meg leutánozni a valóságot, amíg az nem megy a játszhatóság, játékélmény rovására. Pl. egy összevissza rángatózó kamera esetében nem biztos hogy hű de kényelmes a célzás, pl egy FPS-ben.

   
Bitsculptor - Tag | 188 hsz       Online status #110782   2009.05.22 07:31 GMT+1 óra  
Én eddig a valósághű mozgást próbáltam csinálni a kamerával:
Jobb láb - Bal láb és persze az adott irányban headbobbing + weaponsway. Kicsit nagyon bugos volt a lejtőkön a lépkedés lefelé mert gyakorlatilag sose ért le a karakter lába
De kérdés az, hogy megéri-e ilyen részletesen belemenni ebbe egy Crimsonland stílusú játéknál..
Már kiszedtem belőle a tehetetlenségi erőt is ami futás/ugrás közben hatott a kamerára.. Nemkellettvolna?

   
gaborlabor - Moderátor | 4449 hsz       Online status #110780   2009.05.22 07:26 GMT+1 óra  
hát a lépcsős az annyi, hogy ha "remeg" a kamera, akkor kicsivel talán életszerűbb, de szvsz elég idegesítő. ezért a legtöbb játékban gyakorlatilag egy olyanon mész fel, mint amit a tolószékeseknek szoktak építeni. csak nem látszik. gondolom ezt lehet alkalmazni egész pályás terepre is.

   
xanat - Tag | 489 hsz       Online status #110779   2009.05.22 07:22 GMT+1 óra  
ja jo otlet, en is igy hasznalom (vagyis csak fogom, eppen ezen dolgozgatok tengnap ota... vagyis csak agyalok - jobb megtervezni elore... )
amugy a lepcsos tenyleg jo, es a cod2-ben (de azthiszem a cod4-ben) se figyeltek erre! remegek mint allat, ha megyek le a lepcson...
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Bitsculptor - Tag | 188 hsz       Online status #110775   2009.05.22 06:35 GMT+1 óra  
gaborlabor: Ez kurvajó ötlet! Nekemis megoldást jelentene pár bughoz a játékomban
kösssz!

   
gaborlabor - Moderátor | 4449 hsz       Online status #110774   2009.05.22 06:32 GMT+1 óra  
Kuz: és mi lenne, ha a kettőt együtt használnád? Hogy pl a pálya maga modellekből lenne kirakva, még a talaj is, viszont lenne egy heightmap, ami nem teljesen ugyanolyan, mint a talaj modellje, hanem egy kicsit elsimítottabb változata. Mert azt mondod, nagyon göcsörtös a talaj. Akkor viszont a hagyományos módszerrel marhára rángatózna, ugrálna a kamera. (Nem véletlen, hogy pl a lépcsőkre is egy láthatatlan síkot szoktak tenni, hogy ne legyen idegesítő). Akkor a mozgást meg lehetne csinálni a heightmap alapján, a terepet viszont nem az alapján rajzolnád ki.

   
xanat - Tag | 489 hsz       Online status #110773   2009.05.22 06:26 GMT+1 óra  
pont errol volt szo a "Matematika" topicban.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Bitsculptor - Tag | 188 hsz       Online status #110772   2009.05.22 06:26 GMT+1 óra  
Milyen nyelvben írod?

   
Kuz - Törzstag | 4455 hsz       Online status #110771   2009.05.22 06:22 GMT+1 óra  
Hát lehet, hogy akkor maradok az egyszerűbb megoldásnál, és heightmapből csinálom a terepet, mert ott könnyebb lekezelni a lépegetést (ami sík terepen fog zajlani), és minden, ami nem x magasságon van, oda nem lehet menni. Csak kérdés, hogy ezzel mennyire nehezítem meg a pályakészítést. Mert lehet, hogy egyszerűbb lenne sima modellekkel megépíteni a pályát, csak nem tudom hogy lehet visszaadni az adott karakter alatti terület értékeit (főleg a magasságot), pláne akkor, ha a talaj teljesen egyenetlen? Szóval még gondolkodok...
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???

   
Bitsculptor - Tag | 188 hsz       Online status #110769   2009.05.22 05:09 GMT+1 óra  
Én pl most Heightmap-es módszerrel írtam a DBP-ben a mátrix-os megoldást a terepre. Itt nincsenek bounding box-ok, csak koordináták, pl a csúszást úgy oldom meg, hogy a következő lépés koordinátáját adott irányban összehasonlítom a jelenlegivel, és megállapítom a 2 pont közötti magasságkülönbséget (meredekséget). Ha magasabban van a kamera mint a következő érték akkor tud lefelé csúszni.
A másik irányt azért vizsgálom, hogy meghatározzam, tud-e a player olyan magasra lépni mint a köv lépés.
Amúgy én pont most délelőtt egészítettem ki a tilemap editoromat heightmap feature-el, ami már kompatibilis file-t exportál DBP-hez. Majd meló után kiegészítem Accessability-vel és ezennel kész a DeltaForce engine-je

   
Kuz - Törzstag | 4455 hsz       Online status #110759   2009.05.21 13:48 GMT+1 óra  
Idézet
Bitsculptor :
Nembiztos, hogy jól értelmezem a mászkálás problémát, de elsőre az ugrott be, amit még annó a RedAlert pályaszerkesztőjében láttam és azóta is alkalmazom collision helyett is:
Az adott pályához csinálok egy Accessibility mátrix-ot amiben a player koordinátái határozzák meg, hogy lehet-e ott vagy sem, illetve egyéb dolgokat amit megadhatsz neki..


Maga a collision biztos, hogy kell, így ezt nem is terveztem kihagyni. A gond maga a pálya alapjának elkészítése. Közben beszéltem a modelezőmmel, és többféle dolgot mondott. Pl.:
- A kész modelből (mármint talajból) lehet heightmap-et generálni maxban, és azt lehet használni kódból.
- A mászkáláshoz külön láthatatlan modeleket, mint boxokat szoktak használni. Ezek a boxok mondják meg, hogy valahol "át lehet-e menni", vagy nem. A CoD4-ben is vannak ilyen boxok.
- Collisionhöz egyelőre boundingboxot használok, de komolyabb játéknál le kell tudni kezelni olyan alakzatokat is, amiket a végeredmény szempontjából nem lehet boundingbox-szal kezelni (pl lecsúszás a hegyoldalról, barlang bejárat, etc).

Jelenleg azt nem tudom hogy érdemes betölteni, illetve eleve elkészíteni egy talajt. A heightmapot itt azért skippelném, mert azt nem én textúrázom le, hacsak nem lehet valahogy készíteni hozzá egy olyan másik mapot, ami alapján a shaderben össze tudom keverni a megfelelő talaj textúrát. Ez most jutott eszembe, még gondolkodok rajta. Azért jöhetnek az ötletek, hogy mit látok rosszul, mert biztos van ilyen.
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???

   
aaaa - Tag | 26 hsz       Online status #110732   2009.05.21 10:29 GMT+1 óra  
a voxeleket mindenképp tömöriteni kell , a legjobb modszer az hogyha fogsz egy voxel kockát és betömörited jpg-el(dct) vagy wavelettel
igy az 1:10,1:20-as arányt el lehet érni

   
sirpalee - Tag | 1282 hsz       Online status #110731   2009.05.21 09:58 GMT+1 óra  
Idézet
nadam :
sirpalee:
egyszer elég lesz hozzá a hardver, csak azt nem tudjuk, hogy 2 év múlva, vagy 4 évmúlva, vagy esetleg még több. (bár nem hiszem, hogy annyira soká, elég nagy verseny van most a hardver piacon.) Addig van idő finomítgatni az algoritmust, legalább nem kell kapkodni



Oksa, ahogy érzed . Én inkább próbálom kihasználni a tesszalációt. Legrosszabb esetben mehet SVO, de nem akarok csak egyetlen dologra építeni, szerintem nagy lehetőség van a patch felületekben, kevés adat kell hozzá, a hardver meg irtó gyorsan kezeli .
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #110730   2009.05.21 09:53 GMT+1 óra  
sirpalee:
egyszer elég lesz hozzá a hardver, csak azt nem tudjuk, hogy 2 év múlva, vagy 4 évmúlva, vagy esetleg még több. (bár nem hiszem, hogy annyira soká, elég nagy verseny van most a hardver piacon.) Addig van idő finomítgatni az algoritmust, legalább nem kell kapkodni
   
sirpalee - Tag | 1282 hsz       Online status #110728   2009.05.21 09:49 GMT+1 óra  
Én meg utánaszámoltam ennek az üvegkalitkás módszernek, iszonyú mennyiségű mátrix számítás kell hozzá. Inverz számítások, és nem elég pozíciót számolnod az alacsony felbontású részre, hanem forgást is. Ahhoz tudni kell a közeli vertexek pozícióit stb... Szerintem keress más módszert, ez így első körben utánagondolva, bukta lesz. Első körben persze, lehet jobban bele kéne gondolni.
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #110727   2009.05.21 09:46 GMT+1 óra  
sirpalee:

Valóban, a cucc mérete fontos kérdés.
Kétféle reprezentációról lehet beszélni:

Az egyik a full tömörített változat, amit a winchesterről streamelek igény szerint. Még nincs kész a tömörítőalgoritmusom, de ez még full tömörítve is nagy tétel lesz. Egy sok négyzetkilométeres világ nem férne el 2 DVD-n sem. Ezért komponenseket használok majd, nem lesz teljesen egyedi a világnak minden egyes kis része, hanem egy csomó minden újrafelhasználható lesz. (Egy ezer fás erdőben mondjuk csak 50 különböző fa lesz.) Ez a komponensekből építkezés amúgyis jól összeegyeztethető a procedurális generálási törekvéseimmel.

Azt látni kell, hogy az octree miatt hálistennek az SVO mérete sem a testek térfogatával arányban növekszik (az durva lenne), hanem a felszínével arányosan, hiszen a tér nagy része üres. Így aztán kb. a nagyon részletes poligonos reprezentációval egy nagyságrenbe tippelem a tömörített cucc méretét, sőt ki tudja mit hozok ki a tömörítőalgoritmusból.

A másik a runtime reprezentáció mérete. Runtime minden csak a szükséges részletességgel van bestreamelve. A kamerától 2 méterig van csak betöltve a cucc teljes részletességében, 4 méterig már csak fele részletességgel, 8 méterig megint a fele, stb... Gyakorlatilag csak a világ méretének logaritmusával nő a szükséges memória mérete, így számításaim szerin kb. 1 gigabyte 'should be enough for everything', egyszerűen nem kell több még több kilométeres drawing distance esetén sem. Esetleg a geometrialilag nagyon komplex objektumok, mint fűcsomók, fa lombkoronák kissé bekavarhatnak. Persze ezek még csak előzetes becslések, ne vedd őket készpénznek.
   
sirpalee - Tag | 1282 hsz       Online status #110726   2009.05.21 09:32 GMT+1 óra  
Idézet
nadam :
sirpalee:

Megoldom a karakteranimációt is: 'skeletal refraction'-nal.
Ezt úgy képzeld el, hogy a karakter elkészült SVO modelljét egy képzeletbeli üvegkalitkába rakod bele. Az üvegkalitka egy viszonylag kevés poligonból álló mesh, ami körülveszi a modellt.

A játéktérben ezt az üvegkalitkát animálom csak. Amikor ray-tracelek, és egy sugár bejut a kalitkába, akkor a bejövés pontjából és irányából kiszámolom, hogy az eredeti nem animált 'model local space'-ben, ahol a kalitka az eredeti állapotában van, ez minek felel meg, és ott folytatom tovább a tracelést a model-local space-ben. Olyan mint a relativitáselmélet: amikor kell koordinátarendszert váltok, ahelyett, hogy voxelek millióit valóban mozgatnám. (Remélem valamennyire érthetően írtam le az algoritmust.)

Amúgy elismerem ez az egész SVO nagyon kockázatos dolog, de így legalább kisebb a konkurrencia (az ID Soft-os Jon Olick-on kívül nem is tudom, hogy más foglalkozik-e vele komolyabban, és még ő is elég limitáltan használja egyelőre.)



Értem.

A gondok akkor lépnek fel itt, ha átlátszó az objektumod és folyton ki-be lépeget az üvegkalitkából, illetve ha az üvegkalitka részek egymásba lógnak. Az már nem olyan szép. Plusz árnyékok, stb... Szerintem ha megnéznénk sebességben, egy tesszalált karakter jól mappelve, sokkal gyorsabban rajzolódna ki mint egy SVO.

Persze gondolom két részben csinálod, nincs minden beleégetve az SVO-ba, sok kis tracelhető SVO objektumod van.

Ami még engem zavar benne, túl nagy méretű, sima polygonos megoldásnál ott van egy sima micro polygon displacement, és ugye a tesszaláció lehetősége is, amivel sokkal egyszerűbb a LOD-olás, stb...

Tényleg, egy átlag karakterre mekkora SVO mérettel számolsz? Ha tesszalációt használsz, akkor a karakter váz 4-5ezer poly max, aztán + pár mega map (okosan tömörítve).

Amire szükség van minden cellában, az a normal érték, és a color, specular erőssége, felületi roughness, átlátszóság stb. Azért az nem kevés adat, még 8 bit / csatornával sem számolva. Elvileg az SVO-nak az lenne a lényege, hogy egyszerre octree és egyszerre adat is. Ahhoz hogy meghatározd hol van a következő octree egység, és megmond fel van-e osztva, tegyük fel hogy kell 32 bit. Tehát ennyibe kéne belesűríteni a fent említett értékeket.
raytraceisten és übermedic
   
Bitsculptor - Tag | 188 hsz       Online status #110725   2009.05.21 09:20 GMT+1 óra  
Ehh akkro ez csak RTS-eknél járható módszer ilyen formában

Ebben az esetben:
Mátrixnál hogy lehet beállítani, hogy a cellákon ne külön külön legyen ugyanaz a textúra, hanem a textúrámat egy az egyben húzza rá a mátrixra?

Még1 kérdés:
decal-t tudok rayzolni a cella textúráyára?

   
nadam - Törzstag | 364 hsz       Online status #110724   2009.05.21 09:18 GMT+1 óra  
sirpalee:

Megoldom a karakteranimációt is: 'skeletal refraction'-nal.
Ezt úgy képzeld el, hogy a karakter elkészült SVO modelljét egy képzeletbeli üvegkalitkába rakod bele. Az üvegkalitka egy viszonylag kevés poligonból álló mesh, ami körülveszi a modellt.

A játéktérben ezt az üvegkalitkát animálom csak. Amikor ray-tracelek, és egy sugár bejut a kalitkába, akkor a bejövés pontjából és irányából kiszámolom, hogy az eredeti nem animált 'model local space'-ben, ahol a kalitka az eredeti állapotában van, ez minek felel meg, és ott folytatom tovább a tracelést a model-local space-ben. Olyan mint a relativitáselmélet: amikor kell koordinátarendszert váltok, ahelyett, hogy voxelek millióit valóban mozgatnám. (Remélem valamennyire érthetően írtam le az algoritmust.)

Amúgy elismerem ez az egész SVO nagyon kockázatos dolog, de így legalább kisebb a konkurrencia (az ID Soft-os Jon Olick-on kívül nem is tudom, hogy más foglalkozik-e vele komolyabban, és még ő is elég limitáltan használja egyelőre.)
   
sirpalee - Tag | 1282 hsz       Online status #110723   2009.05.21 09:16 GMT+1 óra  
Idézet
Bitsculptor :
Sirpalee:
Lejjebb kerülő cellára gondolok. Tudod mint a tiberian sun-ban volt nagyobb robbanásoknál
Csak az nagy cellák esetében pontatlan mert attól hogy egy 10mx10m-es cella egyik sarkában felrobban valami, nemfog az átellenes sarok is lejjebb kerülni.



Jó de te polygon alapú terepet használsz? Akkor azt a részt újra kell generálni kb, de ehhez az a legegyszerűbb ha indexelt vbuffer-t használsz, csak az a baj, ha statikus terepet használsz, ez nem olyan egyértelmű.

Amit te cellákra gondolsz, az egy heightmap ilyen terep esetében, és ott nem tudsz kisebb részletességre lemenni.
raytraceisten és übermedic
   
Bitsculptor - Tag | 188 hsz       Online status #110722   2009.05.21 09:12 GMT+1 óra  
Sirpalee:
Lejjebb kerülő cellára gondolok. Tudod mint a tiberian sun-ban volt nagyobb robbanásoknál
Csak az nagy cellák esetében pontatlan mert attól hogy egy 10mx10m-es cella egyik sarkában felrobban valami, nemfog az átellenes sarok is lejjebb kerülni.

   
gaborlabor - Moderátor | 4449 hsz       Online status #110719   2009.05.21 09:08 GMT+1 óra  
Szerintem minden modell legyen külön, és azokból lehet építkezni akkor. Csak annyi, hogy akkor írni kell egy pályaszerkesztőt is, de az talán nem vészes. Több előnye is van, pl minden modell újrahasznosítható, mert biztos vannak olyan dolgok (tereptárgyak, növényzet, pár épület) amik ismétlődhetnek pályánként. Meg könnyebb is módosítani a pályákat, ha csak átrendezni szeretnéd az elemeket. Plusz ha minden modell külön van, akkor szerintem könnyebb a frustum cullingot is megírni,a térfelosztást is, meg lehet objektumonkénti LOD.

   
sirpalee - Tag | 1282 hsz       Online status #110718   2009.05.21 09:05 GMT+1 óra  
Idézet
Bitsculptor :
Apropó rombolás:
Mátrix esetében megoldható, hogy robbanáskor NE az egész adott cella kerüljön lejjebb, hanem csak mongyuk felosztható legyen 4 újabb háromszögre, amiknek a találkozása a robbanás pontja a cellában?



Hogy érted ezt a mátrixos dolgot? Hirtelen nem vagyok képben. Lejebb kerülő cella?

Vagy octree-re gondolsz? Bocs kicsit elvesztem hirtelen .
raytraceisten és übermedic
   
Bitsculptor - Tag | 188 hsz       Online status #110717   2009.05.21 09:02 GMT+1 óra  
Idézet
sirpalee :
Nekem egy bajom van az SVO-val : Animáció. Én full dinamikusra és rombolhatóra akarok csinálni mindent... Ott meg az SVO bukta.



Apropó rombolás:
Mátrix esetében megoldható, hogy robbanáskor NE az egész adott cella kerüljön lejjebb, hanem csak mongyuk felosztható legyen 4 újabb háromszögre, amiknek a találkozása a robbanás pontja a cellában?

   
sirpalee - Tag | 1282 hsz       Online status #110716   2009.05.21 08:58 GMT+1 óra  
Idézet
nadam :
....



Nekem egy bajom van az SVO-val : Animáció. Én full dinamikusra és rombolhatóra akarok csinálni mindent... Ott meg az SVO bukta.
raytraceisten és übermedic
   
Bitsculptor - Tag | 188 hsz       Online status #110715   2009.05.21 08:48 GMT+1 óra  
Nembiztos, hogy jól értelmezem a mászkálás problémát, de elsőre az ugrott be, amit még annó a RedAlert pályaszerkesztőjében láttam és azóta is alkalmazom collision helyett is:
Az adott pályához csinálok egy Accessibility mátrix-ot amiben a player koordinátái határozzák meg, hogy lehet-e ott vagy sem, illetve egyéb dolgokat amit megadhatsz neki..

   
xanat - Tag | 489 hsz       Online status #110714   2009.05.21 08:46 GMT+1 óra  
a novenyesdire:
http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series4/Region_growing.php
itt is valami ilyesmit hasznalnak, csak billboarddal.
Amugy a kerdesek engem is erdekelnenek.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Kuz - Törzstag | 4455 hsz       Online status #110713   2009.05.21 08:42 GMT+1 óra  
Elnézést, hogy picit megbontom a témát, de lenne egy kérdésem.
Egy 3D-s mászkálós (TPS-style) játékot kezdtem el kigondolni, és érdekelne, hogy magát a pályát hogy érdemes megcsinálni? Elvileg ugye két lehetőség van :
- modelező progiban összerakom a teljes pályát/pályarészt, és kimentem egy nagy modelként,
- minden objektumot külön modelezek le, és ezeket egyesével töltöm be.
A gond számomra - mivel nem ismerem az ide vonatkozó technikákat -, hogy nem tudom megmondani mely pályarészeken lehet menni, és mely részeken nem. Addig oké, hogy az ütközésdetektálást meg tudom csinálni, de az ilyen mászkálásra vonatkozó dolgokat hogyan lehet megoldani?
Van még egy olyan kérdésem is, ami ehhez tartozik, hogy arra gondoltam, hogy a növényzetet heightmap-szerű megoldással csinálnám meg, azaz befestem a textúra azon részeit x színre, ahol fű van, y színre, ahol fa van, etc. Ezt figyelembevéve (és a fenti mászkálós dolgot) milyen technikát érdemes erre használni (próbálkozni nem akarok, hogy félúton kiderüljön, hogy nagyon rossz úton járok ).
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???

   
nadam - Törzstag | 364 hsz       Online status #110707   2009.05.21 08:09 GMT+1 óra  
Idézet
aaaa :
ja és a másik dolog amit elfelejtettem irni a technologiához, maradjunk a cryteknél , ök megtehetik hogy az enginjük lecsutkázza a mai csucshardvereket, eleve ugy fejlesztenek hogy benn van a gépükben 4 darab ati 4890-es, melyik homebrew programozo engedhet meg magának ilyen költségeket, de ez még a kisebbik baj, melyik homebrew játék jöhet ki ugy hogy szinte csak a csucshardveren fut, vagy még azon is csak döcög,



Láttál már olyan homebrew játékot, amely túl hamar jött ki? Általában pont az szokott a baj lenni, hogy túl későn lesznek hobbyból készült játékok, amire a technológia már elvault. No, hát én ezt fogom elkerülni, mire az enginem igazán combossá fejlődik, addig évek is eltelhetnek, és ha elég jól lövöm be a célokat, akkor a cucc még évek múlva is nagyon korszerű lehet. Ha túl lövök a célon, akkor a játék elkészülte után karbatett kézzel ülök még 1 évet, amire a hardverek elég erősek lesznek, vagy azt az egy évet kizárólag optimalizálással töltöm.

A Crytekkel izomból nem lehet versenyezni. Nem tudnám leutánozni azt, amit ők a mai hardverre csináltak. Éppen ezért olyan dolgokkal foglalkozom, amire nekik még nincs idejük, vagy túl korainak tartják. Az, hogy most egyedül dolgozom valamin, az nem jelenti azt, hogy később nem lesznek társaim, vagy ha jó dolgok sülnek ki az egészből, akkor nem találok némi pénzforrást kiadót is. A mai nagy cégek nagy része is így kezdte. Az ott dolgozók tudását pedig nem kell túlmisztifikálni. Ők is emberek. Én egy teljesen más területen egy elismert nagy cégnek dolgozom, semmivel sem írok 'komolyabb' programokat a munkahelyemen mint otthon.


Szerk.:
Látom szó volt itt mindenféle mappelésekről, bakelésekről: Na ezért lesz nagyon kényelmes a voxeles megoldásom a művészeknek: a highpoly modellből kigenerálja a voxeles cuccot, és kész. Nincs többé normal mapre, displacement mapre meg ilyenekre szükség. Nincs szükség külön modellre a LOD miatt, mert teljesen automatikus lesz a LOD. Nincs szükség lightmapek készítésére sem. Az ambient occlusion-hoz sem kell semmi, mert real time fogok számolni dinamikusan mindent, nem csak direkt megvilágítást, de AO-t sőt egyéb indirekt fényeket is egy saját új algoritmussal (kicsit hasolít az irradience cachingre meg a foton mappingre sőt egy picit a screen space cuccokra is, de saját octreere alapozó algoritmus. Ha minden jól megy a 'mai' screen space GI megoldásoknál szebb lesz.)

Ezt a hozzászólást nadam módosította (2009.05.21 08:26 GMT+1 óra, ---)
   
xanat - Tag | 489 hsz       Online status #110706   2009.05.21 08:08 GMT+1 óra  
azert szerkesztettem, mert felreertheto volt. Ugyertettem, hogy "aaaa" utannanezhet(ne), hogy mit hasznalnak tenyleg egy jatekhoz. A crysisos fickok se hasznaltak tobbet...
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #110704   2009.05.21 08:07 GMT+1 óra  
Idézet
xanat :
nem beled akartam kotni. csak osztottam a velemenyed, hogy egy jatekhoz diffuse, specular, normal, (meg esetleg displace, meg talan-talan AO) map kell "csak".



Bocs, aszittem hogy a google a barátod nekem szólt .

Amúgy a vicc az, hogy filmes cuccokhoz sem használnak többet. Esetleg egy-két speciális map, de kb ez mindenre elég. Szóval lehet mondani, hogy mappelheted az összes csatornát, de gyakorlatilag sosem használja senki sem.
raytraceisten és übermedic
   
xanat - Tag | 489 hsz       Online status #110703   2009.05.21 08:04 GMT+1 óra  
nem beled akartam kotni. csak osztottam a velemenyed, hogy egy jatekhoz diffuse, specular, normal, (meg esetleg displace, meg talan-talan AO) map kell "csak".
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
sirpalee - Tag | 1282 hsz       Online status #110702   2009.05.21 08:00 GMT+1 óra  
Nyugodtan belém próbálhatsz kötni megint, nem tőled kérdeztem, hanem a nagyban magyarázó kedves fórumozó társamtól, én tudom mi kell egy SSS-hez, csak úgy látom hogy a másik nincs tisztában a fogalmakkal .
raytraceisten és übermedic
   
sirpalee - Tag | 1282 hsz       Online status #110700   2009.05.21 07:49 GMT+1 óra  
Idézet
aaaa :
több játék is van ahol a highpolyt festik, és az összes texturát bakelik
ez akkor térül meg amikor cg film is készül a játékhoz, igy csak egyszer kell festeni
igaz hogy ez homebrewnél nem valoszinü hogy felmerül



Ok, kérek példákat. Köszi.

Illetve, hogy milyen renderhez festenek ilyen mapeket... Meg hogy mi is az az SSS map például...
raytraceisten és übermedic
   
aaaa - Tag | 26 hsz       Online status #110699   2009.05.21 07:34 GMT+1 óra  
több játék is van ahol a highpolyt festik, és az összes texturát bakelik
ez akkor térül meg amikor cg film is készül a játékhoz, igy csak egyszer kell festeni
igaz hogy ez homebrewnél nem valoszinü hogy felmerül

   
sirpalee - Tag | 1282 hsz       Online status #110697   2009.05.21 07:19 GMT+1 óra  
Idézet
aaaa :
most nem akarom mindet felsorolni , de 20-nál több textura fajta van ,
diffuse ,reflection,normal,disp,sss,ambient,ref occl, transulency, roughness, aniso, fresnel, transparent absorption, refractive stb ...

és több vertex map, pl uv , morph, weight, color, vagy speciális
persze nem kell mind , csak a szükségesek, általában 5-10 elég, de ez éppen megszorozva a te 45 perceddel má tul pörög egy napon, és akkor csak egyszer renderelted le, ha mondjuk 5-ikre lesz csak jo akkor lesz az 4 nap is



Most nem játékfejlesztésről van szó? Ezeket nem generálni szokták, hanem festeni, szóval a bakelés már megint nem helyes kifejezés. A bakelés max 1 órát tart, egyetlen komplex, filmes szintű modellre. Ez tény.

Gratulálok felsoroltad a mappelhető csatornákat, de ezeket nem szokták mappelni, főleg nem egy játékban. De gyakran egy filmben sem...

SSS map maximum az erőssége, amilyen textúrákat esetleg használhatnak hozzá, az render közben generált, amilyen textúrát még esetleg lehet hozzá használni, az egy point cache, pl a POTF-ban is ezt a módszert használták, de ez már megint nem játékfejlesztés.

De ha VFX-ről szeretnél beszélgetni, tudom mondani, hogy miket szoktak mappelni egy filmes produkcióban... És ennek a töredékével sem foglalkoznak. Egy komplex shaderben átlag 50-60 mappelhető csatorna van, de ezeket senki sem használja, be van állítva kb egy érték és kész.

Csak akkor mondd hogy nem játékfejlesztésről beszélsz...
raytraceisten és übermedic
   
Bitsculptor - Tag | 188 hsz       Online status #110696   2009.05.21 07:13 GMT+1 óra  
A matek nem model szinten jön a képbe
Fogsz egy rahedli modelt amiket lehet paraméterezni is, és ebből matekkal már simán generálhatsz városokat, pl azzal a módszerrel, ahogy a Diablo pályák készültek. Így pl minden alkalommal máshol lesznek városok, más elrendezésűek lesznek stb..és spec épületek is lehetnek benne, mongyuk mindegyik városban külön külön 'set of special buildings'. Máris megnöveli a játékidőt, mert minden alkalommal teljesen más pályákat kapsz.

   
aaaa - Tag | 26 hsz       Online status #110695   2009.05.21 07:03 GMT+1 óra  
ja matekozz ki egy korinthoszi oszlopot , ha csak felhükarcoloban gondolkodunk akkor még esélyes lehet, csak mennyire eladhato egy ilyen gama?

   
Bitsculptor - Tag | 188 hsz       Online status #110694   2009.05.21 06:58 GMT+1 óra  
"ha mondjuk 5-ikre lesz csak jo akkor lesz az 4 nap is"

Nah pont ezért tart sokkal tovább egy város elkészítése designer által. Mennyivel egyszerűbb a matekra bízni amit lehet..

   
aaaa - Tag | 26 hsz       Online status #110693   2009.05.21 06:52 GMT+1 óra  
most nem akarom mindet felsorolni , de 20-nál több textura fajta van ,
diffuse ,reflection,normal,disp,sss,ambient,ref occl, transulency, roughness, aniso, fresnel, transparent absorption, refractive stb ...

és több vertex map, pl uv , morph, weight, color, vagy speciális
persze nem kell mind , csak a szükségesek, általában 5-10 elég, de ez éppen megszorozva a te 45 perceddel má tul pörög egy napon, és akkor csak egyszer renderelted le, ha mondjuk 5-ikre lesz csak jo akkor lesz az 4 nap is

   
sirpalee - Tag | 1282 hsz       Online status #110692   2009.05.21 06:39 GMT+1 óra  
Idézet
aaaa :
sirpalee: a bakelést , map generálást ugy értettem hogy highpolygonrol low polygonra vinni a texturákat , és nem csak a normal map van hanem 5-10 féle helyzettöl függöen,
na szoval szoktak érdekes anomáliák kialakulni, emiatt bütykölni kell hogy jo legyen ,ami mindig plusz idö



A high poly modellezés beletartozik a modellezésbe is. 5-10 fajta? Milyen is?

Normal / specular / height map. Ezek az alap mapok, esetleg AO, de azt manapság screen space számolják dinamikusan. Ebből csak a normalt és height mapet kell generálni, de az egyszerre megvan. Az environment map független a modellezéstől. A color és alfa meg kézzel festett.

Szerk : Meg ne is felejtsük el, hogy a modellezésbe beletartozik a riggelés is. Bár ha templatekkel dolgozik a csapat, akkor az is egyszerű, csak finom utóállítások kellenek.
raytraceisten és übermedic
   
aaaa - Tag | 26 hsz       Online status #110691   2009.05.21 06:36 GMT+1 óra  
sirpalee: a bakelést , map generálást ugy értettem hogy highpolygonrol low polygonra vinni a texturákat , és nem csak a normal map van hanem 5-10 féle helyzettöl függöen,
na szoval szoktak érdekes anomáliák kialakulni, emiatt bütykölni kell hogy jo legyen ,ami mindig plusz idö

   
sirpalee - Tag | 1282 hsz       Online status #110688   2009.05.21 06:24 GMT+1 óra  
Idézet
aaaa :
"Minigun 1etlen render-képe kb 1 óráig "

nemtudom mit renderelt a haverod, de több millio polygon is csak 1-2 perc
meg minek is renderelni, nem realtime kell?

napi 20 ezer polygon nem ügy egy grafikusnak, és szinte mindegy hogy mi van a concept képen, kivétel ez alol a karakter, mert az egy kicsit tovább tart
a texturázás nem ügy, a nagyobb probléma a 5-10 textura bakelése, normalmap , displacemap, reflection map, ambient occlusion, sss , stb..., na ezek betarthatnak pár napig



Teljesen reális az 1 órás render kép, nekünk agyon optimizált shaderekkel egy ilyen fegyver render 5-10 percig tart.

Bakelés napok? Milyen grafikust láttál te dolgozni? Egy normal map generálás 45 perc max, tökéletes minőségben 4096x4096-os felbontásban, de az már filmes szintű melókhoz. A reflection mapet pedig nem modelltől, hanem környezettől függően generálják, de egy HL2 mapper mindjárt megmondja, az mennyi idő alatt generálódik (Ashkandi?).

A modellezés + uv egy fullosan kidolgozott karakter esetén irtó sokáig eltarthat, persze egy komolyabb helyen van pár template karakter (amiknek az elékszítése 1 hét), és arra egy ügyes kezű zbrush artist rárak egy karakter 2-3 nap alatt (akit én ismerek 5-6 óra alatt, de ő egy zseniális szobrász). Erre jön a textúrafestés ami napokig is eltarthat.

Nem vagy tisztában a számokkal...
raytraceisten és übermedic
   
Bitsculptor - Tag | 188 hsz       Online status #110687   2009.05.21 06:18 GMT+1 óra  
Idézet
xanat :
OFF:
"...homebrew játék....szinte csak a csucshardveren fut, vagy még azon is csak döcög" - sajnos ez elofordul, meg ha nem is ugy nez ki, mint a crysis.



Hát igen, optimalizálni kell.

   
xanat - Tag | 489 hsz       Online status #110685   2009.05.21 06:07 GMT+1 óra  
OFF:
"...homebrew játék....szinte csak a csucshardveren fut, vagy még azon is csak döcög" - sajnos ez elofordul, meg ha nem is ugy nez ki, mint a crysis.
Elsosorban nem a program a hulye, hanem a felhasznalo nem tudja hasznalni.
   
Frissebbek | Korábbi postok
[1] > 2 < [3] [4] [5] [6] [7] [8]