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

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

otze

rapso schrieb:

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

Das habe ich genau wo geschrieben?

otze schrieb:

rapso schrieb:

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

Das habe ich genau wo geschrieben?

otze schrieb:

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.

und das ist eben nicht korrekt da es biased ist solange g(N)> 0 pfade. also selbst wenn du gegen unendlich gehst, und auch wenn g(N) statistisch gesehen unbedeutend klein gegenueber dem eigentlichen N ist, ist es biased. wenn du so willst, ist die bias 'funktion' f(x) binaer, entweder ist x==0 -> unbiased oder x!=0 -> biased und N/g(N) ist dabei unbedeutend, was zaehlt ist einzig ob g(N)==0.

otze

nein, bei N->inf ist es unbiased,zumindest solange du endliche Varianz annimmst. wir ziehen samples x_1,...x_N und entfernen die ersten x_1,...,x_g(N). Zur Vereinfachung nehme ich zusätzlich an, dass -C< x_i < C

$\frac 1 {N-g(N)} \sum_{i=g(N)+1}^N x\_i = \frac 1 {N-g(N)} \sum\_{i=1}^N x\_i- \frac 1 {N-g(N)} \sum\_{i=1}^{g(N)} x\_i = \frac N {N-g(N)} (\frac 1 N\sum\_{i=1}^N x\_i) - \frac 1 {N-g(N)} \sum\_{i=1}^{g(N)} x_i$

nun zum limit.Der erste Term:

\lim_{N \rightarrow \infty }\frac N {N-g(N)} (\frac 1 N\sum_{i=1}^N x_i) = [\lim_{N \rightarrow \infty }\frac N {N-g(N)}] \lim_{N \rightarrow \infty }\frac 1 N\sum_{i=1}^N x\_i = [\lim\_{N \rightarrow \infty }\frac 1 {1-g(N)/N}] E_{p(x)}\{x\}=E_{p(x)}\{x\}

der letzte Schritt gilt wegen g(N)/N->0

das der zweite Term gegen 0 geht braucht dann endliche Varianz oder ähnliches. Nach der zusätzlichen Annahme ist

$\lim_{N \rightarrow \infty } \frac 1 {N-g(N)} \sum_{i=1}^{g(N)} x\_i < \lim\_{N \rightarrow \infty } \frac{g(N)}{N-g(N)}C = 0$

rapso

ich glaube du vergisst dass N (bzw g(N), bzw die ganze gleichung) eine natuerliche zahl ist. entweder du hast alle strahlen oder, wenn 1 oder mehr entfernt wurden und du die restlichen nur mittelst, bist du biased.

deswegen sagte ich ja dass es eine binaer entscheidung ist.
entfernst du 0 strahlen ohne mit dem richtigen kriterium zu normalisieren (also mitteln) -> unbiased
entfernst du >0 strahlen ohne mit dem richtigen kriterium zu normalisieren (also mitteln) -> biased

edit:
stell es dir als grundsatz vor, wie bei division, du kannst gerne n gegen 0 gehen und dagegen teilen, aber du kannst nicht durch 0 teilen.

otze

rapso schrieb:

ich glaube du vergisst dass N (bzw g(N), bzw die ganze gleichung) eine natuerliche zahl ist. entweder du hast alle strahlen oder, wenn 1 oder mehr entfernt wurden und du die restlichen nur mittelst, bist du biased.

quatsch. Siehe konvergenz von Folgen sowie die Gesetze der großen Zahlen. Du kannst ja anfangen meinen Bweis zu widerlegen. Und nebenbei auch

http://en.wikipedia.org/wiki/Consistent_estimator

durchlesen(insbesondere den untersten abschnitt über konsistente Schätzer mit Bias). Das limitargument ist eigentlich ganz einfach zu verstehen: wenn der Schätzer biased ist, dann findest du ein epsilon > 0, sodass der Wert des Schätzers in Erwartung um mindestens epsilon abweicht. Der Beweis zeigt dass der Bias im limit gegen 0 geht und es deswegen dieses Epsilon nicht gibt. Dies verträgt sich aber nicht mit der Annahme, dass der Schätzer im limit biased ist.

