Render-Qualitätsprobleme beheben

Render-Qualitätsprobleme unterscheiden sich von Render-Fehler-Problemen. Ein Fehler bedeutet, dass der Job nicht abgeschlossen wurde. Ein Qualitätsproblem bedeutet, dass er abgeschlossen wurde, das Ergebnis aber falsch ist — zu hell, zu dunkel, fehlende Geometrie, die falsche Kamera, eine Ausgabe, die nicht dem entspricht, was Sie in Ihrem Viewport sehen. Diese Probleme sind fast immer Konfigurationsprobleme statt Infrastrukturprobleme, was bedeutet, dass sie auf Ihrer Seite lösbar sind, wenn Sie wissen, wo zu suchen ist.

Diese Seite führt durch die Render-Qualitätsprobleme, die wir am häufigsten auf der Farm sehen, geordnet nach Symptom. Für die Fehlerbehebung bei Job-Fehlern — Jobs, die überhaupt nicht abgeschlossen werden, mitten in einem Frame abstürzen oder Fehlercodes zurückgeben — siehe . Für DCC-spezifische Setup-Details und die Render-Zeit-Einstellungen, die für jede Engine am wichtigsten sind, sehen Sie das relevante setting-up-*-Dokument.

Eine nützliche Arbeitsregel, die wir täglich im Support anwenden: Render-Qualitätsprobleme sind fast immer reproduzierbar. Wenn ein Rendering falsch von der Farm zurückkommt, produziert dieselbe Szene lokal gerendert — gleiche Engine, gleiche Version, gleiche Einstellungen, gleiche Szenendatei — meist dieselbe falsche Ausgabe. Diese Reproduzierbarkeit ist der Diagnoseschlüssel. Wenn lokal gleich wie Farm ist, liegt das Problem in der Szene und Sie können es reparieren, ohne Farm-seitig etwas zu berühren. Wenn lokal sich von Farm unterscheidet, liegt das Problem in der Umgebung: ein Pfad-Mismatch, ein Versions-Mismatch, ein fehlendes Asset oder eine Konfiguration, die mit Ihrer Workstation reist aber nicht mit der Szenendatei.

Die nachstehenden Abschnitte folgen dieser diagnostischen Logik, geordnet nach der Häufigkeit, mit der wir jedes Muster in der Support-Leitung sehen.

Helligkeits- oder Farb-Mismatch gegenüber lokalem Rendering

Dies ist die häufigste Qualitätsbeschwerde, die wir sehen, und zwar mit weitem Abstand. Das Rendering kommt heller, dunkler, gesättigter oder sichtbar anders in der Farbe zurück als das, was Ihr lokaler Viewport zeigt. Fast immer ist die Ursache das Farbmanagement — der Worker interpretiert die lineare, sRGB- oder Filmic-Pipeline anders als Ihr Workstation-Viewport, oder die Farbraum-Kennzeichnung der Textur ist inkonsistent.

Fünf zu überprüfende Dinge in der Reihenfolge der Häufigkeit:

View-Transform-Mismatch. In Blender befindet sich das unter Render-Eigenschaften → Farbmanagement → View Transform. Standard ist Filmic. Wenn Ihr Workstation-Viewport Filmic zeigt, aber die gespeicherte Szenendatei auf Standard (oder umgekehrt) gesetzt ist, verwendet die gerenderte Ausgabe den gespeicherten Wert, nicht den Viewport-Zustand. In Maya ist das Äquivalent das Farbmanagement in Render-Einstellungen → Allgemein (mit ACES, sRGB oder Raw als häufigen Optionen). In 3ds Max prüfen Sie die Gamma- und LUT-Einstellungen unter Anpassen → Einstellungen → Gamma und LUT. In Cinema 4D schauen Sie unter Render-Einstellungen → Ausgabe → Farbprofil. Der Viewport kann einen Transform zeigen, während die gespeicherte Datei einen anderen angibt — der Renderer verwendet den gespeicherten Wert.
Textur-Farbraum-Kennzeichnung. Texturen, die als Farbdaten verwendet werden (Diffuse, Albedo, Basis-Farbe), sollten als sRGB oder Farbe gekennzeichnet sein. Texturen, die als Daten verwendet werden (Normal-Maps, Rauheit, Displacement, Metallic, Opazität), sollten als Nicht-Farbe, Linear oder Raw gekennzeichnet sein. Eine als sRGB gekennzeichnete Normal-Map verursacht subtilen, aber durchdringenden Beleuchtungs-Drift — die Mathematik funktioniert nicht richtig, wenn die Textur eine zusätzliche Gamma-Kurve durchläuft. Durchsuchen Sie Ihren Shader-Graphen oder Textur-Browser vor der Einreichung. Dies ist die häufigste Einzelursache für „mein Rendering sieht ausgewaschen aus"-Tickets.
OCIO-Konfigurations-Drift. Wenn Ihre Workstation eine benutzerdefinierte OCIO-Konfiguration verwendet — ACES 1.3, AgX, eine studio-spezifische Konfiguration — müssen die OCIO-Konfigurationsdateien in Ihrem Projektarchiv enthalten sein, und die Projektdatei muss sie über einen relativen Pfad referenzieren (nicht über einen absoluten Pfad, der nur auf Ihrem Rechner existiert). Wenn der Worker hochfährt und Ihre Szene liest, sucht er die OCIO-Konfiguration unter dem in der Szenendatei angegebenen Pfad. Wenn die Datei nicht da ist, fällt der Renderer lautlos auf seine Standard-Konfiguration zurück (typischerweise Filmic für Blender, sRGB für die meisten anderen), und Ihre Farben driften.
Ausgabeformat kodiert Farbe anders als erwartet. Ausgabeformate, die keine Farbraum-Metadaten tragen — PNG, JPEG, BMP — brennen den Display-Transform in die Pixel-Werte ein. EXR (linear, 32-Bit) bewahrt die rohen, szenenreferenzierten Daten und wendet den View-Transform in der Compositor-Phase an. Wenn Sie ein PNG-Ergebnis von der Farm mit einem EXR-Ergebnis desselben Renderings vergleichen, sehen sie absichtlich unterschiedlich aus. Das ist kein Fehler; so funktionieren die Formate. Wenn Sie beide mit dem passenden View-Transform in Ihrem Compositor betrachten, sollten sie übereinstimmen.
Belichtungs- oder Nachbearbeitungs-Drift. Manche DCCs speichern eine Nachbearbeitungs-„Look"- oder Belichtungskompensation in der Szenendatei, wenden sie aber beim Rendering anders an. Prüfen Sie den Render-Ausgabe-Node, die Belichtungseinstellung der Kamera und alle Compositing-Nodes downstream vom Render-Layer. Eine −0,5-EV-Viewport-Belichtung, die zur Render-Zeit nicht angewendet wird, produziert ein Rendering, das eine halbe Blendenstufe heller als erwartet ist.

