TOPs et PDG

Calcul distribué et itération procédurale dans Houdini

Que sont TOPs et PDG ?

TOPs (Task Operators) et PDG (Procedural Dependency Graph) forment l'un des systèmes les plus ambitieux ajoutés à Houdini ces dernières années. Officiellement introduits dans Houdini 18, ils changent fondamentalement la façon de construire un pipeline de production : au lieu de traiter les tâches séquentiellement, TOPs/PDG permet de les orchestrer en parallèle, de les distribuer sur plusieurs machines, et de les relier par des dépendances explicites.

L'idée centrale est simple mais puissante : chaque opération - simulation, rendu, baking, génération de géométrie - devient un nœud dans un graphe de dépendances. Ce graphe, le PDG, sait exactement dans quel ordre exécuter les tâches, lesquelles peuvent s'exécuter en parallèle, et comment le résultat d'une tâche alimente la suivante. C'est un véritable chef d'orchestre pour toute la chaîne de production.

Mais TOPs ne se limite pas au rendu distribué. C'est un outil de calcul procédural généraliste : utilisez-le pour générer des centaines de variations d'un asset (un rocher avec différents paramètres aléatoires, par exemple), pour lancer des simulations en lot, pour baker des textures en masse, ou pour automatiser des pipelines complexes traversant plusieurs logiciels. En bref, TOPs est un système universel de parallélisation et d'automatisation intégré directement à Houdini.

TOPs vs. PDG : quelle différence ?

PDG (Procedural Dependency Graph) est le moteur sous-jacent - le système conceptuel qui modélise les dépendances entre tâches et gère leur exécution. TOPs (Task Operators) sont les nœuds visuels qu'un artiste place dans le réseau pour définir ces tâches. En pratique, les deux termes sont souvent utilisés de façon interchangeable, mais la distinction est utile : PDG est l'architecture, TOPs est l'interface.

Concepts fondamentaux de PDG

Work Items

L'unité de base de PDG est le Work Item. Chaque tâche à exécuter - rendre une image, générer une variation d'asset, lancer une simulation - est représentée par un Work Item, qui porte des attributs (paramètres, chemins de fichiers, valeurs numériques) et un statut (en attente, en cours, terminé, erreur).

Quand un nœud TOP génère plusieurs Work Items - disons, 50 variations de paramètres différentes - chacun est traité indépendamment et potentiellement en parallèle. C'est ce mécanisme qui transforme un workflow séquentiel classique en un workflow massivement parallèle.

Le graphe de dépendances

Les nœuds TOP sont reliés entre eux dans un graphe qui définit les dépendances. Si le nœud B dépend du nœud A, Houdini s'assure que chaque Work Item de A se termine avant que ceux de B ne commencent. Les dépendances peuvent être simples (une tâche après une autre) ou complexes (plusieurs branches parallèles fusionnant dans un seul nœud).

Schedulers

Un Scheduler décide comment et où les Work Items s'exécutent. Houdini en propose plusieurs selon le contexte :

  • Local Scheduler - exécute les tâches sur la machine locale via le multithreading ; le choix par défaut pour le travail quotidien.
  • HQueue Scheduler - distribue les tâches sur un réseau de machines via HQueue ; idéal pour les fermes de rendu locales.
  • Deadline Scheduler - intégration avec le gestionnaire de rendu Deadline de Thinkbox (AWS) ; un standard de l'industrie.
  • Python Scheduler - pour implémenter des schedulers personnalisés ciblant n'importe quel système tiers.

Architecture d'un réseau TOP

Un réseau TOP se construit dans le contexte /tasks de Houdini (accessible via le menu du Network Editor ou depuis un nœud TOP Network dans le contexte SOP ou OBJ). La logique de construction suit toujours le même schéma : des nœuds générateurs en entrée, des nœuds de traitement au milieu, et des nœuds de résultat ou de conditionnement en sortie.

Nœuds générateurs essentiels

  • Generic Generator - génère un seul Work Item simple, un point de départ basique pour tester un réseau.
  • Wedge - le nœud le plus important pour les variations. Génère N Work Items en variant un ou plusieurs paramètres sur une plage définie (valeurs discrètes, plage continue, ou liste de valeurs). Le cœur de toute approche d'itération procédurale.
  • File Pattern - génère un Work Item par fichier correspondant à un motif ; idéal pour traiter un lot d'assets ou de caches existants.
  • Partition by Frame - découpe une séquence d'images en Work Items individuels pour le rendu distribué.

Nœuds de traitement clés

  • Houdini Processor - exécute un réseau SOP/DOP/ROP à l'intérieur d'un Work Item ; le nœud le plus polyvalent, capable d'exécuter n'importe quelle opération Houdini.
  • ROP Fetch - déclenche le rendu d'un nœud ROP existant (/out) dans le contexte d'un Work Item - un lien direct vers le pipeline de rendu de Houdini.
  • ROP Geometry - exporte la géométrie SOP vers un fichier externe (Alembic, USD, bgeo) par Work Item ; essentiel pour la génération en lot de variations d'assets.
  • Python Script - exécute un script Python dans le contexte du Work Item, permettant d'intégrer n'importe quel outil externe ou logique personnalisée.
  • Shell Script - exécute une commande shell, ouvrant l'accès à n'importe quel outil en ligne de commande.
  • Wait for All - un point de synchronisation qui attend que tous les Work Items en amont soient terminés avant de continuer.

Exemple concret : générer des variations de rocher

Voici un exemple concret et instructif qui montre exactement à quoi sert TOPs/PDG : générer automatiquement N variations d'un rocher procédural, chacune avec des paramètres différents (taille, rugosité, nombre de fractures, seed aléatoire), exportées vers des fichiers séparés, avec un rendu d'aperçu automatique pour chaque variation.

Étape 1 : préparer le réseau SOP du rocher

Avant de construire le réseau TOP, il faut un réseau SOP qui génère le rocher de façon procédurale et paramétrique. Un workflow typique dans le contexte /obj :

  • Sphere SOP - géométrie de base, haute subdivision (icosaèdre, 4 subdivisions).
  • Mountain SOP - déformation par bruit pour la forme générale du rocher. Paramètres exposés : Amplitude, Roughness, Element Size, Seed.
  • PolyReduce SOP - réduction polygonale pour l'aspect rocheux et anguleux. Paramètre exposé : Percentage.
  • Facet SOP - durcit les normales pour un aspect cristallin/fracturé.
  • Transform SOP - mise à l'échelle générale. Paramètre exposé : Scale.

Les paramètres exposés au niveau du nœud parent (via le Parameter Editor) sont ceux que TOPs va faire varier : Amplitude, Roughness, Seed, Scale - exposés via Parameters > Edit Parameter Interface.

Étape 2 : construire le réseau TOP

Dans le contexte /obj, créer un nœud TOP Network et double-cliquer pour y entrer. Construire cette chaîne de nœuds :

  1. Ajouter un nœud Wedge - il génère toutes les variations. Configurer le nombre de variations (disons, 16) et les attributs à varier : 
    Attribute 1: rock_seed    | Type: Integer | Min: 0   | Max: 99
Attribute 2: rock_rough   | Type: Float   | Min: 0.1 | Max: 0.8
Attribute 3: rock_scale   | Type: Float   | Min: 0.5 | Max: 2.0
  2. Connecter un Houdini Processor au Wedge - il exécute le réseau SOP du rocher pour chaque Work Item, en mappant les attributs du Work Item aux paramètres Houdini : 
    @rock_seed   -> ch('../geo1/mountain1/seed')
@rock_rough  -> ch('../geo1/mountain1/roughness')
@rock_scale  -> ch('../geo1/transform1/scale')
  3. Connecter un nœud ROP Geometry au Houdini Processor, exportant la géométrie générée vers un fichier Alembic ou bgeo par variation : 
    Output File: $HIP/rocks/rock_`@wedgeindex`.abc
  4. Ajouter éventuellement un nœud ROP Fetch pour rendre automatiquement une image d'aperçu de chaque variation avec Karma ou Mantra.
  5. Connecter un nœud Wait for All pour synchroniser une fois chaque variation terminée, avant une étape finale (assembler un catalogue, envoyer une notification, etc.).

Étape 3 : exécuter et surveiller le réseau

Pour exécuter le réseau TOP, cliquer sur le bouton Cook du nœud terminal (ou clic droit > Cook Network). Houdini lance les Work Items selon la disponibilité du Scheduler. Dans le viewport TOP, chaque Work Item s'affiche visuellement :

  • Cercle blanc - Work Item en attente.
  • Cercle jaune - Work Item en cours.
  • Cercle vert - Work Item terminé avec succès.
  • Cercle rouge - Work Item échoué. Clic droit > Open Task Graph pour diagnostiquer.

Le Task Graph View (Windows > Task Graph Table) donne une vue tabulaire de chaque Work Item, ses attributs, son statut et ses logs - le principal outil de débogage pour un réseau TOP.

Le nœud Wedge : maîtriser l'itération

Wedge est probablement le nœud TOP le plus utilisé en production, générant un ensemble de Work Items en variant un ou plusieurs paramètres selon différentes stratégies.

Modes de variation de Wedge

  • Range (Float/Integer) - varie linéairement entre un minimum et un maximum sur N échantillons. Exemple : Seed de 0 à 99 sur 10 itérations.
  • Value List - varie à travers une liste spécifique de valeurs. Exemple : Scale avec les valeurs [0.5, 1.0, 1.5, 2.0, 2.5].
  • Random - génère des valeurs aléatoires dans une plage, produisant des résultats différents à chaque exécution.

Combiner plusieurs attributs

Avec plusieurs attributs définis dans un seul Wedge, le comportement dépend du mode de combinaison :

  • Independent (par défaut) - chaque attribut varie indépendamment ; le nombre total de Work Items est le produit des variations de chaque attribut. Avec 4 valeurs de Seed et 3 valeurs de Scale, on obtient 4 × 3 = 12 Work Items.
  • Simultaneous - les attributs varient ensemble, en parallèle. Avec 4 valeurs de Seed et 4 valeurs de Scale, on obtient 4 Work Items (chaque paire associée).

Lire les attributs Wedge dans les SOP

Dans les expressions Houdini sur les nœuds SOP ou dans les paramètres du Houdini Processor, les attributs du Work Item sont accessibles via :

detail('opinput:0', 'rock_seed', 0)   # dans une expression VEX ou SOP
@rock_seed                              # dans un Attribute Wrangle
`@rock_seed`                            # dans un paramètre chaîne (backticks)

Cas d'usage avancés

Générer des bibliothèques d'assets procéduraux

L'un des usages de production les plus puissants de TOPs est la génération automatique de bibliothèques d'assets. En combinant Wedge et Houdini Processor, on peut générer des centaines de variations d'un même asset en une nuit (rochers, arbres, bâtiments, débris) avec des paramètres aléatoires contrôlés, exportées dans le format souhaité avec textures bakées - ce qui prendrait des semaines à modéliser à la main se fait en quelques heures de calcul distribué.

Pipelines de simulation en lot

TOPs peut lancer des dizaines de simulations (fluides, RBD, pyro) avec différentes conditions initiales, rassembler les résultats, et les comparer automatiquement - simuler 20 destructions RBD du même bâtiment avec différentes forces d'impact, exporter des caches Alembic pour chacune, et générer un rendu d'aperçu pour choisir la meilleure variation à pousser en rendu complet.

Baking de textures en masse

Le baking procédural à grande échelle est un cas d'usage courant. TOPs peut itérer sur une liste d'assets (chargée via un File Pattern), exécuter un Houdini Processor par asset qui fait le dépliage UV et le baking de cartes (normal, AO, roughness, height), et tout assembler dans une structure de dossiers organisée - automatisant entièrement le traitement pour des centaines d'assets.

Rendu distribué et optimisation

