Resolución de problemas de calidad de renderizado

Los problemas de calidad de renderizado son diferentes de los problemas de fallo de renderizado. Un fallo significa que el trabajo no se completó. Un problema de calidad significa que se completó, pero el resultado es incorrecto — demasiado brillante, demasiado oscuro, con geometría faltante, con la cámara incorrecta, con una salida que no coincide con lo que ve en su viewport. Estos problemas son casi siempre de nivel de configuración más que de nivel de infraestructura, lo que significa que son solucionables de su lado una vez que sabe dónde buscar.

Esta página recorre los problemas de calidad de renderizado que vemos con mayor frecuencia en la render farm, organizados por síntoma. Para la resolución de problemas de fallos del trabajo — trabajos que no se completan en absoluto, se bloquean a mitad del fotograma o devuelven códigos de error — consulte . Para detalles de configuración específicos del DCC y la configuración de tiempo de renderizado más importante para cada motor, consulte el documento setting-up-* relevante.

Una regla de trabajo útil en la que nos apoyamos todos los días en soporte: los problemas de calidad de renderizado son casi siempre reproducibles. Si un render vuelve incorrectamente de la render farm, la misma escena renderizada localmente — mismo motor, misma versión, misma configuración, mismo archivo de escena — generalmente producirá la misma salida incorrecta. Esa reproducibilidad es la clave de diagnóstico. Si local coincide con la render farm, el problema está dentro de la escena y puede solucionarlo sin tocar nada del lado de la render farm. Si local difiere de la render farm, el problema es ambiental: una discrepancia de ruta, una discrepancia de versión, un asset faltante o una configuración que viaja con su estación de trabajo pero no con el archivo de escena.

Las secciones a continuación siguen esa lógica de diagnóstico, ordenadas según la frecuencia con la que vemos cada patrón en el soporte.

Discrepancia de brillo o color respecto al render local

Esta es la queja de calidad más común que vemos, con una amplia diferencia. El render vuelve más claro, más oscuro, más saturado o visiblemente diferente en color de lo que muestra su viewport local. Casi siempre, la causa es la gestión de color — el worker interpreta el pipeline lineal, sRGB o Filmic de forma diferente a su viewport de la estación de trabajo, o el etiquetado del espacio de color de las texturas es inconsistente.

Cinco cosas a verificar, en orden de frecuencia:

1. Discrepancia de View Transform. En Blender, esto está en Render Properties → Color Management → View Transform. El predeterminado es Filmic. Si su viewport de la estación de trabajo muestra Filmic pero el archivo de escena guardado está configurado en Standard (o viceversa), la salida renderizada usa el valor guardado, no el estado del viewport. En Maya, el equivalente es Color Management en Render Settings → Common (con ACES, sRGB o Raw como opciones comunes). En 3ds Max, verifique la configuración de Gamma y LUT en Customize → Preferences → Gamma and LUT. En Cinema 4D, busque en Render Settings → Output → Color Profile. El viewport puede mostrar una transformación mientras el archivo guardado especifica otra — el renderer usa el valor guardado.
2. Etiquetado del espacio de color de las texturas. Las texturas usadas como datos de color (difuso, albedo, color base) deben etiquetarse como sRGB o Color. Las texturas usadas como datos (mapas normales, rugosidad, desplazamiento, metálico, opacidad) deben etiquetarse como Non-Color, Linear o Raw. Un mapa normal etiquetado como sRGB causará una deriva de iluminación sutil pero generalizada — la matemática no funciona correctamente cuando la textura pasa por una curva gamma adicional. Revise su gráfico de shaders o el navegador de texturas antes de enviar. Esta es la causa individual más común de los tickets de "mi render se ve lavado".
3. Deriva de configuración OCIO. Si su estación de trabajo usa una configuración OCIO personalizada — ACES 1.3, AgX, una configuración específica del estudio — los archivos de configuración OCIO deben incluirse en su archivo de proyecto, y el archivo de proyecto debe referenciarlos mediante una ruta relativa (no una ruta absoluta que solo existe en su máquina). Cuando el worker arranca y lee su escena, busca la configuración OCIO en la ruta que especifica el archivo de escena. Si el archivo no está allí, el renderer recurre silenciosamente a su configuración predeterminada (típicamente Filmic para Blender, sRGB para la mayoría de los demás), y sus colores se desvían.
4. El formato de salida incrusta el color de forma diferente a lo esperado. Los formatos de salida que no llevan metadatos de espacio de color — PNG, JPEG, BMP — hornean la transformación de visualización en los valores de píxeles. EXR (lineal, 32 bits) preserva los datos crudos referenciados a la escena y aplica la transformación de vista en la etapa de composición. Si compara una salida PNG de la render farm con una salida EXR del mismo render, se verán diferentes a propósito. Eso no es un error; así es como funcionan los formatos. Cuando vea ambos con la View Transform correspondiente aplicada en su compositor, deberían coincidir.
5. Deriva de exposición o posproceso. Algunos DCCs guardan un "look" de posproceso o compensación de exposición en el archivo de escena pero lo aplican de forma diferente al renderizar. Verifique el nodo de salida del renderizado, la configuración de exposición de la cámara y cualquier nodo de composición posterior a la capa de renderizado. Una exposición del viewport de −0,5 EV que no se aplica en el momento del renderizado producirá un render que es medio punto más brillante de lo esperado.

