Hallo,

Ich hab mir schon vor längerer Zeit einmal Raytracing angesehen und bin erst vor ein paar Tagen auf das
Photon-Mapping gestoßen.

Meine Frage ist jetzt, was brauch ich denn für Kenntnisse um soetwas zu programmieren?

Ich hab mir das ganze einmal durch den Kopf gehen lassen und mir sind da nur ein paar Dinge eingefallen:
Lineare Algebra (Vekoren, Schnittpunkt von Ebene und Gerade)
Farben (Physikalische eigenschaften vil. noch)

Wenn es nur das ist, dann würde ich eig. sofort loslegen können... also nicht mit dem Programmieren, sondern eher
das ganze im Kopf und am Papier durchspielen.

Ich hab im Internet eig. sogut wie garnichts gefunden wie man das ganze implementieren könnte.
Ich hab mir dass so vorgestellt:
Lichtquelle sendet in einer gewissen Dichte Lichtstrahlen aus. Bei mir wären dass dann Vektoren.
Diese werden auf Schnittpunkte mit allen (bzw. wenn das einmal optimiert wird nur ein Teil) Flächen in der Szene geprüft.
Das weitere ergibt sich dann eh automatisch, die werden dann durch die Szene fliegen und hin und wieder einen Teil ihrer
Farben verlieren, bis sie dann durch "Zufall" auf einer Projektionsfläche landen. Diese Fläche ist dann eig. das, was am
Bildschirm zu sehen ist.


Vielleicht könnt ihr mir sagen ob das so stimmt.

Vielen Dank schon im Voraus!
Andreas

Jap, stimmt so ungefähr. Allerdings ist deine "Projektionsfläche" die gesamte Oberfläche der Szene. Photon-Mapping soll ja gerade das Problem beim Ray-Tracing lösen, dass die Lichtstrahlen nicht die Kamera (bzw. Lichtquelle) treffen.

Ich könnte mich auch irren, aber ich glaube Pixar hat ein Software-Patent auf Photon-Mapping.

_________________
Yeah!

Naja, so ähnlich klappt das. Was du beschreibst ist Monte-Carlo-Raytracing und zwar hoffst Du, daß deine Lichtstrahlen in die Kamera fallen. Klappt angeblich, dauert aber ewig . Photon Mapping legt dagegen eine Photonen-Karte (die map) an, in der Photonen samt Ort, RIchtung und Intensität abgelegt werden. Gewöhnlich wird Photon-Mapping nur für indirekte Beleuchtung berechnet, heisst du startest dein Photon und beim ersten Treffer an der Wand legst du es nicht zu deinen gespeicherten Photonen in die Map, sondern reflektierst, spiegelst, brichst oder sonstwas und erst beim zweiten aufschlagen trägst du das photon in deine Map ein. Damit will man sich das etwas aufwändige Raytracding das du beschreibst sparen, aber dennoch möglichst realistische Lichter erzeugen (da ist deine Variante perfekt ). Man versucht also nur relaiv wenige Photonen von jeder Lichtquelle auszusenden und dann auch nur relativ kleine Karten anzulegen. Wenn man auch direktes Licht damit berechnet (und damit extra viele Photonen erzeugt), dann passiert z.B. das:

statt


Nachdem man also eine Photon-Map angelegt hat, dann beginnt man ganz normal von der Kamera aus zu tracen und sammelt dann die Photonen die in der Umgebung jeden Treffers liegen zum normalen (direkt berechneten) Licht zusätzlich auf (ambient lighting brauchst du dann nicht mehr ). Nachdem man da aber ganz schnell hunderttausende Photonen hat, die in der Karte liegen, ist eine Sinnvolle Raumteilungstechnik sinnvoll Die Original Implementierung von Jensen macht eine art ausbalancierten BSP.

Evtl. steht in disem Thread auch noch irgendwas, was dich interessieren könnte.

O.o
Naja, ich wills ja eig. eh nur privat verwenden...


@Delphic
Das Photon Mapping was du da beschreibst hört sich sehr interessant an... ich wollte eben eine sehr genaue Abbildung.
Denke das schafft aber das Photon Mapping genauso.

