Configurar Blender para el renderizado en la nube

Blender en nuestra render farm ejecuta Cycles (CPU y GPU/Optix), que es el motor de renderizado de producción para trabajos de Blender en nuestra render farm. Eevee no está disponible: requiere un contexto de visualización activo y no puede ejecutarse en los nodos de renderizado headless (consulte la nota sobre Eevee en las notas específicas por motor). Esta página cubre el empaquetado de proyectos —más sencillo en Blender que en la mayoría de los DCCs gracias a cómo Blender gestiona las rutas de activos—, las notas específicas por motor, el render de animación multicámara y la resolución de problemas específicos de Blender.

Para una visión general del posicionamiento de Blender en nuestra render farm —ejemplos de precios, elección de GPU frente a CPU, add-ons compatibles—, consulte el artículo (el artículo sobre V-Ray incluye contexto de Blender). Para benchmarks específicos de Cycles GPU en RTX 5090, consulte .

Versiones compatibles

Blender 4.0, 4.1, 4.2 (LTS), 4.3 y 4.4 están preinstalados en cada worker. Damos soporte a las versiones LTS de Blender como la opción recomendada para trabajos de producción, ya que Blender 4.2 LTS recibe correcciones de errores hasta 2026 y es el objetivo estable para la mayoría de los estudios. La render farm detecta automáticamente la versión guardada en su archivo .blend.

Una nota sobre el ritmo de publicaciones de Blender: Blender lanza una versión principal cada tres o cuatro meses, más una versión LTS anualmente. Incorporamos las nuevas versiones en un plazo de dos semanas desde su disponibilidad pública; el ciclo de lanzamiento de Blender es más rápido que el de los DCCs propietarios, por lo que la render farm se mantiene actualizada de cerca.

Empaquetado del proyecto Blender

Un proyecto de Blender consiste en el archivo .blend más todos los activos externos: texturas, archivos de sonido, cachés de simulación, archivos .blend de bibliotecas enlazadas y HDRIs en EXR para la iluminación de entorno. La resolución de rutas en Blender es más flexible que en otros DCCs (utiliza tanto rutas absolutas como relativas, y recurre a varias ubicaciones de búsqueda), pero para el renderizado en la nube conviene empaquetar todo en una carpeta de proyecto coherente.

El método de empaquetado más sencillo es la función integrada de Blender "Pack Into .blend":

Abra su proyecto. File → External Data → Find Missing Files (para verificar que nada esté ya roto en local).
Empaquete los activos en el archivo .blend. File → External Data → Pack All Into .blend. Blender incrusta todas las texturas, sonidos e imágenes enlazadas directamente en el archivo .blend.
Guarde el proyecto. El archivo .blend es ahora autocontenido; generalmente ocupa entre 10 y 100 veces más que el original, según la cantidad de texturas.
Suba el archivo .blend único (no necesita archivo comprimido si su .blend pesa menos de unos pocos GB; para archivos más grandes, comprima en .tar.gz o .7z para una subida más rápida).

Un segundo método de empaquetado que produce una subida de menor tamaño es "Make Paths Relative" + estructuración manual de carpetas:

File → External Data → Make All Paths Relative. Todas las rutas de activos se convierten en relativas al directorio del archivo .blend.
Verifique que todos los activos se resuelven correctamente con File → External Data → Report Missing Files. El informe no debe mostrar archivos faltantes.
Coloque todos los activos referenciados en subcarpetas relativas al .blend. Estructura estándar: project/scene.blend más project/textures/, project/cache/, project/hdr/, etc.
Archive toda la carpeta como .tar.gz o .7z y súbala.

El método de rutas relativas es preferible para bibliotecas de texturas muy grandes (donde Pack Into .blend generaría un único archivo de tamaño inmanejable) y para proyectos que reutilizan la misma biblioteca de texturas en varias escenas.

Qué verificar antes de enviar

Una lista de verificación previa al envío:

El motor de renderizado activo debe estar en Cycles. Properties → Render Properties → Render Engine determina si el worker utiliza Cycles o Workbench. Configúrelo en Cycles para el renderizado de producción; Eevee no es compatible con la render farm (consulte las notas específicas por motor). Asegúrese de que coincide con la intención de su proyecto.
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 valor predeterminado //tmp/####.png es correcto; el prefijo // significa "relativo al archivo .blend". Evite rutas absolutas como D:\renders\.
El formato de salida coincide con su flujo de trabajo posterior. Secuencia PNG con alfa para composición, OpenEXR Multilayer para salida completa de pasadas, vídeo FFmpeg para entrega directa. Para el renderizado de animaciones, se recomienda encarecidamente usar secuencias de imagen en lugar de salida directa a vídeo.
La gestión del color está configurada. Properties → Render Properties → Color Management. El ajuste predeterminado Filmic + sRGB funciona para la mayoría de los proyectos. Si su proyecto usa ACES o una configuración OCIO personalizada, incluya los archivos de configuración OCIO en la carpeta del proyecto y verifique que la ruta se resuelve correctamente en el worker.
La cámara activa está definida. La cámara activa de la escena (Properties → Scene Properties → Camera) determina qué cámara se renderiza. Asegúrese de que coincide con lo que espera.

Notas específicas por motor

Cycles (CPU)

Cycles CPU se ejecuta en nuestro nivel de workers Dual Intel Xeon E5-2699 V4 (hasta 256 GB de RAM por nodo). Es la opción indicada para escenas que superan la VRAM de la GPU, escenas con bibliotecas de texturas muy grandes, o proyectos que necesitan la salida exacta bit a bit que produce Cycles CPU.

Notas de configuración:

Licencia: Blender es gratuito y de código abierto; no hay preocupaciones de licencias en la render farm.
Muestreo: Cycles Render Properties → Sampling → Render Samples. El muestreo adaptativo con un Noise Threshold de 0.01 produce resultados limpios para animaciones; use umbrales más bajos (0.005, 0.002) para mayor calidad a costa de mayor tiempo de renderizado.
Denoising: Cycles admite OpenImageDenoise (OIDN) y Optix (solo GPU). OIDN se ejecuta en CPU y ofrece buenos resultados para imágenes estáticas y animaciones; configúrelo en Render Properties → Sampling → Denoise.
Árbol de luces: Blender 3.4+ incluye muestreo de árbol de luces para escenas con muchas luces. Actívelo en Render Properties → Sampling para escenas con cientos de fuentes de luz.

Cycles (GPU / Optix)

Cycles GPU se ejecuta en nuestro nivel de workers NVIDIA RTX 5090 (32 GB de VRAM por tarjeta). Es significativamente más rápido que Cycles CPU para la mayoría de escenas (generalmente una aceleración de 5 a 15 veces), en especial para proyectos con trazado de rayos intensivo.

Notas de configuración:

Dispositivo: Properties → Render Properties → Device → GPU Compute. El backend Optix (que utiliza los RT cores de las GPU NVIDIA) está activado de forma predeterminada en nuestros workers.
Límites de VRAM: 32 GB de VRAM por worker son suficientes para la mayoría de proyectos de visualización arquitectónica y animación. Para proyectos que se acerquen al límite de VRAM, la opción "Persistent Data" en Render Properties → Performance reduce los tiempos de carga por fotograma, pero aumenta el uso máximo de VRAM. Para proyectos que superen los 32 GB, cambie a Cycles CPU o divida la escena en partes renderizables.
Denoiser Optix: Más rápido que OIDN para animaciones. Configúrelo en Render Properties → Sampling → Denoise → Use OptiX. Requiere GPU NVIDIA (que nuestro nivel de workers proporciona).

Eevee (no compatible)

Eevee no está disponible en la render farm. Eevee requiere un contexto de visualización activo (una sesión interactiva de OpenGL/GPU) y no puede ejecutarse en el modo de servidor headless en el que operan nuestros nodos de renderizado, por lo que el renderizado con Eevee no es compatible. Un proyecto cuyo motor activo esté configurado en Eevee no se renderizará; cambie el motor de renderizado a Cycles antes de enviar.

Si necesita el aspecto rápido derivado en tiempo real de Eevee, renderícelo localmente. Para el renderizado en la nube, Cycles GPU en nuestra flota de RTX 5090 (con el denoiser Optix) ofrece iteraciones rápidas con una salida físicamente precisa; es el motor de producción compatible para Blender en la render farm.

Cycles CPU frente a Cycles GPU: cuál elegir

Cycles GPU en el nivel RTX 5090 es la opción predeterminada: generalmente es de 5 a 15 veces más rápido por fotograma que Cycles CPU y gestiona la mayoría de escenas de visualización arquitectónica, animación y trazado de rayos intensivo dentro de sus 32 GB de VRAM. Elija Cycles CPU cuando una escena supere los 32 GB de VRAM, dependa de bibliotecas de texturas muy grandes, o necesite la salida exacta bit a bit que produce la vía CPU (hasta 256 GB de RAM por nodo). Ambos producen el mismo resultado físicamente preciso de Cycles; GPU termina más rápido por fotograma, y CPU tiene un mayor límite de memoria.

