Teren v MEGAFPS (>3000 fps)

[VladR]

Asi to skor patri do Popelnice, lebo to nie su striktne ukazky z hry (ale mozno postnem neskor aj tie), aj ked sa nasledovne v hre samozrejme pouziva. Primarne je tento teren urceny na Canyon Screensaver, kde je mojou inspiraciou pamatna scena z ~konca pixarovky Cars, kde McQueenovi je ukazana pri starej benzinke sceneria Grand Canyonu s dohladom straaaaaaaaaaaaasne daleko (odhadujem tak 16-32km). Nieco take chcem mat aj v tom screensaveri. Toto sa uz tomu blizi

Pripada mi neuveritelne, kam az sa da zajst neustalym refaktorovanim a optimalizaciou. Napriek tomu, ze uz s 3D grafikou robim temer 10 rokov, dost ma prekvapilo, ked moja posledna (cca siedma) iteracia optimalizacie terenu prekrocila hranicu 3000 fps (vid screenshoty) a to aj napriek tomu, ze je tam niekolko streamov, ktore to zvyknu dost brzdit (aby clovek usporil VRAM).



Nie je ani tak podstatne, ze ako je ten teren robeny, ale je sranda, ze na smiesnom 1.6 GHz CPU s 7900kou vie ist nadhlad terenu 32768x32768 vo framerate vyse 3000 fps
Ktovie, kolko by to dalo s 3.5 GHz C2D a 8800GTX

A este vacsia sranda je, ze keby som sa s tym este trocha pohral, tak to vybehne na 3500-3800

Do slaka, prave ma napadlo, ze to mam v Debug (jak DX, tak VC). Mozno by tam este nieco spravili zapnute optimalizacie kompileru

BTW, pobezi to aj na GF2 Je to stale v DX8, kvoli co mozno najvyssej spatnej kompatibilite.

Ja viem, ze by som mal radsej robit na hre / screensaveri, ale ked ten streamovaci teren ma tak udesne bavi

Dufam, ze odolam nutkaniu priebezneho dynamickeho generovania heightmap/colormap (proceduralnym texturovanim) za chodu na volnych CPU, lebo to by bol koniec na dalsie 2 roky roboty vo volnom case

[rezna]

PRESUNUTO: ne opravdu to neni projekt - dal jsem ti to do 3D API - tam to asi nejvic patri

[Kula Shaker]

sranda, v dobach kdy jsme blbli s vlastnim enginem mel nas generovany teren na athlonu 1800+ sotva 50fps (Skoda ze nemam screen to by jste se nasmali) ted ale mame true vision a ten sam od sebe vyplodil tohle http://lomointro.ic.cz/editor.html je to sice jen 4k x 4k height map a textura ale.....Taky jsem koukal:)
_________________
http://3dcizek.com

[VladR]

Ja si pamatam doby, ked som sa po tretej iteracii terenu rok-dva dozadu tesil z 300 fps (i ked to bolo na GF6600GT a teren bol podstatne grcnejsi jak toto). Keby mi vtedy dakto povedal, ze to skonci na 3000, tak by som sa len zasmial.

rezna : Ono to de facto projekt je, lebo primarne to bude 3D screensaver, akurat toto priamo nie je hra (i ked ten teren pojde aj do toho RPGcka, co mam rozrobene uz asi 3 roky, no ale cas nepusti).

[Vilem Otte]

Hmm... když se nad tím zamyslíte - tak 3000fps a 300fps není zas takový rozdíl - jak spočteme snímky za sekundu - fps = 1000 / ms, kde ms je počet milisekund nutných k vykreslení.
Abych tady moc "nematematikoval" - pro 3000 fps ti trvalo vypočítat asi 0,3333... ms, pro 300 fps ti to trvalo 3,3333... ms - mezi námi 100Hz monitor ti obrazovku překreslí každých 10 ms (s tím, že většina monitorů k PC je 60Hz, nebo 75Hz), takže jestli ti scéna běží 3000fps, nebo 300fps je celkem k ničemu - ale co se týče rychlosti výpočtu, tak opravdu smekám klobouk. Za 0.3 ms dokázat vykreslit terén 32768x32768 pixelů, opravdu skvělá práce.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[VladR]

Samozrejme, ze prakticky vyznam to ma vzhladom na bezne zobrazovacie frekvencie (60-75 Hz), minimalny. Ide len o to, ze ti zostava viac casu pocas framu na ostatne veci na renderovanie. Ked tam nahodim vegetaciu a budovy, tak to uz padne pod 1000

Aby si to zle nepochopil, 32768x32768 je highest detail, z toho sa to potom zosekava. Pravdaze tam nerenderujem naraz 32767x32768x2 = 2.1 mld tris.

Ono to nie je problem zosekat na nizsi LOD a nie o tom je tento post, ale o tom, ze dnes na low-end karte za ~2k ma clovek celkom pozeratelny teren do slusnej dialky a este k tomu v 3000 fps.


Pre mna to jeden konkretny prakticky vyznam - a to, ze je ten renderer tak skalovatelny, ze to pojde aj na GF2, pretoze chcem aby ten screensaver bolo mozne pustit v plynulom framerate aj na GF2.
A GF2 asi nebude mat nikto s 2 GHz CPU ale tak realne s 0.75 GHz Duronom.

A tam to bude mat prakticky vyznam, pretoze to pojde aspon v 100 fps. Keby mi to slo len 100 fps na 7900ke, tak na GF2 to pojde 0.2 fps.

A nemozem chciet od screensavera minimalne poziadavky na urovni dnesnej 3D hry Poziadavky musia byt ako na 8 rokov staru hru a grafika ako v 3 roky starej hre

