Qué es una render farm completamente gestionada

Introducción

Una render farm completamente gestionada es un servicio de render farm en el que el proveedor se encarga del hardware, la instalación del software, las licencias y el pipeline de renderizado de principio a fin -- de modo que usted solo necesita subir una escena y descargar los frames terminados. Si alguna vez ha investigado el cloud rendering, probablemente haya notado que no todos los servicios de render farm funcionan igual. Algunos le ofrecen una sesión de escritorio remoto y le dejan instalar el software usted mismo. Otros le proporcionan instancias de nube en bruto -- CPU o GPU -- donde usted configura todo, desde la instalación del motor de renderizado hasta las licencias. Y otros gestionan todo el pipeline -- usted sube su escena, el renderizado comienza y usted descarga los frames cuando están listos.

Esa última categoría es lo que la industria llama una render farm completamente gestionada, y es el modelo de servicio de render farm en el que se centra esta guía.

Para una visión más amplia de qué son las render farms y cómo funciona la tecnología en todos los modelos, consulte nuestra guía de render farm para artistas 3D. Es un modelo que llevamos operando en Super Renders Farm desde 2010, y después de procesar cientos de miles de trabajos de renderizado, tenemos una visión clara de dónde funciona, dónde no, y qué es lo que realmente importa a la hora de elegir entre las opciones disponibles.

Esta guía de Super Renders Farm desglosa los tres modelos principales de cloud rendering, los compara en las dimensiones que afectan al trabajo de producción, y le ayuda a averiguar qué servicio de render farm se adapta a su estudio o flujo de trabajo freelance. Este artículo profundiza en lo que "completamente gestionado" significa realmente en la práctica y cuándo tiene sentido cada modelo. Si ya ha decidido que quiere un servicio gestionado y lo está comparando directamente con crear el suyo propio, nuestra comparativa entre render farm completamente gestionada y DIY analiza en detalle esa disyuntiva concreta.

Tres modelos de cloud rendering

El mercado de cloud rendering en 2026 se divide en tres categorías amplias. Se diferencian en quién se encarga de qué -- y esa distinción afecta a todo, desde el tiempo de entrega hasta el coste de las licencias, pasando por cuánto tiempo de su día dedica a la infraestructura en lugar de al trabajo creativo.

Render farm completamente gestionada

En este modelo, el proveedor del servicio de render farm posee y mantiene todo el hardware, instala y licencia todos los motores de renderizado, y opera el pipeline de renderizado de principio a fin. Usted interactúa a través de una aplicación de escritorio o un portal web -- sube su archivo de proyecto, especifica los ajustes de renderizado y descarga los resultados. No hay acceso a escritorio remoto involucrado. No hay instalación de software de su lado.

Ejemplos: Super Renders Farm, RebusFarm, GarageFarm.

Estas tres farms comparten la misma forma de servicio gestionado, pero cubren diferentes stacks de DCC y ofrecen distintas generaciones de flotas GPU. Nuestra comparativa GarageFarm vs Super Renders Farm analiza el cara a cara en precios, hardware y adecuación al caso de uso -- incluyendo dónde difiere el soporte de Houdini y After Effects entre ambas.

Su responsabilidad: preparar el archivo de la escena, enviar el trabajo, revisar el resultado.

La responsabilidad de la farm: hardware, redes, almacenamiento, sistema operativo, instalación del motor de renderizado, licencias, gestión de plugins, programación de trabajos, entrega de frames y resolución de fallos de renderizado.

Alquiler de nube autogestionado (IaaS)

Los proveedores de infraestructura como servicio (IaaS) le proporcionan una máquina remota -- normalmente accesible mediante RDP (Remote Desktop Protocol) o SSH -- con hardware de CPU o GPU en bruto. Usted instala su propio software 3D, configura su propio motor de renderizado, gestiona sus propias licencias y ejecuta los renderizados manualmente o mediante sus propios scripts de pipeline.

Ejemplos: iRender, Vast.ai, RunPod, Paperspace.

Su responsabilidad: todo después de que la máquina arranque. Instalación de software, licencias, transferencia de escenas, gestión del renderizado y descarga de resultados.

La responsabilidad del proveedor: disponibilidad del hardware y conectividad de red.

Cloud DIY (crear el suyo propio)

