Ha az segít, akkor annó az egyetemen csináltam egy felülnézetes szimulációt, ahol az AI-nak ki kell kerülnie dolgokat, eloltania tüzeket és mindezt úgy megoldani, hogy adott számú tûzoltó van csak, de adott tûzhöz adott számú tûzoltó kell, hogy eloltsa (és nem kerülhet deadlockba).

https://www.dropbox.com/s/qary3g3y5zr88r2/MultiRobot.zip?dl=0

Régebbrõl van pár elmentett linkem, nem tudom, hogy ezek közül valamelyik jó lesz-e:
http://theory.stanford.edu/~amitp/GameProgramming/MapRepresentations.html
http://www.david-gouveia.com/portfolio/pathfinding-on-a-2d-polygonal-map/

Az ugráshoz és egyéb akciókhoz pedig meg lehetne azt csinálni, hogy flagek is társulnának a polygonokhoz. Vagy esetleg valamilyen triggerrel megoldani, hogy ugorjon.

Szerintem a probléma ugyan az, mint egy 3D játék esetében, szóval megpróbálhatsz úgy keresgélni, hátha úgy nagyobb sikerrel jársz. Sajnos személy szerint nekem nincs nagy tapasztalatom A.I.-al kapcsolatban.

szerk.:
Lehet ilyen linkelt navmesh jellegû dolgokkal is próbálkozni: https://forum.unity3d.com/threads/how-to-trigger-a-jump-on-an-offmesh-link.313628/
A linkelés pedig meg tudná mondani, hogy miként tud odajutni: teleportálás, ugrás, zuhanás, ilyesmi. Arra pedig már vannak megoldások, hogy megvizsgálja, hogy egy folyosón elférne-e, vagy sem, de sokkal egyszerûbb, ha eleve úgy készül el a navmesh, hogy ahol nem fér el, ott nincs járható terület.

Az alap, a kérdés inkább, hogy hogy építem fel a gráfot, amiben keresni akarok majd.
Próbálgattam keresni navmesh-es dolgokat, de ilyen use-case-re nem nagyon találtam :/ Arról nem is beszélve, hogy itt kéne tudnia ugrani az ai-nak, van ahol nem fér el, etc.

A* algoritmus.

2D-s oldalnézetes világ AI lekérdezésekhez való reprezentálásához tudtok valami jó alapot?

Olyasmikre lenne szükségem, mint hogy két pont között át tud e menni az AI, player meg közte van e másik szörny... esetleg ha próbál a player után menni, és át kell ugrani vmit hozzá, azt észrevegye, ilyesmik.

Elsõ ötlet vmi intervallum fa építés, de még nagyon nem tudom, mit kéne kihozni belõle.

FXAA elég béna, inkább ezt implementáld le (kódja fent van githubon):

http://www.iryoku.com/smaa/

https://research.activision.com/t5/Research-Papers/Filmic-SMAA-Sharp-Morphological-and-Temporal-Antialiasing/ba-p/10012720

Az én blogbejegyzésem róla:
http://darthasylum.blog.hu/2012/10/14/subpixel_morphological_anti-aliasing

Illetve kipróbálható exe + a shader + a keresõ textúrák:
https://www.dropbox.com/sh/q4299yistr2gapn/AABAHRsdpaB9e7dNIUypb3mQa?dl=0

Van egy FXAA, ami totál nem csinál semmit az object széleivel, ha az átlátszó háttére van renderelve - feltételezem nem detektálja élnek :/

Ez koncepcionálisan ilyen, vagy elvileg vmi javítható cucc?

Kösz a tippeket!

Elsõ körben próbálkozok majd png-vel/jpg-vel, VirtualDub-en összefûzve, aztán ha nem jön be, akkor nézem a CAviFile/FFmpeg-t.

De a lustaság dominál, a kép exportálás tûnik a legegyszerûbbnek

