update/render ciklus u grafičkim aplikacijama

[Geomaster]

Do sada sam u grafičkim aplikacijama (konkretno, 2D i 3D igrama) unutar game loop-a prvo apdejtovao svet a zatim renderovao na ekran. Kada sam u sve to uveo PhysX, za to sam pustio poseban thread koji je na CPU-u simulirao fiziku dok je GPU renderovao trenutni frejm, pa sam rezultate te simulacije koristio u sledećem frejmu (zbog temporalne koherencije i iole pristojnog FPS-a to ne pravi nikakav vidljiv problem). Moje pitanje je da li je ovo najbolji način, ili je možda pametnije držati dva thread-a: jedan koji apdejtuje i drugi koji renderuje, i koliko često oni treba da rade? Kako u sve to da ubacim fiziku (sada koristim Bullet ali cenim da je sličan pristup)? Kako je to rešeno u velikim naslovima?

[water wizard]

pa i fiziku radi grafička.. trebao bi malo da obnoviš konfiguraciju za takve za*****cije..

[Geomaster]

water wizard kaže:

pa i fiziku radi grafička.. trebao bi malo da obnoviš konfiguraciju za takve za*****cije..

Zašto mora da radi grafička? To je samo mogućnost. A ovo za konfu ne razumem.

[water wizard]

pa pitaš kako je to rešeno u velikim naslovima.. a da obnoviš mašinu da bi brže išlo...

[Geomaster]

water wizard kaže:

pa pitaš kako je to rešeno u velikim naslovima.. a da obnoviš mašinu da bi brže išlo...

Da, okej, ali konkretno sam mislio kako je taj update/render ciklus rešen, ne samo fizika. A uspevao sam na ovoj mašini da poteram i neke naslove koji su poprilično novi i zahtevaju dosta jaču konfu i tu bottleneck nije bio fizika već grafika. Svejedno ne bih ja imao nešto preterano za*ebanu fiziku za simulaciju, ali me konkretno interesuje kakve su prednosti i mane ovog 'rednog' pristupa (update pa render) nasuprot konkurentnom (da update i render rade kao dva nezavisna thread-a) i kako se to inače realizuje.

[Andross]

Uglavnom svaki engine koji koristi multithreading render radi u odvojenom threadu od ostatka aplikacije, eventualno ima jos jedan za fiziku. Sada kako tacno radi under the hood ne bih znao da ti objasnim jer se nisam bavio time, ali recimo NeoAxis koji je jos uvek singlethreaded radi update 30 (ili 60 nisam siguran) puta u sekundi a izmedju stancuje slike na gpu. Belphegor bi trebao da zna vise na ovu temu, ali kao i uvek google is your friend - sigurno ima bar jedan clanak na tu temu.

[Geomaster]

Guglao sam pre neki dan ali baš nisam našao ništa konkretno, uglavnom samo pitanja na GameDev.net i StackOverflow koja mi nisu dala definitivan odgovor. Ne vidim recimo zašto bi se na GPU slalo češće od 60Hz jer monitor ionako to ne bi mogao da prikaže, a opet i fizika tu igra ulogu jer ona ne može samo da se stepuje za neko Δt već za neki broj fiksiranih koraka. S obzirom na to da je game loop najbitniji deo svake igre želim da se malo bolje pozabavim ovim da ne bih imao problema u budućnosti. I hvala na odgovorima, ljudi.

[Andross]

Jeste al opet tu je i frustrum, okluzija i jos kojekakve stvari koje ipak CPU radi i zahvalnije su u odvojenom threadu po pitanju performansi, nije samo ceranje poligona na karticu

[Belphegor]

Andross kaže:

Belphegor bi trebao da zna vise na ovu temu...

Belphegor je jos uvek duduk. Ali se polako ucim.

Geomaster kaže:

Do sada sam u grafičkim aplikacijama (konkretno, 2D i 3D igrama) unutar game loop-a prvo apdejtovao svet a zatim renderovao na ekran...

Ako sam te razumeo dobro, to je isti nacin koji i ja koristim, a mislim i najlogicniji:

UpdateWorld(); // fizika, "kuliranje" :D, klipovanje...

DrawWorld(); // slanje komandi u GPU queue

I dok radis CPU apdejt istovremeno GPU bi trebalo da ima vremena da odradi svoj posao sinhronizovano.

IMO sto se tice tredova, ja sam se za sad koncretisao samo na nekonkurentne poslove, s'tim (sto je i logicno) da se ti poslovi dobro izbalansiraju/podele na podjednake "tezine" tako da bude sto manje neiskorisenog procesorskog vremena.
Najbolje je profilisi sam i proceni sta je najbolje.

