Un pipeline pratique d'environnement Houdini vers Karma

1. Configuration du projet

Démarrer un nouveau projet Houdini et définir l'échelle/l'unité - en VFX, le mètre est le standard (1 unité = 1m, le défaut de Houdini). Décider de la taille générale de l'environnement dès le départ (disons, une île de 2×2km) comme référence d'échelle pour tout ce qui suit.

2. Terrain et érosion

Dans le contexte OBJ, ajouter un nœud Geometry nommé « Terrain ». À l'intérieur, utiliser HeightField pour créer un terrain plat de la taille cible (2000m pour une île de 2km). Appliquer un HeightField Noise pour le relief initial (ajuster type de bruit et amplitude), puis enchaîner un HeightField Erode pour simuler l'érosion naturelle - régler les itérations (2000, 5000...) jusqu'à obtenir un réseau de vallées crédible, et surveiller les cartes de sédiment et de flux qu'il produit, car elles seront utilisées en aval.

3. Masques

Ajouter un HeightField Mask by Feature configuré pour un masque de pente (1 sur les pentes raides, 0 sur le terrain plat) pour séparer la roche de l'herbe, et un masque d'altitude pour la neige en haute élévation ou la végétation dépendante de l'altitude. Combiner les masques (multiplier pente × altitude pour un masque « neige sur sommets plats »). Utiliser le visualiseur de masque pour vérifier les zones, et peindre manuellement (HeightField Paint Mask) pour forcer des zones spécifiques - par exemple peindre en blanc où un lac doit se trouver. Masques typiques à préparer : mask_water (peint ou issu de l'accumulation de flux), mask_rock (pente > 45°), mask_field (zones plates de basse altitude).

4. Disperser l'environnement

Décider quels objets vont peupler la scène et les importer ou les construire (souvent conservés dans un subnet Assets séparé ou chargés via File/FBX). Pour chaque type d'objet, exécuter un scatter distinct pour contrôler indépendamment densité et placement :

