V-Ray 6 sur un cloud render farm : guide pratique 2026

Introduction

V-Ray occupe une place centrale dans le rendu de production depuis plus de deux décennies, et V-Ray 6 est toujours la version qu'une grande partie des studios utilise au quotidien. Les nouvelles versions majeures arrivent, les pipelines les valident lentement, et un projet archviz en 4K qui doit être livré la semaine prochaine n'attend pas une migration de version. Ainsi, même avec V-Ray 7 désormais disponible, de nombreuses scènes qui parviennent à un cloud render farm V-Ray 6 sont construites, éclairées et validées en version 6 — et elles doivent être rendues de la même façon sur un millier de cœurs que sur une seule station de travail.

C'est précisément là que réside la majeure partie des difficultés. Une scène V-Ray 6 qui se rend parfaitement sur la machine où elle a été construite peut scintiller, perdre des ressources ou basculer silencieusement vers le mauvais moteur dès que ses images sont réparties sur des nœuds de travail qui n'ont jamais vu votre dossier de projet. Chez Super Renders Farm, nous avons passé des années à observer exactement quelles étapes survivent à ce saut et lesquelles échouent. Ce guide passe en revue ce que V-Ray 6 a changé pour ceux qui appuient réellement sur Rendre, comment la version se comporte dans les applications hôtes que nous supportons, quand V-Ray GPU l'emporte sur V-Ray CPU (et quand ce n'est pas le cas), et comment préparer une scène pour que les images distribuées reviennent propres. Rien de tout cela ne suppose que vous ayez acheté vos propres licences de rendu ou que vous souhaitiez vous connecter à distance à une machine pour surveiller une file d'attente.

Ce que V-Ray 6 a changé pour ceux qui renderisent vraiment

Une grande partie des discussions autour de V-Ray 6 porte sur les commodités de modélisation et de look-dev. Ce qui compte sur un render farm est plus restreint : quelles fonctionnalités modifient le travail effectué par un nœud de rendu, la taille du fichier à transférer, ou les plugins à installer. Quelques-unes du cycle V-Ray 6 sont véritablement pertinentes pour un render farm.

V-Ray 6 render features — Enmesh, Chaos Scatter, V-Ray Decals, and volumetric clouds

Enmesh tile un mesh source sur une surface au moment du rendu au lieu de cuire cette géométrie dans la scène. Pensez aux mailles de fer, aux façades perforées, aux tissus tissés, aux grilles. Parce que la géométrie est générée sur le nœud pendant le rendu plutôt qu'enregistrée dans le fichier, le .vrscene qui voyage vers chaque nœud de travail reste léger et la géométrie lourde n'existe jamais que dans la mémoire de rendu. C'est un vrai avantage sur un render farm : moins de transfert réseau, et une RAM qui évolue avec le rendu plutôt qu'avec le fichier sauvegardé.

Chaos Scatter a intégré la diffusion native dans V-Ray lui-même — végétation, rochers, couverture du sol — résolue de manière procédurale au moment du rendu. L'avantage côté render farm est la réduction des dépendances : une scène diffusée avec Chaos Scatter n'a pas besoin d'un plugin de diffusion tiers sous licence et installé sur chaque nœud, ce qui est une chose de moins susceptible de manquer quand une image arrive sur un nœud de travail.

V-Ray Decals projette un matériau sur une surface sans toucher à ses UV ni à sa topologie — étiquettes, autocollants, usure de surface, signalétique. Ils se résolvent entièrement dans le pipeline propre de V-Ray, donc la seule chose dont un nœud a besoin est l'accès aux cartes de texture des décalcomanies.

Le ciel procédural et les nuages volumétriques permettent de construire un ciel sous forme de paramètres plutôt que d'un HDRI fixe, avec des nuages qui se comportent comme de vrais volumes dans la scène. Ces rendus sont plus lourds par image, mais ils sont entièrement parallèles par image — chaque nœud calcule ses propres images sans dépendance envers ses voisins — ils se distribuent donc proprement. La mise en garde concerne la mémoire V-Ray GPU : les ciels volumétriques denses sollicitent la VRAM, et un ciel complexe est souvent plus sûr sur CPU.

Le V-Ray Frame Buffer continue également de mériter sa place dans un pipeline de render farm. Son Light Mix vous permet de séparer et de rééquilibrer des lumières individuelles ou des groupes de lumières après la fin du rendu, directement depuis les éléments de rendu sauvegardés, sans nouveau rendu. Quand un directeur artistique demande « réchauffe la lumière principale et baisse le remplissage » le lendemain d'une séquence terminée, cet ajustement se fait en compositing plutôt que de passer à nouveau dans la file d'attente — ce qui est le changement le moins coûteux que vous puissiez faire. Et Chaos Cosmos, la bibliothèque de ressources intégrée, est pratique dans la fenêtre mais introduit la défaillance de render farm la plus courante que nous observons ; nous y reviendrons dans la section workflow, car il vaut la peine de bien faire les choses.

V-Ray 6 dans les DCC que nous renderisons

V-Ray 6 se livre sous forme d'intégrations séparées pour des applications hôtes distinctes, et le fait pertinent pour un render farm est qu'elles convergent toutes vers le même format de dispatch : un fichier .vrscene rendu par V-Ray Standalone. L'hôte dans lequel vous modélisez importe pour votre workflow ; il importe beaucoup moins pour le nœud, qui exécute simplement la scène exportée.

Sur notre render farm, les applications hôtes que nous faisons passer par V-Ray sont 3ds Max, Maya, Cinema 4D et Houdini. 3ds Max avec V-Ray est le moteur de travail de l'archviz et le chemin le plus courant que nous observons — intérieurs, extérieurs, visualisation de produits. Maya avec V-Ray couvre le même terrain pour les pipelines VFX et d'animation. Cinema 4D avec V-Ray sert les studios de motion et de design. Houdini avec V-Ray for Houdini complète le tableau pour les scènes construites de manière procédurale, où la géométrie pilotée par VEX et par nœuds est résolue dans la scène exportée au moment de l'export. Si vous souhaitez les détails par application, nous maintenons des pages dédiées pour 3ds Max, Maya, Cinema 4D et Houdini, ainsi qu'un aperçu spécifique à V-Ray sur la page V-Ray cloud render farm.

Deux limites honnêtes méritent d'être énoncées clairement. SketchUp dispose de sa propre intégration V-Ray, mais SketchUp n'est pas une application hôte que nous exécutons sur le render farm. Les utilisateurs de SketchUp ont néanmoins un chemin propre : V-Ray for SketchUp peut exporter un .vrscene directement, et ce fichier se rend sur V-Ray Standalone de la même façon qu'un exporté depuis 3ds Max — la scène atteint donc le render farm sans que nous ayons besoin de SketchUp installé nulle part. L'alternative est d'importer le modèle dans 3ds Max, de re-lier les matériaux et d'exporter depuis là, ce qui représente plus de travail mais donne accès à l'ensemble des outils 3ds Max pour le nettoyage. Dans les deux cas, le rendu se fait via l'export d'un hôte supporté, pas à l'intérieur de SketchUp.

L'autre limite concerne Blender. Sur notre render farm, les scènes Blender se renderisent dans Cycles — le moteur de rendu de production natif de Blender — et non dans V-Ray. Donc si votre pipeline est V-Ray, vos hôtes sont les quatre ci-dessus ; si c'est Blender, vous êtes dans Cycles, et c'est un workflow différent.

V-Ray GPU vs V-Ray CPU sur un render farm : la vraie décision

V-Ray 6 vous offre deux moteurs de rendu qui partagent matériaux et éclairage mais se comportent très différemment une fois mis à l'échelle. Choisir le mauvais est l'une des erreurs les plus coûteuses sur un render farm, car vous ne le remarquez généralement pas avant que les images reviennent.