Algunos estudios con personal técnico dedicado configuran su propia infraestructura de renderizado en plataformas de nube pública. Esto implica aprovisionar instancias de CPU o GPU, instalar software de gestión de renderizado (como Thinkbox Deadline o AWS Deadline Cloud), configurar el almacenamiento en red y gestionar todo el stack.

Ejemplos: implementaciones personalizadas en AWS EC2, Google Cloud, Azure -- a menudo usando AWS Deadline Cloud o Deadline autoalojado.

Su responsabilidad: todo el stack tecnológico, desde el aprovisionamiento de instancias hasta el resultado del renderizado.

La responsabilidad del proveedor: infraestructura física (servidores, energía, refrigeración, redes).

Comparativa lado a lado

Así es como se comparan los tres modelos en las dimensiones que más importan para el trabajo de producción:

Dimensión	Completamente gestionada	Nube autogestionada (IaaS)	Cloud DIY
Instalación de software	La farm se encarga	Usted instala	Usted instala
Licencias del motor de renderizado	Incluidas en el coste del renderizado	Se compran por separado (500-1.500 $/año por nodo)	Se compran por separado
Escritorio remoto necesario	No	Sí (RDP/SSH)	Sí (SSH + interfaz web)
Configuración de plugins	La farm la configura por usted	Usted la configura	Usted la configura
Tiempo de configuración (primer trabajo)	Minutos	Horas a días	Días a semanas
Mantenimiento continuo	Ninguno	Moderado (actualizaciones, drivers)	Alto (stack completo)
Escalado	Automático	Manual (activar/desactivar VMs)	Manual (complejo)
Envío de escenas	App de escritorio o subida web	Transferencia manual de archivos	Pipeline personalizado
Modelo de precios típico	Por GHz-hora o por OB-hora	Por hora (tiempo de máquina)	Por hora (tiempo de instancia) + almacenamiento + salida de datos
Costes ocultos	Ninguno	Licencias, almacenamiento, tiempo inactivo	Licencias, almacenamiento, salida de datos, tiempo de DevOps
Habilidad técnica requerida	Baja (adaptada al artista)	Media (nociones de sysadmin)	Alta (ingeniería de nube)

Algo que esta tabla no refleja es el coste de las licencias, que suele ser la mayor sorpresa para los estudios que pasan al autogestionado. Una licencia de V-Ray o Corona cuesta entre 500 y 1.500 $ al año por nodo de renderizado. Si usted activa diez nodos en un proveedor IaaS, eso son entre 5.000 y 15.000 $ al año solo en licencias del motor de renderizado -- además de los costes de cómputo. En una farm completamente gestionada, esas licencias son propiedad del proveedor y están incluidas en el coste por trabajo.

Render farm sin escritorio remoto necesario: cómo funciona

Un servicio de render farm que gestiona todo por usted elimina por completo el paso del escritorio remoto -- esa es la distinción principal frente a los alquileres de GPU tipo IaaS o los servicios de renderizado con escritorio remoto. En esos servicios, su flujo de trabajo es: abrir una sesión RDP a una máquina en la nube, instalar o configurar lo que necesita, abrir su escena dentro de ese escritorio remoto, iniciar el renderizado y mantener la sesión activa hasta que los frames terminen. Si la conexión se cae o el host remoto se reinicia, se puede perder trabajo.

No hay ninguna ventana RDP que mantener, ningún nodo remoto en el que instalar software, ni ninguna sesión en la nube que mantener activa. Su 3ds Max, Cinema 4D, Maya, Blender o Houdini local se conecta a la farm mediante un plugin de envío ligero. El flujo de trabajo se reduce a tres fases -- subir, renderizar, descargar:

• Subir -- el plugin empaqueta su escena, texturas, proxies y datos en caché, y luego los transfiere al clúster de almacenamiento de la farm.
• Renderizar -- el programador de la farm asigna los nodos adecuados (CPU para V-Ray, Corona y Arnold CPU; GPU para Redshift, Octane y V-Ray GPU), gestiona las licencias y reintenta automáticamente los frames fallidos.
• Descargar -- los frames completados se transmiten de vuelta a través del mismo plugin a una carpeta en su máquina local.

Así es como Super Renders Farm opera desde 2010. Si un renderizado falla a las 2 de la madrugada, nuestro equipo ve el fallo en el programador -- usted no necesita reconectarse a nada para diagnosticarlo. Para un recorrido paso a paso de cómo se ve cada fase en la práctica, consulte la sección El flujo de trabajo principal: subir, renderizar, descargar más abajo.