La prueba de diagnóstico que recomendamos en cada ticket de brillo: renderice el mismo fotograma problemático de la escena localmente en su propia estación de trabajo con la misma configuración que el envío a la render farm. Si local coincide con la render farm, la gestión de color de su escena está configurada de forma intencional — el viewport simplemente muestra una interpretación diferente. Si local difiere de la render farm, verifique primero la inclusión de la configuración OCIO y el etiquetado del espacio de color de las texturas.

Cámara no detectada o "no hay cámara en la escena"

El renderer no puede encontrar una cámara desde la que renderizar. El trabajo se interrumpe antes de que se produzca algún fotograma, o la salida está vacía / es el viewport predeterminado. Tres causas comunes:

1. No hay cámara marcada como renderizable. En Maya, Render Settings → Common → Renderable Cameras determina qué cámara se renderiza. El predeterminado es persp, que es la vista de perspectiva de su viewport de modelado — raramente lo que desea para un plano final. Configure la marca de renderizable en la cámara que realmente desea. En Blender, la cámara activa de la escena (Properties → Scene Properties → Camera) es la que se renderiza, y solo esa. En Cinema 4D, el campo Render Settings → Output → Camera anula qué cámara se renderiza si está configurado; de lo contrario, se usa la cámara activa del editor. En 3ds Max, Render Setup → Common → Camera (o el desplegable View) selecciona la cámara de renderizado.
2. La cámara renderizable está oculta. En algunos DCCs (especialmente Maya), una cámara que está oculta en el outliner sigue siendo renderizable siempre que esté marcada como renderizable en Render Settings. En otros (especialmente Blender, donde la cámara activa debe ser visible para que funcione el modo "Camera View" del viewport), ocultar la cámara no afecta directamente al renderizado — pero si recientemente ha reestructurado su escena, verifique que la cámara que espera está en la escena activa y no en una colección, capa de renderizado, take o escena separada que no está seleccionada.
3. El viewport bloqueado anula la cámara renderizable. En 3ds Max y Maya, un patrón de "viewport bloqueado" puede hacer que el renderer use la cámara actual del viewport en lugar de la que pretendía. Esto se manifiesta como "ninguna cámara" (si el viewport está en una vista de perspectiva sin cámara que el renderer rechaza) o "cámara incorrecta" (la siguiente sección). Desbloquee el viewport antes del envío, o establezca explícitamente View to Render en Render Setup.

Para la configuración de cámara específica del DCC, consulte , , o .

La escena renderizada no tiene luces

La geometría se renderiza, pero la escena está completamente oscura, o la iluminación es mucho más oscura de lo esperado — a menudo con un aspecto de wireframe sobre negro que sugiere que ninguna luz llega a las superficies.

Cuatro cosas a verificar:

1. Las luces están deshabilitadas en la visibilidad de renderizado. En Maya, las luces tienen una marca de visibilidad por renderizado en el Attribute Editor (Visibility → Render). Una luz visible en el outliner puede aún estar excluida del cómputo en tiempo de renderizado. En Blender, la visibilidad de renderizado del objeto de luz (el ícono de cámara en el outliner) controla si la luz contribuye al renderizado — separado del ícono de ojo del viewport.
2. Las luces están en una View Layer, Render Layer o colección oculta. Una luz visible en el viewport pero asignada a una capa no renderizada no contribuirá. Verifique que las luces están en la capa o colección que se está renderizando, no en una capa hermana que está oculta en el tiempo de renderizado.
3. La iluminación ambiental está deshabilitada. Si su escena depende de la iluminación ambiental HDRI — común en archviz y visualización de productos — verifique que el ambiente está habilitado en Render Properties. En Blender, World → Surface debe tener la textura de entorno o el shader de fondo conectado. En Maya, el nodo de entorno en el Hypershade debe estar conectado al slot de entorno en tiempo de renderizado de la escena. En 3ds Max, Environment and Effects (atajo de teclado 8) debe tener el HDRI asignado, y en V-Ray, el anulación del entorno de V-Ray es una configuración separada que anula el entorno de la escena.
4. GI o iluminación indirecta está deshabilitada. Para V-Ray y Corona, la iluminación global es una configuración separada de "luces presentes en la escena". Una escena diseñada para rebotes GI pero con GI deshabilitado en el preset de renderizado activo se verá oscura incluso si cada luz directa está correctamente configurada. En V-Ray, GI → Enable global illumination debe estar activado. En Corona, GI → Solver debe estar configurado (Path tracing o UHD Cache). En Redshift, GI → Enable GI debe estar activado. Consulte la para la configuración de caché GI específica del motor que sigue a esta habilitación.

