laicky popis herniho engine

[SamanCZ]

Ahoj, jsem grafik pracujici prevazne na hrach cca 11 let, nekteri me mozna znaji i z jinych for o grafice a HW

A ted k memu dotazu, v jednom nejmenovanem foru na jinem serveru jsem se zapojil do diskuze o tom jaky je spravny pomer mezi poctem poly a poctu textur pri pouziti do herniho engine.
Ciste a jednoduse muj text byl rozcupovan a proto bych rad jestli by se nasel nejaky programator ktery by byl ochoten zde jednoduse v jednotlivich bodech napsat co se deje s modelem/scenou od prvnich kroku az k samotnemu zobrazeni v zavislosti na HW a to s ohledem na vertexi, poly/faces a textury. Aby to muj text bud potvrdilo/vyvratilo, nebo opravilo kde tedy mam ve znalostech teto problematiky chyby.

Ja jsem napsal ze CPU spocita podle polohy modelu a poloh jednotlivich vertexu daneho modelu normaly/polygony/faces aby GPU vedelo kde ma dane normaly/poly/faces zobrazit a dale s nima pracovat, a tyto data posle GPU ktere s temy daty dale pracuje a dopracuje se as k finalovemu obrazu.
Zkracene jsem to shrnul tak ze CPU by melo problem s prilisnym mnozstvim vertexu a naopak GPU by zase melo problem s prilis mnoho texturama (pokud by se nevesli do pameti) proto pouzivame LODy a take mene textur (ne desitky textur na jediny objekt).

diky
_________________
www.stepanprokop.cz

[frca]

Opravdu je to trochu jinak. Dnes už jsou na moderních GK uložené i vertexy, a ty se transformují na GPU. Pro grafický výkon není ani tak zásadní velikost paměti (laicky řečeno kolik se tam vejde textur apod.), jako výkon samotného jádra grafického procesoru a kvalita ovladačů.

K počtu textur na objekt: Je lepší, když je na objektu namapována jedna textura o velikosti 1024x1024 než 4 textury každá o velikosti 512x512. Paměti zabírají stejně, ale problém je to přepínání mezi nimi, které trvá nějakou dobu. Tady už to ale není o výkonu nebo o velikosti paměti, ale o lenosti grafiků.
_________________
www.FRANTICWARE.com

[]semo[]

Ahoj,
je to samozřejmě trochu komplikovanější, než si napsal. Každý engine si to může samozřejmě dělat po svém a určitě se najdou i enginy, které počítají spoustu věcí na CPU - zvlášť na některé konzole. Ale převážně to dnes funguje takto:

- načtený model se skládá z nějaké hierarchie objektů (auto, na něj jsou připojena kola, dveře na kterých jsou zrcátka, ...):

- Každý ten objekt (auto, kolo, ...) má typicky referenci na Vertex Buffer, Index Buffer a Materiál - tj. reference na Shader, (nebo effekt, chceš-li) a jeho nastavení (diffuse texture, specular, ...).

- Vertex a Index buffery obsahují geometrii modelu a jsou nahrané v grafické paměti (VRAM).

- Shadery jsou programy nahrané rovněž v grafické paměti, které mají za úkol zobrazit geometrii obsaženou ve Vertex a Index bufferu na obrazovku.

- V shaderech se počítá transformace modelu (tzn. posune, otočí, ... všechny vertexy objektu). A tady je to, na co ses ptal: vertexy (normály, ...) se transformují na GPU.

- Když má objekt hodně vertexů, musí GPU provést hodně operací s vertexy. Musí je provést i v případě, že objekt je v dálce a je velký několik pixelů. Z tohoto důvodu se používají LODy.

- Operace s pixely (to jsou ty textury, o kterých jsi mluvil) brzdí v případě, že doba potřebná pro vykreslení všech pixelů objektu je delší, než doba potřebná pro transformaci všech jeho vertexů. Záleží tedy na rozlišení a na tom, jak jsi k objektu blízko. Dnes většinou ve hrách brzí právě tyto operace.

- Takže: záleží na scéně, pokud máš třeba malou místnost, nemají lody prakticky cenu, ale pokud kreslíš les, musíš je udělat.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[SamanCZ]

Vseobecne me zajimalo hlavne to, jak se na celem procesu podili hlavne CPU, tedy otazka toho jak moc CPU vadi pokud ma model spousty vertexu, poly/faces.

rozdil rekneme model auta s 10tisic vertexi nebo 1milion vertexu, jak moc rozdilne to pro CPU je/bude z hlediska toho co musi spocitat (vertexi uvadim proto, ze me nejcasteji limity zadavaji firmy prave ve vertexech, nikoliv v poly/faces)

a to i treba z hlediska Fyziky kterou dnes ma nastarosti prevazne CPU, fyzika na GPU je pak jinej pripad, ale to je dnes tusim jen pripad GPU-PhysX, ostatni fyziky na GPU jsou rozsirene myslim spise sporadicky, pokud vubec
_________________
www.stepanprokop.cz

[]semo[]

