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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
> 1 <
monostoria - Törzstag | 3284 hsz       Online status #33516   2006.10.24 06:20 GMT+1 óra  
FPS játékban kevésbé zavaró ez az "áttetsző sík" mászás, mint tps-ben, főleg ha a játékos csak egy box De az ellenfeleknél télleg csúnya lehet, nameg akkor ha igényesek vagyunk, és a játékosunk sem egy box. Akkor viszont csont alapú (bone) animációval kell megcsinálni a lépcsőzést, és aközben emelni a karaktert, egy sík mentén ami a lépcső aljától indul szépen felfele. Így ahogy tolod szépen felfelé és előre a mukit, úgy tűnik mintha lépcsőt mászna

Ezt a hozzászólást monostoria módosította (2006.10.24 06:26 GMT+1 óra, ---)
Engem csak két szakma érdekel... basszak ma, vagy ne basszak ma...
   
tacam-r2 - Tag | 48 hsz       Online status #33511   2006.10.24 04:42 GMT+1 óra  
Idézet
Jedi :
Idézet
DeVi :
Ezt az átlátszó síkot a lépcsőn nem teljesen értem. Hova meg hogyan, és miért?
Jedi: amit írtál kb értettem, de akkor a pálya tervezőnek még ezzel is szöszölni kell, hogy mi a padló, és a több akkor fal lesz. Nem hiszem, hogy a Quake 3-at is így csinálták. Ott hogy csinálták?
De izé: oda érek egy dobozhoz, mondjuk tudom róla, hogy az van elöttem, már bele is lóg a BB, és így a karakter is. Ahogy írtad, itt nem végzek teljes ütközés vizsgálatot. Amire a P1 pont oda ér, hogy "ütközve" legyen a dobozzal, tehát felemeljem a P0-t, addig már könyékig benne vagyok, aztán hirtelen felugrik a tetejére. Ez csúnya. Hol van a mászás animáció, meg a P0 lassú felemelése? Szóval honnan tudom, hogy ott mászni kell, mondjuk még akkor, amikor még nem lógok bele a dobozba. És honnan tudom, hogy elöttem pont ilyen doboz van?
Tovább megyek: mondjuk alacsonyan van a plafon. Felmegyek a dobozra, és ő le kellene gugoljon.



Wazz, a post elejét is elolvasad? ("Egy nagyon egyszerű megoldás")?

A pályatervezőnek nem kell figyelnie azt, h az adott elem milyen, ezt könnyen lehet generálni is. Pl. ha egy felületelem normálvektora 45 foknál nagyobb szögben tér el a függőlegestől, akkor már nem lehet megmászni ("fal" elem lesz).De akár a függőlegestől való eltérést le lehet képezni pl a [0,1] intervallumra is: a 0 a sima vízszintes padló, x<1 esetén is padló de a haladási sebesség arányosan csökken (meredekebb felületen lassaban haladsz), 1 esetén pedig nem tud átmenni rajta.

Lehet h csúnya ha belóg a karakter egy objektumba, de az is csúnya ha csak úgy lebeg színtéren, mert a bb csücske már pont a láda felett van (még "jobb" a hatás ha pl. a karakter széttárt kezekkel "rohangál" és a keze csak elsuhan egy láda felett ).
Valamit valamiért, a real-time dolgoknak ez az áruk.
A mászás animáció is nagyon egyszerű, ha a |P1-P0| érték kicsi (pl lépcsőt mászunk), akkor oda nem kell animáció, ha ez egy konstans C értéknél nagyobb, akkor átváltunk a mászás animációs fázisra.

A legprecízebb az lenne, ha a skeleton minden csontjához hozzárendelsz egy bb-t és ezekkel az illesztett bb-kel végzed el az ütközésvizsgálatot (csak ugye ez jóval több idő). Lehet kicsit egyszerűbben is, h pl csak 5 bb lesz (2 láb, 2 kar, 1 törzs), de ugye itt is 5x kell elvégezni az ütközésfigyelést.

Az átlátszó sík jó módszer a "darabos" lépcsőmászás megoldására, viszont ott meg ha megáll a karakter a lépcsőn, akkor vagy "lebegni" fog felette (ha pont a lépcsőfokokra van illesztve a sík) vagy belelóghat a lába a lépcsőbe (ha sülyesztett a sík). Szintén valamit valamiért, ugye. Mérlegelni kell, h mi a fontos.


Neha a legujabb jatekokban is csak egy box-on keresztul van megoldva az utkozes vizsgalat...
Szoval nem erdemes az embernek ebbe melyen beleasnia...

   
Jedi - Tag | 175 hsz       Online status #33509   2006.10.24 04:18 GMT+1 óra  
Idézet
DeVi :
Ezt az átlátszó síkot a lépcsőn nem teljesen értem. Hova meg hogyan, és miért?
Jedi: amit írtál kb értettem, de akkor a pálya tervezőnek még ezzel is szöszölni kell, hogy mi a padló, és a több akkor fal lesz. Nem hiszem, hogy a Quake 3-at is így csinálták. Ott hogy csinálták?
De izé: oda érek egy dobozhoz, mondjuk tudom róla, hogy az van elöttem, már bele is lóg a BB, és így a karakter is. Ahogy írtad, itt nem végzek teljes ütközés vizsgálatot. Amire a P1 pont oda ér, hogy "ütközve" legyen a dobozzal, tehát felemeljem a P0-t, addig már könyékig benne vagyok, aztán hirtelen felugrik a tetejére. Ez csúnya. Hol van a mászás animáció, meg a P0 lassú felemelése? Szóval honnan tudom, hogy ott mászni kell, mondjuk még akkor, amikor még nem lógok bele a dobozba. És honnan tudom, hogy elöttem pont ilyen doboz van?
Tovább megyek: mondjuk alacsonyan van a plafon. Felmegyek a dobozra, és ő le kellene gugoljon.