Batalio sam GPU occlusion culling i presao na CPU occlusion koje je po mom misljenju dosta bolje resenje. Evo jedne zanimljive/open-src biblioteke koju trenutno koristim ako nisi video.

Sto se tice tajminga, oko toga ne bih hteo da polemisem. Evo par zanimljivih artikala, ako nisi video:

http://www.koonsolo.com/news/dewitters-gameloop/
http://lspiroengine.com/?p=378

Jel pravis neku igru ili "general purpose engine"?

[Geomaster]

Upravo takav mi je pseudokôd za gameloop trenutno, ali se bojim da je to možda neoptimalno, pa zato pitam postoji li neki game loop koji je 'prihvaćen' i koji se naširoko koristi, a nije ovaj. Nemam predstavu kako bi sve radilo kada bi bilo podeljeno u thread-ove pa zato pitam. Zbog čega si batalio GPU occlusion culling? Na kakve si probleme nailazio? Interesuje me zato što ja planiram da koristim taj pristup u scenama gde bi to imalo smisla. Hvala na linku za ovu biblioteku, pogledaću je mada će integracija biti malo čupava jer koristim gotov grafički engine, Horde3D (sa kojim sam apsolutno prezadovoljan tako da moje najtoplije preporuke) pa ću morati da ga čerečim da ubacim i ovo. 'Fala i za ova dva članka, nisam znao za njih ranije ali deluje kao da može da pomogne. Našao sam dva grafička umetnika (jedan lik radi koncept a drugi modeluje, pravi teksture itd.) pa sam počeo neku igru, ali ovo što pišem izgleda veoma general-purpose jer sam pokupio gomilu kôda iz mog starog game engine projekta, ušio Horde3D, Bullet i Lua skripte u to i ispade da mi se sve game-specific stvarčice nalaze u Lua skriptama Radiš ti na nečemu trenutno? Nit' govoriš, nit' romoriš, čoveče

[Belphegor]

Zbog čega si batalio GPU occlusion culling? Na kakve si probleme nailazio?

Menjao sam moju implementaciju dosta puta, u nekim slucajevima mi se desavalo da mi ne prikaze u trenutku objekte koji treba da su vidljivi i ne mogu da nadjem gde je problem. Plus se gubi vreme jer moras da menjas postavke uredjaja, menjanje RT/DS povrsina, cekanje na rezlutat za koji ne znas kad ce da stigne a zavisi od grafe do grafe pa se crta vise objekata nego sto treba.
Frostbite isto koristi CPU occ, Umbra gde sam video da koriste i za AI agente (mislim da Unity koristi Umbru)...
Probaj pa proceni da li se isplati.

Radiš ti na nečemu trenutno? Nit' govoriš, nit' romoriš, čoveče

Pa trenutno sto se tice mog progresa nemam bas nesto i da pokazem. Skoro sam zavrsio 3DS max utility plugin za export staticnih, animiranih (skin/biped sa max-ovim IGame interfejsom) modela, podaci transformacija instanci (trava, drvece...). Resio sam fino intrpolaciju izmedju frejmova ali me muci sistem za tranziciju izmedju animacija, pa jos uvek istrazujem u vezi toga, otom-potom. Resio sam dugo odlagani problem sa klipovanjem trouglova, sto mi je neophodno za decal-e, occlusion culliing. Trenutno radim na sistemu cestica...
recimo, fire heat-haze (nedovrseno):

Fire

I svasta jos nesto "ispod haube".

Našao sam dva grafička umetnika (jedan lik radi koncept a drugi modeluje, pravi teksture itd.) ...

E pa lepo. Sve najbolje vam zelim.

Ja cu mozda traziti pomoc ali tek kad mi kudi-kamo bude sve funkcionalno.

[Geomaster]

Hvala ti mnogo na infou, probaću hardverske occlusion queryje koje implementira Horde3D, probaću nekako da uglavim i neki CPU-bazirani sistem pa videti šta je bolje. Vatra sjajno izgleda, moram priznati da nemam pojma kako si to rešio. Vidim da je particle system, ali deluje mi poprilično realistično što nikad nisam uspeo da postignem u smislu vatre. Sledeća igra će verovatno koristiti tvoj engine

[Andross]

^Billboard + heat haze shader

[Geomaster]

Ma mislio sam konkretno na ovaj oblik vatre, kako izgleda tekstura čestice itd...

