.[ ČeskéHry.cz ].
[DX]Vice svetel v shaderu?

 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> 3D API / 3D Enginy
Zobrazit předchozí téma :: Zobrazit následující téma  
Autor Zpráva
SUK



Založen: 14. 11. 2007
Příspěvky: 93
Bydliště: /dev/null

PříspěvekZaslal: 2. listopad 2008, 21:11:29    Předmět: [DX]Vice svetel v shaderu? Odpovědět s citátem

Cau, mel bych tu jeden dotaz - jak resite kdyz chcete do sceny zakomponovat vice svetel(idealne jeste ruznych typu) a pouzivate u toho shadery?

jsem ted zkousel neco takovehleho
kód:
struct Vertex2Pixel
{
...
      int      LCount : TEXCOORD3;
      float4   aLightDir[8] : TEXCOORD4;
...
};
jenze s tim me posle fxc nekam:
error X4502: invalid output semantic 'TEXCOORD4': Legal indices are in [0,7]

vychazim tudiz z toho ze nelze predavat pole timhle zpusobem.
Dal je tu moznost nasobit vsechny vektory*TBN az v pixel shaderu (ted to mam ve VS) - jenze tipuju ze to bude pomaly a navic mi to prijde tak trosku prasarna (pokud teda neexistuje lepsi zpusob).

Jak to resite vy?

Videl jsem uz hodne zajimavych zpusobu - cpat vsechno do matice float4x4 - coz by davalo maximalne 4 svetla (ale mohl bych natvrdo udelat treba 2 matice). Nebo pripadne mit vsechna svetla natvrdo, to mi prijde jako jeste vetsi prasarna, navic by se s tim blbe operovalo... Poradite teda neco?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky Yahoo Messenger MSN Messenger
Khaj



Založen: 16. 01. 2008
Příspěvky: 49

PříspěvekZaslal: 2. listopad 2008, 21:19:12    Předmět: Odpovědět s citátem

Prvni moznosti je zkusit (vertex) konstanty, tam muzes mit pole.
V pixel shaderu to delat muzes, a kdyz nekdy budes chtit mit bump mapping nebo offset mappting, bdes dokonce i muset Smile.

A konecne cesta, kterou se ubiram ja: nastav blending na scitani a kresli to po jednom svetle porad dokola cely - mam dojem ze se tomu rika multipass rendering (a ma tu vyhodu, ze shader zbytecne neosvetluje temnejma nevyuzitejma svetlama a ze jich muzes mit neomezene).

Rozliseni o jaky svetlo se jedna delam taky v shaderu, a to podle vektoru - nulovej znamena ambient (delam to v pixel shaderu, takze predavam jen vektor od svetla k pixelu, to jestli je to smerovy nebo bodovy resim pro zmenu ve vertex shaderu).

Google az se budes nudit: deffered rendering/shading. (tohle fakt nepotrebujes, uvadim jen pro zajimavost)

At se ti dari!
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
SUK



Založen: 14. 11. 2007
Příspěvky: 93
Bydliště: /dev/null

PříspěvekZaslal: 2. listopad 2008, 21:56:01    Předmět: Odpovědět s citátem

Oh, diky za rychlou odpoved Smile

Bump mapping tam mam, ale prave jenom pro jedno svetlo - matice nasobim v VS, v PS uz pouze dopocitavam svetla. Ale nasobit to vsechno v PS mi prijde prave divny...

Multipass render me taky napadl - ale hned potom ta horsi vec - co rychlost? Pro osum svetel se scena renderuje 8x - to snad nemuze bejt rychly!
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky Yahoo Messenger MSN Messenger
Augi



Založen: 28. 07. 2007
Příspěvky: 782
Bydliště: Čerčany

PříspěvekZaslal: 2. listopad 2008, 22:21:06    Předmět: Odpovědět s citátem

V případě osmi světel (kór pixelovejch) bych se už určitě zkusil poohlídnout po tom deffered renderingu.