Der diagnostische Test, den wir bei jedem Helligkeits-Ticket empfehlen: rendern Sie denselben Frame der problematischen Szene lokal auf Ihrer eigenen Workstation mit denselben Einstellungen wie die Farm-Einreichung. Wenn lokal gleich wie Farm ist, ist das Farbmanagement Ihrer Szene so konfiguriert, wie es ist — der Viewport zeigt nur eine andere Interpretation. Wenn lokal sich von Farm unterscheidet, prüfen Sie zuerst OCIO-Konfigurations-Einschluss und Textur-Farbraum-Kennzeichnungen.

Kamera nicht erkannt oder „keine Kamera in der Szene"

Der Renderer kann keine Kamera finden, von der er rendern kann. Der Job bricht ab, bevor Frames produziert werden, oder die Ausgabe ist leer / Standard-Viewport. Drei häufige Ursachen:

Keine als renderfähig markierte Kamera. In Maya bestimmt Render-Einstellungen → Allgemein → Renderbare Kameras, welche Kamera rendert. Der Standard ist persp, also die Perspektivansicht aus Ihrem Modellierungs-Viewport — selten das, was Sie für einen finalen Shot möchten. Setzen Sie das renderfähige Flag auf der Kamera, die Sie tatsächlich möchten. In Blender ist die aktive Kamera der Szene (Eigenschaften → Szene-Eigenschaften → Kamera) diejenige, die rendert, und nur diese eine. In Cinema 4D überschreibt das Feld Render-Einstellungen → Ausgabe → Kamera, welche Kamera rendert, wenn gesetzt; andernfalls wird die aktive Kamera des Editors verwendet. In 3ds Max wählt Render-Setup → Allgemein → Kamera (oder das View-Dropdown) die Render-Kamera.
Die renderbare Kamera ist ausgeblendet. In manchen DCCs (insbesondere Maya) ist eine im Outliner ausgeblendete Kamera noch renderbar, solange sie in den Render-Einstellungen als renderbar markiert ist. In anderen (insbesondere Blender, wo die aktive Kamera für den „Kamera-Ansicht"-Modus im Viewport sichtbar sein muss) wirkt das Ausblenden der Kamera nicht direkt auf das Rendering — aber wenn Sie Ihre Szene kürzlich neu strukturiert haben, überprüfen Sie, dass die erwartete Kamera in der aktiven Szene ist und nicht in einer separaten Sammlung, einem Render-Layer, einem Take oder einer Szene, die nicht ausgewählt ist.
Gesperrter Viewport überschreibt die renderbare Kamera. In 3ds Max und Maya kann ein „Gesperrter Viewport"-Muster dazu führen, dass der Renderer die aktuelle Kamera des Viewports statt der von Ihnen beabsichtigten Kamera verwendet. Dies erscheint entweder als „keine Kamera" (wenn der Viewport auf einer Nicht-Kamera-Perspektivansicht ist, die der Renderer ablehnt) oder als „falsche Kamera" (der nächste Abschnitt). Entsperren Sie den Viewport vor der Einreichung, oder setzen Sie explizit Ansicht auf Rendern im Render-Setup.

Für DCC-spezifische Kamerakonfiguration, sehen Sie , , oder .

Gerenderte Szene hat keine Lichter

Die Geometrie rendert, aber die Szene ist komplett dunkel, oder die Beleuchtung ist viel dunkler als erwartet — oft ein Drahtgitter-auf-Schwarz-Look, der darauf hindeutet, dass kein Licht die Oberflächen erreicht.

Vier zu überprüfende Dinge:

Lichter sind in der Render-Sichtbarkeit deaktiviert. In Maya haben Lichter ein Render-Sichtbarkeits-Flag pro Render im Attribut-Editor (Sichtbarkeit → Rendern). Ein im Outliner sichtbares Licht kann trotzdem von der Render-Zeit-Berechnung ausgeschlossen sein. In Blender steuert der Render-Sichtbarkeitsschalter des Licht-Objekts (das Kamera-Symbol im Outliner), ob das Licht zum Rendering beiträgt — getrennt vom Auge-Symbol-Viewport-Schalter.
Lichter befinden sich auf einem ausgeblendeten View-Layer, Render-Layer oder einer Sammlung. Ein im Viewport sichtbares, aber einem nicht-gerenderten Layer zugewiesenes Licht trägt nicht bei. Überprüfen Sie, dass Lichter auf dem Layer oder der Sammlung sind, der/die gerendert wird, nicht auf einem Geschwister-Layer, der zur Render-Zeit ausgeblendet ist.
Umgebungsbeleuchtung ist deaktiviert. Wenn Ihre Szene auf HDRI-Umgebungsbeleuchtung angewiesen ist — verbreitet bei Archviz und Produktvisualisierung — überprüfen Sie, dass die Umgebung in den Render-Eigenschaften aktiviert ist. In Blender muss Welt → Oberfläche die Umgebungs-Textur- oder Hintergrund-Shader-Verbindung haben. In Maya muss der Hypershade-Umgebungs-Node in den Render-Zeit-Umgebungs-Slot der Szene eingesteckt sein. In 3ds Max muss Umgebung und Effekte (Tastaturkürzel 8) die HDRI zugewiesen haben, und in V-Ray ist die V-Ray-Umgebungs-Überschreibung eine separate Einstellung, die die Szenenumgebung überschreibt.
GI oder Indirekte Beleuchtung ist deaktiviert. Für V-Ray und Corona ist die Globale Beleuchtung eine separate Einstellung von „Lichter in der Szene vorhanden". Eine für GI-Bounces ausgelegte Szene, aber mit in der aktiven Render-Voreinstellung deaktiviertem GI, erscheint dunkel, selbst wenn jedes direkte Licht korrekt konfiguriert ist. In V-Ray muss GI → Globale Beleuchtung aktivieren eingeschaltet sein. In Corona muss GI → Solver gesetzt sein (Pfad-Tracing oder UHD-Cache). In Redshift muss GI → GI aktivieren eingeschaltet sein. Sehen Sie den für die engine-spezifische GI-Cache-Konfiguration, die auf diese Aktivierung folgt.

Ein schneller diagnostischer Test: Fügen Sie vorübergehend ein einzelnes Sonnen- oder Richtungslicht mit Intensität 1,0 von oben der Szene hinzu und rendern Sie einen Frame. Wenn sogar dieses nicht in der Ausgabe erscheint, liegt das Problem bei der Layer- oder Sammlungs-Sichtbarkeit, nicht bei der Lichtquellen-Konfiguration. Wenn die Test-Sonne korrekt rendert, sind Ihre ursprünglichen Lichter das Problem — arbeiten Sie durch die vier Überprüfungen oben zurück.

Falsche Kamera rendert trotz Angabe der richtigen

Sie haben Kamera A als Render-Kamera gesetzt, aber die Ausgabe zeigt die Ansicht von Kamera B. Dies ist eines der frustrierenderen Qualitätsprobleme, weil die Szenendatei bei der Prüfung korrekt aussieht — das renderfähige Flag ist auf der richtigen Kamera, die aktive Kamera ist die gewünschte. Die Ursache ist fast immer eine der drei folgenden:

Ansicht am Viewport in 3ds Max oder Maya gesperrt. Ein gesperrter Viewport (Rechtsklick Viewport-Bezeichnung → Sperren) überschreibt die Render-Setup-Kameraauswahl. Der Renderer verwendet die Viewport-Kamera, nicht die, die Sie konfiguriert haben. Entsperren Sie den Viewport vor dem Speichern der Szene, oder setzen Sie explizit Ansicht auf Rendern in Render-Setup → Allgemein (Maya) oder Render-Setup → Ausgabe (3ds Max). Dies ist die häufigste Ursache für „falsche Kamera"-Tickets bei 3ds-Max-Einreichungen — die Sperre ist leicht mit einem Tastaturkürzel versehentlich zu setzen und leicht vor der Einreichung zu übersehen.
Multi-Kamera-Szene mit der falschen aktiven Kamera. Wenn Ihre Szene mehrere Kameras hat — Drehscheibe, Held, Beauty, Detail, Alts — überprüfen Sie, welche als aktive Kamera für die aktuelle Szene, den Take oder den Render-Layer gesetzt ist. In Cinema 4D kann jeder Take seine eigene Kamera haben; in Blender hat jede Szene ihre eigene aktive Kamera; in Maya können Render-Setup-Layer die Kamera pro Layer überschreiben. Die Kamera, die rendert, ist die Kamera, die auf dem Layer-/Take-/Szenen-Niveau zugewiesen ist, das Sie eingereicht haben, nicht die, die Sie zuletzt im Viewport ausgewählt haben.
Take-, Szenen- oder Render-Layer-Mismatch. Render-Layer A eingereicht, aber er erbt seine Kamera von Master, und Masters Kamera ist Kamera B? Das passiert. Reichen Sie immer vom Take oder Layer ein, der explizit die gewünschte Kamera hat, und vermeiden Sie es, sich auf Vererbung zu verlassen, außer Sie haben die Kette verifiziert.

Phase 2D wird diesen Abschnitt mit einem Vorher-Nachher-Paar ergänzen: gesperrter-Viewport-Einreichung (falsche Kamera gerendert) vs. entsperrter-Viewport-Einreichung (richtige Kamera gerendert) auf derselben Szenendatei.

Ausgabebild ist teilweise, beschnitten oder kein vollständiger Frame

Das gerenderte Bild kommt zurück, aber nur ein Teil des Frames ist gefüllt — der Rest ist schwarz, transparent oder wiederholt die Viewport-Farbe. Vier zu überprüfende Dinge:

Render-Region ist aktiviert. In V-Ray, Corona, Arnold und mehreren anderen Renderern erlaubt eine „Region"-Option das Rendern nur eines Teilrechtecks des vollständigen Frames für schnelle Vorschau. Wenn Region während des lokalen Tests aktiviert und vor der Einreichung nicht deaktiviert wurde, rendert der Worker nur diese Region — der Rest des Frames bleibt bei seiner Standard-Füllfarbe. Dies ist die häufigste Einzelursache für Teil-Frame-Ausgabe-Tickets.
Ausgabeauflösungs-Mismatch zwischen Szene und Render-Einstellung. Die Render-Eigenschaften-Ausgabeauflösung und die tatsächliche Framegröße in der Ausgabedatei müssen übereinstimmen. Wenn die Kamerablende Ihrer Szene auf eine Auflösung gesetzt ist und Ihre Ausgabe auf eine andere, produziert der Renderer möglicherweise eine teilweise Füllung — die Kamera „sieht" einen kleineren Bereich als das Ausgabe-Canvas, und die leere Region bleibt ungefärbt.
Seitenverhältnis-Mismatch zwischen Kamera und Ausgabe. Eine Kamera mit einem 1,78-Seitenverhältnis, die auf eine 1,0-Ausgabe rendert, produziert ein teilweises Bild — die Kameraansicht füllt nicht den Ausgabe-Frame. Überprüfen Sie, dass das Filmrücken-Seitenverhältnis der Kamera mit dem Ausgabe-Seitenverhältnis übereinstimmt, oder dass „Auflösungs-Gate-Anpassung" (oder das Äquivalent — verschiedene DCCs benennen dies unterschiedlich: „Resolution Gate Fit", „Camera Aperture", „Film Gate") auf Füllen, Horizontal, Vertikal oder Überscan gesetzt ist, wie es Ihr Shot erfordert.
Rahmen- oder Beschnitt-Einstellungen im Ausgabeformat. Manche DCCs und manche Ausgabeformate ermöglichen die Einstellung eines Render-Rahmens unabhängig vom Auflösungs-Gate der Kamera. Überprüfen Sie, dass der Rahmen (in Render-Eigenschaften oder in den Kamera-Attributen) den vollständig beabsichtigten Ausgabebereich abdeckt, nicht eine beschnittene Unterregion.

