Was ist ein Video-Rendering-Service? So funktioniert Cloud-Video-Rendering

Einführung

„Video-Rendering-Service" ist ein Begriff, der locker verwendet wird - manchmal meint er eine Farm, die eine 3D-Animation in eine fertige MP4-Datei verwandelt, manchmal einen Cloud-Transcoding-Dienst, der lediglich eine bereits vorhandene Videodatei neu encodiert, und manchmal ist er einfach ein Marketing-Label für etwas, das eher einer allgemeinen render farm entspricht. Die Verwirrung ist nachvollziehbar, denn ein echter Video-Render-Job besteht tatsächlich aus zwei sehr unterschiedlichen Arbeitsschritten, die zusammengefügt werden: dem Rendern von Frames aus einer 3D-Szene oder einem Comp und dem Encodieren dieser Frames in eine abspielbare Videodatei.

Dieser Leitfaden schlüsselt Schritt für Schritt auf, was ein Video-Rendering-Service tatsächlich leistet - vom Projekt-Upload über verteiltes Frame-Rendering bis zum finalen H.264/H.265-Encoding und Download - und woher die tatsächlichen Rechenkosten stammen. Wir gehen ein durchgerechnetes Kostenbeispiel mit Standard-GHz-Stunden-Raten durch und zeigen dann, wann sich die Nutzung eines Services lohnt und wann lokales Rendering auf der eigenen Maschine sinnvoller ist. Die Terminologiefrage render farm vs. render service behandeln wir hier nicht (das ist ein separates, eher definitorisches Thema - siehe unseren Beitrag Render-Service vs. render farm im Vergleich, falls Sie deswegen hier gelandet sind) - ebenso wenig das allgemeine Geschäftsmodell von Online-Rendering-Services (behandelt in So funktionieren Online-Rendering-Services). Dieser Artikel dreht sich speziell um die Video-Pipeline: was zwischen dem Klick auf „Absenden" und dem Erhalt der fertigen Videodatei passiert.

Video-Rendering-Pipeline: Szene hochladen, Frame-Sequenz rendern, Frame-QC, Encoding zu H.264/H.265, Auslieferung

Was „Video-Rendering" tatsächlich bedeutet

Bevor wir die Pipeline aufschlüsseln, hilft es, genau zu definieren, was dabei eigentlich entsteht. „Video-Rendering" bedeutet im 3D- oder Motion-Design-Kontext fast immer eine von zwei Output-Arten:

• Eine Animation oder Bildsequenz, die aus einer 3D-Szene gerendert wird (3ds Max, Maya, Cinema 4D, Blender, Houdini) oder aus einem Motion-Graphics-Comp (After Effects) - ein Walkthrough, ein Produktspot, eine Titelsequenz, ein VFX-Shot.
• Eine Frame-Sequenz, die anschließend zu einer einzigen Videodatei werden muss - ein Containerformat (MP4, MOV), das einen Codec (H.264, H.265/HEVC) umschließt, den ein Browser, Editor oder das Wiedergabegerät des Kunden tatsächlich abspielen kann.

Ein Video-Rendering-Service im Sinne dieses Artikels übernimmt beide Hälften: Er rendert die Frames aus Ihrer Szene oder Ihrem Comp über einen Cluster von Maschinen und encodiert diese Frames anschließend in das gewünschte Video-Deliverable-Format. Das unterscheidet ihn von einem reinen Transcoding-Service, der nur die zweite Hälfte übernimmt (Sie haben bereits eine Videodatei und möchten sie lediglich in einen anderen Codec oder eine andere Bitrate umcodieren) - die Codec-Seite davon behandeln wir separat in unserem H.264/H.265-Encoding-Leitfaden.

So funktioniert Cloud-Video-Rendering: Die Pipeline

Die Mechanik gliedert sich in vier Stufen, und in den beiden mittleren steckt die eigentliche technische Arbeit.

1. Projekt-Upload. Sie laden Ihre Szenendatei (oder Ihr After-Effects-Projekt) hoch, zusammen mit allen referenzierten Assets - Texturen, HDRIs, Geometrie-Caches, Schriftarten, plugin-abhängige Elemente, Footage-Plates. Auf diesen Schritt gehen die meisten Render-Fehler zurück: eine fehlende Textur, ein relativer Dateipfad, der sich nur auf Ihrem lokalen Laufwerk auflösen lässt, eine Schriftart, die auf der Farm nicht installiert ist. Bei einer vollständig verwalteten render farm scannt der Einreichungsclient oder das Plugin nach referenzierten Assets und markiert alles, was ungelöst wirkt, bevor der Job losgeschickt wird - das fängt einen erheblichen Anteil dieser Fehler ab, bevor sie Rechenzeit für einen Job verbrennen, der ohnehin mittendrin gescheitert wäre.

