Résoudre les problèmes de qualité de rendu

Les problèmes de qualité de rendu sont différents des problèmes d'échec de rendu. Un échec signifie que le job n'a pas abouti. Un problème de qualité signifie qu'il a abouti, mais que le résultat est incorrect — trop lumineux, trop sombre, géométrie manquante, mauvaise caméra, sortie ne correspondant pas à ce que vous voyez dans votre viewport. Ces problèmes sont presque toujours de niveau configuration plutôt que de niveau infrastructure, ce qui signifie qu'ils peuvent être résolus de votre côté une fois que vous savez où chercher.

Cette page passe en revue les problèmes de qualité de rendu que nous voyons le plus souvent sur la farm, organisés par symptôme. Pour le dépannage des échecs de jobs — jobs qui ne se terminent pas du tout, qui plantent en cours d'image ou qui renvoient des codes d'erreur — consultez . Pour les détails de configuration spécifiques au DCC et les paramètres de rendu les plus importants pour chaque engine, consultez le doc setting-up-* correspondant.

Une règle de travail utile sur laquelle nous nous appuyons quotidiennement en support : les problèmes de qualité de rendu sont presque toujours reproductibles. Si un rendu revient incorrect depuis la farm, la même scène rendue localement — même engine, même version, mêmes paramètres, même fichier de scène — produira généralement la même sortie incorrecte. Cette reproductibilité est la clé du diagnostic. Si le rendu local correspond à celui de la farm, le problème est dans la scène et vous pouvez le corriger sans toucher quoi que ce soit côté farm. Si le rendu local diffère de celui de la farm, le problème est environnemental : une incompatibilité de chemins, une incompatibilité de versions, un asset manquant ou une configuration qui est liée à votre station de travail mais pas au fichier de scène.

Les sections ci-dessous suivent cette logique de diagnostic, ordonnées par fréquence d'apparition sur la ligne de support.

Décalage de luminosité ou de couleur par rapport au rendu local

C'est la plainte de qualité la plus fréquente que nous voyons, de loin. Le rendu revient plus clair, plus sombre, plus saturé ou visuellement différent en couleur de ce que montre votre viewport local. Presque toujours, la cause est la gestion des couleurs — le worker interprète le pipeline linéaire, sRGB ou Filmic différemment de votre viewport de station de travail, ou le marquage d'espace colorimétrique des textures est incohérent.

Cinq points à vérifier, par ordre de fréquence :

