V-Ray 6 en una Cloud Render Farm: Guía práctica para 2026

Introducción

V-Ray ha sido una pieza fundamental en el renderizado de producción durante más de dos décadas, y V-Ray 6 sigue siendo la versión que utiliza a diario un gran número de estudios. Las nuevas versiones principales llegan al mercado, los flujos de trabajo de producción las validan lentamente, y un proyecto de archviz en 4K que debe entregarse la semana que viene no espera a que se complete una migración de versión. Por eso, aunque V-Ray 7 ya esté disponible, muchas de las escenas que llegan a una V-Ray 6 cloud render farm están construidas, iluminadas y aprobadas en la versión 6 — y deben renderizarse igual en mil núcleos que en una única estación de trabajo.

Ahí es precisamente donde reside la mayor parte de los problemas. Una escena de V-Ray 6 que se renderiza perfectamente en la máquina en la que fue construida puede parpadear, perder activos o silenciosamente cambiar al motor equivocado en el momento en que sus fotogramas se distribuyen entre nodos de trabajo que nunca han visto la carpeta del proyecto. En Super Renders Farm hemos pasado años observando exactamente qué pasos superan ese salto y cuáles no. Esta guía explica qué cambió en V-Ray 6 para quienes realmente presionan render, cómo se comporta la versión en las aplicaciones anfitrionas que admitimos, cuándo V-Ray GPU supera a V-Ray CPU (y cuándo no), y cómo empaquetar una escena para que los fotogramas distribuidos regresen limpios. Nada de esto asume que usted haya adquirido sus propias licencias de renderizado o que desee conectarse de forma remota a una máquina para supervisar una cola.

Qué cambió en V-Ray 6 para quienes realmente renderizan

Gran parte de la conversación en torno a V-Ray 6 se centra en las mejoras de modelado y de look development. Lo que importa en una render farm es más específico: qué funciones cambian el trabajo que realiza un nodo de renderizado, el tamaño del archivo que debe enviar o los plugins que necesita instalados. Algunas del ciclo de V-Ray 6 son genuinamente relevantes para la render farm.

Funciones de renderizado de V-Ray 6 — Enmesh, Chaos Scatter, V-Ray Decals y nubes volumétricas

Enmesh cubre una malla fuente sobre una superficie en tiempo de renderizado en lugar de incorporar esa geometría en la escena. Piense en cota de malla, fachadas perforadas, tela tejida o rejillas. Dado que la geometría se genera en el nodo durante el renderizado en lugar de almacenarse en el archivo, el .vrscene que viaja a cada nodo de trabajo permanece pequeño y la geometría pesada solo existe en la memoria de renderizado. Esto supone una ventaja real en una render farm: menos transferencia de red y RAM que escala con el renderizado en lugar de con el archivo guardado.

Chaos Scatter incorporó la dispersión nativa directamente en V-Ray — vegetación, rocas, cubierta del suelo — resuelta de forma procedural en tiempo de renderizado. La ventaja en la render farm es la reducción de dependencias: una escena dispersada con Chaos Scatter no necesita un plugin de dispersión de terceros con licencia instalado en cada nodo, lo que elimina un posible factor de fallo cuando un fotograma llega a un nodo de trabajo.

V-Ray Decals proyecta un material sobre una superficie sin modificar sus UVs ni su topología — etiquetas, pegatinas, desgaste de superficie, señalización. Se resuelven íntegramente dentro del flujo de trabajo de V-Ray, por lo que lo único que necesita un nodo es acceso a los mapas de textura del decal.

El cielo procedural y las nubes volumétricas permiten construir un cielo como parámetros en lugar de un HDRI fijo, con nubes que se comportan como volúmenes reales en la escena. Estos renderizados son más pesados por fotograma, pero son completamente paralelos por fotograma — cada nodo calcula sus propios fotogramas sin depender de sus vecinos — por lo que se distribuyen de forma limpia. La salvedad es la memoria de V-Ray GPU: los cielos volumétricos densos consumen VRAM, y un cielo complejo suele ser más seguro en CPU.