2. Verteiltes Frame-Rendering. Das ist der Teil, der Cloud Rendering überhaupt erst lohnenswert macht. Die Frame-Sequenz eines Videos ist von Natur aus parallelisierbar - Frame 400 muss nicht warten, bis Frame 399 fertig ist (mit ein paar Ausnahmen, die weiter unten behandelt werden) - daher teilt ein Render-Manager den gesamten Frame-Bereich auf so viele Worker-Nodes auf, wie verfügbar sind, und verteilt die Abschnitte an jeden einzelnen. Eine 1.200-Frame-Sequenz, die auf 30 Worker aufgeteilt wird, bedeutet, dass jeder Node ungefähr 40 Frames rendert, und die gesamte Sequenz ist ungefähr in der Zeit fertig, die ein einzelner Worker für seinen 40-Frame-Abschnitt bräuchte - nicht in der Zeit, die es dauern würde, alle 1.200 Frames auf einer einzelnen Maschine zu rendern. Das ist der zentrale Mechanismus, der aus einem nächtlichen lokalen Rendering etwas macht, das in ein bis zwei Stunden fertig ist.

3. Encoding. Hier kommt der Teil, der alle überrascht, die annehmen, die gesamte Pipeline würde auf dieselbe Weise parallelisieren: Video-Codecs lassen sich in der Regel nicht auf dieselbe Art auf Worker verteilen wie das Frame-Rendering. H.264 und H.265 nutzen zeitliche Kompression - spätere Frames referenzieren frühere (P-Frames und B-Frames werden aus benachbarten Frames vorhergesagt, statt jeden Frame unabhängig zu speichern) -, was bedeutet, dass ein Encoder in der Regel die gesamte Frame-Sequenz in der richtigen Reihenfolge benötigt, um eine saubere, artefaktfreie Ausgabe zu erzeugen. Wird ein Encoding-Job auf viele Worker verteilt und die Teile anschließend wieder zusammengefügt, drohen sichtbare Nahtstellen an den Segmentgrenzen. Das praktische Muster - und das, was wir auf unserer eigenen Farm für Video-Jobs anwenden - lautet: die Frame-Sequenz über den gesamten Worker-Pool rendern (schnell, weil frame-parallel) und das Encoding anschließend als einzelnen Durchlauf ausführen, entweder auf einem Worker oder lokal nach dem Download. Encoding ist in der Regel deutlich schneller als das Rendern der Frames selbst, sodass dieser Single-Pass-Schritt die Zeitersparnis aus dem parallelen Rendering nicht zunichtemacht - es bedeutet lediglich, dass sich der Abrechnungsposten „Encoding" nicht auf dieselbe Weise verkleinert wie der Posten „Rendering", wenn Sie mehr Worker hinzufügen.

4. Download. Das fertige Ergebnis - sei es das finale encodierte Video oder, falls die Pipeline es benötigt, die zugrunde liegende Frame-Sequenz für eine nachgelagerte Compositing- oder Color-Grading-Stufe - kommt je nach Dateigröße und Workflow per Web-Download, SFTP oder über einen Auto-Download-Client zurück.

Warum sich Frame-Rendering und Encoding im großen Maßstab unterschiedlich verhalten

Der Unterschied zwischen Stufe 2 und Stufe 3 lohnt sich genauer zu betrachten, denn er ist die häufigste Quelle falscher Erwartungen, wenn jemand annimmt, ein „Video-Rendering-Service" skaliere linear über die gesamte Pipeline, nur weil das für die Render-Hälfte gilt.

