Problemas de renderizado 3D: guía de soluciones

Los problemas de renderizado son inevitables cuando se trabaja en 3D. Ya sea que ejecute trabajos en una estación de trabajo local o los distribuya en una render farm en la nube, tarde o temprano algo saldrá mal. En SuperRenders Farm hemos encontrado casi todos los tipos de fallos de renderizado imaginables y, en esta guía, le explicamos los problemas más comunes, cómo diagnosticarlos y los pasos que utilizamos para resolverlos.

Esto no es una descripción teórica: son problemas reales que interrumpen los plazos de entrega y consumen recursos de las máquinas. Abordémoslos de forma sistemática.

Antes de solucionar problemas, resulta útil entender cómo funciona el pipeline de renderizado de principio a fin. Nuestra guía sobre el renderizado en gráficos por computadora cubre los fundamentos técnicos, desde la configuración de la escena hasta el resultado final.

Para errores de renderizado específicos de red (en particular, fallos de socket en configuraciones distribuidas como 3ds Max Backburner), nuestra guía para solucionar errores de red "socket operation unreachable" cubre las causas raíz y los pasos de recuperación.

Renders en negro o en blanco

La salida en negro o completamente en blanco es el problema más frecuente que vemos. El renderizado se completa sin errores, pero el fotograma resultante aparece completamente negro, blanco o solo muestra un color de fondo.

Causas principales:

La cámara no apunta a la geometría
Las luces están desactivadas o tienen intensidad cero
Los materiales no están asignados o están configurados en negro
La configuración de visibilidad de las capas de renderizado oculta la geometría
Problemas con los planos de recorte que cortan objetos
Vinculación de luces incorrecta en Arnold o V-Ray

Nuestro enfoque de diagnóstico:

Primero, verifique la escena en el modo de vista previa del viewport. Cargue un render de referencia sencillo (normalmente utilizamos una escena de prueba tipo Cornell box para esto). Si el viewport muestra la geometría pero la salida del render es negra, el problema está en el motor de renderizado o en una discrepancia con el viewport.

Compruebe la posición de la cámara confirmando la posición y el volumen de vista de la cámara activa. En Maya, revise Near Clip Plane y Far Clip Plane en la forma de la cámara: unos planos de recorte demasiado ajustados cortarán su escena. Hemos perdido horas rastreando valores de near clip plane configurados en 1000 unidades.

En cuanto a la iluminación, active las estadísticas de renderizado en su DCC o establezca la verbosidad en alta en su renderizador. La mayoría de los motores informarán de cero luces o de fuentes con intensidad cero. Si Arnold indica "no light sources", verifique físicamente que al menos una luz tenga intensidad distinta de cero y que no esté vinculada para excluir su geometría.

Para el diagnóstico de materiales en Maya, active Use Default Material en la configuración de renderizado. Si la escena se renderiza con el material predeterminado gris, el problema son sus materiales personalizados. En ese caso, compruebe las asignaciones de materiales y asegúrese de que ninguno tenga un albedo difuso negro con emisión cero.

Errores por falta de memoria

Los fallos por falta de memoria (OOM) interrumpen los renders por lotes a mitad de proceso, normalmente después de consumir horas en una render farm en la nube. El proceso de renderizado se bloquea, o la render farm informa de un tiempo de espera agotado combinado con un uso elevado de memoria.

Factores que consumen memoria:

Resolución y formato de las texturas (las texturas EXR sin comprimir son costosas)
Número de polígonos sin control del nivel de subdivisión
Objetos proxy no habilitados
Rebotes de reflexión y refracción con trazado de rayos
Algoritmos de denoising que retienen fotogramas intermedios
Sobrecarga de plugins provenientes de renderizadores o deformadores sin usar

Nuestro flujo de trabajo de optimización:

Siempre optimizamos las texturas antes de renderizar. Cambie las texturas OpenEXR de 16 bits por PNG o TIFF de 8 bits cuando la calidad lo permita: esto reduce el consumo de memoria en un 50%. Desactive el padding de textura y utilice clamp to edge en lugar de mirror o repeat si el diseño del asset lo permite.

