Troubleshoot render-quality issues

Render-quality issues are different from render-failure issues. A failure means the job didn't complete. A quality issue means it completed, but the result is wrong — too bright, too dark, missing geometry, the wrong camera, output that doesn't match what you see in your viewport. These problems are almost always configuration-level rather than infrastructure-level, which means they're solvable on your side once you know where to look.

This page walks through the render-quality issues we see most often on the farm, organized by symptom. For job-failure troubleshooting — jobs that don't complete at all, crash mid-frame, or return error codes — see . For DCC-specific setup details and the render-time settings that matter most for each engine, see the relevant setting-up-* doc.

A useful working rule we lean on every day in support: render-quality issues are almost always reproducible. If a render comes back wrong from the farm, the same scene rendered locally — same engine, same version, same settings, same scene file — will usually produce the same wrong output. That reproducibility is the diagnostic key. If local matches farm, the issue is inside the scene and you can fix it without touching anything farm-side. If local differs from farm, the issue is environmental: a path mismatch, a version mismatch, a missing asset, or a configuration that travels with your workstation but not with the scene file.

The sections below follow that diagnostic logic, ordered by how often we see each pattern on the support line.

Brightness or color mismatch vs local render

This is the most common quality complaint we see, by a wide margin. The render comes back lighter, darker, more saturated, or visibly different in color from what your local viewport shows. Almost always, the cause is color management — the worker is interpreting the linear, sRGB, or Filmic pipeline differently than your workstation viewport, or texture color-space tagging is inconsistent.

Five things to check, in order of frequency:

1. View Transform mismatch. In Blender, this lives at Render Properties → Color Management → View Transform. Default is Filmic. If your workstation viewport shows Filmic but the saved scene file is set to Standard (or vice versa), the rendered output uses the saved value, not the viewport state. In Maya, the equivalent is Color Management in Render Settings → Common (with ACES, sRGB, or Raw as common options). In 3ds Max, check the Gamma and LUT settings under Customize → Preferences → Gamma and LUT. In Cinema 4D, look at Render Settings → Output → Color Profile. The viewport may show one transform while the saved file specifies another — the renderer uses the saved value.
2. Texture color-space tagging. Textures used as color data (diffuse, albedo, base color) should be tagged as sRGB or Color. Textures used as data (normal maps, roughness, displacement, metallic, opacity) should be tagged as Non-Color, Linear, or Raw. A normal map tagged as sRGB will cause subtle but pervasive lighting drift — the math doesn't work right when the texture goes through an extra gamma curve. Grep through your shader graph or texture browser before submission. This is the single most common cause of "my render looks washed out" tickets.
3. OCIO config drift. If your workstation uses a custom OCIO config — ACES 1.3, AgX, a studio-specific config — the OCIO config files must be included in your project archive, and the project file must reference them via a relative path (not an absolute path that only exists on your machine). When the worker boots and reads your scene, it looks for the OCIO config at the path the scene file specifies. If the file isn't there, the renderer silently falls back to its default config (typically Filmic for Blender, sRGB for most others), and your colors drift.
4. Output format embeds color differently than you expect. Output formats that don't carry color-space metadata — PNG, JPEG, BMP — bake the display transform into the pixel values. EXR (linear, 32-bit) preserves the raw scene-referred data and applies the view transform at the compositor stage. If you compare a PNG output from the farm to an EXR output from the same render, they look different on purpose. That's not a bug; it's how the formats work. When you view both with the matching View Transform applied in your compositor, they should agree.
5. Exposure or post-process drift. Some DCCs save a post-process "look" or exposure compensation in the scene file but apply it differently on render. Check the render output node, the camera's exposure setting, and any compositing nodes downstream of the render layer. A −0.5 EV viewport exposure that doesn't apply at render time will produce a render that's half a stop brighter than expected.

