Configurer Houdini pour le rendu cloud

Houdini sur notre render farm est un environnement multi-renderers construit autour du pipeline moderne USD-first. Karma XPU est le chemin recommandé par SideFX pour les nouveaux projets sous Houdini 20.5 et le moteur de rendu principal mis en avant sur notre page de destination . Karma CPU et Mantra restent disponibles pour les travaux hérités ; les moteurs de rendu tiers — Redshift, Arnold, V-Ray pour Houdini, Octane — sont supportés pour les studios disposant de pipelines établis dans ces moteurs. Cette page couvre le packaging de projet (qui, dans Houdini, signifie HDAs et caches de simulation, pas seulement les textures), le flux de travail des assets Solaris/USD, les notes par moteur de rendu, le flux de soumission et le dépannage spécifique à Houdini que nous observons le plus souvent dans les tickets de support.

Une note sur les licences avant de commencer : nous opérons les installations Houdini sur la render farm sous utilisation render-only, qui permet d'exécuter Houdini sur les workers de rendu pour le rendu hors ligne des projets clients. Super Renders Farm n'est pas un partenaire SideFX — l'utilisation render-only est le cadre légal qui permet le rendu sur render farm des scènes Houdini sans occuper un siège SideFX du pool de licences de votre studio. Vous ne transférez pas votre licence Houdini vers nous, et les métadonnées de tier de projet côté artiste (Indie, Core, FX) ne déterminent pas l'arrangement de licence du worker. Le worker s'appuie sur les licences de la render farm de son côté.

Pour le positionnement de haut niveau — versions Houdini supportées, adéquation matérielle, exemples de tarification — la page de destination dédiée sur constitue la référence canonique. La page que vous lisez est le document de flux de travail : ce qu'il faut faire dans Houdini avant de cliquer sur Submit.

Versions supportées

Houdini 19.5, 20.0 et 20.5 sont pré-installés sur chaque worker de la render farm. Nous suivons le calendrier de sorties de SideFX et nous approvisionnons les nouvelles versions majeures dans les quatre semaines suivant leur disponibilité publique. Les versions ponctuelles (par exemple, Houdini 20.5.410 vs. 20.5.487) sont suivies en continu ; si votre projet est bloqué sur un numéro de build spécifique en raison d'un problème de compatibilité de nœud, mentionnez le build dans les notes du job au moment de la soumission et nous faisons correspondre le worker à celui-ci.

Les fichiers de scène Houdini FX (le tier production) et Houdini Indie (.hip et .hipnc) se chargent sur le worker et se rendent sous l'arrangement d'utilisation render-only de la render farm. Le tier côté artiste (Indie vs. Core/FX) ne se propage pas au siège de licence du worker — le worker utilise le tier que la render farm provisionne pour le rendu. Les fichiers Houdini Apprentice se rendent mais produisent une sortie avec filigrane conformément aux termes de la licence non commerciale de SideFX ; pour les travaux de production payants, sauvegardez la scène depuis une licence non-Apprentice avant la soumission. Les licences éducation suivent la même règle.

Une note sur le rythme de sorties de Houdini : SideFX livre des versions majeures tous les 12 à 18 mois et des mises à jour ponctuelles plus fréquemment. Karma XPU en particulier s'est considérablement amélioré entre 19.5, 20.0 et 20.5 — des fonctionnalités qui étaient en repli CPU dans 19.5 (volumes lourds, certains réseaux de shaders) sont natives XPU dans 20.5. Si votre projet dépend d'une fonctionnalité Karma XPU livrée dans un build spécifique, verrouillez le build dans les notes du job plutôt que de laisser le worker choisir la dernière version disponible.

Packager votre projet Houdini

Un projet Houdini, c'est plus qu'un simple fichier de scène .hip (ou .hipnc). Il inclut généralement aussi : les HDAs (Houdini Digital Assets — .hda ou l'ancien format .otl), les fichiers de cache de simulation (.bgeo, .bgeo.sc, .vdb, .abc), les couches et références d'assets USD (.usd, .usda, .usdc), les textures, et toute géométrie externe importée depuis des SOPs File ou Alembic. Le rendu cloud réussit quand chaque dépendance que la scène référence est présente sur le worker ; il échoue quand quelque chose se résout localement via un chemin propre à la station de travail mais n'a nulle part où se résoudre sur la render farm.

Les conventions de chemins de Houdini sont construites sur des variables d'environnement — le plus souvent $HIP (qui se résout vers le répertoire contenant le fichier .hip), $HIPNAME (le nom de base du fichier de scène) et $JOB (la racine du projet, définie via une variable d'environnement). Pour le rendu cloud, la convention fiable est les chemins relatifs à $HIP partout. Les étapes de packaging ci-dessous appliquent cette convention de bout en bout :

