Raytracer in Python programmieren

Weltbesiedler · Donnerstag 17. November 2011, 19:36

Ist es möglich einen Raytracer in Python zu programmieren der am Ende der Berechnung ein gerendertes Bild ausgibt? Wenn ja, wie viel Arbeit wäre damit verbunden (welche Arbeitsschritte)? Die Frage ist rein hypothetisch

.

BlackJack · Donnerstag 17. November 2011, 20:22

@Weltbesiedler: Ja das ist möglich. Wie viel Arbeit das macht, hängt davon ab was der alles können soll.

Weltbesiedler · Donnerstag 17. November 2011, 20:49

Danke für deine Antwort. Also er soll halt ein vorher definiertes Objekt mit Farbe / Shader / Kaustiks berechnen können. Alle Objekte in der Szene werden vorher definiert (im Code nicht in einer GUI).

deets · Freitag 18. November 2011, 00:11

Wenn du viel zeit hast - denn sowas in Python zu implementieren wird das ganze sehr, sehr langsam machen.

Warum verwendest du nicht POV Ray? Vll.it einem Python Skript zum generieren?

jens · Freitag 18. November 2011, 14:38

Einen simpler raytracer ist nicht wirklich kompliziert, siehe: http://www.python-forum.de/viewtopic.php?f=21&t=27696

Weltbesiedler · Freitag 18. November 2011, 14:58

Wieso würde das so langsam gehen? Weil Python eine Interpreter Sprache ist? Und wie soll ich POV-Ray in ein Python Script implementieren wenn ich den Source-Code gar nicht habe zudem ist POV-Ray nicht in Python geschrieben.

Hyperion · Freitag 18. November 2011, 15:16

Weltbesiedler hat geschrieben:Und wie soll ich POV-Ray in ein Python Script implementieren wenn ich den Source-Code gar nicht habe

Da gäbe es zig Möglichkeiten, angefangen bei einem simplen `subprocess`-Aufruf

Dazu brauchst Du keinen Quellcode - den könntest Du Dir übrigens leicht besorgen...

Weltbesiedler hat geschrieben: zudem ist POV-Ray nicht in Python geschrieben.

Ja und? Ist Qt auch nicht, dennoch existieren dafür Python-Bindings!

Weltbesiedler · Freitag 18. November 2011, 16:03

Danke für die hilfreichen Antworten, ich merke schon das ich noch einige Zeit brauche bis ich das alles ganz verstanden habe. Jetzt hab ich auch gemerkt das es den Source Code auf der Home Page zum Downloaden gibt

.

deets · Freitag 18. November 2011, 17:59

Du sollst nicht Python in POV-Ray machen. Sondern Python benutzen, um eine POV-Ray Scene zu erzeugen, als Textfile. Und die dann dem POV-Ray Programm zum Frass vorwerfen.

Und ja, in Python geschrieben waere der Rendere arschlahm, weil es eine interpretierte Sprache ist.

Hyperion · Freitag 18. November 2011, 18:14

deets hat geschrieben: Und ja, in Python geschrieben wäre der Renderer arschlahm, weil es eine interpretierte Sprache ist.

Hui... das riecht nach Off-Topic Diskussion

Prinzipbedingt würden das doch eher die wenigsten unterschreiben...

Weltbesiedler · Freitag 18. November 2011, 18:33

Ein bisschen Off-Topic schadet ja nicht. Was ist denn Deiner Meinung nach der Grund für die Langsamkeit eines Python Raytracers, Hyperion? Außerdem wäre es mein Traum so einen Renderer wie POV-Ray selber zu programmieren. Er scheint nämlich schon ziemlich angestaubt wenn ich mir da einzelne Bilder bzw. Testszenen so anschaue. "Versteht" denn POV-Ray überhaupt Python?
Testszene Landschaft: http://www.fotos-hochladen.net/uploads/ ... qktlvy.png

deets · Freitag 18. November 2011, 19:01

@Weltbesiedler

Nein, er versteht seine eigene Szenenbschreibungssprache. Die kannst du aber mit Python generieren.

Und was das angestaubte angeht... erstens denke ich sagt das mehr ueber die Gestalter die ihn benutzt haben aus, als ueber den Renderer selbst. Der beherrscht AFAIK so ziemlich alles, was geht.

Und zweitens... mach's mal erst genauso gut. Egal worin... bis du da bist, dauert's ne weile. Es ist ja schoen, dass du sowas selbst machen willst, und als Lernprojekt sicher spannend - insofern, fang ruhig an. Nur bin skeptisch, dass du da bahnbrechend wirken wirst

deets · Freitag 18. November 2011, 19:04

@Hyperion

Jaja, ich habe gerade gestern nett mit Christian Tismer ueber PyPy geredet, und wie toll das ist. Ich bin auch ehrlich begeistert, und vielleicht arbeite ich daran ein bisschen mit. Doch ein drop-in-replacement fuer alles, was man so macht, ist es noch nicht.

Aber bist du wirklich der Meinung, fuer diese Disukssion hier ist das relevant? CPython ist *langsam*. Und interpretiert. *Punkt*. Ich liebe es, aber jetzt hier mit "aber, aber, aber wenn man dies und jenes tut" zu kommen, dann kann man hier jede Diskussion in's unendliche strecken...

Weltbesiedler · Freitag 18. November 2011, 19:46

Der beherrscht AFAIK so ziemlich alles, was geht.

Hab ich auch gerade gemerkt, ist ja fast sowas wie Kaustiken

.
http://img3.fotos-hochladen.net/uploads ... iq7zec.png

Und zweitens... mach's mal erst genauso gut. Egal worin... bis du da bist, dauert's ne weile. Es ist ja schoen, dass du sowas selbst machen willst, und als Lernprojekt sicher spannend - insofern, fang ruhig an. Nur bin skeptisch, dass du da bahnbrechend wirken wirst

