Apró lépésekben haladok az autó versenyzős játék projekttel. Jelenleg modelleket finomítgatok. De mielőtt erről szó esne részletesen, lássuk, mi is történt pár nappal ezelőtt.
Az utóbbi napokban felmértem a készülékem teljesítményét. Futtattam néhány benchmarkot, feltelepítettem a Sky Castle 2 látvány demót. Gyönyörűen néz ki és FullHD felbontás mellett 50-60 FPS-t produkál. De mi a helyzet az én projektemmel? Teljesítmény terén komoly gondok vannak már most és még egy kicsit sem hasonlít egy játékra. Először is, a korábbi angol nyelvű bejegyzésemben említett egyedi kerék fizika kicsit sem jött be. A Unity Car Tutorial alternatív fizikai modelljéből vettem, nagyon elégedett voltam magával a fizikával, azonban kicsit későn, de rájöttem, a teljesítménye csapnivaló! 5-6 autónál már erős FPS zuhanás kezdődött és 10-12 autónál már konkrétan szaggatott, 15-20 FPS-t produkált a Nexusom. Mivel a programkódban nem találtam még olyan részt, amit egyszerűsíteni lehetne a fizika romlása nélkül, úgy döntöttem, áttérek a beépített kerék fizikai modellre.
Mint korábbi angol bejegyzésemben említettem, a konfigurálhatósága nem tetszik. Sok próbálkozás után sem tudtam közel sem olyan jó beállítást találni, mint az egyedi megoldásnál. Viszont a teljesítménye lenyűgöző, simán 30*4 kerékkel 60 FPS, és még növelhettem is. Még 90 autónál is tűrhető volt a sebesség, kb 30-40 FPS. Persze, ez ne tévesszen meg senkit, sok minden más nem volt képernyőn, sok extra dolgok nem kellett számolnia, és nem autó modellekkel, hanem téglatestekkel szemléltettem az autókat. De mi a helyzet, ha modellekről van szó? Nos... nos, az a helyzet, hogy rögtön úgy álltam neki, hogy fizikát levettem róluk és csak statikus modellként raktam le az M23D utánzataimat. Írtam egy pici scriptet, amivel egy gomb nyomásra / érintésre le lehet tenni a modelleket egy adott területen belülre... huhh... kevés érintés kellett, hogy a dicsőséges 60 FPS megfeleződjön. Újabb zsákutca... vagy mégsem?
Igazából sejtem az okokat és dolgozom rajta. Először is, a modellem valamiért magas draw call szám. Legalább is mobil eszköz számára az. Jelenleg 17(!)+ drawcall egy autó, ez nagyon sok! Tudom az okát, egy-két ostoba megoldás, skinned mesh használata a model adott alkatrészén, normális, statikus mesh más részen, több anyag használata, stb... És nem a modell polygon száma okozhatja a teljesítmény romlást. Egy gyors bizonyítás, a Nexusom GPU használata csökkent, ahogy raktam le a sok autó modellt. CPU persze dolgozott a sok draw call miatt. (Erre a draw call kifejezésre jó lenne egy jó magyar definíció, de egyszerűen(?) fogalmazva:
A videokártyának ki kell rajzolnia az objektumokat. Ezt a CPU parancsolja meg neki, de egy ilyen hívás a GPU-tól sok időbe is kerülhet. (Tehát a GPU kéri a CPU-tól a parancsot) Ha túl sok hívásról van szó, akkor egyszerűen a CPU nem tudja időben továbbítani a hívást a GPU-nak, A GPU pedig várakozni kényszerül. Természetesen ilyenkor már csökken a teljesítmény. A hívások száma csökkenthető objektumok kombinálásával (amennyiben azonos anyagot használnak közös textúrákkal). Ekkor hiába van erős videokártyánk, a CPU lassúsága miatt belassul a program. Mobil eszközöknél a hívások számának alacsonyan tartása rengeteget számít a kisebb CPU teljesítmény miatt! Még egyszerűbben fogalmazva: a festőnek (GPU) minél kevesebbet kell mártogatnia az ecsetét annál jobb (kevesebb processzor idő megy el). Viszont néha hátrány, ha egy hívással nagyon nagy dolgot kell rajzolnia (összetett shader, magas polygon szám).
Visszatérve a csodás kis 70-es éveket idéző autó csodánkra... 17 hívás... rengeteg. A Unity képes a hívásokat kötegelni. Azonos anyagú, statikus objektumokat képes statikus kötegeléssel egyetlen hívással kirajzolni. Azonban ez csak a fizetős, Pro verzióban érhető el, amivel jelenleg nem rendelkezem. Dinamikus kötegelés van, ami inkább mozgó dolgokhoz jó, de valahogy máshogy működik, mint a statikus. Lényeg, ezzel rendelkezem, bár nem olyan hatékony, de jó, hogy van. Apró, nem túl bonyolult számítás után megállapítható, hogy az az eléggé magas, 17-es szám csökkenthető egészen 2-re! Elméletben... gyakorlatban nem. Gyakorlatban nem, mert az autóm nem 2, hanem valószínűleg 3, vagy 4 anyagot fog tartalmazni (karosszéria+felfüggesztés+egyéb apróságok (egy anyag), kerekek, üveg és még valami?). Jó hír, hogy a kerekek, bár 4 külön, önálló mesh, a dinamikus kötegelés által csak 1 lesz. Azért apró polygon szám csökkentést is végeztem a modellen, nem tudom, mennyi lesz a végleges, ha átmegy a teszten, akkor a többinek is akár nekiállhatok. De előbb lehet, fizikázni fogok és programozni.
Mára ennyit a blogomra, lehet, megírom röviden-tömören ezt angolul is majd. A rajzolási hívás definiálás pedig... remélem, nem írtam nagy hülyeséget! :P
Wednesday, 15 January 2014
Haladás, fejlődés, teljesítménybeli javulás
Labels:
Android
,
autós játék
,
CPU
,
draw call
,
Google
,
GPU
,
játékfejlesztés
,
M23D
,
magyar játékfejlesztés
,
McLaren M23
,
nexus 7
,
optimalizálás
,
rajzolási hívás
,
unity3d
,
wheel collider
Subscribe to:
Post Comments
(
Atom
)
No comments :
Post a Comment