Incompatibilité de View Transform. Dans Blender, cela se trouve dans Propriétés de rendu → Gestion des couleurs → View Transform. La valeur par défaut est Filmic. Si votre viewport de station de travail affiche Filmic mais que le fichier de scène sauvegardé est réglé sur Standard (ou inversement), la sortie rendue utilise la valeur sauvegardée, non l'état du viewport. Dans Maya, l'équivalent est la Gestion des couleurs dans Paramètres de rendu → Commun (avec ACES, sRGB ou Raw comme options courantes). Dans 3ds Max, vérifiez les paramètres Gamma et LUT sous Personnaliser → Préférences → Gamma et LUT. Dans Cinema 4D, consultez Paramètres de rendu → Sortie → Profil colorimétrique. Le viewport peut afficher une transformation tandis que le fichier sauvegardé en spécifie une autre — le moteur de rendu utilise la valeur sauvegardée.
Marquage d'espace colorimétrique des textures. Les textures utilisées comme données de couleur (diffus, albedo, couleur de base) doivent être marquées sRGB ou Color. Les textures utilisées comme données (normales, rugosité, déplacement, métallique, opacité) doivent être marquées Non-Color, Linéaire ou Raw. Une normale marquée sRGB provoquera une dérive d'éclairage subtile mais omniprésente — les calculs ne fonctionnent pas correctement lorsque la texture passe par une courbe gamma supplémentaire. Parcourez votre graphe de shaders ou votre navigateur de textures avant la soumission. C'est la cause la plus fréquente des tickets « mon rendu semble délavé ».
Dérive de configuration OCIO. Si votre station de travail utilise une configuration OCIO personnalisée — ACES 1.3, AgX, une configuration spécifique à votre studio — les fichiers de configuration OCIO doivent être inclus dans votre archive de projet, et le fichier de projet doit les référencer via un chemin relatif (et non un chemin absolu qui n'existe que sur votre machine). Lorsque le worker démarre et lit votre scène, il cherche la configuration OCIO au chemin spécifié par le fichier de scène. Si le fichier n'est pas là, le moteur de rendu revient silencieusement à sa configuration par défaut (typiquement Filmic pour Blender, sRGB pour la plupart des autres), et vos couleurs dérivent.
Le format de sortie encode les couleurs différemment de vos attentes. Les formats de sortie qui ne transportent pas de métadonnées d'espace colorimétrique — PNG, JPEG, BMP — intègrent la transformation d'affichage dans les valeurs de pixels. EXR (linéaire, 32 bits) préserve les données brutes référencées à la scène et applique la transformation d'affichage à l'étape de composition. Si vous comparez une sortie PNG de la farm à une sortie EXR du même rendu, elles semblent différentes intentionnellement. Ce n'est pas un bug ; c'est ainsi que fonctionnent les formats. Lorsque vous affichez les deux avec la même View Transform appliquée dans votre logiciel de composition, ils devraient concorder.
Dérive d'exposition ou de post-traitement. Certains DCC sauvegardent un « look » de post-traitement ou une compensation d'exposition dans le fichier de scène mais l'appliquent différemment au rendu. Vérifiez le nœud de sortie de rendu, le paramètre d'exposition de la caméra et tout nœud de composition en aval du calque de rendu. Une exposition de viewport de −0,5 EV qui ne s'applique pas au rendu produira un rendu un demi-stop plus lumineux qu'attendu.

Le test de diagnostic que nous recommandons pour chaque ticket de luminosité : rendez une image de la scène problématique localement sur votre station de travail avec les mêmes paramètres que la soumission farm. Si le rendu local correspond à celui de la farm, la gestion des couleurs de votre scène est configurée telle qu'elle est intentionnellement — le viewport affiche simplement une interprétation différente. Si le rendu local diffère de celui de la farm, vérifiez d'abord l'inclusion de la configuration OCIO et le marquage d'espace colorimétrique des textures.

Caméra non détectée ou « no camera in scene »

Le moteur de rendu ne trouve pas de caméra pour rendre. Le job s'interrompt avant que des images ne soient produites, ou la sortie est vide / depuis le viewport par défaut. Trois causes fréquentes :

Aucune caméra marquée comme rendable. Dans Maya, Paramètres de rendu → Commun → Caméras rendables détermine quelle caméra rend. La valeur par défaut est persp, qui est la vue en perspective de votre viewport de modélisation — rarement ce que vous voulez pour un plan final. Définissez l'indicateur de rendu sur la caméra que vous souhaitez réellement. Dans Blender, la caméra active de la scène (Propriétés → Propriétés de la scène → Caméra) est celle qui rend. Dans Cinema 4D, le champ Paramètres de rendu → Sortie → Caméra remplace la caméra rendue si défini ; sinon, la caméra active de l'éditeur est utilisée. Dans 3ds Max, Configuration du rendu → Commun → Caméra (ou le menu déroulant Vue) sélectionne la caméra de rendu.
La caméra rendable est masquée. Dans certains DCC (notamment Maya), une caméra masquée dans le plan de scène est encore rendable tant qu'elle est marquée rendable dans les Paramètres de rendu. Dans d'autres (notamment Blender, où la caméra active doit être visible pour que le mode vue caméra du viewport fonctionne), masquer la caméra n'affecte pas directement le rendu — mais si vous avez récemment restructuré votre scène, vérifiez que la caméra attendue se trouve dans la scène active et non dans une collection, calque de rendu, prise ou scène distincte qui n'est pas sélectionnée.
Le viewport verrouillé remplace la caméra rendable. Dans 3ds Max et Maya, un schéma de « viewport verrouillé » peut amener le moteur de rendu à utiliser la caméra courante du viewport plutôt que la caméra prévue. Cela se manifeste soit comme « aucune caméra » (si le viewport est sur une vue en perspective non-caméra que le moteur de rendu rejette), soit comme « mauvaise caméra » (section suivante). Déverrouillez le viewport avant la soumission, ou définissez explicitement Vue sur Rendu dans la Configuration du rendu.

Pour la configuration de caméra spécifique au DCC, consultez , , ou .

La scène rendue n'a pas de lumières

La géométrie rend, mais la scène est complètement sombre, ou l'éclairage est beaucoup plus sombre qu'attendu — souvent un aspect de fil de fer sur fond noir suggérant qu'aucune lumière n'atteint les surfaces.

Quatre points à vérifier :

Les lumières sont désactivées dans la visibilité de rendu. Dans Maya, les lumières ont un indicateur de visibilité de rendu par rendu dans l'Éditeur d'attributs (Visibilité → Rendu). Une lumière visible dans le plan de scène peut tout de même être exclue du calcul au moment du rendu. Dans Blender, la visibilité de rendu de l'objet lumière (le basculement de l'icône caméra dans le plan de scène) contrôle si la lumière contribue au rendu — distinctement du basculement de l'icône œil pour le viewport.
Les lumières sont sur un Calque de vue, Calque de rendu ou Collection masqué. Une lumière visible dans le viewport mais assignée à un calque non rendu ne contribuera pas. Vérifiez que les lumières sont sur le calque ou la collection rendu, et non sur un calque frère masqué au moment du rendu.
L'éclairage d'environnement est désactivé. Si votre scène repose sur l'éclairage HDRI d'environnement — courant en archviz et visualisation de produits — vérifiez que l'environnement est activé dans les Propriétés de rendu. Dans Blender, Monde → Surface doit avoir la Texture d'environnement ou le shader Background connecté. Dans Maya, le nœud d'environnement Hypershade doit être branché dans l'emplacement d'environnement de rendu de la scène. Dans 3ds Max, Environnement et effets (raccourci clavier 8) doit avoir le HDRI assigné, et dans V-Ray, la substitution V-Ray Environment est un paramètre distinct qui remplace l'environnement de la scène.
GI ou Éclairage indirect est désactivé. Pour V-Ray et Corona, l'Illumination globale est un paramètre distinct de « lumières présentes dans la scène ». Une scène conçue pour les rebonds GI mais avec GI désactivé dans le preset de rendu actif apparaîtra sombre même si toutes les lumières directes sont correctement configurées. Dans V-Ray, GI → Activer l'illumination globale doit être activé. Dans Corona, GI → Solveur doit être défini (Path tracing ou UHD Cache). Dans Redshift, GI → Activer le GI doit être activé. Consultez le pour la configuration du cache GI spécifique à l'engine qui suit cette activation.

