Photonmapping - Wie kann man gleichmäßig helle Wände erzeugen?

schaut sehr gut aus, haette nicht gedacht dass du das so gut hinbekommst nach dem thread start

was genau ist die global lighting? die fireflies dort schauen aus als ob das eigentlich path tracing waere.

XMAMan

Bei GlobalLighting gehe ich wie bei PathTracing auch von einen Strahl, der von der Kamera startet in Richtung Szene und reflektiere dann immer wieder Diffuse. An jeden Punkt wo ich Auftreffe berechne ich, wie viel Licht direkt von allen Lichtquellen dahin scheinen. Ich benutze dafür den SolidAngle(Raumwinkel). Mit der BRDF-Funktion berechne ich dann, wie viel von der einstrahlenden Energie in die Richtung strahlt, aus der der Strahl kam.

Ich berechne mehrere solcher Lichtstrahlpfade und bilde daraus dann den Durchschnitt. Wenn ich zu wenig Samples nehme, dann kommt es halt zu einzelnen hellen Pixeln auf einer Wand.

XMAMan

So hier ist nun mein China-Raum^^

http://www.m-i-u.de/images-i90501bamlef.jpg

Ich habe das Ding jetzt erstmal mit PathTracing gerendert. Das hat übelst lange gedauert. Mir gings hier diesmal um eine Scene, wo vie indirektes Licht und Glasobjekte sind.

Mit Photonmapping geht das Rendern zum Glück dann schneller.

rapso

eine schoene szene. Bin gespannt wie es mit photonmapping ausschaut. wie lange hast du dran gepathtraced? rechnest du dir mit photonmapping lightmaps aus oder renderst du einzelbilder? (deine anfaenge sahen nach lightmaps aus)

du solltest irgendwo noch etwas platzieren was stark reflektiert und etwas, was refraktiert, im light natuerlich, das ist eine der staerken von photonmapping. Mit path tracing wirst du da recht lange rendern bis sowas konvergiert.

irgendwas an der texturierung am boden stimmt nicht. sicher dass dein filter richtig funktioniert? hast du ausreichend primary rays? (der glassscheibe nach sieht es zwar danach aus, das texture filtering sagt aber das gegenteil).

XMAMan

rapso schrieb:

eine schoene szene. Bin gespannt wie es mit photonmapping ausschaut. wie lange hast du dran gepathtraced?

rechnest du dir mit photonmapping lightmaps aus oder renderst du einzelbilder? (deine anfaenge sahen nach lightmaps aus)

du solltest irgendwo noch etwas platzieren was stark reflektiert und etwas, was refraktiert, im light natuerlich, das ist eine der staerken von photonmapping. Mit path tracing wirst du da recht lange rendern bis sowas konvergiert.

irgendwas an der texturierung am boden stimmt nicht. sicher dass dein filter richtig funktioniert? hast du ausreichend primary rays? (der glassscheibe nach sieht es zwar danach aus, das texture filtering sagt aber das gegenteil).

Ich habe 44 Tage fürs rendern gebraucht. Pro Pixel habe ich 30.000 Strahlen ausgesendet.

Natürlich speicher ich die ausgesendeten Photonen in einer Lightmap. Wie meinst du das mit Einzelbilder rendern? Das jedes Pixel seine eigene Photonmap hat?

Als nächstes will ich ein Schachbrett mit Glasfiguren rendern. Dort wird es dann farbige Kaustiken geben. Dort kann Photonmapping dann mal zeigen was es kann.

Wenn ich die Szene mit DirectX oder OpenGL render, dann sehen die Texturen genauso aus. Wenn da also ein Fehler ist, dann wohl eher in mein UV-Koordinaten oder den Bilddaten an sich.

rapso

XMAMan schrieb:

Ich habe 44 Tage fürs rendern gebraucht.

was fuer einen rechner nutzt du dafuer?

