Raytracing vs. Path Tracing: Was ist der Unterschied beim 3D-Rendering?

Einleitung

Raytracing vs. Path Tracing ist kein Wettstreit zweier konkurrierender Techniken: Path Tracing ist eine Art des Raytracings. Klassisches Raytracing verfolgt eine kleine, feste Menge von Strahlen (zu Spiegeln, durch Glas, zu jeder Lichtquelle), während Path Tracing pro Pixel viele zufällige Bounce-Pfade verfolgt und mittelt. Deshalb erfasst es weiches indirektes Licht so überzeugend, und deshalb kostet es so viel mehr Rechenleistung.

Diese Rechenleistung ist in der Produktion entscheidend. Braucht ein Frame 40 statt 4 Minuten oder kommt er voller Rauschen zurück, liegt die Ursache meist im Path Tracing: wie viele Samples es braucht, wie viele Bounces es verfolgt und wie das verbleibende Rauschen bereinigt wird. Dieser Leitfaden erklärt beide Konzepte, zeigt, wie Arnold, Cycles, Karma, V-Ray und Redshift sie anwenden, und was das für die Renderzeit bedeutet.

Er beschränkt sich bewusst auf Offline-Rendering, Frame für Frame, für Film, Animation, Visualisierung und Produktarbeit. Wie Spiele das Raytracing in die Echtzeitgrafik gebracht haben, behandelt unsere Geschichte des Echtzeit-Raytracings in Spielen, und die weitere Trennung zwischen interaktivem und finalem Frame-Rendering steht in Echtzeit- vs. Offline-Rendering. Wenn Sie vorab die Grundlagen dessen brauchen, was ein Renderer tut, beginnen Sie mit Was Rendering ist.

Gegenüberstellung: Klassisches Raytracing sendet einen Kamerastrahl, der sich in feste Reflexions-, Refraktions- und Schattenstrahlen aufteilt, während Path Tracing pro Pixel viele zufällige Bounce-Pfade sendet und mittelt

Raytracing, definiert

Raytracing simuliert Licht rückwärts: Statt Licht von einer Lampe zu verfolgen, bis es zufällig eine Kamera erreicht, schießt der Renderer von der Kamera aus durch jeden Pixel einen Strahl und fragt, was dieser trifft. Die Idee ist alt. Der Wikipedia-Artikel zu Raytracing in der Computergrafik (abgerufen am 19. Oktober 2026) nennt Arthur Appel als Urheber der ersten veröffentlichten Anwendung im Jahr 1968, eines nicht rekursiven Verfahrens, das heute meist Ray Casting heißt.

Die Version, die die meisten meinen, wenn sie von „Raytracing“ sprechen, stammt von Turner Whitted, dessen rekursiver Algorithmus 1979 auf der SIGGRAPH vorgestellt und 1980 veröffentlicht wurde. Trifft ein Kamerastrahl eine Oberfläche, erzeugt der Renderer neue Strahlen in bestimmten, vorhersehbaren Richtungen:

• einen Schattenstrahl zu jeder Lichtquelle, um zu prüfen, ob etwas sie verdeckt,
• einen Reflexionsstrahl in Spiegelrichtung, wenn die Oberfläche reflektierend ist,
• einen Refraktionsstrahl durch die Oberfläche, wenn sie transparent ist.

Jeder davon kann eigene Strahlen erzeugen, sodass ein verzweigter Baum entsteht, der bei einer festgelegten Tiefe endet. Das Ergebnis ist deterministisch, gut bei scharfen Reflexionen, sauberer Brechung und harten Schatten, aber schwach bei allem, was davon abhängt, dass Licht aus vielen Richtungen gleichzeitig eintrifft: weiche Schatten, Glossy-Unschärfe, Color Bleeding und Tageslicht, das im hinteren Teil eines Raums ausläuft.

Diese Effekte nennt die Branche globale Beleuchtung, und klassisches Raytracing allein berechnet sie nicht. Produktions-Renderer behandelten sie lange mit zusätzlichen Systemen wie Irradiance-Caches, Photon Maps und Final Gather, jedes mit eigenen Einstellungen und Artefakten.

