Configurer Blender pour le rendu cloud

Notre render farm exécute Blender avec Cycles (CPU et GPU/Optix) — le moteur de rendu de production que la plupart des jobs Blender utilisent — et supporte également Eevee sur nos nœuds GPU (voir la note Eevee dans les notes par moteur de rendu). Cette page couvre le packaging de projet — plus simple dans Blender que dans la plupart des DCC en raison de la gestion des chemins d'accès aux assets par Blender — les notes par moteur de rendu, le rendu d'animation multi-caméra et le dépannage spécifique à Blender.

Pour un positionnement général de Blender sur notre render farm — exemples de tarifs, choix GPU vs CPU, add-ons supportés — consultez l'article (l'article V-Ray inclut le contexte Blender). Pour des benchmarks GPU Cycles spécifiques sur RTX 5090, voir .

Versions supportées

Blender 4.0, 4.1, 4.2 (LTS), 4.3 et 4.4 sont préinstallés sur chaque worker. Nous recommandons les versions LTS de Blender pour les projets de production, car Blender 4.2 LTS reçoit des correctifs jusqu'en 2026 et constitue la cible stable pour la plupart des studios. La render farm détecte automatiquement la version correspondant à votre fichier .blend.

Une note sur le rythme des sorties Blender : Blender publie une version majeure tous les trois à quatre mois, plus une version LTS annuellement. Nous approvisionnons les nouvelles versions dans les deux semaines suivant leur disponibilité publique — le rythme de sorties de Blender est plus rapide que celui des DCC propriétaires, la render farm suit donc de près.

Packaging de votre projet Blender

Un projet Blender comprend le fichier .blend et tous les assets externes — textures, fichiers audio, caches de simulation, fichiers .blend de bibliothèque liés et HDRIs EXR pour l'éclairage d'environnement. La résolution des chemins dans Blender est plus souple que dans d'autres DCC (il utilise à la fois des chemins absolus et relatifs et effectue plusieurs recherches en cascade), mais pour le rendu cloud, vous devez regrouper tous les éléments dans un dossier de projet cohérent.

La méthode de packaging la plus simple est la fonctionnalité intégrée « Pack Into .blend » de Blender :

Ouvrez votre projet. File → External Data → Find Missing Files (pour vérifier qu'aucun fichier n'est déjà manquant en local).
Packez les assets dans le fichier .blend. File → External Data → Pack All Into .blend. Blender intègre toutes les textures, sons et images liées directement dans le fichier .blend.
Sauvegardez le projet. Le fichier .blend est désormais autonome — généralement 10 à 100 fois plus volumineux que l'original, selon le nombre de textures.
Uploadez le seul fichier .blend (aucune archive nécessaire si votre .blend fait moins de quelques Go ; pour les fichiers plus volumineux, compressez en .tar.gz ou .7z pour un upload plus rapide).

Une seconde méthode de packaging produisant un upload plus léger est « Make Paths Relative » + structuration manuelle du dossier :

File → External Data → Make All Paths Relative. Tous les chemins d'assets deviennent relatifs au répertoire du fichier .blend.
Vérifiez que chaque asset se résout correctement avec File → External Data → Report Missing Files. Le rapport ne doit indiquer aucun fichier manquant.
Placez tous les assets référencés dans des sous-dossiers relatifs au .blend. Structure standard : project/scene.blend avec project/textures/, project/cache/, project/hdr/, etc.
Archivez le dossier entier en .tar.gz ou .7z et uploadez.

La méthode par chemins relatifs est préférable pour les très grandes bibliothèques de textures (où Pack Into .blend produirait un fichier unique difficile à gérer) et pour les projets qui réutilisent la même bibliothèque de textures dans plusieurs scènes.

Ce qu'il faut vérifier avant la soumission

Une courte checklist de pré-vol :

Le moteur de rendu actif correspond à votre projet. Properties → Render Properties → Render Engine détermine si le worker utilise Cycles ou Eevee. Réglez Cycles pour un travail de production path-tracé ou Eevee pour un travail temps réel — les deux effectuent le rendu sur la render farm (voir les notes par moteur de rendu) ; Workbench est un moteur d'aperçu à ombrage solide que vous rendriez normalement en local. Assurez-vous qu'il correspond à l'intention de votre projet.
La plage de frames est définie. Properties → Output Properties → Frame Start / Frame End. La render farm respecte exactement cette plage.
Le chemin de sortie utilise des tokens relatifs. Le chemin par défaut //tmp/####.png convient ; le préfixe // signifie « relatif au fichier .blend ». Évitez les chemins de sortie absolus comme D:\renders\.
Le format de sortie correspond à votre pipeline en aval. Séquence PNG avec alpha pour le compositing, OpenEXR Multilayer pour la sortie complète des passes, vidéo FFmpeg pour la livraison directe. Pour le rendu d'animation, les séquences d'images sont fortement préférées à la sortie vidéo directe.
La gestion des couleurs est configurée. Properties → Render Properties → Color Management. Le réglage par défaut Filmic + affichage sRGB convient à la plupart des projets. Si votre projet utilise ACES ou une configuration OCIO personnalisée, incluez les fichiers de configuration OCIO dans votre dossier de projet et vérifiez que le chemin se résout correctement sur le worker.
La caméra active est définie. La caméra active de la scène (Properties → Scene Properties → Camera) détermine quelle caméra effectue le rendu. Assurez-vous qu'elle correspond à ce que vous attendez.

