Renderizado en la nube para compositing VFX: comp vs 3D

Introducción

La mayoría del contenido sobre renderizado en la nube está escrito para una sola carga de trabajo: una escena 3D que pasa por un path tracer, por buckets, hasta que el ruido desaparece y el fotograma queda terminado. Ese planteamiento es preciso para un trabajo de Redshift o V-Ray, y resulta casi inútil para un render de compositing (composición de imágenes). Un compositing no muestrea rutas de luz. Evalúa un grafo de nodos sobre el metraje y los pases que ya existen, y lo que determina cuánto tarda y cuánto cuesta casi nunca es el número de muestras de la GPU.

Esa distinción importa más de lo que parece a primera vista, porque los consejos genéricos sobre "renderizado en la nube" mezclan constantemente ambas cargas de trabajo. Un compositor que sube por primera vez un script de Nuke o un proyecto de After Effects a una render farm, esperando el mismo comportamiento limitado por GPU que un render 3D, acaba confundido: no entiende por qué un compositing sin simulaciones ni ray tracing sigue siendo lento, o por qué es rápido de una forma que no tiene nada que ver con el nivel de GPU que eligió. Esta guía trata precisamente de esa brecha: qué hace realmente un render de compositing en una render farm, en qué se diferencia mecánicamente de un render 3D, y cuándo vale la pena mover el trabajo de compositing a la nube en lugar de dejar una estación de trabajo renderizando toda la noche.

En Super Renders Farm trabajamos a diario con ambos lados de este pipeline en nuestra render farm, desde el render 3D que produce el beauty pass y los AOVs hasta el render de compositing que los ensambla en el plano final. Ambos comparten el hardware, pero poco más en cuanto a comportamiento de render, y entender esa diferencia es lo que convierte un trabajo de render de compositing en algo predecible en lugar de un misterio.

Diagrama de pipeline que muestra el flujo de compositing con EXR multicapa y multipase: los pases de render 3D se combinan en un archivo EXR multicapa, que después pasa al software de compositing y a la gradación final

El compositing es una carga de trabajo de render distinta al renderizado 3D

Un motor de render 3D como V-Ray, Redshift o Arnold hace transporte de luz: traza rayos, muestrea materiales y acumula reducción de ruido a lo largo del tiempo hasta que la imagen converge. Ese trabajo es genuinamente intensivo en cómputo por píxel, razón por la cual el renderizado 3D depende en gran medida de la CPU o de la GPU según el motor, y por la que la aceleración por GPU tiene un efecto tan grande en los tiempos de render 3D.

Un render de compositing no hace nada de eso. Nuke, After Effects, Fusion y herramientas similares evalúan un grafo de nodos: leen una imagen, aplican una corrección de color, fusionan dos capas, aplican una transformación, escriben el resultado. No hay muestreo ni convergencia. Cada operación es un pase determinista, sobre todo de álgebra lineal, sobre los datos de píxel, y la mayoría de esas operaciones (fusiones, gradaciones, keyers, transformaciones y la mayoría de los filtros) se ejecutan en la CPU y no en la GPU. Un puñado de tipos de nodo concretos (cambios de velocidad (retime) pesados, algunas operaciones de denoising, ciertas herramientas de machine learning) sí están acelerados por GPU, pero son la excepción en un compositing típico, no la regla.

Lo que realmente determina cuánto tarda un render de compositing se parece más a un problema de movimiento de datos que a un problema de cómputo:

Rendimiento de lectura. Un script de compositing lee metraje y pases de render, a menudo varias secuencias EXR multicapa a la vez, en cada fotograma.
Threading de CPU. Las operaciones de compositing se paralelizan entre núcleos de CPU dentro de un mismo fotograma, y el gestor de render paraleliza entre fotogramas repartiendo bloques del rango de fotogramas entre distintos workers.
Memoria. Mantener en memoria varios fotogramas a resolución completa y con múltiples canales al mismo tiempo (un beauty pass, un puñado de AOVs, una matte de cryptomatte, quizá un pase deep) consume mucha más memoria de lo que parece, y quedarse sin RAM a mitad de fotograma es una causa de fallo en el render de compositing más común que la velocidad de CPU en bruto.
Rendimiento de escritura. El fotograma compuesto final, o un precomp intermedio, hay que escribirlo de vuelta, y en los entregables de pipeline de VFX esa salida suele ser otra secuencia EXR en lugar de un único archivo de vídeo.