El V-Ray Frame Buffer también sigue siendo un elemento valioso en un flujo de trabajo de render farm. Su Light Mix permite separar y reequilibrar luces individuales o grupos de luces después de que el renderizado haya finalizado, directamente desde los elementos de renderizado guardados, sin necesidad de volver a renderizar. Cuando un director pide "calentar la luz principal y bajar la luz de relleno" al día siguiente de que una secuencia haya terminado, ese ajuste se realiza en la composición en lugar de volver a pasar por la cola — que es el cambio de menor costo que se puede hacer. Y Chaos Cosmos, la biblioteca de activos integrada, resulta conveniente en el viewport, pero introduce el fallo más común en una render farm que observamos; hablaremos más de esto en la sección del flujo de trabajo, porque vale la pena hacerlo correctamente.

V-Ray 6 en las aplicaciones anfitrionas que renderizamos

V-Ray 6 se distribuye como integraciones separadas para aplicaciones anfitrionas distintas, y el hecho relevante para la render farm es que todas convergen en el mismo formato de despacho: un archivo .vrscene renderizado por V-Ray Standalone. La aplicación en la que se modela importa para el flujo de trabajo; al nodo le importa mucho menos, ya que simplemente ejecuta la escena exportada.

En nuestra render farm, las aplicaciones anfitrionas por las que ejecutamos V-Ray son 3ds Max, Maya, Cinema 4D y Houdini. 3ds Max con V-Ray es el caballo de batalla de la archviz y la ruta más común que vemos — interiores, exteriores, visualización de productos. Maya con V-Ray cubre el mismo terreno para los flujos de trabajo de VFX y animación. Cinema 4D con V-Ray sirve a los estudios de motion y diseño. Houdini con V-Ray para Houdini completa el conjunto para escenas construidas de forma procedural, donde la geometría controlada por VEX y nodos se resuelve en la escena exportada en el momento de la exportación. Si desea el detalle por aplicación, mantenemos páginas de destino para 3ds Max, Maya, Cinema 4D y Houdini, así como una descripción general específica de V-Ray en la página de la V-Ray cloud render farm.

Vale la pena mencionar dos limitaciones de forma honesta. SketchUp tiene su propia integración de V-Ray, pero SketchUp no es una de las aplicaciones anfitrionas que ejecutamos en la render farm. Los usuarios de SketchUp tienen igualmente un camino claro: V-Ray para SketchUp puede exportar un .vrscene directamente, y ese archivo se renderiza en V-Ray Standalone igual que uno exportado desde 3ds Max — por lo que la escena llega a la render farm sin necesidad de tener SketchUp instalado. La alternativa es llevar el modelo a 3ds Max, reenlazar los materiales y exportar desde allí, lo que requiere más trabajo pero ofrece el conjunto completo de herramientas de 3ds Max para la limpieza. En cualquier caso, el renderizado se realiza a través de la exportación de una aplicación anfitriona compatible, no dentro de SketchUp.

La otra limitación es Blender. En nuestra render farm, las escenas de Blender se renderizan en Cycles — el motor de renderizado de producción nativo de Blender — no en V-Ray. Por tanto, si su flujo de trabajo es V-Ray, las aplicaciones anfitrionas son las cuatro anteriores; si es Blender, se trabaja con Cycles, y ese es un flujo de trabajo diferente.

V-Ray GPU vs V-Ray CPU en una render farm: la decisión real

V-Ray 6 ofrece dos motores de renderizado que comparten materiales e iluminación, pero se comportan de manera muy diferente cuando se escalan. Elegir el equivocado es uno de los errores más costosos en una render farm, porque normalmente no se nota hasta que los fotogramas regresan.

