Ray-Tracing, Source Code

Hallo Michael,

schön, dass du die Definition des Richtungscosinus geklärt hast. Zu deiner Sourcecodefrage ist mir eingefallen, dass Ivan Krastev, der Designer des Raytrace-Programms MODAS, in der ReadMe-Datei erwähnte, dass er vor der Modas-Entwicklung mal einen Sourcecode veröffentlicht hat. Hier die entsprechende Passage:

> "After I advertised my "Telescope Design and Analysis Tools" in "Sky & Telescope" magazine (Software Showcase, October issue, 1997, p.65) over 100 amateur astronomers from all over the world contacted me. Many amateurs were using RAYTRACE.EXE from Harrie Rutten and Martin Venrooij, but that program was already compiled (executable file) and could not be changed.
Amateur astronomers and telescope makers were particularly glad that my tools were in BASIC and that the source code was provided. Hence, they could extend, change and customize the software for their own particular needs. Furthermore, a working skew ray tracing numerical method for amateurs (without bugs) had not previously been published. Some telescope makers also asked for tools for advanced amateur astronomers and programmers. "

Ist zwar 'nur' in Basic, aber vielleicht hilft es dir trotzdem weiter. Wenn du an die S+T Ausgabe nicht herankommst, kann ich mir vorstellen, dass Ivan Krastev dir gern weiterhilft. Seine Adresse findest du in der Modas-ReadMe (kostenlose Demo), wahrscheinlich auch wenn du unter modas googlest.

Gruß
Hans-Jürgen

Hallo Michael,

ich will ja niemanden vom Selbermachen abhalten, aber OSLO kann so ziemlich alles und kostet nix (wenn man mit 9 Flächen auskommt).

Clear skies

Tassilo

Hallo Michael,

mein Telescope Optics ist die 3. Auflage von 1993. Die dort angegebenen Systembeispiele habe ich fast alle mit meinem (unabhängig entwickelten) Programm PointSpread verglichen und keine Abweichungen festgestellt. Daher gehe ich davon aus, dass sowohl der Code von Rutten +Van Venrooij als auch meiner fehlerfrei ist, soweit das die Durchrechnung von windschiefen Strahlen an allgemeinen Flächen (auch geneigte Asphären) betrifft. Wo ich Unstimmigkeiten (ich will nicht Fehler sagen) bei R+V gefunden habe, ist die Behandlung der Bildfehler 3. Ordnung in Kapitel 21 (Designing Telescope Optical Systems). Dort sind einige Formeln für die Seidelkoeffizienten nur bis auf Massstabsfaktoren richtig. Z.B. fehlt in Formel 21.2.7 (Öffnungsfehler) ein Faktor 4/M^3, in Formel 21.2.8 (Koma) ein Faktor 4/M^2. Das führt in der weiteren Behandlung dort nicht zu Folgefehlern, weil Öffnungsfehler bzw. Koma zu Null gesetzt werden, um die Korrektionsbedingungen abzuleiten. In meinem Programm benutze ich aber für die Optimierung des Predesign die Methode, die Seidelkoeffizienten 3.Ordnung absichtlich von Null verschieden zu setzen, um Fehler höherer Ordnung zu minimieren. Das funktioniert natürlich nur, wenn die vollständigen Formeln benutzt werden. Daher ist mir diese Diskrepanz aufgefallen.
Zu der Anmerkung von Ivan Krastev zu Fehlern bei der Berechnung eines Schmidtsystems: Die Formeln 4. Ordnung für die Schmidtplatte sind bei R+V identisch mit den von mir benutzten, die Formeln 6. Ordnung habe ich direkt von R+V übernommen, sie scheinen mir absolut zuverlässig zu funktionieren. Vielleicht sind ja in der 3. Auflage bereits solche Fehler korrigiert worden. Du könntest ja auch Harrie Rutten mal direkt fragen.

Gruß
Hans-Jürgen

Hallo Michael,

> Hast du auch die Formeln für die Reflektion an einer nicht-rotationssymmetrischen Fläche?

nein, habe ich nicht, nur Algorithmen für dezentrierte rotationssymmetrische Flächen, aber das ist ja trivial und auch bei R+V beschrieben. Ich glaube auch nicht, dass es da eine geschlossene Formel gibt, sondern eher einen iterativen Algorithmus wie bei allgemeinen Asphären. Im Prinzip sollte das nicht komplizierter sein als bei Rotationsflächen, nur aufwendiger, da man zur Beschreibung der Fläche wesentlich mehr Koeffizienten braucht...

Gruß
Hans-Jürgen

P.S. Wenn du von Harrie Rutten Info zu Fehlern in TO bekommst, bin ich sehr daran interessiert.