Jinak další zajímavej přístup k řešení Tvého problému by mohlo být to, napsat si to v nějakém über-shaderu. To zjednodušeně řečeno znamená předgenerovat si všechny možný varianty shaderů pro všechny kombinace typů a počtů světel.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 3. listopad 2008, 01:32:52    Předmět: Re: [DX]Vice svetel v shaderu? Odpovědět s citátem

SUK napsal:
jsem ted zkousel neco takovehleho
kód:
struct Vertex2Pixel
{
...
      int      LCount : TEXCOORD3;
      float4   aLightDir[8] : TEXCOORD4;
...
};
jenze s tim me posle fxc nekam:
error X4502: invalid output semantic 'TEXCOORD4': Legal indices are in [0,7]

Není dost výstupních registrů z vertex shaderu (interpolátorů), typicky máš přístupný 1x pozici, 2x barva (může mít menší přesnost interpolace), 8x volitelný atributy (koordináty). TEXCOORD4 indexuje od 5. pozice, takže můžeš použít pouze float4[4].

SUK napsal:
Videl jsem uz hodne zajimavych zpusobu - cpat vsechno do matice float4x4 - coz by davalo maximalne 4 svetla (ale mohl bych natvrdo udelat treba 2 matice).

To je blbost. Při interpolaci závisí na počtu bajtů, takže float4[4] = float4x4.

Khaj napsal:
V pixel shaderu to delat muzes, a kdyz nekdy budes chtit mit bump mapping nebo offset mappting, bdes dokonce i muset Smile.

Offset mapping nemá s TBN a se světly nic společného. Při bump mappingu může násobit TBN maticí ve vertex shaderu, je to rychlejší. Pracovat s TBN v pixel shaderu se musí pouze při kombinaci s odrazy (odrážíš skybox třeba). Jsou tam pak ještě další komplikace, ale to už je jiná pohádka.

Teď k diskutovaným metodám.
1) Deferred rendering je docela zajímavá volba, ale není tak triviální, musí se tam řešit jiné optimalizace než při forward renderingu (to je ten "klasický" rendering). Průhlednost se tam dělá hodně blbě, rozhodně to není jen o tom zapnout blending... Rozmysli si, jestli stojí za to si užít tyto komplikace.
2) Multipass je dobrá cesta, do těch osmi světel se to dá ustát. Je potřeba akorát provádět agresivní culling. Postup by mohl být následující:
- vyřadit všechny světla, jejichž působnost není v pohledu kamery
- pro každej objekt vyřadit ty světla, které na něj nedosáhnou
- každé světlo uzavřít do 6 ořezávacích rovin (znamé jako "user-defined clip planes") ve tvaru krychle, tím už na úrovni trojúhelníků vyřadíš část modelu, kde světlo rozhodně nedopadne, kus modelu to doslova odřízne
- uzavřít světlo pomocí scissor testu, což definuje ve viewportu obdélníkový výřez a všechno mimo se nebude počítat, celkem jednoduchá myšlenka, ale implementace už dá zabrat - perspektivní projekce koule (=světla) může dát ve 2D buď elipsu nebo parabolu (při průřezu), jestli to dá i hyperbolu už si nepamatuju, popsáno tady
- A) pokud nemáme hardwarový "if" v pixel shaderu, můžeme za něj jako náhradu využít early-stencil test, popsáno v Radeon SDK March 2006 (dříve ATI SDK), vyřazuje doslova po pixelech, kde světlo nedopadne
- B) pokud máme hardwarový "if", můžeme prostě v pixel shaderu podmínkou vyřadit všechny výpočty kolem světel, vyřazovat se vyplatí všechno - zbylé pixely mimo radius světla, odvrácené pixely, pixely ve stínu apod.
Ve scéně můžeš mít klidně 100 světel, pokud na jeden objekt dopadne zároveň třeba max. 5. Pak aplikuješ optimalizace popsané výše, kde se většinou podaří vyřadit všechny neosvětlené pixely. Pokud je geometrický výkon hodně velká brzda, zjednodušit geometrii nebo počítat v shaderu 1-3 světla naráz (víc tam asi stejně neprotlačíš, hlavně na SM2.0 budeš mít problém, aby se ti tam vůbec vlezlo jedno světlo se stíny).
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Augi



