Lightmaps GI/Radiosity

[Deluxe]

Takze k tomuhle mam par otazek, snad nekdo budete vedet.

1. Jak to s touhle technologii (predpocitany radiosity/osvetleni) v dnesni dobe vypada? Jak moc se pouziva? Je nejaka lepsi moznost?
2. Existuje nejaka knihovna na vypocet GI/Radiosity, ktera by se dala vyuzit na generovani lightmap? Neco jako Autodesk Beast nebo Unreal Lightmass.
3. Protoze mne jde o hlavne exteriery, mozna bude nejaka lepsi moznost pro tenhle pripad. Druhou veci je, ze neni potreba nejaka velka presnost.

Pokud nekdo o tomhle neco vite, nebo vite alespon o nejakym zdroji, kde bych se mohl neco dozvedet, budu rad za kazdou radu.

[franz]

Lightmapy jsou už pár let (asi od dooma3) nahrazovány shadow mappingem.
Pro generování LM jsem používal Gile[s]

[igor]

To nahrazování lightmap shadow mappingem je hloupost. Shadowmapy jsou strašně primitivní, dokážou simulovat jenom stín vzniklý přerušením přímého paprsku ze zdroje světla. Source engine, Unreal engine a určitě mnoho dalších nějaké výpočty radiozity apod. mají (nebo minimálně nějaké "podvody", které k podobným výsledkům směřují).

Abych nebyl úplně OT... Zajímavé články o řešení takového osvětlení psány přímo za vzniku hry, která je hlavně exteriérová, jsou tady http://the-witness.net/news/ Je tam mnoho podrobností, není to nějaký přehled technologii a tudíž nevím, jestli je to to, co hledáš, ale zdroj je to myslím kvalitní a něco z toho bude určitě přínosné.

[Marek]

Doom 3 používal stencil shadows, nikoliv shadow mapy. Stencil stíny se používaly i dávno před ním. Shadow mapy se začaly víc používat až později, protože to tehdy ještě nebyla dost dobře zvládnutá technologie.

Stencil stíny jsou taky super a do některých her se hodí o dost víc než shadow mapy (př.: Thief 3). Taky s nimi není tolik problémů, akorát je potřeba trochu optimalizovat pro fillrate.

Jinak Oblivion (engine: Gamebryo) i Half-Life 2 (engine: Source) stále používají lightmapy. Nedivil bych se, kdyby je Fallout 3 měl taky (beží na stejným enginu jako Oblivion). Ono se to dost vyplatí pro každou kombinaci statický objekt - statické světlo. Může se tam přidat global illumination, ambient occlusion atd. a pak to vypadá úžasně i na archaickým hardwaru.
_________________
AMD Open Source Graphics Driver Developer

[franz]

HL2 i Oblivion jsou staré hry V současných hrách ale málokde vidím statický stín, kor když je moderní, aby hráč s sebou nosil lucernu (amnesia) nebo se měnila denní doba (assassins creed) a pokud ano, možná něco na úrovni AO.

[Deluxe]

Asi sem do toho ty lightmapy blbe zamotal...

Jde mi hlavne o to predpocitany GI a treba i AO, protoze tyhle veci (pokud vim) jsou zatim v realtimu celkem problem...
U AO jeste celkem vim, tam by se dalo pouzit SSAO (na modernim HW).
V pripade GI nemam (skoro) vubec predstavu, tam je asi porad nejlepsi moznost mit GI predpocitany.
Takze o stiny jde az v druhy rade, stejne jsou dynamicky stiny (jakyhokoli typu) nutny.

[Vilem Otte]

Můžu potvrdit - Fallout 3 a Fallout New Vegas mají lightmapy; ty dnes archaické rozhodně nejsou! Jeden známý (spek z GameDev.net fóra) dělá dokonce realtime update lightmap, ovšem zvládne jen pár pozic do sekundy (20 nebo 30)).

SSAO použiješ prakticky všude, kde máš XBox 360 like HW - tedy GeForce 7800 a výše (což zase tak moderní není).

Co se GI týče - tak je zde pár řešení:
Light Propagation Volumes - viz google, tak trochu oser, dělá na ni Crytek
Instant radiosity - to už je jiná, jedná se o instantní tedy okamžitou radiositu, s deferred shadingem je docela rychlá, bohužel bez sekundárních stínů a kaustiky.
Reflective shadow maps - nepřímá světla přes stínové mapy (spousty map), jsou na dnešním HW interaktivní ... bohužel update všech stínových map trvá dlouho, a ten fillrate...
Imperfect shadow maps - rychlejší verze reflective shadow map, kvalita je téměř stejná, možná i vyšší
Path Tracing (tokaspt - the once known as smallpt) - TPB z OMPF.org fóra se činil a přepsal slavné SmallPT Kevina Beasona do CUDA, tím dosáhl interaktivního path tracingu (možná i realtime path tracingu)
Brigade - pokračovatel Arauna ray traceru, interactive/realtime path tracer postavený na CUDA

