Informatika és tudomány

  • VO101Tom
    #50716
    Procedurális hangok BORZALMASAN sok erőforrást esznek. CloD-nál volt egy olyan bug, hogy a hang engine nem limitálta le az egy időben hallható hajtóművek számát, és a doppler effekt realtime számolása másodpercenként valami 60x futott le. Ez azt okozta, hogy nagy bombázókötelékben a teljes proci igény több mint a fele (!) a hang számolásra ment el. Jelenleg a legközelebbi nyolc hajtóművet lehet csak hallani, és a dopplert "csak" másodpercenként 10x csekkolja. Hallani nem lehet a különbséget (szkópon biztos ki lehet mérni, de hallásra nem mondja meg senki), viszont proci teljesítményen sokat nyertünk. Én óvatosan bánnék akármilyen generált, procedurális hanggal. Lejátszani egy hangfájlt, betölteni egy előre megrajzolt textúra fájlt, lefuttatni egy előre felvett animációt minden esetben sokkal kevesebb erőforrásba kerül, mint ezeket realtime számolni, szimulálni.

    A sérülésmodellen lehetne bonyolítani, de az qrva sok meló. Grafikailag ha azt akarod, hogy a belső részek látszódjanak, és a sérülések a textúra kis területein jelenjen csak meg, ahhoz fel kell szabdalni az egész gépet, lemodellezni és feltextúrázni minden egyes külső és belső darabot, kiépíteni a hierarchia rendszert, hogy az alkatrészek melyik mihez csatlakozik, mikor mi esik le, akkor ne maradjon fent semmi az ahhoz kapcsolódik. Átalakítani az FM-et, hogy a hiányzó alkatrészeket is vegye figyelembe. Talajjal ütközésnél, deformálódásnál is új 3D modelleket kell gyártani, ráadásul úgy megcsinálni, hogy az épből sérültté válás hihető legyen, az is nagyon nehéz. Fizikai szimulációt ilyen realtime programoknál erre nem tudsz használni, nagyon sok apró alkatrészt kellene kezelnie, ami tuti tele lenne hibával, glitcheléssel. A modern játékokban a fizikai modell úgy van megírva, hogy ha sok objektumot kell kezelnie, akkor nem telepszik rá teljesen a procira, hanem a saját oldalán egyszerűsít. Na akkor szokott beütni a szar :D Ez egyenként is annyi munka lenne, hogy szerintem ezt egy hobby projectnél nem fogják megcsinálni, vannak ennél sokkal fontosabb dolgok is.

    Falconban KTO-n nekem 170 fps van kabinon kívül, 120 fps kabin nézetben. Az új Észak Németország térképen van talajon 30 fps, de futó csukás után ott is 80-90 körül van (vcync-el stabil a 60). Ha az objektum mennyiséget leveszem menüben csúszkával, akkor talajon olyan 40-45-re megy fel. Múltkor az egyik régi Izraeli hadjáratot töltöttem be, 30 fps-fölé nem ment sehol, újraindítottam a hadjáratot, akkor hasított. Szóval az fps veszteség egy elég összetett dolog. A DirectX 9 egyik szűk keresztmetszete a processzor és videokártya közötti sávszélesség, ha sok objektumot kell megjelenítenie, akkor PC-től függetlenül lesz lassú, mert a dx engine egyszerűen nem tud többet. DX10 nagy előnye például a sebesség, ezért vonták meg a DX9 supportot a VR szemüvegektől is.

    Falconba jönnek majd új shaderek, már pletykálnak arról, hogy a 4.34-ben új víz lesz, és a hajók textúrái is javulnak, amikről már volt egy-két kép is. Ettől függetlenül nagyon drámai változásra én nem számítok, új grafikai engine-t szerintem senki nem ír alá, már a DirectX csere sem lenne egyszerű. PBR féle anyagok a gépigényt is brutálisan feltolnák (most BMS egy adott felületre egyetlen textúrát használ, a PBR ugyanarra a felületre minimum ötöt. Plusz a festés, stencilek, kosz és kopás layerei. Clod pl átlagosan 14 textúra mapot használ ugyanarra a repülőgép felületre (ebben benne vannak a sérülést festő textúrák is), a legtöbb mapon nem csak RGB hanem Alpha mapot is kihasználja (engine tudja, hogy az a grayscale channel nem áttetszőség lesz, hanem valami más). Qrva nagy lenne a gépigény, ha BMS-nél is hasonlót akarnának. Én jobban örülnék, ha a prociidőt a műszaki dolgok, fegyverek, EW, és hasonló cuccok kapnák.
    Utoljára szerkesztette: VO101Tom, 2019.02.18. 17:53:52