Kapitola 8 bohužel obsahuje obrovské množství faktických chyb. Například:
- Softwarové renderery nemusí nutně používat popsaný princip photon mappingu, ve skutečnosti prakticky všechny kromě Mental Raye používají něco úplně jiného. Photon mapping sám o sobě je docela nepraktická a překonaná věc, ostatní metody jsou většinou rychlejší a přesnější.
- Fotony neztrácejí intenzitu (resp. můžou, ale pak to vůbec nefunguje). Místo toho, aby na povrchu s 50% šedé se fotony odrazily s poloviční energií, se použije ruská ruleta - 50% se jich zabije (už neodrazí)
- Fotony neztrácejí intenzitu se vzdáleností, protože radiance se šíří v tradičním modelu v prostředí beze změny. Útlum světel je z geometrických důvodů (čím jsme dál od světla, tím míň jeho fotonů dopadne zrovna na náš povrch/snímač/...)
- Ray tracing (píše se zvlášť ;)) neoznačuje jen tuto metodu. Tahle metoda je teoreticky nezávislá na způsobu hledání průsečíků. Photon mapping jde naimplementovat i v rasterizéru.
- Ray tracing nevytváří žádné body nikde, kde dopadne paprsek. Photon mapping nemá žádné "větší paprsky" - vždy se používají jen a pouze nekonečně tenké paprsky, to co se interpoluje jsou vzniklé fotony.
- Měkký dojem ze scény je díky přítomnosti globálního osvětlení, photon mapping jen snižuje vysokofrekvenční šum.
- LightTrace jsem nikdy neslyšel. GI je třída algoritmů, ne jen nějaký konkrétní.
- Photon mapping který zvládá malé detaily existuje (progressive photon mapping)
- Paprsky z kamery se používají vždy (jediná metoda, kde by nebyly, light tracing bez next event estimation, jsem nikdy neviděl, byl by tak neefektivní, že by se nedal použít nikde). Final gathering neeliminuje žádné paprsky, naopak obrovským způsobem zvyšuje potřebný počet (tisícinásobně). Stejně tak final gathering nedokresluje pouze detaily, používá se globálně pro vše.
- IrradianceMap (správně Irradiance caching) je něco úplně jiného a nezávislého na photon mappingu.
- Zdroje světla se samozřejmě účastní výpočtu FG (aspoň teda v lepších implementacích používajících Multiple Importance Sampling ;))
- Ambient Occlusion nemůže nastoupit po výpočtu GI, ale před, protože jde o modulování textury. Navíc je redundantní a vede v kombinaci s GI na nekorektní výsledek (do kterého jsou měkké stíny započítány dvakrát). Používá se maximálně jako umělecký prostředek.
- "Fyzikální" rendery nejsou žádnou zvláštní kapitolou. Neumí skoro nic navíc, je to spíš reklamní trik, jak přesvědčit uživatele, že to, že jsou 10krát pomalejší, je výhoda, a ne nevýhoda. Všechny renderery principiálně vycházejí ze stejného modelu přenosu světla a v limitě dávají stejný výsledek, maximálně některé ten model rozšiřují o další jevy.
- Vlnovou povahu světla využívají všechny renderery, ne jen "Fyzikální"
- Kaustiku "fyzikální" renderery naopak moc nezvládají, protože se nejlíp (rychle) dělá pomocí fotonů.
- Nechápu zmínku o vertex weight. To je docela náhodná vlastnost materiálu v modeláři, nevím co dělá v článku o algoritmech a principech.
PPM je konzistentní, takže v limitě konverguje do stejného výsledku jako všechny unbiased algoritmy (dokáže zohlednit detaily kvůli snižování poloměru interpolace). Problém je jen pomalejší míra konzistence.
Do vlnové povahy světla spadá například i lom a fresnelovy rovnice pro odraz, takže ano, používají ji všechny renderery ;). Naopak třeba difrakce a intereference se běžně nesimuluje nikde. V běžném provozu to má zanedbatelný efekt, takže to nestojí za obrovský overhead, a jako umělecký prostředek je to nepoužitelný, protože uživatel nechce zadávat tloušťku vrstev v nanometrech, ale chce aby se objekt lesknul jak CDčko. Tak si to místo simulace nafakeuje.
Klasické renderery nepoužívají žádné "berličky" - všechny běžně používané algoritmy konvergují za nekonečný čas do stejného výsledku, jediný rozdíl je, že unbiased metodám stačí konečná paměť. Takže jaké berličky? Co by to mělo znamenat? Musím uznat, že pracuje dokonale marketing Maxwellu/fryrenderu - grafikům nevadí 10násobné render časy, a mají pocit, že dostávají něco navíc z metod, které jsou běžně naimplementované úplně stejně ve Vray/mental ray, ale nikdo je tam nepoužívá, protože jsou moc pomalé. Pamatuju moje zděšení, když moje první iterace implementace path tracingu (napsaná za 2 dny) totálně roztrhala fryrender. Dohnat normální renderery se mi ale dodnes pořádně nepodařilo ;).
Nevidím nic, co by mělo ulehčit život rendereru na vertex weight - prostě spočítám shading obou materiálů a LERPnu to podle váhy. Je to spíš čistě umělecký prostředek (běžně implementovaný i v archirendererech, jako je vray)
---
Naprosto chápu, že to má být jen naťuknutí problematiky, ale neznamená, že to musí být plné chyb a nepřesností ;).
Nejvíce přínosné komentáře
- Softwarové renderery nemusí nutně používat popsaný princip photon mappingu, ve skutečnosti prakticky všechny kromě Mental Raye používají něco úplně jiného. Photon mapping sám o sobě je docela nepraktická a překonaná věc, ostatní metody jsou většinou rychlejší a přesnější.
- Fotony neztrácejí intenzitu (resp. můžou, ale pak to vůbec nefunguje). Místo toho, aby na povrchu s 50% šedé se fotony odrazily s poloviční energií, se použije ruská ruleta - 50% se jich zabije (už neodrazí)
- Fotony neztrácejí intenzitu se vzdáleností, protože radiance se šíří v tradičním modelu v prostředí beze změny. Útlum světel je z geometrických důvodů (čím jsme dál od světla, tím míň jeho fotonů dopadne zrovna na náš povrch/snímač/...)
- Ray tracing (píše se zvlášť ;)) neoznačuje jen tuto metodu. Tahle metoda je teoreticky nezávislá na způsobu hledání průsečíků. Photon mapping jde naimplementovat i v rasterizéru.
- Ray tracing nevytváří žádné body nikde, kde dopadne paprsek. Photon mapping nemá žádné "větší paprsky" - vždy se používají jen a pouze nekonečně tenké paprsky, to co se interpoluje jsou vzniklé fotony.
- Měkký dojem ze scény je díky přítomnosti globálního osvětlení, photon mapping jen snižuje vysokofrekvenční šum.
- LightTrace jsem nikdy neslyšel. GI je třída algoritmů, ne jen nějaký konkrétní.
- Photon mapping který zvládá malé detaily existuje (progressive photon mapping)
- Paprsky z kamery se používají vždy (jediná metoda, kde by nebyly, light tracing bez next event estimation, jsem nikdy neviděl, byl by tak neefektivní, že by se nedal použít nikde). Final gathering neeliminuje žádné paprsky, naopak obrovským způsobem zvyšuje potřebný počet (tisícinásobně). Stejně tak final gathering nedokresluje pouze detaily, používá se globálně pro vše.
- IrradianceMap (správně Irradiance caching) je něco úplně jiného a nezávislého na photon mappingu.
- Zdroje světla se samozřejmě účastní výpočtu FG (aspoň teda v lepších implementacích používajících Multiple Importance Sampling ;))
- Ambient Occlusion nemůže nastoupit po výpočtu GI, ale před, protože jde o modulování textury. Navíc je redundantní a vede v kombinaci s GI na nekorektní výsledek (do kterého jsou měkké stíny započítány dvakrát). Používá se maximálně jako umělecký prostředek.
- "Fyzikální" rendery nejsou žádnou zvláštní kapitolou. Neumí skoro nic navíc, je to spíš reklamní trik, jak přesvědčit uživatele, že to, že jsou 10krát pomalejší, je výhoda, a ne nevýhoda. Všechny renderery principiálně vycházejí ze stejného modelu přenosu světla a v limitě dávají stejný výsledek, maximálně některé ten model rozšiřují o další jevy.
- Vlnovou povahu světla využívají všechny renderery, ne jen "Fyzikální"
- Kaustiku "fyzikální" renderery naopak moc nezvládají, protože se nejlíp (rychle) dělá pomocí fotonů.
- Nechápu zmínku o vertex weight. To je docela náhodná vlastnost materiálu v modeláři, nevím co dělá v článku o algoritmech a principech.
- blury reflextion se píše blurry reflection
Celkově je celá kapitola pokus o popis jednoho algoritmu, jde vidět, že v tom autor dost plave, a snaží se splácat nějaký text, co bude dávat smysl. :/ Doporučil bych mu přečíst si třeba tohle: http://books.google.cz/books/about/Realistic_ray_tracing.html?id=ywOtPMpCcY8C&redir_esc=y ;)
Do vlnové povahy světla spadá například i lom a fresnelovy rovnice pro odraz, takže ano, používají ji všechny renderery ;). Naopak třeba difrakce a intereference se běžně nesimuluje nikde. V běžném provozu to má zanedbatelný efekt, takže to nestojí za obrovský overhead, a jako umělecký prostředek je to nepoužitelný, protože uživatel nechce zadávat tloušťku vrstev v nanometrech, ale chce aby se objekt lesknul jak CDčko. Tak si to místo simulace nafakeuje.
Klasické renderery nepoužívají žádné "berličky" - všechny běžně používané algoritmy konvergují za nekonečný čas do stejného výsledku, jediný rozdíl je, že unbiased metodám stačí konečná paměť. Takže jaké berličky? Co by to mělo znamenat? Musím uznat, že pracuje dokonale marketing Maxwellu/fryrenderu - grafikům nevadí 10násobné render časy, a mají pocit, že dostávají něco navíc z metod, které jsou běžně naimplementované úplně stejně ve Vray/mental ray, ale nikdo je tam nepoužívá, protože jsou moc pomalé. Pamatuju moje zděšení, když moje první iterace implementace path tracingu (napsaná za 2 dny) totálně roztrhala fryrender. Dohnat normální renderery se mi ale dodnes pořádně nepodařilo ;).
Nevidím nic, co by mělo ulehčit život rendereru na vertex weight - prostě spočítám shading obou materiálů a LERPnu to podle váhy. Je to spíš čistě umělecký prostředek (běžně implementovaný i v archirendererech, jako je vray)
---
Naprosto chápu, že to má být jen naťuknutí problematiky, ale neznamená, že to musí být plné chyb a nepřesností ;).