El panorama de las licencias varía significativamente según el motor -- V-Ray, Redshift, Arnold, Corona y Cycles tienen cada uno modelos de licencias de nodo y estructuras de coste diferentes. Nuestra guía de licencias de software de render farm cubre cómo funcionan las licencias de cada motor en los tres tipos de farm.

Para una visión más amplia de cómo funciona el cloud rendering en todos los modelos de servicio -- incluyendo estructuras de precios, una tabla comparativa práctica y orientación para empezar -- consulte nuestra guía explicativa de cloud rendering.

El flujo de trabajo principal: subir, renderizar, descargar

Este es el flujo de trabajo del servicio de render farm en tres palabras: subir, renderizar, descargar. Una render farm completamente gestionada gestiona todo lo demás en su nombre -- instalación de software, licencias, gestión de drivers, programación de trabajos, recuperación de fallos -- de modo que esas tres acciones son toda la interacción que necesita tener con la farm.

Subir. Abra su proyecto en 3ds Max, Cinema 4D, Maya, Blender o Houdini y envíelo a través de la aplicación de escritorio de la farm. La app empaqueta automáticamente su archivo de escena junto con todas las texturas, proxies y datos en caché. Usted no necesita recopilar los assets manualmente, configurar una máquina remota ni abrir una sesión de escritorio remoto. La subida gestiona el remapeo de rutas para que las texturas se resuelvan correctamente en los nodos de renderizado -- la causa más común de renderizados fallidos en configuraciones autogestionadas.

Renderizar. La farm distribuye sus frames entre docenas o cientos de máquinas que se ejecutan en paralelo. Una animación de 1.000 frames que tardaría una semana en su estación de trabajo local puede terminar en unas pocas horas en 50 nodos. Usted supervisa el progreso a través de un panel web o de la app de escritorio, y la farm gestiona todo lo demás por debajo: licencias del motor de renderizado, versiones de plugins, compatibilidad de drivers de GPU, reintento automático de frames si un nodo falla a mitad de renderizado. Usted no toca nada de eso.

Descargar. Los frames completados llegan a la aplicación de escritorio a medida que terminan. Puede previsualizar frames individuales durante el renderizado para detectar errores a tiempo, y luego descargar la secuencia completa en lote cuando el trabajo se completa. Para trabajos grandes que producen miles de frames EXR o PNG de alta resolución, la mayoría de las farms gestionadas también ofrecen entrega directa en almacenamiento en la nube.

Esa es toda la interacción. Sin sesiones de escritorio remoto, sin servidores de licencias que configurar, sin actualizaciones de drivers que gestionar. Para un análisis más profundo de cómo se compara esto con los enfoques autogestionados y DIY, nuestra comparativa entre render farm completamente gestionada y DIY desglosa las disyuntivas en detalle.

Qué sucede cuando usted envía un trabajo a una farm completamente gestionada

Una de las preguntas que más escuchamos es alguna variante de: "Necesito una render farm que gestione todo por mí -- solo quiero subir y descargar. ¿Qué sucede realmente después de que hago clic en Enviar?" A continuación, el flujo de trabajo paso a paso en nuestra farm -- es representativo de cómo operan la mayoría de los servicios de render farm completamente gestionados:

Paso 1: instale la aplicación de escritorio. Descargue el plugin de envío para su software 3D. En nuestra farm, se integra directamente con 3ds Max, Cinema 4D, Maya, Blender y Houdini. El plugin detecta automáticamente su motor de renderizado, la versión y los plugins instalados.

Paso 2: abra su proyecto y haga clic en Enviar trabajo. La aplicación empaqueta su archivo de escena junto con todas las texturas, proxies y datos en caché. Verifica las rutas de archivo, comprueba si faltan assets y comprime todo para la subida. Usted no necesita recopilar texturas manualmente ni remapear rutas -- el plugin se encarga de esto.

Paso 3: subida y cola de renderizado. Su proyecto empaquetado se sube al clúster de almacenamiento de la farm. Una vez subido, el trabajo entra en la cola de renderizado. La farm asigna nodos de renderizado que coinciden con los requisitos de su software y motor -- nodos CPU para motores como V-Ray y Corona, nodos GPU para Redshift u Octane -- incluyendo los drivers correctos, la versión del motor de renderizado y los plugins. No hay ninguna configuración manual involucrada.