Una prueba de diagnóstico rápida: añada temporalmente una sola luz de sol o direccional con intensidad 1.0 desde arriba de la escena y renderice un fotograma. Si incluso eso no aparece en la salida, el problema es la visibilidad de la capa o colección, no la configuración de la fuente de luz. Si el sol de prueba se renderiza correctamente, sus luces originales son el problema — revise los cuatro puntos anteriores.

La cámara incorrecta se renderiza a pesar de especificar la correcta

Configuró la Cámara A como cámara de renderizado, pero la salida muestra la vista de la Cámara B. Este es uno de los problemas de calidad más frustrantes porque el archivo de escena parece correcto al inspeccionarlo — la marca de renderizable está en la cámara correcta, la cámara activa es la que desea. La causa es casi siempre una de estas tres cosas:

1. Vista bloqueada al viewport en 3ds Max o Maya. Un viewport bloqueado (clic derecho en la etiqueta del viewport → Lock) anula la selección de cámara de Render Setup. El renderer usa la cámara del viewport, no la que configuró. Desbloquee el viewport antes de guardar la escena, o establezca explícitamente View to Render en Render Setup → Common (Maya) o Render Setup → Output (3ds Max). Esta es la causa más común de los tickets de "cámara incorrecta" en los envíos de 3ds Max — el bloqueo es fácil de activar accidentalmente con un atajo de teclado y fácil de pasar por alto antes del envío.
2. Escena con múltiples cámaras con la cámara activa incorrecta. Si su escena tiene múltiples cámaras — panorámica, principal, belleza, detalle, alternativas — verifique cuál está configurada como la cámara activa para la escena, take o capa de renderizado actual. En Cinema 4D, cada Take puede tener su propia cámara; en Blender, cada escena tiene su propia cámara activa; en Maya, las capas de Render Setup pueden anular la cámara por capa. La cámara que se renderiza es la cámara asignada en el nivel de capa / take / escena que envió, no la que seleccionó por última vez en el viewport.
3. Discrepancia de take, escena o capa de renderizado. ¿Envió la capa de renderizado A pero hereda su cámara del Master, y la cámara del Master es la Cámara B? Eso sucede. Siempre envíe desde el take o capa que tiene explícitamente la cámara que pretende, y evite depender de la herencia a menos que haya verificado la cadena.

La imagen de salida es parcial, recortada o no es el fotograma completo

El render vuelve pero solo se rellena una parte del fotograma — el resto es negro, transparente o del color repetido del viewport. Cuatro cosas a verificar:

1. La región de renderizado está habilitada. En V-Ray, Corona, Arnold y varios otros renderers, una opción de "Región" permite renderizar solo un subrectángulo del fotograma completo para una vista previa rápida. Si Región estaba habilitada durante las pruebas locales y no se deshabilitó antes del envío, el worker renderiza solo esa región — el resto del fotograma permanece en su color de relleno predeterminado. Esta es la causa individual más común de los tickets de salida de fotograma parcial.
2. Discrepancia de resolución de salida entre la escena y la configuración de renderizado. La resolución de salida de Render Properties y el tamaño real del fotograma en el archivo de salida deben coincidir. Si la apertura de la cámara de su escena está configurada a una resolución y su salida a otra, el renderer puede producir un relleno parcial — la cámara "ve" un área más pequeña que el lienzo de salida, y la región vacía permanece sin color.
3. Discrepancia de relación de aspecto entre la cámara y la salida. Una cámara con una relación de 1,78 renderizando a una salida de 1,0 producirá una imagen parcial — la vista de la cámara no rellena el fotograma de salida. Verifique que la relación de aspecto del film-back de la cámara coincide con la relación de aspecto de la salida, o que "Fit Resolution Gate" (o su equivalente — los diferentes DCCs lo nombran de forma diferente: "Resolution Gate Fit", "Camera Aperture", "Film Gate") está configurado para rellenar, horizontal, vertical o con sangrado según lo que requiera su plano.
4. Configuración de borde o recorte en el formato de salida. Algunos DCCs y algunos formatos de salida permiten establecer un borde de renderizado independiente del gate de resolución de la cámara. Verifique que el borde (en Render Properties, o en los atributos de la cámara) abarca el área de salida completa pretendida, no una subregión recortada.