Un test de diagnostic rapide : ajoutez temporairement un Soleil ou une lumière directionnelle avec une intensité de 1,0 au-dessus de la scène et rendez une image. Si même cela n'apparaît pas dans la sortie, le problème est la visibilité du calque ou de la collection, et non la configuration de la source lumineuse. Si le soleil test rend correctement, vos lumières d'origine sont le problème — retravaillez les quatre vérifications ci-dessus.

La mauvaise caméra rend malgré la spécification de la bonne

Vous avez défini la Caméra A comme caméra de rendu, mais la sortie montre la vue de la Caméra B. C'est l'un des problèmes de qualité les plus frustrants car le fichier de scène semble correct à l'inspection — l'indicateur de rendu est sur la bonne caméra, la caméra active est celle voulue. La cause est presque toujours l'une de ces trois choses :

Vue verrouillée sur le viewport dans 3ds Max ou Maya. Un viewport verrouillé (clic droit sur le label du viewport → Verrouiller) remplace la sélection de caméra dans la Configuration du rendu. Le moteur de rendu utilise la caméra du viewport, et non celle que vous avez configurée. Déverrouillez le viewport avant de sauvegarder la scène, ou définissez explicitement Vue sur Rendu dans Configuration du rendu → Commun (Maya) ou Configuration du rendu → Sortie (3ds Max). C'est la cause la plus fréquente des tickets « mauvaise caméra » sur les soumissions 3ds Max — le verrou est facile à activer accidentellement avec un raccourci clavier et facile à manquer avant la soumission.
Scène multi-caméras avec la mauvaise caméra active. Si votre scène comporte plusieurs caméras — tourniquet, principale, beauté, détail, variantes — vérifiez laquelle est définie comme caméra active pour la scène, la prise ou le calque de rendu actuel. Dans Cinema 4D, chaque Prise peut avoir sa propre caméra ; dans Blender, chaque scène a sa propre caméra active ; dans Maya, les calques de Configuration du rendu peuvent remplacer la caméra par calque. La caméra rendue est celle assignée au niveau du calque / prise / scène soumis, et non celle que vous avez sélectionnée en dernier dans le viewport.
Incompatibilité de prise, de scène ou de calque de rendu. Vous avez soumis le Calque de rendu A mais il hérite sa caméra du Master, et la caméra du Master est la Caméra B ? Cela arrive. Soumettez toujours depuis la prise ou le calque qui dispose explicitement de la caméra prévue, et évitez de compter sur l'héritage à moins d'avoir vérifié la chaîne.

L'image de sortie est partielle, recadrée ou ne représente pas l'image complète

L'image rendue revient mais seule une partie de l'image est remplie — le reste est noir, transparent ou de la couleur du viewport répétée. Quatre points à vérifier :