Schwarze oder leere Renderings

Das Rendering wird erfolgreich abgeschlossen — keine Fehler, keine Warnungen — aber jeder Pixel ist schwarz oder vollständig einheitlich. Am häufigsten bei Maya, aber wir sehen es über alle DCCs hinweg.

Fünf zu überprüfende Dinge:

Layer-Umschalt-Mismatch. In Maya kann Geometrie im Viewport sichtbar, aber auf der Render-Zeit-Sichtbarkeitsebene deaktiviert sein (Anzeigen → Ausblenden → Alle Kameras ausblenden, oder per-Objekt Render-Stats → Primäre Sichtbarkeit = aus). In Blender ist das Äquivalent der Render-Sichtbarkeits-Schalter (Kamera-Symbol) im Outliner. Die häufigste Ursache ist das Umstrukturieren der Layer einer Szene nach dem Testen und das Vergessen, die Render-Sichtbarkeit auf dem neuen Layer oder der neuen Sammlung zu aktivieren.
Kamera-Clipping-Ebenen falsch gesetzt. Wenn die nahe oder ferne Clipping-Ebene falsch gesetzt ist — ferne Ebene zu nah an der Kamera, nahe Ebene hinter der Geometrie — schließt die Kamera die Geometrie nicht in ihren Ansichtsfrustum ein. Standard-Ebenen (Nah 0,1, Fern 1000–10000 je nach Szenenmaßstab) sind normalerweise in Ordnung; dies tritt nach manueller Anpassung auf, insbesondere bei ungewöhnlichen Szenenmaßstäben (große Architektur-Sets oder mikroskopische Produkt-Renderings).
Renderbare Lichter, aber Emission deaktiviert. Wenn Sie emissive Materialien als Lichter verwenden, überprüfen Sie, dass der Emissions-Shader aktiviert ist und nicht-nullwertige Stärke hat. Manche Workflows schalten die Emission während der Viewport-Interaktion aus, um GPU-Wärme zu vermeiden, und vergessen, sie vor der Einreichung wieder zu aktivieren.
Sampling zu niedrig für sichtbare Ausgabe. Mit aggressiven Path-Trace-Sampling-Reduzierungen (sehr niedrige Samples-pro-Pixel) können sehr dunkle Szenen eine vollständig schwarze Ausgabe produzieren, bis die Samples ausreichend konvergieren. Rendern Sie einen Frame lokal mit denselben Einstellungen zur Überprüfung; wenn das lokale Rendering bei derselben Sample-Anzahl auch vollständig schwarz ist, erhöhen Sie das Sampling oder prüfen Sie das Beleuchtungs-Setup.
Render-Ausgabe-Node falsch konfiguriert (Blender, Houdini). In Blenders Compositor und in Houdinis ROP-Netzwerk kann die Ausgabe-Node-Kette so konfiguriert werden, dass das Render-Ergebnis vor dem Speichern verworfen wird. Überprüfen Sie, dass der Composite-Node mit Render-Layern verbunden ist (Blender) oder der Ausgabepfad des ROP korrekt gesetzt ist und der Ausgabemodus nicht „Null" ist (Houdini).