Aber jetzt einmal ganz grob geschätzt... wie lange könnte es denn dauern, so eine Box mit nur einer Kugel drinnen auf
auf eine mittel große Ebene aufzunehmen?
Ich stell mir das nur ein bisschen arg vor wenn ich einen Fehler im Programm suchen muss und jedes mal warten muss
bis alles gerendert ist. Dann kommt noch dazu, dass ich das ganze eig. in Java machen will...
Ein Freund von mir, der mir hilft hätte bei sich einen Quad-Core drin mit 3 GHz. Und Raytracing lasst sich ja wunderbar
parallelisieren... da könnten wir dann auch noch auf verschiedene PCs aufteilen, die jeweils bestimmte Lichter rechnen.
Das zusammenführen der einzelnen Teilbilder ist ja dann kein Problem mehr...
Noch dazu kommt dass er sich wunderbar mit Netzwerken auskennt... vil. kann er was schönen Zaubern.
Ich hätte jedem pc manuell per Programm ein Licht in der Scene zugeteilt, die auftreffenden Photonen in ein File
gespeicher und dann wieder manuell zusammen geführt. Denke aber das bekommt er besser hin.

Also, ich bin jetzt schon ziemlich abgewichen, also... hm wie lange könnte es daueren... verkraftbar wär für so eine große
und schöne Scene wie deine ~1 Tag.
Aber für kleine Test Scenen die ich so nebenbei mal zum ausprobieren ausführ, um zu sehen ob das stimmt was ich mir
überlegt/programmiert hab, sollte man hald nicht 1 Stunde warten...


Andreas

Schau Dir mal die Wikipedia Artikel über Path tracing, Photon tracing und Photon mapping an, so heissen ein paar (die?) Techniken für das lösen der "Rendering equation". Photon tracing ist dabei unerträglich langsam, das kann man mal aus Spass an einfachen Bildern probieren, aber um wirklich rumzuspielen ists glaub nicht geeignet. Alle drei gelten als Löser der Rendering Equation, sollten also bei entsprechend eingesetztem Aufwandt die gegebenen Lichtverhältnisse optimal nachstellen; dabei ists im prinzip egal, welchen Algo du benutzt, ein biserl rauschen tun sie alle Photon Mapping mit einem Photon Cache dürfte der schnellste sein, mit Path Tracing kann man auch leicht spielen, der rechner kämpft aber schon bedeutend länger . Von Patenten auf PM ist mir nichts bekannt, würde mich auch wundern, weil Jensen das imho selbstständig entworfen und veröffentlicht hatte. In Pixar's Renderman ists jedenfalls implementiert - etwaige Optimierung könnten natürlich betroffen sein.

Danke für die links, das mit der Rendergleichung sieht sehr interessant aus!
Gibt es irgendwo umfangreiche (aber nicht gleich Bücherdimensionale) Artikel/Tutorials die sich grob mit den Grundlagen befassen?

Was micht grad noch interessiert (bzw. mir durch den Kopf geht seit ich grad Nicos erste antwort gelesen hab) ist ob man hier eventuell auch mit der Wignerfunktion antreten kann. Hat da schonmal jemand irgendwas gehört ob das für Raytracing verwendet wird?

Mit den Rays stell ich mir das so vor:
Hat einen Vektor als Richtung + Anteile der 3 Grundfarben (?)

Wenn diese dann auf die Ebene treffen wird die alte Farbe mit der des Rays addiert und dann wieder abgelegt.

Für die Brechung hat jedes Objekt in der Scene eine Liste mit Brechungsindizes. Mehrere, weil ein Objekt verschiedene Farben verschieden bricht. Wie ich das Realisiere weiß ich aber noch nicht... weil sich dass Problem stellt dass Violett anders
gebrochen wird als Rot (kommt natürlich aufs Material an), obwohl Rot ein Teil von Violett ist.
Das ist dann eben das Problem mit Welle-Teilchen. Als Welle hat jede Farbe ihre eigene Wellenlänge.
Aber wie kann ich das bei einem Teilchen machen?


@Delphic
Ich weiß nur nicht genau was du mit "Rendering equation" meinst

Ein Ray sollte auch irgendwie einen Ursprung haben


Die "Rendering equation" ist der heilige Gral der Computergrafik. Es handelt sich dabei um die vollständig korrekte Beleuchtung. Diese kann man natürlich nicht vollständig lösen, sondern immer nur Teile davon.