ich erinnere mich an meinen ersten lightmapper, hab dafuer 3 high end "Pentium 90" bekommen. hab die angeworfen und bin dann 2 wochen in den urlaub gegangen als ich wiederkam waren die bei <50% fertig

30.000 ist natuerlich eine ZAHL

Natürlich speicher ich die ausgesendeten Photonen in einer Lightmap. Wie meinst du das mit Einzelbilder rendern? Das jedes Pixel seine eigene Photonmap hat?

ohne dass du sie abspeicherst, einfach nur das bild rendern. wie man es fuer filme macht.

Als nächstes will ich ein Schachbrett mit Glasfiguren rendern. Dort wird es dann farbige Kaustiken geben. Dort kann Photonmapping dann mal zeigen was es kann.

ich hoffe es liegt auf dem tisch in der jetztigen szene, die ist echt nett

Wenn ich die Szene mit DirectX oder OpenGL render, dann sehen die Texturen genauso aus. Wenn da also ein Fehler ist, dann wohl eher in mein UV-Koordinaten oder den Bilddaten an sich.

das vorhin war vom handy aus
jetzt auf dem grossen screen sehe ich dass du auch unmengen von aliasing hast.
ich vermute mal du verwendest kein mipmapping und daher dein aliasing auch bei den texturen.
beim pathtracing kannst du beide probleme loesen, indem du bei jedem der 30k strahlen pro sample einen ganz kleinen offset (subpixel) machst. entweder random oder halt ein grid. ist ja sonst schade um die 30k strahlen wenn du am ende doch noch aliasing hast.

XMAMan

Darf ich vorstellen: Das angekündigte Schachbild:

http://www.imageupload.co.uk/images/2014/12/16/Schachbild.jpg

volkard

XMAMan schrieb:

Darf ich vorstellen: Das angekündigte Schachbild:
http://www.imageupload.co.uk/images/2014/12/16/Schachbild.jpg

geil!

rapso

schaut gut aus, du hast vergessen zu verraten wie lange du diesmal gebraucht hast?

und nun fix das anti aliasing und texture filtering

wenn du die qualitaet verbessern moechtest, solltest du als naechstes realistischerere materialien implementieren. dann bist du bei photorealismus.

wir sollten hier ein weihnachts raytracing jam machen

otze

ist das ein anzeigefehler, ein fehler in meiner sichtmatrix oder sind an den Kanten der Schachfiguren wirklich so störende rauschpixel?

Ansonsten natürlich fette Oberklasse

XMAMan

Die Renderzeit war diesmal beim PathTracing 20 Tage.

Die nächsten Schritte sollen diesmal wirklich Anti aliasing, Textur-Filterung und Normalmapping für feine Holzunebenheiten sein.

@Otze: Das mit den Störpixeln hab ich noch nicht so ganz verstanden warum die sind. Ich habe aber ausversehen die Figuren mit Flatshading gerendert. Dadurch sind sie unnötig eckiger. Ich werde das mal auf Pongshading umstellen, um zu sehen, was dann rauskommt.

Eine Sache, wo ich noch ein Tipp brauche: Ich möchte eine Staubfluse ganz vorne noch hinlegen. Habt ihr eine Idee, wie man sowas machen könnte?

Was mich auch interessieren würde ist, wie man einen Wollfaden/ Wollsocke Raytraced.

rapso

XMAMan schrieb:

... Normalmapping ...

vorsicht, normalmapping ist nicht energie konservierend und kann zu fehlern fuehren.

Das mit den Störpixeln hab ich noch nicht so ganz verstanden warum die sind.

weil strahlen sehr sehr sehr unwahrscheinliche pfade verfolgten, bei der normalisierung sorgen diese seltenen pfade dann zu sehr hellen pixeln. das passiert im besonderen wenn eine diffuse reflection stattfindet die dann auf eine spekulare reflektion trifft und diese dann die lichtquelle trifft. Es ist kein fehler und wenn du lang genug wartest, geht es auch weg.