Render de ángulo multicámara

Para proyectos que necesiten renderizar la misma escena desde múltiples ángulos de cámara en un único envío, Blender admite dos métodos:

Método 1: múltiples escenas con distintas cámaras activas

Blender permite múltiples escenas por archivo .blend. Cada escena puede tener su propia cámara activa y configuración de renderizado:

En su proyecto, cree una nueva escena por ángulo de cámara (Scene → New Scene → Link Objects).
Configure la cámara activa de cada escena con la cámara correspondiente.
Al enviar, la render farm renderiza la escena establecida como "Active" en el momento del envío. Para renderizar varias escenas, envíe cada una como un trabajo separado.

Método 2: View Layer por cámara (Blender 2.8+)

Un método más eficiente para múltiples ángulos de cámara es usar View Layers con distintas cámaras activas:

En Properties → View Layer, cree un View Layer por ángulo de cámara.
En Properties → Output Properties → Output → Use Multi-View, configure las vistas estéreo o múltiples si aplica.
Configure las rutas de salida por View Layer usando el token {layer} en el nombre de archivo de salida.
Envíe el trabajo; el worker renderiza todos los View Layers habilitados en un único pase.

Para turntables típicos de visualización arquitectónica (de 8 a 16 ángulos de cámara), el método 2 es significativamente más eficiente porque la escena se carga una sola vez por fotograma y renderiza todas las vistas desde la misma escena cargada.

Flujo de envío

Existen tres canales de envío para proyectos de Blender:

Subida web + envío mediante el panel de control. Suba el archivo .blend empaquetado (o la carpeta del proyecto archivada) y luego envíe a través del sitio web. Es la ruta de envío más habitual para los usuarios de Blender.
Aplicación cliente. Subida + envío + descarga automática en una sola herramienta.
Plugin de envío. Hay disponible un add-on de Blender para enviar con un solo clic desde el interior de Blender; instálelo desde su panel de cuenta.

Para el flujo de subida-envío-descarga entre DCCs, consulte la .

Resolución de problemas específicos de Blender

Para la resolución de problemas generales aplicable a todos los DCCs, consulte . Casos específicos de Blender:

Algunos objetos de la escena no se renderizan. La causa más frecuente es que el interruptor "Render Visibility" del objeto esté desactivado. En el outliner, pase el cursor sobre la fila del objeto y compruebe que el icono de cámara (Disable in Renders) esté activado. Compruebe también que el objeto no esté en un View Layer oculto.
Faltan texturas a pesar de haber usado Pack Into .blend. Verifique que Pack All Into .blend se ejecutó después de los últimos cambios en las texturas. Si recargó texturas después de empaquetar, es posible que hayan vuelto a referencias externas. Vuelva a empaquetar y guarde.
El render devuelve negro o un color incorrecto. Compruebe la configuración de Color Management (Properties → Render Properties → Color Management). La causa más frecuente es una discrepancia en el View Transform; asegúrese de que tanto su estación de trabajo como el worker usen el mismo View Transform (Filmic es la opción predeterminada y la más segura).
El trabajo de Cycles GPU se ejecuta en CPU. Verifique que Properties → Render Properties → Device esté configurado en GPU Compute y no en CPU. Compruebe también que el backend Optix esté seleccionado si su escena requiere aceleración de trazado de rayos por hardware.
El shader OSL personalizado falla al renderizar. Cycles admite OSL (Open Shading Language), pero los shaders OSL personalizados deben incluirse en el archivo del proyecto. Los archivos de shader OSL (.osl) deben estar en una ubicación que el worker pueda encontrar; lo más sencillo es colocarlos en la misma carpeta que el archivo .blend y referenciarlos mediante una ruta relativa.
El add-on no está disponible en el worker. Es posible que algunos add-ons comunes (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids, etc.) no estén preinstalados. Para Animation Nodes y add-ons procedurales similares, la solución consiste en convertir la geometría procedimental en mallas antes del envío. Para otros add-ons, contacte con soporte para consultar la posibilidad de añadirlos a la imagen del worker.

Referencias cruzadas