Nada de esto es una crítica al software de compositing. Es un tipo de carga de trabajo distinto, construido en torno a mover y combinar datos de imagen que ya existen en lugar de generarlos desde cero, y una render farm que trate un trabajo de compositing como un render 3D, aprovisionando mucha capacidad de GPU y escatimando en RAM y en rendimiento de almacenamiento, rendirá por debajo de lo esperado justo en las máquinas que deberían manejar bien el trabajo.

Qué lee y qué escribe realmente un render de compositing

La forma de las entradas y salidas de un trabajo de compositing es donde la diferencia con el renderizado 3D se nota de forma más concreta.

Entrada: EXR multicapa y multipase. Un compositing normalmente abre uno o más archivos OpenEXR por fotograma que ya llevan muchos canales: un render beauty, pases de diffuse y specular por separado, AOVs de iluminación, un pase Z-depth, vectores de movimiento y mattes de cryptomatte para el aislamiento por objeto, material e ID de asset, todo en un único archivo que se lee mediante un nodo Read y se separa con nodos Shuffle para trabajar pase a pase. Leer ese archivo no es un acceso a un archivo pequeño: es extraer todos los canales que lleva un fotograma, incluso si un compositing concreto solo usa unos pocos, razón por la cual el ancho de banda de lectura del almacenamiento es un cuello de botella real en los nodos de la render farm con mucha carga de compositing, algo que rara vez ocurre en un render 3D, que escribe la mayor parte de sus datos EXR en lugar de leerlos.

Cryptomatte como entrada, no como salida. Los datos de cryptomatte (mattes de ID generadas de forma procedural que permiten a un compositor aislar objetos, materiales o instancias de asset individuales a posteriori, sin volver a renderizar) los escribe el render 3D y los consume el compositing. Eso significa que un trabajo de compositing en la render farm hereda los canales de cryptomatte que produjo el render 3D previo, y un compositing que se apoya en el aislamiento por cryptomatte lee más canales por fotograma que uno que no lo hace. Nuestra guía de EXR-IO y cryptomatte explica cómo se estructuran esos datos y cómo trabajar con ellos de forma eficiente, y merece la pena leerla antes de enviar a cualquier render farm un compositing con mucha carga de cryptomatte.

Pocas salidas, con mucha profundidad de bits. Mientras que un render 3D suele escribir varios pases por fotograma, un render de compositing típicamente reduce esos pases a una, o a un pequeño puñado, de salidas compuestas finales, normalmente EXR de 16 bits half-float para entregables HDR lineales que siguen avanzando por el pipeline de VFX, y ocasionalmente de 32 bits para pases de datos que necesitan precisión completa. La escritura tiene menos canales que la lectura, pero sigue siendo un fotograma a resolución completa, y en un trabajo de deep compositing (que mantiene varias muestras de profundidad por píxel para resolver holdouts sin volver a renderizar la escena 3D) tanto la lectura como la escritura se vuelven considerablemente más pesadas.

La codificación de vídeo es un paso aparte, no el render en sí. Cuando el entregable final es H.264 o HEVC en lugar de una secuencia de imágenes, esa codificación normalmente ocurre como un pase independiente después del render de compositing fotograma a fotograma, no como parte de él, porque los códecs de vídeo no se pueden dividir limpiamente entre workers de la misma forma que una secuencia de imágenes independiente. Nuestra guía de codificación H.264 frente a H.265 analiza en más profundidad las ventajas y desventajas de ese último paso.

Seis pases de render (beauty, diffuse, specular, cryptomatte, depth, ambient occlusion) convergiendo en un único archivo EXR multicapa

Cómo se distribuyen los renders de compositing en una render farm en la nube

El modelo de distribución del trabajo de compositing se parece más al de Nuke que al de un motor de render 3D, y merece la pena precisar por qué.

