Houdini Karma XPU sur une Cloud Render Farm : Guide technique 2026

Introduction

Karma XPU est le moteur de rendu sur lequel un nombre croissant de studios Houdini se standardisent, et pour de bonnes raisons : il s'agit du moteur de rendu de production officiel de SideFX, il s'intègre nativement à Solaris et USD, et son exécution hybride CPU+GPU rend le look-dev presque interactif. Sur une station de travail individuelle, il est très agréable à utiliser. Les difficultés commencent lorsque vous transférez une scène Karma XPU depuis votre station de travail et que vous tentez d'exécuter quelques centaines d'images sur une farm.

À l'échelle d'une farm, Karma XPU cesse de se comporter comme une version plus rapide de Karma CPU pour agir comme une entité à part entière. La VRAM devient un plafond rigide plutôt qu'une simple recommandation. Les simulations qui fonctionnaient bien en mode interactif ne peuvent pas être distribuées du tout avant d'être mises en cache. Le moteur peut silencieusement basculer vers le CPU sur une image lourde et vous laisser vous demander pourquoi un plan a pris six fois plus de temps que le plan voisin. Aucun de ces comportements n'est un bug — c'est l'architecture qui transparaît sous la charge.

Nous gérons le rendu distribué pour les projets Houdini depuis des années, et Karma XPU est l'un des moteurs disponibles sur notre cloud render farm Houdini, aux côtés de Redshift, Mantra, Arnold, V-Ray for Houdini et Octane. Ce guide est l'exploration technique approfondie : ce qu'est réellement Karma XPU, comment il diffère de Karma CPU et Mantra, ce qui change lorsque vous le rendez en mode headless sur une farm, comment la mise en cache des simulations doit fonctionner en premier lieu, et comment choisir entre Karma XPU et Redshift pour un plan donné. Si vous préférez une liste de préparation de scène étape par étape, notre guide de configuration Houdini couvre ce terrain ; cet article suppose que vous connaissez déjà bien Solaris.

Pourquoi Karma XPU est plus difficile à mettre à l'échelle qu'il n'y paraît

Ce qu'il faut comprendre à propos de Karma XPU, c'est que « XPU » n'est pas un moteur de rendu — c'est un mode d'exécution. Karma est un unique délégué de rendu USD, et XPU est le mode qui distribue le travail à vos cœurs CPU et à votre GPU NVIDIA simultanément, les deux appareils contribuant des échantillons à la même image. Karma CPU est le même délégué avec le GPU désactivé. Cette conception est élégante sur une station de travail et délicate sur une farm, pour quatre raisons.

Premièrement, le chemin GPU s'exécute sur OptiX, ce qui signifie qu'il charge la géométrie, les textures et les structures d'accélération dans la VRAM du GPU. Lorsqu'une scène tient dans la VRAM, vous obtenez l'accélération hybride complète. Lorsque ce n'est pas le cas, Karma XPU tend à basculer vers l'exécution CPU plutôt que de transférer les données en flux comme le font certains moteurs de rendu GPU. Le rendu se termine quand même, mais à une fraction de la vitesse attendue — et rien dans un journal de tâche habituel ne le signale clairement.

Deuxièmement, XPU est plus récent que les moteurs qu'il concurrence. Houdini 20.0 a constitué sa première étape de stabilité en production et la version 20.5 a considérablement élargi la couverture fonctionnelle, mais une poignée de fonctionnalités favorisent encore Karma CPU. Si un plan en utilise une, une partie du rendu peut silencieusement passer au mode CPU.

Troisièmement, l'épinglage de version est plus important que les gens ne le pensent. Une scène créée dans une version ponctuelle de Houdini devrait être rendue sur des nœuds de rendu utilisant cette même version ; la surface de Karma a suffisamment évolué entre les versions 20.0, 20.5 et la ligne 21 pour que les rendus inter-versions ne soient pas une hypothèse fiable.

Quatrièmement — et celui-là surprend tout le monde la première fois — les simulations ne sont pas des images. Vous ne pouvez pas simplement envoyer une configuration Pyro ou FLIP sur une farm et vous attendre à ce qu'elle se distribue. Ce point mérite sa propre section, et il en a une ci-dessous.

Karma XPU vs Karma CPU vs Mantra

Trois moteurs de rendu sont livrés avec Houdini, et choisir entre eux est la première vraie décision pour toute tâche de farm. Ils ne sont pas interchangeables.

Mantra est le moteur historique. Il est antérieur à USD, fonctionnant sur le pipeline de description de scène propre à Houdini et utilisant des shaders basés sur VEX (CVEX) plutôt que MaterialX. SideFX ne l'a pas supprimé et il reste entièrement fonctionnel, mais il ne reçoit plus de nouvelles fonctionnalités — la direction clairement choisie est Karma. Mantra conserve sa pertinence dans deux cas : les pipelines avec de vastes bibliothèques de shaders VEX qui seraient coûteuses à reconstruire, et les comportements occasionnels de micropolygone ou de déplacement qui n'ont pas encore d'équivalent propre dans Karma. Si vos shaders sont en CVEX, ils ne se traduisent pas vers Karma, et cela seul peut maintenir un plan sur Mantra.

Karma CPU est le chemin de référence. Il est nativement USD, implémente l'ensemble complet des fonctionnalités Karma, et constitue la référence absolue lorsque vous souhaitez savoir à quoi une image est « censée » ressembler. Il s'exécute en multithread sur les cœurs CPU sans implication du GPU. Sur une farm disposant d'une grande flotte CPU, il est véritablement pratique — il contourne entièrement le plafond de VRAM, ce qui en fait le choix judicieux pour les scènes trop lourdes pour tenir confortablement dans la mémoire GPU.

Karma XPU est le chemin hybride accéléré : CPU plus GPU NVIDIA, les deux traçant dans la même image, utilisant le shading MaterialX et la même base USD native que Karma CPU. En associant le GPU au CPU, il rend le look-dev interactif et les images finales en VRAM plus rapidement que n'importe quel chemin CPU seul, et il constitue la valeur par défaut naturelle pour les nouveaux pipelines Solaris. Sa limitation est qu'il représente un sous-ensemble de fonctionnalités de Karma CPU — la plupart des lacunes qui subsistent concernent des cas limites de volumes, de shading ou d'AOV exotiques, et SideFX les comble version après version. La règle de production honnête consiste à rendre une image de comparaison à la fois avec XPU et CPU avant de confier une séquence à XPU, car lorsque XPU et CPU divergent, CPU est correct.

Schéma de Houdini Karma XPU répartissant le travail de rendu entre CPU et GPU simultanément, les deux contribuant des échantillons à une image unique.

Exécuter Karma XPU en mode headless sur une cloud render farm

En mode interactif, vous lancez le rendu en appuyant sur le bouton dans le viewport Solaris. Sur une farm, ce bouton est un programme en ligne de commande appelé husk. Il s'agit du moteur de rendu USD autonome de SideFX — un processus léger qui charge un stage USD composé et le rend sans démarrer une session interactive complète de Houdini. Il est fourni avec Houdini et constitue la méthode canonique pour rendre Karma à grande échelle. Une soumission ressemble, en substance, à ceci :

husk --renderer Karma \
     --frame 1001 --frame-count 50 \
     --output /project/render/shot_010.$F4.exr \
     /project/usd/shot_010.usd

Chaque nœud de rendu exécute husk sur le même stage USD, mais pour une plage d'images différente, ce qui permet la distribution au niveau des images. Le stage lui-même est un fichier .usd/.usdc entièrement composé qui référence toute la géométrie, les lumières, les caméras et les matériaux. Vos AOV ne sont pas des indicateurs de ligne de commande — ce sont des primitives USD Render Var intégrées dans le stage depuis les LOP Render Settings et Render Var, de sorte que husk les lit sans nécessiter un réseau Houdini actif. La beauté, l'alpha, les normales, l'albedo et le reste voyagent à l'intérieur de l'USD.

Quelques mécaniques spécifiques à la farm méritent d'être connues. Karma prend en charge les points de contrôle (checkpoints), en écrivant l'état intermédiaire du rendu à intervalles d'échantillons afin qu'une image héros longue puisse reprendre plutôt que de redémarrer si un nœud rencontre un problème — précieux pour les images à mille échantillons, moins pertinent pour les animations à échantillons modérés où chaque image est peu coûteuse à refaire. Le débruitage s'effectue soit via le débruiteur OptiX sur le GPU, soit via Intel OIDN sur le CPU ; sur une farm, nous privilégions OIDN lorsque la stabilité temporelle sur de nombreux nœuds est importante, car il produit une sortie identique quelle que soit la machine qui a traité l'image.

Concernant la licence, nous serons directs, car c'est une question fréquente. Karma n'est pas un plugin sous licence séparée comme Redshift, Arnold, V-Ray et Octane — il est fourni en bundle avec Houdini lui-même. Nous exécutons Houdini et Karma sous utilisation render-only pour rendre vos tâches ; nous ne sommes pas un partenaire SideFX et nous ne revendons pas de licences Houdini. Parce que notre farm est entièrement gérée, vous ne vous connectez pas à distance à un nœud, n'installez pas Houdini vous-même, et ne nous remettez pas de licence — vous téléversez votre scène et vos données mises en cache, et la licence côté rendu sur nos nœuds est gérée dans le cadre de l'exploitation du service. Pour les moteurs commerciaux de la stack Houdini, les licences Redshift, Arnold, V-Ray et Octane sont incluses dans le tarif de rendu.

La stack Houdini de Super Renders Farm

Une render farm qui n'exécute qu'un seul moteur oblige chaque plan à passer par le même ensemble de compromis. Les projets Houdini coopèrent rarement avec cela, c'est pourquoi notre cloud render farm Houdini exécute la gamme complète : Karma (en modes XPU et CPU), Mantra, Redshift, Arnold, V-Ray for Houdini et Octane. L'intérêt de cette diversité est que vous choisissez le bon moteur par plan plutôt que par studio — Karma XPU pour le pass de look-dev natif USD, Karma CPU pour l'image héros volumétrique qui ne tiendra pas dans la VRAM, Redshift pour la séquence critique en termes de vitesse, Mantra pour la configuration de shaders historiques.

Le matériel sous-jacent se divise selon la même ligne CPU/GPU que les projets Houdini. Notre flotte CPU contribue plus de 20 000 cœurs CPU, là où la majorité du rendu de production se produit effectivement — dans l'industrie, et sur notre farm, le rendu CPU représente encore la plus grande part des tâches. Cette capacité CPU est ce qui rend Karma CPU et Mantra pratiques à l'échelle d'une séquence, et ce qui prend le relais de Karma XPU lorsqu'une image est trop lourde pour le GPU. Pour les travaux GPU, nos machines GPU dédiées sont équipées de cartes NVIDIA RTX 5090 avec 32 Go de VRAM chacune. Pour Karma XPU spécifiquement, ces 32 Go constituent le chiffre le plus important : la VRAM est le plafond effectif sur la complexité d'une scène avant que XPU cesse d'accélérer sur le GPU. Un jeu de textures UDIM 4K, un environnement instancié dense ou un VDB haute résolution peuvent chacun rapidement épuiser ce budget, et plus la carte est grande, plus vous allez loin avant que le rendu ne bascule silencieusement vers le CPU. Si vous étudiez les travaux GPU en général, nos notes sur le rendu GPU RTX 5090 approfondissent la carte, et la page GPU render farm plus générale couvre la flotte.

Schéma de Karma XPU et de la VRAM du GPU : une scène qui tient dans 32 Go de VRAM se rend à la vitesse hybride CPU+GPU, tandis qu'une scène dépassant la VRAM bascule vers le CPU.

La facturation suit le matériel : le rendu CPU est mesuré par GHz-heure et le rendu GPU par OctaneBench-heure, de sorte qu'une séquence Karma CPU et une séquence Redshift sont facturées sur les unités qui décrivent réellement le travail effectué. Parce que Karma XPU peut utiliser les deux appareils, le modèle mental le plus simple est qu'il est facturé comme du temps GPU lorsqu'il s'exécute sur un nœud GPU et reste dans la VRAM, la contribution CPU étant incluse — une autre raison pour laquelle il vaut la peine de respecter le plafond de VRAM.

Mise en cache des simulations : l'étape que vous ne pouvez pas ignorer

Voici le concept le plus important pour rendre Houdini sur n'importe quelle farm, et celui qui est le plus susceptible de faire perdre une journée s'il est mal compris : les images sont embarrassingly parallel, mais les simulations ne le sont pas.

L'image 1042 d'une animation rendue n'a pas besoin que l'image 1041 existe en premier — les deux peuvent être rendues sur des machines séparées au même moment. Cette indépendance est la raison même pour laquelle les render farms fonctionnent. Une simulation est l'inverse. L'image 1042 d'une sim Pyro est calculée à partir de l'état de la fumée à l'image 1041, qui provenait de 1040, jusqu'à la première image. Vous ne pouvez pas calculer le milieu d'une sim sans calculer tout ce qui précède, dans l'ordre, sur une seule machine. Envoyez une simulation brute à une farm et il n'y a rien à distribuer.

La résolution est déterministe et non négociable : simuler d'abord, mettre en cache sur disque, puis rendre le cache sur la farm. La simulation s'exécute séquentiellement sur une machine (ou une machine dédiée à la simulation) et écrit le résultat de chaque image sur disque. Ces fichiers de cache — maintenant des données statiques et indépendantes des images — sont ce que la farm rend. Les nœuds de rendu ne resimulent jamais ; ils lisent la géométrie et les volumes précalculés et tracent les images en parallèle comme pour toute autre animation.

Schéma du pipeline : une simulation est résolue séquentiellement sur une machine, mise en cache sur disque en VDB ou bgeo, puis rendue image par image en parallèle sur une render farm.

Ce que vous mettez en cache dépend du solveur :

Un détail qui mérite d'être souligné : il existe une vraie différence entre la simulation elle-même et le travail en aval. Le surfaçage FLIP — transformer des particules mises en cache en un maillage de rendu — ne dépend que des particules de chaque image, pas de l'image précédente, de sorte que cette étape est parallélisable et peut aller sur la farm comme sa propre passe, même si la sim sous-jacente ne le pouvait pas. Le schéma de plus en plus courant dans les pipelines Houdini 20 et au-delà est de mettre en cache la géométrie directement vers USD, afin que husk la lise nativement au moment du rendu sans étape de traduction SOP-vers-USD sur le nœud.

C'est également là que PDG/TOPs trouve toute sa place. PDG est le graphe de tâches conscient des dépendances de Houdini, et il modélise exactement la relation dont le rendu de farm a besoin : « mettre en cache cette simulation, et seulement une fois le cache disponible, rendre ces images depuis celui-ci. » Un File Cache TOP produit le cache de sim comme dépendance de sortie ; une tâche de rendu en aval attend et s'étale ensuite par image. PDG peut piloter à la fois la mise en cache et le rendu husk via ses nœuds de planification, c'est pourquoi il est devenu l'épine dorsale des pipelines Houdini sérieux en farm.

Une remarque pratique issue de l'expérience : les caches de tissu et de liquide haute résolution peuvent atteindre des gigaoctets par image, et lorsque des dizaines de nœuds extraient simultanément la même séquence depuis un stockage partagé, le débit de lecture — et non le calcul — devient le goulot d'étranglement. Nous acceptons les téléversements sans limite de taille stricte (nous suggérons de rester sous 300 Go par téléversement, et d'utiliser SFTP ou l'application cliente au-delà), et acceptons les archives .tar, .tar.gz et .7z — mais pas .zip. Repackagez les séquences de cache volumineuses en .tar.gz avant de les téléverser. La sortie rendue reste disponible pendant 45 jours après la fin d'une tâche, ce qui est suffisamment long pour télécharger une séquence complète.

Soumettre une tâche Karma XPU, de bout en bout

En assemblant les éléments, une tâche de farm Karma XPU propre s'exécute dans un ordre prévisible :

Flux de travail en six étapes pour soumettre une tâche Karma XPU à une cloud render farm : mettre en cache les simulations, exporter le stage USD, téléverser, choisir le moteur, distribuer les images, débruiter et télécharger.