— flujo de subida, envío y descarga
— cómo se calculan los costos de los trabajos de Blender
— guía de SFTP y formatos de archivo
— resolución de problemas para todos los DCCs
— instalación del add-on de Blender
— artículo de benchmarks

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 worker. Seguimos el ciclo de lanzamiento de Blender e incorporamos nuevas versiones en un plazo de dos semanas desde su disponibilidad pública. Blender 4.2 LTS es la opción recomendada para trabajos de producción porque recibe correcciones de errores hasta 2026. Q: ¿Puedo renderizar escenas de Eevee en la render farm? A: No. Eevee requiere un contexto de visualización activo y no puede ejecutarse en los nodos de renderizado headless que utiliza la render farm, por lo que el renderizado con Eevee no es compatible. Configure su motor de renderizado en Cycles antes de enviar. Para iteraciones rápidas, Cycles GPU en nuestra flota de RTX 5090 (con el denoiser Optix) es generalmente de 5 a 15 veces más rápido que Cycles CPU para la misma escena, por lo que GPU es la recomendación predeterminada a menos que su escena supere los 32 GB de VRAM. Q: Mi escena usa BlenderKit / Sverchok / Animation Nodes, ¿se renderizará correctamente? A: Los activos de BlenderKit que ya haya descargado y guardado en el archivo .blend se renderizarán correctamente (se convierten en datos de malla estándar una vez colocados). Sverchok y Animation Nodes son procedurales; si la geometría procedimental no se ha convertido en una malla estática, el worker puede producir resultados inesperados. Convierta la geometría procedimental en mallas (Sverchok: Set/Bake to Mesh; Animation Nodes: bake to action) antes del envío. Q: ¿Necesito empaquetar las texturas en el .blend, o puedo subirlas como archivos separados? A: Cualquiera de las dos opciones funciona. Pack Into .blend es la más sencilla porque el resultado es un único archivo autocontenido. El método de rutas relativas + estructura de carpetas es preferible para bibliotecas de texturas muy grandes, donde Pack Into .blend generaría un único archivo de tamaño inmanejable. Asegúrese de ejecutar "Find Missing Files" antes de aplicar cualquiera de los dos métodos para confirmar que nada está roto localmente. Q: El render finaliza pero los colores se ven distintos a los de mi viewport de trabajo. A: Lo más habitual es que se deba a una discrepancia en la gestión del color o en el View Transform. Compruebe Properties → Render Properties → Color Management en su estación de trabajo y verifique que la configuración guardada incluya View Transform: Filmic (el valor predeterminado). Los Look Transforms (alto contraste, bajo contraste, etc.) y los valores de Exposure también se almacenan en el archivo .blend y se aplican en el worker. Q: Estoy renderizando una animación. ¿Debo exportar a archivo de vídeo o a secuencia de imágenes? A: Secuencia de imágenes, casi siempre. PNG con alfa (para composición) u OpenEXR Multilayer (para pasadas completas) es el estándar. La salida directa a vídeo (FFmpeg) no se paraleliza bien en la render farm; el worker que recibe el trabajo renderiza todos los fotogramas de forma secuencial y codifica un único archivo de vídeo. Las secuencias de imágenes permiten a la render farm distribuir los fotogramas entre múltiples workers en paralelo, lo que es significativamente más rápido para cualquier animación de más de unos 100 fotogramas. Q: Mi proyecto usa shaders OSL personalizados. ¿Funcionarán en la render farm? A: Sí, siempre que los archivos de shader .osl estén incluidos en el archivo del proyecto y se referencien mediante rutas relativas en los nodos de shader. El método más sencillo es colocar todos los archivos .osl en la misma carpeta que su archivo .blend. Q: ¿Cómo se compara el costo del renderizado GPU frente al CPU en la render farm? A: El renderizado GPU es generalmente más rápido por fotograma (de 5 a 15 veces para Cycles), pero el costo por worker es mayor porque las máquinas con GPU son más costosas. El costo total de un renderizado es aproximadamente comparable entre Cycles CPU y Cycles GPU para la mayoría de las escenas; GPU termina más rápido pero cuesta más por minuto. Para estimaciones de costo específicas según su escena, la ofrece una comparación por fotograma y por trabajo. Q: ¿Puedo renderizar simulaciones de Blender (fluidos, humo, cabello) en la render farm? A: Para las simulaciones, los archivos de caché deben ser procesados (baked) localmente primero y luego incluidos en la subida del proyecto. La render farm renderiza los fotogramas contra el caché procesado; no ejecuta simulaciones en vivo. Este es el método estándar para todos los DCCs: el procesamiento de simulaciones es trabajo de estación de trabajo, y el renderizado de fotogramas es trabajo de render farm.

---

[PHASE 2D: cover image needed — 1200x675px WebP]