The diagnostic test we recommend in every brightness ticket: render the same scene locally with the same settings on your own workstation. If local matches farm, your scene's color management is configured the way it is intentionally — the viewport is just showing a different interpretation. If local differs from farm, check OCIO config inclusion and texture color-space tags first.

Camera not detected or "no camera in scene"

The renderer can't find a camera to render from. The job aborts before any frames produce, or the output is empty / default-viewport. Three common causes:

1. No camera marked as renderable. In Maya, Render Settings → Common → Renderable Cameras determines which camera renders. The default is persp, which is the perspective view from your modeling viewport — rarely what you want for a final shot. Set the renderable flag on the camera you actually want. In Blender, the scene's active camera (Properties → Scene Properties → Camera) is the one that renders, and only that one. In Cinema 4D, the Render Settings → Output → Camera field overrides which camera renders if set; otherwise the editor's active camera is used. In 3ds Max, Render Setup → Common → Camera (or the View dropdown) selects the render camera.
2. The renderable camera is hidden. In some DCCs (notably Maya), a camera that's hidden in the outliner is still renderable as long as it's marked renderable in Render Settings. In others (notably Blender, where the active camera must be visible for the viewport "Camera View" mode to work), hiding the camera doesn't affect render directly — but if you've recently restructured your scene, verify the camera you expect is in the active scene and not in a separate collection, render layer, take, or scene that isn't selected.
3. Locked viewport overrides the renderable camera. In 3ds Max and Maya, a "locked viewport" pattern can cause the renderer to use the viewport's current camera rather than the camera you intended. This shows up as either "no camera" (if the viewport is on a non-camera perspective view that the renderer rejects) or "wrong camera" (the next section). Unlock the viewport before submission, or explicitly set View to Render in Render Setup.

For DCC-specific camera configuration, see , , , or .

Rendered scene has no lights

The geometry renders, but the scene is completely dark, or the lighting is far darker than expected — often a wireframe-on-black look that suggests no light reaches the surfaces.

Four things to check:

1. Lights are disabled in render visibility. In Maya, lights have a per-render visibility flag in the Attribute Editor (Visibility → Render). A light visible in the outliner can still be excluded from render-time computation. In Blender, the light object's render visibility (the camera-icon toggle in the outliner) controls whether the light contributes to render — separate from the eye-icon viewport toggle.
2. Lights are on a hidden View Layer, Render Layer, or Collection. A light that's visible in the viewport but assigned to a non-rendered layer will not contribute. Verify lights are on the layer or collection being rendered, not on a sibling layer that's hidden at render time.
3. Environment lighting is disabled. If your scene relies on HDRI environment lighting — common in archviz and product visualization — verify the environment is enabled in Render Properties. In Blender, World → Surface must have the Environment Texture or Background shader connected. In Maya, the Hypershade environment node must be plugged into the scene's render-time environment slot. In 3ds Max, Environment and Effects (keyboard shortcut 8) must have the HDRI assigned, and in V-Ray, the V-Ray Environment override is a separate setting that overrides the scene environment.
4. GI or Indirect Lighting is disabled. For V-Ray and Corona, Global Illumination is a separate setting from "lights present in scene." A scene designed for GI bounces but with GI disabled in the active render preset will appear dark even if every direct light is correctly configured. In V-Ray, GI → Enable global illumination must be on. In Corona, GI → Solver must be set (Path tracing or UHD Cache). In Redshift, GI → Enable GI must be on. See for the engine-specific GI cache configuration that follows this enablement.

A quick diagnostic test: temporarily add a single Sun or Directional light with intensity 1.0 from above the scene and render one frame. If even that doesn't appear in the output, the issue is layer or collection visibility, not light-source configuration. If the test sun renders correctly, your original lights are the problem — work back through the four checks above.

Wrong camera renders despite specifying the correct one

You set Camera A as the render camera, but the output shows Camera B's view. This is one of the more frustrating quality issues because the scene file looks correct on inspection — the renderable flag is on the right camera, the active camera is the one you want. The cause is almost always one of three things:

1. View locked to viewport in 3ds Max or Maya. A locked viewport (Right-click viewport label → Lock) overrides the Render Setup camera selection. The renderer uses the viewport camera, not the one you configured. Unlock the viewport before saving the scene, or explicitly set View to Render in Render Setup → Common (Maya) or Render Setup → Output (3ds Max). This is the most common cause of "wrong camera" tickets on 3ds Max submissions — the lock is easy to set accidentally with a hotkey and easy to miss before submission.
2. Multi-camera scene with the wrong active camera. If your scene has multiple cameras — turntable, hero, beauty, detail, alts — verify which one is set as the active camera for the current scene, take, or render layer. In Cinema 4D, each Take can have its own camera; in Blender, each scene has its own active camera; in Maya, Render Setup layers can override the camera per layer. The camera that renders is the camera assigned at the layer / take / scene level you submitted, not the one you last selected in the viewport.
3. Take, scene, or render-layer mismatch. Submitted Render Layer A but it inherits its camera from Master, and Master's camera is Camera B? That happens. Always submit from the take or layer that explicitly has the camera you intend, and avoid relying on inheritance unless you've verified the chain.

Phase 2d will pair this section with a before/after pair: locked-viewport submission (wrong camera rendered) vs unlocked-viewport submission (correct camera rendered) on the same scene file.

Output image is partial, cropped, or not full frame

The rendered image comes back but only part of the frame is filled — the rest is black, transparent, or repeated viewport color. Four things to check:

1. Render Region is enabled. In V-Ray, Corona, Arnold, and several other renderers, a "Region" option lets you render only a sub-rectangle of the full frame for fast preview. If Region was enabled during local testing and not disabled before submission, the worker renders only that region — the rest of the frame stays at its default fill color. This is the single most common cause of partial-frame output tickets.
2. Output resolution mismatch between scene and render setting. The Render Properties output resolution and the actual frame size in the output file must match. If your scene's camera aperture is set to one resolution and your output is set to another, the renderer may produce a partial fill — the camera "sees" a smaller area than the output canvas, and the empty region stays uncolored.
3. Aspect ratio mismatch between camera and output. A camera with a 1.78 aspect rendering to a 1.0 output will produce a partial image — the camera's view doesn't fill the output frame. Verify the camera's film-back aspect matches the output aspect, or that "Fit Resolution Gate" (or its equivalent — different DCCs name this differently: "Resolution Gate Fit", "Camera Aperture", "Film Gate") is set to fill, horizontal, vertical, or overscan as your shot requires.
4. Border or crop settings in the output format. Some DCCs and some output formats let you set a render border independent of the camera's resolution gate. Verify the border (in Render Properties, or in the camera's attributes) encompasses the full intended output area, not a cropped sub-region.

Black or blank renders

The render completes successfully — no errors, no warnings — but every pixel is black or completely uniform. Most common on Maya, but we see it across all DCCs.

Five things to check:

1. Layer-toggle mismatch. In Maya, geometry might be visible in the viewport but disabled at the render-time visibility level (Display → Hide → Hide All Cameras, or per-object Render Stats → Primary Visibility = off). In Blender, the equivalent is the render visibility toggle (camera icon) in the outliner. The most common cause is restructuring a scene's layers after testing and forgetting to enable render visibility on the new layer or collection.
2. Camera clipping planes set incorrectly. If the near or far clipping plane is set wrong — far plane too close to the camera, near plane behind the geometry — the camera doesn't include the geometry in its view frustum. Default planes (near 0.1, far 1000-10000 depending on scene scale) are usually fine; this happens after manual adjustment, especially when working at unusual scene scales (large architectural sets or microscopic product renders).
3. Renderable lights but emission disabled. If you're using emissive materials as lights, verify the emission shader is enabled and has nonzero strength. Some workflows toggle emission off during viewport interaction to avoid GPU heat and forget to re-enable before submission.
4. Sampling too low to produce visible output. With aggressive path-trace sampling reductions (very low samples-per-pixel), very dark scenes can produce all-black output until samples increase enough to converge. Render a single frame locally with the same settings to verify; if the local render is also all-black at the same sample count, increase sampling or check the lighting setup.
5. Render output node misconfigured (Blender, Houdini). In Blender's compositor and in Houdini's ROP network, the output node chain can be configured to discard the render result before saving. Verify the Composite node is connected to Render Layers (Blender) or the ROP's output path is set correctly and the output mode isn't "Null" (Houdini).