Empecemos con la verdad más aburrida: la mayor parte del trabajo con V-Ray sigue siendo trabajo de CPU. En los proyectos que vemos, aproximadamente el 70% del renderizado es CPU — V-Ray (CPU), Corona, Arnold CPU — y la mayor parte corresponde a archviz. V-Ray CPU escala de forma casi lineal con los núcleos físicos, por lo que los servidores de alto número de núcleos se adaptan muy bien. Nuestra flota de CPU está construida sobre máquinas dual Intel Xeon E5-2699 V4 con 96–256 GB de RAM cada una, con un total de más de 20.000 núcleos CPU, y un interior en 4K que tarda horas en una estación de trabajo se distribuye por ese pool fotograma a fotograma. De forma crucial, el renderizado en CPU accede a la RAM del sistema, no a la VRAM, por lo que un interior con gran cantidad de texturas con materiales PBR en 4K y 8K en todo el conjunto no alcanza un límite de memoria como puede suceder con la GPU. Para archviz de calidad final a escala, la CPU suele ser la opción segura por defecto.

V-Ray GPU representa el otro 30%, y es genuinamente más rápido — cuando la escena encaja. Funciona en dos modos: un modo CUDA de amplia compatibilidad, y un modo RTX que utiliza los núcleos de trazado de rayos por hardware en GPUs NVIDIA de clase RTX para una aceleración dependiente de la escena. Nuestras máquinas GPU tienen tarjetas RTX 5090 con 32 GB de VRAM cada una, y ese número de VRAM lo explica todo. La VRAM es la restricción principal en el renderizado GPU: si la geometría y las texturas de una escena caben, V-Ray GPU es excelente para la iteración y para interiores de complejidad moderada. El salto de 24 GB (una tarjeta de gama alta típica para estaciones de trabajo) a 32 GB es la diferencia entre una escena que cabe completamente en memoria y una escena que tiene que paginar datos entrantes y salientes mediante out-of-core, lo que reduce el rendimiento. Para escenas que paginaban en una tarjeta de 24 GB, simplemente tener ese espacio adicional puede representar la mayor parte de la aceleración. Realizamos benchmarks precisamente en hardware RTX 5090 en nuestro análisis de velocidad de V-Ray GPU y en el artículo más amplio sobre rendimiento de renderizado con RTX 5090; la página de la cloud render farm GPU explica cómo están configurados esos nodos.

La decisión, simplificada:

V-Ray 6 también admite un modo híbrido en el que los núcleos CPU y la GPU del mismo nodo contribuyen a un único renderizado, lo que resulta útil cuando una escena GPU está justo en el límite de su presupuesto de memoria. Lo que debe evitarse es asumir que "la GPU siempre es más rápida". Para una escena de archviz grande y con gran cantidad de texturas, V-Ray CPU suele ser más rápido en general porque no lucha contra un techo de memoria. Adapte el motor a la escena, no a las expectativas.

Cómo lograr que una escena de V-Ray 6 se renderice correctamente en una render farm

Esta es la parte que determina si sus fotogramas regresan utilizables. La mecánica no es complicada, pero algunos fallos se producen de forma silenciosa, que es la peor manera de fallar.

El camino de despacho. La forma canónica de renderizar V-Ray en una render farm es exportar la escena como .vrscene y dejar que V-Ray Standalone la renderice en cada nodo. La consecuencia importante es el licenciamiento: un nodo que ejecuta V-Ray Standalone no necesita una licencia de 3ds Max, Maya o Cinema 4D para renderizar — necesita V-Ray. En nuestra render farm esas licencias de renderizado están incluidas en lo que usted paga por renderizar; no aporta su propia licencia y no instala nada. Ese es el significado práctico de "completamente gestionado" — sin escritorio remoto, sin servidor de licencias que supervisar, sin configuración de software por nodo de su parte. Es también la línea clara entre esto y un modelo de alquiler de infraestructura, donde se alquilarían máquinas básicas y habría que aportar las propias licencias.

Distribución de fotogramas, no Distributed Rendering. Estos dos conceptos se confunden constantemente. Una render farm distribuye fotogramas completos entre nodos — el nodo A renderiza el fotograma 1, el nodo B renderiza el fotograma 2, y así sucesivamente. El Distributed Rendering (DR) de V-Ray es algo diferente: varias máquinas colaborando en un único fotograma, dividiendo buckets a través de la red en tiempo real. DR es una herramienta de estudio para un fotograma héroe de gran tamaño; añade latencia de red, exige versiones de V-Ray idénticas en todas partes y es menos eficiente a escala. Para prácticamente toda animación y secuencia de imágenes, la distribución de fotogramas es el modelo correcto, y es lo que hace una render farm por defecto.