Wazz, a post elejét is elolvasad? ("Egy nagyon egyszerű megoldás")?

A pályatervezőnek nem kell figyelnie azt, h az adott elem milyen, ezt könnyen lehet generálni is. Pl. ha egy felületelem normálvektora 45 foknál nagyobb szögben tér el a függőlegestől, akkor már nem lehet megmászni ("fal" elem lesz).De akár a függőlegestől való eltérést le lehet képezni pl a [0,1] intervallumra is: a 0 a sima vízszintes padló, x<1 esetén is padló de a haladási sebesség arányosan csökken (meredekebb felületen lassaban haladsz), 1 esetén pedig nem tud átmenni rajta.

Lehet h csúnya ha belóg a karakter egy objektumba, de az is csúnya ha csak úgy lebeg színtéren, mert a bb csücske már pont a láda felett van (még "jobb" a hatás ha pl. a karakter széttárt kezekkel "rohangál" és a keze csak elsuhan egy láda felett ).
Valamit valamiért, a real-time dolgoknak ez az áruk.
A mászás animáció is nagyon egyszerű, ha a |P1-P0| érték kicsi (pl lépcsőt mászunk), akkor oda nem kell animáció, ha ez egy konstans C értéknél nagyobb, akkor átváltunk a mászás animációs fázisra.

A legprecízebb az lenne, ha a skeleton minden csontjához hozzárendelsz egy bb-t és ezekkel az illesztett bb-kel végzed el az ütközésvizsgálatot (csak ugye ez jóval több idő). Lehet kicsit egyszerűbben is, h pl csak 5 bb lesz (2 láb, 2 kar, 1 törzs), de ugye itt is 5x kell elvégezni az ütközésfigyelést.

Az átlátszó sík jó módszer a "darabos" lépcsőmászás megoldására, viszont ott meg ha megáll a karakter a lépcsőn, akkor vagy "lebegni" fog felette (ha pont a lépcsőfokokra van illesztve a sík) vagy belelóghat a lába a lépcsőbe (ha sülyesztett a sík). Szintén valamit valamiért, ugye. Mérlegelni kell, h mi a fontos.

   
Gaborious - Tag | 50 hsz       Online status #33500   2006.10.24 03:18 GMT+1 óra  
Idézet
Orphy :
Esetleg egy külön bbox-ot nyilvántartani csak a lábra, és valahogy úgy belőni, hogy ne lehessen csak úgy lábujjhegyen megállni egy lépcsőfokon



Keménydió, ügyebár szeretnénk azt ha nekifutunk a lépcsőnek, akor folyamatosan fussunk fel rajta, avagy ne bénázzunk, és ne akadjunk meg minden lépcsőfokon, ja és ne pattogjunk.

meglehet azt csinálni hogy külön bbox van lábanként,ámde mint elöbb montam, amikor fut/lép a karakter, úgy kell lépnie hogy a lépés végén az elölévő láb a következő (vagy egy magasabb) lépcsőfokra lépjen kapásból (ellenkező esetben ugyanarra a lépcsőfokra lép, ergo helybenmarad vagyis megakad).

A másik ha nincs oylan animációs fázis hogy lépcsőzés nincs, hanem csak simán futás animmal akarod megoldani, elkerülhetetlen hogy a karakter ne pattogjon minden lépcsőfoknál, ugyanis mindegyik alklommal amint rálép egy magasabb lépcsőfokra, megemelkedik, és mivel a futásban nincs fokozatos emelkedés rész, így az egész karakter hirtelen megemlkedik a magasabb lépcsőfoknak hála.
[Silent Vertigo] { Solarah }
SilentVertigo Honlap
   
Orphy - Törzstag | 1893 hsz       Online status #33499   2006.10.24 03:06 GMT+1 óra  
Esetleg egy külön bbox-ot nyilvántartani csak a lábra, és valahogy úgy belőni, hogy ne lehessen csak úgy lábujjhegyen megállni egy lépcsőfokon
   
Orphy - Törzstag | 1893 hsz       Online status #33498   2006.10.24 03:02 GMT+1 óra  
Jaja, elég sok helyen láttam ilyet...

Van erre a problémára igazán jó megoldás?
Mármint olyan, amit real-time-ban használni is lehet, és nem 2 fps-el fog száguldani a progi...
   
Gaborious - Tag | 50 hsz       Online status #33497   2006.10.24 02:52 GMT+1 óra  
Idézet
Orphy :
Mi a helyzet akkor, ha a lépcsőfokokra csak függőleges irányban vizsgálunk ütközést, ha felette vagy, addig "esel", amíg nem rajta állsz, ha alatta, akkor addig emelkedsz, amíg nem a lépcsőn lépkedsz... Ezt egy lépcső mesh-el is tuti meg lehet csinálni, terepnél használnak hasonló megoldásokat arra, hogy kövesse a karakter a domborzatot...

Csak csigalépcsőt ne kelljen csinálni



Igen ez egy módszer, és ezt jópáran használták is, ámde ennek is volt egy baromi nagy bibije:
méghozzá az hogy az ütközést a BBoxal vizsgálják ami ügye az egész karaktert magábafoglalja, teljes szélességben stb.. namost ennek az a következménye hogy pl lábújon áll a krakter a lépcsőfokon, bizton te is láttál már játékokban olyat hogy a lépcsőfok szélén áll a pacák, de úgy hogy csak lápújja / vagy még az sem/ takarja a lépcsőfokot. remélem vágod miről bszélek...
[Silent Vertigo] { Solarah }
SilentVertigo Honlap
   