Path Tracing, definiert

Path Tracing wurde laut dem Wikipedia-Artikel zu Path Tracing (abgerufen am 19. Oktober 2026) von Jim Kajiya in seiner Arbeit zur Rendering-Gleichung von 1986 eingeführt und benannt. Es schätzt diese Gleichung durch Zufallsstichproben.

Ein Strahl verlässt die Kamera durch einen Pixel und trifft eine Oberfläche. Statt sich in eine feste Menge von Kindstrahlen aufzuteilen, wählt er zufällig eine neue Richtung, gewichtet nach dem Material (ein Spiegel schickt ihn fast exakt in eine Richtung, eine matte Gipswand kann ihn fast überallhin schicken). Der Strahl prallt erneut ab, und wieder, bis er eine Lichtquelle erreicht, die Szene verlässt oder ein Bounce-Limit trifft. Diese einzelne, nicht verzweigte Kette von Bounces ist ein Pfad, und sie liefert eine Schätzung zurück, wie viel Licht den Pixel auf diesem Weg erreicht.

Ein Pfad ist eine schlechte Schätzung; tausend gemittelte Pfade durch denselben Pixel sind eine gute. Das ist Monte-Carlo-Sampling von Lichtpfaden. Da jeder Pfad an allem abprallen kann, berechnet Path Tracing indirektes Licht, weiche Schatten, glänzende Reflexionen, Kaustiken (im Prinzip) und Color Bleeding in einem einheitlichen Prozess, ohne separaten Cache für jeden Effekt.

Der Preis dafür ist Rauschen. Solange nicht genügend Pfade gemittelt sind, widersprechen sich benachbarte Pixel, und das Bild wirkt körnig. Dieser Kompromiss ist der Teil, der sich in Ihrer Render-Rechnung bemerkbar macht.

Die Unterschiede auf einen Blick

Eine nützliche Faustregel: Raytracing ist das Werkzeug (einen Strahl schießen und herausfinden, was er trifft), und Path Tracing ist eine Strategie, mit diesem Werkzeug das gesamte Beleuchtungsproblem zu lösen. Jeder moderne Path Tracer baut auf Raytracing auf. Nicht jeder Ray Tracer ist ein Path Tracer.

Warum Path Tracing Rauschen erzeugt und warum dessen Bereinigung aufwendig ist

Das Rauschen in einem per Path Tracing berechneten Bild ist kein Fehler: Jeder Pixel ist ein Mittelwert zufälliger Samples, und dieser Mittelwert schwankt, bis es genug davon gibt. Der Wikipedia-Artikel zu Monte-Carlo-Integration (abgerufen am 19. Oktober 2026) gibt an, dass der Fehler der Schätzung mit 1/√N abnimmt, wobei N die Anzahl der Samples ist. Auf das Rendering übertragen: Um das sichtbare Rauschen zu halbieren, brauchen Sie etwa viermal so viele Samples pro Pixel. Um es noch einmal zu halbieren, das Sechzehnfache des Ausgangswerts. Skaliert die Renderzeit ungefähr mit der Sample-Anzahl, was für den Großteil des Frames zutrifft, ist das Beseitigen der letzten Körnung der aufwendigste Teil des gesamten Renders.

Vier Rausch-Kacheln mit 16, 64, 256 und 1.024 Samples pro Pixel; das sichtbare Rauschen halbiert sich mit jeder Vervierfachung der Samples

Manche Szenen sind schwieriger als andere, und die Gründe sind vorhersehbar:

• Kleine oder verdeckte Lichtquellen. Tageslicht durch einen schmalen Spalt bedeutet, dass nur wenige zufällige Pfade das Licht überhaupt finden, sodass die Schätzung langsam konvergiert.
• Glänzende und refraktive Materialien. Gebürstetes Metall, Milchglas und Flüssigkeiten lassen sich nur schwer effizient samplen.
• Viele Bounces. Innenräume mit weißen Wänden sind auf mehrere Bounces angewiesen; ein niedrigeres Limit beschleunigt den Render, verdunkelt aber die Ecken.
• Volumes und Subsurface Scattering. Rauch, Nebel und Haut fügen Streuung im Material hinzu und vervielfachen die Arbeit pro Pfad.
• Bewegungsunschärfe und Tiefenschärfe. Jedes Sample wählt zusätzlich einen Zeitpunkt und einen Punkt auf der Linse, daher sind mehr Samples nötig.

Die Auflösung legt fest, für wie viele Pixel Antworten nötig sind; die Beleuchtung bestimmt, wie viele Samples jeder Pixel braucht, bevor seine Antwort sauber ist.

Wie Produktions-Renderer Path Tracing heute einsetzen

Die meisten Offline-Produktions-Renderer basieren heute auf Path Tracing, aber nicht alle auf dieselbe Weise. Die nützliche Unterscheidung verläuft zwischen dem Path Tracing jedes Bounces und dem Path Tracing des ersten Bounces mit einem Cache für den Rest.

Arnold. Die Arnold-Dokumentation von Autodesk (abgerufen am 19. Oktober 2026) beschreibt Arnold als unbiased, physikalisch basierte Monte-Carlo-Ray/Path-Tracing-Engine und hält fest, dass Caching-Algorithmen wie Photon Mapping und Final Gather vermieden werden. Die Qualität wird hauptsächlich über die Sample-Anzahl gesteuert: Ein saubereres Bild braucht mehr Samples, und mehr Samples brauchen mehr Zeit.

Cycles. Cycles von Blender ist ein Path Tracer, und seine Sampling-Einstellungen (Blender-5.2-LTS-Handbuch, abgerufen am 19. Oktober 2026) zeigen das moderne Werkzeugset deutlich: eine maximale Anzahl pro Pixel verfolgter Pfade, einen Rausch-Schwellenwert, der das Sampling in einzelnen Bereichen beendet, sobald sie sauber genug sind (adaptives Sampling), ein optionales Zeitlimit und eine Auswahl an Denoisern.

Karma. Die Karma-Dokumentation von SideFX selbst (Houdini-22.0-Dokumentation, abgerufen am 19. Oktober 2026) bezeichnet Karma als den physikalisch basierten Path Tracer von Houdini.

V-Ray. Chaos teilt die Aufgabe in eine primäre und eine sekundäre Engine für globale Beleuchtung auf. Für V-Ray GPU in 3ds Max gibt die Seite GPU Global Illumination von Chaos (abgerufen am 19. Oktober 2026) an, dass die primäre Engine immer Brute Force ist (reines Path-Traced-Sampling des ersten Bounces), mit wahlweise Brute Force oder Light Cache für die sekundären Bounces. Light Cache ist eine vorberechnete Annäherung späterer Bounces, die etwas Genauigkeit gegen eine große Ersparnis an Samples tauscht.

Redshift. Die Dokumentation zur globalen Beleuchtung in Redshift von Maxon (abgerufen am 19. Oktober 2026) beschreibt Brute Force als die genaueste und langsamste GI-Engine, bei niedriger Strahlenzahl verrauscht, und bietet als sekundäre Engine eine Irradiance Point Cloud an, die das primäre Brute Force bei schwieriger Beleuchtung schneller und sauberer macht, auf Kosten von etwas Speicherplatz.

Dieses letzte Muster, Path Tracing für den am häufigsten sichtbaren Bounce und ein Cache für den Rest, ist der Grund, warum die Begriffe „biased“ und „unbiased“ in Diskussionen über Renderer auftauchen. Der Mittelwert eines unbiased Renderers konvergiert mit zunehmender Sample-Anzahl gegen die physikalisch korrekte Antwort. Ein biased Renderer nimmt eine kleine, systematische Abweichung (durch einen Cache, ein Clamping oder ein Bounce-Limit) in Kauf, um deutlich früher zu konvergieren. Keines von beidem ist falsch. Bei Animationen brauchen Caches Sorgfalt, weil ein pro Frame berechneter Cache flackern kann; bei Standbildern sind sie oft der schnellste Weg zu einem sauberen Bild.