Speziell für Maya sehen Sie für den Kameraauswahl- und Render-Stats-Workflow, der die häufigste Ursache für schwarze Renderings bei diesem DCC verhindert. Phase 2D wird diesen Abschnitt mit einem Vorher-Nachher-Bild ergänzen: typisches Schwarz-Frame-Symptom + der Layer-Sichtbarkeits-Schalter, der es gelöst hat.

Einige Objekte in der Szene rendern nicht

Ein bestimmtes Objekt ist im Viewport sichtbar, fehlt aber in der gerenderten Ausgabe. Der Rest der Szene rendert korrekt. Verbreitet über alle DCCs, etwas häufiger bei Blender, weil Blenders Drei-Wege-Sichtbarkeitsmodell (Viewport / Render / Auswahl) leicht falsch konfiguriert werden kann.

Fünf zu überprüfende Dinge:

Render-Sichtbarkeits-Schalter am Objekt. Im Blender-Outliner bewegen Sie den Mauszeiger über die Objektzeile — drei Symbole steuern die Sichtbarkeit: Auge (Viewport), Kamera (Render), Bildschirm (Auswählbarkeit). Stellen Sie sicher, dass das Kamera-Symbol für das fehlende Objekt aktiviert ist. In Maya muss Attribut-Editor → Render-Stats → Primäre Sichtbarkeit aktiviert sein. In 3ds Max muss Objekt-Eigenschaften → Rendern → Sichtbarkeit des Objekts über 0 liegen (und Renderbar muss angehakt sein).
Objekt befindet sich auf einer ausgeblendeten Sammlung, einem Layer oder Set. Sammlungen in Blender haben separate Viewport- und Render-Sichtbarkeit. Die Sammlung kann im Viewport sichtbar sein, aber über den Kamera-Symbol-Schalter an der Sammlungszeile vom Rendering ausgeschlossen sein. In Maya sind die Display-Layer-Zuweisung und die Render-Layer-Zuweisung des Objekts getrennt; in 3ds Max muss Layer-Eigenschaften → Renderbar für jeden Layer mit renderbarer Geometrie aktiviert sein.
Das Material des Objekts ist unsichtbar. Ein Material mit null Opazität, null Alpha oder Alpha-Blending-Problemen rendert effektiv unsichtbar — die Geometrie ist da, aber transparent. Überprüfen Sie die Opazität, das Alpha, die Transparenz und alle Alpha-Blend-Einstellungen des Materials. Häufiges Problem: ein Material, das für „Ghost"-Referenz im Viewport eingerichtet und vor der Einreichung nie wiederhergestellt wurde.
Modifier-Stack verbirgt die Geometrie. Manche Modifier (Boolean, Maske, Decimate bei extremen Einstellungen, Build) können Geometrie effektiv aus der Render-Ausgabe löschen, obwohl das Quell-Mesh im Modifier-Stack-Viewport-Modus sichtbar ist. Deaktivieren Sie Modifier am fehlenden Objekt einen nach dem anderen, um festzustellen, welcher der Übeltäter ist, beheben Sie dann die Modifier-Einstellungen oder wenden/baken Sie ihn vor der Einreichung an.
Objekt ist ein Proxy oder eine Instanz mit einer fehlerhaften Referenz. Proxy-Objekte (V-Ray Proxy, Redshift Proxy, Arnold Standin), Alembic-Caches und Instanzen referenzieren externe Dateien. Wenn der Referenzpfad fehlerhaft ist — falscher absoluter Pfad, fehlende Datei im Archiv, Netzwerkshare, der auf dem Worker nicht existiert — rendert der Proxy als nichts. Dies überschneidet sich mit §Fehlende Assets oben; sehen Sie diesen Abschnitt für den vollständigen Pfad-Check-Workflow.