tacam-r2 - Tag | 48 hsz       Online status #33496   2006.10.24 02:50 GMT+1 óra  
Idézet
Gaborious :
Idézet
Orphy :
És ha azt a lejtő síkot kicsit lejjeb viszed?
Lépcsőre meg max nem számolsz akkor ütközést.



A lépcsőre amúgysem számolsz ütközést csak a lejtőre, de ha lejjebb is viszed akkormeg sokszor belelóg a lábad a lépcsőfokokba. Tehát dönteni kell: játszhatóság vs valósághűség... keménydió.


Ha az belsonezetes FPS, akkor azt ugysem latjuk hogy all a labunk, az ellensegnel meg megprobaljuk elviselni...

   
kicsy - Szerkesztő | 4304 hsz       Online status #33495   2006.10.24 02:50 GMT+1 óra  
No igen, de a két lábra külön kéne ütközésvizsgálat ha tényleg szépen akarjuk megcsinálni
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
Orphy - Törzstag | 1893 hsz       Online status #33494   2006.10.24 02:45 GMT+1 óra  
Mi a helyzet akkor, ha a lépcsőfokokra csak függőleges irányban vizsgálunk ütközést, ha felette vagy, addig "esel", amíg nem rajta állsz, ha alatta, akkor addig emelkedsz, amíg nem a lépcsőn lépkedsz... Ezt egy lépcső mesh-el is tuti meg lehet csinálni, terepnél használnak hasonló megoldásokat arra, hogy kövesse a karakter a domborzatot...

Csak csigalépcsőt ne kelljen csinálni
   
Gaborious - Tag | 50 hsz       Online status #33493   2006.10.24 02:29 GMT+1 óra  
Idézet
Orphy :
És ha azt a lejtő síkot kicsit lejjeb viszed?
Lépcsőre meg max nem számolsz akkor ütközést.



A lépcsőre amúgysem számolsz ütközést csak a lejtőre, de ha lejjebb is viszed akkormeg sokszor belelóg a lábad a lépcsőfokokba. Tehát dönteni kell: játszhatóság vs valósághűség... keménydió.
[Silent Vertigo] { Solarah }
SilentVertigo Honlap
   
Orphy - Törzstag | 1893 hsz       Online status #33492   2006.10.24 01:38 GMT+1 óra  
És ha azt a lejtő síkot kicsit lejjeb viszed?
Lépcsőre meg max nem számolsz akkor ütközést.
   
Gaborious - Tag | 50 hsz       Online status #33491   2006.10.24 01:36 GMT+1 óra  
Nwn2 ben a köv a magoldás: ott egy lépcsőt vizálisan megjeneítenek lépcsőként, ámde fizikailag egy lépcső fokaira fektett lejető síkról van szó. Amikor a karakter BBox-a odaér, és a lépcsőre szretne felmenni, akkor a bboxa ütközik a lépcső lejtősíkjával, így azon kezd el felmenni, (persze közben átválthat lépcsőző animációs fázisba is).

enneka megoldásnak van egy előnye , hogy leegyszerüsíti az egészet.
a hátránya hogy hülyén néz ki hogy nema lépcsőfokokon áll a karakter hanem egy nem látható síkon.
[Silent Vertigo] { Solarah }
SilentVertigo Honlap
   
tacam-r2 - Tag | 48 hsz       Online status #33467   2006.10.23 14:21 GMT+1 óra  
Idézet
DeVi :
Ezt az átlátszó síkot a lépcsőn nem teljesen értem. Hova meg hogyan, és miért?
Jedi: amit írtál kb értettem, de akkor a pálya tervezőnek még ezzel is szöszölni kell, hogy mi a padló, és a több akkor fal lesz. Nem hiszem, hogy a Quake 3-at is így csinálták. Ott hogy csinálták?
De izé: oda érek egy dobozhoz, mondjuk tudom róla, hogy az van elöttem, már bele is lóg a BB, és így a karakter is. Ahogy írtad, itt nem végzek teljes ütközés vizsgálatot. Amire a P1 pont oda ér, hogy "ütközve" legyen a dobozzal, tehát felemeljem a P0-t, addig már könyékig benne vagyok, aztán hirtelen felugrik a tetejére. Ez csúnya. Hol van a mászás animáció, meg a P0 lassú felemelése? Szóval honnan tudom, hogy ott mászni kell, mondjuk még akkor, amikor még nem lógok bele a dobozba. És honnan tudom, hogy elöttem pont ilyen doboz van?
Tovább megyek: mondjuk alacsonyan van a plafon. Felmegyek a dobozra, és ő le kellene gugoljon.


