Chyba v úvaze je v tom, že předpokládáš, že ten objekt něco renderuje.
Logické rozdělení je to z pohledu toho, zda se mohou elementy ovlivňovat.
Bohuzel pro rychle vytvoreni modelu (meshe) je myslim nutna tato reprezentace (ikdyz sam se nerendruje, je rendrovan). Uzivaji se co nejefektivnejsi datove typy (tusim pole id bloku - primitivnich intu; overhead pri pouziti napr. Map[(Int,Int,Int),Int] by byl primo monstrozni). Je take treba si uvedomit narocnost voxeloveho sveta - std. dohlednost je IIRC 10, tzn. 20x20chunku = 400x16^2x256 bloku = ~26 milionu bloku (kazdy blok az 6 sten ruzne textury a osvetleni). To je nutne efektivne skladovat, jinak dojde pamet velmi rychle (zanedbal jsem napr. osvetleni, sky flag, tile entity a urcite dalsi veci).
Zkus si představit jednoduché lineární pole objektů (pańáců a pomerančů). Pak můžeš mět jakýsi strom, který určuje, kde se které větve mohou ovlivňovat. Sourozence můžeš paralelizovat (když si to čtu, tak to zní děsivě, ale popisuji spíše potenciál, protože v praxi by to byl spíš takovej keř). A v každém ticku se ti v tom stromu provedou výpočty a v kořeni ti vypadne seznam všech změn, které musíš provést na scéně. Až tady máš to místo, kde budeš renderovat. A kde můžeš perfektně optimalizovat (zničení chunku, a vygenerování už finálního se všemi elementy, renderování jen viditelné scény, atd). A díky tomu, že mám seznam všech změn, mohu zkusit paralelizovat i to renderování.
Na entitach si to celkem predstavit jde (je jich pouze par, v pripade MC tak do stovky v okruhu viditelnosti), ale v pripade bloku? Mit stromy i pro bloky, napr. pro kazdy blok lavy (blok vyskytujici se v "prirode", tj. muze byt ve velkem mnozstvi soucasti sveta), ktery muze zapalit horlave objekty ve svem okoli, bude vetev v tom stromu? To bysme se posunuli o rad, mozna o dva. V kazdem ticku se muze lava "rozlit" dale (zmen za tick u lavovych jezer muze byt tedy mnoho), opravdu si nedovedu predstavit, ze by generovani toho stromu trvalo kratsi dobu, nez neparalelni puvodni verze. Kdyz vidim, jake vykonostni problemy jsou v aktualnim MC obcas s tokem vody, lavy a prepocty osvetleni (kteremu ta tvorba stromu bude asi celkem blizko), tak mi prijde, ze tohle reseni nemuze fungovat (ale mozna to jen klame, fakt nevim).
V zaveru mi z toho tedy vyplyva, ze by musela zustat stavajici reprezentace (pouzivat strom pro meshovani sveta si myslim rozumne nepujde) a paralelne udrzovat strom ovlivnitelnosti. Pomoci nej paralelizovat tick a z vysledneho seznamu zmen paralelne zpracovat vsechny chunky zaraz (prikazy pro 1 chunk tedy budou sekvencni, coz nevadi, maloktere (?) pouzivane cpu ma vice nez 400 jader). Je otazka, zda rezie spjata s udrzovanim/generovanim stromu a rozdelovanim prace (seznam zmen) nevyjde hur, nez stary jednodussi pristup
(tyto zmeny se budou bezne provadet klidne nekolikrat do vteriny, pokud budou trvat dele nez jeden frame, tak se hra zacne "skubat"; anebo by se muselo zacit resit nejaky "shadow world" ala "shadow dom", to ale nevim, jestli by pametove fungovalo).
Jak by se to dalo dělat lépe? JS navrhoval Monády, ale (pravděpodobně díky nedostatku zkušeností) bych se bál aby mi z toho nevylezl podobnej nepřehlednej mrdník, jaký obhajuje gamer u svého mutable řešení.
Prijde mi, ze tema programovani her je velmi narocne - musi se zajistit velmi dobry vykon, pritom ale stabilni (aby nekolisalo FPS). U voxelovych her je vse jeste umocneno nepodporou enginu i GPU. Pritom zrovna ty voxelove hry jsou myslim primo idealni pro masivni paralelizaci (a tedy i pro FP?).
Omlouvam se za dlouhy post. Doufam, ze jsem nektere veci moc nezjednodusil nebo spatne nepochopil. Jen dodam, ze jsem napsal velmi jednoduche rendrovani voxeloveho sveta v jME a od te doby jsem zacal mit respekt k Minecraftu a jeho (ne)dobremu vykonu
.
422 Odpovědí
48943 Zhlédnutí