A v neposlední řadě něco k GI jsem měl i já na Game Access (šlo o realtime instant radiositu se sekundárními stíny, smíchanou s caustics mappingem - tedy bylo to celkové GI, počítané dynamicky v reálném čase ... instantně).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]

[franz]

Jo, to smysl dává.. beru to tedy zpět

[frca]

Jaké mají ty moderní lightmapy rozlišení? Jsou v nich zapečené i normální textury, nebo lightmapa moduluje texturu a k tomu se přičte specular?
_________________
www.FRANTICWARE.com

[gameDeveloper]

Osobně doporučuji technologii Normal Mapped Radiosity využívanou Source Enginem. http://www2.ati.com/developer/gdc/D3DTutorial10_Half-Life2_Shading.pdf . Je velice snadno implementovatelná a lze s ní dosáhnout úžasných výsledků - ostatně zahrajte si jakoukoli hru běžící na tomto enginu. Jedinou "nevýhodu" spatřuji v nutnosti použití tří light map, ovšem ty uvozovky myslím jasně říkají, že se jedná jen o banalitu.

[VladR]

Radiosita JE real-time. Len ju treba pouzivat na rozumne veci, teda nesnazit sa nou vyratat tien postavy, ale pouzit ju nasvetlenie velkych riovnych ploch (hlavne stien).

Ked som sa s nou naposledy (pred ~5 rokmi) hral, tak som na (uz vtedy) smiesnom 1.2 GHz CPU dosahoval real-time vysledky. Ked som to hodil do vertex shaderu, tak nebolo o com (tusim som mal vtedy GF4).


Samozrejme ju treba ratat rozumne. Experimentovat, do akej urovne odrazov ma vobec zmysel ist, a kolko % energie staci rozdistribuovat.

Je zbytocne stravit 10k viac casu s distribuciou 98%, ak 75% energie da zrovnatelny vysledok (akurat s inou hodnotou Exposure).
Iste, samotne lightmapy vyzeraju na pohlad trocha inak, ale v momente ked sa to blendne s povrchovym materialom, tak ten rozdiel je de facto neviditelny.


Osobne, neznasam sucasny plasticky "look" hier. Je jednoduche do hry nadrbat 100 svetiel, ale ono to potom aj tak vyzera.

Je samozrejme blud, ze radiosita by nemohla byt pouzitelna aj na dynamicke objekty. Dnes, ked mas po ruke 3-7 cores, nemas problem spocitat form-factory na akukolvek dynamicku geometriu, len si to treba rozlozit na viac framov.

[Marek]

Ten plastický look je tím, že výpočet osvětlení neprobíhá v lineárním prostoru, ale v prostoru barev, který má nelineární charakteristiku (říká se mu sRGB). To je špatně, protože i blbý dot product pak dává dost divný plastický obraz, viz třeba Doom 3. Ani pokročilé metody osvětlení jako Cook-Torrance tu plastičnost nezachrání, spíš to ještě zhorší.

Způsob, jak to zachránit, je jednoduchý: používat konverzi mezi lineárním a sRGB prostorem tam, kde je to třeba. V podstatě:
- Každou texturu, která obsahuje barvu materiálu, nahrát jako sRGB (všechny fotky, co jste vyfotili foťákem, jsou vždycky v sRGB). To způsobí, že při čtení z textury se barva bude automaticky převádět do lineárního prostoru, který je vhodný pro výpočet fyzikálně korektního osvětlení.
- Normal mapy a obecně textury obsahující různé vektory, úhly, vzdálenosti apod. nahrávat normálně, protože už lineární jsou.
- Veškeré konstanty barev, co jdou do shaderu, si taky musíte převést do lineárního prostoru.
- Shader se nemění.
- Při zobrazení je potřeba zapnout opačnou konverzi, tj. konverzi z lineárního prostoru zpět do sRGB (tj. to, co má vidět oko). Ta konverze by měla být až po blendingu. Je potřeba to ale správně skloubit i s post-processing efekty a konvertovat do sRGB třeba až když to jde na monitor.

Na konverzi z sRGB do linear je v OpenGL rozšíření EXT_texture_sRGB a na konverzi z linear do sRGB je tam ARB_framebuffer_sRGB.

Bez tohoto nebude vaše grafika NIKDY vypadat jako ta, co je v Half-Life 2 a novějších hrách. Pozor, DX9 karty nemají konverzi do sRGB *po* blendingu ale *před* blendingem, což může dělat problémy v obraze. Na Xboxu se ta konverze myslím implementuje dokonce ručně v shaderu, protože ta vestavěná je docela nepřesná.
_________________
AMD Open Source Graphics Driver Developer