A gond ott van, hogy a lepcsoket gyorsan kell megmasznod, es nem akar senki sem atvezeto animalast csinalni, ahogy feptipeg bal-lab-jobb-lab modon a lepcson. Igy hat legegyszerubb
ha felszalad, mintha sik talajon menne. (erre kell a rahelyezett sik)

   
DeVi - Tag | 5 hsz       Online status #33466   2006.10.23 14:13 GMT+1 óra  
Ezt az átlátszó síkot a lépcsőn nem teljesen értem. Hova meg hogyan, és miért?
Jedi: amit írtál kb értettem, de akkor a pálya tervezőnek még ezzel is szöszölni kell, hogy mi a padló, és a több akkor fal lesz. Nem hiszem, hogy a Quake 3-at is így csinálták. Ott hogy csinálták?
De izé: oda érek egy dobozhoz, mondjuk tudom róla, hogy az van elöttem, már bele is lóg a BB, és így a karakter is. Ahogy írtad, itt nem végzek teljes ütközés vizsgálatot. Amire a P1 pont oda ér, hogy "ütközve" legyen a dobozzal, tehát felemeljem a P0-t, addig már könyékig benne vagyok, aztán hirtelen felugrik a tetejére. Ez csúnya. Hol van a mászás animáció, meg a P0 lassú felemelése? Szóval honnan tudom, hogy ott mászni kell, mondjuk még akkor, amikor még nem lógok bele a dobozba. És honnan tudom, hogy elöttem pont ilyen doboz van?
Tovább megyek: mondjuk alacsonyan van a plafon. Felmegyek a dobozra, és ő le kellene gugoljon.

   
monostoria - Törzstag | 3284 hsz       Online status #33378   2006.10.23 11:25 GMT+1 óra  
Azért vagyunk hogy ötletet adjunk és segítsünk egymásnak
Engem csak két szakma érdekel... basszak ma, vagy ne basszak ma...
   
gaborlabor - Moderátor | 4449 hsz       Online status #33371   2006.10.23 11:05 GMT+1 óra  
ahogy itt elolvasgatom a hsz-eket jobbnál jobb ötletek jutnak eszembe!
pl ez az emelkedős átlátszós padlós dolog nagyon jól hangzik!!
amint visszatérek a 3d-hez, kipróbálom majd.

   
monostoria - Törzstag | 3284 hsz       Online status #33369   2006.10.23 10:39 GMT+1 óra  
Ez az áttetsző sík valóban hasznos Gondoljatok csak bele, milyen képugrálás lenne, mire feljutnátok mondjuk egy toronyba
Már elképzelni is "undorító"
Engem csak két szakma érdekel... basszak ma, vagy ne basszak ma...
   
tacam-r2 - Tag | 48 hsz       Online status #33363   2006.10.23 09:37 GMT+1 óra  
Idézet
DeVi :
De honnan tudom, hogy lépcsővel ütközök? Mert mondjuk van az emberem, akinek a bounding box-a egy henger, és ha a henger bárhol beleütközik bármely pologionba, akkor valószínűleg falnak ment, vagy lépcsőnek, vagy ilyesmi.
Olvastam egy olyat, hogy ütközéskor megnézem, hogy ha megemelem mondjuk egy lépcsőnyit a hengert, és úgy ütköztetek. Ha nem ütközik, akkor fel ment a lépcsőre.
De ez eléggé "trükkös" megoldás. Nincs jobb? Vagy a lejtő: lehet, hogy nagyon fel emelem, és a levegőben "van", ezért le kellene vinni...


En ugyanezt hasznalom, kicsit toredekes a mozgas tole.(szokas a lepcsokre meg egy transzperens sikot rahuzni)

   
tacam-r2 - Tag | 48 hsz       Online status #33361   2006.10.23 09:34 GMT+1 óra  
Nem akarom reklamozni magam, de a topaz.extra.hu-n ami van demo az BSP-t hasznal, meg terelosztast...(keveske 4000 sornyi a BSP resz, de megjelenitesben fejlesztve lesz)

   
monostoria - Törzstag | 3284 hsz       Online status #33354   2006.10.23 08:55 GMT+1 óra  
Én kb. 5ször átolvastam mire felfogtam mire is gondolsz
Engem csak két szakma érdekel... basszak ma, vagy ne basszak ma...
   
Jedi - Tag | 175 hsz       Online status #33350   2006.10.23 08:25 GMT+1 óra  
Idézet
DeVi :
De honnan tudom, hogy lépcsővel ütközök? ...



Egy nagyon egyszerű megoldás: a színtered elemeihez hozzárendelsz egy plusz jelzőt, ami szerint -egyszerű terminológiában- az objektumok lehetnek "fal" és "padló" elemek.
A "fal" elemeken nem lehet áthaladni (pl fal, oszlop, szobor, ...), ezeken elvégzed az ütközésvizsgálatot a szokásos módon (ha ütközés van, akkor az elemre merőlegesen -mondjuk a normálvektort használva- "kitolod" a falból a bb-t).
Minden olyan objektum, amire rá lehet mászni "padló" elem lesz (a tényleges padló, a lépcső, megmászható ládák, stb...). Ezekre csak egy függőleges irányú ütközésvizsgálatot végzel. Pl. legyen a P0 pont a bb-d aljának jelenlegi pontja. Fogsz egy félegyenest, ami a bb tetejéről indul lefelé a bb középtengelyén és megnézed, h hol metsz egy "padló" elemet. Ez a metszéspont (legyen mondjuk P1) lesz a bb-d aljának az új pozíciója (azaz el kell tolnod a P1-P0 vektorral). Röviden ennyi.

   
DeVi - Tag | 5 hsz       Online status #33303   2006.10.23 03:49 GMT+1 óra  
De honnan tudom, hogy lépcsővel ütközök? Mert mondjuk van az emberem, akinek a bounding box-a egy henger, és ha a henger bárhol beleütközik bármely pologionba, akkor valószínűleg falnak ment, vagy lépcsőnek, vagy ilyesmi.
Olvastam egy olyat, hogy ütközéskor megnézem, hogy ha megemelem mondjuk egy lépcsőnyit a hengert, és úgy ütköztetek. Ha nem ütközik, akkor fel ment a lépcsőre.
De ez eléggé "trükkös" megoldás. Nincs jobb? Vagy a lejtő: lehet, hogy nagyon fel emelem, és a levegőben "van", ezért le kellene vinni...

   
FZoli - Szerkesztő | 4894 hsz       Online status #33261   2006.10.22 23:17 GMT+1 óra  
terep esetén pl. a pálya heightmapja alapján interpolálod ki a terep adott koordokhoz tartozó magasságát, lépcsőnél könnyeb a dolgod, ha tudod h a lépcsővel ütkzöl akkor nem megállítnai kell a testet, hanem (megállítás és igazítás után) megemelni.