Egy png-s tömörítés valszeg kissebb összméretet produkál sok kis fájlal is, mint egy egy nagy tömörítetlen valami.

Miért baj, hogy sok a file, ha aztán videót csinálsz belõle?

Egyébként ja, ahhoz, hogy 60 FPS-el tudj rögzíteni, elég bika hardware kell.

Mert elsõkörben a minél gyorsabbi fájlba írás a cél...

1920*1080, 60 fps, 60 sec pl... nem, nem akarok képeket csinálni belõle
Mondjuk úgyis lassítani kell, mert real time írni se tudnék... viszont képek generálása akkor sem tûnik túl jó megoldásnak, túl sok fájl lenne.

Idézet

---

Elodin :
A hatalmas méretek miatt nem képfájlba menteném a képeket, hanem csak egy nagy binaryba az egészet

---

És az miért jó neked? Ha képfájlba mentenél, az legalább tud tömöríteni rajta, akár veszteségmentesen is (pl. png). "Kizártnak" tartom, hogy jobb tömörítõ algoritmust írsz magadnak.

Ha jól emlékszem akkor én ebbõl indultam ki és szabtam át:
CAviFile
Be lehet állítani neki codecet (pl XVid; persze ezt telepíteni kell elõtte és konfigolni) és rögtön tömörítve menti. Viszont nálunk ez a folyamat erõsen belassítja renderelést, pl 1-2 fps ha jól emlékszem; de ahol mi használjuk ott ez nem gond, nem tudom nálad mi a helyzet.

De az avi felett kezd eljárni az idõ... lehetne egy próbát tenni az FFmpeg-el:
http://stackoverflow.com/questions/2401764/can-ffmpeg-be-used-as-a-library-instead-of-a-standalone-program
(ezt én még csak command line toolként használtam konvertálásra, szóval sokat nem tudok róla).
de lehet ez sem menne real-time.

esetleg tömörített képet (png, jpg) nem tudsz kimenteni és utána összefûzni? egyáltalán milyen hosszról, felbontásrül, fps-rõl van szó?

A hatalmas méretek miatt nem képfájlba menteném a képeket, hanem csak egy nagy binaryba az egészet, nem tudom, hogy van e olyan program, ami azzal tud dolgozni :/ Vagy vmi c++ lib legalább, amivel könnyû videot exportálni.

Sõt a VirtualDub tud képszekvenciát megnyitni, nem is kell AE hozzá.
http://www.virtualdub.org/blog/pivot/entry.php?id=34

After Effects-el simán videóvá tudod illeszteni, aztán VirtualDub + XVid plug-innel egy 4-es tömörítésen már kapsz is belõle egy egészen kis helyet foglaló videót (full HD videó, 1 perc, kiváló minõség, 40 MB).

Beépített video készítésre tudtok vmi jót?

Ha csak kidobom egy fájlba minden frame végén a frame buffert, van vmi program / lib, amivel abból viszlag egyszerûen tudok normális méretû videot csinálni?

Akad: https://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf

Idézet

---

Asylum :
Ez most átment ilyen reklámtopicba? Akkor én is reklámozok:



GTAO egy 12.9'' -os iPad Pro-n.

---

Van ennek olyan változata is, ahol a színeket szórja árnyék helyett, hogy ne legyen olyan steril az összkép? Kis ambient fény maszatolás a tárgyakról, mert a színek nagyon elkülönülnek és nem is látszik, hogy történik ott valami.

Idézet

---

Matzi :
Nyiss neki egy projektet, az arra van kitalálva.

---

Projektet nem akartam nyitni neki, mert ez egy elég szûk téma. Se neve se semmilye nincs, lassan be is lesz fejezve. Másnak nem adom oda, én szinte nem is fogom használni. Csak pár dologra voltam kíváncsi a témában, azt már ki is aknáztam azt hiszem. Még valamikor lesz egy szépített, gyorsabb változata és annyi. A 10. demora a proto kész is lesz.

