Nem tudja valaki, hogy a BSP fa bejárása a BSP fa melyik tulajdonsága alapján egyirányúsítható (front to back avagy back to front)?
A bináris osztás miatt vagy mert a térszelet mindenképp konvex vagy vmi más miatt?

Szerk:
Rájöttem(?) az első tulajdonság miatt.

Ja, főleg azért, mert úgy indítottam, hogy 3D axis rotation.

@ddbwo: pszt, mert hülyeséget beszélsz

Idézet

---

Pretender :
ÉS bázeg tényleg! Az up vektorra nem gondoltam. Énkérekelnézést.

---

Na az a harmadik dimenzió.
+Z vagy -Z tengely...

Egyébként D2-ben ha jól emlékszem nem 8 irányból látszanak a karakterek hanem 12 vagy több.

Sajnos sokat változott. Olyannyira adnak lefele, hogy az Anal1 helyett van először egy Matematikai Alapozás nevű tárgy. Most is Anal gyakon vannak olyanok, akik nem értik a teljes négyzetté alakítást

ÉS bázeg tényleg! Az up vektorra nem gondoltam. Énkérekelnézést.

Ide írom inkább. Nem hiszem, hogy szignifikánsan változott a linalg anyag.

A megoldás meg, cross-olod a két irányvektort és a figura up vektorjával dot-ot nézel és nézel egy előjelet.

Szerk, tudod mit? Nem fogom erre pazarolni a délelőttöm. Oldd meg, és legközelebb használd a fejed, mielőtt bárkinek nekiugrasz.

Lehet voltál linalgon. Mikor? Most? velem voltál egy csoportban? Nem. Hát akkor? Mellesleg ki mondta, hogy nekem nem lett meg, majom? x)
A cross product 2 vektorra egy 3. merőlegeset generál. x)

Hülye.

Egyrészt voltam linalgon, nekem meg is lett az EA és a gyak is.

Elég nagy fail, mert pont a cross product adja meg neked, mikor kell váltani...

De ne ugass már bele, mert nem voltál ott linalg ea-n meg gy-on. Szánalmas az a szint, amit ott nyomtak, semmit nem kellett, csak magolni pár szabályt (szövegesen) és ennyi. Mátrixot invertálni nem tanultunk meg, stb.

Tudom mi a dot-product...azért ne nézz már madárnak. A cross meg hogy jön ide? Látom nagyon értesz hozzá De akkor felvilágosítalak:
dot(v1,v2) = cos(alfa);
acos(dot) = [0;Pi]
ebből fogok csinálni [0;2Pi]-t, abból meg [0;360]-at. Csak ki kell találni, hogy mikor kell "váltani" a szöget.

Szerintem menj vissza oda, ahonnan jöttél

@Pretender, a linalg kb az egyik leghasznosabb tantárgy a 3d grafnál. De igaz, csak eszközöket ad, gondolkozni nem tanít meg.

Ha érted mi a dot product / cross product és társai, akkor ezzel egyszerű megoldani. Felírod, mögéraksz pár if-et, és hoppá működik. Kb középiskolai szint.

hát van 8 irányom, n, nw, w, sw, s, se, e, ne, ahol n=north, e=east, stb.
- Ha én a {0,0,-1} irányba nézek, az enemy meg {0,0,1} irányba (azaz szemben állunk egymással), akkor a 'n' kellene.
- Ha az enemy továbbra is {0,0,1} irányba néz, de én mögötte vagyok és én is a {0,0,1}-be nézek, akkor kellene 's'. stb.
Könnyebb lenne, ha mutathatnék képet, de nem tehetem, csak ha kész lesz

@sirpalee: dehogy kaptam... linalgon SEMMI értelmeset nem vettünk. Ezt a dot-productot is épp'hogycsak említettük. Na megpróbálok gondolkozni, lehet ideje lenne

szerk.:
Na ilyesmi kellene, azzal a különbséggel, hogy az enemy is különböző irányokba nézhet, itt meg csak a kamera forog.

Erre megfelelő eszközöket kaptál linalgon...

Valamit biztos.

Két dolgot nem értek tisztán .

Mindek a két vektor különbsége, és hogy miért csak a Z tengelyt vizsgálod, így első gondoltara négy negyedet kellene vizsgálni ahol az előjel (vagy minek nevezzem) változhat, te meg csak két felet vizsgálsz így. De korán van, szóval én kérek elnézést.

Melyik a Z koordinátád?
Melyik szöghöz melyik irány tartozik?

Én sem. Annyi, hogy mittomén', le van rakva 10, abból mondjuk 2-3nál jó, többinél nem. Nem számolom el valahol?