Založen: 28. 07. 2007
Příspěvky: 782
Bydliště: Čerčany

PříspěvekZaslal: 3. listopad 2008, 09:01:12    Předmět: Re: [DX]Vice svetel v shaderu? Odpovědět s citátem

Eosie napsal:
Ve scéně můžeš mít klidně 100 světel, pokud na jeden objekt dopadne zároveň třeba max. 5.
Jo, tohle je dobrá poznámka. Pomocí optimalizací, které popsal Eosie, si můžeš např. říct, že jeden objekt bude osvětlen max. osmi světly - pak prostě vybereš pro každý objekt ta světla, která mají největší vliv na osvětlení daného objektu (typicky řízené vzdáleností světla a objektu a intenzitou světla). A jak Eosie říkal, osm světel není s dnešním HW problém...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
SUK



Založen: 14. 11. 2007
Příspěvky: 93
Bydliště: /dev/null

PříspěvekZaslal: 3. listopad 2008, 22:37:10    Předmět: Odpovědět s citátem

diky, diky diky Smile jsem zvedav jak tohle dam s mejma znalostma dohromady Very Happy

btw, co se multipass tyce - neslo by to vyresit treba tim, ze bych jeden pass opakoval tolikrat kolik je potrebnejch svetel, a vzdycky pred dalsim cyklem jenom nastavil do shaderu potrebny veci?

btw jak si predstavit HW if? (neco malo zkusenosti s mikroprocesorama mam, takze tusim jak asi vypadada hardware-neco, ale zkousel jsem mit v PS normalne if(neco) a fungovalo to..)

no, ale jeste jednou diky ... snad to nakonec nebude tak slozity, budou to prevazne staticky objekty.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky Yahoo Messenger MSN Messenger
ladik-BigBoss



Založen: 28. 07. 2007
Příspěvky: 162

PříspěvekZaslal: 4. listopad 2008, 13:11:09    Předmět: Odpovědět s citátem

v HW na jednoduchy if se pouziva multiplexor (mux)
http://en.wikipedia.org/wiki/Multiplexer

ale na programovatelnem HW je to pres podminenou skokovou instrukci.
principielne tedy 'if' v shaderu na GPU je stejny jako 'if' na CPU. proste se zpracuje vyraz a skoci se v programu... to jak uz je navrzeny obvod, ktery to skakani realizuje a jaky to ma vliv na SIMD je vec druha... rozhodne to musi ridit nejaky FSM
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovi WWW stránky
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 4. listopad 2008, 21:24:19    Předmět: Odpovědět s citátem

No hardwarový if (spíš se tomu říká dynamické větvení) na GPU funguje trochu jinak, ukážu to na pixel shaderu, kde to je nejvíc potřeba. U vertex shaderu se bez toho většinou obejdeme.

Když nemáme dynamické větvení kódu, provede se vždy větev THEN i ELSE po sobě a výsledky se zpracují tak, aby ta větev, která se neměla provádět, neovlivnila hodnoty proměnných.

U pixel shaderů od SM3.0 se definují kernely, což jsou bloky např. po 4x4 nebo 16x16 pixelech. Když se podmíněný výraz v podmínce vyhodnotí na všech pixelech v kernelu jako true nebo na všech false, provede se pouze jedna větev. Pokud některé pixely v bloku dávají true a jiné false, musí se provést obě větve jako předtím.

"if" na GPU tedy vůbec není stejně rychlý jak na CPU, ale díky vysokému paralelismu se s tím dá žít. Pak je tu ještě další problém a to ten, že některé SM3.0 GPU umí skákat v kódu pouze dopředu, takže na for cykly, které shader compiler neumí rozvinout, zapomeňte.
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> 3D API / 3D Enginy Časy uváděny v GMT + 1 hodina
Strana 1 z 1

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna