Le rendu en réseau dans Houdini

HQueue, PDG/TOPs, et déléguer des rendus à une ferme

Préparation et optimisation avant un rendu réseau

Avant de lancer un rendu distribué, avoir une vision claire du projet : identifier précisément quelles séquences ont besoin d'être rendues et leurs timings respectifs. Lancer des rendus de test locaux sur plusieurs images, en particulier les plus complexes, et ajuster les réglages de qualité pour réduire le temps de rendu tout en préservant la qualité visuelle. Enregistrer systématiquement quelles images ont été rendues et combien de temps chacune a pris - ces données deviennent la base de planification du job complet.

Planifier soigneusement les besoins techniques : moteur de rendu, plug-ins nécessaires, et stratégie de distribution. Avec plusieurs machines disponibles, décider si des rendus spécifiques doivent être délégués à une machine particulière, ou si toutes les machines doivent travailler collectivement sur la même plage d'images. Déléguer les simulations à des machines locales et sauvegarder systématiquement les caches de rendu pour éviter de les recalculer pendant le rendu final.

Données et architecture réseau

Quand un projet contient beaucoup de données (fichiers de scène, caches de rendu, textures), garder à l'esprit que le rendu réseau distribue et envoie ces données à chaque machine assignée au rendu. La machine la plus rapide et la plus puissante devrait servir de MASTER/distributeur, tandis que les machines moins puissantes sont configurées comme SLAVE. Alternativement, stocker toutes les données sur un NAS et configurer le projet Houdini ou Blender pour tirer les ressources directement depuis lui, évitant entièrement la duplication de données.

Une fois un projet terminé, testé et prêt à rendre, toujours lancer une passe de collecte de ressources/package pour s'assurer que chaque fichier référencé se trouve sur un chemin accessible aux nœuds de rendu.

HQueue : le gestionnaire de rendu de Houdini

Le rendu réseau distribué a besoin d'un gestionnaire de rendu. Bien que des solutions tierces existent, Houdini fournit le sien : HQueue, construit sur une architecture MASTER/SLAVE. Installer un Houdini Launcher sur chaque machine locale et un HQueue Client sur chaque machine esclave qui participera au rendu. Le serveur HQueue Master coordonne la distribution des tâches, tandis que les clients HQueue sur les machines esclaves reçoivent et exécutent les jobs de rendu.

Vérifier que vous avez réellement accès à suffisamment de nœuds de rendu/licences. Houdini est typiquement livré avec un nœud master et 10 nœuds de rendu de base ; accéder à davantage nécessite l'achat d'une licence supplémentaire.

Render Nodes vs. Drivers

Avant de configurer le rendu réseau, il est essentiel de comprendre la différence entre Render Nodes et Drivers :

  • Render Nodes (/out) - des nœuds dans le contexte /out (Output) de Houdini. Ils définissent quoi est rendu (la scène, les objets, les effets) et comment (réglages de qualité, résolution, échantillonnage). Les principaux Render Nodes sont Mantra (PBR, Micropolygon), Karma (XPU, CPU), le ROP Arnold, le ROP Redshift, et d'autres moteurs tiers.
  • Drivers - des paramètres à l'intérieur d'un Render Node contrôlant où et quand les rendus ont lieu : chemins d'image de sortie, format de fichier (EXR, PNG, TIFF), la plage d'images à rendre, les options de rendu par lots d'images, et les réglages de soumission au scheduler (local, HQueue, PDG).

En résumé : Render Node = qui/quoi/comment, Driver = où/quand.

Configurer HQueue et le Scheduler

Installation et configuration

  1. Télécharger et installer le serveur HQueue sur votre machine Master (sidefx.com/products/hqueue).
  2. Installer les clients HQueue sur chaque machine Slave.
  3. Configurer les chemins réseau partagés pour que chaque machine puisse accéder aux fichiers du projet.
  4. Dans Houdini, aller dans Edit > Preferences > HQueue Server et entrer l'URL de votre serveur (typiquement http://[MASTER_IP]:5000).