szvsz, de jönnek még itt majd megerősítő (cagy nem) válaszok

FZoli.

   
DeVi - Tag | 5 hsz       Online status #33256   2006.10.22 15:02 GMT+1 óra  
Nekem egy olyan naív kérdésem lenne, hogy oké ütközök a környezettel, nem megyek bele a falba, de hogy megyek fel/le pl. egy lépcsőn, vagy lejtőn?

   
Gaborious - Guests | hsz       Online status #4241   2005.05.06 02:24 GMT+1 óra  
mind a bsp ,quad,oct-tree (és társaik) arra valók hogy a teret adaptívan fel lehessen osztani annak fügvényében hogy az adott térrészben miből mennyi van.

Tehát, a bsp nem quad és nem octtree.
Ezek ÁLTALÁNOSAN jól használható algoritmusok adatok tárolására. PL: a quadtreet használták képek tömörítésésre is.

Tehát hogy egy levélben mit tárolsz rajtad múlik. Ha akrod akkor csak 3szögeket, ha akarod az objektumok azonosítóját (én ezt ajánlom) de ha akarod akkor kedves szomszéd egyes testrészeit. Egyre megy, a lényeg hogy az adott térrészben található dolgokat el lehet benne tárolni, és neked most ez a fontos.
A BSP fa bonylúltabb és nem annyira dinamikus mint a quad/octtree (ha már ennyit emlegetem az octtree-t leírom hogy az a quadnak egy továbbfejlesztett változata és uúgy müxik mint a quad csak a teret nem négy hanem nyolc egyenlő részre osztja (tehát itt már a magassággal is számolni kell vagyis míg a quadnál pl csak a x,y val kellett foglalkozni (feltételezve hogy z a magasság) addig a octtree a x,y,z is figyelembe veszi)). Előnye az octtree-nak a quadhoz képest, hogy részletesebb felbontást tud addni és magasság alapján is tudsz már keresni (tehát most már ha van egy pos akkor annak mind a x,y,z koordinátája egyértelműen meghatároz egy konkrétabb térrészt ellentétben a quad-dal). Íme egy pl.
ha kérdezik hogy hol tanyázol ember? akkor mondod hogy :
.. városban,.. utca .. házszám (ezáltal megvan az x,y koordináta) és a ..dik emeleten (megvan a z (magasság))
,míg quad esetében csak a x,y-t ismerjük de abban az épületben hogy hol nem tudni, így az egész épületet bejárod ahelyett hogy felmennél a .. emeletre (z). Tehát octtree esetén pontosabban lehet keresni. Octtree-t kültér esetén is használható, és mivel konkrétabban lehet benne keresni így pontosabban meg lehet állapítani hogy mely térrészek láthatóak és melyek nem, de ez már megint egy másik téma.
(Módosította Gaborious 2005.05.06. 10:25-kor)

   
ShAdeVampirE - Guests | hsz       Online status #4240   2005.05.05 11:15 GMT+1 óra  
A quadtreenek vannak csúcsai(node) amik további alcsúcsokra mutatnak(subnode) (ha valamelyik üres akkor oda nem mutat) vagy mutatnak egy levélre(leaf) ami a fa vége és ott tároljuk az összes objektumot/3szöget/geometriát amit akarsz.

Akkor a Quad-tree bármire használható? Mármint 3szögek/objektumok tárolására is?
Mert bsp-nél ugye 3szögek vannak letárolva, hogy melyik-hol van. De akkor pl. 3szöges quad tree miben más? Vagy csak egy speciális bsp-tree?

Bocs, ha vmit félreértettem...