szerk.:
a baj azzal van, hogy az acos(dot) az [0;180] közé adja, de nekem ugye a 8 irány miatt 360 kell. Az egyiknél jó a váltás úgy, hogy a z-t nézem, a másiknál meg nem.

És mi volt a gond az általad leírt megoldással? Mert jobbat én sem tudok mint hogy a két vektor által bezárt szöggel számolj.

Az világos, hogy ronda, az is fog maradni, bár attól függ mit étesz ronda alatt.

Azt nem értem, hog yez miért csak egy ellenfélnél működik.

Ja, amúgy teljesen krumpli vagyok... írogattam, h piros kör meg ilyenek, elfelejtettem csatolni ezt a szörnyen bonyolult kis képet:

ebben az esetben pl. nekem az "észak-keleti" textúrája kellene.

2D-ben nem fog menni csak cos-al. Az egység sugarú kör mindenképpen szinusszal és cosinusszal határozható meg 2D-s vektorként. (sin, cos) vagy (cos, sin)..



Egyszerűbb, ha a kamera forgási szögét tartod meg. Azt a szörny megkaphatja. 360 - kamera vagy ilyesmi lesz a viszonya hozzád képest.
---
A kamera meg amúgy is rad vagy deg alapján forog. Csak ne engedd szabadon...

if (kameraZdeg>=360) kameraZdeg-=360;

A mátrixot alapról számold minden körben, ne összeadásként.

nem dió2 stílusú lenne azt csak példának mondtam, hogy ott is megfelelő szögnél megfelelő textúra volt. FPS lesz.
Fordul az enemy v. máshonnan nézzük, akkor másik textúra kell. Annyi, hogy pl.
- néz előre, mi mögötte vagyunk, akkor a hátát rajzoljuk
- néz jobbra, ugyan onnan nézzük mint az előbb, akkor a jobb oldalát rajzoljuk
- néz előre, de szemből nézzük, akkor az elejét rajzoljuk
- stb.

Értem én, de hogy gondoltad?

Szóval billboard szörnyek vannak, szóval forgáskor mindig ugyan azt látod, ami diablo féle madártávlabol furcsán hat a szemnek FPS-ben még elmegy, meg hozzászoktunk a doom óta.

Ez még OK is de a 8 irányú karaktert hogy képzelted? forgásnál ha eléíri a kamera azt a szöget, akkor grafikát vált?

Egyébként meg minek a kamera forgatás egy dió2 stílusú játékhoz?

Hát mondjuk az ellenfél csak előre néz, Te meg körbe tudod járni. Mintha a diablo 2-ben tudnád forgatni a kamerát.

forgó kamera fix 8 irányú animmal? hát elég furán hangzik.

Nem hiszem, hogy ezt szépre meg lehet csinálni.

Oké... nem tudok rájönni
egy Diablo 2-féle dolgot akarnék megvalósítani. Vannak animációim 8 szögből. A diablo 2-ben azért egyszerű, mert ott a kamera fix, csak a játékos mozog, az alapján kell kiválasztani a megfelelő szögű animációt. Ilyesmi kellene nekem is, azzal a különbséggel, hogy úgymond a kamera is foroghat (ugye a játékos), ezért más lehet a nézési irány. Amit ismerek:
- játékos pozíciója (zöld karika)
- ellenfél pozíciója (piros karika)
- ellenfél hogy merre néz (piros nyíl)
- meg hogy mi merre nézünk, de ez azért nem fontos, mert billboardok, szóval a játékos és ellenfél közötti irány.
Próbáltam így:

és aztán szögekre belőni, de ez azért:
- nem az igazi
- elég ronda
- nem is működik. Pontosabban 1 ellenfélre jó volt.

Az a tutorial nagyon jó^^

http://sakura7.blog.hu/2011/08/11/ismeretlen_vizeken_pathfinding

olyan hál'Istennek nem lesz, hogy nincs út. Ahova mi el tudtunk jutni, oda az enemy is el tud jutni. Ahogy néztem amúgy ez alapján hasonlóan súlyozással megy, bár annyival olcsóbb, mint a dijkstra, hogy az adott node 8 szomszédját kell csak megnézni. Azt hiszem.
Akkor megnézzük azt, ha nincs annál egyszerűbb. A pálya max. 64x64-es

Akkor használd azt Nem igazán bonyolult, és ha az úticél közel van akkor pillanatok alatt megtalálja az utat. Gáz csak akkor van ha nincs út a két pont között, mert akkor az egész játékteret bejárja.

mondtam én, hogy nem jó?

Miért nem jó az A*?