Para los objetos proxy, en SuperRenders Farm aplicamos una política: la geometría con más de 2 millones de polígonos debe usar proxies de Alembic con subdivisión en el momento del renderizado. Esto significa que el archivo de escena base se mantiene por debajo de los 100 MB, y la subdivisión solo ocurre durante el renderizado. En Katana o Houdini, utilice instancing y packed primitives.

Reduzca el número de rebotes. La mayoría de los trabajos de producción necesitan entre 2 y 4 rebotes indirectos, no 8 ni 12. Pruebe su beauty pass con 3 rebotes: rara vez notará diferencias de calidad en el color final. Reduzca por separado los rebotes de reflexión y refracción: las reflexiones normalmente necesitan entre 1 y 2, y las refracciones entre 1 y 3.

Desactive los denoisers durante las pasadas de borrador, o utilice denoisers ligeros como OptiX en lugar de algoritmos de acumulación de fotograma completo. Los denoisers añaden entre 2 y 4 GB de sobrecarga por fotograma.

Tiempos de renderizado lentos

Los tiempos de renderizado largos retrasan la iteración y cuestan más en las render farms en la nube. Las causas más comunes son una configuración de muestreo agresiva, una iluminación ineficiente o parámetros de escena mal configurados.

Factores clave de rendimiento:

Muestreo (AA, muestras difusas, muestras de reflexión)
Número de rebotes de luz y calidad de GI
Renderizado de volúmenes y subsurface scattering
Resolución del shadow map en motores rasterizados
Sobrecarga del denoiser

Ajuste de rendimiento:

Comenzamos toda optimización por el muestreo. Configure las muestras difusas de forma conservadora: entre 6 y 12 muestras son suficientes para la mayoría de las superficies cuando se combinan con un denoiser. Pruebe primero con 8 muestras y, solo si persiste ruido visible, súbalas a 12. Usuarios de Arnold: configure AA_samples entre 3 y 5 para borradores, y entre 5 y 7 para versiones finales.

A continuación, simplifique la iluminación. Las luces de polígono y las superficies emisivas se ven muy bien, pero requieren más muestras para converger. Reemplace la geometría emisiva costosa por objetos de luz simples cuando sea posible. En V-Ray, configure las muestras de luz en 2 o 3 en lugar de auto: esto fuerza un muestreo eficiente sin redundancia.

Para la GI, utilice la separación de motor primario y secundario. La GI con trazado de rayos es costosa; considere usar GI de fuerza bruta (screen-space) para los impactos primarios y luego cambie a path tracing para los rebotes. En RenderMan, utilice PxrPathTracer con integrator:indirectSamples configurado entre 2 y 4.

La calidad del denoiser frente a la velocidad es un equilibrio. Utilice OptiX o denoisers bilaterales rápidos para las iteraciones, y reserve los denoisers de fotograma completo para los fotogramas finales.

Parpadeo en fotogramas de animación

El parpadeo (la variación temporal en la que fotogramas adyacentes muestran ruido o cambios de intensidad) arruina la calidad de la animación. Esto ocurre cuando el muestreo es inconsistente de un fotograma a otro, o cuando la GI cambia entre fotogramas.

Causas comunes:

Umbral de ruido demasiado bajo, que varía por fotograma
La iluminación global no se recalcula de forma consistente
Muestreo adaptativo con umbrales por fotograma
Luces animadas con sombras inestables

Enfoque de estabilización:

Fije el umbral de ruido de forma global. No utilice umbrales adaptativos por fotograma; en su lugar, establezca un número fijo de muestras. En SuperRenders Farm aplicamos un muestreo fijo para todas las secuencias de animación: un mínimo de 64 muestras AA, 8 muestras difusas, bloqueadas en todos los fotogramas.

Para lograr estabilidad en la GI, utilice GI en caché al renderizar secuencias. RenderMan permite precalcular (bake) la GI antes de renderizar la animación; V-Ray ofrece Light Cache, que actualizamos una vez y reutilizamos en todos los fotogramas. Esto elimina la variación de la GI de un fotograma a otro.