Un motor de render 3D puede dividir un único fotograma espacialmente: buckets o tiles repartidos entre distintos hilos o máquinas, porque los píxeles de una región realmente no dependen de los píxeles de otra. Un compositing, por lo general, no se puede dividir así. El valor de un píxel en el fotograma N depende de las entradas de ese fotograma pasando por todo el árbol de nodos, lo que hace que la mayor parte del trabajo de compositing sea trivialmente paralelo por fotograma, no por región de imagen. Un gestor de render no subdivide un fotograma de compositing: subdivide el rango de fotogramas, repartiendo bloques de fotogramas entre distintos workers, cada uno ejecutando su propia instancia de la aplicación de compositing en modo headless (sin interfaz gráfica) para su parte.

Ese es el modelo que explica en detalle nuestra guía de Nuke en render farm en la nube, específicamente para Nuke, incluidos los flags exactos de línea de comandos y la mecánica de licencias. After Effects se comporta de forma similar en la mayoría de los compositings de producción (secuencias de títulos, motion graphics, reveals de archviz), pero con una salvedad que merece la pena señalar aquí: las composiciones de AE que dependen de un estado temporal a través de los fotogramas (motion blur con muestreo entre fotogramas, simulaciones de partículas que se acumulan, algunas operaciones de tracking) no son limpiamente paralelas por fotograma, y dividirlas de forma ingenua entre workers puede producir costuras visibles en los límites de cada bloque. Nuestra guía de configuración de renderizado en la nube para After Effects explica qué flujos de trabajo de AE se paralelizan sin problemas y cuáles necesitan, en cambio, un pase con un único worker.

La forma práctica de un trabajo de render de compositing en una render farm es la siguiente: el script o proyecto, junto con todo lo que referencia, se sube como un paquete autocontenido; el gestor de render divide el rango total de fotogramas en bloques; cada worker toma su bloque, resuelve las mismas rutas de metraje, la misma configuración de color, las mismas fuentes y las mismas dependencias de plugins que tenía la máquina del artista, y renderiza en modo headless; los fotogramas terminados llegan al almacenamiento compartido o en la nube a medida que se completa cada bloque, de modo que una secuencia larga puede empezar a devolver resultados utilizables mucho antes de que termine el último worker.

Problemas habituales en el compositing en la nube

La inmensa mayoría de los renders de compositing que fallan o salen mal en una render farm no son problemas de las matemáticas del compositing. Son problemas de dependencias y de entorno que una estación de trabajo local ocultaba en silencio.

Problema	Causa	Solución
Colores incorrectos, el render "se completa" pero se ve mal	En la render farm se resuelve una configuración OCIO/color distinta a la que usó el artista en local	Fijar el proyecto a una única configuración de color desplegada; confirmar que el entorno de render usa exactamente esa configuración, no una por defecto
Falta metraje o aparecen bloques de placeholder	Rutas locales absolutas (una letra de unidad de Windows, una unidad de red mapeada) que no significan nada en un worker remoto	Reunir todo el material referenciado en un paquete autocontenido y accesible por red antes de enviarlo
Fallo por falta de memoria a mitad de fotograma	Varios pases EXR a resolución completa y con múltiples canales, más una matte de cryptomatte, mantenidos en memoria a la vez	Aprovisionar los nodos de render de compositing con margen de RAM, no solo con número de núcleos de CPU; esta es una causa de fallo más común que el cómputo en bruto
Costuras visibles en los límites de cada bloque	Una operación dependiente del tiempo (motion blur, simulación de partículas, algunas operaciones de tracking) dividida entre workers como si fuera independiente por fotograma	Identificar los compositings dependientes del tiempo y enviarlos a render con un único worker en lugar de a distribución por rango de fotogramas
Falta un plugin, gizmo o fuente	Un gizmo personalizado, un plugin de terceros o una fuente instalados en local pero no en el worker de render	Integrar los nodos/gizmos personalizados en el script cuando sea posible; confirmar con la render farm las matrices de plugins y fuentes antes de enviar
Más lento de lo esperado en un nodo de nivel GPU	El compositing está dominado por fusiones, gradaciones y transformaciones, que son operaciones de CPU, no el subconjunto de nodos acelerados por GPU	Ajustar el trabajo a la capacidad de CPU adecuada; reservar los nodos GPU para compositings que realmente se apoyen en retimes, denoising o nodos de ML acelerados por GPU