____________________
/ ShAdeVampirE /
([url="http://shadevampire.uw.hu">ShAdeVampirE otthona a neten...[/url])

   
Hacker - Guests | hsz       Online status #4239   2005.05.05 07:14 GMT+1 óra  
OK. Megpróbálom megcsinálni Delphiben és majd beszámolok a történtekről .

Programozz ne háborúzz!!!(Módosította Hacker 2005.05.05. 15:16-kor)

   
Gaborious - Guests | hsz       Online status #4238   2005.05.05 04:28 GMT+1 óra  
Értem, hogy bonyolúlt a BSP fa, de attól még nyugodtan megcsinálhatod a quad-tree-t.
Ezekre igazából nem csak azért van szükség hogy kiszűrd a nem látható geometriaát, hanem arra is jó hogy gyorsan meg tudd határozni hogy egy pozíció közelében mely tárgyak vannak (pl, melyekkel ütközhetsz (mert közelvannak, attól még meg kell rájuk is nézni hogy télleg ütközöl e velük))
A 2d-s boolean tömbről lebeszélnélek de gyorsan, amikor delphi3-ban programoztam, akkor a boolean helyfoglalása is 8 bit volt hiába csak egy bit az egész. 5-nél sztem uagyaz a helyzet.
De akkor is rossz (bruteforce+primitív) megoldás a tömb.
Old meg a quad tree-t, mindjárt leírom hogyan kell csinálni.
Az mehetek oda nem mehetek oda szitut meg lehet oldani a köv formában. Ha felülnézetes lesz a z editor akkor elég lenne meghúzni benne egy virtuális falat (azaz felülnézetben egy vonalat) és meg kell h a vonal melyik oldala "tömör beton" (avagy oda te nem mehetsz).
hogyan ellenőrzöd: vagyon te egy pont , összegyüjtöd a pont környékén lévő összes falat (ehez kell majd a quad tree, hogy ne a pályán lévő összes falat keljen egyenként vizsgálni, hanem azokat amelyek, mondjuk csak 1m távolságban vannak tőled) és megnézed rájuk hogy melyik fal mögött vagy (avagy a tömör beton részeében (a tiltott zónában) ha van ilyen akkor kirakod magadat a fal elé, ha egyik fal mögöt sem vagy akkor minden oké. Előfordúlhat hogy belefutsz a falba ,vagyis a poziciód a fal másik oldalán vagy és csak ezek után végzed el az ütközésvizsgálatot, és ebből fakadóan a kiderül hogy a flaban vagy (vagy azon túl) akkor a fal elé kell visszarakni a játékost (igy olyan lenne mintha nekimegy a falnak).

Tehát akkor jöjjön a quad tree alapfokon.
Ez egy rekurzív folyamat. Éredemes a rekurzivitásnak határt szabni, pl csak x szintig építünk quadtreet vagy addig csináljuk amig egy leveélben pl max 100 db objektum/3szög/vertex van.
tehát íme egyfajta pseudo kód:
legyen kezdetben T (mint tér) = az egészjátéktérrel

func buid_qtree(T:tér)
{
1) feltételvizsg:
- ha T térrészben található (összes obj száma>100) akkor folyt a 2.es lépésnél
else ez egy levél, tehát itt most eltároljuk az adott térrészben található összes obj azonosítójaát és kilépünk ebből a fvből.
2) T -t felosztod 4 egyenlő részre.
3) minden kapott (4db) alrészre meghívod a
buid_qtree(alrész)
}

A quadtreenek vannak csúcsai(node) amik további alcsúcsokra mutatnak(subnode) (ha valamelyik üres akkor oda nem mutat) vagy mutatnak egy levélre(leaf) ami a fa vége és ott tároljuk az összes objektumot/3szöget/geometriát amit akarsz.

Oké, nade hogyan szedjük ki hogy mi van a környékünkön?
adott a mi pos helyzetünk.
Van nekünk egy qtree gyökerünk (fa struktúra gyökere,kindulópontja)
és tesszük a következőben:
megnézzük hogy az adott node-ból elérhető subnode-kok közül melyikben van van benne a pos. (ügyebár mindegyik subnode tartalmazza az adott cella szélességét mélységét és a közepét amiből kiszámíthatóak a cella csúcsai (magasság nem kell)) vagyis ha egy pos a négy csúcs között van akkor a cellában van. Aztán annak a összes subnode-jaire uezt meginmtmegint addig míg egy levélhez nem érkezünk. A levélben lévő összes stuff velünk egy cellában van.
Vigyázni kell arr, hogy állhatunk két cella határain is és ilyenkor a egy szomszédos cellát is ki kell vesézni a benne lévő objektumok miatt.

Na remélem vágod.

http://acm.pku.edu.cn/JudgeOnline/showproblem?problem_id=1610
h ttp://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/MARBLE/medium/segment/qua d.htm
http://www.gamedev.net/reference/articles/article1485.asp


" A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"(Módosította Gaborious 2005.05.05. 12:29-kor)

   
Hacker - Guests | hsz       Online status #4237   2005.05.05 03:09 GMT+1 óra  
Idézet
Gaborious írta:
(Hacker írta:
OK. Köszi. Utanánézek a témának.

Programozz ne háborúzz!!!)Sok sikert, de szerintem gyorsabban megoldható a dolog, ugyanis kint aneten van pár már létező (és ingyenes FREEWARE) megoldás, amiket nyugodtan be lehet másolni a kódodba és használni, és elég használni.
Nos a bsp fa építésére is biztosan találsz kódot (a pvs-ben nem vagyok biztos , de azt részben a portalrenderinggel ki lehet váltani beltéri jelenetek esetén), ha kültéri jeleneteknél használod akkor NYUGODTAN használj Quad/octtree-t, pár ügyes trükkel ezeket is lehet hatékonyan használni.
Egy jó tipp, ha esetleg már értesz a pixel/vertex shader programozáshoz (cg,hlsl,... ismerősen csengenek) és mondjuk erős GPU van a gépedben akkor a számítások egy részét lazán rá lehet bízni a GPU-ra (sokkal gyorsabban számol mint egy high-end cpu) mondjuk a octtree felépítését, de ezt témát szerintem hanyagoljuk most (csak megemlítettem hogy így is gyorsabban ki lehet előre számolni dolgokat)


Szerintem olyan sok kódot nem találok majd, mert én Delphiben programozok nem pedig C-ben. Ja még lenne annyi kérdésem, hogy, csinálok a TrueVision-höz egy pályaszerkeztő progit, hogy könnyebb legyen programozni és arra gondoltam, hogy egy kétdimenziós tömbös Boolean-t csinálok ami majd tárolja, hogy lehet-e menni a pálya annak a részére-e? Ez szerintetek jó ötlet (még nekem sokkal egyszerűbben lehetne megoldani, mint a BSP fát)? Jah és, hogy hallottam BSP compilerekről. Azok jó programok? És tudnátok nekem mondani pár ilyen programot?

Programozz ne háborúzz!!!

   
Gaborious - Guests | hsz       Online status #4236   2005.05.05 02:22 GMT+1 óra  
Idézet
Hacker írta:
OK. Köszi. Utanánézek a témának.