Las luces animadas requieren un cuidado adicional. Configure una resolución de shadow map alta (mínimo 2048x2048) y desactive el filtrado del shadow map si su renderizador lo permite: el filtrado puede introducir inestabilidad temporal. En Redshift, active Shadow Map Filtering, pero configure la calidad en High en lugar de Very High.

Texturas faltantes y rutas de assets rotas

Los renders fallan cuando el renderizador no puede localizar los archivos de textura. Esto es habitual al mover proyectos, al usar rutas relativas sin una estructura de directorios adecuada, o al mezclar barras diagonales y barras invertidas en render farms multiplataforma.

Estrategias de resolución de rutas:

Utilice rutas relativas con un punto de anclaje consistente. Definimos todas las rutas de textura en relación con la raíz del proyecto mediante variables de entorno. En Maya, configure MAYA_PROJECT_PATH y haga referencia a las texturas como $MAYA_PROJECT_PATH/textures/diffuse.tx. RenderMan y Houdini admiten mecanismos similares.

En el caso de las render farms en la nube, empaquete las texturas de forma explícita. No confíe en que la render farm encuentre las texturas mediante la búsqueda del sistema operativo. Siempre incluimos un archivo de manifiesto que enumera todas las dependencias de textura, y luego utilizamos un script previo al renderizado para verificar que todas las rutas existen antes de encolar el trabajo.

En las render farms multiplataforma, convierta todas las rutas a barras diagonales. Utilice / también en Windows, no \. La mayoría de los motores de renderizado normalizan esto automáticamente, pero una consistencia explícita evita casos límite.

Pruebe la resolución de texturas localmente con la misma configuración de rutas de búsqueda que la render farm. Utilice la herramienta de validación de texturas de su renderizador: arnoldTextureManager de Arnold, o el Material Library Explorer de V-Ray. Estas herramientas informan de los archivos faltantes antes del renderizado.

Errores de licencia durante el renderizado por lotes

Los fallos al obtener una licencia o los tiempos de espera agotados del servidor de licencias detienen los trabajos por lotes. Esto ocurre cuando se agotan los grupos de licencias o el servidor no está disponible.

Gestión de licencias:

Reserve licencias flotantes para el trabajo por lotes. En SuperRenders Farm mantenemos un grupo de licencias flotantes independiente para los trabajos de render en la nube, separado de las estaciones de trabajo interactivas. Esto evita que un solo artista consuma todas las licencias a mitad de un render.

En el caso de las render farms en la nube, incluya un mecanismo de reintento de licencia. Configure un tiempo de concesión de licencia alto (entre 8 y 12 horas) y active la obtención automática en los nodos de la render farm. En RenderMan, configure RMANTREE y RMS_LICENSE_FILE en su script de renderizado, y luego verifique con rlic info.

Si su renderizador admite licencias locales, utilícelas para el renderizado en la nube. Las licencias flotantes añaden latencia de red; las cachés locales son más rápidas y fiables.

Bloqueos durante el renderizado

Los bloqueos del proceso de renderizado (fallos de segmentación, corrupción de memoria) detienen los trabajos sin generar ninguna salida. Son más difíciles de diagnosticar porque los registros de error son escasos.

Enfoque de diagnóstico:

Active los core dumps y el registro completo. Ejecute el renderizador en primer plano en una máquina de prueba, capturando por completo stderr y stdout. Utilice strace (Linux) o dtruss (macOS) para rastrear las llamadas al sistema e identificar dónde se produce el bloqueo.

Compruebe si hay archivos de escena corruptos. Exporte un subconjunto de geometría (entre 10 y 20 objetos) y vuelva a renderizar. Si el subconjunto se renderiza correctamente, siga aislando el problema. Hemos comprobado que las referencias corruptas, los shaders rotos o los archivos de caché no válidos provocan bloqueos que no aparecen hasta el renderizado.

Valide con una escena limpia. Abra la escena problemática en un archivo nuevo e importe la geometría desde cero. Copie los shaders y las luces manualmente en lugar de referenciarlos desde el archivo corrupto.

Actualice las versiones del renderizador. Los bloqueos suelen indicar errores conocidos que ya se han corregido en versiones más recientes. Compare las notas de la versión del renderizador con la suya.

