Corona Renderer sur les fermes de rendu : Guide complet de configuration

Introduction

Corona Renderer se distingue parmi les moteurs de rendu majeurs car il utilise le lancer de rayons basé CPU exclusivement — aucun chemin de rendu GPU. Cette architecture a des implications profondes pour le déploiement sur ferme de rendu. Sur les fermes traditionnelles construites pour V-Ray GPU, Corona nécessite un provisionning matériel différent, des modèles de licences différents, et des approches d'optimisation distinctes.

Nous sommes un partenaire officiel Chaos, supportant Corona aux côtés de V-Ray et Redshift sur notre ferme. L'accent mis par Corona sur le CPU signifie qu'il excelle dans les scénarios où la bande passante de la ferme GPU est limitée ou où les clients préfèrent la stabilité CPU. Au cours des trois dernières années, nous avons traité des milliers de jobs Corona et affiné les flux de travail qui maximisent l'efficacité de la ferme tout en minimisant les problèmes courants de déploiement.

Ce guide couvre l'architecture de Corona, la configuration du rendu distribué, la licences nœud, la préparation de scène, les erreurs courantes et leurs solutions, Corona vs V-Ray sur les fermes, et les techniques d'optimisation que nous utilisons pour maintenir les temps de rendu Corona compétitifs.

Comprendre l'architecture de rendu basée CPU de Corona

Corona Renderer produit des résultats photoréalistes via le lancer de rayons unidirectionnel — un seul rayon rebondit de la caméra à travers la scène, collectant des échantillons de lumière jusqu'à ce qu'il atteigne une source de lumière ou la limite de rebond. Ceci est différent du lancer de rayons bidirectionnel (approche de V-Ray) ou du rendu spectral (Arnold). La conception unidirectionnelle de Corona privilégie la vitesse et la cohérence. Pour la documentation technique, voir le manuel Corona Renderer.

Pourquoi CPU uniquement ? Le lancer de rayons CPU évite les limitations de mémoire GPU, permettant des fichiers de scène massifs. Une scène avec 500 millions de polygones ou 10 Go de textures s'adapte confortablement sur une machine CPU avec 128 Go de RAM. Le rendu GPU aurait du mal. Le CPU fournit aussi une précision numérique supérieure (virgule flottante 64 bits), cruciale pour la visualisation architecturale où les petits désalignements de surface importent.

Implications ferme : Les rendus Corona consomment beaucoup de CPU mais sont indulgents en mémoire. Un serveur Xeon monoprocesseur rend une scène complexe 4–8 fois plus rapide qu'une machine quad-GPU, mais consomme la même puissance. Notre ferme alloue des machines Xeon E5-2699 v4 à double processeur spécifiquement pour Corona — 44 cœurs par boîte, fonctionnant à 100 % d'utilisation pendant les rendus.

Réalité des licences : Corona utilise des licences verrouillées au nœud, ce qui signifie qu'une licence active un cœur CPU. Une machine 44 cœurs nécessite 44 licences Corona. C'est coûteux à grande échelle mais fournit une facturation de capacité précise et évite les frais de licence flottante. Pour les modèles de licences détaillés entre les moteurs de rendu, voir notre guide des licences nœud.

Configuration du rendu distribué dans Corona

Le rendu distribué Corona divise une image sur plusieurs machines, chacune rendant une tuile et retournant les résultats à la machine de soumission pour la composition. La configuration nécessite :

1. Machine de soumission (primaire) : Exécute Corona, soumet le job, et reçoit les résultats de tuiles.

2. Nœuds ferme (secondaires) : Exécutent Corona en mode sans interface, reçoivent les attributions de tuiles, et retournent les tuiles rendues.

3. Réseau : LAN rapide requis (gigabit minimum, 10 gigabit préféré). Corona transfère des tuiles sur le réseau, donc la latence et la bande passante comptent.

4. Stockage partagé : Les textures, fichiers cache, et actifs de projet doivent être accessibles depuis tous les nœuds. Nous utilisons un NAS 10 Gb monté via NFS sur tous les nœuds ferme.

Étapes de configuration :

