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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [21]
Asylum - Törzstag | 5448 hsz       Online status #205931   2014.12.30 17:17 GMT+1 óra  
Írtam én is hasonló cikket, nem tudom segít-e. Írj inkább kódot, mert nem értem mi a probléma.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Cimpi - Tag | 3 hsz       Online status #205897   2014.12.27 09:52 GMT+1 óra  
Sziasztok!

Egy régebbi cikkel kapcsolatban szeretném a segítségeteket kérni. Crusader írta meglehetősen régen ami egy Tárgy kiválasztásával foglalkozik a modelltérben. Tökéletesen megy a dolog, mert adaptáltam a saját motoromba, de egy dologra nincs felkészítve ugyanis tökéletesen működik egészen addig amíg a kamerát el nem fordítom az X (itt vízszintes) tengely körül - a program továbbra is működik de pontatlan lesz, nem lehet nagy hibája, de én eddig nem találtam megoldást rá. A feladat elég komplex ezért nem hiszem, hogy valaki rá tudna szánni elég időt, hogy nekiálljon elemezni a cikket, bár szerintem elég hasznos lehet - inkább az lenne a kérdésem, hogy van-e esetleg olyan közöttetek, aki találkozott, már ezzel a problémával és tudna segíteni, vagy egy - ezt a témát boncoló oldalra tudna irányítani?
A fáradozásért előre is köszönet!

Ezt a hozzászólást Cimpi módosította (2014.12.27 10:11 GMT+1 óra, 1057 nap)

   
Instalok - Tag | 543 hsz       Online status #205163   2014.10.23 13:51 GMT+1 óra  
Nyilván nem az a része érdekelt, hogy limitálnom kell, hiszen a más libekből elérhető mátrixok sem akadnak ki ezekre. Emlékeim szerint például a gluLookAt és a DirectX D3DXMatrixLookAtLH sem akad ki rá, és gyártani fog valami mátrixot.

Emellett az if a nyilvánvaló megoldás, csak hátha van valami szebb, azért kérdeztem.

   
ddbwo - Tag | 1625 hsz       Online status #205160   2014.10.23 11:48 GMT+1 óra  
Az egész orientációt transzformálni kell. Mindhárom vektort.
Vagy limit fel-le pl 89°.

Ha nincs meg a right, akkor a dir és up egyenes lesz, azaz "nem lehet kitalálni" merre volt jobbra.
---

Ha direktbe csak "target" van, akkor feltétel vizsgálat, a right 0 négyzethossz esetén utolsó right. Ehhez a rightot jegyezni kellene.