La région de rendu est activée. Dans V-Ray, Corona, Arnold et plusieurs autres moteurs de rendu, une option « Region » permet de ne rendre qu'un sous-rectangle de l'image complète pour un aperçu rapide. Si Region était activée pendant les tests locaux et non désactivée avant la soumission, le worker ne rend que cette région — le reste de l'image reste à sa couleur de remplissage par défaut. C'est la cause la plus fréquente des tickets de sortie partielle.
Incompatibilité de résolution de sortie entre la scène et le paramètre de rendu. La résolution de sortie des Propriétés de rendu et la taille réelle de l'image dans le fichier de sortie doivent correspondre. Si l'ouverture de la caméra de votre scène est réglée sur une résolution et votre sortie sur une autre, le moteur de rendu peut produire un remplissage partiel — la caméra « voit » une zone plus petite que le canevas de sortie, et la région vide reste sans couleur.
Incompatibilité de rapport d'aspect entre la caméra et la sortie. Une caméra avec un rapport 1,78 rendant sur une sortie 1,0 produira une image partielle — la vue de la caméra ne remplit pas l'image de sortie. Vérifiez que le rapport d'aspect du film de la caméra correspond au rapport d'aspect de la sortie, ou que « Ajuster la porte de résolution » (ou son équivalent — différents DCC le nomment différemment : « Ajustement de la porte de résolution », « Ouverture de la caméra », « Porte de film ») est réglé sur remplir, horizontal, vertical ou débordement selon les besoins de votre plan.
Paramètres de bordure ou de recadrage dans le format de sortie. Certains DCC et certains formats de sortie permettent de définir une bordure de rendu indépendante de la porte de résolution de la caméra. Vérifiez que la bordure (dans les Propriétés de rendu, ou dans les attributs de la caméra) englobe toute la zone de sortie prévue, et non une sous-région recadrée.

Rendus noirs ou vierges

Le rendu se termine avec succès — aucune erreur, aucun avertissement — mais chaque pixel est noir ou totalement uniforme. Plus fréquent sous Maya, mais nous le voyons sur tous les DCC.

Cinq points à vérifier :

Incompatibilité de basculement de calque. Dans Maya, la géométrie peut être visible dans le viewport mais désactivée au niveau de la visibilité de rendu (Affichage → Masquer → Masquer toutes les caméras, ou Statistiques de rendu par objet → Visibilité primaire = désactivé). Dans Blender, l'équivalent est le basculement de visibilité de rendu (icône caméra) dans le plan de scène. La cause la plus fréquente est la restructuration des calques d'une scène après les tests et l'oubli d'activer la visibilité de rendu sur le nouveau calque ou la nouvelle collection.
Plans de recadrage de caméra incorrectement définis. Si le plan proche ou lointain est mal réglé — plan lointain trop proche de la caméra, plan proche derrière la géométrie — la caméra n'inclut pas la géométrie dans son frustum de vue. Les plans par défaut (proche 0,1, lointain 1000-10000 selon l'échelle de la scène) conviennent généralement ; ce problème se produit après ajustement manuel, notamment lors du travail à des échelles de scène inhabituelles (grands ensembles architecturaux ou rendus de produits microscopiques).
Lumières rendables mais émission désactivée. Si vous utilisez des matériaux émissifs comme lumières, vérifiez que le shader d'émission est activé et a une intensité non nulle. Certains workflows désactivent l'émission pendant l'interaction avec le viewport pour éviter la chauffe GPU et oublient de la réactiver avant la soumission.
Échantillonnage trop faible pour produire une sortie visible. Avec des réductions agressives d'échantillonnage par tracé de chemin (très peu d'échantillons par pixel), les scènes très sombres peuvent produire une sortie entièrement noire jusqu'à ce que les échantillons augmentent suffisamment pour converger. Rendez une seule image localement avec les mêmes paramètres pour vérifier ; si le rendu local est également entièrement noir au même nombre d'échantillons, augmentez l'échantillonnage ou vérifiez la configuration d'éclairage.
Nœud de sortie de rendu mal configuré (Blender, Houdini). Dans le compositeur Blender et dans le réseau ROP Houdini, la chaîne de nœuds de sortie peut être configurée pour rejeter le résultat de rendu avant de le sauvegarder. Vérifiez que le nœud Composite est connecté aux Calques de rendu (Blender) ou que le chemin de sortie du ROP est défini correctement et que le mode de sortie n'est pas « Null » (Houdini).

Pour Maya spécifiquement, consultez pour le workflow de sélection de caméra et de statistiques de rendu qui évite la cause la plus fréquente des rendus noirs sous ce DCC.

Certains objets de la scène ne se rendent pas

Un objet spécifique est visible dans le viewport mais absent de la sortie rendue. Le reste de la scène se rend correctement. Courant sur tous les DCC, légèrement plus fréquent sous Blender car le modèle de visibilité à trois niveaux de Blender (viewport / rendu / sélection) est facile à mal configurer.

Cinq points à vérifier :