Eine Sache, wo ich noch ein Tipp brauche: Ich möchte eine Staubfluse ganz vorne noch hinlegen. Habt ihr eine Idee, wie man sowas machen könnte?

waere vermutlich am einfachsten wenn du es als volume ansiehst mit unregelmaessiger verteilung. quasi ein kleiner nebel der sehr durchsichtige und sehr dichte stellen hat.
"participating media" waere dein stichwort.

Was mich auch interessieren würde ist, wie man einen Wollfaden/ Wollsocke Raytraced.

das haengt davon ab... manche wuerden nur ein mesh mit textur nutzen, auf dem anderen ende ist BTF und recht aufwendig.

wenn du einzelne tracen willst wird es richtig aufwendig

XMAMan

rapso schrieb:

XMAMan schrieb:

... Normalmapping ...

vorsicht, normalmapping ist nicht energie konservierend und kann zu fehlern fuehren.

Hast du eine Idee, wie ich das Holz ansonsten möglichst realistisch aussehen lassen kann? Das hat doch schließlich so ganz kleine unebenheiten. Ich hätte auch noch parallax-Mapping zu bieten. Nur funktioniert meine Engine momentan so, dass ich eine Textur als Input geben muss. Daraus berechne ich dann die Normal- und Höhenmap.

Wenn ich aber mit einer Textur arbeite, dann ist deren Auflösung begrenzt. Für so superkleine Unebenheiten, wie sie bei Holztischen nun mal da ist, reicht das glaube nicht. Ich denke eher ich muss hier mit prozeduralen Texturen arbeiten. Mein Holz(Höhen)muster muss also durch eine Formel berechnet werden. Ist der Ansatz so ok oder würdest du doch noch was anderes sagen?

rapso

XMAMan schrieb:

rapso schrieb:

XMAMan schrieb:

... Normalmapping ...

vorsicht, normalmapping ist nicht energie konservierend und kann zu fehlern fuehren.

Hast du eine Idee, wie ich das Holz ansonsten möglichst realistisch aussehen lassen kann? Das hat doch schließlich so ganz kleine unebenheiten.

das kommt wohl aufs holz an, bei einem schachbrett ist es ja eher glatt mit einer lack schickt, also normalreweise. Holz procedural ist nicht sehr schwer, aber es dauert bis man es sich zurecht getweakt hat.
workshop: http://developer.amd.com/wordpress/media/2012/10/RenderMonkey.pdf
http://tams-www.informatik.uni-hamburg.de/lehre/2004ss/vorlesung/medientechnik/material/JasonM_Shading.pdf
sourcen: http://developer.amd.com/wordpress/media/2012/10/ShadingCourse2004_HLSL.pdf

Ich hätte auch noch parallax-Mapping zu bieten. Nur funktioniert meine Engine momentan so, dass ich eine Textur als Input geben muss. Daraus berechne ich dann die Normal- und Höhenmap.

Wenn ich aber mit einer Textur arbeite, dann ist deren Auflösung begrenzt. Für so superkleine Unebenheiten, wie sie bei Holztischen nun mal da ist, reicht das glaube nicht. Ich denke eher ich muss hier mit prozeduralen Texturen arbeiten. Mein Holz(Höhen)muster muss also durch eine Formel berechnet werden. Ist der Ansatz so ok oder würdest du doch noch was anderes sagen?

das wichtigste dabei ist dass du dein antialiasing endlich einbaust ;), gerade procedurale dinge wirken oft grausam ohne weil bilinear filtering nicht sonderlich gut funktioniert und bei oversampling auch nicht viel bringt.

otze

rapso schrieb:

weil strahlen sehr sehr sehr unwahrscheinliche pfade verfolgten, bei der normalisierung sorgen diese seltenen pfade dann zu sehr hellen pixeln. das passiert im besonderen wenn eine diffuse reflection stattfindet die dann auf eine spekulare reflektion trifft und diese dann die lichtquelle trifft. Es ist kein fehler und wenn du lang genug wartest, geht es auch weg.