Nada de esto es exclusivo de una aplicación en concreto. Es la forma general de lo que se rompe cuando un script de compositing sale de la máquina en la que se creó, y es la razón por la que "probar a pequeña escala antes de lanzar la secuencia completa" (renderizar primero un puñado de fotogramas y compararlos con el resultado en local) es un paso de seguro de bajo coste que merece la pena aplicar a cualquier render de compositing, en cualquier render farm.

Cuándo el renderizado en la nube realmente ayuda a un pipeline de compositing

No todos los compositings necesitan una render farm. Una secuencia corta que se renderiza en local en pocos minutos gana poco con la sobrecarga de subida y cola que implica mover el trabajo a la nube. El compositing en la nube demuestra su valor en un conjunto concreto de situaciones:

Picos con fecha límite ajustada. Un entregable que vence en horas, no en días, donde el número de fotogramas y la complejidad ocuparían una estación de trabajo más tiempo del que permite el plazo. Distribuir una secuencia de 1.000 fotogramas entre docenas de workers convierte un render de toda la noche en algo que puede estar listo en una hora o dos, porque el rendimiento escala de forma casi lineal con el número de workers disponibles.

Trabajo por lotes nocturno que de otro modo bloquearía a un artista. Incluso sin una fecha límite apretada, un compositing que ocuparía la máquina de un artista durante varias horas es tiempo en el que ese artista no puede iterar, revisar o trabajar en el siguiente plano. Enviarlo a una render farm libera la estación de trabajo de inmediato, en lugar de esperar a que termine un render en local.

Secuencias largas con mucha carga de datos por fotograma. El deep compositing, el EXR multicanal en 4K o superior, y los compositings con mucha carga de cryptomatte son exactamente las cargas de trabajo donde más se acumula el tiempo de render por fotograma, y donde distribuir el trabajo entre muchos workers con mucha CPU compensa más que en un compositing ligero y con pocos canales.

Pipelines mixtos de 3D y compositing que ya usan una render farm. Si el render 3D de un plano ya se ejecuta en una render farm en la nube, mantener la etapa de compositing en la misma infraestructura evita un viaje de ida y vuelta a una máquina local entre ambas etapas, y mantiene los pases (beauty, AOVs, cryptomatte) cerca de donde el compositing los va a leer.

Dónde el compositing en la nube demuestra menos su valor: un puñado de compositings cortos y sencillos, sin presión de plazos, donde el tiempo de render en local ya es muy inferior al tiempo que se tarda en preparar y subir un paquete de proyecto autocontenido. La sobrecarga de subida y de auditoría de dependencias es real, y en un trabajo pequeño puede superar el tiempo que se ahorra.

Coste: cuánto cuesta realmente un trabajo de render de compositing

Dado que el compositing es una carga de trabajo limitada por CPU y memoria en la gran mayoría de los nodos de un compositing típico, la tarifa de CPU es lo que suele determinar el coste, y la tarifa de GPU solo se aplica a los nodos concretos (retimes pesados, algo de denoising, herramientas de machine learning) que realmente usan aceleración por GPU.

En nuestra render farm, el cómputo de CPU se factura por GHz-hora, con una tarifa base de $0,004/GHz-hora (los niveles de prioridad van de $0,004 a $0,016/GHz-hora según la prioridad en cola), y el cómputo de GPU se factura por OctaneBench-hora (OBh) con una base de $0,003/OBh, con una tarjeta RTX 5090 (32 GB de VRAM) rondando los $5,2 por hora-tarjeta a plena utilización. Los créditos de render no caducan y no hay un mínimo de alquiler de máquina, así que un trabajo de compositing se factura por el cómputo que realmente consume, no por un bloque de tiempo reservado.