• Arbres - Scatter sur la surface du terrain, Density par exemple 1 point par 50m², en utilisant mask_field comme masque de densité pour que les arbres n'apparaissent que dans les vallées non raides. Ajouter des Relax Iterations (par exemple 5) pour éviter le regroupement. Randomiser pscale (par exemple 0.8-1.2× l'échelle de base) et l'orientation via Attribute Randomize. Alimenter un Switch entre les modèles d'arbres plus les points de scatter dans Copy to Points, avec Pack et Instance activés pour une scène légère.
• Rochers - Scatter sur mask_rock, avec une densité éventuellement modulée par l'altitude (plus dense à la base des éboulis). Copy to Points avec 2 modèles de rocher ou plus, en variant l'échelle pour quelques gros blocs parmi de nombreuses petites pierres.
• Herbe - éviter de disperser brin par brin (trop lourd) ; disperser plutôt des touffes ou paquets d'herbe - par exemple 5000 points combinant mask_field et l'inverse de mask_rock, copiant une touffe modélisée. L'herbe en billboard peut plutôt être gérée par des sprite cards pilotées par shader.
• Eau - extraire mask_water en un polygone, l'extruder légèrement vers le bas, et appliquer un shader d'eau. Des rivières en mouvement nécessiteraient une simulation FLIP (souvent hors du cadre d'un environnement statique) ; une alternative plus simple anime un bump d'ondulation à partir de la texture de flux d'érosion.

5. Revoir la mise en scène

Naviguer dans le viewport avec une caméra de rendu candidate et rechercher les problèmes : arbres sur des pentes impossibles (affiner le masque), rochers flottants (vérifier l'alignement du ray-au-sol), densité d'instances trop élevée ou trop faible par endroits (peindre les masques localement pour ajouter ou retirer). Utiliser la vue de dessus pour vérifier la distribution globale, et essayer quelques variations de seed de scatter - l'approche procédurale rend cela presque gratuit.

6. Shading

Assigner les matériaux une fois la mise en scène établie :

• Matériau de terrain - un Principled Shader mélangeant les textures de roche et d'herbe piloté par mask_rock, avec du displacement micropolygone pour le détail rocheux (tiré de la couche de sédiment). Karma ne rend pas le volume HeightField brut - le convertir d'abord en maillage ou en shader de displacement.
• Matériaux arbre / rocher / herbe - assigner les propres textures PBR des assets (écorce, feuilles) dans des Principled Shaders ; activer le cutout opacity sur l'alpha des feuilles/herbe si nécessaire - Karma le supporte nativement.

Réutiliser les cartes de sédiment et de flux générées plus tôt comme masques de shader pour un réalisme supplémentaire - la carte de flux comme masque de glossiness pour simuler un sol humide dans les creux, la carte de sédiment pour décaler la couleur du sol vers un beige sableux dans les zones de dépôt. Exporter ces cartes via HeightField Output vers des images, ou les passer comme attributs via HeightField → Volume → Attribute From Volume.

7. Solaris, éclairage et aperçu Karma XPU

Passer dans le contexte LOP (Solaris) pour l'éclairage et le rendu Karma. Créer un Stage et importer le terrain et la géométrie d'instances - importer chaque élément séparément (plutôt qu'un seul groupe fusionné) simplifie l'assignation de matériau par élément. Ajouter un Sky Dome Light avec un HDRI, ou le Physical Sun & Sky de Solaris ; un Dome Light avec une teinte bleu clair plus un Sun Light (parallèle, angle ~45°, forte intensité) donne des ombres diurnes crédibles. Ajouter un brouillard atmosphérique via le nœud Environment Settings si vous voulez de la brume de distance.

Basculer le viewport sur Karma XPU pour un aperçu interactif rapide CPU+GPU - vérifier que les matériaux se rendent correctement, confirmer que toutes les instances d'arbres s'affichent (surveiller les réglages de culling d'instances), et itérer l'éclairage en temps réel. XPU a encore quelques lacunes par rapport à Karma CPU (certains types de volume/displacement, certains AOV comme Cryptomatte pas toujours disponibles) - le traiter comme un outil d'interactivité, et prévoir le CPU pour le rendu final.

8. Rendu final et compositing

Ajouter un nœud Karma Render Settings et choisir le moteur CPU pour la passe finale (plus fiable que XPU pour le support complet des fonctionnalités). Régler la résolution (par exemple 1920×1080) et les Pixel Samples (par exemple 128+ selon la complexité de la scène). Activer les AOV nécessaires - beauty, diffuse, direct/indirect, depth, cryptomatte - et ajuster des limites comme le nombre max de rebonds (à augmenter pour le réalisme des feuilles translucides) et le seuil de bruit. Rendre d'abord une petite région de test pour calibrer le nombre d'échantillons avant un passage sur l'image complète.

Utiliser soit le Render to Disk du nœud Karma, soit la ligne de commande husk (rendu USD) pour la passe finale ; une image full-HD avec beaucoup de géométrie/instances/volumes peut prendre de quelques minutes à plusieurs heures selon les échantillons. Surveiller la mémoire - si elle est serrée, réduire le nombre de polygones du terrain lointain (LOD) ou s'appuyer davantage sur l'instanciation. Pour les séquences animées, soumettre via le ROP Karma, ou scripter Houdini avec PDG pour rendre des tuiles ou des images en parallèle.

Inspecter la sortie pour repérer une végétation flottante (problèmes d'alignement de normale) ou des motifs trop répétitifs (varier les seeds aléatoires, placer quelques arbres à la main). Amener les AOV dans un logiciel de compositing (Nuke, After Effects, Fusion) pour l'étalonnage final, le flou atmosphérique, et tout matte painting de distance - une passe Z-depth peut piloter un brouillard progressif en post-production, et les cryptomattes facilitent l'isolation, disons, de tous les rochers pour un étalonnage séparé. Un rendu Houdini direct est presque jamais utilisé tel quel dans un pipeline professionnel ; c'est le compositing qui vend l'image.

Exemple concret : montagne et lac

Un parcours concret : un paysage de montagne avec un petit lac.

• Terrain - un HeightField de 2000×2000m, première passe avec HeightField Noise utilisant un motif Ridged Multi-fractal (bon pour simuler l'érosion naturelle des crêtes), amplitude de 200m. Puis HeightField Erode, 3000 itérations, précipitation 0.2, temps d'érosion 0.5.
• Lac - HeightField Paint creuse une dépression où le lac doit se trouver ; un masque est extrait plus tard pour construire la surface d'eau.
• Masques - mask_slope avec un seuil à 30° pour les zones raides, mask_altitude pour la neige au-dessus de 190m, mask_erosion directement issu de la couche de sédiment du nœud Erode. Combinés, ces masques cartographient précisément la roche exposée, les zones herbeuses et les sommets enneigés.
• Végétation - 3 modèles de conifères (cadre montagneux), dispersés avec une densité inversement proportionnelle à l'altitude - jusqu'à 1 arbre par 30m² dans les vallées, s'éclaircissant avec l'élévation. Des buissons ajoutés sur les pentes moyennes (15-25°) pour la transition forêt-vers-roche-nue.
• Éclairage et rendu - un soleil de fin d'après-midi à 30° d'élévation pour des ombres longues et dramatiques sur le relief, une légère brume atmosphérique pour la profondeur, et une touche de brume matinale sur le lac.
• Résultat - un rendu final 4K à 256 échantillons a pris environ 1h30 sur CPU, produisant une image photoréaliste avec des reflets de soleil sur l'eau, des ombres d'arbres douces, et des textures de détail différenciées selon le terrain.

Conseils généraux applicables à tout projet de ce type : travailler de façon itérative (commencer léger sur les instances/la résolution, monter progressivement en échelle), mettre en cache sur disque les calculs lourds plutôt que de les recalculer, vérifier la cohérence d'échelle tôt (placer une référence humaine - un décalage d'échelle arbre/bâtiment ruine plus d'environnements que tout autre chose), surveiller les artefacts de terrassement HeightField (un léger HeightField Smooth peut les corriger), diviser les scènes lourdes en couches (arrière-plan vs. premier plan) rendues et compositées séparément, et garder les paramètres exposés sur tout HDA construit pour que les variantes soient bon marché à générer.

Intégration moteur : Unity, Unreal, Omniverse

Houdini Engine

Houdini Engine est le plug-in d'intégration de SideFX pour Maya, 3ds Max, Unreal, Unity et plus. L'idée : construire un réseau procédural dans Houdini, l'encapsuler dans un Houdini Digital Asset (HDA) avec des paramètres exposés, puis charger cet asset dans Unity ou Unreal via le plug-in Engine, qui exécute Houdini en arrière-plan sans interface pour générer du contenu dans l'éditeur cible. Un outil de route procédural est l'exemple classique - un artiste construit le HDA dans Houdini (dessiner une courbe, obtenir la géométrie de route, trottoirs, lampadaires), et un level designer dans Unreal place la courbe directement dans l'éditeur, ajustant la largeur ou le nombre de lampadaires sans jamais ouvrir Houdini. Ubisoft intègre Houdini Engine dans ses moteurs maison et Unreal pour que les designers puissent créer des variations de terrain et de ville sans toucher à l'interface de Houdini.

En pratique : installer « Houdini Engine for Unity » ou le plugin « HoudiniEngine » pour Unreal. Les deux gèrent la conversion automatique des entrées (les objets Unity/Unreal peuvent alimenter l'asset comme entrées), les mises à jour dynamiques, et le baking vers des maillages statiques une fois le résultat figé - après quoi le HDA peut même être retiré tandis que les maillages bakés restent. Houdini Engine nécessite sa propre licence (incluse avec Indie et d'autres éditions) ; les productions gardent typiquement un pool de licences Engine flottantes exécutant des calculs Houdini en arrière-plan déclenchés depuis Unreal/Unity.

USD comme format d'échange

USD (Universal Scene Description), développé par Pixar, est le format natif de Houdini dans le contexte Solaris/LOP - toute scène LOP peut exporter vers un ou plusieurs fichiers .usd contenant tout l'environnement (terrain, placements d'arbres, caméras, lumières, shaders compatibles MaterialX). Unreal Engine 5 ajoute le support des Stages USD, donc un environnement Houdini Solaris peut être exporté et importé comme un Stage USD dans Unreal, récupérant maillages, instances (potentiellement converties en Hierarchical Instanced Static Meshes) et caméras - un transfert plus « brut » mais efficace qui préserve les instances et la hiérarchie, évitant une duplication mémoire N-fois d'arbres identiques.

NVIDIA Omniverse

Omniverse est construit entièrement sur USD comme épine dorsale - une plateforme collaborative où plusieurs applications travaillent sur la même scène via un serveur Omniverse Nucleus. Houdini dispose d'un connecteur Omniverse construit par NVIDIA permettant une synchronisation en direct : Houdini peut ouvrir/éditer un stage USD hébergé par Omniverse et pousser les changements en direct, via le nœud LOP OmniLayer. Un artiste peut ajuster le terrain dans Houdini pendant qu'un autre éclaire la scène dans Omniverse Create, voyant les mises à jour arriver en temps réel. NVIDIA a aussi construit un chargeur de Houdini Digital Asset pour Omniverse USD Composer, permettant aux HDA de se charger directement dans Omniverse à peu près comme le fait Houdini Engine pour les éditeurs de jeu.

Matériaux et éclairage à travers la frontière

Via Houdini Engine, le plug-in convertit les Principled Shaders simples en matériaux Unity Standard ou Unreal PBR, bien que pas toujours 1:1 - un motif courant consiste à taguer un groupe (« rock ») pour le faire correspondre à un matériau moteur manuellement pré-construit (« M_Rock »). Les lumières sont généralement reconstruites nativement dans le moteur cible pour la meilleure fidélité, puisqu'un Sun Light Houdini ne se traduit pas parfaitement. Via USD, les lumières (UsdLux) se transfèrent partiellement dans Unreal, et les shaders MaterialX se convertissent partiellement vers Unreal via USDShade-to-MDL - un workflow encore en évolution, donc le transfert de géométrie seule plus un ré-éclairage natif dans le moteur reste courant. Omniverse, étant profondément natif USD, est la cible la plus fluide : les lumières Dome/Sun créées dans les LOP et les shaders MaterialX/USD Preview Surface passent fidèlement, rendus physiquement par le moteur RTX d'Omniverse Create.

Exemple concret : un HDA de terrain vers Unreal

• Dans Houdini - construire un HDA « Modular Terrain Generator » : génère un heightfield via bruit et érosion, crée des masques de texture (roche, herbe, sable), disperse des assets via masques et règles, définit des zones jouables via un autre masque, et expose des paramètres comme « Forest Density », « Mountain Height », « Random Seed ».
• Dans Unreal - installer le plugin Houdini Engine, importer le HDA, et laisser le level designer le placer, ajuster les paramètres de densité/hauteur selon les besoins de gameplay, et même peindre des masques directement dans Unreal qui remontent vers Houdini Engine, qui régénère géométrie, masques et UV.
• Optimisation - une fois le design figé, baker en maillages statiques : les arbres deviennent des Foliage Instances pour la performance runtime, et le terrain devient un Landscape Unreal standard avec ses couches de texture.
• Itération - pour changer radicalement la zone plus tard (ajouter une vallée), retourner au HDA, ajuster les paramètres, et re-baker - les matériaux et l'éclairage construits nativement dans Unreal restent intacts.

Ce workflow préserve la flexibilité procédurale tout en exploitant les forces runtime d'Unreal, et permet aux technical artists (qui construisent les HDA) et aux level designers (qui les utilisent) de collaborer efficacement. Quelques mises en garde pratiques : le coût de recalcul par changement de Houdini Engine peut être élevé sur de gros assets, donc il est courant de précalculer lourdement dans Houdini et d'utiliser Engine surtout pour le placement/paramétrage plutôt que de recalculer une érosion coûteuse en direct ; les UV de lightmap et la collision sur les maillages importés via Engine doivent être validés même si le plugin peut générer les deux automatiquement ; et la synchronisation USD en direct peut saturer un réseau sur des scènes très lourdes, donc il faut filtrer les couches qui se synchronisent réellement en direct.

Houdini n'est pas un silo isolé - USD et Houdini Engine garantissent que les heures passées à construire un système procédural se répercutent dans le reste de la production sans perte majeure, ce qui explique précisément pourquoi il est devenu un pilier des pipelines VFX cinéma comme des pipelines de world-building de jeux.