Préparer la scène (essentiel)

  • Sauvegarder la scène avec la sauvegarde automatique activée (File > Save As, avec l'auto-save activé) - absolument essentiel pour éviter la perte de données.
  • Créer une caméra dans le contexte /obj, positionnée selon votre composition.
  • Créer un Render Node dans /out (Mantra ou Karma, selon le besoin).
  • Configurer l'onglet Driver de ce Render Node - chemin de sortie, format d'image, et plage d'images.

Soumettre à HQueue (méthode classique)

  1. Dans votre Render Node (Mantra/Karma), aller dans l'onglet Driver.
  2. Cliquer sur Render et choisir « Submit Render to HQueue ».
  3. Le HQueue Scheduler s'ouvre, permettant de régler la plage d'images, la priorité du job, les machines cibles (ou laisser HQueue distribuer automatiquement), les images par tâche (chunking), et les dépendances entre jobs (par exemple des simulations qui doivent se calculer d'abord).
  4. Confirmer - le job est ajouté à la file HQueue, et la progression peut être suivie via l'interface web HQueue (http://[MASTER_IP]:5000).

Choisir un moteur de rendu pour les jobs de ferme

Les moteurs natifs de Houdini : Mantra PBR pour un rendu photoréaliste moderne avec support complet des matériaux PBR, illumination globale et caustiques - idéal pour la plupart des projets VFX actuels ; Mantra Micropolygon, le moteur historique de Houdini, excellent pour une géométrie extrêmement détaillée (millions de polygones), des effets de displacement complexes, et un rendu stylisé, moins utilisé aujourd'hui mais toujours pertinent pour des workflows spécifiques ; et Karma, le nouveau moteur de path tracing moderne de SideFX basé sur USD - à utiliser pour des rendus de haute qualité dans des workflows USD, des performances optimisées, et une intégration pérenne. Karma est l'avenir du rendu de Houdini, offrant des temps de rendu compétitifs avec une qualité exceptionnelle.

Moteurs tiers compatibles : Arnold (Autodesk) - la référence de l'industrie pour le cinéma et les VFX, utilisé par ILM, Sony Pictures et d'autres ; un path tracer robuste et fiable avec une excellente qualité d'image mais des temps de rendu plus longs, idéal pour le cinéma haut de gamme. RenderMan (Pixar) - le moteur historique de Pixar, la référence absolue pour les longs-métrages d'animation, optimisé pour les cheveux, la fourrure et le subsurface scattering complexes, utilisé dans tous les studios Pixar et Disney. Redshift (Maxon) - un moteur GPU biaisé extrêmement rapide, parfait pour l'itération rapide et les délais serrés, un excellent ratio qualité/vitesse, très populaire en publicité et motion design, nécessitant un GPU NVIDIA puissant. Octane (OTOY) - un moteur GPU non biaisé avec un rendu spectral physiquement correct, populaire pour les rendus photoréalistes et l'archviz, avec une interface intuitive et un rendu de viewport temps réel ; nécessite aussi un GPU NVIDIA. Guerilla Render - un moteur français optimisé pour d'énormes volumes de données (végétation dense, foules), utilisé notamment par Mikros Image et BUF Compagnie, excellent pour les environnements naturels complexes. AMD ProRender - le moteur open source d'AMD, compatible avec n'importe quelle carte graphique (AMD, NVIDIA, Intel), gratuit mais moins performant que les solutions commerciales - intéressant si vous possédez déjà une carte AMD.

Avancé : le Render Scheduler PDG/TOPs

Pour des workflows plus complexes et professionnels, Houdini 21 offre une approche moderne via PDG (TOPs) et le Render Scheduler.

Démarrer avec le Python Scheduler

  1. Créer un TOP Network dans le contexte /tasks.
  2. Ajouter un nœud Python Scheduler - il permet d'écrire des callbacks Python pour gérer la planification, le lancement et le nettoyage des tâches de rendu.
  3. Configurer les callbacks clés : onStart (initialiser l'état du scheduler à l'enregistrement), onSchedule (définir la logique de planification des work items/chunks, en retournant True en cas de succès), onSubmitAsJob (lancer tout le TOP Network comme un job autonome et récupérer son URI de statut), et onStartCook/onStopCook (actions à exécuter au début/à la fin d'un cook - utile pour préparer ou nettoyer le contexte d'exécution).

Supervision via le panneau Render Scheduler

L'activer via Windows > Render Scheduler. Il permet de superviser les rendus en cours (pause/kill), de basculer l'affichage selon les besoins, de suivre les rendus distribués et d'interagir avec les files d'attente, et de surveiller les nœuds de calcul et leur statut.

Intégrer une ferme existante

Pour intégrer PDG à une infrastructure de ferme de rendu existante, basculer le scheduler par défaut vers un compatible avec cette solution via le menu contextuel du nœud Scheduler (« Set As Default Scheduler ») - alignant PDG avec une infrastructure offline ou réseau partagée (RenderMan, Redshift, Arnold, HQueue, Deadline, etc.).

Astuces pratiques : travailler depuis un répertoire réseau partagé (PDG convertit automatiquement les chemins locaux en chemins distants selon le contexte d'exécution, mais un système de fichiers partagé simplifie beaucoup la vie) ; tester d'abord avec un petit TOP Network et une poignée d'images avant de lancer un rendu de ferme complet ; utiliser la journalisation pour aider à déboguer les callbacks et le statut des jobs ; et définir clairement les dépendances (par exemple des simulations qui doivent se calculer avant le rendu, ou du compositing qui doit s'exécuter après).

Une chaîne de workflow réseau complète : TOPs avec un Python Scheduler → files d'attente de tâches → Render Scheduler → agents de ferme (clients HQueue, workers Deadline, etc.) → supervision centralisée. Cette chaîne permet de tester, déboguer et ajuster le flux de rendu réseau étape par étape.

Houdini offre plusieurs façons de lancer des rendus distribués : directement depuis l'interface via le Scheduler (HQueue ou PDG), via le rendu par lots en ligne de commande, ou via la console Python pour un contrôle programmatique complet. Pour gagner du temps et des ressources, il vaut la peine de lancer les rendus distribués via une console ou une petite application de gestion de rendu plutôt que de garder l'interface complète de Houdini ouverte.

Matériel des machines esclaves

Si les PC de rendu (esclaves) n'ont pas besoin d'exécuter des calculs de simulation ni un usage GPU intensif (rendu CPU uniquement), une carte graphique simple suffit - il vaut alors mieux investir dans la RAM et des processeurs multicœurs puissants à la place. Surveiller les goulots d'étranglement réseau ou matériels, qui ralentiront même la machine la plus puissante. Utiliser la machine la plus lente comme référence pour estimer les temps de rendu - les machines plus rapides terminent alors en avance en bonus, évitant les mauvaises surprises à l'approche de l'échéance.

Il est possible d'écrire un script Python pour gérer la distribution de rendu et parler directement à l'API de Houdini, mais c'est généralement inutile pour les petits ou moyens projets - c'est surtout réservé aux fermes de rendu professionnelles.

Fermes de rendu externes

Les rendus peuvent aussi être délégués à des fermes de rendu professionnelles, qui évitent souvent les casse-têtes techniques locaux (goulots d'étranglement, gestion HQueue, infrastructure). RanchComputing (ranchcomputing.com) est une ferme avec plusieurs avantages pratiques : hébergement européen (conformité RGPD), support en français, tarification comparable aux autres fermes, et - notamment - une véritable intégration Houdini, que de nombreuses fermes n'ont pas puisque SideFX ne distribue pas largement ses licences.

Workflow RanchComputing

  1. Lancer des rendus de test locaux et enregistrer les temps par image.
  2. Télécharger le plugin RanchChecker.
  3. Le déposer dans le dossier OTLS de Houdini et lancer Houdini.
  4. Aller dans le contexte TOP Nodes.
  5. Ajouter un nœud RanchChecker et collecter les ressources du projet.
  6. Envoyer le fichier à la ferme.
  7. Choisir un niveau de priorité/coût et lancer le rendu.
  8. Attendre qu'un créneau de file d'attente se libère.
  9. Une fois terminé, un e-mail permet de télécharger les images via FTP (par exemple FileZilla), ou vous pouvez demander à Ranch de synchroniser chaque image rendue directement vers vous.
Avant d'envoyer un job à Ranch, lancer un test Cinebench R15 pour évaluer la puissance de la machine locale, puis noter le temps de rendu moyen par image sur votre PC - RanchComputing l'utilise pour estimer coût et temps avec une comparaison. Toujours tester quelques images d'abord, même à un certain coût : une fois qu'un rendu de ferme démarre, il est facturé que le résultat déçoive ou non. RanchComputing peut aussi exécuter des simulations sur une ferme GPU dédiée séparément du rendu d'image final - envisager de répartir simulation et rendu final entre ferme et local selon votre stratégie de production. Démarrer tôt compte : le véritable avantage d'une ferme de rendu est de racheter des semaines de temps pour des corrections critiques, du montage, ou du sound design.

Équivalent Blender : RanchComputing supporte aussi Blender avec un workflow similaire. Blender dispose en plus de son propre système de rendu réseau, Flamenco (flamenco.blender.org), un gestionnaire de rendu open source de la Blender Foundation utilisant une architecture manager/worker équivalente à master/slave.

Autres fermes de rendu notables

  • RebusFarm (rebusfarm.net) - une ferme allemande avec un excellent support pour 3ds Max, Cinema 4D, Maya et Blender.
  • GarageFarm (garagefarm.net) - très populaire, tarification compétitive, bon support Houdini et Blender.
  • Fox Render Farm (foxrenderfarm.com) - basée en Chine, tarification très attractive, support 24/7.
  • Conductor (conductortech.com) - une solution cloud premium utilisée par les grands studios.
  • AWS Thinkbox Deadline - la solution cloud d'AWS, évolutivité maximale.
  • Google Zync (zyncrender.com) - la plateforme cloud de Google, intégration GCP.

Ressources

← Voir aussi : TOPs et PDG : le calcul distribué Retour aux articles →