Para concretar esto con un ejemplo ilustrativo (no una cifra de benchmark, ya que el tiempo de render real por fotograma varía enormemente según la resolución, el número de canales y la complejidad de los nodos): un lote de compositing que consume 5.000 GHz-hora de cómputo de CPU agregado, un orden de magnitud plausible para una secuencia de varios miles de fotogramas en 4K distribuida entre docenas de workers durante la noche, cuesta aproximadamente $20 de cómputo a la tarifa base, antes de aplicar cualquier multiplicador por nivel de prioridad. Si una parte de ese mismo trabajo se apoya en nodos acelerados por GPU, esa parte se factura por separado a la tarifa de OBh en lugar de a la de GHz-hora. La mecánica que importa para presupuestar es sencilla, aunque las cifras exactas varíen de un trabajo a otro: el coste sigue el cómputo total consumido, no el tiempo de reloj del render, así que distribuir un trabajo entre más workers para que termine antes no cambia por sí solo lo que cuesta.

Render de compositing frente a render 3D: comparativa

Categoría	Render 3D	Render de compositing
Operación principal	Transporte de luz: muestreo, ray tracing, convergencia de ruido	Evaluación de un grafo de nodos: leer, combinar, transformar, escribir
Cuello de botella principal	Cómputo de GPU o CPU (según el motor)	Threading de CPU, capacidad de memoria, E/S de almacenamiento
Unidad de paralelismo	A menudo espacial (tiles/buckets) más el fotograma	Casi siempre por fotograma, no por región de imagen
Relevancia de la GPU	Central en el render para motores de GPU (Redshift, Octane)	Opcional para un subconjunto concreto de nodos; la mayoría de las operaciones son solo de CPU
Entrada típica	Geometría de la escena, materiales, texturas	Secuencias EXR multicapa y multipase (beauty, AOVs, cryptomatte)
Salida típica	Beauty pass más AOVs, a menudo varios archivos por fotograma	Un número reducido de salidas compuestas, normalmente una única secuencia EXR final
Patrón de fallo	Convergencia/ruido, memoria en escenas complejas, contención de licencias	Dependencias de rutas/assets, desajustes de configuración de color, falta de memoria en lecturas multicanal

Dónde encaja el compositing en un pipeline de renderizado en la nube más amplio

El compositing suele ser la última etapa de una cadena que empieza con un render 3D, y tratar ambas etapas con las mismas suposiciones sobre hardware y cuellos de botella es el error más habitual que vemos en los tickets de soporte de equipos que empiezan con el compositing en la nube. Si su pipeline es enteramente del lado 3D y todavía no tiene claro el modelo de servicio más amplio, nuestra guía sobre qué es una render farm en la nube y nuestra guía de renderizado en la nube para VFX y visualización de producto cubren ese terreno. Para la etapa de compositing en concreto, la guía de renderizado en la nube con Nuke y la guía de configuración de renderizado en la nube para After Effects cubren la mecánica específica de cada aplicación (licencias, flags de envío, matrices de plugins) que este artículo ha mantenido deliberadamente en un plano general. Del lado de After Effects, nuestra página de render farm en la nube para After Effects explica directamente el flujo de trabajo soportado y los precios.

Como referencia canónica sobre el formato de archivo que subyace a la mayoría de los pipelines de compositing VFX, el proyecto OpenEXR documenta el formato multicanal y multiparte que leen y escriben la mayoría de los renders de compositing, y la especificación de Cryptomatte documenta cómo se codifican los datos de matte de ID en esos archivos.

FAQ

Q: ¿El render de compositing es lo mismo que el render 3D en una render farm en la nube? A: No. Un render 3D hace transporte de luz, muestrea y traza rayos hasta que la imagen converge, y ese trabajo es genuinamente intensivo en cómputo por píxel. Un render de compositing evalúa un grafo de nodos sobre datos de imagen que ya existen (metraje, pases de render) y está dominado por el threading de CPU, la capacidad de memoria y la E/S de almacenamiento, más que por el muestreo. Ambas cargas de trabajo comparten el hardware de la render farm, pero tienen cuellos de botella y patrones de fallo distintos.

Q: ¿Por qué el compositing depende más de la E/S que el render 3D? A: Un compositing normalmente lee uno o más archivos EXR multicapa y multipase por fotograma, extrayendo todos los canales que lleva cada archivo (beauty, AOVs, mattes de cryptomatte, profundidad), y mantiene en memoria varios de esos fotogramas a resolución completa a la vez mientras evalúa el grafo de nodos. Ese volumen de lectura, sumado a la escritura del fotograma compuesto final, hace que el rendimiento de almacenamiento y la capacidad de RAM pesen más en el tiempo de render de compositing que la velocidad de cómputo en bruto, para la mayoría de los nodos de un compositing típico.