Solución de problemas en la render farm en la nube

Las render farms en la nube añaden complejidad: resolución de rutas, versiones de plugins y limitaciones específicas de cada render farm.

Diagnósticos específicos de la render farm:

Verifique que las versiones de los plugins coincidan con las de su estación de trabajo local. La mayoría de las render farms ejecutan versiones específicas de V-Ray, Arnold o RenderMan. Si su escena utiliza un plugin más reciente, fallará en los nodos más antiguos de la render farm. Compruebe las versiones compatibles de su render farm y, si es necesario, baje de versión localmente.

Ponga a prueba las suposiciones sobre las rutas. Los nodos de la render farm en la nube pueden montar el almacenamiento del proyecto en /mnt/projects/ en lugar de C:\projects\. Utilice variables de entorno o rutas absolutas que la render farm documente.

Compruebe el espacio en disco de los nodos de la render farm. Algunas render farms purgan automáticamente los assets de trabajos antiguos; si su render utiliza una textura en caché de un trabajo anterior, es posible que ya no exista en el nodo. Incluya siempre los assets dependientes de forma explícita al enviar su trabajo.

Utilice la función de render de prueba de la render farm. Envíe un trabajo de prueba de un solo fotograma con la máxima verbosidad antes de encolar una secuencia completa. Esto detecta el 80% de los problemas específicos de la render farm antes de perder tiempo.

Lista de verificación de problemas de renderizado

Cuando un render falla, siga este orden:

FAQ

Q: Mi salida de render es completamente negra, pero el viewport muestra la escena correctamente. A: El problema casi siempre es el recorte de la cámara o las luces desactivadas. Primero, compruebe los planos de recorte cercano y lejano de su cámara (ajuste el recorte cercano a 0.01 y el lejano a 10000 como prueba general). A continuación, verifique que al menos una luz tenga intensidad distinta de cero y que no esté vinculada para excluir su geometría. Si utiliza Arnold, compruebe la vinculación de luces en el Attribute Editor.

Q: Se producen errores por falta de memoria en la render farm, pero la misma escena se renderiza correctamente en local. A: Es probable que su estación de trabajo local tenga más RAM que el nodo de la render farm. Reduzca la resolución de las texturas (utilice 4K en lugar de 8K), desactive el denoiser, baje el número de rebotes a entre 2 y 3, y active los objetos proxy para la geometría con muchos polígonos. Pruebe localmente con esta misma configuración para confirmar que el problema es de memoria y no de otro tipo.

Q: Los fotogramas se renderizan a velocidades distintas aunque la configuración es idéntica. A: Esto es una variación normal en una render farm debido a la carga del sistema. Si la variación de velocidad supera el 20%, compruebe si hay cuellos de botella de E/S en disco: las lecturas lentas de texturas provocan variaciones entre fotogramas. Utilice almacenamiento SSD para las texturas y aumente el tamaño de la caché de texturas en la configuración de su renderizador.

Q: Mi animación parpadea entre fotogramas. A: Fije su muestreo en un número constante; no utilice un muestreo adaptativo por fotograma. Configure AA_samples en 64, diffuse_samples en 8, y desactive los umbrales adaptativos. Para la GI, utilice GI en caché (Light Cache en V-Ray, GI precalculada en RenderMan) para que la iluminación sea consistente en todos los fotogramas.

Q: ¿Cómo sé si mis tiempos de renderizado son normales? A: Realice una prueba de referencia con una escena de prueba conocida. Nosotros utilizamos una Cornell box sencilla con tres luces y una esfera reflectante, que debería tardar entre 10 y 20 segundos en renderizarse con la configuración de producción. Si su fotograma de producción tarda más de 100 segundos, es posible que su escena tenga geometría costosa, demasiados rebotes, o un muestreo demasiado agresivo.

Enlaces internos: Consulte nuestra guía sobre cómo solucionar los errores de Autodesk CER para soluciones específicas de licencias, y obtenga más información sobre la solución de problemas de renders en negro o en blanco específicos de Maya.

Referencia externa: Para profundizar más en la optimización del renderizado, consulte la documentación de RenderMan sobre optimización de muestreo y GI.