Vannak falak, meg tereptárgyak, meg egyéb pontok, ahova lehet lépni. Az ellenfélnek utat kell találnia hozzánk. Első körben egy dijkstra készült el, ahol a "foglalt" pontok (tehát mondjuk fal) súlya egy meghatározott MAX érték. Viszont ez látszik, hogy nem jó megoldás, mert rengeteg keresést kell végrehajtani a szabad pontok között (már egy 32x32-es szobánál is 1024, ráadásul mindig "duplán" kell iterálni).

A kérdésem az lenne, hogy van-e olyan útkereső algoritmus, amihez csak a nem szabad pontok / szakaszok ismerete szükséges, egyébként meg bárhova léphet, és viszonylag egyszerű? (telefonra kellene)

Nekem sem 2D a világ, csak nincsenek átfedések és ferde falak, tehát elég a 2d-s ütközés amúgy nem igazán érted a problémát, de nem mondhatok többet a projektről meg fogom oldani, valami ilyesmi lesz amúgy. Vagy továbbra is az lesz, hogy ki lesz gyűjtve collision meshként

Összetett mesheknél és teljes vonal tesztnél (nem szűrünk a ray irány alapján) nincs gond az élekkel, csak akkor, ha önmagában egyedül az éterben lebegő plane van a jelenetben. De amúgy nem kell él távolság sem, max rendes fizikához.

2D alapúhoz "2D line-point distance" elég. Csak találni a google-lel. Nekem nem kő 2D.
Fujj 2D!

Ha a pontot a plane-re (vagy triangle síkjára) vetíted, akkor mindenképpen merőleges lesz. Nem a mozgás irányvektorát kell nézni, hanem a pont-sík távolságot. A fal normálját kiolvashatod. Ha a kör középpontjának és a síkra merőleges intersection point távolsága rövidebb a sugárnál, akkor van ütközés.
(point-plane distance)

Tehát a vizsgált sugár (ray) iránya mindig a vizsgált sík normáljának a fordítottja kell hogy legyen. Ez a karikák és gömbök szabálya. ebben az esetben a sarkak vészesek, de a kör vagy gömb középpontját még mindig rá lehet mérni az élek távolságára.

1. kör középpont->sík (a sík fordított normálja a ray iránya)
2. élek pontja - kör középpont távolság. (a sarkakhoz, élekhez)

// uff, ezt neccesen lehet megfogalmazni, de remélem azért kijön amit írni akartam.

javítva... teszteltem magamnak.. a sarkakat 2 dimenziós távolsággal elég mérni a 2D-s középponthoz, nem lassabb mint "IF"ezni a közeli uv-t.

Nekem nem azzal van a baj. A probléma ott van, hogy a falakat külön nem ismerem, csak vagy egységenként, vagy már ahogy véglegesen van, textúránként. Tehát mindenképpen kell valami logikai nem látható fal, ami irányonként csoportosítja egybe. Amúgy meg minden merőleges, tehát minden AABB (bár ránézésre hamarabb mondaná az ember 2d-nek az egész cuccot, mint 3d-nek )

Pretender:
Az eltolás nem jó megoldás, maximum ha mindenhol axis aligned bounding boxot használsz, és még a falak is axis alignedek, de az meg furán néz ki.

Képzeld el, hogy a mozgó objektum egy kör (2D, vagy felülnézet), és ütköznie kell egy objektummal, ami felülről egy négyzet. Ha a kört ponttá redukálod, a falakat meg eltolod sugárnyival, akkor gondolj bele, hogy mi lesz a sarkokkal való ütközésnél. Sokkal egyszerűbb és értelmesebb a kör sugarával számolni, nem kell macerálni a pályát, és ha eltérő sugarú objektumaid vannak, azok is működni fognak. Még ha kell, kódot is adok.

Nem sarkokra gondolsz? kitalálom még majd. Lehet, hogy ígyis-úgyis kell az, hogy "egybeolvasszam" a falakat egy-egy láthatatlan falba, akkor meg már majdnem mindegy, hogy odébbrakom-e őket, és akkor lényegesen egyszerűbb lenne a számolás. Majd látom

Az éleknél szokott a dolog durvulni.

@ddbwo: ez a kisebb az intersection pont a sugárnál dolog azért nem igaz, mert ha annyira "ferdén" megyünk, akkor hamarabb is ütköznünk kell, mint a középpont - intersection pont < r. pl.:

Én a Z-t szedtem ki a képletből, de nem sokat jelent szinte.
Dinamikoknál: R1 + R2 középpont távolság alatt van ütközés. Dinamic szinten elég ha nem lép akkor abban a körben a dolog, de a normált is át lehet adni.

Gömb triangle (plane, sík):

A távolságot megkapjuk. Az alapján kell a pontot a síkra vetíteni az uv-hez.
Gömbnél vagy "zöld karikánál":
Egyszerű a dolog, ha kisebb az intersection point távolsága a sugárnál (vagy átmérő fele), ütközés lesz. (ilyenkor vagy nem mozog, vagy pontosíthatsz Matzi módra).