GI-Cache-, Irradiance- und Light-Cache-Fehlkonfigurationen

Dieser Abschnitt überschneidet sich mit dem , behandelt aber die Symptome, die als Qualitätsprobleme statt Leistungsprobleme auftreten. Wenn Ihr Rendering mit Flackern zwischen Frames zurückkommt, fleckiger indirekter Beleuchtung, Banding in dunklen Bereichen oder sichtbar unterschiedlicher Beleuchtung in benachbarten Frames derselben Animation, ist die Ursache fast immer eine GI-Cache-Konfiguration, die das verteilte Rendering nicht überlebt.

Das Kernproblem: GI-Caches in V-Ray (Irradiance Map, Light Cache), Corona (UHD Cache, Pfad-Tracing) und Redshift (Irradiance Cache, Photon Map) sind vorberechnete Beleuchtungsdatensätze. Wenn Sie eine Animation rendern, muss der Cache entweder (a) einmal vorberechnet und über jeden Frame wiederverwendet werden, oder (b) pro Frame mit ausreichend hoher Qualität berechnet werden, damit er Frame-für-Frame identisch aussieht. Die Vermischung beider — jeden Worker seinen eigenen Cache pro Frame bei niedriger Qualität berechnen zu lassen — produziert sichtbares Flackern, weil das Rauschen jedes Workers unterschiedlich ist.

Vier häufige Fehlkonfigurationen und was dagegen zu tun ist:

Per-Frame-GI-Modus in der Animation. Der „Einzelner Frame"-Modus für Irradiance Map und Light Cache in V-Ray berechnet für jeden Frame einen neuen Cache. Auf einer verteilten Farm berechnet jeder Worker seinen eigenen — sie teilen nicht. Das Ergebnis ist Animations-Flackern. Wechseln Sie zu „Multiframe-Inkrementell" mit dem auf der Festplatte gespeicherten Cache-File, oder berechnen Sie den Cache als separaten Prepass vor und verwenden Sie „Aus Datei" für den eigentlichen Animations-Pass. Sehen Sie den für den vollständigen Workflow.
Cache-Dateipfad ist lokal und fehlt auf Workern. Wenn Sie eine vorberechnete Irradiance Map unter C:\Users\IhrName\Documents\maps\ir.vrmap gespeichert und den Job eingereicht haben, haben die Worker diese Datei nicht. Sie fallen auf die Per-Frame-Berechnung zurück (die erste Ursache oben), und die Animation flackert. Speichern Sie Cache-Dateien im Projektordner, verwenden Sie relative Pfade und schließen Sie die Cache-Dateien in Ihr Projektarchiv vor der Einreichung ein.
Cache-Qualität zu niedrig für die Szene. Selbst wenn korrekt konfiguriert (vorberechnet, im Archiv enthalten), kann ein Light Cache mit 500 Subdivisions oder eine Irradiance Map mit „Sehr niedrig"-Qualität für eine dunkle, GI-schwere Archviz-Szene unzureichend sein. Die Renderings sehen rauschig oder fleckig aus, besonders in Ecken und unter Möbeln. Erhöhen Sie die Subdivisions oder verwenden Sie die Universal-Voreinstellung als Ausgangspunkt.
UHD-Cache über inkompatible Kameras hinweg wiederverwendet. UHD Cache (Corona, V-Ray) ist von der Kameraansicht abhängig. Ein für Kamera A vorberechneter und bei Kamera B wiederverwendeter Cache produziert falsche Beleuchtung — der Cache „denkt", die Kamera ist irgendwo, wo sie nicht ist. Wenn Sie mehrere Kameras derselben Szene rendern, berechnen Sie einen UHD-Cache pro Kamera vor, oder verwenden Sie Pfad-Tracing (kein Cache) für kameraübergreifende Konsistenz.

Für vollständige GI-Cache-Konfiguration, Versions-Hinweise für V-Ray 6.x und den Vorab-Berechnungs-Workflow, der sauber zur Farm geliefert wird, sehen Sie den .