Programozz ne háborúzz!!!
Sok sikert, de szerintem gyorsabban megoldható a dolog, ugyanis kint aneten van pár már létező (és ingyenes FREEWARE) megoldás, amiket nyugodtan be lehet másolni a kódodba és használni, és elég használni.
Nos a bsp fa építésére is biztosan találsz kódot (a pvs-ben nem vagyok biztos , de azt részben a portalrenderinggel ki lehet váltani beltéri jelenetek esetén), ha kültéri jeleneteknél használod akkor NYUGODTAN használj Quad/octtree-t, pár ügyes trükkel ezeket is lehet hatékonyan használni.
Egy jó tipp, ha esetleg már értesz a pixel/vertex shader programozáshoz (cg,hlsl,... ismerősen csengenek) és mondjuk erős GPU van a gépedben akkor a számítások egy részét lazán rá lehet bízni a GPU-ra (sokkal gyorsabban számol mint egy high-end cpu) mondjuk a octtree felépítését, de ezt témát szerintem hanyagoljuk most (csak megemlítettem hogy így is gyorsabban ki lehet előre számolni dolgokat)

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
Hacker - Guests | hsz       Online status #4235   2005.05.04 08:24 GMT+1 óra  
OK. Köszi. Utanánézek a témának.

Programozz ne háborúzz!!!

   
Gaborious - Guests | hsz       Online status #4234   2005.05.04 07:18 GMT+1 óra  
Idézet
Hacker írta:
És van olyan program amivel egyszerûen lehet BSP fát csinálni? Mert nekem ez a BSP fa módszer elég jó lenne a TrueVision enginehez csak nem tudom, hogyan tudok csinálni ilyen fát.

Programozz ne háborúzz!!!
Nos önmagában a BSP nem elég a látványos sikerhez.
Ahhoz hogy például beltéri jeleneteknél hatékony legyen PVS -t (a részlegesen látható területek adatai) is kell számolni.
A kettő zusammen már hatásos. Ha a PVS-t nem használod tetűlassú lesz,

"csak nem tudom, hogyan tudok csinálni ilyen fát" kérdésed arra utal, hogy még nem ismered a BSP-fát.
Megmondom, hogyan lehet ilyen fát csinálni.
Kell egy BSP mag amit elültetve egy kis ***földbe, szt lócsolgatva ... NEMMMM, nem , csak vicceltem

A BSP fák számolása abszolúte nem egyszerű stuff, eléggé bonyolúlt tud lenni, ha bonyolúlt az a adatmodel amiben a geometriai adatokat tároltad.
A PVS-ről nem is beszélve, az meg télleg bonyolúlt, és számítása irdatlan sok időt vesz igénybe.
Csak egy példa: amikor John C. (id kisisten) elkészült a Quake3-mmal akkor a pályák kiszámitása (tehát a végleges PVS+BSP+megvilágítás(radiosity) felépítése/kiszámítása) egy akkoriban bika nagygépnek (nem pc-nek) egy pálya átlagban 1 hétig tartott 7/24 módban persze.

Tehát a téma ütős nagyon.
Olvassál el pár cikket a neten (google ) és a bsp ezekkel a témákkal szokták összehozni ha grafikáról vanszó:
BSP, PVS, Raytracing, Radiosity, Global Illumination, Hidden surface removal, culling, portal-rendering stb...

kezdésnek itt pár link

http://www.gamedev.net/reference/articles/article657.asp
http://w ww.cs.wisc.edu/~schenney/courses/cs838-f2000/large-models/visibility-1.ppt
http://www.melax.com/bsp/MelaxGDC.doc
http://www.cs.fit.edu/~wds/classes/gr aphics/Hidden/hidden/hidden.html
http://www.cc.gatech.edu/~kwatra/publication s/btpreport.ps


és sok minden van még a neten. Sok sikert a tanuláshoz.


"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
Hacker - Guests | hsz       Online status #4233   2005.05.04 05:44 GMT+1 óra  
És van olyan program amivel egyszerűen lehet BSP fát csinálni? Mert nekem ez a BSP fa módszer elég jó lenne a TrueVision enginehez csak nem tudom, hogyan tudok csinálni ilyen fát.

Programozz ne háborúzz!!!

   
Gaborious - Guests | hsz       Online status #4232   2005.05.03 04:52 GMT+1 óra  
CSak megjegyezném újra: hogy a BSP jó dolog, csaka a baj vele, hogy nem dinamikus, tehát ha vmi dinamikus, rombolható tájat akar az ember, akkor vmi mást kell használni: pl : terep esetén elég a quad-tree tárolás esetleg a bonylúltabb terep esetén pedig a octtree az ajánlott. Persze lehet ezekből egyfajta mutáns hybrid adatszerkezetet kikeverni, csak mindig mérlegeljük, hogy most akkor sok lesz-e a terepátalakítás vagy csak időnként robban vmi, MERT ha csak ritkán deformáljuk a terepet akkor lehet hogy egy BSP még mindig jó, csak deformáláskor a fa egy részét újra kell építeni (ami azért nem valami gyors),
míg ha viszonylag gyakran változik a terep akkor biztosan gyorsabb az egyszerűbb quad-tree is, bár ennek meg az a hátránya, hogy nemolyan hatékonyan szűri ki a nem látható dolgokat (vagyis biztosan nagyobb lesz az overdraw quad-tree esetén mint egy normális BSP esetén).

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
Gaborious - Guests | hsz       Online status #4231   2005.05.03 04:33 GMT+1 óra  
Idézet
syam írta:
ahoi,
a bsp fa, a teret osztja fel a benne szereplő 3szögek(poligonok) alapján ugy, hogy
Csak egy megjegyzés, szakirodalomban a BSP tree helyett használhatják a Kd tree kif.-t is. Tehát ha látod hogy Kd-tree akkor valszeg BSP ről van szó (feltéve ha K=3).

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
syam - Guests | hsz       Online status #4230   2005.05.02 15:05 GMT+1 óra  
ahoi,
a bsp fa, a teret osztja fel a benne szereplő 3szögek(poligonok) alapján ugy, hogy "elrendezi" őket, hogy melyik van "jobbra balra fel le". kicsit pongyola megfogalmazás, de a lényeg kb ez.
ha ez megvan, akkor egy adott 3szöget nagyon gyorsan meg lehet találni a sokaságban és innentől jöhet a collision detecion.
a bsp pedig egy régi találmány, doom1-3,quake1-4 + ezen enginere épülő játékok is mind ezt használják...:]