Paso 4: renderizado. Los frames se distribuyen entre los nodos disponibles. La mayoría de los trabajos en nuestra farm son renderizados por CPU -- V-Ray, Corona y Arnold CPU se ejecutan en nuestra flota de máquinas Intel Xeon E5-2699 V4 dobles con 96-256 GB de RAM. Para el renderizado por GPU (Redshift, Octane, V-Ray GPU), los trabajos se ejecutan en nodos NVIDIA RTX 5090 dedicados con 32 GB de VRAM cada uno. La farm gestiona la programación de trabajos, el reintento de frames en caso de fallo y el equilibrio de carga automáticamente, independientemente del tipo de renderizado.

Paso 5: descarga. A medida que los frames se completan, quedan disponibles para descargar a través de la misma aplicación de escritorio. Puede configurar la descarga automática a una carpeta local. Cuando el trabajo completo termina, usted recibe una notificación.

Todo el proceso -- desde la instalación hasta el primer frame renderizado -- suele tardar menos de 30 minutos para un nuevo usuario. Para los usuarios recurrentes con el plugin ya instalado, es subir, renderizar, descargar. Sin sesión de escritorio remoto. Sin instalación de software. Sin gestión de licencias.

Quién se beneficia más de cada modelo

No todos los estudios necesitan el mismo enfoque. Aquí tiene un desglose práctico:

Completamente gestionada: freelancers, estudios pequeños, equipos con plazos ajustados

Si su equipo está formado principalmente por artistas y diseñadores -- no por personal de TI -- un servicio de render farm completamente gestionado elimina la sobrecarga técnica que ralentiza la producción. Esta es la opción correcta cuando:

• Usted no cuenta con un sysadmin dedicado ni con un render wrangler
• Necesita escalar el renderizado para cumplir un plazo sin planificar infraestructura
• Trabaja con motores con licencia (V-Ray, Corona, Redshift) y no quiere gestionar licencias por nodo
• Quiere enviar un trabajo y centrarse en la siguiente tarea, no supervisar una máquina remota
• Utiliza plugins como Forest Pack, RailClone, X-Particles o TurbulenceFD que requieren una configuración específica

Hemos visto este patrón repetidamente: un estudio de archviz de tres personas que trabaja con V-Ray o Corona (renderizado por CPU -- que representa alrededor del 70 por ciento de los trabajos en nuestra farm) con un plazo el viernes dedica el martes por la tarde a subir 50 frames, y para el miércoles por la mañana todo está renderizado y descargado. Sin sesiones RDP, sin dolores de cabeza con servidores de licencias, sin infraestructura que gestionar.

Nube autogestionada (IaaS): usuarios técnicos que necesitan control total

Los alquileres de GPU autogestionados tienen sentido cuando necesita ejecutar software personalizado que las farms gestionadas no soportan, o cuando necesita una máquina persistente para pruebas iterativas. Casos habituales:

• Motores de renderizado propietarios o poco comunes
• Cargas de trabajo de aprendizaje automático junto con el renderizado
• Simulaciones de larga duración (fluidos, tela, partículas) que necesitan un estado de máquina persistente
• Equipos con capacidad de DevOps existente que prefieren el control total

La disyuntiva es real: usted gana flexibilidad, pero asume el coste de las licencias, el tiempo de mantenimiento y la responsabilidad de resolución de problemas. Hemos hablado con estudios que cambiaron de IaaS a servicios gestionados específicamente porque sus artistas dedicaban entre 5 y 10 horas al mes a actualizaciones de drivers, configuración de licencias y resolución de problemas de RDP -- tiempo que debería haberse dedicado al trabajo creativo. Si está sopesando gestionado frente a DIY para su propio equipo, nuestra comparativa entre render farm completamente gestionada y DIY analiza esa decisión con mayor profundidad de la que cubre esta guía.

Cloud DIY: grandes estudios de VFX con ingenieros de pipeline dedicados

Crear su propia infraestructura de renderizado en la nube solo tiene sentido económico a gran escala -- normalmente 50 o más nodos de renderizado concurrentes -- y solo si cuenta con ingenieros de pipeline en plantilla. AWS Deadline Cloud ha reducido la complejidad de configuración en comparación con Deadline totalmente autoalojado, pero usted sigue gestionando el aprovisionamiento de instancias, la arquitectura de almacenamiento, las redes, las licencias y la optimización de costes.

Para la mayoría de los estudios de menos de 20 personas, la sobrecarga de ingeniería del cloud DIY supera el ahorro de costes en comparación con un servicio de render farm gestionado.