rapso

otze schrieb:

rapso schrieb:

ich glaube du vergisst dass N (bzw g(N), bzw die ganze gleichung) eine natuerliche zahl ist. entweder du hast alle strahlen oder, wenn 1 oder mehr entfernt wurden und du die restlichen nur mittelst, bist du biased.

quatsch. Siehe konvergenz von Folgen sowie die Gesetze der großen Zahlen. Du kannst ja anfangen meinen Bweis zu widerlegen. Und nebenbei auch

http://en.wikipedia.org/wiki/Consistent_estimator

durchlesen(insbesondere den untersten abschnitt über konsistente Schätzer mit Bias). Das limitargument ist eigentlich ganz einfach zu verstehen: wenn der Schätzer biased ist, dann findest du ein epsilon > 0, sodass der Wert des Schätzers in Erwartung um mindestens epsilon abweicht. Der Beweis zeigt dass der Bias im limit gegen 0 geht und es deswegen dieses Epsilon nicht gibt. Dies verträgt sich aber nicht mit der Annahme, dass der Schätzer im limit biased ist.

achso, jetzt sehe ich dein versehen. consistence und bias sind verschiedene dinge. z.B. ist photonmapping consistent und liefert genau wie dein anstaz in der unendlichkeit das richtige resultat, dennoch ist es biased, genau wie deine idee solange du nicht mit dem attribut normalisierst mit dem du die paths verwirfst.

vielleicht verstehst du es mit formeln besser, es gilt dass
${a}'=\frac 1 {n} \sum_{i=0}^{n} S(1)$
und
${a}''=S(N)$
fuer
$n \in \mathbb{N}$
wenn S die sampling funktion ist, der parameter die path anzahl, statistisch
${a}' \equiv {a}''$

oder anders gesagt, wenn XNAMan jeden tag ein unbiased Bild mit X samples/Pixel rendert und sich das durschnittsbild bilded, kann er irgendwann aufhoeren wenn ihm die Bildqualitaet gefaellt ohne angst haben zu muessen, dass es einen fehler (ausgenommen des rauschens) gibt.
bei einem biased renderer muss er komplett X*N samples/Pixel rendern und kann dann das resultat betrachten und darf sich nicht gewiss sein, dass ein optisch ansprechendes Bild richtig ist, weil es sein kann dass bei X*(N+1) sich die bildinformation aendert (z.b. ein neuer stern am himmel zu sehen ist).

otze

der unterschied ist mir bekannt. deswegen sagte ich ja "im limit unbiased" was eine notwendige, aber keine hinreichende Bedingung für Konsistenz ist.

Aber ich glaub, wir sind jetzt beim selben Punkt, also passt das.

rapso

otze schrieb:

der unterschied ist mir bekannt. deswegen sagte ich ja "im limit unbiased" was eine notwendige, aber keine hinreichende Bedingung für Konsistenz ist.

ja, deswegen antwortete ich, es ist im limit wohl consistent, aber bleibt biased, sonst waere jeder consistent algorithmus unbiased.

Aber ich glaub, wir sind jetzt beim selben Punkt, also passt das.

ok

XMAMan

rapso schrieb:

gut job

solide dass du dich da so verbissen hast bis es gute resultate gibt!

das radiosity bild schaut nicht ganz richtig aus, als ob irgendwas mit texture mapping falsch waere.

wir wollen hier jetzt natuerlich deinen raum sehen mit photonmapping (und den anderen versionen falls du die muesse hast )

So rapso, du sagst, dass mein Radiosity noch nicht ganz ok ist? Ich habe den Algorithmus nun korrigiert. Ich bin jetzt wieder voll drin im Raytracing-Fiber^^ Hier ist nun mein neues Radiosity-Bild:

http://s22.postimg.org/mj5e1yy6l/Radiosity1.png

http://s22.postimg.org/z99mf264t/test.png

http://s22.postimg.org/s2ciwxklp/Vergleich.png

rapso

schaut gut aus, aber ich werde wieder meckern dass ich da antialiasing sehen will

photonmapping hat einen leichten rot bias, radiosity hingegen leicht richtung blau. falls du floats benutzt, versuch mal doubles, vielleicht hast du ein precission problem weil du soviele werte accumulierst.

XMAMan

rapso schrieb:

schaut gut aus, aber ich werde wieder meckern dass ich da antialiasing sehen will

photonmapping hat einen leichten rot bias, radiosity hingegen leicht richtung blau. falls du floats benutzt, versuch mal doubles, vielleicht hast du ein precission problem weil du soviele werte accumulierst.

Das mit den Aliasing gebe ich dir recht. Das stört mich selber. Momentan hat meine Funktion zum Auslesen eines Texels lediglich die Möglichkeit, dass ich von genau einen Pixel aus der Bitmap lese, oder ich lese von 4 Pixeln mit 4 Wichungsfaktoren(Summe ist 1).

Leider bringt dieses 4-Pixel-Interpolieren voll wenig. Kann es sein, dass ich einfach ein anderen Filter noch nehmen muss? Was würdest du mir empfehlen?

rapso

XMAMan schrieb:

Leider bringt dieses 4-Pixel-Interpolieren voll wenig. Kann es sein, dass ich einfach ein anderen Filter noch nehmen muss? Was würdest du mir empfehlen?

ich denke du sprichst hier ueber textur filtering, oder? ich sprach eher vom bild.

ein pixel in deinem bild ist eine flaeche, du zeichnest jedoch immer nur die farbe eines speziellen unktes innerhalb dieser flaeche.
zumindestens beim path tracing (als referenz) solltest du versuchen bei jedem neuen strahl von einer anderen position innerhalb des pixels zu feuern. im simpelsten fall hast du sowas

for(int x=0;x<width;x++)
{
 float3 Direction(float(x)/width,...);
}

das solltest du in sowas aendern koennen

for(int x=0;x<width*AA;x++)
{
 float3 Direction((float(x)+float(rand())/RAND_MAX)/(width*AA),...);
}

damit hast du pro pixel einen zufaelligen wert innerhalb des pixels.

das geht natuerlich noch viel besser, aber fuer den anfang sollte das, gerade mit den tausenden von strahlen pro pixel die du abfeuerst, gut resultate liefern.

das filtern aus 4 punkten einer textur hilft dir beim hochskalieren. das macht aber nicht wirklich etwas besser, selbst wenn es aliasing loest, weil es dann matsch gibt (wobei das meine persoenliche meinung ist).
fuer gute qualitaet wuerdest du eigentlich mehr texel als pixel brauchen.

der richtige filter ist dann ein wenig aufwendig. du musst nicht einfach einen punkt haben aus dem du interpolierst, du musst den pixel im screen auf die textur projezieren und dort jeden texel entsprechend der abdeckung einbeziehen. das wird aber noch aufwendiger wenn du reflektionen einbeziehen moechtest, ein pixel projeziert auf eine spiegelnde kugel kann dann eventuell eine ganze textur abdecken.

deswegen ist das supersampling mittels antialiasing, wie oben beschrieben, zu bevorzugen. denn zum antialiasing von geometrie und shading, bekommst du texture-antialiasing 'for free'.

XMAMan

rapso schrieb:

XMAMan schrieb:

Leider bringt dieses 4-Pixel-Interpolieren voll wenig. Kann es sein, dass ich einfach ein anderen Filter noch nehmen muss? Was würdest du mir empfehlen?

ich denke du sprichst hier ueber textur filtering, oder? ich sprach eher vom bild.