Distribución de rango de fotogramas frente a V-Ray Distributed Rendering en una render farm

GI sin parpadeo. Para la animación, esta es la elección que suele dar problemas. Brute Force GI más una Light Cache por fotograma calcula la iluminación de forma independiente para cada fotograma — más lento por fotograma, pero sin parpadeo y sin dependencia entre fotogramas, por lo que cualquier nodo puede renderizar cualquier fotograma en cualquier orden. Ese es el valor predeterminado seguro contra parpadeos que recomendamos para animaciones distribuidas. El método de Irradiance Map es más rápido por fotograma porque precalcula una solución de GI y la reutiliza, pero solo funciona para animaciones de cámara en vuelo con luces y objetos estáticos, y cada nodo debe leer el mismo mapa precalculado desde una ruta compartida. El fallo clásico: el mapa se guarda en una ruta local como C:\Users\artista\escena.vrmap, los nodos no pueden encontrarlo, y cada fotograma recalcula silenciosamente el GI — produciendo exactamente el parpadeo que intentaba evitar. Si usa Irradiance Map, precalcúlelo una vez, envíe el archivo con el trabajo y vuelva a establecer las rutas. Si no está seguro, use Brute Force.

Denoising. V-Ray 6 ofrece el V-Ray Denoiser (CPU), el NVIDIA AI Denoiser (necesita una GPU NVIDIA en el nodo) e Intel Open Image Denoise (CPU, funciona en cualquier lugar). Los tres trabajan por fotograma sin estado entre fotogramas, por lo que son seguros para el renderizado completamente paralelo. Nuestro consejo habitual: guarde siempre el pase de belleza sin denoise junto con la salida con denoising. Si el denoiser difumina un detalle, vuelva a aplicar el denoising en posproducción en lugar de volver a renderizar la secuencia.

Activos de Chaos Cosmos — el fallo silencioso. Este es el fallo más común de V-Ray 6 en la render farm para usuarios nuevos, y falla de forma silenciosa. Los activos de Cosmos se descargan en la caché local de Cosmos. Al exportar el .vrscene, esos activos se referencian por sus rutas locales. Los nodos no tienen su caché de Cosmos, por lo que obtienen una escena que apunta a archivos que no existen — y el resultado es vegetación faltante, props grises o un cielo en blanco, sin ningún error concreto. La solución es recopilar los activos antes de enviar: use las herramientas de recopilación de activos / "empaquetar proyecto" de V-Ray para reunir todos los activos de Cosmos y de texturas en una carpeta junto a la escena y volver a establecer las rutas como relativas. Haga eso y el trabajo será autónomo. Omítalo y tendrá que volver a renderizar. La misma disciplina aplica a las texturas ordinarias — cualquier cosa referenciada por una ruta local absoluta es un activo faltante esperando a ocurrir.

Flujo de despacho de V-Ray 6 en la render farm, desde la exportación del DCC hasta los nodos de renderizado de V-Ray Standalone

Subida de archivos. Empaquete el proyecto como .tar.gz o .7z — los archivos .zip no son compatibles para la subida, así que reempaquete antes de enviar un proyecto comprimido en zip. Para escenas muy grandes, SFTP o el cliente de escritorio es más estable que una subida desde el navegador. La salida de renderizado permanece disponible durante 45 días, así que descargue los fotogramas terminados con prontitud o deje que el cliente los descargue automáticamente.

Lista de verificación previa al envío

La mayoría de los renderizados fallidos en una render farm tienen su origen en cuatro o cinco causas recurrentes. Ejecutar un único fotograma de prueba en la render farm antes de comprometer una secuencia de 2.000 fotogramas cuesta solo unos minutos y detecta casi todos los problemas. Aquí está la versión resumida que entregamos a los usuarios:

Los costos siguen la misma lógica de por unidad en todos los motores, lo que facilita la estimación: el renderizado CPU se factura a $0,004 por GHz-hora, y el renderizado GPU a $0,003 por OctaneBench-hora, con todas las licencias de motor de renderizado ya incluidas en esas tarifas. Las nuevas cuentas comienzan con $25 de crédito de renderizado gratuito para ejecutar exactamente el tipo de prueba de fotograma único descrita anteriormente, y los créditos no caducan. El desglose completo está disponible en la página de precios, y si está comparando proveedores en lugar de motores, nuestra comparación de render farms para V-Ray explica qué buscar.

FAQ

Q: ¿Puedo renderizar V-Ray 6 en una cloud render farm sin actualizar a V-Ray 7? A: Sí. Las escenas de V-Ray 6 se renderizan a través de V-Ray Standalone desde un .vrscene exportado, y no existe ningún requisito de migrar a una versión principal más reciente. Muchos flujos de trabajo de producción permanecen en V-Ray 6 deliberadamente, y una render farm renderiza la versión en la que se construyó y aprobó su escena.

Q: ¿Necesito comprar mi propia licencia de V-Ray para el renderizado en la nube? A: No. En nuestra render farm, la licencia de renderizado de V-Ray está incluida en la tarifa de renderizado por unidad, por lo que usted no aporta ni paga una licencia separada para renderizar. Esta es la diferencia entre una render farm completamente gestionada y un modelo de alquiler de infraestructura, donde alquilaría máquinas y aportaría sus propias licencias de software.

Q: V-Ray GPU o V-Ray CPU — ¿cuál debo usar en una render farm? A: Use V-Ray GPU cuando la geometría y las texturas de su escena quepan en VRAM y desee velocidad para interiores o iteración; use V-Ray CPU cuando la escena sea grande y con gran cantidad de texturas o necesite el conjunto de funciones más maduro para la entrega final. La CPU accede a la RAM del sistema en lugar de a la VRAM, por lo que gestiona escenas de archviz de gran tamaño que obligarían a una GPU a recurrir a un paginado out-of-core más lento.

Q: ¿Cómo se evita el parpadeo del GI en una animación de V-Ray 6 renderizada en muchos nodos? A: Use Brute Force GI con una Light Cache por fotograma como valor predeterminado — calcula la iluminación de forma independiente para cada fotograma, de modo que los nodos distribuidos nunca entren en conflicto. Reserve el método de Irradiance Map para las animaciones de cámara en vuelo con luces y objetos estáticos, y asegúrese de que el mapa precalculado se encuentre en una ruta compartida que todos los nodos puedan leer.

Q: ¿Por qué faltan mis activos de Chaos Cosmos cuando los fotogramas regresan de la render farm? A: Los activos de Cosmos se referencian por rutas locales que solo existen en su propia caché, por lo que los nodos de renderizado no pueden encontrarlos y los objetos se renderizan en gris, faltantes o en blanco sin ningún error concreto. Recopile y establezca rutas relativas para todos los activos en una carpeta de proyecto autónoma antes de enviar — las herramientas de recopilación de activos de V-Ray hacen esto — para que la escena lleve consigo todo lo que necesita.

Q: ¿Puedo renderizar una escena de V-Ray para SketchUp en la render farm? A: Sí, mediante una exportación. SketchUp no es una aplicación anfitriona que ejecutamos, pero V-Ray para SketchUp puede exportar un .vrscene que se renderiza directamente en V-Ray Standalone, o puede llevar el modelo a 3ds Max y exportar desde allí. El renderizado se realiza a través de la escena exportada de una aplicación anfitriona compatible, no dentro de SketchUp.

Q: ¿Cuál es la diferencia entre una render farm y V-Ray Distributed Rendering? A: Una render farm distribuye fotogramas completos entre muchas máquinas, que es el modelo eficiente para animaciones y secuencias de imágenes. V-Ray Distributed Rendering (DR) en cambio divide los buckets de un único fotograma entre máquinas en tiempo real — útil para un fotograma héroe muy grande, pero más lento y más frágil a escala, y no es así como se renderizan las secuencias en una render farm.