Ja ich weis leider selber das ich so einen Renderer wahrscheinlich nicht schreiben werde und klar ist auch das das Ergebnis (falls überhaupt was dabei rauskommt) nicht bahnbrechend wird. Brauche ich für das Thema Raytracer eine Literatur weil in das Thema eingearbeitet habe ich mich bis jetzt noch nicht, oder reichen Python Kenntnisse und Mathematik Kenntnisse aus? Entschuldigung wenn meine Fragen hier etwas naiv rüberkommen was vielleicht daran liegt das sie es auch sind

.

EyDu · Freitag 18. November 2011, 21:37

Weltbesiedler hat geschrieben:Brauche ich für das Thema Raytracer eine Literatur weil in das Thema eingearbeitet habe ich mich bis jetzt noch nicht, oder reichen Python Kenntnisse und Mathematik Kenntnisse aus? Entschuldigung wenn meine Fragen hier etwas naiv rüberkommen was vielleicht daran liegt das sie es auch sind .

Prinzipiell ist die Mathematik hinter Raytracern recht simpel (man kann es natürlich beliebig komplex werden lassen), aber woher sollen wir denn wissen, wie gute deine Python und Mathematikkenntnisse sind? Probiere doch einfach mal POV-Ray aus, frage die Suchmaschine deiner Wahl nach Raytracing und lese dich ein. Das ist für alle Seiten viel effizienter als nach irgendwelchen theoretischen Allgemeinplätzen zu fragen.

Sebastian

Hyperion · Freitag 18. November 2011, 22:03

@deets: Ich wollte Dir auch nicht direkt widersprechen; evtl. hättest Du direkt etwas von Python oder besser noch CPython sagen sollen. Java / C# z.B. sind in ihren Standardumsetzungen ziemlich flott, obwohl sie interpretiert sind - aber das weißt Du ja mindestens genau so gut wie ich. Nur der OP vermutlich nicht, daher sollte man ihm zumindest so genau wie nötig beschreiben, worin die Kausalitäten liegen. Ansonsten rennt er durch die Welt und erzählt rum, dass interpretierte Sprachen per se langsam sind...

@Weltbesiedler: Mal ein Beispiel von mir. Man kann virtuelle LEGO-Modelle (LDraw-Format) in PovRay-Szenen-Dateien umwandeln und dann rendern lassen. Habe ich intensiv für meine Diplomarbeit verwendet.

Da ich mit dem Tool zur Umwandlung nicht wirklich zufrieden war, habe ich mal angefangen Python-Utilities zu schreiben, die so eine Umwandlung auf Basis von `jinja2` durchführen. Allerdings bin ich da nie wirklich so richtig weit gekommen...

BlackJack · Freitag 18. November 2011, 23:19

@Hyperion: Du hast LEGO-Modelle für Deine Diplomarbeit gerendert? Jetzt bin ich aber neugierig!

0x1cedd1ce · Samstag 19. November 2011, 09:36

@Hyperion: Natürlich sind interpretierte Sprachen langsamer als nicht interpretierte, da erst jeder Befehl durch den Interpreter muss und nicht direkt ausgeführt wird. Das kann zwar recht flott sein. Aber pures asm ist schneller.

Das Hauptproblem ist aber nicht der Interpreter, sondern die CPU. Ein Raytracer benutzt hauptsächlich Fließkomma-Opperationen und die sind extrem langsam auf ner CPU.

@weltenbesiedler:
Raytracer sind sehr simpel. Du brauchst dafür nur Schnittpunkte und etwas Wissen über Matrizen, Vektoren, Normalen. Wenn du dich erstmal auf einfache Objekte beschränkst. z.B. nur Kugeln nutzt. Dann kannst du sehr schnell etwas brauchbares herstellen. Achte sehr genau darauf das diese Objekte eine Oberklasse haben, damit du einfach neue hinzufügen kannst.
Die Funktionsweise findest du mittels Google, bei mir an der Uni gibt es die Vorlesung "Computer Graphik" die genau das behandelt. Vielleicht findest du Vorlesungsfolien im Netz.
Für diese Vorlesung hab ich auch ein Raytracer implementiert. Allerdings in C++, von dem ich keine Ahnung hatte. Arbeitsaufwand 1 bis 2 Tage
Nach dem eigentlichen Tracer brauchst du noch ein Shader, z.B. Phong-Shading. Das ist eigentlich nur ein Algorythmus mit dem man die Farbe eines Schnittpunktes berrechnet, geht ganz schnell.
Ein Schattenfühler um zu erkennen ob ein Schnittpunkt im Schatten liegt ist nur eine weiterführung des Raytraces.
Damit du auch Bildchen auf deine Objekte bekommst brauchst du noch etwas zum Mappen von Bitmaps.
Falls du dann noch Lust hast gibt es tolles Sachen wie Bump-Map, Environment-Mapping.

jens · Samstag 19. November 2011, 10:04

Es gibt eh schon einige Renderer, auch viele OpenSource Software. Ein paar Links hab ich hier: http://www.jensdiemer.de/de/Blog/312/3d-render-engines/

DasIch · Samstag 19. November 2011, 11:47

0x1cedd1ce hat geschrieben:@Hyperion: Natürlich sind interpretierte Sprachen langsamer als nicht interpretierte, da erst jeder Befehl durch den Interpreter muss und nicht direkt ausgeführt wird. Das kann zwar recht flott sein. Aber pures asm ist schneller.

Wenn man einen guten GC und JIT hat kann ein Interpreter durchaus schneller sein als der Code den ein Compiler generiert, so "natürlich" ist da gar nichts.