Raytracer in Python programmieren

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

@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.
Bild
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...
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
BlackJack

@Hyperion: Du hast LEGO-Modelle für Deine Diplomarbeit gerendert? Jetzt bin ich aber neugierig! :-)
0x1cedd1ce
User
Beiträge: 31
Registriert: Sonntag 3. Oktober 2010, 12:21

@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.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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/

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

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.
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

Springt ein JIT-*Compiler* an, wird für den Code gar nichts mehr interpretiert. Natürlich haben JIT-Compiler, anders als statische, Laufzeit-Informationen und können u.U. bessere Entscheidungen treffen, aber das als als Vorteil für einen Interpreter zu sehen ist dann doch grenzwertig ...

Einen GC können auch nicht-interpretierende Umgebungen haben, außerdem sehe ich nicht wie das ein Performance-Vorteil sein soll?
Benutzeravatar
Weltbesiedler
User
Beiträge: 103
Registriert: Dienstag 2. Februar 2010, 18:44
Wohnort: Bayern

ü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.
Mag für dich bestimmt einfach gewesen sein aber für mich ist es das höchstwahrscheinlich nicht, leider. Zudem fehlen mir wohl die mathematischen Grundlagen für die Berechnung der Farbe eines Schnittpunktes.

@jens
Ja ich weis, ich hab auch schon die meisten OpenSource Renderer ausprobiert (POV-Ray, LuxRender, Cycles, SLG, YafaRay, Blender Intern). Und umso mehr ich ausprobiert hatte, umso mehr wollte ich die Technik dahinter verstehen und das geht wohl am besten indem man so etwas einfach selber programmiert :).

@Hyperion
Sehr, sehr cooles Bild, ganz ehrlich! Allerdings weis ich nicht, wie ich ein Python Script in ein POV-Ray Script umwandeln kann. Könntest du die Lego-Maschine mal in ein Glas Material umwandeln und dann ein Licht auf einen Punkt in dem Bagger konzentrieren (Winkel vielleicht 15°) und die Licht Intensität erhöhen? Wüsste gerne ob da Kaustiken rauskommen :D .

Ich hab mir inzwischen ein paar Bücher über Grafikprogrammierung rausgesucht und werde mir diese die Tage mal ausleihen.
BlackJack

@Weltbesiedler: Wenn Dir die mathematischen Grundlagen fehlen, kannst Du natürlich auch keinen Raytracer programmieren. Dann musst Du das entweder lernen oder Dir ein anderes Ziel suchen.

Niemand hat davon geredet ein Python-Skript in ein POV-Ray-Skript umzuwandeln. Und was ist das für eine Obsession mit dem Kaustikeffekt? Was bringt Dir das wenn Hyperion das noch einmal rendert? Ich habe das Gefühl Du willst nur sinnlos Leute beschäftigen. Wenn Du Dich damit nämlich mal etwas praktisch beschäftigt hättest, wüsstest Du, das Glasmaterial + „photon mapping“ (für den Kaustikeffekt) das ganze um Grössenordnungen aufwändiger und damit langsamer werden lässt.
Benutzeravatar
Weltbesiedler
User
Beiträge: 103
Registriert: Dienstag 2. Februar 2010, 18:44
Wohnort: Bayern

War ja nur eine Idee, keine Panik.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

@cofi, DasIch D hat zum Beispiel einen GC
the more they change the more they stay the same
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Dav1d hat geschrieben:@cofi, DasIch D hat zum Beispiel einen GC
Auf was genau willst du damit jetzt hinaus?
derdon
User
Beiträge: 1316
Registriert: Freitag 24. Oktober 2008, 14:32

Wahrscheinlich darauf, dass die Existenz eines GC nichts damit zu tun hat, ob die Sprache interpretiert oder kompiliert wird und dass ein JIT damit auch nichts zu tun hat.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Auf nichts besonderes (derdons Aussage trifft da ziemlich genau zu), es war nur eine Anmerkung, deshalb mit @ um zu zeigen, dass es nicht zum Thema "Raytracer" passt.
the more they change the more they stay the same
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

BlackJack hat geschrieben:@Hyperion: Du hast LEGO-Modelle für Deine Diplomarbeit gerendert? Jetzt bin ich aber neugierig! :-)
Hehe... naja, ich weiß nicht, wann ich die Arbeit als PDF online stellen darf - habe ja erst letzte Woche abgegeben. Werde ich dann aber sicherlich machen. Kernpunkt sind eigentlich semantische Technologien (Ontologien; OWL + SPARQL), um Probleme des klassischen Produktentwicklungsprozesses zu lösen bzw. Fehler zu minimieren: Also gemeinsames Verständnis, Aggregation von Kernideen / Eigenschaften einer Baugruppe, Integration / Referenzierung von Fachdokumenten. CAD-Dateien als Kernmedium dienen da als Beispiel und damit ich selber als Nicht-Ingenieur irgend ein Beispielszenario entwickeln musste habe ich einfach LEGO als mein "Universum" gewählt - das habe ich immerhin früher über ein Jahrzehnt studiert :mrgreen:

Und naja, damit die Probleme anschaulich beschrieben werden können habe ich mich eben bemüht meine LDraw-Baupläne hübsch zu rendern ;-) Leider sind viele Tools in dem Bereich "angestaubt" ¹, weswegen ich mich mal versucht habe, selber einen Konverter LDraw -> PovRay zu schreiben. Allerdings ist das wider Erwarten nicht wirklich trivial... und naja, die Arbeit an sich hatte ja auch noch Priorität :-)

Aber mal schauen, vielleicht gehe ich das ja doch noch mal an...

¹ Hauptproblem war bei mir, dass ich die Kameraeinstellungen gerne anders gewählt hätte, als es das Konverterprogramm anbietet. Zudem habe ich auch mit anderen Lichtern gearbeitet usw. Da kam mir die Idee, dass man das mit Jinja2 viel flexibler gestalten könnte. Das ganze kombiniert mit kleinen Konfigurationsdateien könnte einen da echt helfen, sinnloses manuelles Editieren zu ersparen. Zudem gibt es div. Farb- / Material- und Bauteildefinitionen - die könnte man entsprechend auch flexibel definierbar machen... vielleicht eine hübsche GUI oben drauf... *seufz* viele Probleme und wenig Zeit ;-)

@weltbesiedler: Ist denn jetzt schon geklärt, dass Du wirklich einen eigenen Raytracer schreiben willst, oder ob Dein Fokus eher auf der Benutzung eines existierenden liegt?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Weltbesiedler
User
Beiträge: 103
Registriert: Dienstag 2. Februar 2010, 18:44
Wohnort: Bayern

Hyperion:
Vielleicht doch erstmal auf POV-Ray fokusieren...
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Weltbesiedler hat geschrieben:Hyperion:
Vielleicht doch erstmal auf POV-Ray fokusieren...
Was willst Du denn eigentlich? Willst Du (aus Spaß an der Freude / Interesse am Verständnis der Technologie) einen Raytracer schreiben oder liegt Dein Fokus auf dem visuellen Ergebnis?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Weltbesiedler
User
Beiträge: 103
Registriert: Dienstag 2. Februar 2010, 18:44
Wohnort: Bayern

Ich denke der Hauptpunkt ist die Verständnis an der Technologie. Wenn das erreicht ist kann man über das visuelle Ergebnis sprechen.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Weltbesiedler hat geschrieben:Ich denke der Hauptpunkt ist die Verständnis an der Technologie. Wenn das erreicht ist kann man über das visuelle Ergebnis sprechen.
Ich glaube Du hast meine Frage nicht verstanden; dafür kann ich aus Deiner Antwort entnehmen, was Du willst ;-)

Du willst also die Prinzipien hinter dem Raytracing verstehen. Povray könntest Du also benutzen, um erst einmal die Möglichkeiten eines RayTracers nachvollziehen zu können. Der Code an sich ist vermutlich zu komplex, um daraus wirklich etwas nachvollziehen zu können - aber evtl. irre ich auch hier und man kann - zumindest kleinere Algorithmen - doch daraus nachvollziehen.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Weltbesiedler
User
Beiträge: 103
Registriert: Dienstag 2. Februar 2010, 18:44
Wohnort: Bayern

Ich glaube Du hast meine Frage nicht verstanden
Wie war denn Deine Frage? In welcher Sprache ist POV-Ray geschrieben damit ich weiß womit ich es öffnen muss? Da gibt es ja teilweise total schöne Bilder, Wahnsinn :shock: :
http://hof.povray.org/BonsaiGirlA24.html
http://hof.povray.org/chado.html
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Weltbesiedler hat geschrieben:
Ich glaube Du hast meine Frage nicht verstanden
Wie war denn Deine Frage?
Ich wollte wissen, ob Dein Fokus auf dem Ergebnis des Renders liegt, also Du auf den Output eines Raytracers angewiesen bist und ihn nur als Werkzeug verwenden willst, oder eben den Vorgang als solches spannend findest und verstehen willst. Offensichtlich ist letzteres der Fall.
In welcher Sprache ist POV-Ray geschrieben damit ich weiß womit ich es öffnen muss?
Ich vermute mal C. Aber "öffnen" kannst Du jede Sprache in einem beliebigen Editor ;-) (Ok, von einigen esoterischen mal abgesehen...)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Antworten