sztem rakj az árnyékra valami blurt

Nyiss neki egy projektet, az arra van kitalálva.

Hát vártam a bugok jelentését, vagy tippeket. Lévén, hogy programozom az engine-t

Az nem a buktatók kitárgyalása, hogy fél naponként feltöltesz egy új változatot, és kiírod, hogy javítottál benne valamit, mint valami blogon.

Az elsõ komment szerint az engine fejlesztés buktatóit lehet itt kitárgyalni. Tehát mik a GTAO buktatói? na meg az mi az? Most hallom elõször. Mi a lényege és mit csinál hogyan tömören?

ui.:

gta online és Ground Truth Ambient Occlusion amit kilehet hozni belõle, de erõsen javallott a gta

Ez most átment ilyen reklámtopicba? Akkor én is reklámozok:



GTAO egy 12.9'' -os iPad Pro-n.

Hibákat megtaláltam.
Most a falbaakadással kell még valamit kezdeni, mert elég csúnya tud lenni.
https://www.dropbox.com/s/dv1me0n02pj0bg4/cut9.zip?dl=0

WASD QE shift Esc F1

köszi, kipróbáltam még nagy mapon is kíváncsiságból, és támadtak bugok. lépcsõzés nem megy gyakran és néha kidobja a pályáról valami...

A map az a dm_bwo_refuge hl2dm-bõl konvertálva
https://www.dropbox.com/s/o6siko750up3u0p/cutExtra.zip?dl=0

u.i.: F1-et kell nyomni közelihez

Állati jól megy.

Változtattam a méreten, eddig véletlen kétszeres volt, ezért gyorsabb is lett az egész.
Kamerán változtattam, van lépcsõzés, ugrás és beleírtam a "talaj" figyelését.
https://www.dropbox.com/s/5digjmsiqj8o67a/cut8.zip?dl=0

Kíváncsi vagyok, ez mennyire bejövõs a másikhoz képest. (Abban a lejtõ bünti volt).

Azok a fránya élek még vissza vannak.

WASD, QE, SPACE, ESC

Javított változat. Nincs már skate és simábban mozog.
https://www.dropbox.com/s/0bbwfk6howijjlo/cut7.zip?dl=0

edge-ekkel és több síkkal vannak még turpisságot. És ugrás, lépcsõzés kell még.

Jó lesz ez, csak még bugtalanítani kell. Na meg folyamatosan javítom a hierarchiát (már ha van rá idõm). Az élek sarkok problémásak még. Ezeken is próbálkozok még, jönnek az ötletek, csak még nem tiszta a dolog h miért is nem megy egy-egy megoldás, de az is meglesz gondolom...
https://www.dropbox.com/s/i0tym2ke2mza8dj/cut6.zip?dl=0

nyilak vagy wasd, mindkettõ mást csinál.
shift sprint
esc vagy f4
space

Ami furcsa bug megjelent, hogy most a lejtõkön skate-el, amit gondolom nem kéne neki annyira gyorsan.
---

u.i.:

Sikerült eltüntetni a skate bugot.

Akkor elmondom mégegyszer: mozgatást nem csinálunk fizikával (AABB vagy kapszula vagy bármi). Az enginekben ezt character controller néven fogod megtalálni és többnyire azt csinálják, amit én is leimplementáltam.

Oké, még a szûrést kell rendeznem és a lépcsõzést, aztán szépíteni. Túl sok változás nem látszik, de van benne elég, simábban megy. Már a polygon fillt is megérdemli.
https://www.dropbox.com/s/7gnz7r88bc8dadp/cut4.zip?dl=0

Ha valakinek van tippje mit miért csinál, nyugodtan szólhat. Bár kb van elképzelésem, a szûrés sorrendjein kell igazítani, hogy ne veszekedjen önmagával.

Pedig pont fizikával kombináltam a dolgot, amúgy nem fizika lenne, ez egy bevált módszer.(azt hiszem) ami készül.

