Hübsch. Ist doch erstaunlich, wie ein globaler Ansatz bei der Beleuchtung die Optik verbessern kann. Für eine wirkliche +3 fehlen mir allerdings noch ein paar technische Details, zum Beispiel die Art der Lichtberechnung oder die Rechenzeit für das Bild.

Anhand des Gekriesels auf den Oberflächen vermute ich, Du streust von jedem Punkt aus eine Handvoll zufällige Strahlen in den Raum und schaust, wieviel Licht von dort kommt. Wahrscheinlich auch gewichtet mit dem Cosinus zur Senkrechte. Wenn Du das iterativ machen würdest, also auf diese Art mehrfach über die ganze Szene gehst und dabei jeweils das akkumulierte Licht auf allen Oberflächen mit einberechnest, müsstest Du auch noch eine schöne indirekte Beleuchtung mit reinbekommen. So daß zum Beispiel der grüne Körper rechts unten ein wenig grünes Licht auf die Rückseite des rosa Körpers davor zurückwirft.

Bye, Thomas

ich verwende eine naive monte-carlo simulation, soweit richtig erkannt, deswegen dauert das ganze ziemlich lange ( ca. 4 Stunden ). grundsätzlich wäre das möglich, dann wäre aber die Zeit explodiert.

Der Winkel findet keine Beachtung, es wird nur getestet, wieviele Lichtstrahlen einen Punkt treffen, ich war ehrlich gesagt selbst überrascht, das keine Winkelberechnung nötig ist, im Endeffekt ist es aber durchaus logisch nachvollziehbar, denn eine zum Licht ausgerichtete Oberfläche wird natürlich von mehr Strahlen getroffen als eine schräge.

Hmm... probiere mal die Gewichtung der Einzelstrahlen mit dem Cosinus. Das entspricht dem echten geometrischen Zusammenhang und dürfte nebenbei auch das Gekriesel beseitigen bzw. dämpfen. Auf der HP habe ich gelesen, daß Du teilweise bis zu 6000 Strahlen pro Pixel verschickst... eigentlich müssten 256 reichen, weil Du sowieso nicht mehr als 8 Bit Genauigkeit im Bild unterbringen kannst. Eine regelmäßige Streuung der Strahlung auf einer Halbkugel und eben jene Cosinus-Gewichtung müssten eigentlich erreichen können, daß Du auch mit 256 Strahlen auskommst.

Nuja, nur ein paar Ideen. Die +2 von mir hast Du ja bereits.

Bye, Thomas

8 Bit Genauigkeit stimmt nicht ganz. bis zum Release eines Pixels an die Screen-Surface handle ich die Farben als float[4]. Dinge wie Importance-Sampling und Photon-Maps würden das Gekriesel auch stark reduzieren.

Das mit dem Cosinus schau ich mir auf jeden Fall mal an

P.S.: Die regelmäßige Streuung sollte durch den Twister-Algorithmus gegeben sein. Das Gekriesel wird glaube ich durch den Kosinus nicht reduziert, es ist ja auch kriselig bei auf einer Ebene benachbarten Intersections.

Neben meinem üblichen Kritikpunkt, dem kurzen Erklärungstext, möchte ich mal noch was zur GI sagen. Ich sehe nämlich keine. Der Witz an GI ist doch da nicht nur direkte Beleuchtung sondern auch indirekte Beleuchtung möglich ist. Also das Licht von links reflektiert an der Decke und dann ist es rechts neben der Säule nicht komplett dunkel. Also entweder ist die Quali ein bissl zu schlecht um das zu erkennen, oder das kann der Raytracer wirklich nicht.

sry TGGC, aber von GI hab ich nun wirklich nichts gesagt ;)

Benutzt du irgendwelche Beschleunigerstrukturen wie Octrees oder so?

Ich verwende einen kd-baum ( ein achsenparalleler bsp-baum ) mit iterativem ( = nicht rekursivem ) Traversal. Den Baum baue ich mit SAH ( = Surface Area Heuristics ).

Klingt wie Octtree.

octree = 8-fach split

bsp = kd = 2-fach split