Denoising: weniger Samples, gleiche Deadline

Wenn das Halbieren des Rauschens das Vierfache an Samples kostet, besteht die naheliegende Abkürzung darin, früher aufzuhören und das verbleibende Rauschen herauszufiltern. Genau das tun moderne Denoiser.

Die beiden Denoiser, denen die meisten Artists begegnen, sind Intel Open Image Denoise und NVIDIA OptiX. Intel beschreibt Open Image Denoise (abgerufen am 19. Oktober 2026) als Open-Source-Bibliothek mit Denoising-Filtern für Bilder, die mit Raytracing gerendert wurden. Die oben zitierte Cycles-Seite zum Sampling listet beide als Optionen auf, weist darauf hin, dass OptiX nur auf NVIDIA-GPUs verfügbar ist, und beschreibt die automatische Einstellung so, dass sie Open Image Denoise gegenüber OptiX bevorzugt.

Denoiser sind darauf trainiert, Sampling-Rauschen von echtem Detail zu unterscheiden, haben aber Nebenwirkungen:

• Verlorene Feindetails. Feine Texturen, Haare und dünne Geometrie können weggeglättet werden, wenn zu wenige Samples eingeflossen sind.
• Zeitliches Flackern. Ein Denoiser, der jeden Frame einzeln bearbeitet, kann bei aufeinanderfolgenden Frames leicht unterschiedliche Ergebnisse liefern, was in Animationen als Flimmern wahrgenommen wird.
• Compositing-Passes. Wenn Sie den Beauty-Pass entrauschen, die AOVs aber nicht (oder umgekehrt), addieren sich die Passes im Compositing nicht mehr sauber.

Die praktische Regel lautet: Entrauschen Sie einen Frame, der bereits ordentlich konvergiert ist, nicht einen, der überwiegend aus Rauschen besteht. Ein Denoiser verringert die Zahl der benötigten Samples. Er ersetzt sie nicht.

Was Path Tracing für die Renderzeit bedeutet

Die Renderzeit eines per Path Tracing berechneten Jobs ergibt sich aus wenigen Größen: Frames, Pixel pro Frame, Samples pro Pixel und wie aufwendig jedes Sample für die jeweilige Szene ist.

Ein hypothetisches Beispiel, nur zur Veranschaulichung. Ein zehnsekündiger Shot mit 24 Bildern pro Sekunde umfasst 240 Frames. Angenommen, jeder Frame braucht bei der Sample-Anzahl, die ihn sauber macht, 16 Minuten auf einer Maschine. Das sind 64 Maschinenstunden. Nun verlangt der Kunde weniger Körnung in den Schatten. Bedeutet das Halbieren des Rauschens das Vierfache an Samples und skaliert die Zeit mit den Samples, liegt derselbe Shot nun bei etwa 256 Maschinenstunden. Ein guter Denoiser kann einen Großteil davon zurückholen, weshalb Sample-Anzahl und Denoiser gemeinsam an einem Testframe festgelegt werden.

Rechnung zur Renderzeit für einen per Path Tracing berechneten Shot: 240 Frames mal 16 Minuten pro Frame ergeben 64 Maschinenstunden, und das Vierfache an Samples zum Halbieren des Rauschens ergibt etwa 256 Maschinenstunden

Drei Gewohnheiten halten diese Rechnung unter Kontrolle:

1. Messen Sie an einem repräsentativen Frame. Testen Sie den schwierigsten Frame des Shots (den mit dem meisten Glas, Volumen oder Bewegungsunschärfe), nicht den ersten.
2. Nutzen Sie adaptives Sampling und einen Rausch-Schwellenwert, wo der Renderer einen anbietet, damit saubere Bereiche wie Himmel und glatte Wände früh aufhören zu samplen.
3. Setzen Sie Samples dort ein, wohin das Auge schaut. Erhöhen Sie die Samples für die konkreten Lichter oder Materialien, die verrauscht bleiben, nicht für den ganzen Frame.