For Maya specifically, see for the camera-selection and render-stats workflow that prevents the most common cause of black renders on that DCC. Phase 2d will pair this section with a before/after: typical black-frame symptom + the layer-visibility toggle that resolved it.

Some objects in scene not rendering

A specific object is visible in the viewport but missing from the rendered output. The rest of the scene renders correctly. Common across all DCCs, slightly more common on Blender because Blender's three-way visibility model (viewport / render / select) is easy to misconfigure.

Five things to check:

1. Render visibility toggle on the object. In Blender's outliner, hover over the object's row — three icons control visibility: eye (viewport), camera (render), screen (selectability). Make sure the camera icon is enabled for the missing object. In Maya, Attribute Editor → Render Stats → Primary Visibility must be on. In 3ds Max, the object's Object Properties → Rendering → Visibility must be set above 0 (and Renderable must be checked).
2. Object is on a hidden collection, layer, or set. Collections in Blender have separate viewport and render visibility. The collection might be visible in viewport but excluded from render via the camera-icon toggle on the collection row. In Maya, the object's Display Layer assignment and Render Layer assignment are separate; in 3ds Max, Layer Properties → Renderable must be on for every layer holding renderable geometry.
3. Object's material is invisible. A material with zero opacity, zero alpha, or alpha blending issues will render as effectively invisible — the geometry is there but transparent. Verify the material's opacity, alpha, transparency, and any alpha-blend settings. Common pitfall: a material that was set up for "ghost" reference in viewport and never restored before submission.
4. Modifier stack hides the geometry. Some modifiers (Boolean, Mask, Decimate at extreme settings, Build) can effectively delete geometry from render output even though the source mesh is visible in the modifier stack viewport mode. Disable modifiers one at a time on the missing object to identify which one is the culprit, then either fix the modifier's settings or apply / bake it before submission.
5. Object is a proxy or instance with a broken reference. Proxy objects (V-Ray Proxy, Redshift Proxy, Arnold Standin), Alembic caches, and instances reference external files. If the reference path is broken — wrong absolute path, missing file in the archive, network share that doesn't exist on the worker — the proxy renders as nothing. This overlaps with §Missing assets below; see that section for the full path-checking workflow.

GI cache, irradiance, and light-cache misconfigurations

This section overlaps with the but covers the symptoms that surface as quality issues rather than performance issues. If your render comes back with flickering between frames, splotchy indirect lighting, banding in dark areas, or visibly different illumination on adjacent frames of the same animation, the cause is almost always a GI cache configuration that doesn't survive distributed rendering.

The core issue: GI caches in V-Ray (Irradiance Map, Light Cache), Corona (UHD Cache, Path tracing), and Redshift (Irradiance Cache, Photon Map) are precomputed lighting datasets. When you render an animation, the cache must be either (a) precomputed once and reused across every frame, or (b) computed per-frame with high enough quality to look identical frame-to-frame. Mixing the two — letting each worker compute its own cache per-frame at low quality — produces visible flicker, because each worker's noise pattern is different.

Four common misconfigurations and what to do about them:

1. Per-frame GI mode in animation. V-Ray's "Single frame" mode for Irradiance Map and Light Cache computes a fresh cache for every frame. On a distributed farm, each worker computes its own — they don't share. The result is animation flicker. Switch to "Multiframe Incremental" with the cache file saved to disk, or precompute the cache as a separate prepass and use "From file" for the actual animation pass. See for the full workflow.
2. Cache file path is local and missing on workers. If you saved a precomputed Irradiance Map to C:\Users\YourName\Documents\maps\ir.vrmap and submitted the job, the workers don't have that file. They fall back to per-frame computation (the first cause above) and the animation flickers. Save cache files to the project folder, use relative paths, and include the cache files in your project archive before submission.
3. Cache quality too low for the scene. Even when configured correctly (precomputed, included in archive), a Light Cache at 500 subdivs or Irradiance Map at "Very Low" quality can be insufficient for a dark, GI-heavy archviz scene. The renders look noisy or splotchy, especially in corners and under furniture. Increase subdivisions or use the Universal preset as a baseline.
4. UHD Cache reused across incompatible cameras. UHD Cache (Corona, V-Ray) is camera-view-dependent. A cache precomputed for Camera A and reused on Camera B will produce wrong illumination — the cache "thinks" the camera is somewhere it isn't. If you render multiple cameras of the same scene, precompute a UHD Cache per camera, or use Path tracing (no cache) for cross-camera consistency.

For full GI cache configuration, version notes for V-Ray 6.x, and the pre-calculate workflow that ships clean to the farm, see .

Missing assets — textures, proxies, references, plugins

The render completes but parts of the scene are obviously wrong: textures are pink (Maya's default for missing texture), purple (V-Ray's default), checker-pattern (Arnold), or solid magenta (Blender). Proxies render as bounding boxes or empty space. Specific materials render as the engine's "missing" placeholder.

The cause is path resolution. Your scene file references assets by path, and on the worker, those paths don't resolve. Six things to check:

1. Absolute paths in scene file. If your scene references textures at C:\Users\YourName\Project\textures\wood.jpg, the worker doesn't have that path. Use relative paths (./textures/wood.jpg or ../textures/wood.jpg) or pack assets into the scene file. Most DCCs have a "Make Paths Relative" or "Resource Collector" workflow that converts absolute paths to relative before submission — Maya's File Path Editor, 3ds Max's Asset Tracking, Blender's File → External Data → Make Paths Relative, Cinema 4D's File → Save Project with Assets, Houdini's Pre-Render Script with hou.findFile.
2. Assets not included in the project archive. Relative paths help, but only if the assets they reference are actually present in the archive you uploaded. Run the DCC's project consolidation tool (or just zip the entire project folder including textures, caches, references, and HDRIs) before submission. Don't trust that you uploaded everything — verify with a list comparison.
3. Case sensitivity mismatch. Windows is case-insensitive (Texture.JPG and texture.jpg are the same file); the farm workers run Linux, which is case-sensitive (they're different files). A scene file that references Texture.JPG will fail to find texture.jpg on a Linux worker. Most DCCs lowercase paths on export — but not always. If you see specific textures missing only on the farm, check the case of the actual filename vs the case in the scene file's reference.
4. Plugin not installed on workers. If your scene depends on a third-party plugin — Forest Pack, RailClone, Phoenix FD, MultiScatter, GrowFX, Ornatrix — the worker must have that plugin installed at the same version. We pre-install the major plugins, but verify your specific version is supported by checking the relevant DCC's doc. If your plugin isn't supported, you'll need to bake the plugin's output (scatter to mesh, hair to mesh) before submission, or escalate to support.
5. Linked or referenced scenes with broken paths. If your main scene references a sub-scene (Maya reference, Blender Linked Library, 3ds Max XRef Scene), and the sub-scene's path is absolute or external to the archive, the worker can't find it. Sub-scenes have to be in the archive and referenced relatively, just like textures.
6. Asset version mismatch. Less common but worth checking: a scene saved in Maya 2026 with assets that depend on Maya 2026-specific node types won't render correctly on a worker running Maya 2024. Match your scene-save version to the worker version listed in the relevant setting-up-* doc.

If you've checked all six and assets are still missing, the support team can pull the render-time worker log and identify exactly which asset path failed to resolve. That log narrows the cause from "something is missing" to "this specific file at this specific path."

Color drift in EXR vs PNG outputs of the same render

You rendered the same scene to both EXR and PNG and the colors don't match. This is usually expected behavior rather than a bug, but it surprises people regularly enough that it earns its own section.

EXR stores linear floating-point data without a baked color transform. PNG (and JPEG, BMP) bakes the display transform into the pixel values. When you view the EXR in a compositor with the matching Filmic, ACES, sRGB, or AgX display transform applied, it should match the PNG visually — the underlying data is the same, but the encoding is different.

Two situations where this turns into an actual problem:

1. Compositor color management differs from DCC color management. If you render an EXR with ACES View Transform applied in your DCC, then open the EXR in a compositor (Nuke, Fusion, After Effects, Resolve) configured for sRGB or no color management, the displayed result will differ. Configure the compositor to use the same View Transform / OCIO config as your DCC. This is one of the most common compositor-onboarding issues we see — the EXR is fine, the compositor is interpreting it wrong.
2. PNG was saved with a different View Transform than the EXR. Some DCCs allow per-format View Transform overrides. If you set EXR to "Raw" and PNG to "sRGB" in the same scene's output settings, they will produce visually different results from the same render, by design. Check the per-format output settings and standardize on one transform unless you specifically need per-format variation.

General diagnostic flow

When a render-quality issue appears, work through these steps in order. Most tickets resolve at step 1–3 without escalation.

1. Reproduce locally. Render one frame of the problem scene on your workstation with the same settings as the farm submission. If local matches farm, the issue is in the scene — fix the scene. If local differs from farm, the issue is environmental: path, plugin version, OCIO config, or asset archive.
2. Check Color Management and View Transform. This causes ~40% of the quality issues we see on the support line.
3. Check camera selection in Render Settings. ~20% — wrong camera, locked viewport, layer or take mismatch.
4. Check Render Region, Border, or Crop. ~10% — partial output.
5. Check Layer, Collection, or Render Layer visibility. ~15% — missing objects, missing lights, dark scenes.
6. Check texture color-space tagging. ~10% — subtle but pervasive brightness drift.
7. Check GI cache configuration for animation flicker. ~3% — see .
8. Check asset paths and archive completeness. ~2% — pink textures, missing proxies.

If steps 1–8 don't identify the cause, the support team will pull the worker log for your job and narrow the cause to a specific worker-fleet state, a renderer version mismatch, or a configuration issue we can address on our side. Send a support message with the job ID, the wrong output, and a description of what you expected — that's enough for us to begin the trace.

Cross-references

• — job-failure troubleshooting (the job didn't complete at all)
• — upload, submit, download workflow
• — GI cache, Irradiance Map, Light Cache, UHD Cache configuration
• — project archive packaging, asset consolidation, missing-asset prevention
• — Maya camera, render-layer, render-stats configuration
• — 3ds Max camera locks, region rendering, Gamma and LUT settings
• — Cinema 4D Take system, camera tags, color profile
• — Blender render visibility, color management, Filmic vs AgX
• — AE color management for compositing render output
• — Houdini ROP camera reference, output node configuration

FAQ

Q: My render came back darker than my viewport. What changed? A: Almost always a Color Management or View Transform mismatch. The output file's color transform reflects the saved Render Properties → Color Management settings, not your viewport's current state. Verify View Transform (Filmic, AgX, Standard, sRGB, ACES) and Look settings are saved correctly in your project before submission, and that your texture color-space tagging is consistent (sRGB for color textures, Non-Color for data textures).

Q: My render came back with no lighting. The scene has lights, I can see them in the viewport. A: Check four things in order: (1) each light's render visibility toggle (separate from viewport visibility); (2) which Render Layer, View Layer, or Collection the lights are on, and whether that layer is enabled for rendering; (3) whether the HDRI environment is enabled in Render Properties or the World shader; (4) whether GI or Indirect Lighting is enabled in the active render settings for engines that gate it separately (V-Ray, Corona, Redshift).

Q: The wrong camera rendered even though I selected the right one in Render Settings. A: Most likely a "View Locked" condition in 3ds Max or Maya — a locked viewport overrides Render Settings camera selection. Unlock the viewport, or explicitly set View to Render in your DCC's Render Setup before submission. Also verify the Take, Scene, or Render Layer you submitted has the camera you intended at the layer level, since some DCCs inherit camera from a parent.

Q: Why do my EXR and PNG outputs of the same render look different? A: EXR stores linear floating-point data without a baked display transform; PNG bakes the display transform into the pixel values. When you view the EXR in a compositor with the matching View Transform applied, it should look the same as the PNG. If they look different in the compositor, the compositor's color management doesn't match your DCC's — configure the compositor to use the same OCIO config and View Transform.

Q: A specific object is missing from my render but visible in the viewport. A: Check (1) the object's render visibility flag (separate from viewport visibility — camera icon in Blender, Primary Visibility in Maya, Renderable in 3ds Max); (2) the visibility of the Collection, Render Layer, or Display Layer the object lives on; (3) whether any modifier (Boolean, Mask, Decimate) is hiding the geometry at render time; (4) whether the object is a proxy with a broken external reference (see also Missing assets section).

Q: My render came back partial or cropped. Half the frame is black. A: Check whether Render Region (or Border, Crop) is enabled in your renderer. Region rendering produces a partial fill of the output frame. Disable Region before submission, or set it to the full frame. Also verify the camera's aspect ratio matches the output aspect, and that the output resolution in Render Properties matches the camera's film-back resolution.

Q: My textures look washed out or oversaturated compared to my workstation. A: Texture color-space tagging. Color textures (diffuse, albedo, base color) should be tagged as sRGB or Color; data textures (normal, roughness, displacement, metallic, opacity) should be tagged as Non-Color, Linear, or Raw. Mis-tagged textures cause subtle but consistent color drift, especially on PBR materials where normal-map gamma matters.

Q: My ACES OCIO config is set on my workstation. Does the farm respect it? A: Yes, if the OCIO config files are included in your project archive and the project file references the config via a relative path. If the OCIO config files are missing from the archive, the worker falls back to the DCC's default config (typically Filmic for Blender, sRGB for most others), and your colors will drift. Always include the OCIO config folder in your project archive.

Q: My animation flickers — each frame looks like it has different indirect lighting. A: GI cache misconfiguration. In V-Ray, switch from "Single frame" Irradiance Map to "Multiframe Incremental" with the cache saved to disk, and either precompute the cache as a prepass or use the Universal Path tracing preset. For other engines, see the corresponding GI cache settings — the rule is the same: precompute once and reuse, or use a no-cache mode (Path tracing) for cross-frame consistency. See for the full workflow.

Q: My textures render as pink, purple, or magenta on the farm. A: Missing assets. The scene file references textures at paths the worker can't resolve — usually absolute Windows paths (C:\Users\...), assets not included in the project archive, or case-sensitivity mismatches between your Windows filesystem and the worker's Linux filesystem. Use relative paths, run your DCC's project consolidation tool before submission, and verify the archive includes every referenced texture.

Q: My Forest Pack / Phoenix FD / Ornatrix scene came back with the plugin objects missing. A: Plugin version or compatibility mismatch on the worker. Check the relevant or doc for the supported plugin versions on our worker fleet. If your version is supported, the scene should render correctly — if not, bake the plugin's output to mesh before submission, or contact support to verify the install status of your specific plugin version.

---

[PHASE 2D: before/after pairs needed for §Brightness, §Wrong camera, §Output not full, §Black/blank, §Objects missing — Phase 2d delegate to dispatch per-section visual comparison]