[Belphegor]

Da trenutno je samo 1 billboard, treba da dodam jos koji radi varijacije plus dim, zato sam i rekao nedovrseno.

Bazna textura:


Za distorziju kordinata textura:


Opacity:


+ RT scene

[Stevvan]

Po meni, najednostavnije i najbitnije pravilo u ovom poslu je KISS (Keep It Simple Stupid)
Za fiziku je najbitnije da ima konstantan delay, znaci da se fiksira na recimo 30 frejmova po sekundi, jer u slucaju da masina malo zabode ili sta vec, ogroman delay bi doveo do artefakta. E sad najednostavnije je i grafiku i fiziku zakucati na to i nece biti osetnih razlika za krajnjeg korisnika sto i jeste najvaznije a olaksava zivot. Ako zelis da imas nezavisan framerate onda se moze koristiti akumulator, tj. vrednost na koju se dodaje delay izmedju 2 frejma, pa kad postane veci od recimo 1/30 ciklicno se vrsi update fizike dok ne padne ispod te vrednosti, ovo se moze resiti i u okviru jedne ili 2 niti. Problemi nastaju u svakom slucaju ako resis da igra bude multiplayer, za to sam samo cuo da nezavistan framerate izaziva pakao i da treba bezati od toga kao djavo od krsta Nisam nikad pravio multiplayer tako da to ne mogu da potvrdim, ali su mi reci tog programera bile prilicno ubedljive xD

[Geomaster]

Počeo je raspust pa je, logično, prva stvar koju sam uzeo da radim rešavanje ovog problema sa game loop-om (koji mi se vuče još od postavljanja ove teme ).

Elem, ispada da je sve ovo mnogo teže nego što mi je delovalo. Ovde ulogu igraju više konkurentnih stvari na koje treba paziti. Odlučio sam da se logika (procesuiranje ulaza, AI i slične stvari koje su u vezi sa gameplay-em) zakucavaju na nekoj konstantnoj vrednosti (tipa 25 FPS) a da grafika/fizika rade što brže moguće. Pošto koristim Bullet našao sam njihov game loop koji je zapravo veoma koristan, međutim, ja nalećem na još jedan problem: V-Sync. Koristim GLFW i njegovu funkciju glfwSwapBuffers() koja ako je VSync uključen blokira dok ne sačeka rastersku liniju od drajvera (što u najgorem slučaju može trajati i do 17ms ako je monitor na 60Hz). To mi pravi problem jer po njihovom game loop-u treba da se događa render-fizika-logika a meni tokom rendera procesor samo bleji u praznom hodu dok ne dođe rasterska linija.

Odvajanje u više thread-ova liči na dobru ideju. Izdvojiti logički thread, neka on uradi jedan otkucaj logike, zatim spava preostalo vreme, pa onda opet itd. Onda drugi thread neka radi fizika-render što brže moguće. E a u tom slučaju opet render zakucava u praznom hodu pa se gubi dragoceno vreme tokom kojeg može da se simulira fizika. Ovo znači da treba da dodam još jedan thread u kome će se samo raditi fizika. Ali kako njega sinhronizovati sa renderom? Bullet nudi automatsku interpolaciju, ali kakvo delta vreme da mu prosledim? Kako da sinhronizujem sve ovo pomoću mutex-a, da ne s*ebem sve ali da zbog svog tog zaključavanja/otključavanja ne gubim na performansama?

Nemoguće da niko ovo nije radio i da nije naleteo na sličnu nedoumicu. Google je veoma neodređen, još nisam našao ništa što bi mi pomoglo, posebno ne kad se u celu smešu doda multithreading za koji mi zdrav razum kaže da je neophodan za lepe performanse unutar ovog višejezgarnog sveta u kom živimo.

[Stevvan]

Opet moram da te pitam: Zasto fizika mora da radi sto brze moguce, tj zasto je ne zakucas na konstantan framerate, kad pobogu svi to preporucuju?

[Geomaster]

Stevvan kaže:

Opet moram da te pitam: Zasto fizika mora da radi sto brze moguce, tj zasto je ne zakucas na konstantan framerate, kad pobogu svi to preporucuju?

Pade mi to na pamet dok sam kucao gornji post nego nespavanje u kombinaciji sa još nespavanja mi nije dozvolilo da trezveno razmišljam. Bio sam u nekom tripu da fizika nije dovoljno brza da radi na nekom konstantnom FPS-u od 30 ili sl. Da, zakucaću i fiziku.