Fehlende Assets — Texturen, Proxies, Referenzen, Plugins

Das Rendering wird abgeschlossen, aber Teile der Szene sind offensichtlich falsch: Texturen sind rosa (Mayas Standard für fehlende Textur), lila (V-Rays Standard), Schachbrettmuster (Arnold) oder einfarbig magenta (Blender). Proxies rendern als Begrenzungsrahmen oder leerer Raum. Bestimmte Materialien rendern als „Fehlend"-Platzhalter der Engine.

Die Ursache ist die Pfadauflösung. Ihre Szenendatei referenziert Assets über Pfade, und auf dem Worker werden diese Pfade nicht aufgelöst. Sechs zu überprüfende Dinge:

Absolute Pfade in der Szenendatei. Wenn Ihre Szene Texturen unter C:\Users\IhrName\Projekt\textures\wood.jpg referenziert, hat der Worker diesen Pfad nicht. Verwenden Sie relative Pfade (./textures/wood.jpg oder ../textures/wood.jpg) oder packen Sie Assets in die Szenendatei. Die meisten DCCs haben einen „Pfade relativ machen"- oder „Ressourcensammler"-Workflow, der vor der Einreichung absolute Pfade in relative umwandelt — Mayas Dateipfad-Editor, 3ds Maxs Asset-Tracking, Blenders Datei → Externe Daten → Pfade relativ machen, Cinema 4Ds Datei → Projekt mit Assets speichern, Houdinis Pre-Render-Script mit hou.findFile.
Assets nicht im Projektarchiv enthalten. Relative Pfade helfen, aber nur wenn die Assets, die sie referenzieren, tatsächlich im hochgeladenen Archiv vorhanden sind. Führen Sie das Projektkonsolidierungs-Tool des DCC aus (oder zippen Sie einfach den gesamten Projektordner einschließlich Texturen, Caches, Referenzen und HDRIs) vor der Einreichung. Verlassen Sie sich nicht darauf, dass Sie alles hochgeladen haben — überprüfen Sie mit einem Listenvergleich.
Groß-/Kleinschreibungs-Mismatch. Windows ist groß-/kleinschreibungsunempfindlich (Texture.JPG und texture.jpg sind dieselbe Datei); die Farm-Worker laufen unter Linux, das groß-/kleinschreibungsempfindlich ist (sie sind verschiedene Dateien). Eine Szenendatei, die Texture.JPG referenziert, findet texture.jpg auf einem Linux-Worker nicht. Die meisten DCCs verwenden beim Export Kleinbuchstaben für Pfade — aber nicht immer. Wenn Sie sehen, dass bestimmte Texturen nur auf der Farm fehlen, prüfen Sie die Groß-/Kleinschreibung des tatsächlichen Dateinamens vs. die Groß-/Kleinschreibung in der Szenereferenz.
Plugin nicht auf Workern installiert. Wenn Ihre Szene von einem Drittanbieter-Plugin abhängt — Forest Pack, RailClone, Phoenix FD, MultiScatter, GrowFX, Ornatrix — muss der Worker dieses Plugin in derselben Version installiert haben. Wir installieren die Major-Plugins vor, aber überprüfen Sie, ob Ihre spezifische Version unterstützt wird, indem Sie das relevante DCC-Dokument prüfen. Wenn Ihr Plugin nicht unterstützt wird, müssen Sie die Ausgabe des Plugins vor der Einreichung baken (Scatter zu Mesh, Haare zu Mesh), oder den Support kontaktieren.
Verlinkte oder referenzierte Szenen mit fehlerhaften Pfaden. Wenn Ihre Hauptszene eine Unterszene referenziert (Maya-Referenz, Blender-Verknüpfte Bibliothek, 3ds-Max-XRef-Szene) und der Pfad der Unterszene absolut oder außerhalb des Archivs ist, kann der Worker sie nicht finden. Unterszenen müssen im Archiv sein und relativ referenziert werden, genau wie Texturen.
Asset-Versions-Mismatch. Weniger häufig, aber es lohnt sich zu prüfen: eine in Maya 2026 gespeicherte Szene mit Assets, die von Maya-2026-spezifischen Node-Typen abhängen, rendert auf einem Worker mit Maya 2024 nicht korrekt. Passen Sie Ihre Szenen-Speicher-Version an die in der relevanten setting-up-*-Dokumentation aufgeführte Worker-Version an.

Wenn Sie alle sechs geprüft haben und Assets immer noch fehlen, kann das Support-Team das Render-Zeit-Worker-Protokoll für Ihren Job herausziehen und genau identifizieren, welcher Asset-Pfad nicht aufgelöst werden konnte. Dieses Protokoll verengt die Ursache von „etwas fehlt" auf „diese spezifische Datei unter diesem spezifischen Pfad."

Farb-Drift in EXR- vs. PNG-Ausgaben desselben Renderings

Sie haben dieselbe Szene sowohl in EXR als auch in PNG gerendert und die Farben stimmen nicht überein. Das ist normalerweise erwartes Verhalten statt ein Fehler, überrascht aber regelmäßig genug Menschen, um einen eigenen Abschnitt zu verdienen.

EXR speichert lineare Gleitkomma-Daten ohne einen eingebrennten Farb-Transform. PNG (und JPEG, BMP) brennt den Display-Transform in die Pixel-Werte ein. Wenn Sie das EXR in einem Compositor mit dem passenden Filmic-, ACES-, sRGB- oder AgX-Display-Transform angewendet betrachten, sollte es visuell mit dem PNG übereinstimmen — die zugrunde liegenden Daten sind dieselben, aber die Kodierung ist unterschiedlich.

Zwei Situationen, in denen das zu einem tatsächlichen Problem wird:

Compositor-Farbmanagement unterscheidet sich vom DCC-Farbmanagement. Wenn Sie ein EXR mit angewendetem ACES-View-Transform in Ihrem DCC rendern, dann das EXR in einem Compositor (Nuke, Fusion, After Effects, Resolve) öffnen, der für sRGB oder kein Farbmanagement konfiguriert ist, unterscheidet sich das angezeigte Ergebnis. Konfigurieren Sie den Compositor so, dass er denselben View-Transform / OCIO-Config wie Ihr DCC verwendet. Dies ist eines der häufigsten Compositor-Onboarding-Probleme, die wir sehen — das EXR ist in Ordnung, der Compositor interpretiert es falsch.
PNG wurde mit einem anderen View-Transform als das EXR gespeichert. Manche DCCs erlauben View-Transform-Überschreibungen pro Format. Wenn Sie EXR auf „Raw" und PNG auf „sRGB" in denselben Ausgabe-Einstellungen der Szene setzen, produzieren sie absichtlich visuell unterschiedliche Ergebnisse aus demselben Rendering. Überprüfen Sie die Pro-Format-Ausgabe-Einstellungen und standardisieren Sie auf einen Transform, außer Sie benötigen speziell Variation pro Format.

Allgemeiner diagnostischer Ablauf

Wenn ein Render-Qualitätsproblem auftritt, arbeiten Sie diese Schritte der Reihe nach durch. Die meisten Tickets lösen sich bei Schritt 1–3 ohne Eskalation.

Lokal reproduzieren. Rendern Sie einen Frame der problematischen Szene auf Ihrer Workstation mit denselben Einstellungen wie die Farm-Einreichung. Wenn lokal gleich wie Farm ist, liegt das Problem in der Szene — reparieren Sie die Szene. Wenn lokal sich von Farm unterscheidet, liegt das Problem in der Umgebung: Pfad, Plugin-Version, OCIO-Config oder Asset-Archiv.
Farbmanagement und View-Transform prüfen. Verursacht ~40 % der Qualitätsprobleme, die wir in der Support-Leitung sehen.
Kameraauswahl in den Render-Einstellungen prüfen. ~20 % — falsche Kamera, gesperrter Viewport, Layer- oder Take-Mismatch.
Render-Region, Rahmen oder Beschnitt prüfen. ~10 % — teilweise Ausgabe.
Layer-, Sammlungs- oder Render-Layer-Sichtbarkeit prüfen. ~15 % — fehlende Objekte, fehlende Lichter, dunkle Szenen.
Textur-Farbraum-Kennzeichnung prüfen. ~10 % — subtiler, aber durchdringender Helligkeits-Drift.
GI-Cache-Konfiguration auf Animations-Flackern prüfen. ~3 % — sehen Sie den .
Asset-Pfade und Archiv-Vollständigkeit prüfen. ~2 % — rosa Texturen, fehlende Proxies.

Wenn die Schritte 1–8 die Ursache nicht identifizieren, zieht das Support-Team das Worker-Protokoll für Ihren Job heraus und verengt die Ursache auf einen spezifischen Worker-Fleet-Zustand, einen Renderer-Versions-Mismatch oder ein Konfigurationsproblem, das wir auf unserer Seite beheben können. Senden Sie eine Support-Nachricht mit der Job-ID, der falschen Ausgabe und einer Beschreibung des Erwarteten — das reicht uns, um die Verfolgung zu beginnen.

Querverweise

— Fehlerbehebung bei Job-Fehlern (der Job wurde überhaupt nicht abgeschlossen)
— Upload-, Einreichungs- und Download-Workflow
— GI-Cache, Irradiance Map, Light Cache, UHD-Cache-Konfiguration
— Projektarchiv-Verpackung, Asset-Konsolidierung, Prävention fehlender Assets
— Maya-Kamera, Render-Layer, Render-Stats-Konfiguration
— 3ds-Max-Kamera-Sperren, Region-Rendering, Gamma- und LUT-Einstellungen
— Cinema-4D-Take-System, Kamera-Tags, Farbprofil
— Blender-Render-Sichtbarkeit, Farbmanagement, Filmic vs. AgX
— AE-Farbmanagement für das Compositing der Render-Ausgabe
— Houdini-ROP-Kamerareferenz, Ausgabe-Node-Konfiguration

FAQ

Q: Mein Rendering kam dunkler als mein Viewport zurück. Was hat sich geändert? A: Fast immer ein Farbmanagement- oder View-Transform-Mismatch. Der Farb-Transform der Ausgabedatei spiegelt die gespeicherten Render-Eigenschaften → Farbmanagement-Einstellungen wider, nicht den aktuellen Zustand Ihres Viewports. Überprüfen Sie, dass View Transform (Filmic, AgX, Standard, sRGB, ACES) und Look-Einstellungen korrekt in Ihrem Projekt vor der Einreichung gespeichert sind, und dass Ihre Textur-Farbraum-Kennzeichnung konsistent ist (sRGB für Farbtexturen, Nicht-Farbe für Datentexturen).

Q: Mein Rendering kam ohne Beleuchtung zurück. Die Szene hat Lichter, ich kann sie im Viewport sehen. A: Prüfen Sie vier Dinge der Reihe nach: (1) den Render-Sichtbarkeits-Schalter jedes Lichts (getrennt von der Viewport-Sichtbarkeit); (2) auf welchem Render-Layer, View-Layer oder welcher Sammlung sich die Lichter befinden und ob dieser Layer für das Rendering aktiviert ist; (3) ob die HDRI-Umgebung in den Render-Eigenschaften oder dem World-Shader aktiviert ist; (4) ob GI oder Indirekte Beleuchtung in den aktiven Render-Einstellungen für Engines aktiviert ist, die es separat steuern (V-Ray, Corona, Redshift).

