Výkon aplikace (FPS)

[perry]

Tak jsem udelal velmi základní QuadTree s Frustrum Culling (16 dílů), ale nárust FPS mi přijde, že je poměrně malý (když kreslím jenom polovinu terénu, rozdíl je cca. 20 FPS)

Najdu si bloky, které mám vykreslit a ty poté kreslím. Problém se mi zdá, že je přepínání toho draw.

[VladR]

Ohladom terenu - takze mas heightmapu 256x256, co je 131.072 tris. To je sice zufalo lowres, ale ak ti to staci, tak OK.

Druha vec je, ze to renderujes 10x, cize je to nakoniec 1M tris.
To sice moze vyzerat hrozivo, ale 7900GTX zvladne v pohode tych 7M tris v plynulom framerate (vyskusane na 7950ke, ale to nie je velky rozdiel oproti 7900 GTX).

Pozeram, ze si konecne implementoval zakladny quadtree, 4x4, cize mas jeden chunk 64x64->8192 tris. To sice nie je bohvieco, a ak by si teren renderoval len na 1 raz, tak by to bolo zufalo malo. Ale pri 10 renderoch uz urcite rozdiel vidno.

Ak mas 4x4 chunky, tak si bud isty, ze to volanie (max 16 krat) DIP ta nespomaluje vobec, lebo je to tak maly pocet, ze to nestoji za rec.

Akym sposobom texturujes teren ? Pokial tam mas nejake narocne per-pixel operacie, tak ak to renderujes 10 razy, tak je jasne, ze kartu zabijes.
Urcite vypinas texturovanie/efekty na tie passy, ktore ich nepotrebuju ?

[VladR]

Zacali sme zabiehat do prilisnych detailov, pricom netusime ktory element ta brzdi najviac.

Venuj radsej 15 minut nakodeniu featury, ktora ti kedykolvek v buducnosti moze pomoct - sprav si ON/OFF na klavesy (napr. 1-9) a na zaciatku renderovania kazdej featury daj jedno if (!feature [X].enabled) return; a mas to.

Po spusteni zistis za 5 sekund, ktora vec ta uziera najviac

Jasne, nejaky profiler od nVidie by bol lepsi, ale tamto nastavit je peklo, kdezto toto budes mat vzdy k dispozicii automaticky, bez akejkolvek dodatocnej namahy

[perry]

Terén texturuju jenom ve finálním kreslení a pro vodu, pro stíny kreslím jenom bílou barvou.
Texturovaní mám podle nadm. výšky (zatím) - 0.. 10 textura A, 8...20 textura B atd. Ty textury jeste upravuji podle vzdálenosti od pozorovatele. V okolí větší počet než v dálce.

Ohledně testu.. zkousel jsem vice-mene vykomentovavat bloky kodu, ale problem je, ze se to pořád chová cca, stejne. Ten QuadTree to ted trošku "nakopl" (zatím testuji pouze na kružnice).

[VladR]

OK. Hod tu nejaku statistiku - napr. aktualny stav, ked uplne vypnes renderovanie terenu, alebo ked uplne vypnes odrazy , resp. tiene.


Skusil si uz porovnat vykon v 640x480 vs 1680x1050 ? To nam hodne napovie ci si momentalne CPU/GPU-limited.

V pripade, ze ten teren ta skutocne brzdi najviac, je pomoc jednoducha - sprav si dodatocny low-res teren - 64x64 a ten renderuj ako tien/odraz.

Jedina vec, ktora ta (mimo narocnych shaderov) moze pri terene realne brzdit su streamy. Kolko ich pouzivas ? Tipol by som, ze len jeden. Nepredpokladam, ze pouzivas separatny stream na UV/indexy/XZ a separatny na Ypos, ze ?

[perry]

Používám jeden stream na všechno... to možná není špatný nápad to rozdělit. Protože při renderu shadow mapy mi stačí jenom pozice a nepotřebuji nomarlu, UV, a vyskove indexy

[VladR]

Streamy sa pouzivaju, ked potrebujes usetrit VRAM, resp. by si potreboval updatovat VB kazdy frame a presun vacsieho kvanta dat cez zbernicu ti proste vykon zabije.