Renders negros o en blanco

El render se completa con éxito — sin errores, sin advertencias — pero cada píxel es negro o completamente uniforme. Más común en Maya, pero lo vemos en todos los DCCs.

Cinco cosas a verificar:

1. Discrepancia en el toggle de capa. En Maya, la geometría puede ser visible en el viewport pero deshabilitada en el nivel de visibilidad en tiempo de renderizado (Display → Hide → Hide All Cameras, o Render Stats → Primary Visibility = off por objeto). En Blender, el equivalente es el toggle de visibilidad de renderizado (ícono de cámara) en el outliner. La causa más común es reestructurar las capas de una escena después de las pruebas y olvidar habilitar la visibilidad de renderizado en la nueva capa o colección.
2. Planos de recorte de la cámara configurados incorrectamente. Si el plano de recorte cercano o lejano está configurado incorrectamente — el plano lejano demasiado cerca de la cámara, el plano cercano detrás de la geometría — la cámara no incluye la geometría en su volumen de vista. Los planos predeterminados (cercano 0,1, lejano 1000-10000 dependiendo de la escala de la escena) son generalmente correctos; esto ocurre tras ajustes manuales, especialmente cuando se trabaja a escalas de escena inusuales (grandes conjuntos arquitectónicos o renders de productos microscópicos).
3. Luces renderizables pero emisión deshabilitada. Si usa materiales emisivos como luces, verifique que el shader de emisión está habilitado y tiene una intensidad distinta de cero. Algunos flujos de trabajo desactivan la emisión durante la interacción en el viewport para evitar calor de GPU y olvidan volver a habilitarla antes del envío.
4. Muestreo demasiado bajo para producir una salida visible. Con reducciones agresivas del muestreo de trazado de rayos (muestras por píxel muy bajas), las escenas muy oscuras pueden producir una salida completamente negra hasta que las muestras aumenten lo suficiente para converger. Renderice un fotograma localmente con la misma configuración para verificar; si el render local también es completamente negro con el mismo recuento de muestras, aumente el muestreo o verifique la configuración de iluminación.
5. Nodo de salida de renderizado mal configurado (Blender, Houdini). En el compositor de Blender y en la red ROP de Houdini, la cadena del nodo de salida puede configurarse para descartar el resultado del renderizado antes de guardarlo. Verifique que el nodo Composite está conectado a Render Layers (Blender) o que la ruta de salida del ROP está configurada correctamente y el modo de salida no es "Null" (Houdini).

Para Maya específicamente, consulte para el flujo de trabajo de selección de cámara y estadísticas de renderizado que previene la causa más común de renders negros en ese DCC.

Algunos objetos de la escena no se renderizan

Un objeto específico es visible en el viewport pero falta en la salida renderizada. El resto de la escena se renderiza correctamente. Común en todos los DCCs, ligeramente más común en Blender porque el modelo de visibilidad de tres estados de Blender (viewport / renderizado / selección) es fácil de configurar incorrectamente.

Cinco cosas a verificar:

1. Toggle de visibilidad de renderizado en el objeto. En el outliner de Blender, pase el cursor sobre la fila del objeto — tres íconos controlan la visibilidad: ojo (viewport), cámara (renderizado), pantalla (seleccionabilidad). Asegúrese de que el ícono de cámara está habilitado para el objeto faltante. En Maya, Attribute Editor → Render Stats → Primary Visibility debe estar activado. En 3ds Max, Object Properties → Rendering → Visibility del objeto debe estar configurado por encima de 0 (y Renderable debe estar marcado).
2. El objeto está en una colección, capa o conjunto oculto. Las colecciones en Blender tienen visibilidad de viewport y de renderizado separadas. La colección puede ser visible en el viewport pero excluida del renderizado mediante el toggle del ícono de cámara en la fila de la colección. En Maya, la asignación de Display Layer y Render Layer del objeto son separadas; en 3ds Max, Layer Properties → Renderable debe estar activado para cada capa que contiene geometría renderizable.
3. El material del objeto es invisible. Un material con opacidad cero, alfa cero o problemas de mezcla alfa se renderizará como efectivamente invisible — la geometría está ahí pero es transparente. Verifique la opacidad, el alfa, la transparencia y cualquier configuración de mezcla de alfa del material. Problema común: un material configurado para referencia "fantasma" en el viewport y nunca restaurado antes del envío.
4. La pila de modificadores oculta la geometría. Algunos modificadores (Boolean, Mask, Decimate con configuraciones extremas, Build) pueden eliminar efectivamente la geometría de la salida del renderizado aunque la malla fuente sea visible en el modo de viewport de la pila de modificadores. Deshabilite los modificadores uno por uno en el objeto faltante para identificar cuál es el culpable, luego corrija la configuración del modificador o aplíquelo / hornéelo antes del envío.
5. El objeto es un proxy o instancia con una referencia rota. Los objetos proxy (V-Ray Proxy, Redshift Proxy, Arnold Standin), los cachés de Alembic y las instancias referencian archivos externos. Si la ruta de referencia está rota — ruta absoluta incorrecta, archivo faltante en el archivo, recurso compartido de red que no existe en el worker — el proxy se renderiza como nada. Esto se superpone con §Assets faltantes a continuación; consulte esa sección para el flujo de trabajo completo de verificación de rutas.

Errores de configuración de caché GI, irradianza y caché de luz

Esta sección se superpone con la pero cubre los síntomas que aparecen como problemas de calidad en lugar de problemas de rendimiento. Si su render vuelve con parpadeo entre fotogramas, iluminación indirecta irregular, bandas en áreas oscuras, o iluminación visiblemente diferente en fotogramas adyacentes de la misma animación, la causa es casi siempre una configuración de caché GI que no sobrevive al renderizado distribuido.

El problema central: las cachés GI en V-Ray (Irradiance Map, Light Cache), Corona (UHD Cache, Path tracing) y Redshift (Irradiance Cache, Photon Map) son conjuntos de datos de iluminación precomputados. Cuando renderiza una animación, la caché debe ser (a) precomputada una vez y reutilizada en cada fotograma, o (b) computada por fotograma con suficiente calidad para verse idéntica fotograma a fotograma. Mezclar los dos — dejar que cada worker compute su propia caché por fotograma a baja calidad — produce un parpadeo visible, porque el patrón de ruido de cada worker es diferente.

Cuatro configuraciones incorrectas comunes y qué hacer con ellas:

1. Modo GI por fotograma en animación. El modo "Single frame" de V-Ray para Irradiance Map y Light Cache computa una caché nueva para cada fotograma. En una render farm distribuida, cada worker computa la suya — no las comparten. El resultado es el parpadeo de la animación. Cambie a "Multiframe Incremental" con el archivo de caché guardado en disco, o precompute la caché como un prepass separado y use "From file" para el pase de animación real. Consulte la para el flujo de trabajo completo.
2. La ruta del archivo de caché es local y falta en los workers. Si guardó un Irradiance Map precomputado en C:\Users\SuNombre\Documents\maps\ir.vrmap y envió el trabajo, los workers no tienen ese archivo. Recurren al cómputo por fotograma (la primera causa anterior) y la animación parpadea. Guarde los archivos de caché en la carpeta del proyecto, use rutas relativas e incluya los archivos de caché en su archivo de proyecto antes del envío.
3. La calidad de la caché es demasiado baja para la escena. Incluso cuando está configurada correctamente (precomputada, incluida en el archivo), una Light Cache con 500 subdivisiones o un Irradiance Map con calidad "Very Low" puede ser insuficiente para una escena archviz oscura con mucho GI. Los renders se ven ruidosos o irregulares, especialmente en esquinas y bajo los muebles. Aumente las subdivisiones o use el preset Universal como línea base.
4. UHD Cache reutilizado en cámaras incompatibles. UHD Cache (Corona, V-Ray) depende del punto de vista de la cámara. Una caché precomputada para la Cámara A y reutilizada en la Cámara B producirá una iluminación incorrecta — la caché "piensa" que la cámara está en un lugar en el que no está. Si renderiza múltiples cámaras de la misma escena, precompute un UHD Cache por cámara, o use Path tracing (sin caché) para la consistencia entre cámaras.

Para la configuración completa de la caché GI, notas de versión para V-Ray 6.x, y el flujo de trabajo de precálculo que se envía limpiamente a la render farm, consulte la .

Assets faltantes — texturas, proxies, referencias, plugins

