Výkon aplikace (FPS)

[perry]

Mám aplikaci, která ma v současné době na
Core2Duo 2.4GHz
GF 7900GTX 512MB

přibližně kolem 80-90FPS (průměr)

Co renreduji:
terén (256 x 256 x 2 trianglu), voda, stíny (kaskády -> 3 stínové mapy), objekt (sky-dome) a castice (500 castic => 1 castice = 1 triangle)

Přijde mi, že FPS není ideální a že někde mám něco blbě. Jelikož i starší hry měli všechno tohle a běželi o hodně rychleji. Když vezmu v potaz, že moje grafika byla před 3 lety high-end (jedna z nejvýkonnějších na trhu) a v aplikavích s daleko větším počtem polygonů jsem míval podobné FPS
C# jako takový by snižoval výkon max. o 10%

Postup renderu:
begin();
Render reflexe vody
sky-dome
for (int i = 0; i < 3; i++)
{
render shadow mapy pro kaskadu i
render sceny pro kaskadu i
render vody pro kaskau i
castice v kaskade i
}

end();

present();

kaskady menim zmenou viewportu a prepoctenim matic projection a view

[nou]

mas to v DirectX? inak mozno je to CPU bound tymi casticami ktovie ako ich aktualizujes a posielas do karty.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[perry]

Jj.. DirectX9 (přes SlimDX)... jinak ty častice to nedělají... když je vyhodim, je to stejny.

Mam asi min. 10x vykreslení scény abych dostal 1frame... což se mi zdá trošku moc, ovšem imho s tím nic udělat nejde.
1x na vodu
3x shadow mapa pro ruzne viewporty
3x scena pro ruzne viewporty

[Marek]

10x vykreslení scény rozhodně je moc.

Měl bys použít nějaké techniky pro zvýšení rychlosti, viz níže.

Snížení režie na CPU:
- Geometry instancing
- Frustum culling (a dělení prostoru, lody...) na všechno (shadow mapy, odraz vodní hladiny, viewporty)

Snížení počtu vertexů:
- User clip planes (odřezat co nejde vidět)

Snížení počtu pixelů:
- Scissor test
- Pokud máš zapnutý zbuffer a nepoužíváš alpha test ani clip/discard v shaderu, vždy kresli objekty od nejbližšího po nejvzdálenější, skybox na konec.

Zrychlení výpočtu pixelů:
- Použij větvení kódu pro vyřazení nepotřebných výpočtů, ale používej ho spíš na velké věci (třeba na vyřazení osvětlení když je objekt ve stínu).

Zrychlení výpočtu vertexů:
- Použil bych Render To Vertex Buffer AKA Stream Out pro transformaci veškeré geometrie scény (kromě projekce) a výsledek bych pak použil ve všech renderování. Nevím ale, zda máš tuhle funkcionalitu k dispozici.

Nějaké obecné rady:
- Dost náročné je přepínání framebufferu/textury, do které renderuješ. Změna viewportu v rámci jednoho framebufferu/textury je OK.
_________________
AMD Open Source Graphics Driver Developer

[perry]

Kreslit scénu musím bohužel od nejvzdálenějšího, protože jinak byl problém se zrcadlením částic a jejich průhledností.

Ohledně Snížení počtu vertexů. Jak tohle přesně udělat. Mám použít device.SetClipPlane(), nebo jsi myslel neco jiného ?

[Marek]

Kresli nejdřív neprůhledné objekty odpředu a až poté kresli průhledné odzadu s vyplým zápisem do zbufferu.

Jo, nejspíš to SetClipPlane, ale samozřejmě si musíš ty roviny nějak spočítat sám (určitě ve vodní hladině není vidět všechno, co se pro ten odraz renderuje). Ono to vlastně nesníží počet zpracovaných vertexů, ale pixelů (včetně rasterizace primitiv).
_________________
AMD Open Source Graphics Driver Developer

[perry]

Ok.. a ještě ohledně Frustrum Culling.. chápu ho na objekty, quad-tree apod... ale jak se přibližně dá udělat na terén ?
Pokud terén rozbiju na sub-meshe a pak je budu chtít kreslit, nebude to pomalejší než kreslit to celý přes VB/IB ? Takhle budu volat max treba 20x draw na usek...

[Marek]

Pokud renderuješ scénu 10x, tak to rozhodně problém bude. Můžeš si tuto optimalizaci nechat až na konec a pak to třeba nasekat hodně nahrubo.
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

[johnnash]

ROAM uz je dneska mrtvy, ja mam hotovy GeoMipMapping a funguje to paradne http://www.flipcode.com/archives/article_geomipmaps.pdf.

[Augi]

10 renderů sice zní hrozivě, ale pokud používáš cascading shadow maps (aspoň tak jsem to pochopil), tak ty 3 rendery pracují s (v ideálním případě) disjuktní množinou vertexů a stínové mapy by měly být poměrně malé, takže to by zabiják bejt nemusel.

Asi by to chtělo, aby jsi podrobněji rozepsal, jaké optimalizace používáš a jak přesně renderuješ.

Ale jak psal Eosie - základ je renderovat jen to, co je skutečně potřeba a renderovat nejprve neprůhledné objekty odpředu dozadu (příp. řadit dle textur nebo jiných heuristik) a pak teprve průhledné objekty odzadu dopředu (s vypnutým Z-bufferem).

[perry]

Optimalizace zatím nemám žádné proto tenhle topic.

Postup renderingu jsem vice-mene napsal v prvním prispevku.

[Marek]

Je třeba vzít v úvahu, že hry používají poměrně drsné optimalizace od samotné hry až po grafický engine. Neoptimalizovaný kód bude vždycky pomalý.
_________________
AMD Open Source Graphics Driver Developer

[perry]

Ohledně frustrum culling. Vybral jsem si QuadTree.

Ted jak scénu kreslit. Mám nekolik nápadů:
a) každý sub-díl - vlastní vertex a index buffer a přepínat při kreslení index a vertex buffer (imho nejhorší varianta, velká režie okolo)
b) centrální vertex buffer a dělit pomocí index bufferu - při kreslení se potom bude volat drawIndexedPrimitives několikrát za sebou nad jedním VB akorát se bude měnit IB. (osobně můj favorit)
c) vytvořit pro každý díl 1 mesh a pak volat DrawSubset() (přijde mi dost podobné možnosti a), akorát využité vestavěné metody a třídy)
d) ??? jsou nějaké další možnosti ??

Co jsem hledal na netu, tak nikde se moc vlastním renderingem potom nezabývají. Všude vytvoří strom a tim to končí.

[Augi]

Záleží, jaký máš terén. Pokud Ti ho modelují vertex po vertexu grafici, tak Ti nezbyde než ho rozdělit na meshe a ty pak testovat na viditelnost.

Podle toho, co jsi dosud psal, ale předpokládám, že máš terén řešený pomocí nějaké pravidelné mřížky. Zde záleží, jak je terén velký. Pokud se v pohodě vleze do grafické paměti, tak bych začal tím, že bych udělal jeden velký vertex buffer a jeden velký index buffer. Jednotlivé tiles by pak definovány indexem, na kterém se má začí renderovat a počtem trojúhelníků.

Dál se pak můžeš pohnout tím, že implementuješ nějaký LOD na terénu. To by teoreticky šlo zařídit jen dalším index bufferem...