Napr. ja mam u seba 9x9 = 72 chunkov po 128x128, tak je uspora len na XZ/UV koordinatoch (9x9-1)x(128x128)x(8+ = ~18 MB, co je celkom dost. (samozrejme, aj tie XZ/UV su este pakovane)

U teba to nestoji za tu namahu s debugovanim.

Kym mas 1, resp. 2 streamy, tak pokles vykonu nepocitis. Ale ked mas 3-4, tak vtedy to padne rapidne, i ked pocet textur/trianglov je ten isty. A to bez ohladu na to, ze mas vertex size alignnuty na nasobok 16/32.

Cize, ak sa rozhodnes ist do streamov, tak chod iba do jedneho dodatocneho, kde budes mat nasekane vsetko co v chunku potrebujes (aj za cenu pripadnej duplicity).

[perry]

Jak se řeší kreslení objektů, které sice leží uvnitř frustra, ale jsou řekněme "za kopcem" ?

[Marek]

Možnostní nemáš málo:
1) Použít nějaký šikovný algoritmus, třeba v octree může mít každá noda uloženo, jaké další nody jsou z ní viditelné. Existují i sofistikovanější metody.
2) Udělat depth-only průchod, který vykreslí scénu jen do zbufferu. Druhý průchod se pak dělá standardně akorát s vypnutým zápisem do zbufferu. Depth test ti vyřadí všechny pixely, které jsou v zákrytu, a vyřazení bude pravděpodobně hned po rasterizaci před pixel shaderem (tzv. EarlyZ). Může to dost pomoct.
3) Kreslit objekty od předu se zapnutým depth testem. Poskytuje částečně výhody metody (2) a není potřeba kreslit scénu 2x. EarlyZ se ti tady ale může vypnout při alpha testu a KILL instrukci v pixelu shaderu (pixel shader se tedy bude muset provést vždy).
4) Occlusion Queries ti umožní získat, kolik pixelů objekt zabere v pohledu. Protože to závisí na tom, kolik pixelů projde depth testem, je lepší se držet rad v (2) nebo (3), aby to mělo smysl.
5) Conditional Rendering funguje podobně jako Occlusion Queries, akorát není potřeba vracet počet pixelů do RAM a tím způsobovat ztráty výkonu čekáním na GPU. Místo toho se při renderingu objektu spustí podmíněný draw-call, který si přečte ten počet z VRAM. Tahle funkce nemusí být ve všech 3D API k dispozici (bohužel), ale co je mi známo, GPU umí podmíněně spustit command stream na základě hodnoty ve VRAM.
_________________
AMD Open Source Graphics Driver Developer

[VladR]

Tomu sa hovori Occlusion Culling a byt tebou, zvazim ci to nenecham na kartu. Nejaku formu mali uz pred 10 rokmi a kazdou generaciou sa to zlepsovalo. Vyskusaj (napr. manualne na nejaku klavesu) vypnutie renderovania daneho useku, o ktorom istotne vies, ze ho nevidno a uvidis, ci to vobec ma zmysel sa tym zaoberat a nenechat to radsej na kartu tym, ze to proste zrenderujes front to back (vyjma transparentnych objektov).

Samozrejme, ak mas cas, pohraj sa s occlusion queries, ktore maju HW podporu.

Ale musel by si mat velmi clenity teren a obrovske kvantum objektov, ktore by boli skryte, aby si pocitil hmatatelny rozdiel, obzvlast ak sa bavime o framerate okolo 30 fps, kde to uz musi byt hodne narocny objekt, aby ti framerate posunul o pol framu.

Ved ukaz screenshot (staci wireframe) zvrchu a z pohladu kamery a hned uvidime, ci to vobec ma zmysel.

Mohol by si kreslit najprv scenu len do zbufferu, co by ti v pripade narocnych pixel shaderov mohlo dost pomoct. Ale hlavne si najprv zisti, manualne, ci to vobec stoji za to.




EDIT : kurnik, Eosie, ty si rychly, asi sedis na tom notifikacnom maili

[perry]

Ok.. díky.. udělám to kreslení od nejlbižšího po nejdál a ještě vyzkouším Render to Vertex Buffer To mi docela zajímá, co udělá

[]semo[]

Osobně bych to tim Render to Vertex Buffer nekomplikoval, i když to jistě může bejt zajímavý. Stejně tak Occlusion culling mi tu připadá dost zcestný. Lepší by bylo najít příčinu, než vrstvit nový fíčury. Jistě tam bude nějaká brzda.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

Nj.. ale jak tu příčinu najít Tím že jsem zkoušel vykomentovávat kusy kódu se to moc nezlepšilo, v programech od NVidie, co na to jsou určené se zatím moc nevyznám... to je hromada věcí ale tak pro profíky (je skvělý že mají v referencích třeba Crysis, ale já mam nižší cíle .. aspoň aby to vypadalo jako Far Cry )... nejvíc mě podle mě brzdí ty stíny, jenomže na takhle low-polygonal terénu co mám, mi přijde těch 150FPS šíleně málo (potom co jsem tam dal Frustrum Culling).

[]semo[]

Možná to brzdí víc věcí současně, zkus to, co navrhoval VladR: vypínátka na všechny ty featury. Nebo nakonec zjistíš, že to neni grafikou :-).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Marek]

150 FPS je hodně, méně než 30 je málo.

Máš doufám aplikaci zkompilovanou pro release se všema optimalizacema?
_________________
AMD Open Source Graphics Driver Developer