Weitere Worker-Nodes zu einem Frame-Rendering-Job hinzuzufügen, senkt die Wanduhrzeit fast proportional - bis zu dem Punkt, an dem keine unabhängigen Frames mehr zu verteilen sind (ein 200-Frame-Job, aufgeteilt auf 300 Worker, hat 100 ungenutzte Worker). Weitere Worker zu einem Encoding-Job hinzuzufügen, bringt fast nichts, weil es normalerweise nur einen Encoding-Job gibt, nicht viele. Deshalb kann eine Einreichung, die auf dem Papier „GPU-lastig" oder „CPU-lastig" wirkt, trotzdem an einem Single-Worker-Encoding-Schritt hängen bleiben, wenn die Frame-Anzahl im Verhältnis zur Sequenzlänge klein ist oder wenn die Deliverable-Liste mehrere verschiedene Encoding-Ziele umfasst (ein 4K-Master plus ein komprimierter Web-Cut plus ein vertikaler Social-Crop), die jeweils einen eigenen Durchlauf benötigen.

Auch auf der Render-Seite gibt es Ausnahmen. Effekte mit zeitlichen Abhängigkeiten - Motion Blur, der über Frame-Grenzen hinweg sampelt, Partikelsimulationen, die Zustand von Frame zu Frame akkumulieren, Fluid- oder Cloth-Simulations-Caches - parallelisieren nicht so sauber wie ein rein frame-unabhängiges Rendering, weil ein Worker, der Frame 500 rendert, unter Umständen den bei Frame 499 berechneten Simulationszustand benötigt. Farmen lösen das, indem sie zuerst den Simulations-/Caching-Durchlauf ausführen (oft single-threaded oder auf wenigen Workern) und anschließend den rein visuellen Render-Durchlauf über den gesamten Pool verteilen, sobald der Cache existiert. Nutzt Ihr Projekt speziell After Effects, behandelt unser Setup-Leitfaden für After-Effects-Cloud-Rendering dieses zweistufige Muster (Bildsequenz-Rendering über die gesamte Flotte, dann ein Single-Worker-Adobe-Media-Encoder-Durchlauf) genauer, einschließlich der genauen aerender-Befehlsstruktur. Für Motion-Design-Pipelines im weiteren Sinne - Cinema 4D, After Effects und die Plugin-Stacks, die für Titelsequenzen und Werbespots üblich sind - behandelt unser Leitfaden zu render farms für Motion Design workflow-spezifische Überlegungen.

Was kostet das? Ein durchgerechnetes Beispiel

Die Preisgestaltung von Render-Services basiert normalerweise auf Recheneinheiten statt auf einer pauschalen Rate pro Video, weil eine 10-Sekunden-Titelkarte und ein 60-Sekunden-VFX-lastiger Werbespot selbst bei gleicher Auflösung und Frame-Anzahl sehr unterschiedliche Rechenleistung verbrauchen. Auf unserer Farm wird CPU-Rendering mit $0,004 pro GHz-Stunde abgerechnet und GPU-Rendering mit $0,003 pro OctaneBench-Stunde (OBh) - eine RTX 5090 (32 GB VRAM) läuft bei diesem Basissatz auf ungefähr $5,2 pro Karten-Stunde. Die Render-Engine-Lizenzierung (V-Ray, Corona, Arnold, Redshift, Octane) ist im Satz enthalten statt separat abgerechnet zu werden; Cycles ist kostenlos und Open Source.

Hier ein anschauliches Beispiel, damit die Zahlen greifbar werden. Angenommen ein 30-sekündiges Produktvisualisierungs-Video in 1920×1080, 24fps - das sind 720 Frames.

CPU-Pfad (V-Ray oder Corona, Standard-Priorität): Angenommen, zur Veranschaulichung, im Durchschnitt 6 Minuten Renderzeit pro Frame auf einem unserer CPU-Nodes (Dual Intel Xeon E5-2699 V4, 44 Kerne bei 2,2 GHz Basistakt - ungefähr 96,8 GHz-Äquivalent an aggregierter Taktfrequenz pro Node).

• Rechenleistung pro Frame: (6 Minuten ÷ 60) × 96,8 GHz = 9,68 GHz-Stunden
• Kosten pro Frame: 9,68 × $0,004 = $0,0387
• Gesamt für 720 Frames: 720 × $0,0387 ≈ $27,90

GPU-Pfad (Redshift oder Octane, RTX 5090): Angenommen, zur Veranschaulichung, im Durchschnitt 2 Minuten Renderzeit pro Frame auf einer GPU-Karte.

• Rechenleistung pro Frame: 2 Minuten ÷ 60 = 0,033 Karten-Stunden
• Kosten pro Frame: 0,033 × $5,2 ≈ $0,173
• Gesamt für 720 Frames: 720 × $0,173 ≈ $124,80

