Lit Particles

[pcmaster]

Caute, davam to sem, ale mozno sa to hodi do grafickej sekcie.

Moj problem je vymysliet, ako rasterizovat osvetlene castice (billboardy). Hlavna poziadavka je:

Lubovolny pocet svetiel roznych typov (spot/dir/point) x (no-shadow/pcf/...) -- svetla bez tiena sa ale v podstate pouzivat vobec nebudu (nijaky deferred shading s 1000 svetlami bez shadowmap, lez jednotky az desiatky svetiel s transparentnymi (obyc/deep opacity/fourier opacity) shadowmapami). Pocty particlov budu v radoch iba desiatok az stoviek tisic.

Real-time rychlost nie je pri vysokom pocte svetiel poziadavkou, staci interaktivna rychlost a nizsia. Kazde svetlo so sebou nesie vacsinu parametrov, ktore Maya ma pre svetla, tj zozere i viac nez desat textur. To vylucuje moznost zapojit viac nez 1-3 svetla do shadera naraz (nedostatok texturovacich jednotiek).

Pristup stylu vybrat len niektore dolezite svetla a spravit lighting (a shadowing) len s nimi mi pride nepouzitelny, ale mozno nebude ina cesta. Popping chyby pri zmene sady dolezitych svetiel su ale uplne neprijatelne.

Vykreslovat ich na viac prechodov, tj aplikovat jednotlive svetla postupne v passoch je pre tento typ transparentnej geometrie (i keby bola depth-sortovana, co obcas je, obcas nie), je zial zhola nemozne (napravte ma, ak sa mylim).

Samotny osvetlovaci model, zial, tiez este nemam uplne premysleny

Takze, nejake napady, ako kreslit osvetlene, univerzalne particle? Ako z toho von?
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[pcmaster]

Tak. Dolezite bolo si to takto povedat. Napad teda vznikol, nie moj, poradil kolega, ale asi takto.

Pred samotnou rasterizaciou sa vo vertex shaderi (ci dokonca compute shaderi, to je celkom jedno) spravi pre kazde svetlo osvetlenie particlu (per-vertex), pricom k rasterizacii nedojde a vystup z VS sa naakumuluje do bufferu (stream out/feedback/RWBuffer/atomicke/whatever). Nascitany vystup bude teda v podstate finalna farba, zmodulovana vsetkymi svetlami i shadowmapami. No a tento buffer sa potom pripoji k ostatnym vstupnym bufferom do input assemblera a particle sa vyrasterizuju prave raz, uz bez svetiel. Ano, per pixel osvetlenie takto nevyrobim, ale zase chlapci od NVIDIE ukazali, ze staci billboard prehnat cez teselator a spocitat osvetlenie na jemnejsich vertexoch a je to pekne To sa uvidi, ci bude potrebne.

Tak, co si myslite? Niekto? Nieco?
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[VladR]

Nemas nejaky link po ruke, kde by bolo viac detailov tejto techniky ? Celkom ma to zaujalo.

[pcmaster]

Nie, pretoze sme ju vymysleli pred asi 15 minutami! Ak sa podari, tak mozno paper napiseme Tu je miesto nad nou filozofovat. Alebo nad osvetlovacim modelom, ci cimkolvek.

Inak hodne este spomenut, ze sa snazim podporovat vsetky mozne shading typy particlov, ktore su v Autodesk Maya (tam niektore idu len v SW rendereroch, niektore len v HW renderoch a niektore su divne ).
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Vilem Otte]

Imho nejlepším řešením zde je, překvapivě, ray tracing (ušetří ti spousty práce). Nicméně tomu se zřejmě chceš vyhnout, takže k tomu co můžeme použít...

Deferred shading by to hodně usnadnil, jenže ten asi použít nemůžeme (Deep G-Buffery by byly asi příliš velké). Teoreticky bys mohl jejich počet srazit stipplingem, ale... - tím se pipeline stane příliš komplikovanou a tím bude velmi pomalá.