Démarrer Corona → Render → Distributed Rendering Settings → Enable Distributed Mode → Configure Worker Machines (adresses IP ou noms d'hôte). Corona gère automatiquement la division de tuiles et la composition de résultats sur la machine primaire.

Si vous utilisez 3ds Max ou Cinema 4D avec Corona, le processus est similaire mais se trouve dans la boîte de dialogue des paramètres de rendu plutôt que dans l'interface utilisateur autonome de Corona.

Exigences du nœud worker : Chaque worker a besoin de la version exacte de Corona que la machine primaire. Les versions incompatibles causent des défaillances silencieuses de tuiles. Nous maintenons la cohérence des versions via le provisioning automatisé — les nouveaux nœuds workers téléchargent Corona depuis un référentiel central lors de l'initialisation.

Licences Corona pour les fermes de rendu

Les licences nœud Corona sont des abonnements perpétuels par cœur. Une licence active un cœur CPU pour le rendu. Contrairement au modèle de licence nœud de V-Ray (une licence par machine indépendamment du nombre de cœurs), Corona est granulaire.

Implications de coûts : Une machine 64 cœurs nécessite 64 licences Corona — coûteux mais transparent. Vous payez pour ce que vous utilisez. Nous avons calculé la licences Corona de notre ferme à environ 0,03–0,05 € par cœur de rendu par mois (basé sur notre accord de partenaire rendu Chaos), rendant les fermes 1 000 cœurs économiquement viables pour la production à haut volume.

Activation de licence : Les licences Corona sont verrouillées au nœud via l'adresse MAC système. Sur notre ferme, nous maintenons une base de données de licence mappant les adresses MAC aux clés de licence. Quand un worker démarre, il s'active automatiquement les licences lors de l'initialisation — critique pour les déploiements cloud élastiques.

Flottante vs verrouillée au nœud : Corona ne supporte pas les licences flottantes (contrairement à V-Ray). Chaque cœur obtient sa propre licence. Ceci simplifie la comptabilité mais nécessite une gestion d'inventaire soignée. Pour une comparaison entre les modèles de licences des moteurs de rendu, voir notre comparaison des licences Corona.

Chemins de mise à niveau : Corona maintient la compatibilité rétroactive dans les versions majeures (par ex., les moteurs Corona 11 peuvent fonctionner avec les scènes Corona 10). Cependant, les clés de licence sont verrouillées à la version. La mise à niveau de Corona 10 vers Corona 11 nécessite de nouvelles clés de licence pour tous les cœurs.

Sur notre ferme : Nous maintenons deux lots de licences — un ensemble primaire pour le rendu en production, un ensemble secondaire pour le développement et les tests. Ceci isole la production de l'expérimentation.

Préparation de scène et erreurs courantes de soumission ferme

Les scènes Corona échouent sur les fermes pour des raisons prévisibles. Notre liste de contrôle pré-soumission aborde toutes :

1. Chemins de texture : Assurez-vous que toutes les textures utilisent des chemins UNC absolus (par ex., \\\\farm-nas\\project\\textures\\wood.exr) ou des chemins relatifs dans la structure du projet. Corona ne cuit pas les textures dans le fichier de scène comme certains moteurs de rendu, donc les chemins manquants = textures manquantes au moment du rendu.

Nous avons créé un script « vérificateur de chemin » automatisé en MaxScript qui signale tout chemin de texture non-UNC avant la soumission. Ceci a éliminé environ 95 % des défaillances de ferme « texture manquante ».

2. Fichiers proxy : Corona supporte magnifiquement les proxies V-Ray (.vrmesh), mais les chemins proxy doivent être absolus. Nous convertissons les chemins relatifs (par ex., .\\proxies\\building.vrmesh) en chemins UNC complets avant la soumission.

3. Cartes HDR : Les cartes d'environnement (fichiers .hdr) doivent être accessibles depuis les nœuds workers. Même règle que les textures — chemins UNC absolus.

4. Plugins et extensions : L'écosystème de plugins Corona est petit. Si votre scène utilise un matériau tiers (par ex., Substance Designer à l'intérieur de 3ds Max), ce plugin doit exister sur les nœuds workers ou le matériau échouera à se charger silencieusement, se rendant en noir.

5. Scènes animées : Corona gère l'animation et le flou de mouvement efficacement, mais vérifiez la mise en cache de frames sur les nœuds workers. Certaines configurations mettent en cache les frames inutilement, gonflant l'utilisation NAS.

6. Disponibilité des licences : Vérifiez que votre nombre de licences Corona correspond au nombre de cœurs que vous demandez. Une scène soumise à 100 cœurs mais avec seulement 50 licences se rendra à 50 % de capacité silencieusement — pas de message d'erreur. Nous avons ajouté des vérifications de quota à notre tableau de bord ferme pour éviter ceci.

Dépannage des erreurs courantes