El render se completa pero partes de la escena son obviamente incorrectas: las texturas son rosas (predeterminado de Maya para textura faltante), moradas (predeterminado de V-Ray), con patrón de tablero de ajedrez (Arnold) o magenta sólido (Blender). Los proxies se renderizan como cajas delimitadoras o espacio vacío. Los materiales específicos se renderizan como el marcador de posición "faltante" del motor.

La causa es la resolución de rutas. Su archivo de escena referencia los assets por ruta, y en el worker, esas rutas no se resuelven. Seis cosas a verificar:

1. Rutas absolutas en el archivo de escena. Si su escena referencia texturas en C:\Users\SuNombre\Project\textures\wood.jpg, el worker no tiene esa ruta. Use rutas relativas (./textures/wood.jpg o ../textures/wood.jpg) o empaquete los assets en el archivo de escena. La mayoría de los DCCs tienen un flujo de trabajo "Make Paths Relative" o "Resource Collector" que convierte las rutas absolutas en relativas antes del envío — File Path Editor de Maya, Asset Tracking de 3ds Max, File → External Data → Make Paths Relative de Blender, File → Save Project with Assets de Cinema 4D, Pre-Render Script de Houdini con hou.findFile.
2. Assets no incluidos en el archivo de proyecto. Las rutas relativas ayudan, pero solo si los assets que referencian están realmente presentes en el archivo que cargó. Ejecute la herramienta de consolidación de proyectos del DCC (o simplemente comprima toda la carpeta del proyecto incluyendo texturas, cachés, referencias e HDRIs) antes del envío. No confíe en que cargó todo — verifique con una comparación de listas.
3. Discrepancia de mayúsculas y minúsculas. Windows no distingue entre mayúsculas y minúsculas (Texture.JPG y texture.jpg son el mismo archivo); los workers de la render farm ejecutan Linux, que sí distingue entre mayúsculas y minúsculas (son archivos diferentes). Un archivo de escena que referencia Texture.JPG no encontrará texture.jpg en un worker Linux. La mayoría de los DCCs convierten las rutas en minúsculas al exportar — pero no siempre. Si ve texturas específicas faltando solo en la render farm, verifique las mayúsculas del nombre de archivo real frente a las mayúsculas en la referencia del archivo de escena.
4. Plugin no instalado en los workers. Si su escena depende de un plugin de terceros — Forest Pack, RailClone, Phoenix FD, MultiScatter, GrowFX, Ornatrix — el worker debe tener ese plugin instalado a la misma versión. Preinstalamos los plugins principales, pero verifique que su versión específica es compatible consultando el documento del DCC relevante. Si su plugin no es compatible, deberá hornear la salida del plugin (dispersión a malla, cabello a malla) antes del envío, o escalar al soporte.
5. Escenas vinculadas o referenciadas con rutas rotas. Si su escena principal referencia una subescena (referencia de Maya, Biblioteca vinculada de Blender, Escena XRef de 3ds Max), y la ruta de la subescena es absoluta o externa al archivo, el worker no puede encontrarla. Las subescenas deben estar en el archivo y referenciarse relativamente, igual que las texturas.
6. Discrepancia de versión de asset. Menos común pero vale la pena verificar: una escena guardada en Maya 2026 con assets que dependen de tipos de nodos específicos de Maya 2026 no se renderizará correctamente en un worker con Maya 2024. Haga coincidir la versión de guardado de la escena con la versión del worker indicada en el documento setting-up-* relevante.

Si ha verificado los seis puntos y los assets aún faltan, el equipo de soporte puede obtener el registro del worker en tiempo de renderizado para su trabajo e identificar exactamente qué ruta de asset no se resolvió. Ese registro reduce la causa de "algo falta" a "este archivo específico en esta ruta específica".

Deriva de color entre salidas EXR y PNG del mismo render

Renderizó la misma escena a EXR y PNG y los colores no coinciden. Esto es generalmente un comportamiento esperado en lugar de un error, pero sorprende a la gente con suficiente frecuencia como para merecer su propia sección.

EXR almacena datos de punto flotante lineal sin una transformación de color horneada. PNG (y JPEG, BMP) hornea la transformación de visualización en los valores de píxeles. Cuando ve el EXR en un compositor con la transformación de visualización Filmic, ACES, sRGB o AgX correspondiente aplicada, debería coincidir visualmente con el PNG — los datos subyacentes son los mismos, pero la codificación es diferente.

Dos situaciones en las que esto se convierte en un problema real:

1. La gestión de color del compositor difiere de la gestión de color del DCC. Si renderiza un EXR con la View Transform ACES aplicada en su DCC, luego abre el EXR en un compositor (Nuke, Fusion, After Effects, Resolve) configurado para sRGB o sin gestión de color, el resultado mostrado diferirá. Configure el compositor para usar la misma View Transform / configuración OCIO que su DCC. Este es uno de los problemas de incorporación al compositor más comunes que vemos — el EXR está bien, el compositor lo interpreta incorrectamente.
2. El PNG se guardó con una View Transform diferente al EXR. Algunos DCCs permiten anulaciones de View Transform por formato. Si configuró EXR como "Raw" y PNG como "sRGB" en la configuración de salida de la misma escena, producirán resultados visualmente diferentes del mismo render, por diseño. Verifique la configuración de salida por formato y estandarice en una transformación a menos que necesite específicamente variación por formato.

Flujo de diagnóstico general

Cuando aparece un problema de calidad de renderizado, trabaje a través de estos pasos en orden. La mayoría de los tickets se resuelven en los pasos 1–3 sin necesidad de escalar.

1. Reproduzca localmente. Renderice un fotograma de la escena problemática en su estación de trabajo con la misma configuración que el envío a la render farm. Si local coincide con la render farm, el problema está en la escena — solucione la escena. Si local difiere de la render farm, el problema es ambiental: ruta, versión de plugin, configuración OCIO o archivo de assets.
2. Verifique la gestión de color y la View Transform. Esto causa ~40% de los problemas de calidad que vemos en el soporte.
3. Verifique la selección de cámara en la configuración de renderizado. ~20% — cámara incorrecta, viewport bloqueado, discrepancia de capa o take.
4. Verifique la región de renderizado, el borde o el recorte. ~10% — salida parcial.
5. Verifique la visibilidad de capa, colección o Render Layer. ~15% — objetos faltantes, luces faltantes, escenas oscuras.
6. Verifique el etiquetado del espacio de color de las texturas. ~10% — deriva de brillo sutil pero generalizada.
7. Verifique la configuración de caché GI para el parpadeo de animación. ~3% — consulte la .
8. Verifique las rutas de assets y la integridad del archivo. ~2% — texturas rosas, proxies faltantes.

Si los pasos 1–8 no identifican la causa, el equipo de soporte obtendrá el registro del worker para su trabajo y reducirá la causa a un estado específico de la flota de workers, una incompatibilidad de versión del renderer o un problema de configuración que podemos abordar de nuestra parte. Envíe un mensaje de soporte con el ID del trabajo, la salida incorrecta y una descripción de lo que esperaba — eso es suficiente para que comencemos el rastreo.

Referencias cruzadas

• — resolución de problemas de fallos de trabajos (el trabajo no se completó en absoluto)
• — flujo de trabajo de carga, envío y descarga
• — caché GI, Irradiance Map, Light Cache, configuración de UHD Cache
• — empaquetado de archivos de proyecto, consolidación de assets, prevención de assets faltantes
• — cámara de Maya, capa de renderizado, configuración de estadísticas de renderizado
• — bloqueos de cámara de 3ds Max, renderizado de región, configuración de Gamma y LUT
• — sistema Take de Cinema 4D, etiquetas de cámara, perfil de color
• — visibilidad de renderizado de Blender, gestión de color, Filmic vs AgX
• — gestión de color de AE para la salida de renderizado de composición
• — referencia de cámara ROP de Houdini, configuración del nodo de salida

FAQ

Q: Mi render volvió más oscuro que mi viewport. ¿Qué cambió? A: Casi siempre una discrepancia de gestión de color o View Transform. La transformación de color del archivo de salida refleja la configuración guardada de Render Properties → Color Management, no el estado actual de su viewport. Verifique que View Transform (Filmic, AgX, Standard, sRGB, ACES) y la configuración de Look están guardados correctamente en su proyecto antes del envío, y que el etiquetado del espacio de color de sus texturas es consistente (sRGB para texturas de color, Non-Color para texturas de datos).

Q: Mi render volvió sin iluminación. La escena tiene luces, puedo verlas en el viewport. A: Verifique cuatro cosas en orden: (1) el toggle de visibilidad de renderizado de cada luz (separado de la visibilidad del viewport); (2) en qué Render Layer, View Layer o colección están las luces, y si esa capa está habilitada para el renderizado; (3) si el entorno HDRI está habilitado en Render Properties o el shader de World; (4) si GI o Iluminación indirecta está habilitado en la configuración de renderizado activa para los motores que lo controlan por separado (V-Ray, Corona, Redshift).