Ezt a hozzászólást ddbwo módosította (2014.10.23 12:29 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Instalok - Tag | 543 hsz       Online status #205159   2014.10.23 08:53 GMT+1 óra  
View mátrix számolásnál ugye adott a world up vektor, egy eye position és egy target position. Az utóbbi kettőből számolunk egy irányvektort, majd egy right vektort az up és az irányvektor segítségével. Szóval valami ilyesmi:
Kód:
dir = normalize(target - eye);
right = normalize(cross(up, dir));
up = cross(dir, right);

A problémám az, hogy, ha a dir pontosan a (0, -1, 0) az up pedig (0, 1, 0), akkor a cross product eredménye (0, 0, 0). Ez a normalizálásnál is, és az utána következő cross productnál is gondot okoz. Mivel szokták ezt szépen kiküszöbölni?

   
Asylum - Törzstag | 5448 hsz       Online status #204258   2014.07.26 18:13 GMT+1 óra  
Picit gondolkodtam és (az egyszerűség kedvéért egy négyszög + befglaló körre): optimális esetben

Kód:
<v1 - c, v1 - c> = r^2
<v2 - c, v2 - c> = r^2
<v3 - c, v3 - c> = r^2
<v4 - c, v4 - c> = r^2


4 ismeretlen van (cx, cy, cz, r), viszont ez nemlineáris egyenletrendszer, úgyhogy sima mátrix invertálással nem lehet megoldani. De ki lehet silabizálni belőle.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 543 hsz       Online status #204252   2014.07.26 15:36 GMT+1 óra  
Egy csonkagúlához (view frustum) tartozó minimális befoglaló gömböt keresem. Eddig a következő nem túl pontos algoritmust használtam:
Kód:
center := sum(frustum_points) / count(frustum_point);
radius := max(distance(center, frustum_points))

Ez azonban valószínűleg nem ad minimális eredményt, és léteznek ennél jobb megoldások is. Használtam picit a Google-t is, de nem szívesen olvasok "krix-kraxokat", amíg nem muszáj.

   
ddbwo - Tag | 1625 hsz       Online status #202838   2014.05.02 15:29 GMT+1 óra  
Ja hogy "tile-based_deferred_rendering".
Ha ezt egyből tudom, mindjárt mondtam volna is, hogy olyat nem csináltam.
Ha a Frostbite2 használja, gondolom jó az.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
syam - Törzstag | 1491 hsz       Online status #202837   2014.05.02 12:22 GMT+1 óra  
M4:
Köszi
Az első felállás szerint a frustum csúcsait nem lehetett felhasználni azért voltam tanácstalan.
Éjjel viszont leesett , hogy "vazz, a csúcsokból számolom ki a síkokat"
Onnantól meg egyszerű: gömb - frustum vágás, ha ez igent mond, akkor ponthalmaz - sík vágás.

A teljes sztori itt:
http://sakura7.blog.hu/2014/05/02/tile-based_deferred_rendering
alias aalberik
   
syam - Törzstag | 1491 hsz       Online status #202834   2014.05.01 23:17 GMT+1 óra  
törölve

Ezt a hozzászólást syam módosította (2014.05.02 00:15 GMT+1 óra, ---)
alias aalberik
   
M4 - Tag | 187 hsz       Online status #202833   2014.05.01 22:32 GMT+1 óra  
Elsőre könnyebbnek tűnt, de aztán kitaláltam a megoldást. Remélem nincs benne hiba.
1. A félgömb a frustumban van. Ha a gömb közepe a frustumban van, akkor metszik egymást.
2. A frustum a félgömbben van. Ha a frustum valamelyik csúcsa a félgömbben van, metszik egymást.
3. A félgömb és a frustum határai metszik egymást. Kiválasztjuk a frustum egy oldalát. A (most még teljes) gömbbel metszetjük. Ekkor megtudjuk milyen messze van a gömb közepe az oldal síkjától, és hogy mekkora kört metsz (ha metsz). A metszőkör közepét és az átmérőjét vetítsük a gömböt vágó sík normáljára. Ha a vetített szakasz átmegy a vágósíkon a pozitív részbe, a metszőkörnek lesz olyan pontja, ami a félgömbön van. Most nézzük meg mi van, ha a metszőkör a síkon nem teljesen a frustum oldalát metszi. Metsszük az oldalt a körrel. Ekkor egy körívekből és szakaszokból álló "sokszöget" kapunk. Ha a körív legpozitívabb pontja (ha vetitjük a kört a vágósík normáljára a kapott szakasz legpozitívabb pontja) még a sokszög része, akkor azt vizsgáljuk metszi-e a félgömböt. Ha nem a sokszög része, akkor a sokszög egyik csúcsa lesz a legpozitívabb. Azokat vizsgájuk meg hogy a félgömbön van-e.
Ha ezt a műveletet elvégezzük az összes oldalra, megvagyunk. De nem kell mindet megnézni. Ha a gömb középpontja az egyik szemközti oldalpár síkja között van, akkor azokat az oldalakat nem kell megnézni, mert ha ott van metszéspont, akkor lesz másik oldalon is. Szóval maximum három oldallal kell metszetni.
Szerk: ja elfelejtettem, a félgömb körlapkáját is meg kell nézni, hogy metszi-e a frustum egy oldalát. (gondolkozom...) Lehet hogy ezt az esetet nem kell megvizsgálni.

Ezt a hozzászólást M4 módosította (2014.05.01 22:44 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #202831   2014.05.01 15:38 GMT+1 óra  
Idézet
syam :
A feladat frustum és spot light fénytere közötti érintkezés detektálása.
Az elérhető adatok pedig azok amiket felsoroltam.
Most már úgy látom, hogy a kúp-frustum metszés kivitelezhetőbb, mint a félgömb-frustum.


Egy kúp eleve nem ír le jobban egy spot lightot, mint egy félgömb? Ha nem kell túl nagy pontosság, akkor egy object-oriented boundingbox is szóba jöhet.

   
ddbwo - Tag | 1625 hsz       Online status #202830   2014.05.01 14:39 GMT+1 óra  
Arra egy cone-cone félét találtam ki. De az nem lesz neten. Legalábbis nem programozás szempontból írják, amit nem volt kedvem boncolgatni...

Másik megközelítés a közös objektum szemszögéből (ha lehetséges) frustum&&cone
illetve esetleg frustum&&frustum
A végeredmény hasonló.

A cone csak matematikailag írható körül, a síkkal vagdosás meg macerássá teszi az egészet.

(sík-szakasz,beesési szög, távolság arány) és az kivül vagy belül esik a frustumon...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
syam - Törzstag | 1491 hsz       Online status #202829   2014.05.01 12:52 GMT+1 óra  
A feladat frustum és spot light fénytere közötti érintkezés detektálása.
Az elérhető adatok pedig azok amiket felsoroltam.
Most már úgy látom, hogy a kúp-frustum metszés kivitelezhetőbb, mint a félgömb-frustum.
alias aalberik
   
ddbwo - Tag | 1625 hsz       Online status #202826   2014.05.01 10:24 GMT+1 óra  
Mindenképpen félgömb kell?

Csak ha az első gömb teszt sikeres, egy dot ellenőrzés marad... Jaa. A Hesse normal form-ra vetített középponthoz mérten. A vége lemaradt.

Ezt a hozzászólást ddbwo módosította (2014.05.01 10:33 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
syam - Törzstag | 1491 hsz       Online status #202822   2014.04.30 22:19 GMT+1 óra  
Foglalkozott már vki frustum - félgömb metszésével?
Mindkettő tetszőleges helyzetű lehet és csak a metszés megléte - nem léte érdekes.

A frustumnak síkjai adottak Hesse alakban. A félgömb a középpontjával, sugarával és egy normál vektorral van megadva.

Ezt a hozzászólást syam módosította (2014.04.30 22:33 GMT+1 óra, ---)
alias aalberik
   
ddbwo - Tag | 1625 hsz       Online status #202670   2014.04.17 21:31 GMT+1 óra  
Idézet
Marcsello :
ddbwo: érzem, hogy te rátaláltál a megoldásra, csak nem tudom dekódolni, amit írtál



Sorry, kapkodtam.

Azért volt rossz helyen, mert a sarka a pozíciója, de arra lett forgatva, nem a közepéhez mérten.
Innen lefelé menet első képen látszik. A sarka vagyis a pozíció elfordul fejjel lefelé (bal fentről jobb lentre), míg a kép a sprite igazi középpontján forog.
---
De ha sikerült, akkor m1.

Ezt a hozzászólást ddbwo módosította (2014.04.17 21:37 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Pretender - Törzstag | 2498 hsz       Online status #202669   2014.04.17 19:42 GMT+1 óra  
Ezért voltam arra kíváncsi, hogy a sarokpont az jól megvan-e, mert ha igen, akkor az a számítás jó, és a sprite forgatásával lesz a gond, ami valószínűleg a saját középpontja körül forgatott. Az a lényeg, hogy megvan.

Ja igen, egyébként a lila téglalapot nem is teljesen értettem, de most már vágom!

   
Marcsello - Tag | 228 hsz       Online status #202668   2014.04.17 18:55 GMT+1 óra  
Megvan:

Hosszas source kód boncolgatás után (mert dokumentáció az úgy, nem létezik, úgy látszik Ukránban nem divat)
ráátaláltam, arra, hogy ha FX-ként adok neki egy FX2D_RPIVOT-ot, akkor a csücskétől fogja forgatni. De persze ezt sehol nem találtam meg leírva nos az elforgatott, már leírt vektorral, és ezzel együtt úgy néz ki, hogy rajta marad. Azért nem kiabálom el előre, kipróbálom még pár helyzetben, bár ráközelítve úgy látszik, mintha itt is egy kicsit kimászna mögüle a body
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Marcsello - Tag | 228 hsz       Online status #202667   2014.04.17 18:18 GMT+1 óra  
Erre van rajta a lila keret az a sprite méretei, csak 0 angle-val, de azért raktam rá egy bógyót is.
Igen, szépen követi a bogyó a body-t. és ebben a keretben marad a sprite is, csak ő ugye a saját tengelye körül szeretne elfordulni, nem pedig, a csücske körül

---
ez a második ide is bedobott kódrészlettel van, de a bogyó tényleg jó szemléltető eszköz, mert ezeken ránézésre valóban nem látszik
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Pretender - Törzstag | 2498 hsz       Online status #202666   2014.04.17 18:12 GMT+1 óra  
Na, ugyan ezt mondtam én is, ha megnézed
Mondom, szerintem próbáld ki azt, hogy nem forgatod a spriteot, hanem csináld a következőt:

Fogsz egy ilyen gombóc textúrát, amit mindig ráillesztesz a bal felső sarokra. 0 angle esetén ez ugye adott. Elforgatáskor pedig követnie kéne a body (alias logikai objektum) bal felső sarkát. Ha nem ezt teszi, akkor látszik, hogy annál a számolásnál van bibi (egyébként nem fordítva van a cos és sin? kicsit bamba vagyok ma felfogni ). Ha viszont a kis bogyó követi a bal felső sarkot, akkor a beépített rajzolással van a gond.

   
Marcsello - Tag | 228 hsz       Online status #202665   2014.04.17 18:04 GMT+1 óra  
Nah, akkor tisztázzunk.
- A Sprite a saját középpontja körül forog (ez a képe a sótartónak)
- A Sprite pozíciója a bal felső sarka
- A fizikai(logikai) objektum pedig a gombóccal jelölt középpontja körűl... (illetve ahol megfogjuk egérrel, de az angle-t a gombóctól méri)
- addott egy texrect változó ami tartalmazza azt, hogy a fizikai body gombóccal jelölt központjától relatíve menyire kell eltolni a spritet, hogy 0 angleban rá illeszkedjen, ez általában mínusz érték (jah az előbb rosszat írtam: x: -26.060 y: -141.000 a sótartóé)
- ezen kívül a texrect tartalmazza a kép szélességét/magasságát, ezeknek fele a csücsöktől számított közepe (ez körül forog is)
- adott a pos változó, ami tartalmazza a body gombóccal jelölt középpontját a nagy egyetemes világűrben
- adott az angle, ami a body forgása
- az origó a bal felső sarokban van (ha ez számít, és lefele, és jobbra növekszik)

Tehát amik vannak

Body:
- pos
- angle

Sprite
- x,y (csücsök relatíve a body középpontjától)
- w,h

alapfelállásban csak szépen összeadtam a pos-t a texrect-el így egyhelyben állva jó volt,
de amikor elfordult az első ábrát adta vissza

tehát továbbra is a body középpontjától kéne eltolni, csak a forgatástól függően valami számítással

ddbwo: érzem, hogy te rátaláltál a megoldásra, csak nem tudom dekódolni, amit írtál

/ránézésre valóban látszik egy kis elcsúszás 0 angle-ban is de az azért van, mert elcsesztem a ráillesztést, az nem számít/
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Pretender - Törzstag | 2498 hsz       Online status #202664   2014.04.17 17:14 GMT+1 óra  
Egyébként a logikai objektum forgatása a középpontja szerint van? Mert ha nem, akkor ott van a gond. Próbáldd meg esetleg úgy kirajzolni, hogy a forgatást nem veszed figyelembe, csak a középpontot lövöd be (mármint a draw hívásnál 0 angle-t adsz át neki), mert lehet, hogy azon belül van valami furcsaság.

szerk.:
Mert ugye lehet, hogy az a gond, hogy kiszámolod a középponthoz képest a textúra bal felső sarkát. Ha a draw függvényen belül pedig a textúrát a középpont szerint forgatja, akkor jóhogy nem lesz jó.

Hogy jól értem-e:
Adott egy logikai objektum, aminek ismerjük a középpontját.
Adott egy radiánban mért szög, ami megmondja, hogy a logikai objektum mennyivel fordult el. Ez az elforgatás a középpontján át történik.
Adott egy textúra, aminek ki szeretnénk számolni a bal felső sarkát ami illeszkedik az elforgatott logikai objektumra.
Ezt úgy próbáljuk meg elérni, hogy a 0 angle esetén kiszámolt eltolás vektort áttranszformálod a logikai objektum terébe (legalábbis forgatás szempontjából). Ettől meg ugye azt várnánk, hogy az elforgatott ojjektum bal felső sarkát kapjuk meg.

Ezt a hozzászólást Pretender módosította (2014.04.17 17:20 GMT+1 óra, ---)

   
ddbwo - Tag | 1625 hsz       Online status #202663   2014.04.17 15:34 GMT+1 óra  
Aha. megvan. Látom. A forgatás a középpontra megy, az eltolás a bal felső sarokra.
---

A kép középpontját kell kiszámolni, a középpont és a body különbözetét és a sprite sarkának a pozícióját. Jó cucc, nem mondom...
---

Tehát a korrekció az a bodyPos+spriteCenter elforgatása
A kép helye a bodypos-korrekció+keretpos.
---

Természetesen a spriteCentert a bodyCenter-hez mérten kell elforgatni...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
ddbwo - Tag | 1625 hsz       Online status #202662   2014.04.17 15:14 GMT+1 óra  
Én is a GL keretein kívül értettem.

A pont forgatása már megvan.

A kép középpontjának és a body középpontjának a különbségét kell elforgatni. Ez lesz a csúszás. Tehát a kép koordinátájából ki kell vonni az elcsúszást.

bodyPos-csúszás. De a forgatásnak két iránya lehet, nem mindegy melyiket használja a ZenGL. Ha ezt, akkor úgy jó.
-----------------

Ha a body aabb közepére megy. és a képen valamekkora igazítás van. Legalábbis úgy vettem ki.

De ha a cucc gyorsan vagy sokat forog, és sokszorosan túllépi a 360 fokot, akkor csúszás lesz a pontatlanság miatt.

Ezt a hozzászólást ddbwo módosította (2014.04.17 15:30 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Marcsello - Tag | 228 hsz       Online status #202661   2014.04.17 14:49 GMT+1 óra  
Idézet
Pretender :
Nem valami olyasmi kellene, hogy megvan az eredeti állapotában az eltolás x,y irányban. Majd fogod, ezt a két vektort transzformálod egy forgatási mátrixszal, ami az angle-nek felel meg. Azaz, ha úgy tetszik, megkapod az objektum saját terében a két eredeti vektort.



Igen, Ez kell nekem.
És ennek a matematikai része, mert gugliztam kicsit, és erre találtam: [url]http://en.wikipedia.org/wiki/Rotation_(mathematics)[/url]


Amiből a következőt csináltam:


Kód:
// texrect <- az eredeti eltolás vektor
// pos <- a body középpontjának pozíciója
// Body^.a <- radiánban az elforgatás

rotDpos.x:= (texrect.x * cos(Body^.a)) - (texrect.y * sin(Body^.a));
rotDpos.y:= (texrect.x * sin(Body^.a)) + (texrect.y * cos(Body^.a));

ssprite2d_Draw(tex, pos.x + rotDpos.x , pos.y + rotDpos.y , texrect.w, texrect.h, (Body^.a * rad2deg),255);


nos, az eredeti eltolás vektor:
x: -116.330 y: -141.000

és csak azt értem el, hogy még nagyobb ívben száll le:





Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Pretender - Törzstag | 2498 hsz       Online status #202659   2014.04.17 14:22 GMT+1 óra  
Nem valami olyasmi kellene, hogy megvan az eredeti állapotában az eltolás x,y irányban. Majd fogod, ezt a két vektort transzformálod egy forgatási mátrixszal, ami az angle-nek felel meg. Azaz, ha úgy tetszik, megkapod az objektum saját terében a két eredeti vektort.

   
Marcsello - Tag | 228 hsz       Online status #202658   2014.04.17 14:00 GMT+1 óra  
Igen, csak az a helyzet, hogy ZenGL-ből kimaradt az a hatalmas OpenGL csoda, hogy elforgatom, aztán tologatom. Csak egy szép kis függvény van, miszerint:
Kód:
ssprite2d_Draw(..., X , Y , W , H , Angle ,...);

Szóval valami csodamatematikával kellene utána tolni a koordinátákat.
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
ddbwo - Tag | 1625 hsz       Online status #202655   2014.04.17 12:36 GMT+1 óra  
A kép középpontját el kell forgatni a body középpontjához mérten és arra eltolni. Matematikailag ennyi. A többinek a spec cuccait nem tudom.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Marcsello - Tag | 228 hsz       Online status #202652   2014.04.17 10:14 GMT+1 óra  
Hatalmas, Orbitális nagy problémával állok szemben, ami inkább matematikai, mint fizikai, de a fizikához is köze van.
A lényeg a lényeg, hogy Chipmunk-ban szerkesztgetek, és elhatároztam, hogy rakok valami szép textúrát azokra a bodykra. Ezzel nincs is semmi baj. kiszámoltam szépen hogy a body középpontjától menyire kell eltolni a kép sarkát, szépen ráraktam, csak az a baj, hogy valahogy ahogy elforog, mivel nem a pontos közepén van a közepe, így szépen lecsúszik róla a kép, mivel az meg a saját középpontja körül fordul el.

Itt van egy kis szemléltetés is:

Itt viszonylag jól áll:


Itt szépen lecsúszott:


Itt meg teljesen:


A Kék vonal az maga a fizikai objektum a Lilás pedig a középpontjára rámért eltolás (a kép csücskéhez), és oda van írva mellé a középpontjának a koordinátái, amit egy cián bóha jelöl, amihez mérten elv van tolva.

Szóval valamit kéne művelni a kép koordinátáival, csak fogalmam sincs, hogy mit, és három napja nem is tudok rájönni.
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Pretender - Törzstag | 2498 hsz       Online status #201213   2014.02.15 17:28 GMT+1 óra  
Nagyobb terepre mivel érdemes útkeresést csinálni? Néztem ezt a navmesht, teljesen érthető, hogy hogy működik, de egy nagyobb outdoor scenere nem lesz túl nagy az adatmennyiség? Főleg, ha feltételezzük, hogy a legtöbb terület bejárható, viszont sok (viszonylag kicsi) járhatatlan terep van (sziklák, dobozok, stb.). Ezek mentén ugye osztani kell a mesht, amik növelik a gráf méretét, ezáltal az algoritmus futási idejét. Arról nem is beszélve, hogy a memóriaigény is növekszik.
Továbbá számomra kérdéses még a "görbe" felületek körbejárása is. Gondolom valamilyen kerekítéssel oldják meg, hogy ne álljon végtelen számú háromszögből / polygonból az adott rész.

   
Pretender - Törzstag | 2498 hsz       Online status #201184   2014.02.13 21:09 GMT+1 óra  
Komplett quaternion osztály, hátha kell valakinek...

   
nab - Tag | 30 hsz       Online status #198931   2013.11.07 11:18 GMT+1 óra  
Ok, kösz.

   
Marcsello - Tag | 228 hsz       Online status #198924   2013.11.07 06:38 GMT+1 óra  
nekem valami ilyesmi van, ami üzemel is:
x = x + (speed * sin(fok))
y = y - (speed * cos(fok))
persze ha a fokot a lua radiánban kéri, akkor
fok = (fok / 180) * Pi
az hogy összeadás vagy kivonás a képernyő viszonyaitól függ
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
fpeti - Törzstag | 1291 hsz       Online status #198922   2013.11.07 01:21 GMT+1 óra  
Vmi ilyesmi kéne, ez pszeudokód:

Kód:
xadd = cos(radian(ship.rotation))
yadd = sin(radian(ship.rotation))

ship.x = ship.x + xadd * SPEED;
ship.y = ship.y + yadd * SPEED;
   
nab - Tag | 30 hsz       Online status #198915   2013.11.06 20:51 GMT+1 óra  
Hello

Nem vagyok egy matek zseni ezért kéne egy kis help.

Csinálok egy játékot amiben egy hajót akarok mozgatni az űrben. 2D -röl van szó.

A hajó mozgatását nem tudom megoldani. Így szeretném megvalósítani: http://www.youtube.com/watch?v=_brww6GHGeE

A kódom lua -ában vagy mert Corona SDK -ban csinálgatom.

Kód:
local function onKeyEvent( event )
    if event.nativeKeyCode == 65 then -- A
    ship.rotation = ship.rotation - 3
    end
    if event.nativeKeyCode == 68 then -- D
    ship.rotation = ship.rotation + 3
    end
    if event.nativeKeyCode == 87 then -- W
        SPEED = SPEED + 1
    end
    if event.nativeKeyCode == 83 then -- S
    ship.y = ship.y + 3
    end
    return false
end

local t = {}
function t:timer( event )
        ship.y = ship.y - SPEED
end


Szóval az érdekelne, hogy amikor elfordul a hajó és mozdul előre akkor abban a fokban kéne elmozdulni amerre éppen nézek, ehhez szögfüggvénnyel ki kéne számolni, de hogyan?

Ha valaki segítene megköszönném.

   
Asylum - Törzstag | 5448 hsz       Online status #194496   2013.06.03 20:54 GMT+1 óra  
Ezek a kavterniók azok amiktöl én is képes vagyok agyfaszt kapni...
Annyit szeretnék elérni, hogy az arcball kamerámat az aktuális orientációjából egy adott másikba forgassam, szépen.

A szögek eulerben adottak, ezekböl csinálok két kvaterniót majd slerp. A baj csak az, hogy egyrészt kibaszott idióta pathokat ír le, másrészt elbassza az egész orientációt, mivel nincs gimbal lock és behozza a roll-t.

Valaki csinált már ilyet?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5448 hsz       Online status #194468   2013.06.02 21:57 GMT+1 óra  
Asylum - Törzstag | 5448 hsz       Online status #190751   2013.01.24 11:00 GMT+1 óra  
Kód:
typedef float vec2[2];
typedef float vec3[3];
typedef float vec4[4];

bool LineIntersectSegmentHomogeneous(
    vec3& out, const vec2& pt, const vec2& dir,
    const vec2& start, const vec2& end)
{
    vec4 m = { dir[0], start[0] - end[0], dir[1], start[1] - end[1] };
    vec4 adj = { m[3], -m[1], -m[2], m[0] };
    vec2 y = { start[0] - pt[0], start[1] - pt[1] };

    float det = m[0] * m[3] - m[1] * m[2];
    float t = adj[0] * y[0] + adj[1] * y[1];
    float u = adj[2] * y[0] + adj[3] * y[1];

    out[0] = pt[0] * det + t * dir[0];
    out[1] = pt[1] * det + t * dir[1];
    out[2] = det;

    return (((u < 0) == (det < 0)) && fabs(u) <= fabs(det));
}


Parancsolj. Nincs benne osztas.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 464 hsz       Online status #190745   2013.01.24 09:28 GMT+1 óra  
Easy kvesztsun:
szakasz es egyenes metszespontja. OSZTAS NELKUL.
Link is jo, ha ertelmes leirast ad.

   
Pretender - Törzstag | 2498 hsz       Online status #190352   2013.01.14 15:27 GMT+1 óra  
Igazából nyilván pointereket használok, szóval olyan 10.000 elem esetén is 4 bytes-os pointerrel számolva a tömb mérete 40.000 byte lesz, ami azért nem túl sok Nyilván nem órákat dolgozok rajta, mert most vizsgaidőszak van, nem igazán foglalkozok vele, csak előre gondolkozok, hogy aztán néhány óra alatt leimplementáljak egy hatékony tárolót.

   
versio - Tag | 659 hsz       Online status #190348   2013.01.14 15:13 GMT+1 óra  
ez a megoldas egyszeru, nem kell baszkodni vele orakat, es a leggyorsabb is, fregmentalodas nem fordul elo, esetleg kicsi lesz a tomb, de ezt meg mar multkor megbeszeltuk
   
Asylum - Törzstag | 5448 hsz       Online status #190346   2013.01.14 14:54 GMT+1 óra  
Nyilvan a tomb merete ekkor fix => fragmentalodni fog, ha meg defragmentalod az osszes kiadott indexet updatelni kell.

De most komolyan ilyen baromsaggal szorakozol? Kit erdekel hany orajel, mukodjon.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
versio - Tag | 659 hsz       Online status #190345   2013.01.14 14:45 GMT+1 óra  
Pretender:

tarolod egy tomben oket, aztan visszaadod a tomb indext , mint ID, igy a kereses ideje 1 orajel
ennel gyorsabb nem letezik
   
Pretender - Törzstag | 2498 hsz       Online status #190344   2013.01.14 13:12 GMT+1 óra  
Igazából nem hiszem, hogy túl gyakran változik, nagyjából arra kell, hogy az összes game objectet ebben a mapben tárolom, és törléskor / szerkesztőben kijelöléskor, stb. az indexe (neve) alapján el lehetne kérni. Szóval inkább a gyors keresés a fontos, mint a folyamatos hozzáadás / törlés.

   
Asylum - Törzstag | 5448 hsz       Online status #190341   2013.01.14 09:14 GMT+1 óra  
Ez a szofa nem tunik trivinek (marmint felepiteni).
Nemreg egy kollegaval osszemertunk harom implementacio (AVL fa, B fa, piros fekete fa (STL)). A B fa nyert,meghozza eleg nagy elonnyel.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
M4 - Tag | 187 hsz       Online status #190340   2013.01.14 08:38 GMT+1 óra  
(Nem kanapé )
Magyarul nem találtam:
http://en.wikipedia.org/wiki/Trie
Szóval a szó betűiből építed a fát, de ábrán jobban látszik.
Most nézem, van bináris fás változat is, azt írják az gyors.
Egyébként milyen gyakran változik az adat? Csak néha, vagy gyakran?

   
Pretender - Törzstag | 2498 hsz       Online status #190338   2013.01.14 07:04 GMT+1 óra  
Na igen, csak az ilyenkor nem tartozna bele a számolásba, hogy a legrosszabb esetben n db karaktert is össze kell hasonlítani, hogy a fában megtaláljuk a helyét?
"aaa...ab"
"aaa...ac" <--- beszúrandó
csak az n. karakter különbözik, viszont szeretnénk tudni, hogy a beszúrandó hol helyezkedik el a fában, tehát elindulunk ugye a gyökértől, és lépkedünk a megfelelő irányba. Ráadásul ha kiegyensúlyozott fát szeretnénk (AVL fa), hogy a magassága optimális legyen, akkor beszúráskor kiegyensúlyozatlannál válhat, amit korrigálni kell, ez is plusz néhány művelet.

@M4: a szofát nem ismerem, az mi az?

   
versio - Tag | 659 hsz       Online status #190313   2013.01.13 19:57 GMT+1 óra  
Pretender: ezer elemnel nem biztos hogy megeri, mivel belefer a cache-be, meg az l1-be is siman , aminek az eleresi ideje 1 orajel , tehat 10 ugras = 10 orajel

1000 adat befer az L1-be = 1 orajel * 10 ugras = 10 orajel
10000 adat befer az L2-be = 14 orajel * 14 ugras = 200 orajel
1000000 adat befer az L3-ba = 30 orajel *20 ugras = 600 orajel
>10000000 adat a memoriabol = 200 orajel * 24 ugras = 4800 orajel

a hash tablanal csak egy olvasasra van szukseg , a kulcs altalaban egyszeru par 10 orajel maximum, lathato hogy bizonyos helyzetekben akar ezer szeresere is gyorsul a kod
   
M4 - Tag | 187 hsz       Online status #190311   2013.01.13 19:44 GMT+1 óra  
Használhatsz szófát is, nem tudom milyen gyors.

   
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [21]