Notes par moteur de rendu

Cycles (CPU)

Cycles CPU s'exécute sur notre niveau de workers Dual Intel Xeon E5-2699 V4 (jusqu'à 256 Go de RAM par nœud). C'est le choix pour les scènes qui dépassent la VRAM GPU, les scènes avec de très grandes bibliothèques de textures, ou les projets nécessitant la sortie bit-perfect que produit Cycles CPU.

Notes de configuration :

Licence : Blender est gratuit et open source ; aucune contrainte de licence sur la render farm.
Échantillonnage : Cycles Render Properties → Sampling → Render Samples. L'échantillonnage adaptatif avec un seuil de bruit de 0,01 produit une sortie propre pour l'animation ; des seuils plus bas (0,005 ; 0,002) pour une qualité supérieure au détriment du temps de rendu.
Débruitage : Cycles supporte OpenImageDenoise (OIDN) et Optix (GPU uniquement). OIDN fonctionne sur CPU et donne de bons résultats pour les images fixes et l'animation ; à configurer dans Render Properties → Sampling → Denoise.
Arbre de lumières : Blender 3.4+ inclut l'échantillonnage par arbre de lumières pour les scènes avec de nombreuses sources lumineuses. À activer dans Render Properties → Sampling pour les scènes avec des centaines de sources lumineuses.

Cycles (GPU / Optix)

Cycles GPU s'exécute sur notre niveau de workers NVIDIA RTX 5090 (32 Go de VRAM par carte). Il est nettement plus rapide que Cycles CPU pour la plupart des scènes (généralement 5 à 15× plus rapide), en particulier pour les projets avec un lancer de rayons intensif.

Notes de configuration :

Dispositif : Properties → Render Properties → Device → GPU Compute. Le backend Optix (qui utilise les RT cores des GPU NVIDIA) est activé par défaut sur nos workers.
Contraintes VRAM : 32 Go de VRAM par worker suffisent pour la plupart des projets d'archviz et d'animation. Pour les projets approchant la limite VRAM, l'option « Persistent Data » dans Render Properties → Performance réduit les temps de chargement par frame mais augmente l'utilisation maximale de la VRAM. Pour les projets dépassant 32 Go, basculez sur Cycles CPU ou divisez la scène en parties rendables.
Débruiteur Optix : Plus rapide qu'OIDN pour l'animation. À configurer dans Render Properties → Sampling → Denoise → Use OptiX. Nécessite un GPU NVIDIA (que notre niveau de workers fournit).

Eevee (supporté, GPU)

Eevee effectue le rendu sur nos nœuds GPU — il est supporté. Eevee-Next (Blender 4.2+) effectue le rendu headless sur GPU, de sorte qu'un projet Eevee soumis à la render farm se rend de la même façon qu'un job Cycles : réglez le Render Engine sur Eevee, définissez votre plage de frames et soumettez.

La nuance honnête à connaître : Eevee est un moteur temps réel, et il est si rapide par frame sur un seul GPU moderne que les courtes séquences sont souvent plus rapides à rendre sur votre propre station de travail — un aller-retour vers la render farm est fréquemment inutile pour quelques frames Eevee. Là où la render farm justifie son utilisation avec Eevee, c'est à l'échelle : de larges plages de frames non surveillées, des scènes Eevee-Next qui prennent un temps réel par frame, ou simplement pour libérer votre propre GPU. Rendez donc les passes Eevee rapides en local lorsque c'est pratique, et envoyez Eevee à la render farm quand le batch est important, non surveillé, ou que le GPU de votre station de travail est occupé. Cycles reste le moteur autour duquel la plupart du travail de rendu Blender sur la render farm est construit ; Eevee est pleinement supporté à ses côtés.

Cycles CPU vs Cycles GPU — lequel choisir