Bei diesem Vergleich sind zwei Dinge bemerkenswert. Erstens fällt der GPU-Posten in diesem konkreten Beispiel höher aus, was der reflexartigen Annahme widerspricht, GPU-Rendering sei automatisch die günstigere Option - es hängt stark davon ab, wie viel schneller (oder nicht) Ihre konkrete Szene auf der GPU im Vergleich zur CPU rendert, und wie gut der GPU-Pfad Ihrer Render-Engine mit dem spezifischen Feature-Set der Szene umgeht (starkes Displacement, bestimmte Shader-Graphen und Szenen, die den VRAM sprengen, können einen GPU-Geschwindigkeitsvorteil vollständig zunichtemachen). Zweitens ändert sich keine der beiden Gesamtsummen, wenn Sie den Job auf mehr oder weniger Worker-Nodes verteilen - Parallelität verändert die Durchlaufzeit, nicht die verbrauchte Gesamtrechenleistung, denn Sie zahlen für tatsächlich genutzte GHz-Stunden oder Karten-Stunden, nicht für Wanduhrzeit. 720 Frames auf 30 Nodes zu verteilen ist ungefähr 30-mal schneller fertig, als sie auf einem einzelnen Node laufen zu lassen - die Rechnung bleibt in beiden Fällen gleich.

Die Encoding-Kosten sind normalerweise nur ein kleiner Zuschlag zur Render-Gesamtsumme - das Encoding einer 720-Frame-Sequenz nach H.264 läuft deutlich schneller ab als das Rendern derselben Frames aus einer 3D-Szene, da es sich um eine wesentlich leichtere Rechenoperation pro Frame handelt. Der Render-Posten ist derjenige, den es zu optimieren lohnt; der Encoding-Schritt fällt bei den meisten Jobs kaum ins Gewicht, außer die Deliverable-Liste erfordert mehrere separate Encoding-Durchläufe in unterschiedlichen Auflösungen oder Codecs.

Das sind anschauliche Zahlen, um die Rechnung nachvollziehbar zu machen, kein Angebot für ein konkretes Projekt - die tatsächlichen Frame-Zeiten hängen stark von Szenenkomplexität, Auflösung, Sampling-Einstellungen und den eingesetzten Effekten ab. Eine umfassendere Tabelle mit Frame-Zeitspannen für Archviz- und Animations-Szenentypen finden Sie in unserem Leitfaden zu Kosten pro Frame. Unser Cost Calculator liefert eine projektspezifische Schätzung, und eine kleine Test-Frame-Einreichung vor dem vollständigen Job ist der zuverlässigste Weg, um reale Zahlen für Ihre eigene Szene zu bestätigen.

Wann sich ein Video-Rendering-Service lohnt - und wann lokales Rendering

Lokales Rendering ist sinnvoll, wenn: der Job kurz genug ist, dass die lokale Renderzeit Ihren Zeitplan nicht blockiert, Ihre Workstation genügend VRAM- oder CPU-Spielraum für die Szene hat und Sie sich in der Look-Dev-Phase befinden, in der schnelle lokale Feedback-Zyklen wichtiger sind als finaler Durchsatz in Endqualität. Lokales Rendering spart außerdem die Upload-Zeit für große Asset-Bibliotheken, was bei einer langsamen Verbindung ins Gewicht fallen kann.

Ein Video-Rendering-Service lohnt sich, wenn: die Frame-Anzahl oder die Komplexität pro Frame dazu führt, dass die lokale Renderzeit den Zeitplan auffrisst (ein nächtliches lokales Rendering, das erst am nächsten Tag mittags fertig ist, ist ein reales Produktionsrisiko, kein hypothetisches), Sie mehr Render-Kapazität benötigen, als Ihre lokale Hardware bietet - ohne zusätzliche Maschinen zu kaufen -, oder Sie Output in Endqualität rendern, während Ihre Workstation für die Look-Dev-Arbeit am nächsten Projekt frei bleiben soll. Es spielt auch eine Rolle, wenn eine Deadline mehrere parallele Deliverables verlangt - ein 4K-Master, ein komprimierter Web-Cut und ein vertikaler Social-Crop, von denen jedes einen eigenen Render-plus-Encoding-Durchlauf braucht und sich auf einer einzelnen lokalen Maschine schnell summiert.