Zůstává tedy Forward shading, kde je možné řešení brute force (tedy ve více fázích budeš osvětlovat postupně po 3, nebo 4 světlech) a additivní blending výsledků do sebe. Tedy mýlíš se, není to nemožné. Bohužel co se týče rychlosti, nebude to nijak extrémně rychlé (ale vzhledem k jinému řešení - deep G-Buffery - to bude mnohem rychlejší).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[]semo[]

Pěkně ste to vymysleli :-).

Otázky:
1) Jak bude fungovat ta "akumulace do bufferu"? Nemám teď moc přehled, co se dá v nových shader modelech dělat a co ne. Bude možné výsledek osvětlení z VS přímo přičíst do bufferu, nebo budeš sečítat dva buffery v dalším kroku (ať už na CPU, nebo na GPU)?

2) Pro jaký shader model to bude? Předpokládám že dost nový, číst shadowmapy ve vertex shaderu by jinak bylo pomalý nebo nemožný (ostatně stejně jako akumulace do toho bufferu).

Vilem Otte: Deferred shading by byl komplikovaný, particly bejvají často průhledný a to si s deffered shadingem moc nerozumí.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[pcmaster]

Semo, AFAIK, je uz teraz uplne jedno, ci a ako pristupujes k texturam v shaderoch. Samozrejme, ak budes citat vzdialene texely z dovodu, ze kazda castica moze byt niekde uplne inde, tak to asi nebude velmi koherentne (cache friendly). Predsalen, blizke fragmenty sahaju vacsinou na blizke texely. Takze z tohto hladiska to je urcite bude trochu horsie. No na druhej strane tam bude ovela menej texture loads (per-vertex lighting).

V DX10+ (urcite i GL3.x) mozes veselo posielat vystup do stream-output bufferu uz z vertex shaderu (ci geometry shaderu), v DX11 potom logicky i z domain shaderu, proste z poslednej casti pred rasterizaciou. Zatial je plan taky, ze:

[Marek]

[pcmaster]

[Marek]

Já jen říkám, jak to má být správně vykresleno.

Samozřejmě řešení existuje a asi je jich víc. Mě zrovna napadá jen tohle:
Poslat z geometry shaderu do rasterizace vždy tolik instancí té samé částice, kolik máš světel. Pixel shader pak nasvítí každou instanci jedním světlem a output merger ti to ve framebufferu zkombinuje.

Nebudeš moct během toho měnit blending, takže nastavíš jen (ONE, INV_SRC_ALPHA) a pro každý nenulový světlo nastavíš výstupní alphu pixelu na 0. Tím se ti ta blendovací funkce zredukuje na (ONE, ONE).
_________________
AMD Open Source Graphics Driver Developer

[Marek]

To bys ale stejně musel mít v pixel shaderu nabindovaný textury pro všechny světla, což jak jsi říkal nemůžeš. Plus je teda výhodnější ty světla rovnou sčítat v pixel shaderu.
_________________
AMD Open Source Graphics Driver Developer

[Marek]

Už ses nějak rozhodl, jak to budeš dělat? Použiješ ten per-vertex postup?
_________________
AMD Open Source Graphics Driver Developer

[pcmaster]

Nakoniec to je/bude per-particle/per-vertex akumulacny lighting-pre-pass a rasterizacia len jeden krat. Zrejme to bude krasne stacit, uvidime.
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Vilem Otte]

Light pre-pass (nebo-li preskladany deferred shading) a polopruhledne castice - Jak to planujete vyresit?
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[pcmaster]

Presne, ako som napisal RGB akumulacna operacia je add, alfa zase maximum. Na alfu totiz ma potom vplyv aj to, ci je castica v tieni, alebo nie (to je poziadavka - mat zaskrtavatko, ktore sposobi, ze castice v tieni zmiznu a nevyrenderuju cierny quad). Takze, pre kazde svetlo sa spocita osvetlenie a pricita sa, alfa podobne (max(old, new)). Vsetko bez rasterizacie. Pri rasterizacii sa uz prida len incandescence, sprite texture a podobne a pouzije sa priamo naakumulovana alfa. Co sa tyka depth sortingu, tak ten je vypinatelny.
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.