ein pixel in deinem bild ist eine flaeche, du zeichnest jedoch immer nur die farbe eines speziellen unktes innerhalb dieser flaeche.
zumindestens beim path tracing (als referenz) solltest du versuchen bei jedem neuen strahl von einer anderen position innerhalb des pixels zu feuern. im simpelsten fall hast du sowas
for(int x=0;x<width;x++)
{
 float3 Direction(float(x)/width,...);
}
das solltest du in sowas aendern koennen
for(int x=0;x<width*AA;x++)
{
 float3 Direction((float(x)+float(rand())/RAND_MAX)/(width*AA),...);
}
damit hast du pro pixel einen zufaelligen wert innerhalb des pixels.

das geht natuerlich noch viel besser, aber fuer den anfang sollte das, gerade mit den tausenden von strahlen pro pixel die du abfeuerst, gut resultate liefern.

das filtern aus 4 punkten einer textur hilft dir beim hochskalieren. das macht aber nicht wirklich etwas besser, selbst wenn es aliasing loest, weil es dann matsch gibt (wobei das meine persoenliche meinung ist).
fuer gute qualitaet wuerdest du eigentlich mehr texel als pixel brauchen.

der richtige filter ist dann ein wenig aufwendig. du musst nicht einfach einen punkt haben aus dem du interpolierst, du musst den pixel im screen auf die textur projezieren und dort jeden texel entsprechend der abdeckung einbeziehen. das wird aber noch aufwendiger wenn du reflektionen einbeziehen moechtest, ein pixel projeziert auf eine spiegelnde kugel kann dann eventuell eine ganze textur abdecken.

deswegen ist das supersampling mittels antialiasing, wie oben beschrieben, zu bevorzugen. denn zum antialiasing von geometrie und shading, bekommst du texture-antialiasing 'for free'.

Meine Funktion zur Erzeugung eines Primärstrahls sieht bereits so aus:

public static Strahl GetPrimärStrahlForPixel(Kamera kamera, int screenWidth, int screenHight, int x, int y, Random rand)
        {
            float kameraAbstand = kamera.GetKameraAbstandFromBildebene();
            float f = (float)screenWidth / (float)screenHight;

            float fx = 0, fy = 0;
            if (rand != null)
            {
                //Gleichverteilung (Sieht nicht so cool aus)
                //fx = (float)rand.NextDouble() * 2 - 1;     
                //fy = (float)rand.NextDouble() * 2 - 1;

                //Tent-Filter (Erzeuge mit größerer Wahrscheinlichkeit in der Mitte des Pixels ein Strahl) (Die Verteilungsfunktion ist ein Dreieck/Zelt). Deswegen Tent-Filter
                float r1 = 2 * (float)rand.NextDouble();
                float r2 = 2 * (float)rand.NextDouble();
                fx = r1 < 1 ? (float)Math.Sqrt(r1) - 1 : 1 - (float)Math.Sqrt(2 - r1); //Erzeugt Zahl zwischen -1 und +1
                fy = r2 < 1 ? (float)Math.Sqrt(r2) - 1 : 1 - (float)Math.Sqrt(2 - r2); //-1 + +1
            }

            //Die Bildebene ist f Breit und 1 Hoch
            Vektor bildEbenenPunkt = new Vektor(+((x + fx + 0.5f) / (float)screenWidth * f - f / 2),
                                                -(((y + fy + 0.5f) / (float)screenHight) - 0.5f), 0);

            return new Strahl(new Vektor(0, 0, 0), Vektor.Normiere(bildEbenenPunkt - new Vektor(0, 0, kameraAbstand)));
        }

Die Zahlen fx und fy sind meine Zufallszahlen, welche den Strahl so versetzen, dass er nicht immer nur durch die Pixelmitte geschossen wird. Trotzdem habe ich das Gefühl das bringt kein sichtbaren Effekt. Woran kann das liegen?