glu[ OpenGL,c++,cg ]

   
csirkee - Guests | hsz       Online status #4229   2005.05.02 12:02 GMT+1 óra  
A DarkBASIC tudja ezt használni?

CSirkee
Clan-Knights Of Xedamor
www.bdgames.uw.hu
info.bdg@citromail.hu

   
nagyy - Guests | hsz       Online status #4228   2005.05.01 06:10 GMT+1 óra  
LOD = Level Of Detail, azaz részletességi szint. Ezzel lehet pl megoldani, hogy a közelebbi dolgok részletesebbek legyenek mint a távolabbiak. Ezt a módszert a megjelenítés gyorsítására szokták használni.

nagyy

   
Hacker - Guests | hsz       Online status #4227   2005.05.01 03:09 GMT+1 óra  
Helló!

Én hallottam a BSP fáról, ami tárolja a vertexek elhelyezését és így nagyon könnyű megcsinálni egy pályát (én TrueVision-t használok és a tutoriáljában nagyon egyszerűen össze van hozva). De nekem lenne egy kérdésem: hogyan tudok BSP fát csinálni? Ja és mi az a LOD? Minek a rövidítése?

Programozz ne háborúzz!!!

   
Baz from the LKS - Guests | hsz       Online status #4226   2005.04.23 08:52 GMT+1 óra  
Hali!
Nemtom, a mi proginkban úgy lesz, hogy lemodellezzük aztán kész.
AZtán a programban megadjuk, hogy ide és ide nem szabad mennie, így nem kell ütközésvizsgálat.. persze ez nem jó egy morrowind méretű pályára

Üdv: --==[B@z]==--

   
nagyy - Guests | hsz       Online status #4225   2005.04.17 09:45 GMT+1 óra  
Üdv,

A legegyszerűbben úgy tudsz megjeleníteni egy terepet, fogsz N * M csúcspontot tartalmazó mátrixot, és ezeket megfelelően összekötve egymással kialakítssz egy háromszög listát, vagy szalagot, és ezt megjeleníted.

A domborzatot egy szürke árnyalatos képben célszerű tárolni, ami ugyanúgy N * M pixelből áll. Ilyenkor az egyes pixelek színei tárolják, hogy a terep adott pontján mekkora a magasság (pl.: fehér = a maximális magasság, fekete = nincs magasság, szürkés = az árnyalatnak megfelelő magasság) Ennek az előnye, hogy egyszerűen módosítható valami rajzprogival.

A textúrázást úgy a legegyszerűbb megoldani, ha fogsz egy kellően nagy képet (pl.: 512x512), és azt az egész terepre felteszed. Ez persze még nem tökéletes megoldás, mert a textúra nagyítása miatt a terep még elég csúnyán fog kinézni. Ezt úgy szokták megoldani, hogy készítenek egy "részletességi textúrát", amelyet pedig úgy tesznek a terepre, hogy a terep egyes mezőit fedje el. Ilyen részletességi textúra lehet pl.: egy olyan szürkeárnyalatos kép, ami a repedezett földet tárolja, stb...

Azt, hogy hova lehet menni, és hova nem úgy a legegyszerűbb vizsgálni, hogy az egyes objektumok mozgatásakor megnézzük, hogy ütközött -e egy másikkal, vagy nem. Ha ütközött vele, akkor nem lehet oda menni, egyébként lehet.

Erre a terepre az egyes tereptárgyakat külön - külön objektumonkén lehet elhelyezni, a megjelenítéskor.

Ez egyáltalán nem haékony megoldás (és nem is teljes), de kezdésnek megteszi. Ha valami hatékonyabb, és látványosabb módszer kell, akkor érdemes a LOD -ot megismerni, és használni, a textúrázást pedig célszerűbb az egyes csempékre külön-külön végezni.

nagyy

   
ShAdeVampirE - Guests | hsz       Online status #4224   2005.04.17 04:15 GMT+1 óra  
Még sosem csináltam ilyet, így gondoltam megkérdezem: ha egy FPS nézetű gámához akarok térképet készíteni, akkor azt hogyan? Szal van vmi különlegesség, amire figyelnem kell, vagy csak simán modellezzem le, és ugyan úgy jelenítsem meg mint egy tárgyat?

1előre semmi komoly nem kéne nekem, csak az alapok, de azért érdekelne, hogy pl. azt hogy tudom letárolni, hogy egy hely átjárható-e, és hogy a tárgyakat hogy helyezzem el a térképen -> külön file-ba, vagy 1be mindent?

____________________
/ ShAdeVampirE /

   
> 1 <