Erreur	Cause	Solution
Le rendu retourne des pixels noirs ou tout noir	Plugin ou matériau manquant	Vérifiez les définitions de matériau dans la scène ; vérifiez la disponibilité du plugin sur la ferme
Les tuiles ne se composent pas correctement	Incompatibilité de version entre primaire et worker	Mettez à jour tous les workers vers la version Corona correspondant à la machine primaire
Le rendu est extrêmement lent (environ 100 fois plus lent qu'attendu)	Rendu en mode interactif au lieu de distribué	Vérifiez que les paramètres de rendu distribué sont activés et les workers enregistrés
Certaines tuiles échouent ; d'autres réussissent	Timeout réseau récupérant les textures	Déplacez les textures vers un volume NAS local accessible via NFS ; augmentez le timeout réseau dans les paramètres Corona
L'activation de licence échoue sur le worker	Incompatibilité d'adresse MAC ou clé de licence expirée	Vérifiez l'adresse MAC dans la base de données de licence ; renouvelez la licence si expirée
Bruit/artefacts apparaissent de manière incohérente	Corruption du cache worker	Effacez C:\\ProgramData\\Corona\\Cache sur tous les workers ; resoumettez

Corona vs V-Ray sur les fermes de rendu : Quand utiliser chacun

Avantages de Corona :

• Support de scène massive (500 M+ polygones, 10 Go+ textures)
• Sortie cohérente et propre avec moins d'artefacts à gérer
• Qualité excellente pour la visualisation architecturale et produit
• CPU uniquement signifie mise à l'échelle prévisible (plus de cœurs = plus rapide)

Pour plus de détails sur la configuration de Corona sur notre ferme, voir notre page de destination ferme Corona.

Faiblesses de Corona :

• CPU uniquement (pas de chemin GPU), donc plus lent par cœur que V-Ray GPU
• Licences plus coûteuses (par cœur, pas par machine)
• Écosystème de plugins plus petit que V-Ray

Avantages de V-Ray :

• Rendu GPU (cartes RTX) — rapide pour les scènes complexes
• Rendu distribué, réseau bien établis
• Écosystème plus large et support tiers

Faiblesses de V-Ray :

• Les limites de mémoire GPU les scènes à environ 50–100 Go de budgets texture
• Compétition de ressources GPU — une scène lourde affame les autres

Notre cadre décisionnel :

• Corona pour : Archviz (>200 M polys), visualisation produit, travail studio avec d'énormes bibliothèques d'actifs
• V-Ray pour : Délai plus court, GPU disponible, rendu animation (fermes de frames)
• Les deux : Charges de travail mixtes à haut volume — répartis entre pools Corona et V-Ray

Techniques d'optimisation pour le rendu Corona distribué

1. Accord de taille de tuile : Corona divise les images en tuiles (32x32 pixels par défaut). Les tuiles plus petites = distribution plus fine-grained mais plus de surcharge réseau. Les tuiles plus grandes = moins de trajets réseau mais charge déséquilibrée si une tuile est plus difficile. Nous utilisons généralement 64x64 pour la sortie 4K, 128x128 pour la 8K.

2. Rendu multi-passes : Corona supporte la division d'une image en plusieurs passes (lumière directe, indirecte, AO, etc.), rendant chacune indépendamment. Ceci est plus rapide que le rendu simple-pass et permet la flexibilité de composition. Notre ferme rend tous les jobs Corona comme multi-passes par défaut.

3. Bande passante mémoire : Le rendu CPU de Corona est limité par la mémoire, pas par le CPU. Les machines à double processeur avec fréquence RAM maximisée (3 200 MHz+) se rendent environ 20 % plus rapides que la RAM standard. Nous spécifions la mémoire haute fréquence dans le matériel Corona-dédié.

4. Localité de cache : Corona bénéficie du cache L3 CPU. Les machines avec des caches plus grands (comme l'E5-2699 v4 avec 55 Mo L3) se rendent 10–15 % plus rapides. Lors du provisioning de capacité Corona, prioritéisez le cache CPU sur la vitesse d'horloge.

5. Optimisation réseau : 10 Gb LAN vaut l'investissement pour les fermes Corona. Les LAN gigabit deviennent des goulots d'étranglement au-dessus de 20 rendus Corona concurrents. Nous avons documenté ceci ; les fermes avec infrastructure 10 Gb voient un transfert de tuiles 25–30 % plus rapide.

6. Pré-traitement de scène : Avant la soumission ferme, utilisez Corona « Preprocess for distributed rendering » intégré qui cache la géométrie, les matériaux, et les textures localement. Ceci réduit le trafic réseau pendant le rendu réel.

Déploiement à l'échelle : Notre architecture de ferme

Notre configuration Corona s'étend sur 12 machines Xeon à double processeur (528 cœurs totaux, environ 480 utilisables après surcharge). Cette configuration :

• Gère 100–200 jobs Corona concurrents selon la complexité de la scène
• Rend des images 3–5 minutes (archviz 4K typique + GI lourd) en 20–30 minutes
• Coûte environ 6 000–8 000 € par mois en électricité, maintenance, et licences
• Génère environ 15 000–20 000 € de revenus mensuels, donnant un ROI 2,5x dans 18 mois du déploiement matériel

Pour les studios envisageant des fermes Corona sur site, cette échelle est le point d'équilibre. En dessous de 300 cœurs, le rendu cloud (AWS, Google Cloud) est plus rentable. Au-dessus de 500 cœurs, l'on-site se met à l'échelle mieux.

Super Renders Farm est une ferme de rendu cloud et partenaire officiel de rendu Chaos.

FAQ

Puis-je utiliser Corona avec V-Ray dans la même scène ?

Non. Une scène se rend avec un moteur. Cependant, vous pouvez rendre deux passes (une Corona, une V-Ray) et composer en post-production. Nous ne recommandons pas ceci en raison de la complexité, mais c'est techniquement possible.

Corona supporte-t-il le rendu distribué imbriqué (ferme → sous-ferme) ?

Non. Le mode distribué Corona s'attend à une machine primaire et des machines workers sur un réseau plat. La délégation imbriquée n'est pas supportée. Les scènes complexes sont gérées en mettant à l'échelle une seule ferme, non en fédérant des fermes.

Quel est la surcharge typique pour le rendu distribué ?

La surcharge réseau et composition de tuiles est 5–15 %, selon la taille de tuile et la latence réseau. Un rendu single-machine 1 minute pourrait prendre 65–75 secondes distribué sur 8 machines (1 minute ÷ 8 machines = 7,5 secondes, plus 5–15 % surcharge). La mise à l'échelle se décompose au-dessus d'environ 50 machines en raison de la surcharge de composition.

Puis-je rendre Corona sur internet vers des fermes distantes ?

Techniquement oui, mais la latence réseau le rend impractique. 100 ms de latence → délais visibles dans le transfert de tuiles. Nous recommandons les LAN gigabit locaux. Pour le rendu distant, utilisez les services cloud (Chaos Cloud, AWS, Google Cloud) avec réseau optimisé.

La licence Corona nécessite-t-elle la connectivité internet ?

Non. Les licences Corona sont verrouillées au nœud via l'adresse MAC. Une fois activées, elles fonctionnent hors ligne. C'est idéal pour les studios sécurisés sans accès internet. Les clés de licence sont perpétuelles — pas de renouvellement d'abonnement.

Corona peut-il reprendre le rendu si un worker plante au milieu d'une tuile ?

Non. Le rendu distribué redémarre le job entier si un worker échoue. C'est pourquoi le monitoring matériel et réseau robuste est critique. Un worker qui plante au milieu du rendu gaspille le temps de calcul. Nous maintenons 99,5 % de disponibilité worker via le monitoring proactif du matériel et la gestion thermique.

Comment gère-t-on les itérations de scène Corona sur une ferme ?

Utilisez le versioning. Chaque itération est un fichier séparé (scene_v01.max, scene_v02.max). Les soumissions ferme sont liées aux versions de fichier, permettant le suivi et le re-rendu des itérations spécifiques. Nous maintenons une base de données de fichier mappant les IDs de job aux versions de scène.

Le format de sortie de Corona est-il flexible pour la composition en aval ?

Oui. Corona peut se rendre en OpenEXR avec des passes arbitraires (directe, indirecte, spéculaire, diffuse, ombres, etc.), permettant la flexibilité de composition complète. Nous rendons multi-passes OpenEXR par défaut, permettant à la post-production d'ajuster l'éclairage, les matériaux, et les effets sans re-rendu.

Quelle est la taille de scène maximale que Corona peut gérer ?

Théoriquement illimitée, limitée seulement par la RAM disponible. Nous avons rendu des fichiers de scène 3 Go (1 B+ polygones, 50 Go de bibliothèque de textures) sans problème sur des machines 256 Go RAM. Au-delà, nous diviseriions la scène et composerions en post-production.

Comment Corona gère-t-il le flou de mouvement et la profondeur de champ sur les fermes ?

Les deux sont calculés pendant l'échantillonnage — pas de post-traitement séparé. Le flou de mouvement est légèrement plus lent en raison des casts de rayons supplémentaires, mais la profondeur de champ a une surcharge minimale. Les deux fonctionnent identiquement sur les fermes que sur les machines locales.