Configurar Blender para el renderizado en la nube

Blender en nuestra render farm ejecuta Cycles (CPU y GPU con Optix) y Eevee Next, los dos motores de renderizado de producción incluidos con Blender 4.x. En comparación con los DCC propietarios, Blender es inusual en un aspecto útil: un archivo .blend puede hacerse completamente autónomo desde dentro de la aplicación, de modo que el empaquetado para una render farm a menudo es una sola acción de menú en lugar de una búsqueda manual de recursos. Esta página recorre ese flujo de principio a fin: empaquetado, verificación previa al envío, notas por motor para Cycles CPU / Cycles GPU / Eevee Next, renderizado de animación multicámara, los tres canales de envío y la resolución de problemas específicos de Blender. Los fallos entre DCC están cubiertos en .

Para ejemplos de precios y la elección entre GPU y CPU en nuestra render farm, consulte . Para los benchmarks de Cycles GPU en la flota RTX 5090, consulte .

Versiones compatibles

Blender 4.0, 4.1, 4.2 LTS, 4.3 y 4.4 están preinstalados en cada nodo de trabajo. La render farm detecta automáticamente la versión guardada del archivo .blend; no hay selector de versión que gestionar: el nodo lee el encabezado del archivo y lanza el binario correspondiente.

Blender lanza una versión principal cada tres o cuatro meses más una versión LTS anualmente. Las nuevas versiones se ponen a disposición en aproximadamente dos semanas desde su disponibilidad pública. Recomendamos Blender 4.2 LTS para trabajo de producción, ya que recibe correcciones de errores hasta 2026 y es el objetivo estable para la mayoría de los estudios.

Los archivos guardados en Blender 3.x se abrirán en los nodos 4.x, pero dos casos requieren atención: los renderizados de Eevee Legacy pueden no coincidir con la salida de Eevee Next (consulte la sección de Eevee Next), y los archivos muy antiguos de 2.7x / 2.8x deben abrirse localmente, guardarse en 4.x y volver a probarse antes del envío. Si debe renderizar un proyecto antiguo, guarde primero una copia anclada a la versión; la render farm no puede degradar un archivo guardado en 4.x.

Cómo empaquetar su proyecto de Blender

Un proyecto de Blender es el archivo .blend más cualquier recurso externo: texturas, archivos de sonido, cachés de simulación, archivos .blend de biblioteca vinculada, perfiles de luz IES, archivos de configuración OCIO, HDRIs en EXR y cualquier archivo de shader .osl. La resolución de rutas de Blender es más permisiva que la de otros DCC, pero para el renderizado en la nube esa permisividad puede causar problemas: una ruta que se resuelve en su estación de trabajo a través de la lógica de respaldo de Blender puede no resolverse de la misma manera en un nodo, y el resultado son marcadores de posición rosas de textura faltante.

Se admiten tres patrones de empaquetado. Elija el que se ajuste al tamaño de su proyecto y a la frecuencia con que reutiliza recursos entre escenas.

Patrón 1 — Pack Resources (recomendado para la mayoría de los proyectos)

El "Pack Resources" integrado de Blender incorpora todos los datos externos en el propio .blend, produciendo un archivo único y autónomo.

File → External Data → Find Missing Files. Recorre el proyecto y reporta las referencias no resueltas; corrija cualquier elemento roto localmente primero.
File → External Data → Pack Resources. Blender incorpora todas las texturas, sonidos, perfiles IES e imágenes vinculadas en el .blend.
Guarde el proyecto. El .blend empaquetado es ahora autónomo: espere que crezca entre 10× y 100× según el recuento y la resolución de las texturas.
Cargue el único .blend. No se necesita archivo a menos que el tamaño del archivo sea suficientemente grande para que la compresión (.tar.gz o .7z) acelere la carga, generalmente por encima de unos pocos GB.

Patrón 2 — Rutas relativas + estructura de carpetas (para grandes bibliotecas de texturas)

Para proyectos en los que Pack Resources produciría un único archivo difícil de manejar, el patrón de rutas relativas mantiene el .blend pequeño y envía los recursos como carpetas junto a él.