Hallo Michael,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Hast du auch die Formeln für die Reflektion an einer nicht-rotationssymmetrischen Fläche? <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Falls ich dein Problem richtig verstehe, hier die Formel zur Berechnung
der Reflektion von Lichtstrahlen an beliebigen Flächen:

n...Flächennormalenvektor mit der Länge 1, steht senkrecht auf die Fläche (im Bild nicht ersichtlich)
l...Einfallender Vektor/Lichtstrahl
r...Reflektierter Vektor/Lichtstrahl

r=l-2(n*l)*n

(hier ist n*l das innere Produkt bzw. Skalar Produkt zw. Normale und einfallendem Vektor)

Je nach Art der Fläche kann es problematisch sein die Normalen zu bestimmen.

Wahrscheinlich klar - aber ich habs mal gepostet!

mfg Wolfgang

Hallo Wolfgang,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: ratman</i>
<br />
Falls ich dein Problem richtig verstehe, <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

auch wenn du Michaels Frage richtig beantwortet hast, noch eine allgemeine Anmerkung: die Bestimmung der Richtung des reflektierten Strahls bei bekannten Schnittkoordinaten an der Fläche ist nur die eine Hälfte des Problems. Vorher muss aber der Strahlschnittpunkt mit der Fläche gefunden werden. Für Kegelschnitte kenne ich dafür eine geschlossene Formel, für allgemeine Asphären nicht, auch R+V haben nur eine iterative Lösung. Das gilt dann natürlich auch für nichtrotationssymmetrische Flächen.

Gruß
Hans-Jürgen

Hallo Michael,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: mkoch</i>
<br /> Erst beim zweiten Teil (Bestimmung des Vektors) muss man anders vorgehen.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
bei meinem Agorithmus gibt es da keinen Unterschied, es muss nur die Flächennormale am Schnittpunkt bekannt sein (die hast du ja über deine Flächenkoeffizienten). Den Algorithmus von R+V kenne ich nicht so im Detail. Ich verstehe deine Anmerkung so, dass dort die Richtung des reflektierten (bzw. gebrochenen) Strahls nicht allgemein, sondern unter Ausnutzung der Rotationssymmetrie bestimmt wird. Wenn das so ist, müsstest du das natürlich entsprechend ändern. Die Formel für Reflektion hast du ja schon von Wolfgang bekommen.

Viel Erfolg beim Programmieren!
Hans-Jürgen

Hallo Leute,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">&gt; Je nach Art der Fläche kann es problematisch sein die Normalen zu bestimmen.

Das scheint mir eher das kleinere Problem zu sein, wenn die Fläche und die beiden partiellen Ableitungen bekannt sind.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Das ist natürlich richtig, aber gibt es da nicht Flächen bei dennen die
partiellen Ableitungen an manchen Stellen null werden - das würde zu
falschen Ergebnissen führen?!

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">auch wenn du Michaels Frage richtig beantwortet hast, noch eine allgemeine Anmerkung: die Bestimmung der Richtung des reflektierten Strahls bei bekannten Schnittkoordinaten an der Fläche ist nur die eine Hälfte des Problems. Vorher muss aber der Strahlschnittpunkt mit der Fläche gefunden werden. Für Kegelschnitte kenne ich dafür eine geschlossene Formel, für allgemeine Asphären nicht, auch R+V haben nur eine iterative Lösung. Das gilt dann natürlich auch für nichtrotationssymmetrische Flächen.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Das ist die hohe Kunst des Raytracings. Ich könnte mir vorstellen
das ein Bisektionsverfahren die jeweiligen Schnittpunkte finden könnte - ob es alle findet ist natürlich auch so ein Frage.

mfg Wolfgang

Hallo Michael,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: mkoch</i>
<br />Ich kann die Formel nachvollziehen, aber nur unter der Annahme dass man den Normalenvektor anders rum definiert, von oben nach unten gerichtet. Kann das sein, oder habe ich da einen Denkfehler gemacht?
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

ich habe die Formel auch noch mal kontrolliert und komme zu dem Ergebnis, dass sie mit den dargestellten Vektorrichtungen richtig ist.
Natürlich kann der Denkfehler auch bei mir liegen.

Gruß
Hans-Jürgen

Hallo Leute,

Die Gleichung sollte eigentlich richtig sein! Bei Gelegenheit werde ich
die gesamte Herleitung posten - habe aber im Moment sehr wenig Zeit!
Daher vertröste ich euch auf später!

mfg Wolfgang

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: mkoch</i>
<br />
Kennt jemand ein einfaches optisches Ray-Tracing Programm dass als Source Code verfügbar ist? Vorzugsweise Pascal, C oder Basic.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
hi!
ist wahrscheinlich nicht das was Du suchst, aber ich könnte Dir eine C++ source zur Berechnung von Zernike - Polynomen und Koeffizienten zur Verfügung stellen. Das ist natürlich kein Raytracer, aber vielleicht für die Auswertung nicht uninteressant ...
lg
birki

