Světla - model space vs. view space

[perry]

Je nějaký rozdíl, zda se světla počítají v model (world) space nebo ve model-view space ?
Přijde mi, že počítat T-1 (world * view) je pomalejší (o to násobení), než přímo použít T-1(world)... ale ve většině článků se počítá s T-1 (world * view).

Díky za vysvětlení..
_________________
Perry.cz

[Marek]

Je to jedno. V praxi závisí na okolnostech, v jakých se nacházíš. Některý techniky se líp dělaj v tangent space, jiný v object space, jiný zas ve world space a někdy je snažší to počítat rovnou ve view space. Jde o to, co se ti líp dělá a co je pro tvůj grafickej algoritmus nejpřirozenější.
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

Nejpřirozenější je počítat vše ve screen-space.

Jednodušeji řečeno nějaký "deferred shading"-like algoritmus je jedno z nejlepších řešení. V případě že chceš hodně světel (a případně hodně stínovacích modelů s jistými úpravami).

Samozřejmě co psal eosie je pravda, záleží na okolnostech.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]

[nou]

no trochu otazny je world space kde moze nastat problem s presnostou.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[perry]

Jo.. na deferred shading jsem právě začal dělat, tak jsem se ptal Přijde mi to docela pěkný a jednoduchý
_________________
Perry.cz

[Vilem Otte]

#perry - neboj, za chvíli tě to přejde, asi tak ve chvíli, kdy budeš chtít dělat více typů osvětlení (na plast je dobrý Blinn/Phong + Lambert, jinde zase Cook-Torrance a Oren-Nayar je nezbytností, nedej bože pokoušet se o subsurface scattering, ten může být trochu "nightmarish").

Když se přes to dostaneš (použiješ třeba jen Blinn/Phong + Lambert; v jiných případech se vše stává mnohem náročnější), začneš chtít poloprůhledné materiály (samozřejmě alfa-test jde udělat relativně snadno) a je tu další obří problém (který lze vyřešit nejsnáze snad stipplingem), samozřejmě jsou tu i mnohem lepší řešení (a časově mnohem náročnější) - jako prolínat deferred rendering a realtime ray tracing (což je způsob jak do DS přidat reflekce, refrakce (=průhlednost), GI (ne nějaký pseudo-oser jako má Cryengine 3, nebo SSAO), a další).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]

Jsem si myslel, že stippling dneska už nikdo nepoužívá.
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

Já raději použiju ray tracer (při oknech, apod.) či alfa test (s sample alpha to coverage) pro listy, stébla trávy, apod.

Nicméně co jsem slyšel, tak stippling pro alpha blend v DS se používá - samozřejmě v úrovni sub-pixelů (ale může vyústit v aliasing míst, kde je použitý). Afaik např. Dice ho myslím používají.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[perry]

No.. chápu to dobře, že deferred shading se běžně používá, že to není nějaká zastaralá technika (jasně, za chvíli klidně bude)...

Jinak zatím teda pracuju na základní verzi (1 materiál, žádný bum ani paralax mapping, normály tím pádem jen ve vrcholech) s phongovým modelem...
_________________
Perry.cz

[Vilem Otte]

#perry - vlastně nebude, pokud by ses podíval na jádro mého realtime raytraceru (ve chvíli kdy běží v módu čistého ray tracingu) tak bys viděl, že raytracing svým způsobem má blíže k deferred rendereru než forward rendereru.
A tím myslím i komerční offline raytracery (zejména photon mappery, ale také path traceru, MLT renderery, etc.).

I forward rendering je však někde velmi výhodný, záleží na situaci (např. při směrových světlech je deferred shading velmi náročný a forward rendering jej výkonově i vlastnostmi světla lehce porazí).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[perry]

No tak směrové světlo mám 1 / scéna (Slunce) a pak tam mam jako zdroje částicové efekty (oheň apod) + lampy atd.. takže tohle počítat ve forwardu mi přijde jako zabiják (+ stíny do toho)
_________________
Perry.cz

[Vilem Otte]

Mno, s forwardem je to o něco těžší - musel bys postavit hierarchii pro světla a přiřazovat modelům jen ty, které je osvětlují s nějakým stropem, řekněme 4 světla na objekt.

Deferred tohle trošku usnadní (a výpočtem pak může být mnohem rychlejší), jediné v čem tě bude štvát je jak moc zabere fillrate (oproti forward), ale i forward něco zabere a pokud počítáš SSAO či podobnou šílenost, tak zjistíš, že na tom vlastně nakonec vyděláš.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[perry]

Nechce se mi zakládat nový topic kvůli jedné otázce... Jak řešit rekonstrukci pozice z gBufferu...
Několik možností mě napadá
a) ukládat depth do textury (třeba R32F nebo A8R8G8B8) a pak rekonstrukce pomocí view vectoru z rohů quadu, který se v PS interpoluje jako texcoord (tak to mám teď podle implementace z tutoriálu)
b) uložit přímo pozici xyz do 64bit textury
c) 3 textury pro x,y,z (asi nejhorší)
_________________
Perry.cz

[pcmaster]

Rozhodne a Cokolvek ine je blbost a strata pamati (a bandwidth. Samozrejme, mozu byt pripady, ked ti to nevadi!). Nakresli si to na papier, uvidis, ze z field of view (ci focal lenght) a rozlisenia, pripadne z inverznej projekcnej matice (a pripadne inverznej pohladovej, podla potreby a toho, co za "Z" si ulozis) v pixel shaderi lahko spocitas polohu v kazdom priestore, vratane world-space. A ano, pekne budes interpolovat polohu v tom FS quade, ale to ostatne budes musiet tak ci tak pre rozne ine veci, vsakze. Podobne s normalami.
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.