_________________
Yeah!

hab ich ganz vergessen



Hm... aber wenn ich eh jeden Lichtstrahl verfolge brauch ich das doch gar nicht, oder irre ich mich da?


Hab ich grad gefunden:
http://de.wikipedia.org/wiki/Lichtbrechung#Unterschied_zwischen_Brechung.2C_Beugung_und_Extinktion
Mit einer welle könnte man alles erklären... auch die Beugung.
Ich überleg mir mal ob ich das ganze mit Wellen machen könnte...

Nun ja...du kannst nicht jeden Lichtstrahl verfolgen, sind einfach zu viele

_________________
Yeah!

Das Problem welches du hast, wenn du das als Wellen machen willst (und damit wirklich jeden "Strahl" verfolgst) ist, dass das Huygens-Prinzip gilt: Jeder Oszillator, der von einer Welle getroffen wird, sendet wiederum eine Elementarwelle aus. Da aber die Wellen sich auf Osziallatoren bewegen, hast du ganz schnell nahe unendlich viel Wellen. Okay. Nun kannst du sagen, du willst das vernachlässigen und nur an Ecken/Schnittkanten das beachten... Okay... Das wäre vielleicht wirklich interessant. Wenn du dann von Kugelwellen ausgehst... Ja, das gibt bestimmt interessante Ergebnisse.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Nicht ganz, ein paar Dinge erfasst sie noch nicht, etwa Volumenstreuung. Aber darüber würde ich mir erstmal gar keine Gedanken machen, denn mit der Rendering Equation alleine bekommt man schon so allerlei faszinierende Bilder hin


Haargenau, man versucht halt das beschriebene Licht-Gleichgewicht möglichst gut zu approximieren. Und da kommen halt die drei genanten Verfahren ins Spiel. Es gibt noch eine ganze Reihe mehr, die man ausprobieren kann, wenn man Spass dran hat

Irgendwie sieht die "Rendering equation" kompliziert aus
Brauch ich das wirklich, auch wenn ich jetzt nur einmal klein anfangen will?

Für den Anfang hab ich mir das jetzt einmal so vorgestellt:
Ich schreib einmal so allgemein wie möglich (dass es für später dann erweiterbar ist) einen ganz simplen Raytracer.
Also ohne Beleuchtung ohne Schatten. Einfach nur von einem Projektions-Punkt auf die Objekte schießen und wenn
getroffen, Farbe auf der Fläche ändern.

Wenn ich das ganze Programmtechnisch gut hinbekomme, sollte es nicht mehr so aufwendig (vom schreiben her) sein,
einen Photon Mapper draus zu machen.

Nö, brauchst du nicht. Bilde einfach munter Geraden vom Kamerapunkt aus durch den Pixel, den du einfärben willst und gucke, was du so an Geometrie triffst. Damit hast du schonmal die halbe Miete für einen Raytracer.
Die Rendering-Equation ist übrigens nur halb so kompliziert, wie sie aussieht.

Also eigentlich startet man ja von einem Projektionspunkt und je nachdem welche Farbe das Objekt hat, nimmt man diese Farbe und setzt damit die Farbe des Projektionspunktes, aber vielleicht hab ich dich ja auch nur falsch verstanden. Aber Beleuchtung und Schatten wirst Du schon brauchen, um mit Photon-Mapping gute Ergebinsse zu erzielen, weil wie gesagt, das direkte Licht wird auch bei PM nicht per Photonen gerechnet. Aber sobald du Objekte mit Strahlen schnreiden kannst, hastes im Prinzip schon geschafft, dann ist auch beleuchtung und Schatten nur noch Kleinkram, der sich fast genauso berechnet wie Schnittpunkte Projektionsfläche<-> Objekt.

[edit] Achso zur Rendering equation: Sieht nur wegen der vielen Parameter über Richtung, Wellenlänge und Co. so kompliziert aus. Im Prinzip steht da nur, daß die ausgehende Lichtintensität in eine best. Richtung L_0 gleich der emitierten Lichtenergie L_e (für Lichtquellen) in einer best. Richtung plus der gewichteten "Summe" der eingehenden Intensitäten L_i aus allen Richtungen ist.