Basculement de visibilité de rendu sur l'objet. Dans le plan de scène Blender, survolez la ligne de l'objet — trois icônes contrôlent la visibilité : œil (viewport), caméra (rendu), écran (sélectabilité). Assurez-vous que l'icône caméra est activée pour l'objet manquant. Dans Maya, Éditeur d'attributs → Statistiques de rendu → Visibilité primaire doit être activé. Dans 3ds Max, les Propriétés de l'objet → Rendu → Visibilité doit être au-dessus de 0 (et Rendable doit être coché).
L'objet est dans une collection, un calque ou un ensemble masqué. Les collections dans Blender ont des visibilités séparées pour le viewport et le rendu. La collection peut être visible dans le viewport mais exclue du rendu via le basculement de l'icône caméra sur la ligne de la collection. Dans Maya, l'attribution du Calque d'affichage et du Calque de rendu d'un objet sont séparées ; dans 3ds Max, les Propriétés du calque → Rendable doit être activé pour chaque calque contenant de la géométrie rendable.
Le matériau de l'objet est invisible. Un matériau avec une opacité nulle, un alpha nul ou des problèmes de mélange alpha rendra l'objet effectivement invisible — la géométrie est là mais transparente. Vérifiez l'opacité, l'alpha, la transparence et tout paramètre de mélange alpha du matériau. Piège courant : un matériau configuré pour être un « fantôme » de référence dans le viewport et jamais restauré avant la soumission.
La pile de modificateurs masque la géométrie. Certains modificateurs (Booléen, Masque, Décimate à des paramètres extrêmes, Construction) peuvent effectivement supprimer la géométrie de la sortie de rendu même si le maillage source est visible dans le mode viewport de la pile de modificateurs. Désactivez les modificateurs un par un sur l'objet manquant pour identifier lequel est le coupable, puis corrigez les paramètres du modificateur ou appliquez / calculez-le avant la soumission.
L'objet est un proxy ou une instance avec une référence brisée. Les objets proxy (V-Ray Proxy, Redshift Proxy, Arnold Standin), les caches Alembic et les instances référencent des fichiers externes. Si le chemin de référence est brisé — chemin absolu incorrect, fichier manquant dans l'archive, partage réseau inexistant sur le worker — le proxy se rend comme rien. Cela rejoint la section §Assets manquants ci-dessous ; consultez cette section pour le workflow complet de vérification des chemins.

Mauvaises configurations de cache GI, d'irradiance et de cache de lumière

Cette section recoup le mais couvre les symptômes qui se manifestent comme des problèmes de qualité plutôt que de performances. Si votre rendu revient avec un scintillement entre les images, un éclairage indirect en taches, un banding dans les zones sombres ou une illumination visiblement différente sur des images adjacentes de la même animation, la cause est presque toujours une configuration de cache GI qui ne survit pas au rendu distribué.

Le problème central : les caches GI dans V-Ray (Irradiance Map, Light Cache), Corona (UHD Cache, Path tracing) et Redshift (Irradiance Cache, Photon Map) sont des jeux de données d'éclairage précalculés. Lors du rendu d'une animation, le cache doit être soit (a) précalculé une fois et réutilisé sur chaque image, soit (b) calculé par image avec une qualité suffisamment élevée pour sembler identique d'image en image. Mélanger les deux — laisser chaque worker calculer son propre cache par image à faible qualité — produit un scintillement visible, car le motif de bruit de chaque worker est différent.

Quatre configurations incorrectes fréquentes et comment y remédier :

