Diskussion:Raytracing

message: Ich bin ja so happy, daß es geklappt hat. Man zieht den Objektpunkt durch den Brennpunkt, berechnet die Steigung der Verbindungslinie
und läßt sie hinter dem Brennpunkt auf eine Projektionsfläche treffen. Die Projektionsfläche mitsamt Mittelpunkt mappt man dann auf die Bildschirmausgabe und deren Mittelpunkt. In der Regel einfach nur x und y durch z mal minus eins mit einem Skalierungsfaktor multiplizieren und zur Screen-Mitte aufaddieren. Drehung der Kamera entspricht einer Drehung aller Punkte in entgegengesetzte Richtung um den Brennpunkt vor der Projektion. Einfache Kreisdrehformeln. Vielleicht mit Sinus und Cosinus, Tabellenoptimiert. In PC Underground steht's drin. Kleinste Z-Koordinate für jeden Screen-Punkt speichern und nur dann darstellen, wenn der aktuelle Punkt einen kleineren Z-Wert besitzt (der wahre Z-Buffer).
Ich habe im Testprogramm einen dreidimensionalen Würfel generiert, der sich beliebig drehen und verschieben läßt. Es geht so.
Weiter braucht man weiter vom Brennpunkt weg bloß eine geringere Auflösung. So kann man die Geschwindigkeit optimieren, indem man die Auflösung der zu projizierenden Pixelgruppe runtersampelt.
Und die Physik-Simulation zerlegt das Objekt in ein paar Einzelatome. Und die Koordinaten der Einzelatome an den Eckpunkten nimmt man dann, um einem Eckpunkt Koordinaten zuzuordnen und anhand der Koordinaten von den paar anderen Eckpunkten löst man dann die Gleichung auf,
die die Drehwinkel in X-, Y- und Z-Richtung des Objekts ausgehend von einem Koordinatensystem, das seinen Ursprung im ersten Eckpunkt hat
zu bestimmten. Das überträgt man in die grafische Positionierung des Objekts im Raum vor der Projektion.
Jetzt aber zum Raytracing. Man kann vielleicht einen Haufen Rechenleistung sparen, wenn man einfach nur doppelte Schnittpunkte des Strahls mit dem Objekt ausgehend von der Lichtquelle sucht. Wie eine Babuschka-Puppe bekäme vielleicht das Objekt eine äußere und eine innere Pixelgruppe. Nur wenn der Lichtstrahl das Objekt an zwei Punkten berührt, bevor er den Innenbereich erwischt, markiert man den zweiten Punkt auf einer Schattenrißdarstellung. Man könnte die Linie erhalten, die die Grenze des Schattenwurfs definiert.
Es betrifft alle nicht-konvexen Bereiche des Objekts, die von der Lichtquelle abgewandt sind.
Oder so.
Über diese abgewandten Bereiche brettert man vielleicht mit einem Flood-Fill und dunkelt den in dann in einer Maske erfaßten Bereich auf einen Faktor ab, daß nur noch die Helligkeit des Streulichts bleibt.
Sehen wir es getrennt zwischen Steulicht und dem Licht, das von konkreten Lichtquellen ausgeht. Das ist zwar nicht korrekt, sieht aber gut und überzeugend aus.
Mit gewissen Optimierungen und Bereichseingrenzungen könnte man vielleicht Rechenleistung sparen, indem man einfach die Grenzen der Schatten als Linien einzeichnet und die erfaßten Bereiche mit Flood-Fill markiert und abdunkelt. Dann müßte man nicht mehr alle Lichtstrahlen mit allen Winkeln und deren Rückstreuungen zurückverfolgen.
Nur so eine Idee. Könnte was bringen. Zwar nicht korrekt, gäbe aber gesetzt den Fall optisch beeindruckende Resultate und würde Rechenleistung sparen. (nicht signierter Beitrag von 93.201.9.114 (Diskussion) 22:48, 11. Mär. 2015 (CET)
thread_title:  Nicht jeden Strahl verfolgen, sondern die Umrisse des Schattens markieren? 

message: Hat man nur eine punktförmige Lichtquelle, geht der Schattenwurf genauso wie die Projektion selber.
Man macht wieder eine Camera-Oscura-Projektion sämtlicher Objektpunkte durch den Projektionspunkt und läßt den
Strahl mittels Strahlensatz auf das 2D-Screen-Array treffen. Dann merkt man sich dessen Z-Wert.
Alle Objektpunkte, die größer sind als der kleinste Z-Wert werden hinterher abgedunkelt.
Die andere Idee war, nur die Umrisse der Schatten zu berechnen und den abzudunkelnden Bereich vom Objekt hinterher
mit Flood-Fill zu ergänzen. Ob man den Bauklotz auch noch irgendwo einbauen kann?
Das Problem ist immer noch, daß die Objektpunkte selber das Licht ebenfalls zurückwerfen. Das braucht zuviel.
Zwei weiße Wände, eine von der Lichtquelle verdeckt, die andere Wand wirft aber eine Rückstreuung auf die eine.
Man müßte rekursiv von jedem Punkt der einen Wand die Reflexion berechnen. (nicht signierter Beitrag von 87.143.84.121 (Diskussion) 16:33, 7. Mai 2016 (CEST)
thread_title:  Punktförmige Lichtquelle 

message: Der Absatz über die zu aufwändige berechnung in realzeit ist ja dank rtx etc. obsolet, sollte man den überarbeiten oder zumindest bis dahin erst einmal löschen? --2003:E9:9709:7200:9B8D:7AA7:573D:1EC0 11:30, 1. Dez. 2022 (CET)
thread_title:  Realtime update 

message: Der erste Abschnitt zu Ursprung und Bedeutung findet sich 1 zu 1 auf Englisch in der folgenden Datei: 
Zitat aus der Datei:
"Before the development of ray tracing, computer graphics essentially consisted of a series of “programming
tricks” that attempted to imitate the shading of illuminated objects. Ray tracing was the first algorithm in this
field to make some physical sense."
Zitat aus dem Artikel:
"Vor der Entwicklung von Raytracing bestand das junge Gebiet der 3D-Computergrafik im Wesentlichen aus einer Reihe von „Programmiertricks“, mit denen die Schattierung von beleuchteten Objekten nachgeahmt werden sollte. Raytracing war der erste Algorithmus auf diesem Gebiet, der einen gewissen physikalischen Sinn ergab." --Laura240406 (Diskussion) 18:26, 14. Apr. 2024 (CEST)
thread_title:  Eventuell kopierter Text