Q: ¿Necesita nodos GPU una render farm de compositing? A: Para la mayoría de los compositings, no. La mayoría de las operaciones de compositing (fusiones, gradaciones, keyers, transformaciones, la mayoría de los filtros) se ejecutan en la CPU. Un conjunto más pequeño y concreto de tipos de nodo (retimes pesados, algunas operaciones de denoising, herramientas de machine learning) están acelerados por GPU, y los compositings que se apoyan mucho en esos nodos se benefician de la capacidad de GPU. Para un compositing típico con mucha carga de fusiones y gradaciones, los núcleos de CPU y la RAM importan más que el nivel de GPU.

Q: ¿Qué es cryptomatte y por qué importa para el compositing en la nube? A: Cryptomatte son datos de matte de ID generados de forma procedural, escritos por el render 3D, que permiten a un compositor aislar objetos, materiales o instancias de asset individuales a posteriori sin volver a renderizar la escena 3D. En un trabajo de compositing en la nube, los datos de cryptomatte son una entrada que el compositing lee, no algo que el render de compositing genere, y los compositings con mucha carga de cryptomatte leen más canales por fotograma, lo que aumenta la carga de E/S y memoria en el nodo de render.

Q: ¿Pueden renderizar en la misma render farm en la nube tanto compositings de Nuke como de After Effects? A: Sí, en una render farm que soporte ambas aplicaciones, aunque el modelo de distribución varía ligeramente. Los compositings de Nuke son casi siempre paralelos por fotograma por diseño (cada fotograma es completamente autocontenido). Los compositings de After Effects son paralelos por fotograma en la mayoría de los casos de producción, pero las composiciones que dependen de un estado temporal a través de los fotogramas, como ciertas configuraciones de motion blur o de simulación de partículas, necesitan renderizarse con un único worker en lugar de con distribución por rango de fotogramas para evitar costuras. Nuestras guías de Nuke y de After Effects explican la mecánica específica de cada aplicación.

Q: ¿Cuándo tiene sentido enviar un trabajo de compositing a una render farm en la nube en lugar de renderizarlo en local? A: El compositing en la nube compensa más en picos con fecha límite ajustada, en trabajo por lotes nocturno que de otro modo ocuparía la estación de trabajo de un artista, y en secuencias grandes o con mucha carga de datos por fotograma (deep compositing, EXR multicanal en 4K o superior, compositings con mucha carga de cryptomatte). Compensa menos en un puñado de compositings cortos y sencillos, sin presión de plazos, donde el tiempo de render en local ya es más corto que el tiempo que se tarda en preparar un paquete de proyecto autocontenido para subirlo.

Q: ¿Cómo se factura el render de compositing en una render farm en la nube? A: En nuestra render farm, el cómputo de CPU (que determina el coste de la mayor parte del trabajo de compositing) se factura por GHz-hora, con una tarifa base de $0,004/GHz-hora, y niveles de prioridad de hasta $0,016/GHz-hora. Los nodos acelerados por GPU se facturan por separado, por OctaneBench-hora, con una base de $0,003/OBh. El coste sigue el cómputo total consumido, no el tiempo de reloj, así que distribuir un trabajo entre más workers para que termine antes no cambia por sí solo el coste total.

Q: ¿Qué formatos de archivo maneja normalmente una render farm de compositing? A: El OpenEXR multicapa y multiparte es el estándar de entrada y salida para el pipeline de VFX, y lleva beauty passes, AOVs, mattes de cryptomatte y datos de profundidad en 16 bits half-float (o en 32 bits para pases de datos que necesitan precisión completa). Cuando el entregable final es un archivo de vídeo (H.264, HEVC, ProRes) en lugar de una secuencia de imágenes, esa codificación normalmente se ejecuta como un pase aparte después del render de compositing fotograma a fotograma, ya que los códecs de vídeo por lo general no se pueden dividir entre workers de la misma forma que una secuencia de imágenes independiente. Nuestra guía de H.264 frente a H.265 explica ese último paso de codificación.