Mode GI par image dans une animation. Le mode « Image unique » de V-Ray pour l'Irradiance Map et le Light Cache calcule un nouveau cache pour chaque image. Sur une farm distribuée, chaque worker calcule le sien — ils ne le partagent pas. Le résultat est un scintillement d'animation. Passez à « Multiframe Incremental » avec le fichier de cache sauvegardé sur disque, ou précalculez le cache comme passe séparée et utilisez « Depuis le fichier » pour la passe d'animation réelle. Consultez pour le workflow complet.
Le fichier de cache est local et manquant sur les workers. Si vous avez sauvegardé une Irradiance Map précalculée à C:\Users\VotreNom\Documents\maps\ir.vrmap et soumis le job, les workers n'ont pas ce fichier. Ils reviennent au calcul par image (la première cause ci-dessus) et l'animation scintille. Sauvegardez les fichiers de cache dans le dossier du projet, utilisez des chemins relatifs et incluez les fichiers de cache dans votre archive de projet avant la soumission.
Qualité du cache trop faible pour la scène. Même configuré correctement (précalculé, inclus dans l'archive), un Light Cache à 500 subdivisions ou une Irradiance Map à qualité « Très faible » peut être insuffisant pour une scène d'archviz sombre et chargée en GI. Les rendus semblent bruités ou en taches, surtout dans les coins et sous les meubles. Augmentez les subdivisions ou utilisez le preset Universel comme ligne de base.
Cache UHD réutilisé sur des caméras incompatibles. Le Cache UHD (Corona, V-Ray) dépend du point de vue de la caméra. Un cache précalculé pour la Caméra A et réutilisé sur la Caméra B produira une illumination incorrecte — le cache « croit » que la caméra est quelque part où elle n'est pas. Si vous rendez plusieurs caméras de la même scène, précalculez un Cache UHD par caméra, ou utilisez le Path tracing (sans cache) pour une cohérence entre les caméras.

Pour la configuration complète du cache GI, les notes de version pour V-Ray 6.x et le workflow de précalcul qui s'envoie proprement à la farm, consultez le .

Assets manquants — textures, proxies, références, plugins

Le rendu se termine mais des parties de la scène sont visiblement incorrectes : les textures sont roses (défaut Maya pour texture manquante), violettes (défaut V-Ray), en damier (Arnold) ou magenta uni (Blender). Les proxies se rendent comme des boîtes englobantes ou de l'espace vide. Des matériaux spécifiques se rendent comme le substitut « manquant » du moteur.

La cause est la résolution des chemins. Votre fichier de scène référence des assets par chemin, et sur le worker, ces chemins ne se résolvent pas. Six points à vérifier :

Chemins absolus dans le fichier de scène. Si votre scène référence des textures à C:\Users\VotreNom\Projet\textures\bois.jpg, le worker n'a pas ce chemin. Utilisez des chemins relatifs (./textures/bois.jpg ou ../textures/bois.jpg) ou intégrez les assets dans le fichier de scène. La plupart des DCC ont un workflow « Rendre les chemins relatifs » ou « Collecteur de ressources » qui convertit les chemins absolus en relatifs avant la soumission.
Assets non inclus dans l'archive du projet. Les chemins relatifs aident, mais seulement si les assets qu'ils référencent sont effectivement présents dans l'archive téléversée. Exécutez l'outil de consolidation de projet du DCC (ou compressez simplement le dossier de projet entier incluant textures, caches, références et HDRIs) avant la soumission.
Incompatibilité de casse. Windows est insensible à la casse (Texture.JPG et texture.jpg sont le même fichier) ; les workers de la farm tournent sous Linux, qui est sensible à la casse (ce sont des fichiers différents). Un fichier de scène référençant Texture.JPG ne trouvera pas texture.jpg sur un worker Linux. La plupart des DCC mettent les chemins en minuscules à l'exportation — mais pas toujours.
Plugin non installé sur les workers. Si votre scène dépend d'un plugin tiers — Forest Pack, RailClone, Phoenix FD, MultiScatter, GrowFX, Ornatrix — le worker doit avoir ce plugin installé à la même version. Nous préinstallons les plugins majeurs, mais vérifiez que votre version spécifique est prise en charge en consultant le doc setting-up-* du DCC concerné.
Scènes liées ou référencées avec des chemins brisés. Si votre scène principale référence une sous-scène (référence Maya, bibliothèque liée Blender, scène XRef 3ds Max), et que le chemin de la sous-scène est absolu ou externe à l'archive, le worker ne peut pas la trouver. Les sous-scènes doivent être dans l'archive et référencées relativement, comme les textures.
Incompatibilité de version d'asset. Moins fréquent mais à vérifier : une scène sauvegardée dans Maya 2026 avec des assets dépendant de types de nœuds spécifiques à Maya 2026 ne rendra pas correctement sur un worker sous Maya 2024. Faites correspondre la version de sauvegarde de votre scène à la version worker indiquée dans le doc setting-up-* correspondant.

Si vous avez vérifié les six points et que les assets manquent toujours, l'équipe de support peut extraire le journal du worker au moment du rendu pour votre job et identifier exactement quel chemin d'asset n'a pas réussi à se résoudre.

Dérive de couleur entre les sorties EXR et PNG du même rendu

Vous avez rendu la même scène en EXR et en PNG et les couleurs ne correspondent pas. C'est généralement un comportement attendu plutôt qu'un bug, mais cela surprend suffisamment régulièrement les utilisateurs pour mériter sa propre section.

EXR stocke des données en virgule flottante linéaires sans transformation d'affichage intégrée. PNG (et JPEG, BMP) intègre la transformation d'affichage dans les valeurs de pixels. Lorsque vous affichez l'EXR dans un logiciel de composition avec la transformation Filmic, ACES, sRGB ou AgX correspondante appliquée, il devrait visuellement correspondre au PNG — les données sous-jacentes sont les mêmes, mais l'encodage est différent.

Deux situations où cela devient un vrai problème :

La gestion des couleurs du logiciel de composition diffère de celle du DCC. Si vous rendez un EXR avec la View Transform ACES appliquée dans votre DCC, puis ouvrez l'EXR dans un logiciel de composition (Nuke, Fusion, After Effects, Resolve) configuré en sRGB ou sans gestion des couleurs, le résultat affiché sera différent. Configurez le logiciel de composition pour utiliser la même View Transform / configuration OCIO que votre DCC.
Le PNG a été sauvegardé avec une View Transform différente de l'EXR. Certains DCC permettent des substitutions de View Transform par format. Si vous avez réglé EXR sur « Raw » et PNG sur « sRGB » dans les mêmes paramètres de sortie de la scène, ils produiront des résultats visuellement différents du même rendu, par conception. Vérifiez les paramètres de sortie par format et standardisez sur une transformation, sauf si vous avez besoin d'une variation par format.

Flux de diagnostic général

Lorsqu'un problème de qualité de rendu apparaît, parcourez ces étapes dans l'ordre. La plupart des tickets se résolvent aux étapes 1 à 3 sans escalade.

Reproduire localement. Rendez une image de la scène problématique sur votre station de travail avec les mêmes paramètres que la soumission farm. Si le rendu local correspond à celui de la farm, le problème est dans la scène — corrigez la scène. Si le rendu local diffère de celui de la farm, le problème est environnemental : chemin, version de plugin, configuration OCIO ou archive d'assets.
Vérifier la Gestion des couleurs et la View Transform. Cela cause ~40 % des problèmes de qualité que nous voyons sur la ligne de support.
Vérifier la sélection de caméra dans les Paramètres de rendu. ~20 % — mauvaise caméra, viewport verrouillé, incompatibilité de calque ou de prise.
Vérifier la Région, la Bordure ou le Recadrage de rendu. ~10 % — sortie partielle.
Vérifier la visibilité du Calque, de la Collection ou du Calque de rendu. ~15 % — objets manquants, lumières manquantes, scènes sombres.
Vérifier le marquage d'espace colorimétrique des textures. ~10 % — dérive de luminosité subtile mais omniprésente.
Vérifier la configuration du cache GI pour le scintillement d'animation. ~3 % — consultez le .
Vérifier les chemins d'assets et la complétude de l'archive. ~2 % — textures roses, proxies manquants.

Si les étapes 1 à 8 n'identifient pas la cause, l'équipe de support extraira le journal du worker pour votre job et précisera la cause jusqu'à un état spécifique de la flotte de workers, une incompatibilité de version de moteur de rendu ou un problème de configuration que nous pouvons résoudre de notre côté.

Références croisées

— dépannage des échecs de jobs (le job n'a pas abouti du tout)
— workflow de téléversement, soumission, téléchargement
— cache GI, Irradiance Map, Light Cache, configuration UHD Cache
— conditionnement d'archive de projet, consolidation d'assets, prévention des assets manquants
— configuration de caméra Maya, calque de rendu, statistiques de rendu
— verrous de caméra 3ds Max, rendu de région, paramètres Gamma et LUT
— système de prises Cinema 4D, tags de caméra, profil colorimétrique
— visibilité de rendu Blender, gestion des couleurs, Filmic vs AgX
— gestion des couleurs AE pour la composition de sortie de rendu
— référence de caméra ROP Houdini, configuration du nœud de sortie

FAQ

Q : Mon rendu est revenu plus sombre que mon viewport. Qu'est-ce qui a changé ? A : Presque toujours une incompatibilité de Gestion des couleurs ou de View Transform. La transformation de couleur du fichier de sortie reflète les paramètres de Gestion des couleurs → Propriétés de rendu sauvegardés, pas l'état actuel de votre viewport. Vérifiez que la View Transform (Filmic, AgX, Standard, sRGB, ACES) et les paramètres Look sont correctement sauvegardés dans votre projet avant la soumission, et que le marquage d'espace colorimétrique de vos textures est cohérent.

Q : Mon rendu est revenu sans éclairage. La scène a des lumières, je les vois dans le viewport. A : Vérifiez quatre points dans l'ordre : (1) le basculement de visibilité de rendu de chaque lumière (séparé de la visibilité viewport) ; (2) le Calque de rendu, le Calque de vue ou la Collection sur lesquels se trouvent les lumières, et si ce calque est activé pour le rendu ; (3) si l'environnement HDRI est activé dans les Propriétés de rendu ou le shader World ; (4) si GI ou Éclairage indirect est activé dans les paramètres de rendu actifs pour les engines qui le contrôlent séparément (V-Ray, Corona, Redshift).

Q : La mauvaise caméra a rendu même si j'ai sélectionné la bonne dans les Paramètres de rendu. A : Très probablement une condition « Vue verrouillée » dans 3ds Max ou Maya — un viewport verrouillé remplace la sélection de caméra dans les Paramètres de rendu. Déverrouillez le viewport, ou définissez explicitement Vue sur Rendu dans la Configuration du rendu de votre DCC avant la soumission. Vérifiez également que la Prise, la Scène ou le Calque de rendu soumis a la caméra prévue au niveau du calque.

Q : Pourquoi mes sorties EXR et PNG du même rendu semblent-elles différentes ? A : EXR stocke des données en virgule flottante linéaires sans transformation d'affichage intégrée ; PNG intègre la transformation d'affichage dans les valeurs de pixels. Lorsque vous affichez l'EXR dans un logiciel de composition avec la View Transform correspondante appliquée, il devrait ressembler au PNG. S'ils semblent différents dans le logiciel de composition, la gestion des couleurs du logiciel de composition ne correspond pas à celle de votre DCC.

Q : Un objet spécifique est manquant de mon rendu mais visible dans le viewport. A : Vérifiez (1) l'indicateur de visibilité de rendu de l'objet (séparé de la visibilité viewport — icône caméra dans Blender, Visibilité primaire dans Maya, Rendable dans 3ds Max) ; (2) la visibilité de la Collection, du Calque de rendu ou du Calque d'affichage sur lequel se trouve l'objet ; (3) si un modificateur (Booléen, Masque, Décimate) masque la géométrie au moment du rendu ; (4) si l'objet est un proxy avec une référence externe brisée (voir aussi la section Assets manquants).

Q : Mon rendu est revenu partiel ou recadré. La moitié de l'image est noire. A : Vérifiez si la Région de rendu (ou Bordure, Recadrage) est activée dans votre moteur de rendu. Le rendu de région produit un remplissage partiel de l'image de sortie. Désactivez la Région avant la soumission, ou réglez-la sur l'image complète. Vérifiez également que le rapport d'aspect de la caméra correspond au rapport d'aspect de la sortie, et que la résolution de sortie dans les Propriétés de rendu correspond à la résolution du film de la caméra.

Q : Mes textures semblent délavées ou sursaturées par rapport à ma station de travail. A : Marquage d'espace colorimétrique des textures. Les textures de couleur (diffus, albedo, couleur de base) doivent être marquées sRGB ou Color ; les textures de données (normale, rugosité, déplacement, métallique, opacité) doivent être marquées Non-Color, Linéaire ou Raw. Les textures mal marquées provoquent une dérive de couleur subtile mais cohérente, surtout sur les matériaux PBR où le gamma de la normale est important.

Q : Ma configuration OCIO ACES est réglée sur ma station de travail. La farm la respecte-t-elle ? A : Oui, si les fichiers de configuration OCIO sont inclus dans votre archive de projet et que le fichier de projet référence la configuration via un chemin relatif. Si les fichiers de configuration OCIO sont manquants dans l'archive, le worker revient à la configuration par défaut du DCC (typiquement Filmic pour Blender, sRGB pour la plupart des autres), et vos couleurs dériveront. Incluez toujours le dossier de configuration OCIO dans votre archive de projet.

Q : Mon animation scintille — chaque image semble avoir un éclairage indirect différent. A : Mauvaise configuration du cache GI. Dans V-Ray, passez de l'Irradiance Map en mode « Image unique » à « Multiframe Incremental » avec le cache sauvegardé sur disque, et précalculez le cache comme pré-passe ou utilisez le preset de Path tracing Universel. Pour les autres engines, consultez les paramètres de cache GI correspondants — la règle est la même : précalculer une fois et réutiliser, ou utiliser un mode sans cache (Path tracing) pour la cohérence inter-images. Consultez le pour le workflow complet.

Q : Mes textures se rendent en rose, violet ou magenta sur la farm. A : Assets manquants. Le fichier de scène référence des textures à des chemins que le worker ne peut pas résoudre — généralement des chemins Windows absolus (C:\Users\...), des assets non inclus dans l'archive de projet, ou des incompatibilités de casse entre votre système de fichiers Windows et le système de fichiers Linux du worker. Utilisez des chemins relatifs, exécutez l'outil de consolidation de projet de votre DCC avant la soumission et vérifiez que l'archive inclut toutes les textures référencées.

Q : Ma scène Forest Pack / Phoenix FD / Ornatrix est revenue avec les objets plugin manquants. A : Incompatibilité de version de plugin ou de compatibilité sur le worker. Consultez le doc ou correspondant pour les versions de plugins pris en charge sur notre flotte de workers. Si votre version est prise en charge, la scène devrait se rendre correctement — sinon, calculez la sortie du plugin en maillage avant la soumission, ou contactez le support pour vérifier le statut d'installation de votre version spécifique de plugin.

---

Résoudre les problèmes de qualité de rendu