Commençons par la vérité ennuyeuse : la plupart du travail V-Ray reste un travail CPU. Parmi les projets que nous observons, environ 70 % du rendu est CPU — V-Ray (CPU), Corona, Arnold CPU — et l'essentiel est de l'archviz. V-Ray CPU évolue presque linéairement avec les cœurs physiques, ce qui explique pourquoi les serveurs à grand nombre de cœurs lui conviennent si bien. Notre parc CPU est construit sur des machines Intel Xeon E5-2699 V4 doubles avec 96 à 256 Go de RAM chacune, totalisant plus de 20 000 cœurs CPU, et un intérieur 4K qui prend des heures sur une station de travail est découpé sur ce pool image par image. Surtout, le rendu CPU adresse la RAM système, pas la VRAM, donc un intérieur riche en textures avec des matériaux PBR en 4K et 8K sur l'ensemble du décor ne se heurte pas à une limite mémoire comme peut le faire un GPU. Pour l'archviz en qualité finale à grande échelle, le CPU est généralement le choix par défaut sûr.

V-Ray GPU représente les 30 % restants, et il est réellement plus rapide — quand la scène tient. Il fonctionne en deux modes : un mode CUDA largement compatible, et un mode RTX qui utilise les cœurs de ray-tracing matériel des GPU NVIDIA de classe RTX pour une accélération dépendante de la scène. Nos machines GPU sont équipées de cartes RTX 5090 avec 32 Go de VRAM chacune, et ce chiffre de VRAM est toute l'histoire. La VRAM est la contrainte principale du rendu GPU : si la géométrie et les textures d'une scène tiennent, V-Ray GPU est excellent pour l'itération et pour les intérieurs de complexité modérée. Le saut de 24 Go (une carte haut de gamme typique pour station de travail) à 32 Go est la différence entre une scène qui tient entièrement en mémoire et une scène qui doit paginer des données via out-of-core, ce qui coûte en performances. Pour les scènes qui paginaient sur une carte à 24 Go, avoir simplement l'espace peut représenter la plus grande part de l'accélération. Nous avons mesuré exactement cela sur du matériel RTX 5090 dans notre test de vitesse V-Ray GPU et dans notre analyse plus large des performances de rendu RTX 5090 ; la page GPU cloud render farm explique comment ces nœuds sont configurés.

La décision, résumée :

V-Ray 6 supporte également un mode hybride où les cœurs CPU et le GPU du même nœud contribuent à un seul rendu, ce qui est utile quand une scène GPU est juste à la limite de son budget mémoire. Ce qu'il faut éviter, c'est de supposer que « le GPU est toujours plus rapide ». Pour une grande scène archviz riche en textures, V-Ray CPU est souvent plus rapide globalement parce qu'il ne se bat pas contre un plafond mémoire. Faites correspondre le moteur à la scène, pas au battage médiatique.

Préparer une scène V-Ray 6 pour un rendu propre sur un render farm

C'est la partie qui détermine si vos images reviennent utilisables. Les mécanismes ne sont pas compliqués, mais certains échouent silencieusement, ce qui est la pire façon d'échouer.

Le chemin de dispatch. La façon canonique de rendre V-Ray sur un render farm est d'exporter votre scène sous forme de .vrscene et de laisser V-Ray Standalone la rendre sur chaque nœud. La conséquence importante est la licence : un nœud de travail exécutant V-Ray Standalone n'a pas besoin d'une licence 3ds Max, Maya ou Cinema 4D pour rendre — il a besoin de V-Ray. Sur notre render farm, ces licences de rendu sont incluses dans ce que vous payez pour rendre ; vous n'apportez pas votre propre licence et vous n'installez rien. C'est le sens pratique de « entièrement géré » — pas de bureau à distance, pas de serveur de licences à surveiller, pas de configuration logicielle par nœud de votre côté. C'est aussi la ligne claire entre cela et un modèle de location d'infrastructure, où vous loueriez des machines nues et fourniriez vos propres licences.

Distribution d'images, pas Distributed Rendering. Ces deux notions sont constamment confondues. Un render farm répartit des images entières entre les nœuds — le nœud A rend l'image 1, le nœud B rend l'image 2, et ainsi de suite. Le Distributed Rendering (DR) de V-Ray est une chose différente : plusieurs machines collaborant sur une seule image, répartissant les buckets sur le réseau en temps réel. Le DR est un outil de studio pour une seule image héroïque très volumineuse ; il ajoute de la latence réseau, exige des versions V-Ray identiques partout, et est moins efficace à grande échelle. Pour essentiellement toute animation et séquence d'images, la distribution d'images est le bon modèle, et c'est ce que fait un render farm par défaut.