Valamit az élekkel elírhattam. hogyan is kell megkapni az élek síkját, ha élen jár?

ebbõl kéne kitalálni:



Tudom melyik sík vágta, megvan a szakasz is és az eredeti poly amibõl vágtam.

itt az aabb-nél két vektor van. de melyik az? a két edge amibõl a normál lesz, vagy az mi az?

Nem, az edge amibõl a sík lesz.

Szerintem itt egy alapvetõ hibába estél bele: karaktermozgást NEM csinálunk fizika engine-el.
A PBR példaprogimban van rendes ütközésdetektálás:

https://github.com/asylum2010/Asylum_Tutorials/blob/master/ShaderTutors/common/fpscamera.cpp

Ez van a legközelebb ahhoz, amit akarok:
https://www.dropbox.com/s/l5efyd203p7fl9m/cut3.zip?dl=0
nyilak, space

Még bugos, de majdnem kész proto. letapad, kiesik, belassul, begyorsul.

A sutherland-hogman-t kitaláltam magamtól, (ami nem volt nehéz, mivel benne és kint-nél megy a vágás, ez nem egy nagy eresztés),ami a prototípusbann is szépen megy.

Most oda értem, ahol a múltkor is megragadtam. A polygon síkjára rátolom az aabb-t, ezután úgy kéne csúsznia a síkon, ahogy az fpsekben szokott lenni. Döbbenetes módon ez a csúszósík (sliding plane) nevet viseli, ahogy megtudtam.

Szóval van egy mozgás vektora az aabb-nek, és van egy maradék távolság, amit még mozogna, ha nincs ott fal. Ezt a vektort rávetítem a pont síkjára. próbáltam local, global, meg mindenhogy variáltam, de a pálya szélén a polyk egyszerûen nem adják meg a megfelelõ új vektort, viszont a tetejérõl, ami kint van a mappon, szépen csúszik. meg a map közepén a bütykön. Próbáltam megfordítani a sík normálját, de egyszerûen nem hajlandó felcsúszni rá.

Poligonvágáshoz Sutherland-Hodgman algoritmus.

Csúsztatás alatt nem tudom mit értesz; amíg a motorban nincs súrlódás, addig kb. minden csúszik megállás nélkül.

Pontosíts a kérdésen.

Esetleg ezt lehet még érdemes megnézni.

Jó progi, a kód kommentjeit vicces olvasni, de nekem leginkább az a rész kéne, hogy mégis mi az a síkon csúsztatás. Rávetítem a mozgásvektort a síkra, vagy mit csinálok? Most hirtelen ez jutott eszembe.

ui: Jó, látom. Megvan.

Atyaég, még megvan az a régi írásom, nem mondanám, hogy most vállalnám, de anno ez volt az elsõ kódom, ami kb. mûködött.
Nekem most egy hegyére állított kapszula a karakter kontroller jött be, kis elmozdulásonként nézi, hogy belelóg-e egy 3szögbe, akkor megpróbálja kitolni onnan. Elõnye, hogy a háromszög-kapszula ütköztetés elég szimpla kód - szakasz+háromszög távolsága. De lehet azzal is szórakozni persze, mire megy. Igazából emiatt nincs is sokféle tuti kód a neten a témában.

Köszi, elég vaskosnak tûnik. Átnézem.

Én ezt az egy értelmes oldalt találtam a témával kapcsolatban.Van forráskód is.
http://superminimum.atw.hu/colldet/colldet.htm

Én is ebbõl dolgoztam,de aztán meguntam és inkább Bullet physicsre váltottam.

Csináltam egy jobb tesztet, persze messze nem az, amit akarok, de a hibák elõbukkannak..
https://www.dropbox.com/s/e1il5208nxv99tf/cut2.zip?dl=0

pl beakad néha a sarka a falba. elvileg minden perfect, de mégis beakad. Lehet, hogy a mozgatás miatt, ami most csak egy pattogó labda mozgása, de talán precízió miatt, mert float minden szám. De a számok is nagyok, itt 150 a jelenet széle.
Na azt ki lehet találni, hogy mivel vetít, ennek semmiképpen sem szabadna beakadni, bármekkora a sebessége és bármilyen irányban éri a polyk sarkait, éleit, síkjait a box.

Na de a felületeken hogyan kell elcsúsztatni, azt még nem tudom.

c++ topicba feltettem egy kérdést (mivel c++ban van, de közbe rájöttem, hogy ide illett volna), miszerint aabb polygonba vágásához és válaszhoz kéne anyag. Na a poly vágás részét kitaláltam, megcsináltam, a max táv is megvan, de még kéne az is, hogy ezt hogyan reagálja le az aabb objektum. Rövidnek hangzik, csakhogy még a síkon is el kell csúsztatni, ha már rajta van, különben odatapad a gravitáció miatt és ennyi a mozgásnak.
Tehát még mindig kéne a válasz reakció hozzá, ha valaki tud anyagot vagy tudja milyen néven keressem meg...

u.i.: példa program: https://www.dropbox.com/s/ma2mlglkdrv5olg/cut.zip?dl=0
nyilak mozgatja az irányt, f4 kilép.

Ez, és minden hasonló matematikai megoldás túl szabályos határokhoz vezet.
Szerintem turidoo tippje állhat a legközelebb a valósághoz. Fõleg, hogy végülis ez is valami hasonló lehet.

Egyébként elég durva rendszerük van ahogy nézem Ha lesz idõm, csekkolom az editorukat, hátha akkor okosabb leszek vmivel.

Nekem is az a tippem, mint syam-nak:



Az alpha lehet akár alpha test is.

Eléggé hasonlónak tûnik, de a megoldás, amit használ, egyáltalán nem tûnik effektívnek. Esetemben annyira nem is indokolt, mert nekem nem kell megjegyezni az egész világra az értéket.

Mindenesetre én egyelõre jegeltem ( ) a problémát, majd visszatérek rá, ha hirtelen megvilágosodom (vagy hirtelen muszáj lesz :/ ).

lehet semmi köze hozzá, de engem emlékeztet erre a jégolvasztós effektre:
snowball-earths-melting-effect
dynamically-melting-snow

Próbálkoztam a normálokkal, önmagukban nem vezettek eredményre.

Lévén hogy nekem több target-em is lehet (divinitybe csak a kamera és a kijelölt hõs között van az effekt), egyik megvalósítási próbálkozásom, hogy az adott karakterek elé/felé renderelek egy horizontálisan mindig kamera felé forduló eltorzított ellipszoidot egy maszk textúrába a depth adatokkal. Utána mindent, ami a mentett depth és a kamera közé esne, azt dobom.
Itt ugye probléma volt a túl szabályos szél - egyszerûen ocsmányul néz ki.

Utána elsõ lépésben elfelejtettem, hogy több targetem is lehet, és próbáltam jobban a divinity szerûséget reprodukálni. Szerintem az alapja az egésznek a view pozíció és a target-et összekötõ egyenestõl való távolság - de ezzel megint az a baj, hogy túl sima a szél.

Majdnem biztos vagyok benne mostmár én is, hogy valami textúra van a dologban, de akkor sem tiszta, hogy hogy.

"model uv-ját használva rá van nyomva egy textúra" - ez megmagyarázná, hogy miért változik a mintázat, ahogy megyek egy konkrét objektum mentén anélkül, hogy a kamera vagy a karakter vagy a fal egymáshoz képesti helyzete nagyon változna.

Még nem teljesen tiszta, hogy hogy befolyásolja a clip-elést a textúra (sztem egy bizonyos radiuson belül pl. mindenképp clipelés van), meg hogy milyen textúrát érdemes használni, de vmi ilyesmivel fogok próbálkozni, köszi a segítséget