File → External Data → Make All Paths Relative. Todas las rutas de recursos se vuelven relativas al directorio del .blend (prefijo de ruta //).
File → External Data → Report Missing Files. No debe mostrar ninguna. Corrija cualquier elemento reportado antes de continuar.
Coloque todos los recursos referenciados en subcarpetas relativas al .blend. Estructura estándar: project/scene.blend más project/textures/, project/cache/, project/hdr/, project/osl/, project/lib/. Evite espacios en los nombres de carpetas.
Archive toda la carpeta del proyecto como .tar.gz o .7z y cargue el archivo.

Patrón 3 — Bibliotecas vinculadas (avanzado; estudios con bibliotecas de recursos compartidos)

Blender admite la vinculación de bibliotecas, donde un archivo .blend referencia objetos, materiales o escenas de otro .blend. Esto es común en estudios con bibliotecas de recursos compartidos (props, personajes, materiales):

Haga primero las rutas relativas (paso 1 del Patrón 2).
Verifique que cada vínculo de biblioteca se resuelva localmente a través de File → External Data → Find Missing Files.
Incluya cada biblioteca .blend vinculada en el archivo. Una referencia como //../shared/props/chair.blend solo se resuelve si el archivo existe en esa ruta en el nodo. Pruebe localmente moviendo toda la carpeta del proyecto a una nueva ubicación y abriendo la escena maestra: si se abre limpiamente, las mismas rutas se resuelven en el nodo.
Considere hacer las bibliotecas locales para trabajos de larga duración. File → External Data → Make Library Override convierte las referencias en copias editables dentro del .blend, intercambiando tamaño de archivo por independencia.

Qué verificar antes del envío

Una lista de verificación previa al envío breve aplica antes de cualquier envío:

El motor de renderizado activo está configurado. Properties → Render Properties → Render Engine: Cycles, Eevee Next o Workbench. El nodo respeta lo que guarda.
El rango de fotogramas está configurado. Properties → Output Properties → Frame Start / Frame End. La render farm respeta exactamente este rango.
La ruta de salida usa tokens relativos. El predeterminado //tmp/####.png está bien; el prefijo // significa "relativo al archivo .blend". Evite las rutas absolutas como D:\renders\; no pueden resolverse en los nodos Linux.
El formato de salida coincide con su pipeline posterior. Secuencia PNG con alfa para composición, OpenEXR Multilayer para la salida de todos los pases. Para animación, se prefieren fuertemente las secuencias de imágenes sobre la salida de video directa (consulte las FAQ de multicámara).
La gestión del color está configurada. Properties → Render Properties → Color Management. El Filmic + sRGB predeterminado funciona para la mayoría de los proyectos. Para ACES o una configuración OCIO personalizada, incluya los archivos de configuración OCIO en la carpeta de su proyecto.
La cámara activa está configurada. La cámara activa de la escena (Properties → Scene Properties → Camera) determina qué cámara se renderiza. "Se renderizó la cámara equivocada" se encuentra entre los tickets de soporte de Blender más comunes y es uno de los más simples de prevenir.
Las cachés de simulación están horneadas. Las simulaciones de fluidos, humo, tela, cabello y cuerpos blandos deben hornearse localmente primero; la render farm renderiza contra la caché horneada y no ejecuta simulaciones en vivo. Incluya la carpeta de caché en la carga.
Las sondas de luz están horneadas. Las sondas de Eevee Next (Irradiance Volume, Reflection Plane, Reflection Cube) deben hornearse localmente y los datos horneados guardarse con el .blend (Render Properties → Light Probes → Bake Indirect Lighting). Las sondas sin hornear producen iluminación indirecta plana o faltante.

Notas específicas por motor

Cycles (CPU)

Cycles CPU se ejecuta en nuestro nivel de nodos Intel Xeon E5-2699 V4 dual (hasta 256 GB de RAM por nodo). Es la opción para escenas que superan la VRAM de la GPU, proyectos con bibliotecas de texturas muy grandes, o escenas que usan características aún no compatibles con el backend de GPU.

Licencia: Blender es gratuito y de código abierto; nada que autorizar, ninguna licencia que consumir.
Muestreo: Render Properties → Sampling → Render Samples. Adaptive Sampling con Noise Threshold 0.01 es un buen valor predeterminado para animación; umbrales más bajos (0.005, 0.002) para mayor calidad a costo de tiempo de renderizado. Time Limit (por fotograma) es un protector útil para el trabajo de animación.
Denoise: Cycles admite OpenImageDenoise (OIDN) y Optix (solo GPU). OIDN se ejecuta en CPU y produce buenos resultados para imágenes estáticas y animación; configúrelo en Render Properties → Sampling → Denoise. Para animación, habilite el denoise temporal (OIDN 2.x en Blender 4.2+) para reducir el parpadeo entre fotogramas.
Árbol de luz: Blender 3.4+ incluye muestreo de árbol de luz para escenas con muchas fuentes de luz. Habilítelo en Render Properties → Sampling → Light Tree para interiores de archviz o iluminación de escenario con cientos de fuentes de luz.

Cycles (GPU / Optix)

Cycles GPU se ejecuta en nuestro nivel de nodos NVIDIA RTX 5090 (32 GB de VRAM por tarjeta). Generalmente es entre 5 y 15 veces más rápido por fotograma que Cycles CPU para archviz y animación, y más para tomas de VFX path-traced con muchos volumétricos y SSS.

Dispositivo: Properties → Render Properties → Device → GPU Compute. El backend Optix (núcleos RT en GPU NVIDIA) está habilitado por defecto en nuestros nodos.
VRAM: 32 GB por nodo es suficiente para la mayoría de los proyectos de archviz, diseño en movimiento y animación con varias texturas de 4K. Para proyectos que se acercan al límite, "Persistent Data" en Render Properties → Performance reduce el tiempo de carga por fotograma a costo de un pico de VRAM ligeramente mayor. Para proyectos que superan los 32 GB, cambie a Cycles CPU en el nivel Xeon o divida la escena.
Denoiser Optix: Más rápido que OIDN para animación y la opción estándar en GPU. Configure en Render Properties → Sampling → Denoise → Use OptiX. Para imágenes estáticas, OIDN a menudo produce una salida ligeramente más limpia; para animación, el modo temporal de Optix suele ser el mejor equilibrio.
Paridad de características: Cabello, volúmenes, SSS, OSL (4.0+, con requisitos de hardware), Adaptive Subdivision: todos compatibles con Cycles GPU en 4.x. La brecha de características CPU/GPU está esencialmente cerrada.

Eevee Next

Eevee Next se ejecuta en nuestro nivel de nodos GPU. Es la opción para diseño en movimiento, renders estilizados, iteración rápida y previz donde el costo por fotograma importa más que la fidelidad absoluta.

Muestreo y reflexiones: Render Properties → Sampling controla el recuento de muestras por píxel. Para los finales, 64–128 muestras normalmente produce una salida limpia. Las sondas de luz, las reflexiones en espacio de pantalla y las refracciones en espacio de pantalla deben hornearse o configurarse por toma.
Eevee Next vs Eevee Legacy: Blender 4.2+ incluye Eevee Next como la nueva arquitectura (nombre interno BLENDER_EEVEE_NEXT vs el legacy BLENDER_EEVEE). Los proyectos 3.x más antiguos que usan Eevee Legacy pueden necesitar ajustes al migrar; pruebe un solo fotograma localmente antes de enviar una animación.
Volumétricos: El pipeline volumétrico de Eevee Next difiere significativamente de la versión legacy. Los volúmenes que se renderizaban correctamente en Eevee Legacy pueden mostrar diferencias de densidad o dispersión. Verifique localmente antes de enviar.
Horneado de sondas de luz: Crítico y la fuente del ticket de soporte de Eevee más común. Render Properties → Light Probes → Bake Indirect Lighting. Hornee localmente, guarde, y los datos del horneado viajan con el archivo. Las sondas sin hornear producen iluminación indirecta plana o faltante.

Workbench

Workbench es el motor de renderizado de viewport de Blender, útil para fotogramas de vista previa técnica (pases de ID mate, giros de arcilla, vista previa de AO). Se ejecuta en nodos de CPU o GPU; envíe de la misma manera que Cycles o Eevee, con Render Engine configurado como Workbench antes de guardar.

Comparación rápida: Cycles GPU vs Eevee Next

| Aspecto | Cycles GPU | Eevee Next | |---|---|---| | Velocidad de renderizado (escena típica) | Más lento por fotograma, físicamente preciso | Más rápido por fotograma, derivado en tiempo real | | Fotorrealismo | Mayor | Menor (pero mejora con cada versión) | | Parpadeo en animación | Bajo (con modo temporal del denoiser Optix) | Puede ser mayor; necesita horneado de sondas | | Restricción de VRAM | Límite rígido de 32 GB; fallback a CPU | 32 GB pero uso típicamente menor | | Calidad de volumétricos | Path-traced, preciso | Aproximado; verifique localmente antes de enviar | | Ideal para | Archviz, VFX, animación fotorrealista | Diseño en movimiento, estilizado, iteración rápida |

Renderizado multicámara

Para proyectos que necesitan renderizar la misma escena desde múltiples ángulos de cámara en un solo envío, Blender admite varios patrones. Elija según cómo se relacionan los ángulos entre sí.

Patrón A — Múltiples escenas con diferentes cámaras activas

Blender permite múltiples escenas por .blend, cada una con su propia cámara activa y configuración de renderizado:

Cree una nueva escena por ángulo de cámara (Scene → New Scene → Link Objects comparte datos para que las ediciones se propaguen).
Configure la cámara activa de cada escena.
Al enviar, la render farm renderiza la escena marcada como Active al momento del guardado. Para renderizar múltiples escenas, envíe cada una como un trabajo separado.

El Patrón A es la opción correcta cuando los ángulos necesitan diferente muestreo, formatos de salida o resoluciones.

Patrón B — View Layer por cámara (Blender 2.8+)

Para muchos ángulos de cámara que comparten la configuración de renderizado, use View Layers cada uno con una cámara activa diferente:

En Properties → View Layer, cree un View Layer por ángulo de cámara.
Vincule la cámara de cada View Layer a través de una propiedad Camera en la capa (o maneje la cámara activa en el Compositor).
Configure las rutas de salida por View Layer usando el token {layer} en el nombre de archivo de salida.
Envíe; el nodo renderiza todos los View Layers habilitados en un solo pase.

Para giros de archviz típicos (8–16 ángulos de cámara), el Patrón B es más eficiente porque la escena se carga una vez y todas las vistas se renderizan desde el mismo estado cargado. Un único trabajo multicámara que produce N secuencias de salida cuesta menos que N trabajos de una sola cámara.

Patrón C — Salida múltiple del Compositor (avanzado)

Para el postprocesado complejo por cámara, el Compositor puede enrutar el renderizado de cada cámara a un nodo File Output diferente. Mismo patrón que las exportaciones AOV multicapa. Use el Patrón B a menos que tenga una razón real de postprocesado para usar el Compositor.

Flujo de envío

Tres canales de envío funcionan para proyectos de Blender. Elija el que se ajuste a su flujo de trabajo.

Carga web + envío a través del dashboard. Cargue el .blend empaquetado (o la carpeta del proyecto archivada) en su cuenta y luego envíelo a través del dashboard. El dashboard lee el encabezado del .blend para detectar la versión de Blender, el motor de renderizado, el rango de fotogramas y la cámara activa, y rellena previamente el formulario de envío. Confirme o anule, envíe y monitoree.
Client App. La Client App (Windows / macOS) envuelve la carga + el envío + la descarga automática. Después de la instalación, arrastre el .blend o el archivo sobre la aplicación, confirme el formulario de envío y la aplicación gestiona la carga, el monitoreo del progreso y la descarga de fotogramas a medida que se completan.
Plugin de envío (complemento de Blender). Hay disponible un complemento de Blender para el envío dentro de la aplicación; instálelo desde el dashboard de su cuenta. El plugin lee la configuración de renderizado de la escena actual, solicita anulaciones (rango de fotogramas, ruta de salida, resolución) y envía sin salir de Blender.

Para el flujo de carga-envío-descarga entre DCC, consulte la . Para los pasos de instalación del plugin, consulte .

Resolución de problemas específicos de Blender

Para la resolución de problemas generales que aplica a todos los DCC (recurso faltante, discrepancia de rango de fotogramas, errores de ruta de salida), consulte . Los casos a continuación son específicos de Blender.

Algunos objetos de la escena no se renderizan. Causa más común: la "Render Visibility" del objeto (icono de cámara en el outliner) está desactivada. Compruebe también que el objeto no esté en un View Layer oculto, y verifique los indicadores de Object Properties → Visibility → Ray Visibility (camera, diffuse, glossy, transmission, volume, shadow).
Texturas faltantes a pesar de Pack Resources. Verifique que Pack Resources se ejecutó después de los últimos cambios de textura. Si recargó las texturas después del empaquetado, pueden haber vuelto a ser referencias externas. Vuelva a empaquetar y a guardar.
El renderizado devuelve negro o color incorrecto. Normalmente es una discrepancia de View Transform. Confirme que Properties → Render Properties → Color Management usa View Transform: Filmic (el predeterminado) tanto en su estación de trabajo como en el archivo guardado. Los Look Transforms y los valores de Exposure están incorporados en el .blend y se aplican en el nodo.
Las sondas de luz de Eevee Next no se hornean en el nodo. El nodo no hornea; las sondas deben hornearse localmente y guardarse con el .blend. Render Properties → Light Probes → Bake Indirect Lighting, guarde, cargue.
El trabajo de Cycles GPU se ejecuta en CPU. Verifique que Properties → Render Properties → Device esté configurado como GPU Compute. Si el archivo fue creado en una estación de trabajo sin GPU NVIDIA, el valor guardado de Device puede ser CPU por defecto.
El shader OSL personalizado falla al renderizar. Cycles admite OSL, pero los archivos .osl deben estar incluidos en el archivo y referenciados por ruta relativa. Colóquelos en la misma carpeta que el .blend. OSL en GPU tiene requisitos de hardware que pueden no coincidir con todos los shaders; si un shader funciona en CPU pero no en GPU, renderice esa escena en el nivel CPU.
Referencia de biblioteca vinculada rota. Una biblioteca vinculada solo se resuelve si el .blend vinculado está presente en la ruta esperada en el nodo. Use el empaquetado del Patrón 2 e incluya cada biblioteca vinculada en el archivo. Ejecute File → External Data → Find Missing Files localmente antes de cargar.
Complemento faltante en el nodo. Los complementos comunes (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids) pueden no estar todos preinstalados. Para complementos procedurales, hornee la geometría en mallas estáticas antes del envío (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action; Geometry Nodes: Apply modifier). Para otros complementos, contacte a soporte sobre añadirlos a la imagen del nodo.
La animación parpadea (Cycles). Normalmente es variación de ruido entre fotogramas. Aumente las muestras, baje el Adaptive Sampling Noise Threshold, habilite el denoise temporal (OIDN 2.x o Optix). Confirme que el modo de semilla aleatoria (Render Properties → Sampling → Advanced → Seed) coincide con la intención de su proyecto: Animated para variación natural, fijo para salida bit estable.
La animación parpadea (Eevee Next). Casi siempre son sondas de luz sin hornear o desactualizadas. Vuelva a hornear Indirect Lighting, guarde, vuelva a cargar. Las reflexiones en espacio de pantalla que dependen del estado del viewport también pueden parpadear; favorezca Reflection Probes para reflexiones limpias.

Referencias cruzadas

— flujo de carga, envío y descarga que aplica a todos los DCC
— cómo se calculan los costos de los trabajos de Blender, modelo de precios por GHz-hora
— guía de SFTP, formatos de archivo, transferencia de archivos grandes
— resolución de problemas entre DCC (recurso faltante, rango de fotogramas, ruta de salida, desviación de gestión del color)
— instalación del complemento de Blender para el envío dentro de la aplicación
— entorno de escritorio para carga + envío + descarga
— flujo de envío desde el dashboard
— artículo de benchmark que incluye números de Cycles GPU
— artículo de comparación con una sección de contexto de Blender

FAQ

Q: ¿Qué versiones de Blender admite la render farm? A: Blender 4.0, 4.1, 4.2 LTS, 4.3 y 4.4 están preinstalados en cada nodo de trabajo. Seguimos el ciclo de lanzamiento de Blender y ponemos a disposición las nuevas versiones en aproximadamente dos semanas desde su disponibilidad pública. Blender 4.2 LTS es la opción recomendada para trabajo de producción porque recibe correcciones de errores hasta 2026. La render farm detecta automáticamente la versión guardada del archivo .blend; no selecciona una versión al momento del envío.

Q: ¿Debo renderizar con Cycles o Eevee Next? A: Cycles para archviz fotorrealista, VFX y animación donde importa el transporte de luz físicamente preciso. Eevee Next para diseño en movimiento, trabajo estilizado, iteración rápida y previz donde el costo por fotograma importa más que la fidelidad absoluta. Cycles GPU en nuestra flota RTX 5090 es típicamente entre 5 y 15 veces más rápido por fotograma que Cycles CPU para la misma escena, por lo que GPU es la recomendación predeterminada de Cycles a menos que su escena supere los 32 GB de VRAM o use características que requieran el backend de CPU.

Q: Mi escena usa recursos de BlenderKit / Sverchok / Animation Nodes / Geometry Nodes — ¿se renderizará? A: Los recursos de BlenderKit que ya ha descargado y guardado en el .blend se renderizan bien; una vez colocados se convierten en datos de malla estándar. Sverchok y Animation Nodes son procedurales; si la geometría procedural no se ha horneado en una malla estática, el nodo puede producir una salida inesperada. Hornee la geometría procedural en mallas (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action; Geometry Nodes: Apply modifier en el árbol de nodos resultante) antes del envío. Los Geometry Nodes que se resuelven en el momento del renderizado sin hornear generalmente funcionan, pero pruebe un solo fotograma localmente primero.

Q: ¿Necesito empaquetar las texturas en el .blend, o puedo cargarlas como archivos separados? A: Cualquiera de los dos patrones funciona. Pack Resources es lo más sencillo porque el resultado es un único archivo autónomo. Las rutas relativas + estructura de carpetas es preferible para bibliotecas de texturas muy grandes y proyectos que comparten una biblioteca de texturas entre escenas. Ejecute Find Missing Files antes de cualquiera de los dos enfoques para confirmar que nada está roto localmente.

Q: Mi renderizado termina pero los colores parecen diferentes a los de mi viewport de estación de trabajo. A: La mayoría de las veces es una discrepancia de View Transform. Confirme que Properties → Render Properties → Color Management usa View Transform: Filmic (el predeterminado) tanto en su estación de trabajo como en el archivo guardado. Los Look Transforms y los valores de Exposure también están incorporados en el .blend y se aplican en el nodo.

Q: Estoy renderizando una animación. ¿Debo generar salida a archivo de video o a secuencia de imágenes? A: Secuencia de imágenes, casi siempre. PNG con alfa (para composición) u OpenEXR Multilayer (para todos los pases) es el estándar. La salida de video directa (FFmpeg) no se paraleliza: un nodo renderiza todos los fotogramas de forma secuencial y codifica un único archivo. Las secuencias de imágenes permiten que la render farm distribuya los fotogramas entre múltiples nodos en paralelo, lo que es más rápido para cualquier animación de más de aproximadamente 100 fotogramas.

Q: ¿Cómo se compara el costo del renderizado en GPU frente al de CPU en la render farm? A: El GPU es típicamente más rápido por fotograma (5–15× para Cycles) pero la tarifa por nodo es mayor. El costo total es aproximadamente comparable para la mayoría de las escenas: el GPU termina en menos tiempo de reloj de pared pero factura más por minuto. La ofrece una comparación por fotograma y por trabajo para su escena específica.

Q: ¿Puedo renderizar simulaciones de Blender (fluidos, humo, cabello, tela) en la render farm? A: Hornee primero la caché de simulación localmente y luego incluya la carpeta de caché en la carga del proyecto. La render farm renderiza los fotogramas contra la caché horneada; no ejecuta simulaciones en vivo. Hornee en disco (Cache Type → All Frames + Save Cache to Disk), confirme que la carpeta de caché está en la carpeta del proyecto, empaquete y cargue.