Die vollständige Liste der Einstellungen, die die Renderzeit beeinflussen, von Bounce-Limits bis zu Texturgrößen, finden Sie in unserem Leitfaden zur Optimierung der Renderzeit. Ob diese Samples auf Prozessoren oder Grafikkarten schneller laufen, hängt vom Renderer und von der Szene ab; das behandelt GPU-Rendering vs. CPU-Rendering.

Path-Tracing-Jobs auf einer render farm ausführen

Jeder Frame einer per Path Tracing berechneten Sequenz wird unabhängig gerendert, sodass 240 auf viele Maschinen verteilte Frames in der Zeit von nur wenigen Frames fertig werden, während die gesamte Rechenleistung, die eine Farm abrechnet, gleich bleibt. Wenn Ihnen das Konzept einer Farm neu ist, erklärt unser Leitfaden, was eine render farm ist, das Modell.

Bei Super Renders Farm, einer vollständig verwalteten render farm, laden Sie die Szene hoch, und die Farm kümmert sich um Software und Render-Lizenzen, sodass es keine Remote-Desktop-Sitzung gibt und nichts zu installieren ist. Der Großteil der Arbeit, die wir sehen, wird auf der CPU gerendert (V-Ray und Corona in 3ds Max, Arnold in Maya, Cycles in Blender, Karma und Mantra in Houdini) und läuft auf unseren CPU-Nodes.

GPU-Path-Tracing läuft auf unseren GPU-Nodes, jeweils mit 2x NVIDIA RTX 5090 Karten und 32 GB VRAM pro Karte. Der Speicher gilt pro Karte und wird nicht über die beiden Karten hinweg gebündelt, sodass ein GPU-Frame in 32 GB passen muss. Redshift rendert ausschließlich auf GPU-Nodes. Redshift für Cinema 4D, Maya und Houdini sowie Cycles auf der GPU laufen dort ohne Setup-Anfrage; die GPU-Hardware und die unterstützten Engines sind auf unserer Seite zur GPU-Cloud-render-farm aufgeführt. Passt eine Szene nicht in den Speicher einer Karte, ist ein CPU-Path-Tracer für diesen Job meist der sicherere Weg.

Aktuelle Preise stehen auf der Preisseite; wir haben in dieser Erklärung bewusst keine Zahlen genannt, weil sie sich ändern und weil die Sample-Anzahl, auf die Sie sich festlegen, die Endkosten stärker beeinflusst als jeder Stundenwert. Neue Konten erhalten 25 $ kostenlose Render Credits, die Sie für einen repräsentativen Testframe einsetzen können, bevor Sie sich auf eine ganze Sequenz festlegen, und unser Support-Team ist rund um die Uhr per Live-Chat erreichbar.

Häufige Missverständnisse

„Path Tracing und Raytracing sind konkurrierende Technologien.“ Das sind sie nicht. Path Tracing ist eine Methode, die auf Raytracing aufbaut. Ein Produktions-Renderer, der heute als Ray Tracer beschrieben wird, ist darunter meist ein Path Tracer.

„Mehr Samples bedeuten immer ein besseres Bild.“ Über den Punkt hinaus, an dem das Rauschen in der Ausgabeauflösung unsichtbar ist, erhöhen zusätzliche Samples nur die Renderzeit. Genau diesen Punkt sollen adaptives Sampling und Rausch-Schwellenwerte finden.

„Biased heißt falsch.“ Biased-Verfahren wie Caches konvergieren früher und gehören in der Produktion zum Alltag. Die richtige Wahl hängt vom Shot ab, insbesondere davon, ob es sich um ein Standbild oder eine Animation handelt.

„GPU-Path-Tracing ist immer schneller.“ Pro Frame ist es oft schneller, aber nur, wenn die Szene in den Speicher der Karte passt und der Renderer jedes von der Szene genutzte Feature unterstützt. Große Archviz-Szenen und aufwendige Volumes rendern häufig zuverlässiger auf der CPU.

