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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] > 3 < [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [28]
Elodin - Tag | 184 hsz       Online status #206027   2015.01.05 00:07 GMT+1 óra  
Legyen állítható, és ez a default
Vmilyen szinten úgyis a user dolga lesz egymáshoz illő animációkat gyártani, vagy leglább összeilleszteni vhogy őket.

   
Instalok - Tag | 619 hsz       Online status #206026   2015.01.04 23:03 GMT+1 óra  
Igen, valami ilyesmit tapasztaltam én is a Unity oldaláról. Lejátszási ideje viszont csak az AnimClipeknek van. Valahogy úgy lehetne megoldani talán, hogy mindegyik State megmondja magáról, hogy mennyi ideig fut - SimpleState esetén egyszerű, csak az AnimClip ideje, BlendTree esetén meg a sub-statek idejeinek valamilyen súlyozása.

Viszont kérdéses, hogy lehet-e általánosítani ezt az x%-os időben való elindulást: séta-futás-oldalazás váltáshoz jó lenne, kérdéses, hogy mire használnak még BlendTreeket.

   
Elodin - Tag | 184 hsz       Online status #206023   2015.01.04 20:57 GMT+1 óra  
Vmi olyasmi tűnik logikusnak, hogy mindkét animáció sebességét módosítod, hogy egyszeri lejátszásuk (súly1 * t1 + súly2*t2) időt vegyen igénybe.

Menet közben meg úgy indítanék, hogy ha a séta animáció az idő x%-ánál tart, akkor a futás onnan indulna szintén - persze ennek is csak akkor van értelme, ha alapból szinkronba van a séta és a futás, de más különben nem nagyon lehet mit csinálni.

De én is csak user oldalról láttam még ilyet, csak találgatok

   
Instalok - Tag | 619 hsz       Online status #206021   2015.01.04 19:52 GMT+1 óra  
Animációkezelésen dolgozok jelenleg, és egy kicsit elakadtam. A Unity-ben található rendszer eléggé megtetszett, így valami hasonlóval próbálkoztam én is. Egy meshhez tartozik egy Animator. Az Animator tartalmaz Layereket. A Layer tartalmaz State-eket, amiből 2 fajta van: SimpleState, BlendTree. A SimpleState egyetlen AnimClip-et tárol, és azt tudja lejátszani. A BlendTree pedig State-eket tárol, és azok között a 2 aktuálisat blendeli össze. Valami ilyesmi a felépítés, például:
Kód:
animator
{
    layer "baseLayer"
    {
        simple_state "idle"
        {
            loop = true
            speed = 1.5
            anim_clip "idle"
        }
        blend_state "walkBack"
        {
            simple_state "walkBackLeft"
            {
                loop = true
                anim_clip "walkBackLeft"
            }
            simple_state "walkBack"
            {
                loop = true
                anim_clip "walkBack"
            }
            simple_state "walkBackRight"
            {
                loop = true
                anim_clip "walkBackRight"
            }
        }
        blend_state "locomotion"
        {
            blend_state "walk"
            {
                simple_state "walkLeft"
                {
                    loop = true
                    anim_clip "walkLeft"
                }
                simple_state "walk"
                {
                    loop = true
                    anim_clip "walk"
                }
                simple_state "walkRight"
                {
                    loop = true
                    anim_clip "walkRight"
                }
            }
            blend_state "run"
            {
                simple_state "runLeft"
                {
                    loop = true
                    anim_clip "runLeft"
                }
                simple_state "run"
                {
                    loop = true
                    anim_clip "run"
                }
                simple_state "runRight"
                {
                    loop = true
                    anim_clip "runRight"
                }
            }
        }
    }
}

Alapvetően nincs gond, felépítettem a rendszert, egészen egyben van már, azonban a BlendTree-nél elakadtam picit. Főleg a következő probléma jutott eszembe:
Van egy séta előre animáció, ami mondjuk 3mp, meg van egy futás előre, ami 1,5mp. Amikor a kettő között 0.5 súllyal blendelek (azaz fele ez, fele az), akkor nem mehet teljes sebességgel mindkét state (legyen az SimpleState vagy BlendTree), mert 1,5mp-nél a futás már befejeződik, de a séta még csak akkor vált a másik lábra.

Szóval a kérdés igazából a szinkronizálás. Az is kérdéses, hogy amíg az egyik súlya 0.0 a másiké 1.0 (azaz csak egyetlen sub-state lejátszása van folyamatban), akkor ennek megváltozásakor honnan induljon a másik animáció. Például séta animáció éppen a jobb lábnál tart, amikor elkezdünk blendelni a futásba, ami a bal lábbal indít.


   
DieToBorn - Tag | 32 hsz       Online status #204986   2014.10.08 19:45 GMT+1 óra  
Sziasztok!

Időközbe ragaszkodtam ahhoz amit mondtatok, át írtam nagy részt az egészet és úgy működik most már ahogy kell neki Viszont olyan problémám van most hogy be van töltve 7 bitmap és be lassul tőle a progi.. PNG autókat töltök be 6db-ot meg a háttér is PNG . Kérdésem az lenne hogy tudtok valamit erre a problémára?

szerk:

traffic osztály:
http://pastebin.com/zThnW3eH

Paint:
http://pastebin.com/msQiPW64

A következő képpen van deklarálva:
Kód:
        private TRAFFIC traffic_car1,
                        traffic_car2,
                        traffic_car3,
                        traffic_car4,
                        traffic_car5,
                        traffic_car6;


Load-ba pedig így hozom létre:

Kód:
            traffic_car1 = new TRAFFIC();
            traffic_car1.color = a;
            traffic_car1.imagex = 40;
            traffic_car1.speed = 9;

            traffic_car2 = new TRAFFIC();
            traffic_car2.color = b;
            traffic_car2.imagex = 105;
            traffic_car2.speed = 11;

            traffic_car3 = new TRAFFIC();
            traffic_car3.color = c;
            traffic_car3.imagex = 160;
            traffic_car3.speed = 13;

            traffic_car4 = new TRAFFIC();
            traffic_car4.color = d;
            traffic_car4.imagex = 220;
            traffic_car4.imagey = 370;
            traffic_car4.speed = 9;

            traffic_car5 = new TRAFFIC();
            traffic_car5.color = ee;
            traffic_car5.imagex = 285;
            traffic_car5.imagey = 370;
            traffic_car5.speed = 12;

            traffic_car6 = new TRAFFIC();
            traffic_car6.color = f;
            traffic_car6.imagex = 345;
            traffic_car6.imagey = 370;
            traffic_car6.speed = 14;



Szerk.: Elnézést a dupla postért! Idő közbe rájöttem hogy a paintbe nem szerencsés állandón létrehozni imagelist-et meg betölteni a forrás fájlokat... Kezdek rá érezni a dolgokra

Ezt a hozzászólást DieToBorn módosította (2014.10.08 20:32 GMT+1 óra, ---)

   
DieToBorn - Tag | 32 hsz       Online status #204969   2014.10.07 14:29 GMT+1 óra  
Én azt hittem hogy ez csak a megjelenítést végzi és csak egyszer hozza létre...
Jó tudni :/
Load-ba próbáltam már de akkor meg be se tölti mert grafikus objektum és mindenképpen a paint kell neki...

szerk: e.graphics nem is jó akkor ott mert a load nem ezt kezeli mármint az nem paint event

szerk2: Form load-ba ha ezt beteszem:
Kód:
             this.DoubleBuffered = true;
            Graphics g = this.CreateGraphics();
            Level new_level = new Level(g);
            new_level.init();

akkor nem jeleníti meg :/

Ezt a hozzászólást DieToBorn módosította (2014.10.07 14:47 GMT+1 óra, ---)

   
Instalok - Tag | 619 hsz       Online status #204962   2014.10.07 07:53 GMT+1 óra  
De, pontosan úgy fogod tudni mozgatni. Annyi, hogy betöltéskor kell csak létrehoznod. Az alábbi kódrészlet:
Kód:
// paint event
this.DoubleBuffered = true;
Graphics g = e.Graphics;
Create_Map(g);

Ez tényleg minden egyes paint event esetén lefut? Ha igen, akkor azért nem tudod mozgatni. A pályát csak egyszer hozd létre, még betöltéskor. Gondolj bele: ha mindig újra és újra elkészíted, akkor az értékek "resetelődnek". Statikussal pedig azért működött, mert a statikus érték nem példányhoz tartozik, azaz mindegy, hogy mikor, hol és mennyit hoztál belőle létre.

   
DieToBorn - Tag | 32 hsz       Online status #204960   2014.10.07 07:03 GMT+1 óra  
Ha kiveszem hogy ne legyen statikus akkor meg nem fogom tudni mozgatni :/
pl.: Level a = new Level();
a.imagey +=1; így nem :/ Nem fog akkor mozogni..

   
Instalok - Tag | 619 hsz       Online status #204956   2014.10.06 21:42 GMT+1 óra  
Ehhez tudnod kellene, hogy mit jelent az, hogy valami statikus
Ez így ebben a formában sehogy sem fog működni. Tessék csak külön létrehozni az objektumokat, és azoknak az értékét állítani. A statikus pont azt jelenti, amit te nem szeretnél.

Konstruktívabban: a statikus nem példányhoz tartozik, azaz, ha van 10 példányod, mind a 10-hez ugyan az(ok) az érték(ek) fog(nak) tartozni.

   
Tunyu - Tag | 450 hsz       Online status #204954   2014.10.06 21:14 GMT+1 óra  
Nem mondanám hogy teljesen értem, de általában ilyen esetben egy for ciklussal ki tudod választani a kívánt objektumot.Azt mondják hogy minden objektumhoz tartozik egy ID amivel ki lehet választani, na én ezt nem szoktam használni, hanem a for ciklussal kiválasztom a tömbből a kívánt elemet.

   
DieToBorn - Tag | 32 hsz       Online status #204952   2014.10.06 20:45 GMT+1 óra  
Sziasztok!

Segítség kellene az alábbi problémámhoz:

van egy osztályom pl:
http://pastebin.com/QZ8uqN1f

és így jelenítem meg: (ez már a form-ba van)
http://pastebin.com/Yie0N8RR

alapvetően az osztályra tudok csak hivatkozni és nem pedig az objektumra mert statikus pl a kép x,y és oké hogy megoldom a mozgatását (timert hozok létre és abba pl így néz ki: Level.imagey = Level.imagey ++ de ha csinálok belőle 10et akkor mind a 10 ugyan úgy mozogni fog és nem csak az adott példány

Lövésem sincs hogy hogy lehetne megoldani :/ Mert ezzel a módszerrel alapvetően akármennyi objektumot létre tudok hozni de mivel az imagex és az imagey statikus így az objektum nevének azonosítójával nem tudom elérni pl: Level a = new Level() a.imagex = valami.. ezt így nem tudom.. És így gyakorlatilag nem tudom irányítani az objektumaimat :/

   
Instalok - Tag | 619 hsz       Online status #204734   2014.09.08 23:30 GMT+1 óra  
Az szép megoldás lenne. Én valami sokkal egyszerűbben törtem a fejem. Mégpedig megvizsgálom a kérdéses pozíció távolságát is az adott háromszögtől, ami, ha egy tűréshatáron belül van, akkor azt vegye számításba.

Emellett ki szeretném egészíteni még két dologgal, amelyeknek a közös pontja egy sugár. Mégpedig első körben azt szeretném, hogy ha a sugár * 2 < portal size, akkor arra ne mehessen. Azaz például egy vékony hídon ne akarjon átmenni egy széles tank. Ehhez valószínűleg le kell cserélnem az útkeresésben használt pontokat a háromszög középpontjairól a portalok középpontjaira, hogy meg tudjam vizsgálni, hogy az adott él kellően széles-e. Emellett már csak apróság lesz az, hogy a falaktól tartson egy sugárnyi távolságot. Így a navmesh akár tökéletesen illeszkedhet a falakhoz, mert a mozgó actor sugara határozná meg, hogy mennyivel menjen el mellette.

   
syam - Törzstag | 1491 hsz       Online status #204733   2014.09.08 23:18 GMT+1 óra  
Én a navmesh magassági problémájának megoldására azt látom, hogy a navmesh konvex poligonjaiból konvex testeket kellene készíteni. Ez pedig ugrásra, látás becslésére és egyebekre is felhasználható lenne.
alias aalberik
   
Instalok - Tag | 619 hsz       Online status #204730   2014.09.08 19:41 GMT+1 óra  
No azt hiszem eljutottam valamilyen változatig. Alapvetően működik, valószínűleg nem lett a legoptimálisabb, de egyelőre kielégítő teljesítményt nyújt. Ki kell még egészíteni, hogy az y koordinátával is foglalkozzak. Bővebben itt

Köszönöm a segítséget!

   
Instalok - Tag | 619 hsz       Online status #204722   2014.09.08 09:56 GMT+1 óra  
Remélhetőleg egy utolsó post tőlem ezzel kapcsolatban.

Útkereséskor ugyebár kell a start és goal háromszög, ezt valahogy pozíció alapján meg kell határozni. Tele van az internet point in triangle képletekkel, így még túl okosnak sem kell lenni (a baricentrikus megközelítést használom egyébként). A problémám a magassággal van. Egyrészt, ezek az algoritmusok nem igen foglalkoznak a magassággal. Így, ha mondjuk van egy híd, illetve az alatt is van bejárható terület, akkor kérdéses, hogy melyik háromszöget találja meg.

Ráadásul kicsit félek attól, hogy worst case a teljes navmesh minden háromszögére lefuttassam a point in triangle algoritmust, hogy megtaláljam a megfelelőket.

   
Instalok - Tag | 619 hsz       Online status #204720   2014.09.08 08:11 GMT+1 óra  
Ez tulajdonképpen ugyan azt használja, mint amit második megoldásként leírtam, csak eltárol egy indexet is. Nem tudom mennyivel kifizetődőbb, mint helyben összehasonlítani a 4 vertexet. Adjacency vizsgálatkor az összehasonlítása két 3D-s pontnak legfeljebb 12 float összehasonlításából áll:
Kód:
if ((n1v1 == n2v1 && n1v2 == n2v2) || (n1v1 == n2v2 && n1v2 == n2v1))

Ahol az n1v1 az egyik vizsgált node egyik vertexe. Hasonlóan a többi.

Minden esetre ezt is elmentem, jó ötlet, kellhet még máshova is - például, ha másik modellformátumot akarok használni. Köszi ismét!

   
syam - Törzstag | 1491 hsz       Online status #204717   2014.09.07 23:49 GMT+1 óra  
Szinte mindenre van vmilyen algoritmusom

http://stackoverflow.com/questions/14396788/how-can-i-generate-indices-from-vertex-list-in-linear-time

Nálam az std::set find parancsa néha bugzott (nem tudom, h a bemenő adat vagy esetleg a msvc stl bugija-e).
Mindenesetre több millió vertexre 1-2 mperc alatt lefutott 2 ghz-s gépen.
alias aalberik
   
Instalok - Tag | 619 hsz       Online status #204715   2014.09.07 21:56 GMT+1 óra  
Működött úgy is a dolog. Ahhoz használtam egy mapet és egy vectort.
Kód:
map<Vector3, int32>
vector<map<..>::const_iterator>

Egy új vertexnél megnéztem, hogy benne van-e a mapben, ha igen, akkor visszaadtam a mapben tárolt indexet, ha nem, akkor hozzáadtam először a maphez egy új elemet, majd a vektorban is eltároltam a map iterátorát. Így, ha kellett a pozíció, az index segítségével megindexeltem a vektort, ami megadta az iterátort, aminek meg elkértem a kulcsát. Kicsit nyakatekert lett, de működött.

A másik út pedig az, hogy egyetlen setem van:
Kód:
set<Vector3>

Új vertex felvételekor szintén megvizsgálom, hogy benne van-e, ha nincs, akkor hozzáadom, végül mindenképpen visszaadok erre a setre mutató iterátort. Ezt tárolom el háromszögenként pontok gyanánt. Ekkor viszont a linken látható algoritmus nem működik, marad a brute-force összehasonlítás, pozíciók alapján.

Harmadik megoldás pedig az lenne, hogy az elsőt használjam, csak valamilyen értelmes adatszerkezettel.

   
syam - Törzstag | 1491 hsz       Online status #204714   2014.09.07 20:34 GMT+1 óra  
Jaja brute force, az izgalmas része a szomszédos vertexek felismerése.
alias aalberik
   
Instalok - Tag | 619 hsz       Online status #204713   2014.09.07 20:23 GMT+1 óra  
Ahogy így gyorsan ránéztem, ez is csak annyit csinál. Végigmegy a háromszögeken, és a még meg nem vizsgált háromszögekkel összehasonlítja, hogy van-e közös oldaluk. Végül is előfordulhat, hogy nincs ennél jobb megoldás, jó eséllyel ezt úgy is csak egyszer kell megcsinálni. Köszi a segítséget!

szerk.:
No mondjuk, ha így akarja az ember csinálni, akkor a háromszögekből ki kell menteni a (unique) pontokat, ezeknek megfelelően csak indexeket tárolni a háromszögnél, gondolom erre utaltál, amikor az indexelt vertex buffert írtad. Ennek a 22. oldalán is erről van szó, ha jól értettem.

Ezt a hozzászólást Instalok módosította (2014.09.07 20:36 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #204712   2014.09.07 20:15 GMT+1 óra  
Indexelt vertextömb + ahhoz tartozó háromszögek kellenek.

http://lwjgl.org/forum/index.php?topic=2407.0;wap2 - innen a setConnectivity fgv ( a plane itt háromszöget jelent). - ezt azt az algoritmust soha sem akartam megérteni

A végeredmény az, hogy minden háromszögnek tudni fogod a 3 szomszédját. Ahol nincs szomszéd ott -1 lesz a háromszögindex.
alias aalberik
   
Instalok - Tag | 619 hsz       Online status #204711   2014.09.07 19:47 GMT+1 óra  
No még mindig leakadtam valamin. Kézzel megadni nem egy nagy feladat egy navmesht, de első körben egy modellből szeretném betölteni. Azon gondolkozok, hogy a kapcsolatokat hogy a leggyorsabb kiépíteni. Annyit kell ugye megállapítani, hogy melyik két háromszög a szomszédos, ami akkor igaz, ha van azonos oldaluk. Először azon gondolkoztam, hogy megnézem az eddigi háromszögeket, és megkeresem, hogy van-e olyan oldala (két vertexe), ami megegyezik az új háromszög bármely oldalával. Ez viszont egyre növekvő futásidejű lesz, és bizonyára lehet okosabban is csinálni.

Alapvetően inputnak csak egy háromszöglistám van, akár obj-ból, vagy bármi másból.

   
Instalok - Tag | 619 hsz       Online status #204708   2014.09.07 18:03 GMT+1 óra  
Ah, értem már! Köszi!

Nem, egyelőre azt akarom elérni, hogy manuálisan épített navmeshre szépen fusson egy útkereső, lehetőleg még gyorsan is. Szóval még nincs se recast, se detour, meg semmi fancy dolog.

   
syam - Törzstag | 1491 hsz       Online status #204707   2014.09.07 17:27 GMT+1 óra  
Én anno (2012. aug. 9 svn log szerint) megértettem és annyi maradt meg belőle, hogy nem véletlen a tölcsér elnevezés.
Vizsgálandó pontból elindulva a "portálokhoz" két szakaszt készítünk. Ez adja a bizonyos tölcsért, A bal oldali szakasz jobb oldalán van a jobb oldali szakasz bal oldalán pedig a bal.
Ahogy haladunk "előre" a portálokon a tölcsér egyre szűkül. Egyszer pedig elérünk egy olyan "portálhoz", ahol a tölcsér "kifordul" vagyis a bal szakasz bal oldalára kerül a jobb oldali szakasz vagy a jobb oldali szakasz jobb oldalára a bal.
Attól függően hogy melyik következik be a portál bal vagy jobb oldali pontjából lesz "sarok". Ezt a sarkot eltároljuk és innen indítjuk tovább az algoritmust amíg el nem jutunk e végpontba.

És igen, ezt egy A*-gal kiválasztott navmesh poligon-listára kell lefuttatni

Navmeshre a recastnavigation-t használod?
alias aalberik
   
Instalok - Tag | 619 hsz       Online status #204706   2014.09.07 16:13 GMT+1 óra  
Google első találata a simple stupid funnel algorithm. Kicsit nehezen tudtam úgy követni a kódot, ezért gyorsan átfirkantottam c++ra - fogalmam sincs, hogy fordul-e, Notepad++ powa .

Maga az algoritmus még nem jött át teljesen. Ha jól értem, a portalok lesznek a navmesh háromszögeinek azon oldalai, amelyek egy szomszédos háromszöggel közösek. A left-right vertexeket pedig a körüljárási irány határozza meg? Minden esetre ezeket a portalokat mondjuk egy A* útkeresővel találom meg, amit lefuttatok azon gráfra, amely a háromszögek középpontjaiból és azok közötti szomszédossági kapcsolatokból áll.

No, minden esetre ki kellene próbálni, az a biztos. A c++ változat itt:
Kód:
void funnel(const Vector2& _from, const Vector2& _to)
{
    static Portal* fromPortal = new Portal();
    static Portal* toPortal = new Portal();
    static std::vector<Portal*> portals; // input
    static std::vector<Vector2> points; // output
   
    // start from scratch
    portals.clear();
   
    // add start
    fromPortal->left = fromPortal->right = _from;
    portals.push_back(fromPortal);
   
    // add portals between adjacent nodes
    getPortalsFromNavmesh(_from, _to, portals);
   
    // add destination
    toPortal->left = toPortal->right = _to;
    portals.push_back(toPortal);
   
    // get smooth path
    stringPull(portals, points);
}

void stringPull(const std::vector<Portal*>& _portals, std::vector<Vector2>& _result)
{
    _result.clear();

    Vector2 portalApex = portals[0]->left;
    Vector2 portalLeft = portals[0]->left;
    Vector2 portalRight = portals[0]->right;
   
    uint32 apexIndex = 0;
    uint32 leftIndex = 0;
    uint32 rightIndex = 0;
   
    _result.push_back(portalApex);
   
    for (uint32 i = 1; i < _portals.size(); ++i)
    {
        const Vector2& left = portals[i]->left;
        const Vector2& right = portals[i]->right;
       
        // update right vertex
        if (triarea2(portalApex, portalRight, right) <= 0.0f)
        {
            if (Vector2::nearEqual(portalApex, portalRigt) || triarea2(portalApex, portalLeft, right) > 0.0f)
            {
                portalRight = right;
                rightIndex = i;
            }
            else
            {
                _result.push_back(portalLeft);
               
                portalApex = portalLeft;
                apexIndex = leftIndex;
               
                portalRight = portalApex;
                rightIndex = apexIndex;
               
                i = apexIndex;
                continue;
            }
        }
       
        // update left vertex
        if (triarea2(portalApex, portalLeft, left) >= 0.0f)
        {
            if (Vector2::nearEqual(portalApex, portalLeft) || triarea2(portalApex, portalRight, left) < 0.0f)
            {
                portalLeft = left;
                leftIndex = i;
            }
            else
            {
                _result.push_back(portalRight);
               
                portalApex = portalRight;
                apexIndex = rightIndex;
               
                portalLeft = portalApex;
                leftIndex = apexIndex;
               
                i = apexIndex;
                continue;
            }
        }
    }
   
    _result.push_back(portals[portals.size() - 1]->left);
}

struct Vector2
{
    float32 x;
    float32 y;
   
    // ctor, copy ctor, operators, ...
   
    static bool nearEqual(const Vector2& _a, const Vector2& _b);
    static Vector2 operator-(const Vector2& _a, const Vector2& _b);
};

struct Portal
{
    Vector2 left;
    Vector2 right;
};

float32 triarea2(const Vector2& _a, const Vector2& _b, const Vector2& _c)
{
    const Vector2 a(b - a);
    const Vector2 b(c - a);

    return (b.x * a.y - a.x * b.y);
}

   
Instalok - Tag | 619 hsz       Online status #204703   2014.09.07 14:23 GMT+1 óra  
Köszi, rákeresek, bizonyára tele van az internet vele. Elég népszerű ez a navmesh dolog, úgy vettem észre, talán nem is véletlenül.

   
syam - Törzstag | 1491 hsz       Online status #204702   2014.09.07 14:17 GMT+1 óra  
Funnel (tölcsér) algorithm a varázsszó ^^
alias aalberik
   
Instalok - Tag | 619 hsz       Online status #204701   2014.09.07 14:09 GMT+1 óra  
Adott egy navmesh, azaz adottak háromszögek illetve a közöttük lévő kapcsolatok. Alap esetben felépítem a gráfot például a háromszögek középpontját felhasználva (piros gülük). Ezen fut az egyszerű A* útkereső.

A kérdésem az lenne, hogy mi alapján egyszerűsítik az utat? Csak a középpontokat felhasználva a piros utat kapom meg, egyszerűsítés után pedig a zöldet. Nem igazán tudom erre a szakszót, így ötletem sincs, hogy igazából mire keressek.


   
Pretender - Törzstag | 2498 hsz       Online status #202025   2014.03.16 17:39 GMT+1 óra  
Inkább az a kérdéses, hogy az útvonalakat hogy célszerű egyszerűsíteni. Nyilván brute-force megoldást lehet írni, de az nem lesz túl hatékony. Nem is a mesh meghatározása a kérdéses, hanem azok "körbejárása". De egyelőre kikötöttem egy grid-based A* algoritmusnál. Úgyis van térfelosztás, egy max 100x100-as griden kell majd utat keresni, azt meg illik akadás-mentesen tennie.

   
ddbwo - Tag | 1654 hsz       Online status #202023   2014.03.16 16:45 GMT+1 óra  
A vertexekből konvex hull-t csinálsz, kicsit kinagyítod és a külseje lesz az útvonal. Ha csak ilyen körbejárható akadályok vannak, akkor nem annyira érdekes az útkeresés, mindenképpen közelebb jut a célhoz, beakadni nem fog.
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 #202014   2014.03.15 12:09 GMT+1 óra  
Azon gondolkoztam, hogy nem lehetne-e az útkeresést "megfordítani", azaz nem a bejárható területeket jelöljük ki, hanem azt, ahova nem lehet menni.

Csodálatos ábra:


Hirtelen ötletként jutott eszembe, hogy megnézem, hogy az adott pozíciótól a következő pozícióig keresztezne-e az utunk valamilyen bejárhatatlan részt. Ha igen, akkor kiszámolom a metszéspontokat, majd a kisebb kerületű rész lesz az út. (az ábrán kék)

Ez ugye viszont nem tökéletes, mert az út optimalizálható (az ábrán zöld). Amennyire én tudom, ezt navmesh esetén is valahogy meg kell tenni, szóval bizonyára léteznek rá algoritmusok. További problémát jelenthet még az, ha több ilyen tárgyat "keresztezek", de az igazából az út-optimalizálást bonyolítja csak, az alapelv ugyan az.

Ami viszont kevésbé tetszik, hogy ez kb. le is korlátoz 2D-re. Nem nagyon tudom elképzelni, hogy hogyan működhetne 3D-ben (ha egyáltalán 2D-ben lehetséges). Nem tudom... szerintetek? Érdemes elindulni ilyen irányban?

szerk.:
Aha, másnak is eszébe jutott már. Bár az implementáció nem tökéletes, mert ki lehet olyan esetet hozni, hogy a végén egy kis kerülővel megy, mivel azt csinálja, hogy a legközelebbi waypointot keresi meg, ami néha nem túl nyerő.

Ezt a hozzászólást Pretender módosította (2014.03.16 10:24 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #201951   2014.03.11 16:11 GMT+1 óra  
Próbálkozott már vki inverz kinematikával és tud esetleg szebb, de nem sokkal drágább megoldást a CCD-nél?
alias aalberik
   
Fisher007 - Tag | 94 hsz       Online status #199257   2013.11.19 12:22 GMT+1 óra  
Idézet
versio :
amugy halott technologia, felesleges bele az ido



Ezt miből gondolod?
   
ddbwo - Tag | 1654 hsz       Online status #199253   2013.11.19 11:24 GMT+1 óra  
Idézet
versio :
"Valaki foglalkozott már Oculus Rifttel?"

carmackot kerdezted ?

amugy halott technologia, felesleges bele az ido



Mennyire lehet nehéz?

renderscene();
swapbuffer(&left);
renderscene();
swapbuffer(&right);

A két scene közt a különbség max annyi, hogy a kameravektortól el kell tolni a renderkamerát balra, illetve jobbra a játékegységben megfelelő 2,5 cm-t. Magyarul szem távolságra. Tehát vsz felezi az FPS-t is.
---

Mikor vörös-cián képeket buheráltam crysis-ből oldalazós trükkel, akkor minden úgy nézett ki, mint valami karton doboz. De egyre több poly van, úgyhogy vsz előbb-utóbb bekerülhet a hétköznapi dolgok közé.
A játékosoknak viszont elég gond, ha felezi vmi az fps-t. Hánytató is lenne egy akadozó 3D-s fps.
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 #199252   2013.11.19 11:20 GMT+1 óra  
Tapasztalatokra lennék inkább kíváncsi, ha vannak :3
alias aalberik
   
versio - Tag | 673 hsz       Online status #199251   2013.11.19 11:09 GMT+1 óra  
"Valaki foglalkozott már Oculus Rifttel?"

carmackot kerdezted ?

amugy halott technologia, felesleges bele az ido
   
syam - Törzstag | 1491 hsz       Online status #199249   2013.11.19 10:39 GMT+1 óra  
Valaki foglalkozott már Oculus Rifttel?
alias aalberik
   
StrykerKKD - Tag | 30 hsz       Online status #198982   2013.11.08 14:46 GMT+1 óra  
Egyébként ha csak appot akarsz, akkor arra bőven jó egy HTML5-ős megoldás.
   
zeller - Törzstag | 489 hsz       Online status #198974   2013.11.08 11:35 GMT+1 óra  
Ezt most talaltam
http://kivy.org/
Borsinak kosz az SO linket.
Erdemes ranezni sztem

   
syam - Törzstag | 1491 hsz       Online status #198972   2013.11.08 11:08 GMT+1 óra  
Gui alatt azt értem amit a wiki is és ahogy nézem elég sok tutorial van, hogy kell sdllel "összetett" guit készíteni ill. a ceguit is össze lehet házasítani vele.
Szó mi szó, jó lehet az sdl "már önmagában" is :3
alias aalberik
   
glezmen - Törzstag | 381 hsz       Online status #198969   2013.11.08 10:14 GMT+1 óra  
Idézet
syam :
Az SDL tudomásom szerint nem tud guit. Jól tudom?



attol fugg mit ertesz GUI alatt. A GUI mozaikszo ugye 'grafikus felhasznalo feluletet' jelent, az SDL meg ad grafikat, szoval ilyen ertelemben nyilvan tudja.
Ha a GUI alatt elore elkeszitett widgeteket (gombok, textedit, stb) ertesz, akkor azt valoban nem tudja alapbol, de vannak ilyen kulso libek is hozza (bar en meg egyet sem probaltam).

Ha egyszeru GUI kell (gombok, tobb kepernyo, ilyesmi) akkor az SDL boven jo.
Ha bonyolult UI (menuk, faszerkezet, texteditorok, stb) akkor inkabb Qt, bar ahogy mondtam, ott nem tudom hogy mennyire teljes koru a tamogatasa mobil platformokon, illetve nullarol indulva azert kell egy kis ido mire az ember atlatja es megtanulja (onnantol viszont Qrva jo )
   
zeller - Törzstag | 489 hsz       Online status #198966   2013.11.08 06:46 GMT+1 óra  
Nem hagyomanyos ertelembe vett jatekot irnek, csak egy gui appot, igaz nem nativ kinezettel.
Lehet, hogy maradok az SDL-nel emiatt, a qt valoban tul nagy, es a sajat widgeteket ugyis meg kell rajzolni...

   
borsi - Tag | 180 hsz       Online status #198963   2013.11.07 22:52 GMT+1 óra  
Még néhány unity alternatíva: http://www.waveengine.net/ http://v-play.net/ http://stackoverflow.com/questions/17584717/2d-cross-platform-game-development-engines. Azért nem véltelen, hogy unity manapság talán a legnépszerűbb indie engine.

   
syam - Törzstag | 1491 hsz       Online status #198961   2013.11.07 22:29 GMT+1 óra  
Az SDL tudomásom szerint nem tud guit. Jól tudom?
alias aalberik
   
glezmen - Törzstag | 381 hsz       Online status #198960   2013.11.07 22:15 GMT+1 óra  
Idézet
zeller :
Azon gondolkoztam, hogy leszamitva a unityt, van-e olyan dolog, ami valoban write once run everywhere, legalabbis andorka, makk, paci, szifon negyszogben. Azaz a relevans platformokon.
A bongeszoben futo alkalmazasokat most elvetem, mert az kevesnek tunik.
Arra jutottam, hogy a c++ az egyetlen mindenhol tamogatott nyelv (ugye iosre is lehet kompilalni?)
Nade
van olyan GUI lib ami hasonlo kvalitasokkal bir?
Qt esetleg? 5.2-vel igerik mindenhova...
Valakinek tapasztalata van ilyen total multiplatform ideakkal?



Qt5 mar alakul, bar pont a heten neztem, azert meg nem teljes a mobilos funkcionalitasa.
Ami nekem tokeletesen bevalt, es szinte tokeletesen igaz ra a 'write once run everywhere' vagy legalabbis a 'write once build everywhere', az az SDL2.
Ugyanaz a kod fordult windowsra, Linuxra, OSX-re, Androidra, iPhone-ra (meg PSP-re, stb).
A specialis dolgok kezelesehez kell egy-ket ifdef (pl. filekezelesnel Android eseteben kell egy fuggvenyhivas ami megmondja hogy mi az SD kartya vagy a belso memorianak az app altal alapban hasznalhato path-a, desktopon ez nyilvan nincs, ott mas a platform logikaja), de ez a komplett projectben is csak kb. tucatnyi sor.
   
syam - Törzstag | 1491 hsz       Online status #198952   2013.11.07 18:12 GMT+1 óra  
A cuccom fut 4 platformon még ha nem is teljesen mature a támogatás mindenhol

Sajnos guit nem igen találtam ami mindenhol lenne - kivéve a qt, de az túl nagy nekem ill. amit használok fltk azt cross-platformnak hívják.
alias aalberik
   
zeller - Törzstag | 489 hsz       Online status #198944   2013.11.07 16:41 GMT+1 óra  
Jobb hijan.
Azon gondolkoztam, hogy leszamitva a unityt, van-e olyan dolog, ami valoban write once run everywhere, legalabbis andorka, makk, paci, szifon negyszogben. Azaz a relevans platformokon.
A bongeszoben futo alkalmazasokat most elvetem, mert az kevesnek tunik.

Arra jutottam, hogy a c++ az egyetlen mindenhol tamogatott nyelv (ugye iosre is lehet kompilalni?)
Nade
van olyan GUI lib ami hasonlo kvalitasokkal bir?
Qt esetleg? 5.2-vel igerik mindenhova...

Valakinek tapasztalata van ilyen total multiplatform ideakkal?
Vagy unity ftw?

   
Pretender - Törzstag | 2498 hsz       Online status #197970   2013.10.05 15:42 GMT+1 óra  
Shadow mapping #1:
- draw geometry into shadowmap
- draw geometry with shadow computation

Shadow mapping #2:
- draw geometry into shadowmap
- draw geometry
- use depth and create shadows
- use a postprocess pass to apply shadows

Problémáim:
#1: ezzel a módszerrel a shadow eredményen nem használható semmilyen postprocessing (pl. blur), cserébe geometriánként meghatározhatom, hogy melyikre hasson árnyék
#2: ez az előzőnek kb. az ellentéte: használható az eredményen postprocessing, cserébe ugye egybe van, így nem tudom meghatározni, hogy melyik geometriára hasson az árnyék

Ez csak azért érdekes, mert ha pl. van olyan alphablendes cuccom, amit pl. nem szeretnék, hogy beárnyékoljon, akkor az 1. tűnik jobb megoldásnak, annak viszont vannak hátrányai.

Esetleg egy shadow mapping #3:
- draw geometry into shadowmap
- draw geometry
- draw geometry again and compute shadows
- use a postprocess pass to apply shadows

Ez a kettőnek a keveréke, cserébe 3x van kirajzolva a jelenet (ha nem akarok MRT-t használni)

   
Pretender - Törzstag | 2498 hsz       Online status #197764   2013.09.30 08:37 GMT+1 óra  
Át fogom gondolni még egyszer ezt a deferredet. Most pl. úgy van, hogy lineáris depthé írom át a depthbuffer tartalmát (hogy ne kelljen külön textúrát feltöltenem). A transparent objecteket pedig úgy renderelem, hogy lekérem a depthet a textúrából, és ha az adott pixel depth > olvasott_depth akkor discard.
Ez ugye a hardwares depth test kiesése miatt lassabb. Ha meg külön targetbe töltöm, akkor azért lassabb az egész renderelés. A forwardnál meg ugye alapvetően nincsenek ilyen transparentes problémák. Arról nem is beszélve, hogy tetszőleges material használható, míg deferrednél trükközni kell.

Syam, esetleg pár szót tudnál az újabb dolgokról írni? Melyik érné meg, stb. Esetleg valami jó kis paper. Köszi!

   
ddbwo - Tag | 1654 hsz       Online status #197749   2013.09.29 21:57 GMT+1 óra  
Erről az a reklám jutott eszembe, hogy:
"megmutatom mit kell tennie a digitális átállás során, ha előfizetéssel rendelkezik".

xD
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
   
Frissebbek | Korábbi postok
[1] [2] > 3 < [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [28]