[Kaemon]

OT: 2. PC doma je celeron 2.4GHz s GF 2

[VladR]

Tak to ale asi mas len na testovanie, do casu. Alebo je to na furt ? Zaujimave, obcas tie upgrady su funny

[swarm]

Nebyl by link ke stažení? Rád bych se na to mrknul, sic mám možnost to vyzkoušet jen u sebe na Lenovo Thinkpad X300 (Core Duo L7100 1,2GHz, 2GB RAM, 64GB SSD a grafika Intel GMA X3100). Myslim, že se nemusíš bát, že by ti to tady někdo zneužil pro vlastní potřebu a pokud se bojíš, tak mi případně pošli jen na SZ.

Hrama se teď dvakrát moc nezabývám, ale připomnělo mi to dobu, kdy jsem se jima zabýval ještě docela hodně a screeny jsou docela pěkný .
_________________
Diagon Swarm - redaktor notebook.cz, moderátor diskuzního fora 3dfx.cz, zive.cz a notebook.cz
Blog o mobilní technice -> [WWW]

[VladR]

Zneuzitia sa nebojim Nic mimo terenu a par textur tam nie je.
Predovsetkym by som to musel zosekat do distribuovatelnej podoby, kedze to momentalne taha z adresara, kde je odhadom tak 8 GB roznych dat z roznych terenov v roznych verziach. Musel by som prekrokovat kazdy directory, co sa taha.

Tak ci tak musim spravit, kedze z toho mat byt screensaver a ten nemoze mat viac ako 20 MB. Mozno sa k tomu dokopem cez vikend, rad by som totiz vedel, ako to bezi presne na notase aky mas ty - ~1 GHz CPU a GMA3100 - to odhadujem na vacsinu cieloveho trhu (az na tu RAMku, tej mas vcelku vela, ale co uz. Mam doma nejake stroje, kde viem jednoducho spravit 512 MB RAM, takze pripadne swapovanie odhalim rychlo).

[CubA]

Gratuluju, vypadá to vskutku parádně.
Prosímtě neměl bys nějaký užitečný (ideálně s popisem algoritmu, ne jen samá matematika) paper o streamovaném načítání terénu? Potřeboval bych načítat celkem rozsáhlá území (100ky km s dohledem kolem 20-25km). Ale načtení jedné části(10x10km) mi momentálně zabere i pár minut, což není úplně ideální.

[VladR]

Tak to ta sklamem. Ziadne pdfko o tom nemam. Proste som na to siel sedliackym rozumom (a plus sa konalo niekolko rewritov/refaktorov). Data musis dostat do RAMky co najrychlejsie, cize musia mat minimalnu velkost. 2 Bytes na vertex je preto pri 16-bit heightmape horna hranica, idealne tak 0.5 Bytes na vertex

Dalsia vec, ktoru si treba uvedomit je, ze najvyssiu uroven detailov je potrebne streamovat len v tesnom okoli kamery. Tym padom ti staci z vacsiny casu streamovat len 1.5% - 6% povodnych dat v HiRes.

Streamovanie musi byt sebestacne a fool-proof bez ohladu na framerate. S tym sa treba pohrat. Proste kazdy X-ty frame nieco nacitas. Vzdy vychadzaj z toho, co realne user uvidi a tomu prisposob to, co nacitavas. Kopec veci tak vies zosekat, kde user nespozna rozdiel.
A tym experimentovanim zabijes nejaky cas, to je jasne.
Pri streamovani rataj s tym, ze CPU ma dnes kazdy silne, cize akekolvek vypocty dalej rozdistribuuj cez viacero framov.

V akom detaile mas vlastne ten usek 10x10km ?

[CubA]

průměrně jeden bod na každých 20 metrů, ale nemám pravidelnou síť takže je v tom docela guláš (jednou má linie 0.5km a jindy 10m). 2Byty\vertex jsou pro mě nedosažitelná hranice, musím ukládat jak výšku tak i polohu. Takže asi sbohem superrychlé vykreslování (ještě jednou gratulace). Alespoň 180 z toho ale jednou dostanu(momentálně 20-60 podle složitosti).

[VladR]

Samotne vykreslovanie kludne moze byt rychle, len tomu musi predchadzat patricny preprocessing. Netusim, ako presne vyzera rozmiestnenie siete vertexov, ale aspon nahrubo by si to mohol podelit do chunkov. To, ze v niektorom bude niekolkokrat viac vertexov ako v inom, uz budes musiet akceptovat. Akurat musis osetrit polygony na hrane, lebo tie budu duplikovane v oboch susednych chunkoch (alebo aj nie, ak tam nebudu velmi vyrazne presahy - to treba vidiet).

Samozrejme, zo vseobecneho meshu uz jednoducho LOD nespravis, na to si uz musis nastudovat rozne pdfka, ktore rataju s error metrics na pixel - a to je samozrejme CPU intensive.

Ak to budes mat podelene na chunky, nepotrebujes ukladat plnu poziciu kazdeho vertexu v ramci chunku. Staci ti len offset od laveho dolneho rohu chunku. A na offset ti s prehladom staci 6 Bytes (po 2 na kazdy koordinat). Skus experimentovat, a mozno ti budu stacit len 4 Bytes na offset (4*8 = 32 bitov, tie uz podel podla toho, ake tam mas obvykle rozsahy hodnot v ramci chunku - povedzme 10,10,12). Ukladat 4 Bytes vs 12 je slusny rozdiel, pretoze teraz loadujes 3-nasobne mnozstvo dat oproti tomu, keby si mal 4 Bytes. Uz tu by si mal prvu velku usporu - jak miesta, tak casu loadovania.

[tempicek]