Cycles GPU sur le niveau RTX 5090 est le choix par défaut : il est généralement 5 à 15× plus rapide par frame que Cycles CPU et gère la plupart des scènes d'archviz, d'animation et à lancer de rayons intensif dans sa VRAM de 32 Go. Choisissez Cycles CPU lorsqu'une scène dépasse 32 Go de VRAM, dépend de très grandes bibliothèques de textures, ou nécessite la sortie bit-perfect produite par le chemin CPU (jusqu'à 256 Go de RAM par nœud). Les deux produisent le même résultat Cycles physiquement précis — GPU termine plus vite par frame, CPU dispose d'un plafond mémoire plus élevé.

Rendu multi-angle caméra

Pour les projets nécessitant de rendre la même scène depuis plusieurs angles de caméra en une seule soumission, Blender supporte deux approches :

Approche 1 : plusieurs scènes avec différentes caméras actives

Blender permet plusieurs scènes par fichier .blend. Chaque scène peut avoir sa propre caméra active et ses propres réglages de rendu :

Dans votre projet, créez une nouvelle scène par angle de caméra (Scene → New Scene → Link Objects).
Définissez la caméra active de chaque scène sur la caméra correspondante.
Lors de la soumission, la render farm rend la scène définie comme « Active » au moment de la soumission. Pour rendre plusieurs scènes, soumettez chacune comme un job séparé.

Approche 2 : View Layer par caméra (Blender 2.8+)

Une approche plus efficace pour de nombreux angles de caméra consiste à utiliser des View Layers avec différentes caméras actives :

Dans Properties → View Layer, créez un View Layer par angle de caméra.
Dans Properties → Output Properties → Output → Use Multi-View, configurez la stéréo ou la multi-vue si applicable.
Configurez les chemins de sortie par View Layer en utilisant le token {layer} dans le nom du fichier de sortie.
Soumettez ; le worker rend tous les View Layers activés en une seule passe.

Pour les typiques travellings d'archviz (8 à 16 angles de caméra), l'approche 2 est nettement plus efficace car la scène se charge une seule fois par frame et rend toutes les vues depuis la même scène chargée.

Flux de soumission

Trois canaux de soumission fonctionnent pour les projets Blender :

Upload web + soumission via le tableau de bord. Uploadez le .blend packé (ou le dossier de projet archivé), puis soumettez via le site web. C'est la voie de soumission la plus courante pour les utilisateurs Blender.
Application client. Upload + soumission + téléchargement automatique en un seul outil.
Plugin de soumission. Un add-on Blender pour une soumission en un clic depuis Blender est disponible ; installez-le depuis votre tableau de bord de compte.

Pour le flux upload-soumission-téléchargement multi-DCC, voir le .

Dépannage des échecs spécifiques à Blender

Pour le dépannage général applicable à tous les DCC, voir . Cas spécifiques à Blender :

Certains objets de la scène ne se rendent pas. Cause la plus fréquente : le toggle « Render Visibility » de l'objet est désactivé. Dans l'outliner, survolez la ligne de l'objet et vérifiez que l'icône caméra (Disable in Renders) est activée. Vérifiez également que l'objet ne se trouve pas sur un View Layer masqué.
Textures manquantes malgré Pack Into .blend. Vérifiez que Pack All Into .blend a été exécuté après les dernières modifications de textures. Si vous avez rechargé des textures après le packaging, elles ont peut-être été réinitialisées en références externes. Repackez et resauvegardez.
Le rendu retourne une image noire ou aux couleurs incorrectes. Vérifiez les réglages de Color Management (Properties → Render Properties → Color Management). La cause la plus fréquente est une discordance de View Transform — assurez-vous que votre station de travail et le worker utilisent le même View Transform (Filmic est le choix par défaut et le plus sûr).
Le job Cycles GPU s'exécute sur CPU à la place. Vérifiez que Properties → Render Properties → Device est réglé sur GPU Compute, et non CPU. Vérifiez également que le backend Optix est sélectionné si votre scène nécessite l'accélération matérielle du lancer de rayons.
Le shader OSL personnalisé échoue au rendu. Cycles supporte OSL (Open Shading Language), mais les shaders OSL personnalisés doivent être inclus dans votre archive de projet. Les fichiers shader OSL (.osl) doivent se trouver à un emplacement accessible par le worker — le plus simple est de les placer dans le même dossier que le .blend et de les référencer par chemin relatif.
Add-on manquant sur le worker. Les add-ons courants (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids, etc.) peuvent ne pas être préinstallés. Pour Animation Nodes et les add-ons procéduraux similaires, la solution est de cuire (bake) la géométrie procédurale en meshes avant la soumission. Pour les autres add-ons, contactez le support pour discuter de leur ajout à l'image du worker.

Références croisées

— flux upload, soumission, téléchargement
— calcul du coût des jobs Blender
— guide SFTP, formats d'archive
— dépannage multi-DCC
— installation de l'add-on Blender
— article benchmark

FAQ

