Configurer Blender pour le rendu cloud

Blender sur notre render farm exécute Cycles (CPU et GPU avec Optix) et Eevee Next — les deux moteurs de rendu de production livrés avec Blender 4.x. Comparé aux DCCs propriétaires, Blender est inhabituel d'une manière utile : un fichier .blend peut être rendu entièrement auto-contenu depuis l'application, donc le packaging pour une render farm est souvent une seule action de menu plutôt qu'une chasse aux assets manuelle. Cette page parcourt ce flux de bout en bout : packaging, vérification pré-soumission, notes par moteur de rendu pour Cycles CPU / Cycles GPU / Eevee Next, rendu d'animation multi-caméra, les trois canaux de soumission, et le dépannage spécifique à Blender. Les échecs inter-DCC sont couverts dans .

Pour des exemples de tarification et le choix GPU vs CPU sur notre render farm, voir . Pour les benchmarks Cycles GPU sur le parc 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. La render farm fait correspondre automatiquement la version sauvegardée de votre fichier .blend — il n'y a pas de sélecteur de version à gérer ; le worker lit l'en-tête du fichier et lance le binaire correspondant.

Blender livre une version majeure tous les trois à quatre mois plus une version LTS annuellement. Les nouvelles versions sont approvisionnées dans environ deux semaines suivant leur disponibilité publique. Nous recommandons Blender 4.2 LTS pour le travail de production puisqu'il reçoit des corrections de bugs jusqu'en 2026 et constitue la cible stable pour la plupart des studios.

Les fichiers sauvegardés en Blender 3.x s'ouvriront sur les workers 4.x, mais deux cas nécessitent attention : les rendus Eevee Legacy peuvent ne pas correspondre à la sortie d'Eevee Next (voir la section Eevee Next), et les très vieux fichiers 2.7x / 2.8x devraient être ouverts localement, re-sauvegardés en 4.x, et re-testés avant la soumission. Si vous devez rendre un vieux projet, sauvegardez d'abord une copie verrouillée sur une version ; la render farm ne peut pas rétrograder une sauvegarde 4.x.

Packager votre projet Blender

Un projet Blender est le fichier .blend plus tout asset externe — textures, fichiers son, caches de simulation, fichiers de bibliothèque .blend liés, profils de lumière IES, fichiers de config OCIO, HDRIs EXR, et tout fichier de shader .osl. La résolution de chemins de Blender est plus tolérante que celle des autres DCCs, mais pour le rendu cloud cette tolérance mord : un chemin qui se résout sur votre station de travail via la logique de repli de Blender peut ne pas se résoudre de la même manière sur un worker, et le résultat est des placeholders roses de texture manquante.

Trois schémas de packaging sont supportés. Choisissez celui qui correspond à la taille de votre projet et à la fréquence à laquelle vous réutilisez les assets entre les scènes.

Schéma 1 — Pack Resources (recommandé pour la plupart des projets)

La fonctionnalité intégrée « Pack Resources » de Blender embarque toutes les données externes dans le .blend lui-même, produisant un seul fichier auto-contenu.

File → External Data → Find Missing Files. Parcourt le projet et signale les références non résolues ; corrigez tout ce qui est cassé localement d'abord.
File → External Data → Pack Resources. Blender embarque toutes les textures, sons, profils IES et images liées dans le .blend.
Sauvegardez le projet. Le .blend packagé est maintenant auto-contenu — attendez-vous à ce qu'il grossisse 10× à 100× selon le nombre et la résolution des textures.
Uploadez le .blend unique. Aucune archive nécessaire à moins que le fichier ne soit assez gros pour que la compression (.tar.gz ou .7z) accélère l'upload — typiquement au-delà de quelques Go.

Schéma 2 — Make Paths Relative + structure de dossiers (pour les grandes bibliothèques de textures)

Pour les projets où Pack Resources produirait un seul fichier ingérable, le schéma des chemins relatifs garde le .blend petit et expédie les assets sous forme de dossiers à côté.