Frame-range distribution versus V-Ray Distributed Rendering on a render farm

GI sans scintillement. Pour l'animation, c'est le choix qui piège les gens. Brute Force GI plus un Light Cache par image calcule l'éclairage indépendamment pour chaque image — plus lent par image, mais zéro scintillement et aucune dépendance entre images, donc n'importe quel nœud peut rendre n'importe quelle image dans n'importe quel ordre. C'est la valeur par défaut sans scintillement que nous recommandons pour l'animation distribuée. L'approche Irradiance Map est plus rapide par image car elle précalcule une solution GI et la réutilise, mais elle ne fonctionne que pour les animations de caméra avec des lumières et des objets statiques, et chaque nœud doit lire la même carte précalculée depuis un chemin partagé. La défaillance classique : la carte est sauvegardée dans un chemin local comme C:\Users\artiste\scene.vrmap, les nœuds ne peuvent pas la trouver, et chaque image recalcule silencieusement la GI — produisant exactement le scintillement que vous cherchiez à éviter. Si vous utilisez Irradiance Map, faites-la cuire une fois, envoyez le fichier avec le projet, et recheminez-la. Si vous n'êtes pas sûr, utilisez Brute Force.

Denoising. V-Ray 6 vous offre le V-Ray Denoiser (CPU), le NVIDIA AI Denoiser (nécessite un GPU NVIDIA sur le nœud), et Intel Open Image Denoise (CPU, fonctionne partout). Les trois fonctionnent par image sans état inter-images, ils sont donc sûrs pour un rendu entièrement parallèle. Notre conseil standard : sauvegardez toujours la passe brute non-débruitée en parallèle avec la sortie débruitée. Si le denoiser efface un détail, vous refaites le débruitage en post au lieu de re-rendre la séquence.

Les ressources Chaos Cosmos — le tueur silencieux. C'est la défaillance V-Ray 6 la plus courante sur un render farm pour les nouveaux utilisateurs, et elle échoue silencieusement. Les ressources Cosmos se téléchargent dans votre cache Cosmos local. Quand vous exportez le .vrscene, ces ressources sont référencées par leurs chemins locaux. Les nœuds n'ont pas votre cache Cosmos, ils reçoivent donc une scène pointant vers des fichiers qui ne sont pas là — et le résultat est de la végétation manquante, des accessoires gris ou un ciel blanc, sans erreur franche. La solution est de collecter les ressources avant de soumettre : utilisez les outils de collecte de ressources / « pack project » de V-Ray pour rassembler chaque fichier Cosmos et chaque texture dans un dossier à côté de la scène et recheminer tout en chemins relatifs. Faites cela et le projet est autonome. Négligez-le et vous re-renderiserez. La même discipline s'applique aux textures ordinaires — tout ce qui est référencé par un chemin local absolu est une ressource manquante en attente de se manifester.

V-Ray 6 farm dispatch pipeline from DCC export to V-Ray Standalone render nodes

Upload. Compressez le projet en .tar.gz ou .7z — les archives .zip ne sont pas supportées pour l'upload, donc recompressez avant d'envoyer un projet zippé. Pour les scènes très volumineuses, SFTP ou l'application de bureau est plus fiable qu'un upload par navigateur. Les sorties de rendu restent disponibles pendant 45 jours, donc récupérez les images terminées rapidement ou laissez le client les télécharger automatiquement.

Une checklist pré-vol avant de soumettre

La plupart des échecs de rendu sur render farm sont liés à quatre ou cinq causes répétitives. Exécuter une seule image de test sur le render farm avant de valider une séquence de 2 000 images prend quelques minutes et en attrape presque la totalité. Voici la version courte que nous donnons aux gens :

