Köszi, van benne valami.

Mondjuk ez attól is függ, hogy mennyire adsz szabad kezet a kliensnek. Ha például az ubershader nem dynamic brancinges, hanem preprocessorral szétválasztott, akkor ugye sok különbözõ shadered lesz (egyébként pont ezt emelték ki az UE4-féle shader graph nagy hátrányának - boldog-boldogtalan nekiáll új shadereket gyártani, ezzel növelve a kombinációk számát).

Persze ez most jelen esetemben nem lesz igazán probléma, mert szerencsére eléggé korlátolt a projekt, de azért érdekel, hogy a nagyobb game enginek hogyan bírkoznak meg ezzel a feladattal (Unity, UE4 és társai).

Nem jelent problémát, mert felhasználás szempontjából a kombinációk száma viszonylag alacsony.
Gondolj bele, hogy mik a leggyakoribb taskok:
- kirajzolni valamit egy (háttérben über)shaderrel
- gbuffer kirajzolása
- additive blending
- depth write disable

Illetve blit mûveletek. Szóval ez csak elméletben tûnik soknak, a gyakorlatban minimális. Az ArchiCAD-ról tudok nyilatkozni, mert ott én írtam meg az absztrakt felületet erre (ami alá most már Metal-t rakunk be): 2D-ben van mondjuk 20 féle shader kombináció (20 pipeline), 3D-ben van kb. 7 féle shader (7 pipeline). Hozzávéve a color/depth/stencil írás/nem írásokat van mondjuk cakkumpakk 30-40 féle pipeline. Nem egy nagy szám.

Egyébként egy nem publikus projekt keretében átírtam az ArchiCAD-et PBR-re; ott sem volt lényegesen több (gbuffer és deferred lighting shader-t írtam pluszban).

https://www.dropbox.com/s/quac6ga1cx0kbtm/achasbugs.avi?dl=0

(szerk.: ha érdekel, akkor felrakom a ‘feature’ videót is; bár az is hasonló)

Köszi! Abszolút érthetõ egyébként, OGL és korábbi API-k esetén valószínûleg hasonlót csinál a háttérben, csak runtime, miközben éppen rajzolni akar az ember.

Nem jelent ez egyébként problémát? Gondolva a Unity-re vagy UE4-re, ahol megannyi shader közül lehet választani (és még újakat is lehet gyártani), meg procedurálisan generálni mesheket, a kombinációk száma gyorsan az egekbe szökhet.

Röviden: igen. Mivel az input layout szorosan kapcsolódik a vertex shader-hez. De ez ugyanígy van Metal-ban meg DX12-ben is.

Követve a Vulkan szemléletét a precompiled pipeline objectekkel, elõre meg kell mondani, hogy milyen layouttal rendelkezõ vertex bufferek lesznek felhasználva rajzoláshoz. Ami egy viszonylag erõs limitáció lehet, fõleg, ha némi szabadságot akar adni az ember a kliensnek olyan szempontból, hogy hogyan állítja össze a vertex buffert.

Megnézve például a Unity-ben a Mesh objectet, ott egyesével állítgathatunk be különféle vertex attribútumokat (pl. külön pozíció, uv1, normals, stb.). Ez azt jelenti, hogy a háttérben többféle kiosztású vertex buffer kerül létrehozásra.

Tehát (például Vulkanban) minden egyes shader + vertex layout kombinációhoz külön-külön pipeline objectet kell létrehozni? Ez egy idõ után elég sok lehet, fõleg, ha a kliens írhat saját "surface shadert" (olyasmi, mint UE4-ben a Material).

Továbbá, amikor egy új kirajzolandó objektum a jelenetbe kerül, ott meg lehet keresni a megfelelõ shader + vertex layout kombinációhoz tartozó pipeline-t (ha nincs, akkor csinálni egyet), de valahogy okosan kell tárolni, hogy melyik graphics pipeline objecten keresztül legyen kirajzolva. Ez mondjuk talán a kisebbik gond, de mindenképpen gondolni kell erre is.

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.