Lehet két geometria is, egyik az ami megjelenik (modell) és szanaszét rücskös, horpadt, meg minden. A másik meg lehet az ütközéses geometria, ami lehet már full függőleges. De úgy berakva, hogy ne lógjon a falba...

Tényleg, ennyi lenne. Még átgondolom majd, köszi.

A 2 és a 3 D között nincs nagy különbség, ha körrel és gömbbel szeretnél ütközni, illetve azok ütköznek szakasznak vagy háromszögnek.

Kb a lépések az alábbiak:
- Megnézed, hogy a középpont a mozgás közben metszi e a síkot/egyenest, vagy megy e annak a közelébe ( táv < R)
- Ha igen, akkor megnézed, hogy ha az egyenest/síkot a normálja mentén R-el a pont felé tolod, akkor menni utat kell megtennie a középpontnak, hogy érintse az egyenest/síkot.
- Kiszámolod, hogy ez a pont hol van az eredeti (nem eltolt) egyensesen/síkon
- A megkapott pontot megnézed, hogy rajta van e a szakaszon/háromszögön
- Ha nincs, akkor veszed a legközelebbi pontját, és megnézed, hogy az a pont érinti e a kört/gömböt a pályájának valamelyik pontját, és ha igen, akkor mennyi távot tesz meg (erre van egy jó és egyszerű függvény, nem vészes)
- Ha az előbbi két lépés valamelyikéből valamelyikre kijött egy pont meg egy távolság, akkor már csak el kell mozdítanod a testet a távval (-epszilon), és az új középpont, meg az érintési pontból felületi normált számítani, és az alapján elcsúsztani tovább

Nem lesz szintkülönbség meg semmi, csak és kizárólag merőleges falak. Természetesen legelőször gömbben gondolkoztam, de arra nem jöttem rá, hogy hogy csináltam meg. Elég a 2D.

Ha nincs semmi egyéb körülmény, akkor persze, jobban megéri, egyszerűbb számolni vele. Ha mondjuk akarsz szintkülönbségeket, vagy egymás tetejére rakott dolgokat, akkor már jobb a 3D.

Amúgy nem kell láthatatlan fal, elég ha a játékos nem pontszerű, hanem egy gömb/kör/henger, dimenziótól függően.

Van egy 3d-s szobám, merőleges falak, csak az y = 0 pozícióban tudok mozogni. Hogy érdemes ezekre sliding collisiont számolni? Első körben azon gondolkoztam, hogy valahogy megoldom, hogy legyen egy láthatatlan fal rész is (ami nyilván "bentebb van" a falnál) amivel konkréten ütközünk. Ekkor ray-triangle metszéssel, először odarakom az intersect ponthoz, aztán sliding.
A kérdés az, hogy jobban megéri-e 2d-ben kezelni az egészet? Tehát vonalaim vannak, meg egy kicsi "sugár" (inkább szakasz), ami a játékos jelenlegi pozíciójából a következő pozíciójába mutat.

Na igen, az lehet. A kérdés onnantól már csak az, hogy megéri-e egy early z-cullt egybekötni azzal, hogy kirenderelem a depthmapet (mert úgyis kelleni fog), vagy mrt-be 1be rendereljem a geometriát... Multipassnál talán az előbbi hatásosabb lenne.

Szerintem ekkora méretnél valószínűleg a multipass a gyorsabb. Ha nem hat mind a 10 fény ugyanarra a meshre, akkor lehet, hogy egy menetben is jól megoldható lenne a dolog, csak ügyesen kell átadni a shadernek a fényeket.

Nem biztos, hogy teljesen idevaló a kérdés, de hát akkor hova? Na mind1.
Tehát: most van egy (mondjuk jó) kis deferred shadingem, és nem lenne egyszerre a jelenetben látható túl sok fény, ezért azon gondolkoztam, hogy egy mondjuk 10 point lightos scene mikor lenne a leggyorsabb?
- deferred shading (ez van most, szükséges: mrt, nagyobb sávszél a vga-nak, stb.)
- multipass lighting lenne úgy, hogy 1 a geometry pass, de ott is mrt-t írnék (shading + color. szükséges: szintén mrt)
- multipass lighting: úgy, hogy első passban depth write + read, kiírom a depthet textúrába, azután depth write off csak read marad, majd jöhet a shading.
Nyilván talán kellene majd front to back renderelés

Pedig kivancsi lettem volna ra...

Idézet

---

HomeGnome :
"Nem pixel alapon rajzol, hanem rgb szerint.." OMG..

---

inkább ki is törölte, ahogy látom

"Nem pixel alapon rajzol, hanem rgb szerint.." OMG..