File → External Data → Make All Paths Relative. Tous les chemins d'assets deviennent relatifs au répertoire du .blend (préfixe de chemin //).
File → External Data → Report Missing Files. Devrait n'afficher rien. Corrigez tout ce qui est signalé avant de continuer.
Placez tous les assets référencés dans des sous-dossiers relatifs au .blend. Structure standard : project/scene.blend plus project/textures/, project/cache/, project/hdr/, project/osl/, project/lib/. Évitez les espaces dans les noms de dossiers.
Archivez l'intégralité du dossier de projet en .tar.gz ou .7z et uploadez l'archive.

Schéma 3 — Bibliothèques liées (avancé ; studios avec des bibliothèques d'assets partagées)

Blender supporte le liaison de bibliothèques, où un fichier .blend référence des objets, matériaux ou scènes depuis un autre .blend. C'est courant dans les studios avec des bibliothèques d'assets partagées (props, personnages, matériaux) :

Rendez d'abord les chemins relatifs (étape 1 du schéma 2).
Vérifiez que chaque lien de bibliothèque se résout localement via File → External Data → Find Missing Files.
Incluez chaque .blend de bibliothèque liée dans l'archive. Une référence comme //../shared/props/chair.blend ne se résout que si le fichier existe à ce chemin sur le worker. Testez localement en déplaçant votre dossier de projet complet vers un nouvel emplacement et en ouvrant la scène master — si elle s'ouvre proprement, les mêmes chemins se résolvent sur le worker.
Envisagez de rendre les bibliothèques locales pour les jobs de longue durée. File → External Data → Make Library Override convertit les références en copies modifiables à l'intérieur du .blend, échangeant la taille de fichier contre l'auto-confinement.

Ce qu'il faut vérifier avant la soumission

Une courte checklist de pré-vol s'applique avant toute soumission :

Le moteur de rendu actif est défini. Properties → Render Properties → Render Engine — Cycles, Eevee Next ou Workbench. Le worker honore ce que vous sauvegardez.
L'intervalle de frames est défini. Properties → Output Properties → Frame Start / Frame End. La render farm respecte cet intervalle exactement.
Le chemin de sortie utilise des tokens relatifs. Le défaut //tmp/####.png convient ; le préfixe // signifie « relatif au fichier .blend ». Évitez les chemins absolus comme D:\renders\ — ceux-ci ne peuvent pas se résoudre sur des workers Linux.
Le format de sortie correspond à votre pipeline en aval. Séquence PNG avec alpha pour le compositing, OpenEXR Multilayer pour la sortie de passes complètes. Pour l'animation, les séquences d'images sont fortement préférées à la sortie vidéo directe (voir la FAQ Multi-caméra).
La gestion des couleurs est définie. Properties → Render Properties → Color Management. Le défaut Filmic + sRGB fonctionne pour la plupart des projets. Pour ACES ou une config OCIO personnalisée, incluez les fichiers de config OCIO dans votre dossier de projet.
La caméra active est définie. La caméra active de la scène (Properties → Scene Properties → Camera) détermine quelle caméra se rend. « Mauvaise caméra rendue » figure parmi les tickets de support Blender les plus courants et l'un des plus simples à prévenir.
Les caches de simulation sont bakés. Les simulations de fluides, fumée, tissu, cheveux et soft-body doivent être bakées localement d'abord ; la render farm rend contre le cache baké et n'exécute pas de simulation en direct. Incluez le dossier de cache dans l'upload.
Les light probes sont bakées. Les probes Eevee Next — Irradiance Volume, Reflection Plane, Reflection Cube — doivent être bakées localement et les données bakées sauvegardées avec le .blend (Render Properties → Light Probes → Bake Indirect Lighting). Les probes non bakées produisent un éclairage indirect plat ou manquant.

Notes spécifiques par moteur de rendu

Cycles (CPU)

Cycles CPU s'exécute sur notre tier 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 projets avec de très grandes bibliothèques de textures, ou les scènes qui utilisent des fonctionnalités pas encore supportées sur le backend GPU.

Licence : Blender est gratuit et open source ; rien à autoriser, aucune licence à consommer.
Échantillonnage : Render Properties → Sampling → Render Samples. L'Adaptive Sampling avec Noise Threshold 0.01 est un bon défaut pour l'animation ; des seuils plus bas (0.005, 0.002) pour une qualité supérieure au prix du temps de rendu. La Time Limit (par frame) est une garde utile pour le travail d'animation.
Denoising : Cycles supporte OpenImageDenoise (OIDN) et Optix (GPU uniquement). OIDN s'exécute sur CPU et produit de bons résultats pour les images fixes et les animations ; configurez dans Render Properties → Sampling → Denoise. Pour l'animation, activez le denoising temporel (OIDN 2.x dans Blender 4.2+) pour réduire le scintillement d'une frame à l'autre.
Light tree : Blender 3.4+ inclut l'échantillonnage Light Tree pour les scènes à nombreuses lumières. Activez dans Render Properties → Sampling → Light Tree pour les intérieurs archviz ou l'éclairage de scène avec des centaines de sources lumineuses.

Cycles (GPU / Optix)

Cycles GPU s'exécute sur notre tier de workers NVIDIA RTX 5090 (32 Go de VRAM par carte). Il est typiquement 5 à 15× plus rapide par frame que Cycles CPU pour l'archviz et l'animation, et davantage pour les plans VFX path-traced lourds en volumétrie et SSS.

Device : Properties → Render Properties → Device → GPU Compute. Le backend Optix (cœurs RT sur les GPUs NVIDIA) est activé par défaut sur nos workers.
VRAM : 32 Go par worker suffit pour la plupart des projets archviz, motion design et animation avec plusieurs textures 4K. Pour les projets approchant la limite, « Persistent Data » dans Render Properties → Performance réduit le temps de chargement par frame au prix d'une VRAM de pic légèrement plus élevée. Pour les projets dépassant 32 Go, basculez sur Cycles CPU sur le tier Xeon ou découpez la scène.
Denoiser Optix : Plus rapide qu'OIDN pour l'animation et le choix standard sur GPU. Configurez dans Render Properties → Sampling → Denoise → Use OptiX. Pour les images fixes statiques, OIDN produit souvent une sortie légèrement plus propre ; pour l'animation, le mode temporel d'Optix est généralement le meilleur compromis.
Parité de fonctionnalités : Cheveux, volumes, SSS, OSL (4.0+, avec exigences matérielles), Adaptive Subdivision — tous supportés sur Cycles GPU en 4.x. L'écart de fonctionnalités CPU/GPU est essentiellement comblé.

Eevee Next

Eevee Next s'exécute sur notre tier de workers GPU. C'est le choix pour le motion design, les rendus stylisés, l'itération rapide et la previz où le budget par frame compte plus que la fidélité absolue.

Échantillonnage et reflets : Render Properties → Sampling contrôle le nombre d'échantillons par pixel. Pour les rendus finaux, 64 à 128 échantillons produisent typiquement une sortie propre. Les light probes, les reflets en espace écran et les réfractions en espace écran doivent être bakées ou configurées par plan.
Eevee Next vs Eevee Legacy : Blender 4.2+ livre Eevee Next comme nouvelle architecture (nom interne BLENDER_EEVEE_NEXT vs le BLENDER_EEVEE hérité). Les anciens projets 3.x utilisant Eevee Legacy peuvent nécessiter un ajustement lors de la migration ; testez une seule frame localement avant de soumettre une animation.
Volumétrie : Le pipeline volumétrique d'Eevee Next diffère significativement de la version héritée. Les volumes qui se rendaient correctement en Eevee Legacy peuvent montrer des différences de densité ou de diffusion. Vérifiez localement avant de soumettre.
Bake de light probes : Critique et la source du ticket de support Eevee le plus courant. Render Properties → Light Probes → Bake Indirect Lighting. Bakez localement, sauvegardez, et les données bakées voyagent avec le fichier. Les probes non bakées produisent un éclairage indirect plat ou manquant.

Workbench

Workbench est le moteur de rendu de la fenêtre de visualisation de Blender, utile pour les frames de prévisualisation technique (passes d'ID mat, tour de potier en argile, prévisualisation AO). S'exécute sur des workers CPU ou GPU ; soumettez de la même manière que Cycles ou Eevee, avec Render Engine défini sur Workbench avant la sauvegarde.

Comparaison rapide Cycles GPU vs Eevee Next

| Préoccupation | Cycles GPU | Eevee Next | |---|---|---| | Vitesse de rendu (scène typique) | Plus lent par frame, physiquement précis | Plus rapide par frame, dérivé temps réel | | Photoréalisme | Plus élevé | Plus bas (mais s'améliorant à chaque version) | | Scintillement d'animation | Faible (avec le mode temporel du denoiser Optix) | Peut être plus élevé ; nécessite le bake des probes | | Contrainte VRAM | Limite dure de 32 Go ; repli sur CPU | 32 Go mais usage typiquement plus faible | | Qualité volumétrie | Path-traced, précis | Approximatif ; vérifier localement avant de soumettre | | Idéal pour | Archviz, VFX, animation photoréaliste | Motion design, stylisé, itération rapide |

Rendu multi-caméra

Pour les projets qui ont besoin de rendre la même scène depuis plusieurs angles de caméra en une seule soumission, Blender supporte plusieurs schémas. Choisissez selon la relation entre les angles.

Schéma A — Plusieurs scènes avec différentes caméras actives

Blender permet plusieurs scènes par .blend, chacune avec sa propre caméra active et ses propres paramètres de rendu :

Créez une nouvelle scène par angle de caméra (Scene → New Scene → Link Objects partage les données pour que les modifications se propagent).
Définissez la caméra active de chaque scène.
À la soumission, la render farm rend la scène marquée comme Active au moment de la sauvegarde. Pour rendre plusieurs scènes, soumettez chacune comme un job séparé.

Le schéma A est le bon choix lorsque les angles ont besoin d'un échantillonnage, de formats de sortie ou de résolutions différents.

Schéma B — View Layer par caméra (Blender 2.8+)

Pour de nombreux angles de caméra qui partagent les paramètres de rendu, utilisez des View Layers chacun avec une caméra active différente :

Dans Properties → View Layer, créez un View Layer par angle de caméra.
Liez la caméra de chaque View Layer via une propriété Camera sur le layer (ou pilotez la caméra active dans le Compositor).
Configurez les chemins de sortie par View Layer en utilisant le token {layer} dans le nom de fichier de sortie.
Soumettez ; le worker rend tous les View Layers activés en une seule passe.

Pour les tours de potier archviz typiques (8 à 16 angles de caméra), le schéma B est plus efficace parce que la scène se charge une seule fois et toutes les vues se rendent depuis le même état chargé. Un seul job multi-caméra qui produit N séquences de sortie coûte moins que N jobs caméra unique.

Schéma C — Multi-sortie via le Compositor (avancé)

Pour le post-traitement par caméra complexe, le Compositor peut router le rendu de chaque caméra vers un nœud File Output différent. Même schéma que les exports d'AOV multi-couches. Utilisez le schéma B sauf si vous avez une vraie raison de post-traitement de recourir au Compositor.

Flux de soumission

Trois canaux de soumission fonctionnent pour les projets Blender. Choisissez celui qui correspond à votre flux de travail.

Upload web + soumission via le dashboard. Uploadez le .blend packagé (ou le dossier de projet archivé) vers votre compte, puis soumettez via le dashboard. Le dashboard lit l'en-tête du .blend pour détecter la version Blender, le moteur de rendu, l'intervalle de frames et la caméra active, et pré-remplit le formulaire de soumission. Confirmez ou remplacez, soumettez, surveillez.
Client App. La Client App (Windows / macOS) enveloppe upload + soumission + téléchargement automatique. Après installation, glissez le .blend ou l'archive sur l'app, confirmez le formulaire de soumission, et l'app gère l'upload, le suivi de progression et le téléchargement des frames au fur et à mesure de leur achèvement.
Plugin de soumission (add-on Blender). Un add-on Blender pour la soumission dans l'app est disponible ; installez depuis le dashboard de votre compte. Le plugin lit les paramètres de rendu de la scène actuelle, propose des overrides (intervalle de frames, chemin de sortie, résolution), et soumet sans quitter Blender.

Pour le flux upload-soumission-téléchargement inter-DCC, voir . Pour les étapes d'installation du plugin, voir .

Dépannage des échecs spécifiques à Blender

Pour le dépannage général qui s'applique à tous les DCCs (asset manquant, incompatibilité d'intervalle de frames, erreurs de chemin de sortie), voir . Les cas ci-dessous sont spécifiques à Blender.

Certains objets de la scène ne se rendent pas. Cause la plus fréquente : la « Render Visibility » de l'objet (icône caméra dans l'outliner) est désactivée. Vérifiez également que l'objet n'est pas sur un View Layer caché, et vérifiez Object Properties → Visibility → flags Ray Visibility (camera, diffuse, glossy, transmission, volume, shadow).
Textures manquantes malgré Pack Resources. Vérifiez que Pack Resources a été exécuté après les derniers changements de textures. Si vous avez rechargé les textures après le packaging, elles peuvent être revenues à des références externes. Re-packagez et re-sauvegardez.
Le rendu retourne du noir ou une mauvaise couleur. Habituellement une incompatibilité de View Transform. Confirmez que Properties → Render Properties → Color Management utilise View Transform : Filmic (le défaut) à la fois sur votre station de travail et dans le fichier sauvegardé. Les Look Transforms et valeurs d'Exposure sont embarqués dans le .blend et s'appliquent sur le worker.
Les light probes Eevee Next ne se bakent pas sur le worker. Le worker ne bake pas ; les probes doivent être bakées localement et sauvegardées avec le .blend. Render Properties → Light Probes → Bake Indirect Lighting, sauvegardez, uploadez.
Le job Cycles GPU s'exécute sur CPU à la place. Vérifiez que Properties → Render Properties → Device est défini sur GPU Compute. Si le fichier a été créé sur une station de travail sans GPU NVIDIA, la valeur Device sauvegardée peut par défaut être CPU.
Un shader OSL personnalisé échoue au rendu. Cycles supporte OSL, mais les fichiers .osl doivent être inclus dans l'archive et référencés par chemin relatif. Placez-les dans le même dossier que le .blend. OSL sur GPU a des exigences matérielles qui peuvent ne pas correspondre à chaque shader ; si un shader fonctionne sur CPU mais pas sur GPU, rendez cette scène sur le tier CPU.
Référence de bibliothèque liée cassée. Une bibliothèque liée ne se résout que si le .blend lié est présent au chemin attendu sur le worker. Utilisez le schéma 2 de packaging et incluez chaque bibliothèque liée dans l'archive. Lancez File → External Data → Find Missing Files localement avant l'upload.
Add-on manquant sur le worker. Les add-ons courants (Animation Nodes, BlenderKit, Sverchok, FLIP Fluids) peuvent ne pas tous être pré-installés. Pour les add-ons procéduraux, bakez la géométrie en meshes statiques avant la soumission (Sverchok : Set/Bake to Mesh ; Animation Nodes : bake to action ; Geometry Nodes : Apply modifier). Pour les autres add-ons, contactez le support à propos de leur ajout à l'image du worker.
L'animation scintille (Cycles). Habituellement une variation de bruit d'une frame à l'autre. Augmentez les échantillons, abaissez le seuil de bruit Adaptive Sampling, activez le denoising temporel (OIDN 2.x ou Optix). Confirmez que le mode de graine aléatoire (Render Properties → Sampling → Advanced → Seed) correspond à l'intention de votre projet — Animated pour une variation naturelle, fixe pour une sortie bit-stable.
L'animation scintille (Eevee Next). Presque toujours des light probes non bakées ou obsolètes. Re-bakez Indirect Lighting, sauvegardez, re-uploadez. Les reflets en espace écran qui dépendent de l'état de la fenêtre de visualisation peuvent aussi scintiller — privilégiez les Reflection Probes pour des reflets propres.

Références croisées

— flux upload, soumission, téléchargement qui s'applique à tous les DCCs
— comment les coûts des jobs Blender sont calculés, modèle de tarification GHz-hour
— guide SFTP, formats d'archive, transfert de gros fichiers
— dépannage inter-DCC (asset manquant, intervalle de frames, chemin de sortie, dérive de gestion des couleurs)
— installation de l'add-on Blender pour la soumission dans l'app
— wrapper desktop pour upload + soumission + téléchargement
— flux de soumission via le dashboard
— article de benchmark incluant les chiffres Cycles GPU
— article de comparaison avec une section contexte Blender

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 de sorties de Blender et approvisionnons les nouvelles versions dans environ deux semaines suivant leur disponibilité publique. Blender 4.2 LTS est le choix recommandé pour le travail de production parce qu'il reçoit des corrections de bugs jusqu'en 2026. La render farm fait correspondre automatiquement la version sauvegardée de votre fichier .blend — vous ne sélectionnez pas une version au moment de la soumission.

Q : Dois-je rendre avec Cycles ou Eevee Next ? A : Cycles pour l'archviz photoréaliste, la VFX et l'animation où le transport de lumière physiquement précis importe. Eevee Next pour le motion design, le travail stylisé, l'itération rapide et la previz où le coût par frame importe plus que la fidélité absolue. Cycles GPU sur notre parc RTX 5090 est typiquement 5 à 15× plus rapide par frame que Cycles CPU pour la même scène, donc le GPU est la recommandation Cycles par défaut sauf si votre scène dépasse 32 Go de VRAM ou utilise des fonctionnalités qui nécessitent le backend CPU.

Q : Ma scène utilise des assets BlenderKit / Sverchok / Animation Nodes / Geometry Nodes — se rendra-t-elle ? A : Les assets BlenderKit que vous avez déjà téléchargés et sauvegardés dans le .blend se rendent bien — une fois placés, ils deviennent des données de mesh standard. Sverchok et Animation Nodes sont procéduraux ; si la géométrie procédurale n'a pas été bakée en mesh statique, le worker peut produire une sortie inattendue. Bakez la géométrie procédurale en meshes (Sverchok : Set/Bake to Mesh ; Animation Nodes : bake to action ; Geometry Nodes : Apply modifier sur l'arbre de nœuds résultant) avant la soumission. Les Geometry Nodes qui se résolvent au moment du rendu sans bake fonctionnent généralement, mais testez une seule frame localement d'abord.