Définissez le dossier du projet. Lorsque vous sauvegardez un nouveau projet, Houdini définit $HIP sur le répertoire contenant le fichier .hip. Vérifiez dans le shell Python avec hou.text.expandString('$HIP') — le chemin doit correspondre à l'emplacement de votre fichier de scène.
Utilisez la structure de sous-dossiers standard. $HIP/cache/ pour les simulations, $HIP/geo/ pour Alembic et la géométrie externe, $HIP/tex/ pour les textures, $HIP/hda/ pour les digital assets, $HIP/usd/ pour les couches et références USD, $HIP/render/ pour la sortie. Tous les chemins dans les SOPs File de votre scène, les COPs File, les sorties ROP et les références de textures doivent utiliser $HIP/... plutôt que des chemins absolus avec lettre de lecteur.
Vérifiez que les chemins se résolvent. File → Refresh All. Houdini signale toute référence de fichier non résolue dans la Console. Depuis le shell Python, hou.fileReferences() retourne la liste complète des références externes — examinez-en chacune qui commence par D:\, Y:\, un partage UNC comme \\server\, ou tout chemin que le worker ne peut pas atteindre.
Bakez les simulations sur disque. La render farm n'exécute pas les simulations dans le cadre du job de rendu — les simulations relèvent du travail en station de travail, et la render farm effectue le rendu contre des fichiers de cache pré-bakés. Bakez tous les réseaux DOP (fluides FLIP, Pyro, tissu Vellum, RBD Bullet, grains), les solveurs de particules, et toute autre sortie de simulation en fichiers .bgeo.sc ou .vdb dans $HIP/cache/ avant la soumission. Le SOP File Cache avec « Save to Disk » est le flux de travail standard.
Embarquez ou incluez les HDAs. Si votre scène utilise des HDAs personnalisés issus d'une bibliothèque studio, soit embarquez-les dans le .hip (menu Asset → Save Operator Type → « Embedded »), soit incluez les fichiers .hda/.otl dans $HIP/hda/ pour que le worker puisse les charger depuis le dossier du projet. Les bibliothèques HDA partagées du studio sur des lecteurs réseau ne sont pas accessibles depuis le worker.
Aplatissez ou regroupez les couches USD. Si votre scène utilise Solaris/LOPs, soit bakez la stage USD en un seul fichier USD composé via le USD ROP avant la soumission, soit incluez l'intégralité de l'arborescence du répertoire $HIP/usd/ afin que chaque couche se résolve sur le worker. Les règles de résolution des assets USD sont couvertes en détail dans la section suivante.
Archivez l'intégralité du dossier $HIP. Utilisez .tar, .tar.gz ou .7z. Nous n'acceptons pas les uploads .zip pour les projets Houdini (les conventions de nommage de fichiers de Houdini contiennent parfois des caractères qui posent problème à l'intérieur d'archives .zip Windows sur des workers Linux).

Un piège spécifique à Houdini courant : les champs « Pre-Render Script » et « Post-Render Script » sur les nœuds ROP référencent parfois des scripts Python propres à la station de travail — les outils de pipeline de votre studio, un chemin de config Houdini local, un appel hou.ui.displayMessage qui ouvre une boîte de dialogue pour laquelle le worker n'a aucun écran. Le rendu cloud échoue alors silencieusement ou se bloque en attendant une entrée qui n'arrivera jamais. Auditez tout callback Python ou HScript de pré-rendu avant la soumission ; désactivez ou rendez portable tout code qui touche à des chemins exclusivement locaux, à des appels d'UI, ou à des hou.system() qui appellent des binaires de station de travail. Privilégiez la journalisation par print() plutôt que les callbacks interactifs.

Solaris, couches USD et résolution des assets

Si votre scène est créée dans Solaris (le réseau LOPs /stage), la couche de résolution des assets USD ajoute une dimension supplémentaire à la soumission cloud qui n'est pas présente dans les scènes purement OBJ/SOP. Le resolver USD de Houdini suit les règles standard de résolution d'assets USD : les références dans une couche sont résolues par rapport au chemin d'identifiant de la couche, aux chemins de recherche configurés via houdini.env ou le plugin de resolver d'assets, et à tous les arcs de composition utilisés par la stage (references, sublayers, payloads).

Pour la soumission cloud, deux schémas fonctionnent de manière fiable :

Aplatir la stage. Utilisez le nœud USD ROP avec « Save to Disk » et l'option « Flatten Stage » activée. Le résultat est un seul fichier .usd composé (ou .usdc pour le binaire) qui contient toute la stage avec toutes les références résolues. C'est le schéma le plus simple — le worker lit un seul fichier, sans indirection de resolver — mais vous perdez la structure en couches qui fait la valeur d'USD pour la collaboration.
Regrouper l'intégralité de l'arborescence d'assets. Placez toutes les couches USD sous $HIP/usd/ et utilisez des références relatives à $HIP dans vos sublayers, references et payloads. Le worker résout $HIP vers la racine d'upload, donc les fichiers de couches situés à la même position relative se chargent correctement.