Pour les projets d'animation, TOPs avec un HQueue Scheduler distribue le rendu image par image sur un réseau de machines. Mais TOPs va plus loin : il peut gérer intelligemment les dépendances (simuler d'abord, puis rendre, puis compresser les images, puis assembler la vidéo), relancer automatiquement les images échouées, et envoyer une notification une fois tout terminé.

Intégrer des logiciels externes

Via les nœuds Shell Script et Python Script, TOPs peut orchestrer des outils hors de Houdini : appeler Substance Painter pour texturer un asset, lancer Blender pour une opération spécifique, déclencher des scripts Nuke pour le compositing, ou interagir avec des API web. TOPs devient le chef d'orchestre de tout un pipeline multi-logiciels.

Attributs et flux de données

La communication entre les nœuds d'un réseau TOP se fait principalement via les attributs des Work Items. Comprendre comment les attributs sont créés, transmis et modifiés est essentiel pour construire des réseaux TOP robustes.

Types d'attributs

  • Integer/Float/String - des valeurs scalaires simples, le type le plus courant pour les paramètres de variation.
  • File - un chemin vers un fichier d'entrée ou de sortie ; les attributs de type fichier permettent à Houdini de gérer automatiquement les dépendances de fichiers.
  • @pdg_input / @pdg_output - des attributs spéciaux contenant les fichiers d'entrée et de sortie d'un Work Item, utilisés par Houdini pour construire automatiquement le graphe de dépendances.

Transmettre les attributs

Par défaut, chaque nœud TOP hérite des attributs du Work Item entrant et peut en ajouter de nouveaux. L'attribut wedgeindex (l'index du Work Item au sein du Wedge, commençant à 0) est particulièrement utile pour nommer les fichiers de sortie de façon unique :

$PDG_DIR/rock_v`@wedgeindex`_seed`@rock_seed`.abc

La variable $PDG_DIR est le répertoire de travail du PDG, configurable dans les réglages du TOP Network. $PDG_TEMP est un répertoire temporaire que Houdini gère automatiquement pour les fichiers intermédiaires.

Bonnes pratiques

Organiser un réseau TOP

  • Utiliser des nœuds Null pour nommer les étapes - comme pour les réseaux SOP, nommez vos jalons (OUT_wedge, OUT_sim, OUT_render) pour la lisibilité et une connexion facile depuis d'autres contextes.
  • Commenter généreusement - les réseaux TOP complexes peuvent vite devenir illisibles ; les commentaires (touche C) et les couleurs de nœuds sont essentiels.
  • Découper en sous-réseaux - pour les pipelines complexes, utiliser des nœuds TOP Subnetwork pour encapsuler des groupes fonctionnels de nœuds.

Déboguer efficacement

  • Tester d'abord avec 1 ou 3 Work Items - avant de lancer 100 variations, réduire temporairement le Wedge à 1 ou 3 itérations pour confirmer que le réseau fonctionne.
  • Utiliser le Task Graph Table - Windows > Task Graph Table pour inspecter les attributs et logs de chaque Work Item.
  • Clic droit > Open Failed Work Items - voir rapidement quels Work Items ont échoué et accéder à leurs logs détaillés.
  • Dirty et re-cook sélectif - clic droit sur un nœud > Dirty > Dirty All Below pour forcer le recalcul uniquement à partir d'un point précis du réseau.

Performance et chemins réseau

  • Utiliser des chemins UNC absolus - pour le rendu distribué en réseau, chaque chemin de fichier doit être accessible depuis chaque machine (\server\projects\...).
  • Préférer bgeo.sc aux formats texte - pour les caches intermédiaires, le bgeo.sc compressé se lit et s'écrit bien plus rapidement que les formats ASCII.
  • Limiter la résolution d'aperçu - pendant la phase d'exploration des variations, rendre en basse résolution (512×512) pour itérer rapidement, puis re-rendre en pleine résolution une fois la variation choisie.
  • Éviter les chemins locaux (C:\Users\) - ils ne fonctionneront jamais sur les machines esclaves d'un réseau distribué.

Ressources

← Précédent : Nuages, atmosphère et éclairage d'environnement