Q: Die falsche Kamera hat gerendert, obwohl ich die richtige in den Render-Einstellungen ausgewählt hatte. A: Höchstwahrscheinlich eine „Ansicht gesperrt"-Bedingung in 3ds Max oder Maya — ein gesperrter Viewport überschreibt die Kameraauswahl der Render-Einstellungen. Entsperren Sie den Viewport, oder setzen Sie explizit Ansicht auf Rendern in Ihrem DCC-Render-Setup vor der Einreichung. Überprüfen Sie auch, dass der eingereichte Take, die Szene oder der Render-Layer die gewünschte Kamera auf Layer-Ebene hat, da manche DCCs die Kamera von einem übergeordneten Element erben.

Q: Warum sehen meine EXR- und PNG-Ausgaben desselben Renderings unterschiedlich aus? A: EXR speichert lineare Gleitkomma-Daten ohne einen eingebrennten Display-Transform; PNG brennt den Display-Transform in die Pixel-Werte ein. Wenn Sie das EXR in einem Compositor mit dem passenden View-Transform angewendet betrachten, sollte es genauso aussehen wie das PNG. Wenn sie im Compositor unterschiedlich aussehen, stimmt das Farbmanagement des Compositors nicht mit dem Ihres DCC überein — konfigurieren Sie den Compositor so, dass er denselben OCIO-Config und View-Transform verwendet.

Q: Ein bestimmtes Objekt fehlt in meinem Rendering, ist aber im Viewport sichtbar. A: Prüfen Sie (1) das Render-Sichtbarkeits-Flag des Objekts (getrennt von der Viewport-Sichtbarkeit — Kamera-Symbol in Blender, Primäre Sichtbarkeit in Maya, Renderbar in 3ds Max); (2) die Sichtbarkeit der Sammlung, des Render-Layers oder des Display-Layers, auf dem das Objekt lebt; (3) ob ein Modifier (Boolean, Maske, Decimate) die Geometrie zur Render-Zeit verbirgt; (4) ob das Objekt ein Proxy mit einer fehlerhaften externen Referenz ist (sehen Sie auch den Abschnitt Fehlende Assets).

Q: Mein Rendering kam teilweise oder beschnitten zurück. Die Hälfte des Frames ist schwarz. A: Prüfen Sie, ob Render-Region (oder Rahmen, Beschnitt) in Ihrem Renderer aktiviert ist. Regions-Rendering produziert eine teilweise Füllung des Ausgabe-Frames. Deaktivieren Sie die Region vor der Einreichung, oder setzen Sie sie auf den vollständigen Frame. Überprüfen Sie auch, dass das Seitenverhältnis der Kamera mit dem Ausgabe-Seitenverhältnis übereinstimmt, und dass die Ausgabeauflösung in den Render-Eigenschaften der Filmrücken-Auflösung der Kamera entspricht.

Q: Meine Texturen sehen im Vergleich zu meiner Workstation ausgewaschen oder übersättigt aus. A: Textur-Farbraum-Kennzeichnung. Farbtexturen (Diffuse, Albedo, Basis-Farbe) sollten als sRGB oder Farbe gekennzeichnet sein; Datentexturen (Normal, Rauheit, Displacement, Metallic, Opazität) sollten als Nicht-Farbe, Linear oder Raw gekennzeichnet sein. Falsch gekennzeichnete Texturen verursachen subtilen, aber konsistenten Farb-Drift, insbesondere bei PBR-Materialien, bei denen die Gamma-Behandlung der Normal-Map wichtig ist.

Q: Meine ACES-OCIO-Konfiguration ist auf meiner Workstation gesetzt. Respektiert die Farm sie? A: Ja, wenn die OCIO-Konfigurationsdateien in Ihrem Projektarchiv enthalten sind und die Projektdatei die Konfiguration über einen relativen Pfad referenziert. Wenn die OCIO-Konfigurationsdateien im Archiv fehlen, fällt der Worker auf die Standard-Konfiguration des DCC zurück (typischerweise Filmic für Blender, sRGB für die meisten anderen), und Ihre Farben driften. Schließen Sie immer den OCIO-Konfigurationsordner in Ihr Projektarchiv ein.

Q: Meine Animation flackert — jeder Frame sieht aus, als hätte er eine unterschiedliche indirekte Beleuchtung. A: GI-Cache-Fehlkonfiguration. In V-Ray wechseln Sie von „Einzelner Frame" Irradiance Map zu „Multiframe-Inkrementell" mit auf der Festplatte gespeichertem Cache und entweder berechnen Sie den Cache als Prepass vor oder verwenden Sie das universelle Pfad-Tracing-Preset. Für andere Engines sehen Sie die entsprechenden GI-Cache-Einstellungen — die Regel ist dieselbe: einmal vorberechnen und wiederverwenden, oder einen Cache-freien Modus (Pfad-Tracing) für Frame-übergreifende Konsistenz verwenden. Sehen Sie den für den vollständigen Workflow.

Q: Meine Texturen rendern rosa, lila oder magenta auf der Farm. A: Fehlende Assets. Die Szenendatei referenziert Texturen an Pfaden, die der Worker nicht auflösen kann — meistens absolute Windows-Pfade (C:\Users\...), nicht im Projektarchiv enthaltene Assets oder Groß-/Kleinschreibungs-Mismatches zwischen Ihrem Windows-Dateisystem und dem Linux-Dateisystem des Workers. Verwenden Sie relative Pfade, führen Sie das Projektkonsolidierungs-Tool Ihres DCC vor der Einreichung aus und überprüfen Sie, dass das Archiv jede referenzierte Textur enthält.

Q: Meine Forest-Pack-/Phoenix-FD-/Ornatrix-Szene kam mit fehlenden Plugin-Objekten zurück. A: Plugin-Versions- oder Kompatibilitäts-Mismatch auf dem Worker. Prüfen Sie das relevante Dokument oder für die unterstützten Plugin-Versionen auf unserem Worker-Fleet. Wenn Ihre Version unterstützt wird, sollte die Szene korrekt rendern — falls nicht, baken Sie die Ausgabe des Plugins vor der Einreichung zu Mesh, oder kontaktieren Sie den Support, um den Installationsstatus Ihrer spezifischen Plugin-Version zu überprüfen.

---