Hallo Michael,
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: mkoch</i>
<br />Ich verstehe nicht wo die drei Faktoren "r" herkommen und vermute dass man sie jeweils durch "1" ersetzen müsste.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Wenn ich die Formel richtig verstehe, ist das die Rücktransformation des Normalenvektors in kartesische Koordinaten.
Die z-Komponente des Tangentenvektors in t-Richtung erhält man ja formal mit dZt=r*dt*1/r*dF/dt= dt*dF/dt. Die Zerlegung des Vektors in x- und y-Richtung erhält man mit dXt=r*dt*sin(t) und dYt=r*dt*cos(t). Wenn du die Komponenten des Tangentenvektor in r-Richtung entsprechend berechnest, dr und dt zu 1 setzt und das Kreuzprodukt bildest, erhälst du genau die fragliche Formel. Du könntest r noch ausklammern, dann wäre aber der erste Term der x-Komponente 1/r*dF/dt*sin(t).

Gruß
Hans-Jürgen

Hallo Michael,
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: mkoch</i>
<br />Noch eine Frage:
Wie bestimmt man denn den Normalenvektor bei r=0?
Die genannte Formel versagt ja an der Stelle.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
ups, stimmt. Ich glaube, das liegt daran, das für r=0 dt nicht definiert ist. Jede Änderung geht ja in r-Richtung (Am Nordpol kann man ja auch nur Richtung Süden gehen).
Ich würde den Punkt so behandeln, das ich dF/dr für r=0 bilde, was ja allgemein eine Funktion von t ist. Für t würde ich die Werte 0 und pi/2 einsetzen, um gleich einfache kartesische Komponenten der beiden Vektoren zu erhalten. Das Kreuzprodukt der beiden Vektoren hat dann die Richtung der Flächennormalen im Punkt r=0.

Gruß
Hans-Jürgen

Hallo Freunde simulierter Strahlen,

Hier mal eine sehr flexible Alternative zu Stand-Alone Programmen:
ich hab mir vor längerem einen Raytracer auf Excelbasis gebastelt. Der Trick war, die Strahlparameter als ASCII-Daten in eine Zelle zu quetschen, z.B. "2.0;5.0;10.0;0.0;0.0;1.0" bedeutet Strahlausgangspunkt x=2; y=2; z=2; Strahlrichtung u=0; v=0; w=1.
Die optischen Elemente waren ähnlich angegeben (Scheitelposition x,y,z; Flächen-'Radius' r; Brechungsindizes n1,n2; Exzentrizität e; Blendendurchmesser d).

Für die Berechnung habe ich eine Makrofunktion Trace(Element, Strahlparameter) erstellt, die die optischen Daten und Strahlparameter in Textform ausliest, verwurschtelt und als neuen Strahl wieder in Textform ausgibt. Somit stellt jede Excelzelle ein Strahlsegment zwischen 2 optischen Flächen dar.
Noch ein bisschen Graphik dazu, und ein extrem flexibles Raytracingkonzept war fertig. Hübsch ist vor allem, dass Abhängigkeiten ("Radius 1 muss gleich Radius 5 sein und der doppelt so groß wie Koordinatendifferenz z17-z6", oder so ähnlich) sehr leicht darstellbar sind. Zudem kann man fix irgendwelche Differenzquadratsummen erzeugen und die mit dem Solver minimieren lassen - schon hat man einen einfachen Optimieralgorithmus, der Radien oder Abstände variiert, um die beste Abbildung zu finden.
Zudem hat man Zugang zu wirklich allen Informationen - und jeder kann sich selbst irgendwelche Spezialauswertungen und Graphiken dazubasteln.

Zu Mathematik:
ich verwende die Kegelschnittgleichung in Scheitelform
x^2 + y^2 = 2*r*z - (1-e^2)*z^2

Die Normale ist dann [x, y, (1-e^2)*z-r] (muss noch normiert werden)

Mit u=einfallender Strahl, v=ausgehender Strahl, n=Normalenvektor,
(n.u)=Skalarprodukt, gilt:

Reflektion: v = u - 2*(n.u)*n

Brechung: v = (u + k * n)/|u + k * n| mit k=sqr((n.u)^2+(n2/n1)^2-1) - (n.u).

Was noch nicht drin ist, sind zur opt.Achse verkippte Elemente. Bisher kann man nur den Scheitelpunkt frei im Raum positionieren. Kann aber leicht nachgerüstet werden...[:D]

Bei Interesse stelle ich die Datei gerne zur Verfügung.
Wer's gleich braucht, am besten eine email an mich (khs(ät)z.zgs.de). Ansonsten stelle ich das Ding und die Herleitung mal auf meine Homepage (falls ich mal Zeit habe - dauert aber noch etwas)

Gruß
Karl-Heinz