Die beiden schließen sich innerhalb eines Projekts nicht gegenseitig aus: Ein gängiges Muster ist Look-Dev und Iteration lokal, dann ein einzelnes finales Rendering an die Farm, sobald die Szene final ist - so bekommen Sie schnelles lokales Feedback in der kreativen Phase und verteilten Durchsatz in der Deliverable-Phase.

Häufige Probleme beim Cloud-Video-Rendering

Fehlende oder ungelöste Assets. Die häufigste Ursache für einen fehlgeschlagenen oder teilweise fehlgeschlagenen Video-Render-Job. Über einen absoluten lokalen Pfad referenzierte Texturen, auf der Worker-Flotte nicht installierte Schriftarten oder ein plugin-abhängiger Effekt, für den die Farm keine Lizenz hat, tauchen hier am häufigsten auf. Ein Asset-Scan vor der Einreichung fängt die meisten davon ab, bevor Rechenzeit verbraucht wird.

Simulationsabhängige Frames, die außer der Reihe gerendert werden. Wenn in eine Szene eine Fluid-, Cloth- oder Partikelsimulation direkt ins Rendering eingebacken ist (statt vorab auf die Festplatte gecacht zu sein), kann die Verteilung der Frames auf Worker ohne vorherige Erzeugung des Simulations-Caches zu inkonsistenten Ergebnissen von Frame zu Frame führen, da jeder Worker seinen Abschnitt unabhängig berechnet. Die Lösung ist, zuerst die Simulation zu cachen und dann den rein visuellen Render-Durchlauf zu verteilen.

Encoding-Artefakte an Segmentgrenzen. Wird ein Encoding-Job doch auf Worker verteilt (manche Pipelines versuchen das, um Zeit zu sparen), können an den Nahtstellen der Segmente sichtbare Nähte oder Helligkeits-/Farbverschiebungen entstehen. Deshalb wird der Encoding-Schritt normalerweise als einzelner Durchlauf ausgeführt statt genauso verteilt wie das Frame-Rendering.

Abweichende Framerate oder Farbraum bei der Lieferung. Ein Rendering, das mit der falschen Framerate eingerichtet wurde, oder ein Encoding, das nicht zum Farbraum passt, in dem die Frames gerendert wurden, ergibt ein technisch vollständiges Video, das trotzdem nicht den Erwartungen des Kunden entspricht. Framerate, Auflösung und Farbraum (sowie ob das Deliverable broadcast-sicher sein muss) vor der Einreichung zu bestätigen, vermeidet ein erneutes Rendering.

Zusammenfassende Checkliste

FAQ

Q: Was ist ein Video-Rendering-Service? A: Ein Video-Rendering-Service ist ein Anbieter, der Video-Output aus einer 3D-Szene oder einem Motion-Graphics-Projekt auf externer Hardware statt auf Ihrer eigenen Workstation rendert und dabei sowohl das frame-weise Rendering als auch das finale Encoding in eine abspielbare Videodatei übernimmt (typischerweise H.264 oder H.265). Er unterscheidet sich von einem reinen Transcoding-Service, der lediglich eine bereits vorhandene Videodatei neu encodiert, statt Frames aus einer Szene zu rendern.

Q: Wie funktioniert verteiltes Video-Rendering eigentlich? A: Ein Render-Manager teilt die gesamte Frame-Anzahl auf verfügbare Worker-Nodes auf, da die meisten Frames eines Videos unabhängig voneinander gerendert werden können. Jeder Worker rendert seinen zugewiesenen Frame-Bereich parallel, sodass eine Sequenz, die auf einer Maschine Stunden dauern würde, über viele Worker deutlich schneller fertig ist. Der Encoding-Schritt, der die fertigen Frames in eine einzelne Videodatei umwandelt, läuft danach in der Regel als einzelner Durchlauf statt auf dieselbe Weise verteilt, weil Video-Codecs zeitliche Kompression nutzen, die sich nicht sauber auf Worker aufteilen lässt.

Q: Warum beschleunigt sich Encoding nicht auf dieselbe Weise wie Rendering, wenn ich mehr Worker hinzufüge? A: Weil es normalerweise einen Encoding-Job pro Deliverable gibt, nicht einen pro Frame. Frame-Rendering parallelisiert, weil jeder Frame (meistens) unabhängig berechnet werden kann. Das Encoding einer Frame-Sequenz nach H.264 oder H.265 benötigt in der Regel die gesamte Sequenz in der richtigen Reihenfolge, da spätere Frames im komprimierten Output aus früheren vorhergesagt werden. Wird ein Encoding-Job auf Worker verteilt, drohen sichtbare Nähte an den Stellen, wo die Teile wieder zusammengefügt werden - deshalb führen die meisten Farmen ihn stattdessen als einzelnen Durchlauf aus.

Q: Was kostet Cloud-Video-Rendering? A: Die Kosten richten sich nach der insgesamt verbrauchten Rechenleistung (GHz-Stunden für CPU, OctaneBench-Stunden für GPU), nicht nach einer pauschalen Rate pro Video. Auf unserer Farm wird CPU-Rendering mit $0,004 pro GHz-Stunde abgerechnet und GPU-Rendering mit $0,003 pro OBh (eine RTX 5090 kostet bei diesem Satz etwa $5,2 pro Karten-Stunde), inklusive Render-Engine-Lizenzierung. Ein 30-sekündiges Video mit 720 Frames kann je nach Szenenkomplexität, Engine und ob die konkrete Szene auf CPU oder GPU schneller rendert, zwischen etwa $25 und deutlich über $100 kosten - es gibt keine einzelne Zahl, die projektübergreifend gilt. Ein Test-Frame-Rendering ist der zuverlässigste Weg, um einen konkreten Job zu schätzen.

Q: Ändert das Rendern auf mehr Maschinen die Gesamtkosten? A: Nein. Die Verteilung eines Jobs auf mehr Worker-Nodes verändert die Durchlaufzeit, nicht die verbrauchte Gesamtrechenleistung - Sie werden für die tatsächlich zum Rendern der Frames genutzten GHz-Stunden oder Karten-Stunden abgerechnet, unabhängig davon, wie viele Nodes sie parallel verarbeitet haben. 100 Frames auf 10 statt auf 1 Node zu rendern, ist ungefähr 10-mal schneller fertig, kostet aber insgesamt dieselbe Rechenleistung.

Q: Sollte ich Video lokal rendern oder einen Cloud-Video-Rendering-Service nutzen? A: Das hängt von Frame-Anzahl, Deadline-Druck und Hardware ab. Kurze Renderings, die Ihren Zeitplan nicht blockieren, oder aktive Look-Dev-Iteration, bei der schnelles lokales Feedback wichtiger ist als Durchsatz, funktionieren meist gut lokal. Lange Sequenzen, enge Deadlines oder mehrere gleichzeitige Deliverables (ein 4K-Master plus mehrere komprimierte Cuts) sind die Fälle, in denen sich die verteilte Kapazität eines Cloud-Services lohnt, da lokales Rendering Ihre Workstation für die gesamte Dauer blockiert.

Q: Welche Videoformate und Codecs unterstützt Cloud-Video-Rendering typischerweise? A: Die meisten Video-Rendering-Services unterstützen H.264 und H.265/HEVC als Standard-Delivery-Codecs, zusätzlich zu verlustfreien Zwischenformaten (EXR, PNG, DPX-Bildsequenzen) für Pipelines, die an eine nachgelagerte Compositing- oder Color-Grading-Stufe übergeben statt eine fertige Videodatei liefern müssen. Codec-Lizenzierung und Encoder-Verfügbarkeit (insbesondere ProRes) variieren je nach Anbieter und Plattform (Windows- vs. macOS-Worker) - es lohnt sich, das direkt zu bestätigen, falls Ihr Deliverable einen bestimmten Codec erfordert. Unser Encoding-Leitfaden behandelt die praktischen Unterschiede zwischen H.264, H.265 und AV1 für die Auslieferung.

Q: Kann ein Video-Rendering-Service Simulationen wie Fluids oder Partikel verarbeiten? A: Ja, aber der Workflow unterscheidet sich von einem rein frame-unabhängigen Rendering. Simulationen mit zeitlichen Abhängigkeiten (jeder Frame hängt vom Zustand des vorherigen Frames ab) werden normalerweise zuerst auf die Festplatte gecacht - oft auf wenigen Workern, manchmal auf einem einzigen -, und der visuelle Render-Durchlauf, der aus diesem Cache liest, wird anschließend genauso über den gesamten Worker-Pool verteilt wie bei einer nicht-simulierten Szene. Der Versuch, die Simulation selbst ohne vorab erzeugten Cache auf unabhängige Worker zu verteilen, kann zu inkonsistenten Ergebnissen zwischen den Frames führen.