Une subtilité : le LOP « Asset Reference » de Solaris et le SOP Reference dans les contextes /obj sérialisent tous deux le chemin de référence tel qu'écrit. Si vous avez écrit D:\studio_assets\char_robot.usd dans un LOP Reference, le worker n'a pas de D:\ et la référence échoue. Réécrivez la référence sous la forme $HIP/usd/char_robot.usd (ou ${SRF_ASSETS}/char_robot.usd avec un mappage de variable d'environnement documenté que la render farm honore). Plus le chemin est simple, plus il voyage de manière fiable.

Une deuxième subtilité : les bibliothèques d'assets USD peuvent porter leur propre indirection de versionnement. Une stage Solaris qui référence des assets USD compilés contre USD 23.x peut ne pas se charger proprement sur un worker avec USD 22.x livré dans un build Houdini plus ancien. La matrice de versions Houdini-USD compte — si votre bibliothèque d'assets a été créée pour la version USD de Houdini 20.5, effectuez le rendu sur des workers Houdini 20.5.

Gestion des HDAs

Les Houdini Digital Assets (HDAs, parfois encore vus avec l'ancienne extension .otl) sont des réseaux de nœuds réutilisables packagés sous forme de fichiers d'assets autonomes. Ils sont courants dans les pipelines de production, en particulier pour les assets procéduraux — bâtiments, végétation, systèmes de foule, solveurs personnalisés — qui sont créés séparément des plans individuels et partagés entre les scènes.

Trois schémas pour la gestion des HDAs sur la render farm :

Embarquer le HDA dans le fichier .hip. Menu Asset → Operator Type Manager → clic droit sur le HDA → « Save to Embedded ». Le HDA est désormais stocké à l'intérieur du .hip et voyage avec la scène. C'est le schéma le plus sûr pour les jobs ponctuels ou pour les HDAs que vous créez spécifiquement pour un seul plan.
Regrouper les HDAs dans $HIP/hda/. Placez tous les fichiers .hda/.otl dans un sous-dossier de votre projet, puis dans Houdini → Edit → Preferences → File Locations, assurez-vous que $HIP/hda/ fait partie du chemin de recherche OTL (alternativement, définissez HOUDINI_OTLSCAN_PATH pour inclure $HIP/hda/ dans votre houdini.env). Le worker lit les HDAs depuis cet emplacement lors du chargement de la scène.
Référencer les HDAs depuis une bibliothèque partagée du studio. Si votre studio utilise une bibliothèque HDA partagée sur un lecteur réseau (par exemple, \\studio-fs\houdini\hda\), cette bibliothèque n'est pas accessible depuis le worker. Soit copiez les HDAs pertinents dans $HIP/hda/ avant la soumission, soit embarquez-les dans le .hip.

Avant la soumission, listez les HDAs chargés dans la scène depuis le shell Python :

text

for hda in hou.hda.loadedFiles():
    print(hda)

Chaque chemin dans la sortie doit soit se résoudre sous $HIP, soit être un HDA standard SideFX livré avec Houdini lui-même (ceux-ci sont pré-installés sur chaque worker). Tout HDA tiers qui vit en dehors de $HIP ne sera pas trouvé.

Gestion des fichiers de cache

Les fichiers de cache constituent typiquement la plus grande catégorie individuelle dans un upload de projet Houdini — les simulations FLIP, les caches Pyro, les bakes de tissu Vellum, les exports Alembic et les volumes VDB peuvent chacun atteindre des dizaines ou des centaines de gigaoctets. Deux schémas réduisent le temps d'upload sans compromettre le rendu :

Compressez les caches au moment du bake. .bgeo.sc (bgeo compressé, compression blosc) est significativement plus petit que .bgeo pour la même géométrie et constitue le défaut moderne pour les SOPs File Cache. Pour les fichiers VDB, le volume est déjà compressé à l'intérieur du conteneur OpenVDB, mais les archives .tar.gz compressent bien les métadonnées de répertoire environnantes.
Utilisez $HIP/cache/ de manière cohérente. Le SOP File Cache de Houdini utilise par défaut $HIP/cache/{node_name}/$F4.bgeo.sc, qui est le bon schéma pour les scènes portables vers la render farm. Évitez les chemins de cache absolus comme D:\sim_cache\ — le worker n'a pas de D:\ et le rendu démarrera, enregistrera des avertissements « cannot find cache file » et produira une géométrie vide là où la simulation devrait se trouver.

Pour les très grandes simulations — caches FLIP ou Pyro de plusieurs téraoctets qui dépassent un upload navigateur — utilisez SFTP plutôt que le formulaire d'upload web. Le document couvre le flux de travail SFTP, la reprise d'archive et les seuils pratiques pour passer de l'upload web à SFTP.

Une note de flux de travail pour les studios qui cachent sur la station de travail mais rendent sur la render farm : si votre répertoire de cache se trouve sur un SSD local rapide et que votre fichier de projet utilise $HIP/cache/, le cache se déplace avec le projet lors de l'upload — aucun remappage manuel n'est nécessaire. Si le schéma de votre station de travail consiste à mettre en cache vers un lecteur réseau partagé et que votre .hip référence ce lecteur directement, vous devrez soit copier les caches dans $HIP/cache/ et mettre à jour les chemins du SOP File Cache, soit définir une variable d'environnement $JOB sur le worker qui reflète le partage réseau de la station de travail (moins fiable ; l'approche par chemin relatif est préférable).

Ce qu'il faut vérifier avant la soumission

Une courte checklist de pré-vol pour toute soumission Houdini :

Le nœud ROP actif est correctement défini. Output context → Render. Le ROP que vous sélectionnez au moment de la soumission détermine quel moteur de rendu le worker invoque. Les ROPs mal appariés (par exemple, sélectionner un ROP Karma pour une scène dont l'éclairage a été créé pour Mantra) sont la cause la plus fréquente des tickets « le rendu semble complètement différent ».
L'intervalle de frames correspond aux paramètres du ROP. L'intervalle de frames stocké sur le ROP (paramètres f1, f2, f3) est ce que le worker utilise, et non l'intervalle de lecture de la timeline ni la frame actuelle de la fenêtre de visualisation. Confirmez que l'intervalle de frames du ROP correspond bien à ce que vous souhaitez rendre.
Le chemin de sortie utilise des tokens relatifs à $HIP. $HIP/render/$F4.exr est le défaut sûr pour de l'EXR multicouches avec un padding à quatre chiffres. Évitez les chemins absolus avec lettre de lecteur dans l'expression de sortie du ROP.
Tous les SOPs File et références de textures se résolvent. File → Refresh All. Corrigez toute erreur « Unable to read » dans la Console avant la soumission — le worker les signalera également, mais au prix d'une frame de rendu gaspillée.
Les HDAs sont soit embarqués, soit dans $HIP/hda/. Vérifiez en fermant complètement la scène et en la rouvrant depuis une session Houdini différente ; si les HDAs échouent à se charger localement, le worker échouera également à les charger.
Les caches sont bakés. Exécutez un bake de cache manuel sur chaque SOP File Cache via Render → Save to Disk avant la soumission. Ne vous reposez pas sur « Auto-Bake on Frame Change » — bakez explicitement et confirmez que les fichiers de cache existent aux chemins $HIP/cache/... attendus.
Les couches USD (si Solaris) sont regroupées ou aplaties. Soit incluez l'arborescence complète $HIP/usd/, soit écrivez un USD composé aplati via le USD ROP.
Aucun script pré-rendu ou post-rendu interactif. Auditez les callbacks Python ROP et les Pre-Frame Scripts pour détecter tout appel d'UI, shell-out, ou chemin propre à la station de travail.

Notes spécifiques par moteur de rendu

Karma XPU (recommandé)

Karma XPU est le moteur de rendu hybride CPU+GPU de SideFX, promu au statut prêt-pour-la-production dans Houdini 20.5 et chemin par défaut tourné vers l'avenir pour les nouveaux projets Houdini. C'est le moteur de rendu principal sur notre page de destination Houdini et le chemin que la plupart des nouveaux clients adoptent sur la render farm.

Notes de configuration :

Tier de worker : S'exécute sur notre tier de workers GPU RTX 5090 (32 Go de VRAM par carte) pour la portion GPU du rendu, avec repli CPU pour toute fonctionnalité que le chemin de code XPU ne supporte pas encore.
Contraintes VRAM : 32 Go de VRAM par worker. Karma XPU est plus efficace en VRAM que les moteurs de rendu purement GPU car il peut décharger des portions du rendu (la volumétrie en particulier) vers la mémoire CPU lorsque la VRAM est contrainte — mais les scènes USD très denses avec des volumes haute résolution bénéficient quand même de rester dans l'enveloppe de 32 Go.
Intégration au pipeline USD. Karma est le moteur de rendu conçu pour le pipeline USD-first de Solaris. Si votre projet utilise /stage (contexte Solaris LOPs), Karma est le choix naturel de moteur de rendu et le worker résout les références d'assets USD de la même manière qu'il résout les références SOP File — les chemins relatifs à $HIP l'emportent.
AOVs. Configurés par render product dans le prim Render Settings de la stage USD. L'EXR multicanal est le format de sortie par défaut et c'est ce que nous recommandons pour les pipelines VFX (préserve tous les AOVs dans un seul fichier par frame).
Échantillonnage. Les échantillons de path-tracing de Karma sont configurés par prim Render Settings. Calibrez localement sur une seule frame avant de soumettre une séquence — la convergence d'échantillons de XPU diffère de celle du CPU, et la calibration se traduit directement vers le worker.
Motion blur. Karma XPU supporte le motion blur de géométrie et le flou de fenêtre d'obturation. Confirmez que votre réglage d'obturation de motion blur sur le prim caméra USD correspond à ce que le prim Render Settings attend — la gestion de l'obturation par Solaris et l'échantillonnage du motion blur de Karma ne s'accordent pas toujours dès le premier coup, et le symptôme est « le rendu semble correct mais le motion blur est manquant ou doublé ».

Karma CPU

Karma CPU est la variante purement CPU de Karma. Complète en fonctionnalités et stable depuis Houdini 19 ; le repli naturel pour les scènes qui dépassent la VRAM GPU ou qui dépendent de fonctionnalités pas encore implémentées dans le chemin de code XPU.

Notes de configuration :

Tier de worker : Tier de workers CPU (nœuds Dual Intel Xeon E5-2699 V4, 96 à 256 Go de RAM par nœud, plus de 20 000 cœurs CPU agrégés sur l'ensemble du parc).
Quand l'utiliser plutôt que Karma XPU : géométrie très lourde (>50M polygones), rendu volumétrique dense qui dépasse 32 Go de VRAM, shaders OSL personnalisés qui n'ont pas encore d'équivalent XPU, ou projets mélangeant des passes de simulation gourmandes en CPU dans la même soumission.
Même intégration Solaris/USD que Karma XPU. La configuration des render products et des AOVs est identique ; seul le backend de calcul diffère.

Mantra (legacy)

Mantra est le moteur de rendu pré-Karma de Houdini — le moteur micropolygones de SideFX qui précède le pipeline USD-first. SideFX a signalé que Mantra n'est pas la voie d'avenir ; Karma l'est. Mantra reste dans le build Houdini pour la compatibilité ascendante avec les projets créés avant que Karma ne soit viable.

Notes de configuration :

Tier de worker : Tier de workers CPU.
Performance. Mantra est généralement plus lent par frame que Karma CPU pour des scènes équivalentes et lui manque le chemin d'accélération GPU que Karma XPU fournit. Les nouveaux projets devraient utiliser Karma.
Quand l'utiliser. Lorsque votre fichier de projet est bloqué sur Mantra (une production de longue durée qui a démarré avant que Karma ne soit viable, une bibliothèque de shaders qui n'a pas été portée), ou lorsque vous avez besoin d'une fonctionnalité spécifique à Mantra (certains cas limites de micropolygones de Mantra n'ont pas encore d'équivalent Karma exact). Pour les nouveaux travaux en 2026, utilisez Karma par défaut.

Redshift pour Houdini

Redshift pour Houdini s'exécute sur notre tier de workers GPU RTX 5090. Redshift est le choix des studios avec des pipelines Redshift établis — souvent des shops Maya ou Cinema 4D qui se diversifient vers Houdini pour les FX et qui veulent partager des bibliothèques de shaders entre DCCs.

Notes de configuration :

Cadre de licence. Redshift sur notre render farm fonctionne sous notre licence . Redshift est désormais un produit Maxon, et notre partenariat Maxon couvre Redshift sur l'ensemble des DCCs que nous supportons (C4D, Houdini, Maya).
Mémoire out-of-core. Activée par défaut. Étend la mémoire effective de la scène au-delà du plafond de 32 Go de VRAM par worker, ce qui est important pour les scènes denses qui dépasseraient autrement la mémoire GPU.
Fonctionnalités spécifiques à Houdini. Redshift s'intègre directement avec les types de primitives de volume de Houdini (VDB, caches Pyro) — aucune étape d'export spéciale n'est nécessaire pour le rendu de volumes. Le ROP Redshift expose des paramètres natifs Houdini pour le ray bias, l'échantillonnage et la configuration des AOVs.
Verrouillage de version. Redshift sort sur son propre cycle 3.x, indépendant du rythme de sorties de Houdini. Les versions majeures de Redshift (3.0 → 3.5 → 4.0 lorsqu'il sortira) ne sont pas garanties rétrocompatibles — une scène sauvegardée avec Redshift 3.5.18 peut ne pas se charger proprement sur un worker exécutant Redshift 3.0.x. Notez le build Redshift au moment de la sauvegarde de la scène et confirmez la compatibilité du worker avant de soumettre une séquence complète.

Arnold pour Houdini

Arnold pour Houdini (parfois appelé HtoA, actuellement sur le cycle de sortie Arnold 7.x) s'exécute sur notre tier de workers CPU. C'est le choix des studios avec des pipelines Maya/Houdini Arnold partagés, où le lookdev est créé dans un DCC et les FX dans l'autre mais la couche de shaders et de rendu est unifiée.

Notes de configuration :

Cadre de licence. Arnold sur notre render farm fonctionne sous la licence Autodesk render-node.
AOVs. Le système d'AOVs d'Arnold dans Houdini fonctionne de la même manière que dans Maya. Configurez par ROP et écrivez vers de l'EXR multicanal ou des fichiers par AOV ; le schéma inter-DCC est cohérent.
Verrouillage de version. Les versions HtoA suivent le rythme de sorties d'Arnold (HtoA 6.x pour Houdini 19.5/20.0 ; HtoA 7.x pour Houdini 20.5/21.0 lorsqu'il sortira). Les sauts majeurs de HtoA (6 → 7) ne devraient jamais être présumés compatibles — confirmez que le worker dispose au moins de la version mineure avec laquelle votre scène a été sauvegardée.

V-Ray pour Houdini

V-Ray pour Houdini s'exécute sur notre tier de workers CPU. L'adoption dans Houdini est nettement plus faible que dans 3ds Max ou Maya, mais l'intégration est supportée pour les studios avec des pipelines centrés sur V-Ray.

Notes de configuration :

Cadre de licence. V-Ray sur notre render farm fonctionne sous notre licence .
Assets VRayProxy. Supportés. Incluez les fichiers .vrmesh dans $HIP/geo/ afin que le worker puisse les résoudre.
Spécificités Houdini. Le ROP de V-Ray pour Houdini expose les mêmes paramètres de rendu que V-Ray dans 3ds Max — type de sampler, render elements (AOVs), format de sortie. Le mappage de paramètres inter-DCC est documenté dans la référence V-Ray pour Houdini de Chaos.

Octane pour Houdini

Octane pour Houdini s'exécute sur notre tier de workers GPU RTX 5090. Utilisé principalement par les studios de motion design qui font le pont entre Houdini et Cinema 4D pour des sorties stylisées.

Notes de configuration :

Cadre de licence. Licence Otoy render-node.
Contraintes VRAM. Les mêmes que pour Octane pour C4D — 32 Go de VRAM par worker, avec un profil mémoire plus agressif que Redshift (pas de chemin out-of-core). Les scènes qui tiennent dans 24 Go sur Redshift peuvent nécessiter un sous-échantillonnage des textures ou une décimation de géométrie pour tenir dans 32 Go sur Octane.

Flux de soumission

Trois canaux de soumission fonctionnent pour les projets Houdini sur la render farm :

Upload web + soumission via le dashboard. Archivez le dossier $HIP en .tar.gz ou .7z, uploadez via le site web, puis configurez le job (moteur de rendu, nœud ROP, intervalle de frames, format de sortie) et soumettez. C'est le chemin le plus courant pour les jobs Houdini ponctuels et les projets sous environ 50 Go de taille totale d'upload.
SFTP pour les gros projets. Les projets Houdini avec des caches de simulation de plusieurs téraoctets devraient passer par SFTP pour des transferts reprenables. Voir pour le flux de travail SFTP, les identifiants, et le seuil pour passer de l'upload web à SFTP.
Client App. La Super Renders Farm Client App enveloppe l'upload, la soumission et le téléchargement automatique dans une application desktop. Utile pour les studios avec des soumissions récurrentes où la même structure de projet est re-rendue avec des changements de paramètres. Voir .

Un plugin de soumission pour Houdini qui s'intègre directement à l'interface Houdini est en cours de développement mais n'est pas encore pré-installé sur tous les workers. Pour l'instant, le flux de soumission via le dashboard web est le chemin recommandé. La visite guidée inter-DCC de la soumission — ce qu'il faut remplir, comment définir l'intervalle de frames, où trouver les fichiers de sortie — se trouve dans le .

Sous le capot, le worker invoque les points d'entrée de rendu batch de Houdini : hbatch pour les soumissions de fichiers HIP vers des ROPs en contexte OBJ/SOP (Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane), et husk pour les soumissions de stage USD vers Karma (CPU ou XPU). Vous n'avez généralement pas besoin de connaître l'invocation sous-jacente, mais si vous déboguez un comportement inattendu de nommage de sortie ou d'intervalle de frames, les paramètres au niveau du ROP sont ce que le worker passe à hbatch/husk via des flags de ligne de commande.

Dépannage des échecs spécifiques à Houdini

Pour le dépannage général inter-DCC (asset manquant, rendu échoué à la frame N, problèmes courants de format de sortie), voir . Les schémas d'échec spécifiques à Houdini que nous voyons le plus souvent dans les tickets de support :

« Unable to find HDA » ou un HDA échoue à se charger avec un placeholder de nœud obsolète. Le worker ne peut pas localiser le fichier HDA que la scène référence. Vérifiez que les HDAs sont soit embarqués dans le .hip (menu Asset → Operator Type Manager → « Save to Embedded »), soit présents dans $HIP/hda/ avec le chemin de recherche configuré. Si vous référencez des HDAs depuis une bibliothèque partagée du studio, copiez-les dans le dossier du projet avant la soumission.
Fichier de cache non trouvé au rendu / géométrie de simulation vide. Vérifiez que les fichiers de cache ont bien été bakés sur disque avant la soumission — ouvrez chaque SOP File Cache et confirmez que l'onglet « Output » affiche les fichiers au chemin affiché. Si le chemin utilise une lettre de lecteur absolue (D:\sim_cache\flip.0001.bgeo.sc), changez-le en $HIP/cache/{node_name}/$F4.bgeo.sc et re-bakez. La vérification de 60 secondes avant l'upload — File → Refresh All, plus un scan manuel des SOPs File Cache — prévient la plus grande catégorie unique d'échecs de rendu Houdini que nous voyons.
Les sorties de rendu sont complètement vides / frames noires. Vérifiez le prim « Render Settings » du ROP (pour Karma sur une stage Solaris) ou la référence de caméra (pour Mantra, Redshift, Arnold, V-Ray, Octane sur des ROPs en contexte /obj). La cause la plus courante est une caméra qui est définie dans la fenêtre de visualisation mais pas référencée dans le ROP — le worker n'a pas de fenêtre de visualisation, donc la référence de caméra au niveau du ROP fait autorité.
Karma XPU échoue immédiatement avec « OptiX not available » ou « GPU not detected ». Rare sur notre render farm car le parc de workers GPU dispose d'une couverture confirmée des pilotes CUDA + OptiX. Si cela se produit, la cause la plus courante est un worker en cours de mise à jour ou un rollback de pilote en cours ; resoumettez 5 à 10 minutes plus tard ou contactez le support si le problème persiste sur plusieurs soumissions.
Le script Python de pré-rendu échoue sur le worker. Désactivez le script ou rendez-le portable en termes de chemins. Le Python personnalisé qui référence des chemins de modules propres à la station de travail (les outils de pipeline de votre studio), ouvre des boîtes de dialogue UI ou shell-out vers des binaires locaux via hou.system() ne s'exécutera pas sur un worker Linux sans tête.
Les références d'assets Solaris / USD cassent. Les chemins du resolver d'assets USD doivent être relatifs à $HIP, utiliser un contexte de resolver USD que le worker peut charger, ou être aplatis en un seul USD composé via le USD ROP avant la soumission. Les chemins absolus dans les couches de référence USD sont le mode d'échec le plus courant ici.
Décalage de version de plugin / la scène échoue à se charger. La version locale du plugin diffère de celle du worker — le plus souvent les sauts HtoA 6 → 7 ou Redshift 3.0 → 3.5. Vérifiez la version du plugin au moment de la sauvegarde de la scène (visible via le texte d'en-tête du fichier HIP ou le tampon de version dans le menu ROP du plugin) et confirmez que le worker dispose au moins de cette version mineure. Les sauts de version majeurs ne devraient jamais être présumés compatibles.
Décalage de version Houdini (scène 20.5 sur worker 20.0). Le format de fichier HIP inclut des métadonnées de version ; un Houdini plus ancien ne peut pas ouvrir les scènes sauvegardées avec une version plus récente. Confirmez que le worker dispose de Houdini ≥ la version de sauvegarde de la scène, ou ré-enregistrez la scène dans la version cible si c'est absolument nécessaire.
La simulation OpenCL échoue à s'exécuter au rendu. Les simulations OpenCL se font au bake, pas au rendu. Bakez vers le cache avant la soumission. La render farm n'exécute pas de simulations OpenCL en direct pendant le rendu — c'est par conception et cela s'applique à FLIP, Pyro, Vellum et à tout autre solveur accéléré par OpenCL.
Dérive de config OCIO entre la soumission et le worker. Si votre variable d'environnement OCIO locale pointe vers une config propre au studio non présente sur le worker, les couleurs sont rendues sous la config par défaut du worker et semblent différentes. Regroupez le fichier de config OCIO avec le projet, définissez OCIO via l'override d'environnement de soumission, ou utilisez la config ACES intégrée à Houdini que le worker livre également.
Avertissement « missing field » des caches Pyro/FLIP entre versions de Houdini. Le format de fichier de cache change occasionnellement entre les versions majeures de Houdini ; un cache plus ancien chargé sur un Houdini plus récent perd parfois des champs. Re-cachez la simulation dans la version cible de Houdini, ou confirmez que le worker utilise le même build Houdini que celui qui a écrit le cache.

Références croisées

— flux de travail upload, soumission, téléchargement (inter-DCC)
— comment les coûts des jobs Houdini sont calculés (tiers GPU vs CPU)
— guide SFTP, formats d'archive, transferts de gros projets
— dépannage inter-DCC
— wrapper desktop de soumission
— page de destination (matrice des moteurs de rendu, matériel, exemples de tarification)

FAQ

Q : Quelles versions de Houdini la render farm supporte-t-elle ? A : Houdini 19.5, 20.0 et 20.5 sont pré-installés sur chaque worker. Nous suivons le calendrier de sorties de SideFX et nous approvisionnons les nouvelles versions majeures dans les quatre semaines suivant leur disponibilité publique. Les fichiers de scène Houdini FX (.hip) et Houdini Indie (.hipnc) sont tous deux supportés. Les fichiers Houdini Apprentice se rendent mais produisent une sortie avec filigrane selon les termes de la licence non commerciale de SideFX — pour les travaux de production payants, sauvegardez la scène depuis une licence non-Apprentice avant la soumission.

Q : Dois-je transférer ma licence Houdini pour effectuer un rendu sur la render farm ? A : Non. Nous opérons Houdini sous utilisation render-only, qui permet d'exécuter Houdini sur les workers de rendu pour le rendu hors ligne sans occuper un siège SideFX du pool de licences de votre studio. Votre licence Houdini locale reste avec vous. Super Renders Farm n'est pas un partenaire SideFX — l'utilisation render-only est le cadre légal qui permet le rendu sur render farm des scènes Houdini.

Q : Devrais-je utiliser Karma XPU, Karma CPU ou Mantra pour un nouveau projet ? A : Karma XPU pour les nouveaux projets en 2026 — c'est le chemin recommandé par SideFX, il s'exécute sur notre tier GPU RTX 5090 et il est significativement plus rapide que Karma CPU ou Mantra pour la plupart des scènes. Utilisez Karma CPU pour les scènes qui dépassent 32 Go de VRAM, qui s'appuient sur de la volumétrie lourde qui déborde le GPU, ou qui utilisent des shaders OSL personnalisés non encore supportés en XPU. N'utilisez Mantra que lorsque votre projet est bloqué sur Mantra (une production de longue durée démarrée avant que Karma ne soit viable, ou une fonctionnalité de shader spécifique à Mantra sans équivalent Karma). Pour les nouveaux travaux, utilisez Karma par défaut.

Q : La render farm peut-elle exécuter des simulations Houdini (Pyro, FLIP, Vellum, RBD) ? A : Non — les simulations relèvent du travail en station de travail. Bakez tous les caches de simulation en fichiers .bgeo.sc ou .vdb localement avant la soumission. La render farm effectue le rendu contre des caches pré-bakés ; elle n'exécute pas de simulation en direct dans le cadre du job de rendu. C'est le même schéma que les flux de travail de simulation Blender ou Maya sur la plupart des render farms cloud gérées.

Q : Mon projet utilise le pipeline Solaris/USD de Houdini. Sera-t-il rendu correctement ? A : Oui, avec Karma (CPU ou XPU) comme moteur de rendu. Le chemin conçu pour Solaris est Karma — les deux moteurs de rendu consomment la stage USD nativement et l'intégration Solaris/Karma est le pipeline forward recommandé par SideFX. Pour la soumission cloud, soit aplatissez la stage USD en un seul fichier .usd composé via le USD ROP, soit regroupez l'intégralité de l'arborescence du répertoire $HIP/usd/ afin que chaque couche se résolve sur le worker. Les moteurs de rendu tiers (Redshift, Arnold) peuvent également rendre des scènes basées USD si leur intégration Houdini le supporte — vérifiez localement sur une seule frame avant de soumettre une séquence complète.

Q : Ma scène utilise des HDAs personnalisés issus de la bibliothèque partagée de notre studio. La render farm les trouvera-t-elle ? A : La render farm ne trouvera pas les HDAs sur le lecteur réseau partagé de votre studio (\\studio-fs\hda\... ou équivalent). Soit embarquez les HDAs dans le .hip via le menu Asset → Operator Type Manager → « Save to Embedded », soit copiez les fichiers .hda/.otl dans $HIP/hda/ avant d'archiver le projet. Vérifiez avec hou.hda.loadedFiles() depuis le shell Python que chaque HDA chargé se résout sous $HIP ou est un asset standard SideFX.

Q : Comment package-t-on un projet Houdini qui utilise des caches de simulation ? A : Bakez chaque simulation vers $HIP/cache/{solver_name}/$F4.bgeo.sc (ou .vdb pour les volumes) localement avant la soumission. Vérifiez que les fichiers de cache existent aux chemins attendus via File → Refresh All. Archivez l'intégralité du dossier $HIP — y compris le sous-dossier cache/ — en .tar.gz ou .7z. Pour les caches de plus de quelques centaines de gigaoctets, uploadez via SFTP plutôt que par le formulaire web. La render farm effectue le rendu contre les caches bakés ; la simulation elle-même s'exécute sur votre station de travail, pas sur un nœud worker.

Q : Quelle peut être la taille d'un upload de projet Houdini ? A : Il n'y a pas de limite stricte de taille d'upload, mais nous recommandons de maintenir un upload navigateur unique sous environ 50 Go. Au-dessus, passez à SFTP pour des transferts reprenables — voir . La render farm a géré des rendus de sim Houdini de plusieurs téraoctets, tous uploadés via SFTP avec la structure de répertoires correctement préservée.

Q : Mon rendu Mantra est beaucoup plus lent sur la render farm qu'en local. Est-ce attendu ? A : La vitesse par frame de Mantra sur notre tier de workers CPU (Dual Xeon E5-2699 V4) est comparable à celle d'une station de travail haut de gamme. Si vous constatez des temps par frame significativement plus lents que localement, les causes les plus probables sont : une configuration d'échantillonnage différente sur le worker (Mantra lit les échantillons depuis le ROP — confirmez que les réglages au niveau du ROP correspondent), ou une accélération OpenCL locale qui n'est pas active sur le tier purement CPU du worker. La correction structurelle est la migration : Karma XPU sur notre tier GPU est significativement plus rapide que Mantra pour la plupart des scènes, et Karma est le chemin que SideFX recommande pour l'avenir.

Q : La render farm supporte-t-elle PDG/TOPs de Houdini pour la gestion distribuée des tâches ? A : PDG est une orchestration côté station de travail ; la render farm utilise son propre système de file d'attente et d'assignation de workers. Vous pouvez utiliser PDG localement pour créer et baker les assets, puis soumettre les jobs ROP finaux à la render farm via le dashboard web ou la Client App. La soumission directe pilotée par PDG vers des render farms externes figure sur notre roadmap mais n'est pas encore un flux de travail de première classe.

Q : Comment le coût est-il calculé pour le rendu cloud Houdini ? A : Le coût de Houdini sur la render farm suit le tier de worker du moteur de rendu — les tarifs GPU pour Karma XPU, Redshift et Octane ; les tarifs CPU pour Karma CPU, Mantra, Arnold et V-Ray pour Houdini. La complexité par frame (nombre d'échantillons, nombre d'AOVs, résolution de sortie) pilote le coût par frame ; le choix de moteur de rendu pilote le tarif par nœud-heure. Les simulations ne coûtent extra que si vous les exécutez sur la render farm (nous recommandons de cacher localement et d'uploader le cache). Pour les détails de tarification, voir ou estimez via notre .

---