Q: La cámara incorrecta se renderizó aunque seleccioné la correcta en la configuración de renderizado. A: Lo más probable es una condición de "View Locked" en 3ds Max o Maya — un viewport bloqueado anula la selección de cámara de la configuración de renderizado. Desbloquee el viewport, o establezca explícitamente View to Render en Render Setup de su DCC antes del envío. También verifique que el Take, Escena o Render Layer que envió tiene la cámara que pretende al nivel de la capa, ya que algunos DCCs heredan la cámara de un padre.

Q: ¿Por qué mis salidas EXR y PNG del mismo render se ven diferentes? A: EXR almacena datos de punto flotante lineal sin una transformación de visualización horneada; PNG hornea la transformación de visualización en los valores de píxeles. Cuando ve el EXR en un compositor con la View Transform correspondiente aplicada, debería verse igual que el PNG. Si se ven diferentes en el compositor, la gestión de color del compositor no coincide con la de su DCC — configure el compositor para usar la misma configuración OCIO y View Transform.

Q: Un objeto específico falta en mi render pero es visible en el viewport. A: Verifique (1) la marca de visibilidad de renderizado del objeto (separada de la visibilidad del viewport — ícono de cámara en Blender, Primary Visibility en Maya, Renderable en 3ds Max); (2) la visibilidad de la colección, Render Layer o Display Layer en la que vive el objeto; (3) si algún modificador (Boolean, Mask, Decimate) está ocultando la geometría en tiempo de renderizado; (4) si el objeto es un proxy con una referencia externa rota (véase también la sección de Assets faltantes).

Q: Mi render volvió parcial o recortado. La mitad del fotograma es negro. A: Verifique si la Región de renderizado (o Borde, Recorte) está habilitada en su renderer. El renderizado de región produce un relleno parcial del fotograma de salida. Deshabilite la región antes del envío, o configúrela al fotograma completo. También verifique que la relación de aspecto de la cámara coincide con la relación de aspecto de la salida, y que la resolución de salida en Render Properties coincide con la resolución del film-back de la cámara.

Q: Mis texturas se ven lavadas o sobresaturadas en comparación con mi estación de trabajo. A: Etiquetado del espacio de color de las texturas. Las texturas de color (difuso, albedo, color base) deben etiquetarse como sRGB o Color; las texturas de datos (normal, rugosidad, desplazamiento, metálico, opacidad) deben etiquetarse como Non-Color, Linear o Raw. Las texturas mal etiquetadas causan una deriva de color sutil pero consistente, especialmente en materiales PBR donde la gamma del mapa normal importa.

Q: Mi configuración OCIO de ACES está en mi estación de trabajo. ¿La respeta la render farm? A: Sí, si los archivos de configuración OCIO se incluyen en su archivo de proyecto y el archivo de proyecto referencia la configuración mediante una ruta relativa. Si los archivos de configuración OCIO faltan en el archivo, el worker recurre a la configuración predeterminada del DCC (típicamente Filmic para Blender, sRGB para la mayoría de los demás), y sus colores se desviarán. Incluya siempre la carpeta de configuración OCIO en su archivo de proyecto.

Q: Mi animación parpadea — cada fotograma parece tener una iluminación indirecta diferente. A: Configuración incorrecta de la caché GI. En V-Ray, cambie de Irradiance Map en modo "Single frame" a "Multiframe Incremental" con la caché guardada en disco, y precompute la caché como un prepass o use el preset de Path tracing Universal. Para otros motores, consulte la configuración de caché GI correspondiente — la regla es la misma: precompute una vez y reutilice, o use un modo sin caché (Path tracing) para la consistencia entre fotogramas. Consulte la para el flujo de trabajo completo.

Q: Mis texturas se renderizan rosas, moradas o magenta en la render farm. A: Assets faltantes. El archivo de escena referencia texturas en rutas que el worker no puede resolver — generalmente rutas absolutas de Windows (C:\Users\...), assets no incluidos en el archivo de proyecto, o discrepancias de mayúsculas entre su sistema de archivos de Windows y el sistema de archivos Linux del worker. Use rutas relativas, ejecute la herramienta de consolidación de proyectos de su DCC antes del envío, y verifique que el archivo incluye cada textura referenciada.

Q: Mi escena de Forest Pack / Phoenix FD / Ornatrix volvió con los objetos del plugin faltantes. A: Incompatibilidad de versión o compatibilidad del plugin en el worker. Consulte el documento relevante o para las versiones de plugins compatibles en nuestra flota de workers. Si su versión es compatible, la escena debería renderizarse correctamente — si no es así, hornee la salida del plugin a malla antes del envío, o contacte con el soporte para verificar el estado de instalación de su versión específica del plugin.

---