Při kreslení, je procesoru jedno, jestli model auta bude mít 1000 vertexů, nebo 1 000 000. Ale GPU je taky procesor a tomu to už jedno neni. Proto jsou tu limity.

CPU používá geometrii modelu typicky při nějakém efektu, kdy je potřeba provést kolizi s trojúhelníky - z firem, kde jsi pracoval, jistě znáš pojem "decaly" - když se do něčeho střelí, je potřeba detekovat přesně kolizi a vytvořit tam dírku. Nicméně v takovém případě se transformuje spíše přímka (trasa střely) do prostoru objektu. Tudíž opět nejde o počet vertexů, ale o počet trojúhelníků při kolizi.

Fyzika většinou používá vlastní modely nezávislé na grafice. Ještě jsem neviděl, že by to bylo jinak.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Marek]

[Augi]

Jo. CPU vypočítá (příp. jen předá z fyziky) maximálně matice (16 čísel), které udávají pozici/natočení/scale modelu - vlastní transformaci vertexů dělá až GPU.

[Jack M.A.X.]

Měl bych dotaz k tomu, co zmínil frca

[SamanCZ]

diky za odpovedi
_________________
www.stepanprokop.cz

[nou]

no kazda tetura navyse znamena zbytocny drawcall navyse. pri par modeloch to samozrejme nema zmysel ale pri stovkach uz ano.

ono to zacne potom limitovat procesor ktory nezvlada viac drawcall.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[Vilem Otte]

[Marek]

Vilem Otte> Draw calls je menší problém jenom u profi enginů (instancing atd.) Setkal jsem se i s enginy, které mají mnohem horší limity. Bez instancingu si toho moc nevykreslíš.

Průměrný amatérský engine (žádnej kick-ass ego-fap shader-heavy high-tech engine) plynule zvládne cca 1000 draw calls (příkaz 'renderuj') za snímek. Některé enginy zvládnout míň, třeba 200, a některé i statisíce, ale to jsou spíš ty profi. Odvíjí se to hodně od rychlosti CPU, GPU klidně můžete mít i z budoucnosti, ničemu nepomůže.

Každá změna textury, parametru materiálu (třeba barva), změna pozice nebo rotace = nový draw call. Každej submesh = nový draw call.

Každej model vám může vygenerovat i 30 draw calls a pokud máte limit 500, hru prostě neuděláte. Co s tím?

1) Textury celého modelu (nebo i více modelů) sloučit do jedné.
2) Když se mění parametry materiálu pro každou část modelu, dejte je do textury (různé specular a gloss mapy jsou právě hodnoty materiálu v textuře).
3) Všechny části modelu musíte sloučit, aby to byl celistvej neoddělitelnej kus geometrie.
4) Když jste něco udělali špatně, programátor vám to velmi rád vrátí na přepracování.

Sranda to přestává být, když takhle musíte slučovat i více modelů. Např. produkty ve výloze. Všechny musíte sloučit do jednoho modelu, i kdyby jich bylo 20! (včetně textur!) Jinak to uprostřed města prostě nevykreslíte.
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

Já mívám obvykle pár tisíc maximálně (pokud renderuji přes rasterizaci), ale vše je završeno v BVH (což v tomto případě hodně ušetří).

1.) Slučování textur jo, ale jen do určité velikosti a jen pro modely relativně blízko sebe (ať pracuje dobře LOD), při příliš velkých texturových atlasech by byl texture read a texture access velmi náročný na GPU (lookup do 512x512 textury je méně náročný než lookup do 4096x4096 textury).

2.) Zpravidla toto platí vždy (hlavně pokud chceme mít různé stínování pro pár submeshů, kdy by nás přepínání parametrů pro shadery výkonově docela zabilo).

3.) Statický model do jediného draw callu - jo, ale! Lepší ho dynamicky rozkouskovat na několik větších sektorů a prostě sektory co nejdou vidět ani nekreslit (a tím pádem všechny dynamické objekty uvnitř neviděných sektorů). Nejlepší je hodit ho do jediného kusu a pak rozkouskovat.

4.) Přepracovávat modely je docela drastické řešení. Ale také funguje ... horší pak pro toho, kdo vývoj platí (ten se pak jo prohne).

Další věc je místo malých shaderů používat ubershader (zase je třeba vyladit náročnost ubershaderu proti více malým shaderům - více malých je horší pro CPU, ubershader pro GPU).

Uprostřed města to sranda často je když pak dojde k tomu, abys musel mít spoustu typů budov a začal slučovat texturu pro celou budovu (včetně obsahu výlohy) do jedné na 2048x2048 mapu a udržel dostatečnou kvalitu - to je taky sranda.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[franz]

Také bych se zeptal na výkon je nějaký rozdíl mezi použitím scale=1 a scale=0.002151541 ? Tím myslím měřítko veškeré geometrie.

[Augi]

Samotná skutečnost, že v matici jsou jiný čísla, pokles výkonu nezpůsobí Ale pokud bude např. objekt na obrazovce kvůli tomu větší, tak se musí rasterizovat více pixelů a to se jistě na výkonu projevit může.