Q: Quelles versions de Blender la render farm supporte-t-elle ? A: Blender 4.0, 4.1, 4.2 LTS, 4.3 et 4.4 sont préinstallés sur chaque worker. Nous suivons le rythme des sorties de Blender et approvisionnons les nouvelles versions dans les deux semaines suivant leur disponibilité publique. Blender 4.2 LTS est le choix recommandé pour les projets de production car il reçoit des correctifs jusqu'en 2026. Q: Puis-je rendre des scènes Eevee sur la render farm ? A: Oui — Eevee effectue le rendu sur nos nœuds GPU (Eevee-Next fonctionne headless sur GPU), vous pouvez donc soumettre un projet Eevee de la même façon que vous soumettez un job Cycles. La nuance honnête : Eevee est si rapide par frame sur un seul GPU moderne que les courtes séquences sont souvent plus rapides à rendre en local — de nombreux artistes les gardent donc sur leur propre station de travail ; la render farm est la plus utile pour Eevee lorsque le batch est important et non surveillé, ou que votre propre GPU est occupé. Cycles reste le moteur principal pour la plupart du travail Blender ; pour Cycles, GPU sur notre parc RTX 5090 (avec le débruiteur Optix) est généralement 5 à 15× plus rapide que Cycles CPU, sauf si votre scène dépasse 32 Go de VRAM. Q: Ma scène utilise BlenderKit / Sverchok / Animation Nodes — sera-t-elle rendue ? A: Les assets BlenderKit que vous avez déjà téléchargés et sauvegardés dans le .blend se rendront correctement (ils deviennent des données de mesh standard une fois placés). Sverchok et Animation Nodes sont procéduraux — si la géométrie procédurale n'a pas été cuite en mesh statique, le worker peut produire un résultat inattendu. Cuisez la géométrie procédurale en meshes (Sverchok : Set/Bake to Mesh ; Animation Nodes : bake to action) avant la soumission. Q: Dois-je packer les textures dans le .blend, ou puis-je les uploader comme fichiers séparés ? A: Les deux fonctionnent. Pack Into .blend est la méthode la plus simple car le résultat est un fichier unique autonome. Les chemins relatifs + la structure de dossiers est préférable pour les très grandes bibliothèques de textures où Pack Into .blend produirait un fichier unique difficile à gérer. Assurez-vous d'exécuter « Find Missing Files » avant l'une ou l'autre approche pour confirmer qu'aucun fichier n'est manquant en local. Q: Mon rendu se termine mais les couleurs sont différentes de celles de ma fenêtre d'affichage locale. A: C'est le plus souvent une discordance de Color Management ou de View Transform. Vérifiez Properties → Render Properties → Color Management sur votre station de travail et confirmez que les réglages sauvegardés incluent View Transform : Filmic (le défaut). Les Look Transforms (contraste élevé, faible contraste, etc.) et les valeurs d'Exposure sont également intégrés dans le .blend et s'appliquent sur le worker. Q: Je rends une animation. Dois-je exporter vers un fichier vidéo ou une séquence d'images ? A: Séquence d'images, presque toujours. PNG avec alpha (pour le compositing) ou OpenEXR Multilayer (pour les passes complètes) est la norme. La sortie vidéo directe (FFmpeg) ne se parallélise pas bien sur la render farm — le worker qui reçoit le job rend toutes les images séquentiellement et encode un seul fichier vidéo. Les séquences d'images permettent à la render farm de distribuer les frames sur plusieurs workers en parallèle, ce qui est nettement plus rapide pour toute animation de plus d'environ 100 frames. Q: Mon projet utilise des shaders OSL personnalisés. Fonctionneront-ils sur la render farm ? A: Oui, si les fichiers shader .osl sont inclus dans votre archive de projet et référencés via des chemins relatifs dans les nœuds de shader. La méthode la plus simple est de placer tous les fichiers .osl dans le même dossier que votre fichier .blend. Q: Comment comparer le coût du rendu GPU vs CPU sur la render farm ? A: Le rendu GPU est généralement plus rapide par frame (5 à 15× pour Cycles), mais le coût par worker est plus élevé car les machines GPU sont coûteuses. Le coût total d'un rendu est globalement comparable entre Cycles CPU et Cycles GPU pour la plupart des scènes — GPU termine plus vite mais coûte plus par minute. Pour des estimations de coût spécifiques à votre scène, le fournit une comparaison par frame et par job. Q: Puis-je rendre des simulations Blender (fluide, fumée, cheveux) sur la render farm ? A: Pour les simulations, les fichiers de cache doivent être cuits en local d'abord, puis inclus dans votre upload de projet. La render farm rend les frames à partir du cache cuit ; elle n'exécute pas de simulation en temps réel. C'est la méthode standard pour tous les DCC — la cuisson des simulations est le travail de la station de travail, le rendu des frames est le travail de la render farm.

---

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