FAQ

Q: Was ist der Unterschied zwischen Raytracing und Path Tracing? A: Klassisches Raytracing verfolgt von jedem Trefferpunkt aus eine feste Menge von Strahlen (zu Lichtquellen, in Spiegelrichtung und durch transparente Oberflächen) und liefert ein deterministisches, rauschfreies Ergebnis ohne indirektes Licht. Path Tracing verfolgt pro Pixel viele zufällige Bounce-Pfade und mittelt sie, wodurch indirektes Licht, weiche Schatten und Color Bleeding ganz natürlich berechnet werden, aber Rauschen entsteht, bis genügend Samples gemittelt sind.

Q: Was ist Path Tracing in einfachen Worten? A: Beim Path Tracing wird ein Strahl von der Kamera in die Szene geschickt, der an jeder Oberfläche in eine zufällige Richtung abprallt, bis er Licht findet; das wird pro Pixel viele Male wiederholt, und die Ergebnisse werden gemittelt. Eingeführt wurde es von Jim Kajiya in seiner Arbeit zur Rendering-Gleichung von 1986, und es bildet die Grundlage der meisten Offline-Produktions-Renderer von heute.

Q: Ist Path Tracing eine Art von Raytracing? A: Ja. Path Tracing nutzt Raytracing, um herauszufinden, was jeder Strahl trifft, und wendet dann Monte-Carlo-Sampling an, um zu entscheiden, wohin der nächste Strahl geht. Jeder Path Tracer ist ein Ray Tracer, aber nicht jeder Ray Tracer ist ein Path Tracer.

Q: Warum rauschen per Path Tracing berechnete Renders? A: Jeder Pixel ist ein Mittelwert zufälliger Samples, und dieser Mittelwert bleibt unsicher, bis es genug davon gibt. Der Fehler sinkt proportional zu eins durch die Wurzel der Sample-Anzahl; das Halbieren des Rauschens braucht also etwa das Vierfache an Samples und bei den meisten Szenen etwa die vierfache Renderzeit.

Q: Nutzen V-Ray, Arnold, Cycles und Redshift Path Tracing? A: Ja, auf unterschiedliche Weise. Arnold, Cycles und Karma sind Path Tracer, die die Qualität hauptsächlich über Samples steuern. V-Ray und Redshift bieten eine Brute-Force-Engine, die den ersten Bounce per Path Tracing berechnet und mit einem Cache für spätere Bounces kombiniert werden kann (Light Cache in V-Ray, die Irradiance Point Cloud in Redshift), was früher konvergiert, dafür aber eine kleine Verzerrung (Bias) in Kauf nimmt.

Q: Ersetzt Denoising höhere Sample-Anzahlen? A: Nicht vollständig. Denoiser wie Intel Open Image Denoise und NVIDIA OptiX erlauben es, bei weniger Samples aufzuhören, wirken aber am besten bei Frames, die bereits ordentlich sauber sind. Zu wenige Samples können bei Standbildern Feindetails kosten und in Animationen Flackern verursachen.

Q: Ist Path Tracing auf GPU oder CPU schneller? A: Das hängt vom Renderer und von der Szene ab. GPU-Path-Tracing ist pro Frame oft schneller, wenn die Szene in den Speicher der Karte passt, während CPU-Path-Tracing sehr große Szenen, aufwendige Volumes und Features bewältigt, die eine GPU-Engine nicht unterstützt. Auf unserer Farm tragen die GPU-Nodes 2x RTX 5090 mit 32 GB pro Karte, nicht über die Karten hinweg gebündelt.

Q: Kann eine render farm Path Tracing beschleunigen? A: Eine Farm verringert nicht die Rechenleistung, die ein Frame braucht, rendert aber viele Frames gleichzeitig, sodass eine Sequenz in einem Bruchteil der tatsächlichen Wartezeit fertig wird. Die gesamte Maschinenzeit, die stark von der gewählten Sample-Anzahl abhängt, bestimmt die Kosten.