Les coûts suivent la même logique par unité pour les deux moteurs, ce qui rend l'estimation simple : le rendu CPU est facturé à 0,004 $ par GHz-heure, et le rendu GPU à 0,003 $ par OctaneBench-heure, toutes les licences de moteurs de rendu étant déjà incluses dans ces tarifs. Les nouveaux comptes commencent avec 25 $ de crédit de rendu gratuit pour exécuter exactement le type de test sur une seule image décrit ci-dessus, et les crédits n'expirent pas. Le détail complet se trouve sur la page tarifs, et si vous évaluez les prestataires plutôt que les moteurs, notre comparatif des render farms pour V-Ray présente ce qu'il faut rechercher.

FAQ

Q: Puis-je rendre V-Ray 6 sur un cloud render farm sans migrer vers V-Ray 7 ? A: Oui. Les scènes V-Ray 6 se renderisent via V-Ray Standalone depuis un .vrscene exporté, et il n'est pas nécessaire de migrer d'abord vers une version majeure plus récente. De nombreux pipelines de production restent délibérément sur V-Ray 6, et un render farm rend la version dans laquelle votre scène a été construite et validée.

Q: Dois-je acheter ma propre licence V-Ray pour le rendu cloud ? A: Non. Sur notre render farm, la licence de rendu V-Ray est incluse dans le tarif de rendu par unité, vous n'apportez donc pas de licence séparée et ne la payez pas pour rendre. C'est la différence entre un render farm entièrement géré et un modèle de location d'infrastructure, où vous loueriez des machines et fourniriez vos propres licences logicielles.

Q: V-Ray GPU ou V-Ray CPU — lequel utiliser sur un render farm ? A: Utilisez V-Ray GPU quand la géométrie et les textures de votre scène tiennent en VRAM et que vous souhaitez la vitesse pour les intérieurs ou l'itération ; utilisez V-Ray CPU quand la scène est grande et riche en textures ou nécessite le jeu de fonctionnalités le plus mature pour la livraison finale. Le CPU adresse la RAM système plutôt que la VRAM, il gère donc les grandes scènes archviz qui forcerait un GPU dans un pagination out-of-core plus lente.

Q: Comment éviter le scintillement GI dans une animation V-Ray 6 renderisée sur de nombreux nœuds ? A: Utilisez Brute Force GI avec un Light Cache par image comme valeur par défaut — il calcule l'éclairage indépendamment pour chaque image, les nœuds distribués ne divergent donc jamais. Réservez la méthode Irradiance Map pour les animations de caméra uniquement avec des lumières et des objets statiques, et assurez-vous que la carte précalculée se trouve sur un chemin partagé accessible à chaque nœud.

Q: Pourquoi mes ressources Chaos Cosmos manquent-elles quand les images reviennent du render farm ? A: Les ressources Cosmos sont référencées par des chemins locaux qui n'existent que dans votre propre cache, les nœuds de rendu ne peuvent donc pas les trouver et les objets se rendent en gris, manquants ou blancs sans erreur franche. Collectez et recheminez toutes les ressources dans un dossier de projet autonome avant de soumettre — les outils de collecte de ressources de V-Ray font cela — afin que la scène porte tout ce dont elle a besoin.

Q: Puis-je rendre une scène V-Ray for SketchUp sur le render farm ? A: Oui, via un export. SketchUp n'est pas une application hôte que nous exécutons, mais V-Ray for SketchUp peut exporter un .vrscene qui se rend directement sur V-Ray Standalone, ou vous pouvez importer le modèle dans 3ds Max et l'exporter depuis là. Le rendu se fait via la scène exportée d'un hôte supporté plutôt qu'à l'intérieur de SketchUp.

Q: Quelle est la différence entre un render farm et le Distributed Rendering de V-Ray ? A: Un render farm distribue des images entières sur de nombreuses machines, ce qui est le modèle efficace pour les animations et les séquences d'images. Le Distributed Rendering (DR) de V-Ray répartit plutôt les buckets d'une seule image entre des machines en temps réel — utile pour une très grande image héroïque, mais plus lent et plus fragile à grande échelle, et ce n'est pas ainsi que les séquences sont renderisées sur un render farm.