Q : Dois-je packager les textures dans le .blend, ou puis-je les uploader comme fichiers séparés ? A : Les deux schémas fonctionnent. Pack Resources est le plus simple parce que le résultat est un seul fichier auto-contenu. Le schéma chemins-relatifs + structure de dossiers est préférable pour les très grandes bibliothèques de textures et les projets qui partagent une bibliothèque de textures entre scènes. Lancez Find Missing Files avant l'une ou l'autre approche pour confirmer que rien n'est cassé localement.

Q : Mon rendu se termine mais les couleurs semblent différentes de la fenêtre de visualisation de ma station de travail. A : Le plus souvent, c'est une incompatibilité de View Transform. Confirmez que Properties → Render Properties → Color Management utilise View Transform : Filmic (le défaut) à la fois sur votre station de travail et dans le fichier sauvegardé. Les Look Transforms et valeurs d'Exposure sont également embarqués dans le .blend et s'appliquent sur le worker.

Q : Je rends une animation. Dois-je sortir en fichier vidéo ou en 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 le standard. La sortie vidéo directe (FFmpeg) ne se parallélise pas — un seul worker rend toutes les frames séquentiellement et encode un fichier. Les séquences d'images permettent à la render farm de distribuer les frames sur plusieurs workers en parallèle, ce qui est plus rapide pour toute animation au-delà d'environ 100 frames.

Q : Comment le rendu GPU se compare-t-il en coût vs CPU sur la render farm ? A : Le GPU est typiquement plus rapide par frame (5 à 15× pour Cycles) mais le tarif par worker est plus élevé. Le coût total est à peu près comparable pour la plupart des scènes — le GPU termine en moins de temps mural mais facture plus par minute. Le donne une comparaison par frame et par job pour votre scène spécifique.

Q : Puis-je rendre des simulations Blender (fluides, fumée, cheveux, tissu) sur la render farm ? A : Bakez d'abord le cache de simulation localement, puis incluez le dossier de cache dans votre upload de projet. La render farm rend les frames contre le cache baké ; elle n'exécute pas de simulation en direct. Bakez sur disque (Cache Type → All Frames + Save Cache to Disk), confirmez que le dossier de cache est dans votre dossier de projet, packagez et uploadez.

---