1. Mettre en cache chaque simulation. Pyro en VDB, FLIP et Vellum en .bgeo.sc ou USD. Confirmez que les caches sont complets et continus en termes d'images — une image manquante en milieu de séquence se manifeste comme un trou dans le rendu, pas comme une erreur.
2. Exporter un stage USD composé avec vos primitives Render Settings et Render Var intégrées, tous les chemins d'assets résolus afin qu'ils soient accessibles depuis un nœud de rendu plutôt que depuis les lecteurs locaux de votre station de travail.
3. Packager le projet — scène, caches, textures et toute configuration OCIO — et le téléverser. Comme la farm est entièrement gérée, il n'y a pas de nœud où se connecter ni d'installation Houdini à surveiller.
4. Choisir le moteur. Karma XPU pour le look-dev en VRAM et les passes finales ; basculer vers Karma CPU pour les images que vous savez trop lourdes pour 32 Go ; choisir Redshift là où la vitesse est la priorité.
5. Distribuer les images. La farm étale la plage d'images sur les nœuds, chacun exécutant husk pour sa tranche. Vous suivez la progression plutôt que de la gérer.
6. Débruiter et télécharger. Récupérez les EXR (avec OIDN appliqué si vous l'avez configuré) dans la fenêtre de 45 jours.

Le mode d'échec récurrent dans tout cela est la résolution d'assets. USD résout les chemins par rapport à la couche qui les référence, ou en tant que chemins absolus, et un chemin absolu pointant vers le lecteur de votre station de travail locale produira simplement des textures manquantes ou une géométrie manquante sur un nœud de rendu — souvent sans erreur explicite, juste du noir là où un asset devrait se trouver. Résolvez les chemins par rapport à une racine de projet partagée, gardez votre configuration OCIO cohérente sur l'ensemble de la tâche afin que la couleur ne dérive pas, et aplatissez les dépendances HDA personnalisées dans l'USD avant l'export afin qu'un nœud n'ait pas besoin d'un plugin qui ne lui a jamais été fourni. Pour les fondamentaux plus larges de la façon dont le rendu cloud distribue ce type de travail, notre vue d'ensemble de la cloud render farm contextualise.

Quand choisir Karma XPU plutôt que Redshift

Karma XPU et Redshift peuvent tous deux rendre Houdini sur une farm GPU, et le choix ne porte pas sur lequel est « meilleur » — il porte sur ce dont le plan et le pipeline ont besoin. Ils proviennent de philosophies différentes. Karma XPU est physiquement basé, natif USD, utilisant le shading MaterialX, et fabriqué par le même éditeur que Houdini. Redshift est un moteur de rendu GPU mature, principalement biaisé, avec plus d'une décennie d'historique en production, un plugin Houdini, et — c'est sa caractéristique distincte en farm — un système out-of-core robuste qui déborde gracieusement de la VRAM vers la RAM système et le NVMe lorsqu'une scène devient trop volumineuse. Là où Karma XPU tend à basculer vers le CPU en cas de dépassement de VRAM, Redshift continue de rendre sur le GPU avec une pénalité de performance prévisible, c'est pourquoi une carte de 32 Go peut gérer des scènes bien supérieures à 32 Go de textures sous Redshift.

Cette différence oriente la plupart des décisions :

Les autres moteurs comblent les lacunes. Arnold est le choix pour les VFX lourds avec subsurface scattering complexe, cheveux et volumes, ou lorsqu'un pipeline dépend déjà de shaders spécifiques à Arnold — il suffit d'épingler la version HtoA sur les nœuds de farm et de pré-convertir les textures en .tx. V-Ray for Houdini convient aux studios déjà standardisés sur V-Ray dans 3ds Max et Maya qui souhaitent un rendu cohérent entre les DCC ; vous pouvez en savoir plus sur notre page Redshift sur le côté GPU de cette comparaison. Octane convient aux équipes déjà dans son écosystème spectral et nodal, et est facturé proprement par OctaneBench-heure. Si vous souhaitez une comparaison plus large entre fournisseurs plutôt qu'entre moteurs, notre comparaison de render farms Houdini couvre cette décision.

Une mise en garde spécifique à Karma XPU sur une farm : parce qu'une séquence peut contenir à la fois des images légères (accélérées GPU) et des images lourdes (silencieusement limitées par le CPU), les temps de rendu peuvent varier considérablement au sein de ce qui ressemble à une tâche uniforme. La solution est un contrôle de mémoire pré-lancement sur l'image la plus lourde avant de valider la plage entière — si elle va dépasser 32 Go de VRAM, choisissez délibérément entre Karma CPU sur la flotte CPU et le chemin out-of-core de Redshift plutôt que de laisser le moteur décider à mi-séquence. Au-delà du moteur lui-même, les pièges habituels des farms s'appliquent toujours : épinglez la version de Houdini, gardez la configuration du débruiteur explicite plutôt que de vous fier aux paramètres par défaut des nœuds, et vérifiez que chaque chemin d'asset se résout depuis un nœud et pas seulement depuis votre machine.

Pour les détails officiels du moteur, SideFX maintient une documentation approfondie pour Karma et le moteur de rendu en ligne de commande husk — à lire avant votre première soumission importante.

FAQ

Q: Quelle est la différence entre Karma XPU et Karma CPU ? A: Ce sont le même moteur de rendu Karma natif USD en deux modes d'exécution. Karma CPU s'exécute uniquement sur les cœurs CPU et implémente l'ensemble complet des fonctionnalités de qualité de référence. Karma XPU ajoute votre GPU NVIDIA et rend à la fois sur CPU et GPU pour plus de vitesse, mais prend actuellement en charge un sous-ensemble des fonctionnalités de Karma CPU et est limité par la VRAM du GPU. L'habitude pratique consiste à confirmer une image sur Karma CPU lorsque la sortie XPU semble incorrecte, car CPU est la référence absolue.

Q: Ai-je besoin d'une licence SideFX ou Houdini pour rendre Karma sur une cloud render farm ? A: Non, de votre côté, sur une farm entièrement gérée. Karma est fourni en bundle avec Houdini plutôt que sous licence séparée comme Redshift ou Octane, et nous exécutons Houdini sous utilisation render-only pour rendre vos tâches — nous ne sommes pas un partenaire SideFX et ne revendons pas de licences Houdini. Vous téléversez votre scène et vos caches ; la licence côté rendu sur nos nœuds est gérée dans le cadre du service managé.

Q: Pourquoi les simulations doivent-elles être mises en cache avant le rendu sur une farm ? A: Parce que les simulations sont séquentielles et les images ne le sont pas. Chaque image de simulation dépend de l'état de l'image précédente, de sorte qu'une sim doit être résolue dans l'ordre sur une seule machine. Les images de rendu, en revanche, sont indépendantes et peuvent s'exécuter sur des centaines de nœuds simultanément. La mise en cache de la simulation terminée sur disque (VDB pour Pyro, .bgeo.sc ou USD pour FLIP et Vellum) la transforme en données statiques que la farm peut rendre en parallèle sans resimulation.

Q: Comment Karma XPU gère-t-il une scène qui dépasse la VRAM du GPU ? A: Contrairement à Redshift, qui transfère les données depuis la mémoire système, Karma XPU tend à basculer vers l'exécution CPU lorsqu'une scène ne tient pas dans la VRAM. Le rendu se termine quand même, mais l'accélération GPU est perdue et l'image peut prendre beaucoup plus de temps — sans rien d'évident dans le journal. Pour les scènes que vous savez lourdes, il vaut mieux choisir délibérément Karma CPU sur la flotte CPU ou le chemin out-of-core de Redshift plutôt que de laisser le basculement se produire à mi-séquence.

Q: Karma XPU est-il plus rapide que Redshift ? A: Cela dépend du plan. Redshift est un moteur de rendu GPU très optimisé, principalement biaisé, et est souvent plus rapide sur les scènes de production typiques, en particulier les scènes intensives en VRAM où son système out-of-core maintient le travail sur le GPU. Karma XPU est physiquement basé et entièrement natif USD, ce qui est mieux adapté aux pipelines Solaris et au shading MaterialX, même s'il nécessite plus d'échantillons pour un bruit équivalent. La vitesse seule ne décide pas — l'adéquation au pipeline et la marge de VRAM généralement le font.

Q: Qu'est-ce que husk et dois-je l'utiliser directement ? A: husk est le moteur de rendu USD en ligne de commande autonome de SideFX, et c'est ce qui rend réellement Karma sur un nœud de farm — un processus léger qui charge un stage USD composé sans session Houdini complète. Sur une farm managée, vous ne l'invoquez pas manuellement ; vous soumettez votre scène et la farm exécute husk par image sur les nœuds à votre place. Savoir qu'il existe vous aide à comprendre pourquoi un export USD propre et entièrement résolu est si important.

Q: PDG/TOPs peut-il piloter un rendu Karma sur la farm ? A: Oui. PDG modélise la dépendance entre la mise en cache d'une simulation et le rendu depuis celle-ci, et ses nœuds de planification peuvent dispatcher à la fois l'étape File Cache et le rendu husk en aval sur une farm. C'est la méthode standard pour les pipelines Houdini sérieux pour exprimer « mettre en cache d'abord, puis étaler le rendu par image », et elle maintient automatiquement les parties séquentielles et parallèles de la tâche dans le bon ordre.

Q: Quels moteurs de rendu Houdini puis-je utiliser en dehors de Karma XPU ? A: Notre stack Houdini exécute Karma en modes XPU et CPU, plus Mantra, Redshift, Arnold, V-Ray for Houdini et Octane. Cette gamme vous permet d'adapter le moteur au plan — Karma XPU pour le look-dev natif USD, Karma CPU pour les images héros intensives en VRAM, Redshift pour la vitesse et l'out-of-core, Mantra pour les shaders VEX historiques, et Arnold, V-Ray ou Octane là où un pipeline en dépend déjà.