Alternativ einfach die kleinsten und größten 5% der Strahlen raus werfen und neu normalisieren.

rapso

otze schrieb:

rapso schrieb:

weil strahlen sehr sehr sehr unwahrscheinliche pfade verfolgten, bei der normalisierung sorgen diese seltenen pfade dann zu sehr hellen pixeln. das passiert im besonderen wenn eine diffuse reflection stattfindet die dann auf eine spekulare reflektion trifft und diese dann die lichtquelle trifft. Es ist kein fehler und wenn du lang genug wartest, geht es auch weg.

Alternativ einfach die kleinsten und größten 5% der Strahlen raus werfen und neu normalisieren.

ich sprach vom normalisieren aufgrund der wahrscheinlichkeiten beim monte carlo path tracing. wahrscheinlichkeiten hast du z.b. bei der abbruch bedingung, bei der berechnung der strahlrichtung. das "normalisieren" was du meinst verursacht ja keinen fehler.
wenn du es wirklich manipulieren moechtest und...
... du moechtest unbiased bleiben, dann musst du die wahrscheinlichkeitsverteilung aendern. (ist aber nicht trivial so allen 'fireflies' auf die schliche zu kommen)
... du biased sein moechtest, kannst du statt 5% der strahlen wegzuwerfen, wo du nicht weisst ob 0.1% oder 10% invalide sind, eher 'clampen' (das ist auch was renderer im biased mode eher machen). das passt auch besser zur eigentlichen idee von path tracing, dass du mit unendlich viel zeit ein perfektes bild bekommst. unendlich viel strahlen kannst du nicht zwischenspeichern, deswegen summiert man es auf.

man kann sich aber mit sowas das bild versauen wenn man korrekte resultate haben moechte. es gibt ja komplexe caustic und die wahrscheinlichkeit soeinen pfad zu treffen sind sehr sehr klein, manchmal muss man millionen von samples machen und wenn man die 'manipuliert', kann es sein dass das resultat falsch ist oder dass es ploetzlich sehr viel laenger dauert, weil man den path tracer dazu 'ueberredet' hat diese seltenen 'firefly'-pfade eher nicht zu verfolgen.

der beste weg sowas korrekt zu loesen ist bisher 'metropolis light transport', aber so gut das auch bei komplexen pfaden wirkt, so kontraproduktiv kann es bei simplen shading sein.

ein klassisches beispiel ist http://www.cs.berkeley.edu/~sequin/CS184/IMGS/caustic_metalring.jpg
die caustics sehen am anfang aus wie fireflies und bei optimierungen gegen fireflies zerlegt es das bild oft.

otze

rapso schrieb:

ich sprach vom normalisieren aufgrund der wahrscheinlichkeiten beim monte carlo path tracing.

Ja,ich auch. Du nimmst alle PFade des punkts und anstatt zu mitteln, wirfst du einfach die outlier raus und mittelst dann. Ich hatte jetzt pauschal 5% gesagt und das ist natürlich nicht unbiased. folgendes ist unbiased:

Für N gezogene strahlwerte wirfst du g(N) raus wobei
$\lim_{N \rightarrow \infty} \frac N {g(N)} \rightarrow \infty$
wenn du über die verbleibenden N-g(N) strahlen mittelst, erhälst du im limit $N \rightarrow \infty$ einen unbiased estimator der für endliche N robust(im statistischen Sinne) ist. Natürlich musst du dann alle N pixelfarben im speicher behalten, aber das ist eher ein geringes Problem, weil N niemals wirklich groß ist. Dafür zerstört dir ein seltener pfad nicht einzelne Pixel.

rapso

otze schrieb:

rapso schrieb:

ich sprach vom normalisieren aufgrund der wahrscheinlichkeiten beim monte carlo path tracing.

Ja,ich auch. Du nimmst alle PFade des punkts und anstatt zu mitteln, wirfst du einfach die outlier raus und mittelst dann.

Es sind aber keine Outlier im mathematischen sinne, es sind seltene (oft caustic) pfade die aber, je nach bild, auch optisch wichtig sind.

Ich hatte jetzt pauschal 5% gesagt und das ist natürlich nicht unbiased. folgendes ist unbiased:

Für N gezogene strahlwerte wirfst du g(N) raus wobei
$\lim_{N \rightarrow \infty} \frac N {g(N)} \rightarrow \infty$
wenn du über die verbleibenden N-g(N) strahlen mittelst, erhälst du im limit $N \rightarrow \infty$ einen unbiased estimator der für endliche N robust(im statistischen Sinne) ist.

wenn das immer noch auf deine vorherige aussage bezogen ist bezueglich hellster pfade, dann ist das immer noch biased. um unbiased zu bleiben, musst du mit dem kriterium normalisieren mit dem du die pfade verwirfst. wirfst du also die hellsten raus, muestest du die verbleibenden anhand der resthelligkeit in relation zur vorherigen gesammthelligkeit normalisieren. damit waerst du dort wo du angefangen hast, jedoch haettest du dann noch die varianz gesteigert.

Entsprechend hat jeder unbiased path tracer die fireflies, auch VRay, Arnold usw.

otze

rapso schrieb:

Ja,ich auch. Du nimmst alle PFade des punkts und anstatt zu mitteln, wirfst du einfach die outlier raus und mittelst dann.

Es sind aber keine Outlier im mathematischen sinne, es sind seltene (oft caustic) pfade die aber, je nach bild, auch optisch wichtig sind.[/quote]
Wenn sie aber selbten sind, hast du ein Problem. Denn dann kannst du nicht garantieren, dass benachbarte Pixel eben jene seltene Pfade enthalten und damit kommt es zu artefakten im Bild. Auch wenn es natürlich mathematisch so richtig ist, haben wir niemals unendlich viele samples, also müssen wir schauen, womit wir leben können: Varianz, oder Bias. Und ein wenig Bias kann einem eine Menge Varianz ersparen. Die Fireflies sind ein Indikator dafür, dass die Varianz ein Problem ist und mehr Rechenzeit ist keine Option mehr. Es macht also Sinn, Varianz gegen Bias einzutauschen - solange die Konfidenzintervalle des biased Schätzers innerhalb derer des unbiased sitzen, haben wir gewonnen und einen objektiv besseren Schätzer (angenommen der unbiased shcätzer hat mittelwert 1 und varianz 10, dann ist ein biased Schätzer mit mittelwert 1.1 und Varianz 3 wesentlich besser, solange wir die Schätzung nicht wiederholen können).

wenn das immer noch auf deine vorherige aussage bezogen ist bezueglich hellster pfade, dann ist das immer noch biased.

Ja, dashabe ich geschrieben. Solange man nicht unendlich viele samples hat, ist das Verfahren biased. Aber der Bias wird auch mit steigendem N immer kleiner. Das Verfahren schneidet den Tail der Verteilung ab Und je mehr samples man nimmt, desto kleiner wird der Teil des Tails den man abschneidet, da g(N) langsamer steigt als N. Zum Beispiel mit g(N)=sqrt(N). Für N=100 wirfst du g(N)/N=10/100=10 der samples raus. mit N=10000 nur noch g(N)/N 100/10000=1%. Der Bias verringert sich dementsprechend. Andere Wahlen für g(N) wären zum Beispiel ceil(log(N)) (N=100 ->g(N)=5 und N=10000 ->g(N) = 10). Damit kann man dann experimentieren, je nachdem wie wahrscheinlich die fireflies sind.

rapso

otze schrieb:

rapso schrieb:

otze schrieb:

Ja,ich auch. Du nimmst alle PFade des punkts und anstatt zu mitteln, wirfst du einfach die outlier raus und mittelst dann.

Es sind aber keine Outlier im mathematischen sinne, es sind seltene (oft caustic) pfade die aber, je nach bild, auch optisch wichtig sind.

Wenn sie aber selbten sind, hast du ein Problem. Denn dann kannst du nicht garantieren, dass benachbarte Pixel eben jene seltene Pfade enthalten und damit kommt es zu artefakten im Bild. Auch wenn es natürlich mathematisch so richtig ist, haben wir niemals unendlich viele samples

das hast du gut erfasst/zusammengefasst, das ist die kehrseite von vanilla unbiased path tracern.

otze schrieb:

, also müssen wir schauen, womit wir leben können: Varianz, oder Bias. Und ein wenig Bias kann einem eine Menge Varianz ersparen. Die Fireflies sind ein Indikator dafür, dass die Varianz ein Problem ist und mehr Rechenzeit ist keine Option mehr.

per se ist das kein problemindikator und kein indikator, dass du unbiased aufgeben musst. es gibt viele wege einen vanilla path tracer um faktoren von 100x und 1000x auf einen schlag schneller zu machen ohne biased zu werden. es werden Filme mit riesen aufloesungen und fast rauschfrei gerendert (z.b mit Arnold) und die Beleuchtungskomplexitaet pro pixel schlaegt vermutlich was XMAMan fuers ganze bild hatte (ohne seine leistung damit abwerten zu wollen, aber ein es ist doch noch ein riesen schritt).

Es macht also Sinn, Varianz gegen Bias einzutauschen - solange die Konfidenzintervalle des biased Schätzers innerhalb derer des unbiased sitzen, haben wir gewonnen und einen objektiv besseren Schätzer (angenommen der unbiased shcätzer hat mittelwert 1 und varianz 10, dann ist ein biased Schätzer mit mittelwert 1.1 und Varianz 3 wesentlich besser, solange wir die Schätzung nicht wiederholen können).

es gib die einen die sinn sehen biased zu sein und die anderen die sinn sehen unbiased zu sein. beide haben ihre argumente und es kommt mir manchmal fast wie religion vor. die grossen path tracer haben einen unbiased mode. fuer preview sind biased nett, fuer final rendering bei sich annaehernder qualitaet nehmen sich biased vs unbiased dann nicht mehr viel. das was biased an 'optimierungen' auf den ersten metern bringt braucht dann laenger um ausgebuegelt zu werden um fehler zu vermeiden (z.b. wenn caustic doch sichtbar sein sollen).

wenn das immer noch auf deine vorherige aussage bezogen ist bezueglich hellster pfade, dann ist das immer noch biased.

Ja, dashabe ich geschrieben. Solange man nicht unendlich viele samples hat, ist das Verfahren biased. Aber der Bias wird auch mit steigendem N immer kleiner. Das Verfahren schneidet den Tail der Verteilung ab Und je mehr samples man nimmt, desto kleiner wird der Teil des Tails den man abschneidet, da g(N) langsamer steigt als N. Zum Beispiel mit g(N)=sqrt(N). Für N=100 wirfst du g(N)/N=10/100=10 der samples raus. mit N=10000 nur noch g(N)/N 100/10000=1%. Der Bias verringert sich dementsprechend. Andere Wahlen für g(N) wären zum Beispiel ceil(log(N)) (N=100 ->g(N)=5 und N=10000 ->g(N) = 10). Damit kann man dann experimentieren, je nachdem wie wahrscheinlich die fireflies sind.

ja, je kleiner der anteil den du rauswirfst, desto kleiner der bias. wenn du bei 0 ankommst bist du wieder unbiased. hat aber nicht mehr wirklich was damit du tun dass du etwas rauswerfen und trotzdem unbiased sein wolltest