Problemas comunes con los enfoques autogestionados y DIY

Después de años incorporando estudios que anteriormente usaban configuraciones autogestionadas o DIY, hemos catalogado los problemas recurrentes:

Problema	Causa	Impacto
Errores de licencia del motor de renderizado	Servidor de licencias mal configurado o asientos superados	Los renderizados fallan silenciosamente o producen frames negros
Incompatibilidad de drivers o runtime	Versión de driver incompatible con el motor de renderizado (GPU) o redistribuibles faltantes (CPU)	Bloqueos, errores de CUDA o fallos silenciosos de renderizado
Texturas faltantes tras la subida	Rutas de archivo no remapeadas para la máquina remota	Materiales blancos o rosas en el resultado
Cargos por máquina inactiva	Olvidó apagar la instancia tras el renderizado	50-200 $ en cargos inesperados por incidente
Conflictos de versión de plugins	El plugin instalado en remoto no coincide con el local	Los datos de simulación o partículas se renderizan incorrectamente
Cuello de botella en la transferencia de red	Escenas grandes (50+ GB) con ancho de banda de subida limitado	Horas de tiempo de transferencia antes de que comience el renderizado
Sin reintento de trabajo en caso de fallo	Un solo frame que falla mata todo el trabajo	Tiempo perdido, necesidad de identificar y reenviar manualmente los frames fallidos

En una farm completamente gestionada, estos problemas los gestiona el proveedor. La gestión de licencias, la compatibilidad de drivers, el remapeo de rutas, el versionado de plugins y el reintento de frames forman parte del servicio. Eso no es una afirmación de marketing -- es la realidad operativa de lo que significa "completamente gestionado".

Cómo evaluar una render farm: lista de verificación para la decisión

Al comparar opciones de servicio de render farm, estas son las preguntas que realmente importan:

Software y licencias:

• ¿La farm preinstala su motor de renderizado y su versión?
• ¿Las licencias del motor de renderizado están incluidas, o necesita las suyas propias?
• ¿Soporta sus plugins (Forest Pack, X-Particles, TFD, etc.)?

Flujo de trabajo:

• ¿Puede enviar directamente desde su aplicación 3D?
• ¿Se requiere escritorio remoto para alguna parte del proceso?
• ¿La farm gestiona la recopilación de texturas y el remapeo de rutas?
• ¿El reintento de frames es automático cuando un nodo de renderizado falla?

Hardware:

• ¿Qué especificaciones de CPU hay para el renderizado por CPU? (El número de núcleos, la velocidad de reloj y la RAM afectan al rendimiento de V-Ray y Corona -- los motores de renderizado más comunes en producción)
• ¿Qué modelo de GPU y VRAM está disponible? (Importante para motores GPU como Redshift y Octane -- las escenas con texturas pesadas necesitan 24+ GB de VRAM)
• ¿Cuántos nodos de renderizado hay disponibles, y puede escalar entre varios nodos para trabajos de animación?

Transparencia de costes:

• ¿El precio es por GHz-hora, por OB-hora, por frame o por hora de máquina?
• ¿Hay costes ocultos por almacenamiento, transferencia de datos o licencias?
• ¿Existe una prueba gratuita o créditos iniciales para probar antes de comprometerse?

Soporte:

• ¿Hay soporte técnico disponible durante su horario laboral?
• ¿El equipo de la farm puede configurar plugins personalizados si es necesario?
• ¿Qué ocurre si un renderizado falla -- recibe una notificación, y hay reintento automático?

Para referencia: nuestra farm ejecuta nodos CPU Intel Xeon E5-2699 V4 dobles (que gestionan la mayoría de los trabajos de renderizado -- V-Ray, Corona, Arnold) junto con nodos GPU NVIDIA RTX 5090 dedicados con 32 GB de VRAM para cargas de trabajo de Redshift y Octane. Todas las licencias del motor de renderizado están incluidas. La configuración de plugins la gestiona nuestro equipo antes de que comience su primer renderizado. No hay escritorio remoto involucrado en ningún momento.

Completamente gestionada no significa limitada

Un concepto erróneo habitual es que "completamente gestionada" significa renunciar al control sobre sus ajustes de renderizado. Eso no es exacto. En una farm gestionada, usted sigue controlando:

• Resolución, rango de frames y formato de salida
• Ajustes del motor de renderizado (muestreo, GI, denoising)
• Selección de cámara y configuración de capas de renderizado
• Preferencias de prioridad y plazo
• Tipo de máquina (CPU o GPU) y asignación de nodos

Lo que renuncia es al trabajo de infraestructura: instalar software, gestionar licencias, configurar drivers, resolver fallos de hardware y supervisar la disponibilidad de las máquinas. Para la mayoría de los equipos de producción, esa disyuntiva es sencilla -- usted no contrató artistas 3D para que gestionaran servidores. Si todavía está decidiendo si un servicio de render farm completamente gestionado o una infraestructura cloud DIY se adapta mejor a su equipo, consulte nuestra comparativa entre render farm completamente gestionada y DIY para el desglose directo de la disyuntiva, o nuestra guía más amplia de cloud render farm para ver cómo encajan los servicios gestionados en el panorama más amplio del cloud rendering.

FAQ

Q: ¿Necesito instalar algún software en la render farm yo mismo? A: En Super Renders Farm, no. En una render farm completamente gestionada, todo el software 3D, los motores de renderizado y los plugins están preinstalados y mantenidos por el equipo de la farm. Usted solo instala una aplicación de escritorio ligera en su máquina local para el envío de trabajos y la descarga de frames.

Q: ¿Se requiere acceso por escritorio remoto para usar una render farm completamente gestionada? A: No. Las farms completamente gestionadas no utilizan sesiones de escritorio remoto (RDP). Usted envía los trabajos a través de una aplicación de escritorio o un portal web, y los frames se entregan directamente a su máquina local. No hay necesidad de conectarse a un servidor remoto.

Q: ¿Necesito comprar licencias de motor de renderizado por separado para la farm? A: No. Las farms completamente gestionadas incluyen las licencias del motor de renderizado en el coste de su renderizado. Ya sea que use V-Ray, Corona, Redshift, Arnold u Octane, las licencias son propiedad de la farm y están gestionadas por ella. Sus licencias locales permanecen en su estación de trabajo.

Q: ¿Qué ocurre si mi escena utiliza plugins como Forest Pack o X-Particles? A: Las farms gestionadas mantienen una biblioteca de plugins de uso habitual. Si su proyecto requiere un plugin que aún no está instalado, el equipo de soporte de la farm lo configurará antes de que comience su renderizado. Usted no necesita encargarse de la instalación del plugin.

Q: ¿Puedo simplemente subir mi archivo de escena y descargar los resultados sin ninguna configuración? A: En esencia, sí. Después de una instalación única de la app de escritorio (que tarda unos minutos), el flujo de trabajo es: abrir su proyecto, hacer clic en Enviar trabajo, y descargar los frames cuando estén listos. La app se encarga automáticamente de la recopilación de texturas, el remapeo de rutas y la subida.

Q: ¿En qué se diferencia una render farm completamente gestionada de alquilar una máquina virtual en la nube? A: Un alquiler de VM en la nube (IaaS) -- ya sea CPU o GPU -- le proporciona una máquina remota donde usted instala y gestiona todo por sí mismo: software, licencias, drivers y pipeline de renderizado. Una farm completamente gestionada se encarga de todo eso por usted. La disyuntiva: IaaS ofrece más flexibilidad para configuraciones personalizadas, pero las farms gestionadas eliminan la sobrecarga de infraestructura y los costes de licencias. La mayoría de los estudios que usan motores de renderizado por CPU como V-Ray o Corona consideran que el enfoque gestionado ahorra un tiempo significativo.

Q: ¿Qué motores de renderizado y software 3D soporta Super Renders Farm? A: Soportamos 3ds Max, Cinema 4D, Maya, Blender, Houdini, After Effects y NukeX. Los motores de renderizado incluyen V-Ray, Corona, Arnold, Redshift, Octane y Cycles. Todos los motores están preinstalados con versiones actuales y recientes disponibles.

Q: Necesito una render farm que gestione todo por mí -- solo quiero subir y descargar. ¿Es posible? A: Sí -- eso describe un servicio de render farm completamente gestionado. El proveedor preinstala su software 3D y sus motores de renderizado, posee y gestiona todas las licencias, configura los plugins y gestiona la programación de trabajos y el reintento de frames en caso de fallo. Su parte del flujo de trabajo se limita a tres acciones: subir su escena, esperar a que el renderizado se complete y descargar los frames terminados. No hay sesión de escritorio remoto ni infraestructura que configurar.