Compositing VFX et rendu cloud : pourquoi le rendu de comp est une charge de travail différente de la 3D

Introduction

La plupart des contenus sur le rendu cloud sont écrits pour un seul type de charge de travail : une scène 3D qui traverse un path tracer, bucket par bucket, jusqu'à ce que le bruit disparaisse et que l'image soit terminée. Ce cadrage est exact pour un travail Redshift ou V-Ray, et il est presque inutile pour un rendu de compositing. Un comp n'échantillonne pas de trajets de lumière. Il évalue un node graph par rapport à des rushes et des passes qui existent déjà, et ce qui détermine sa durée et son coût n'est presque jamais le nombre d'échantillons GPU.

Cette distinction compte plus qu'il n'y paraît en surface, car les deux charges de travail sont constamment confondues dans les conseils génériques sur le « rendu cloud ». Un compositeur qui déplace pour la première fois un script Nuke ou un projet After Effects sur une farm, en s'attendant au même comportement lié au GPU qu'un rendu 3D, se retrouve perplexe devant un comp sans simulation ni ray tracing qui reste pourtant lent, ou qui va vite d'une façon qui n'a rien à voir avec le niveau de GPU choisi. Ce guide porte sur cet écart : ce qu'un rendu de comp fait réellement sur une farm, en quoi il diffère mécaniquement d'un rendu 3D, et quand il vaut la peine de déplacer le travail de compositing vers le cloud plutôt que de laisser tourner une station de travail toute la nuit.

Nous travaillons quotidiennement avec les deux volets de ce pipeline sur notre farm chez Super Renders Farm, du rendu 3D qui produit la beauty pass et les AOV jusqu'au rendu de compositing qui les assemble en un plan final. Les deux partagent le matériel, mais peu de choses d'autre en matière de comportement de rendu, et comprendre cette différence est ce qui rend un travail de rendu de comp prévisible plutôt que mystérieux.

Diagramme de pipeline montrant le flux de compositing EXR multicouche : les passes de rendu 3D se combinent en un fichier EXR multicouche, qui passe ensuite au logiciel de compositing puis à l'étalonnage final

Le compositing est une charge de travail de rendu différente de la 3D

Un moteur de rendu 3D comme V-Ray, Redshift ou Arnold effectue du transport de lumière : il trace des rayons, échantillonne les matériaux et accumule la réduction du bruit au fil du temps jusqu'à ce que l'image converge. Ce travail est réellement intensif en calcul par pixel, ce qui explique pourquoi le rendu 3D est gourmand en CPU ou en GPU selon le moteur, et pourquoi l'accélération GPU a un effet aussi important sur les temps de rendu 3D.

Un rendu de compositing ne fait rien de tout cela. Nuke, After Effects, Fusion et les outils similaires évaluent un node graph : lire une image, appliquer une correction colorimétrique, fusionner deux calques, appliquer une transformation, écrire le résultat. Il n'y a ni échantillonnage ni convergence. Chaque opération est un passage déterministe, essentiellement d'algèbre linéaire, sur les données de pixels, et la majorité de ces opérations (fusions, gradings, keyers, transformations, la plupart des filtres) s'exécutent sur le CPU plutôt que sur le GPU. Une poignée de types de nodes spécifiques (retimes lourds, certaines opérations de denoise, certains outils de machine learning) sont accélérés par le GPU, mais ils constituent l'exception dans un comp typique, pas la règle.

Ce qui détermine réellement la durée d'un rendu de comp se rapproche davantage d'un problème de déplacement de données que d'un problème de calcul :

• Débit de lecture. Un script de comp lit des rushes et des passes de rendu, souvent plusieurs séquences EXR multicouches à la fois, pour chaque image.
• Threading CPU. Les opérations de compositing se parallélisent sur les cœurs CPU au sein d'une même image, et le render manager parallélise entre les images en répartissant des blocs de la plage d'images entre différents workers.
• Mémoire. Garder plusieurs images pleine résolution et multicanal en mémoire en même temps (une beauty pass, quelques AOV, une matte cryptomatte, parfois une passe deep) consomme bien plus de mémoire qu'il n'y paraît, et manquer de RAM en cours d'image est une cause d'échec de rendu de comp plus fréquente que la vitesse brute du CPU.
• Débit d'écriture. L'image composée finale, ou un précomp intermédiaire, doit être réécrite, et pour les livrables de pipeline VFX, cette sortie est généralement une nouvelle séquence EXR plutôt qu'un seul fichier vidéo.

Rien de tout cela n'est une critique des logiciels de compositing. C'est un type de charge de travail différent, construit autour du déplacement et de la combinaison de données d'image déjà existantes plutôt que de leur génération à partir de zéro, et une render farm qui traite un travail de comp comme un rendu 3D, en provisionnant une capacité GPU importante et en lésinant sur la RAM et le débit de stockage, sous-performera précisément sur les machines censées bien gérer ce travail.

Ce qu'un rendu de comp lit et écrit réellement

La forme des entrées et sorties d'un travail de compositing est l'endroit où la différence avec le rendu 3D se manifeste le plus concrètement.

EXR multicouches et multi-passes en entrée. Un comp ouvre généralement un ou plusieurs fichiers OpenEXR par image qui portent déjà de nombreux canaux : un rendu beauty, des passes diffuse et spéculaire séparées, des AOV d'éclairage, une passe de profondeur Z, des vecteurs de mouvement, et des mattes cryptomatte pour l'isolation par objet, matériau et asset ID, le tout dans un seul fichier lu via un node Read et éclaté avec des nodes Shuffle pour le travail passe par passe. Lire ce fichier n'est pas un petit accès fichier ; cela revient à récupérer chaque canal que porte une image, même si un comp donné n'en touche que quelques-uns, ce qui explique pourquoi la bande passante de lecture du stockage est un véritable goulot d'étranglement sur les nodes de farm à forte charge de comp, d'une façon qui est rarement le cas pour un rendu 3D, lequel écrit la majorité de ses données EXR sans la lire.

Cryptomatte en entrée, pas en sortie. Les données cryptomatte (des mattes d'ID générées de façon procédurale qui permettent à un compositeur d'isoler des objets, matériaux ou instances d'asset individuels après coup, sans avoir à relancer le rendu) sont écrites par le rendu 3D et consommées par le comp. Cela signifie qu'un travail de farm de compositing hérite des canaux cryptomatte produits en amont par le rendu 3D, et qu'un comp qui s'appuie sur l'isolation cryptomatte lit davantage de canaux par image qu'un comp qui ne le fait pas. Notre guide EXR-IO et cryptomatte explique comment ces données sont structurées et comment les exploiter efficacement, un guide à lire avant d'envoyer un comp fortement cryptomatte vers n'importe quelle farm.

Un petit nombre de sorties, en haute profondeur de bits. Là où un rendu 3D écrit souvent plusieurs passes par image, un rendu de comp réduit généralement ces passes à une, ou à une petite poignée, de sorties composées finales, en général de l'EXR half-float 16 bits pour les livrables HDR linéaires destinés à la suite du pipeline VFX, parfois du 32 bits pour les passes de données qui exigent une précision complète. L'écriture comporte moins de canaux que la lecture, mais reste une image pleine résolution, et pour un travail de deep compositing (conserver plusieurs échantillons de profondeur par pixel pour résoudre les holdouts sans relancer le rendu de la scène 3D), la lecture comme l'écriture deviennent considérablement plus lourdes.

L'encodage vidéo est une étape séparée, pas le rendu lui-même. Lorsque le livrable final est du H.264 ou du HEVC plutôt qu'une séquence d'images, cet encodage se déroule généralement comme une passe distincte après le rendu de comp image par image, et non dans le cadre de celui-ci, car les codecs vidéo ne se répartissent pas proprement entre workers comme le fait une séquence d'images indépendante. Notre guide de comparaison d'encodage H.264 vs H.265 détaille les compromis de cette dernière étape.

Six passes de rendu (beauty, diffuse, specular, cryptomatte, profondeur, ambient occlusion) convergeant vers un seul fichier EXR multicouche

Comment les rendus de comp se distribuent sur une cloud farm

Le modèle de distribution du travail de compositing se rapproche davantage de celui de Nuke que de celui d'un moteur de rendu 3D, et il vaut la peine d'être précis sur les raisons.

Un moteur de rendu 3D peut découper une seule image spatialement : des buckets ou tiles distribués à différents threads ou machines, parce que les pixels d'une région ne dépendent réellement pas des pixels d'une autre région. Un comp ne peut généralement pas être découpé de cette façon. La valeur d'un pixel à l'image N dépend des entrées de cette image traversant l'intégralité de l'arbre de nodes, ce qui rend la majeure partie du travail de compositing embarrassingly parallel par image, et non par région d'image. Un render manager ne subdivise pas une image de comp ; il subdivise la plage d'images, en répartissant des blocs d'images entre différents workers, chacun exécutant sa propre instance de l'application de compositing en mode headless (sans interface graphique) pour sa portion.

C'est le modèle que détaille notre guide Nuke sur cloud render farm, spécifiquement pour Nuke, y compris les flags de ligne de commande exacts et la mécanique des licences. After Effects se comporte de façon similaire pour la plupart des comps de production (génériques, motion design, reveals archviz), mais avec une réserve à souligner ici : les compositions AE qui dépendent d'un état temporel entre les images (motion blur avec échantillonnage inter-images, simulations de particules qui s'accumulent, certaines opérations de tracking) ne sont pas proprement parallélisables par image, et les répartir naïvement entre workers peut produire des coutures visibles aux frontières des blocs. Notre guide de configuration du rendu cloud pour After Effects détaille quels workflows AE se parallélisent proprement et lesquels nécessitent plutôt une passe à worker unique.

Concrètement, un travail de rendu de comp sur une farm ressemble à ceci : le script ou le projet, avec tout ce qu'il référence, est envoyé sous forme de bundle autonome ; le render manager découpe la plage d'images totale en blocs ; chaque worker récupère son bloc, résout les mêmes chemins de rushes, la même config colorimétrique, les mêmes polices et dépendances de plugins que la machine de l'artiste, et rend en mode headless ; les images terminées arrivent dans le stockage partagé ou cloud au fur et à mesure que chaque bloc se termine, de sorte qu'une longue séquence peut commencer à renvoyer une sortie exploitable bien avant que le dernier worker n'ait terminé.

Problèmes courants en compositing cloud

L'immense majorité des rendus de comp qui échouent ou reviennent incorrects sur une farm ne sont pas des problèmes de mathématiques du compositing. Ce sont des problèmes de dépendances et d'environnement que la station de travail locale masquait silencieusement.

Rien de tout cela n'est propre à une application en particulier. C'est la forme générale de ce qui casse lorsqu'un script de compositing quitte la machine sur laquelle il a été créé, et c'est pourquoi « tester en petit avant de lancer la séquence complète » (rendre d'abord une poignée d'images, comparer au résultat local) est une mesure d'assurance à faible coût qui vaut la peine d'être prise sur tout rendu de comp, sur toute farm.

Quand le rendu cloud aide vraiment un pipeline de compositing

Tous les comps n'ont pas besoin d'une farm. Une courte séquence qui rend localement en quelques minutes gagne peu à l'upload et à la surcharge de file d'attente liés au passage au cloud. Le compositing cloud se justifie dans un ensemble précis de situations :

Pics liés à une deadline. Un livrable dû en heures, pas en jours, où le nombre d'images et la complexité occuperaient une station de travail plus longtemps que le délai ne le permet. Distribuer une séquence de 1 000 images entre des dizaines de workers transforme un rendu de toute une nuit en quelque chose qui peut revenir en une heure ou deux, car le débit évolue de façon quasi linéaire avec le nombre de workers disponibles.

Travail par lots de nuit qui bloquerait sinon un artiste. Même sans deadline serrée, un comp qui occuperait la propre machine d'un artiste pendant plusieurs heures représente du temps où cet artiste ne peut ni itérer, ni réviser, ni travailler sur le plan suivant. L'envoyer sur une farm libère immédiatement la station de travail au lieu d'attendre qu'un rendu local se termine.

Grandes séquences avec des données lourdes par image. Le deep compositing, l'EXR multicanal en 4K et au-delà, et les comps fortement cryptomatte sont exactement les charges de travail où le temps de rendu par image s'accumule le plus, et où la distribution sur de nombreux workers riches en CPU rapporte davantage que pour un comp léger, avec peu de canaux.

Pipelines mixtes 3D et comp déjà sur une farm. Si le rendu 3D d'un plan tourne déjà sur une cloud render farm, conserver l'étape de compositing sur la même infrastructure évite un aller-retour vers une machine locale entre les deux étapes, et garde les passes (beauty, AOV, cryptomatte) proches de l'endroit où le comp les lira.

Là où le compositing cloud se justifie le moins : une poignée de comps courts et simples, sans pression de deadline, où le temps de rendu local est déjà bien inférieur au temps nécessaire pour préparer et téléverser un bundle de projet autonome. La surcharge liée à l'upload et à l'audit des dépendances est réelle, et pour un petit travail elle peut dépasser le temps gagné.

Coût : ce que coûte réellement un travail de rendu de comp

Le compositing étant une charge de travail limitée par le CPU et la mémoire pour la grande majorité des nodes d'un comp typique, c'est généralement le tarif CPU qui détermine le coût, le tarif GPU ne s'appliquant qu'aux nodes spécifiques (retimes lourds, certains denoise, outils de machine learning) qui utilisent réellement l'accélération GPU.

Sur notre farm, le calcul CPU est facturé au GHz-heure, avec un tarif de base de 0,004 $/GHz-heure (les niveaux de priorité vont de 0,004 $ à 0,016 $/GHz-heure selon la priorité de file d'attente), et le calcul GPU est facturé à l'OctaneBench-heure (OBh), à un tarif de base de 0,003 $/OBh, une carte RTX 5090 (32 Go de VRAM) tournant autour de 5,2 $/heure-carte à pleine utilisation. Les render credits n'expirent pas, et il n'y a pas de minimum de location de machine, de sorte qu'un travail de comp est facturé pour le calcul qu'il consomme réellement, et non pour un bloc de temps réservé.

Pour rendre cela concret avec un exemple chiffré illustratif (pas un chiffre de benchmark, car le temps de rendu réel par image varie énormément selon la résolution, le nombre de canaux et la complexité des nodes) : un lot de compositing qui consomme 5 000 GHz-heures de calcul CPU agrégé (un ordre de grandeur plausible pour une séquence 4K de plusieurs milliers d'images distribuée entre des dizaines de workers pendant la nuit) coûte environ 20 $ de calcul au tarif de base, avant tout multiplicateur de niveau de priorité. Si une partie de ce même travail s'appuie sur des nodes accélérés par GPU, cette portion est facturée séparément au tarif OBh plutôt qu'au tarif GHz-heure. Le mécanisme qui compte pour le budget est simple, même quand les chiffres exacts varient d'un travail à l'autre : le coût suit le calcul total consommé, pas le temps de rendu en horloge murale, donc distribuer un travail entre davantage de workers pour finir plus vite ne change pas en soi ce qu'il coûte.

Rendu de comp vs rendu 3D : comparaison côte à côte

Où le compositing s'insère dans un pipeline de rendu cloud plus large

Le compositing est généralement la dernière étape d'une chaîne qui commence par un rendu 3D, et traiter les deux étapes avec les mêmes hypothèses sur le matériel et les goulots d'étranglement est l'erreur la plus fréquente que nous constatons dans les tickets de support des équipes découvrant le compositing cloud. Si votre pipeline est entièrement côté 3D et que vous n'avez pas encore défini le modèle de service plus large, notre guide sur ce qu'est une cloud render farm et notre guide de rendu cloud pour la VFX et la visualisation produit couvrent ce terrain. Pour l'étape de compositing spécifiquement, le guide de rendu cloud pour Nuke et le guide de configuration du rendu cloud pour After Effects détaillent les mécaniques propres à chaque application (licences, flags de soumission, matrices de plugins) que cet article a volontairement gardées générales. Côté After Effects, notre page After Effects cloud render farm détaille directement le workflow pris en charge et la tarification.

Pour une référence canonique sur le format de fichier qui sous-tend la plupart des pipelines de compositing VFX, le projet OpenEXR documente le format multicanal et multi-parties que la plupart des rendus de comp lisent et écrivent, et la spécification Cryptomatte documente la façon dont les données de matte d'ID sont encodées dans ces fichiers.

FAQ

Q: Le rendu de compositing est-il la même chose que le rendu 3D sur une cloud farm ? A: Non. Un rendu 3D effectue du transport de lumière, échantillonne et trace des rayons jusqu'à ce que l'image converge, et ce travail est réellement intensif en calcul par pixel. Un rendu de compositing évalue un node graph sur des données d'image qui existent déjà (rushes, passes de rendu) et est dominé par le threading CPU, la capacité mémoire et l'I/O de stockage plutôt que par l'échantillonnage. Les deux charges de travail partagent le matériel de la farm mais ont des goulots d'étranglement et des modes d'échec différents.

Q: Pourquoi le compositing est-il plus limité par l'I/O que le rendu 3D ? A: Un comp lit généralement un ou plusieurs fichiers EXR multicouches et multi-passes par image, récupérant chaque canal porté par le fichier (beauty, AOV, mattes cryptomatte, profondeur), et garde plusieurs de ces images pleine résolution en mémoire en même temps pendant l'évaluation du node graph. Ce volume de lecture, combiné à la réécriture de l'image composée, fait du débit de stockage et de la capacité RAM un facteur plus important dans le temps de rendu du comp que la vitesse de calcul brute, pour la majorité des nodes d'un comp typique.

Q: Une render farm de compositing a-t-elle besoin de nodes GPU ? A: Pour la plupart des comps, non. La majorité des opérations de compositing (fusions, gradings, keyers, transformations, la plupart des filtres) s'exécutent sur le CPU. Un ensemble plus restreint de types de nodes spécifiques (retimes lourds, certaines opérations de denoise, outils de machine learning) sont accélérés par le GPU, et les comps qui s'appuient fortement sur ces nodes bénéficient de la capacité GPU. Pour un comp typique dominé par les fusions et les gradings, les cœurs CPU et la RAM comptent plus que le niveau de GPU.

Q: Qu'est-ce que cryptomatte et pourquoi est-ce important pour le compositing cloud ? A: Cryptomatte est une donnée de matte d'ID générée de façon procédurale, écrite par le rendu 3D, qui permet à un compositeur d'isoler des objets, matériaux ou instances d'asset individuels après coup, sans relancer le rendu de la scène 3D. Pour un travail de compositing cloud, les données cryptomatte sont une entrée que le comp lit, et non quelque chose que le rendu de comp génère, et les comps fortement cryptomatte lisent davantage de canaux par image, ce qui augmente la charge d'I/O et de mémoire sur le node de rendu.

Q: Les comps Nuke et After Effects peuvent-ils tous deux rendre sur la même cloud farm ? A: Oui, sur une farm qui prend en charge les deux applications, bien que le modèle de distribution diffère légèrement. Les comps Nuke sont presque toujours parallélisables par image de par leur conception (chaque image est entièrement autonome). Les comps After Effects sont parallélisables par image dans la plupart des cas de production, mais les compositions qui dépendent d'un état temporel entre les images, comme certains montages de motion blur ou de simulation de particules, nécessitent un rendu à worker unique plutôt qu'une distribution par plage d'images pour éviter les coutures. Nos guides Nuke et After Effects détaillent les mécaniques propres à chaque application.

Q: Quand est-il pertinent d'envoyer un travail de compositing sur une cloud farm plutôt que de rendre localement ? A: Le compositing cloud se justifie le plus lors de pics liés à une deadline, de travail par lots de nuit qui bloquerait sinon la station de travail d'un artiste, et pour des séquences volumineuses ou lourdes par image (deep compositing, EXR multicanal en 4K et au-delà, comps fortement cryptomatte). Il se justifie le moins pour une poignée de comps courts et simples, sans pression de deadline, où le temps de rendu local est déjà plus court que le temps nécessaire pour préparer un bundle de projet autonome à téléverser.

Q: Comment le rendu de compositing est-il facturé sur une cloud farm ? A: Sur notre farm, le calcul CPU (qui détermine le coût pour la plupart des travaux de compositing) est facturé au GHz-heure, à un tarif de base de 0,004 $/GHz-heure, avec des niveaux de priorité allant jusqu'à 0,016 $/GHz-heure. Les nodes accélérés par GPU sont facturés séparément à l'OctaneBench-heure, à un tarif de base de 0,003 $/OBh. Le coût suit le calcul total consommé plutôt que le temps en horloge murale, donc distribuer un travail entre davantage de workers pour finir plus vite ne change pas en soi le coût total.

Q: Quels formats de fichiers une render farm de compositing gère-t-elle généralement ? A: L'OpenEXR multicouches et multi-parties est le standard pour les entrées et sorties de pipeline VFX, portant les beauty passes, les AOV, les mattes cryptomatte et les données de profondeur en 16 bits half-float (ou 32 bits pour les passes de données exigeant une précision complète). Lorsque le livrable final est un fichier vidéo (H.264, HEVC, ProRes) plutôt qu'une séquence d'images, cet encodage s'exécute généralement comme une passe séparée après le rendu de comp image par image, car les codecs vidéo ne se répartissent généralement pas entre workers comme le fait une séquence d'images indépendante. Notre guide H.264 vs H.265 détaille cette dernière étape d'encodage.