Houdini Solaris et USD : guide des flux de travail en couches pour les scènes architecturales

Dans la documentation de Houdini 22.0, SideFX présente Houdini Solaris comme l’ensemble des outils de création de scènes basées sur USD, de look development et de rendu Karma. Pour les équipes de visualisation architecturale, l’idée centrale de Solaris consiste à organiser la scène en couches liées entre elles, plutôt qu’à la considérer comme un fichier unique et immuable. Ce guide associe les notions fondamentales d’USD aux réseaux LOP de Solaris afin de mettre en place une méthode de travail reproductible.

1. Planifier la scène sous forme de couches USD

USD est un système qui décrit les scènes 3D en combinant des couches. Dans le cas d’un intérieur résidentiel, la scène principale peut référencer des fichiers distincts contenant le mobilier, l’éclairage et d’autres éléments. Dans l’exemple de cuisine de la documentation de SideFX, le fichier principal rassemble lui aussi des assets tels que des chaises et une table, ainsi que l’éclairage. Cette approche est conçue pour faciliter le travail de plusieurs équipes sur différentes parties d’une même scène.

Avant de commencer, déterminez quels éléments seront gérés séparément. Par exemple, conserver les assets de mobilier et la configuration d’éclairage dans des couches distinctes facilite le suivi des modifications et permet de savoir quelle partie a été modifiée. Les couches ne correspondent pas uniquement à une séparation des fichiers : elles peuvent représenter une partie précise de la scène, comme un asset, un personnage, un élément de rig ou une configuration d’éclairage. Dans Houdini, les nœuds du réseau LOP modifient la scène USD entrante et produisent une nouvelle sortie de scène.

2. Séparer les modifications sans altérer les données

L’un des principaux avantages de l’approche par couches d’USD est de pouvoir conserver les modifications dans une nouvelle couche plutôt que de modifier directement la scène existante. Ainsi, la nouvelle modification n’affecte pas automatiquement les autres personnes qui utilisent la même scène de base ; les membres de l’équipe peuvent choisir d’utiliser cette couche. Il est également possible de remplacer un asset par une version plus récente et de réappliquer les modifications existantes.

Dans Solaris, vous pouvez utiliser Layer Break LOP lorsque vous devez créer une nouvelle couche dans le réseau. Pour ajouter un fichier USD présent sur le disque à la pile de couches du stage existant, utilisez Sublayer LOP ; pour faire référence à une couche créée dans le réseau LOP, utilisez Reference LOP. Ces nœuds peuvent sembler servir à des fins similaires, mais la documentation les décrit comme des outils destinés à des opérations différentes : l’un charge une sous-couche existante, l’autre ajoute une référence à une couche créée.

1. Définissez les limites de la scène principale et des éléments qui seront gérés séparément.

2. Créez des couches distinctes pour les modifications qui doivent préserver les données existantes.

3. Ajoutez une couche présente sur le disque avec Sublayer LOP, et une couche créée dans le réseau avec Reference LOP.

4. Considérez le résultat de la fusion des couches comme le stage.

3. Bien comprendre le stage, les prims et leurs propriétés

Le stage désigne l’arbre de prims final calculé à partir de la fusion des couches USD. Un fichier USD peut constituer à lui seul une couche ; dans un autre contexte, le même fichier peut créer un stage lorsqu’il est chargé au niveau supérieur. Il n’est donc pas juste d’établir une distinction absolue entre un « fichier de stage » et un « fichier de couche » sur la seule base de leur extension.

Les prims sont les unités fondamentales d’un stage. Un mesh, une lumière, un matériau ou un objet contenant des informations de transformation peut être un prim. Les prims peuvent contenir des propriétés et des prims enfants. Les propriétés se répartissent en deux types principaux : les attributs et les relations. Un attribut contient une valeur d’un type donné, comme une dimension ou une couleur, tandis qu’une relation établit un lien entre un prim et un autre. L’assignation d’un matériau, par exemple, peut être considérée comme une relation entre un mesh et un matériau.

Lorsque plusieurs couches contiennent des valeurs différentes pour une même propriété, l’avis le plus fort dans la composition des couches peut remplacer l’autre valeur. C’est pourquoi, face à une modification inattendue, il faut vérifier quelle couche agit sur la propriété plutôt que de se limiter à la valeur finale affichée. Solaris permet de configurer des opérations de haut niveau via les nœuds LOP ; il n’est pas nécessaire de modifier manuellement la structure de bas niveau d’USD dans tous les cas.

4. Vérifier le résultat de la scène et le format de fichier

Pour examiner le stage produit par un nœud LOP, faites un clic droit sur ce nœud et choisissez LOP Actions › Inspect Flattened Stage. Selon la documentation, cette opération permet d’afficher la sortie du stage en syntaxe usda. Cette inspection constitue une étape de vérification utile pour contrôler les prims et les propriétés présents après la fusion des couches.

Choisissez également les extensions de fichier en fonction du flux de travail. Un fichier portant l’extension .usd peut être au format binaire ou texte. .usda désigne du texte brut lisible, tandis que .usdc désigne le format binaire. Cette distinction entre extensions permet d’éviter toute confusion dans le suivi des assets ou le contrôle des versions lors du changement de format de fichier. La documentation précise également qu’Inline USD LOP permet d’ajouter du code USD en texte brut au stage ; considérez-le comme une option de dépannage à utiliser au besoin, et non comme la méthode habituelle de création de scènes.

Ce que cela implique pour les équipes d’architecture et de visualisation

Cette approche est pertinente pour les équipes qui souhaitent gérer différents éléments d’une même scène architecturale, comme les assets et l’éclairage, dans des couches séparées. En isolant une modification de la scène de base, on peut réduire le risque de changer involontairement le travail des collègues qui utilisent le même contenu. La possibilité de mettre à jour les couches facilite également la prise en compte des changements apportés aux assets ou à l’éclairage avec les modifications existantes. L’avantage n’est pas un gain automatique de vitesse de rendu, mais un contrôle accru de la manière dont les données de scène sont organisées et partagées.

Les studios qui évaluent Solaris et USD doivent d’abord vérifier leur compatibilité avec l’organisation actuelle des fichiers et des assets, définir les responsabilités de chacun au sein de l’équipe pour les couches, et tester la version de Houdini utilisée. La documentation de SideFX fournie ici porte le titre Houdini 22.0 ; elle ne garantit pas la compatibilité avec d’autres versions. Il est donc nécessaire d’effectuer des vérifications sur l’installation cible avant de transférer des scènes de production. Ces sources ne détaillent pas les exigences matérielles ou de licence ; il n’est donc pas possible d’en tirer des recommandations spécifiques à ce sujet.

Erreurs fréquentes

• Regrouper toutes les modifications dans une seule couche peut compliquer le suivi de l’origine de chaque changement. Envisagez de séparer le contenu selon sa fonction.

• Ne confondez pas Reference LOP et Sublayer LOP : la documentation les décrit comme des outils permettant d’intégrer des sources différentes à la scène.

• Ne partez pas du principe que l’extension .usd désigne toujours un fichier texte ou toujours un fichier binaire. Tenez compte de la distinction entre .usda et .usdc pour les formats texte et binaire.

• N’utilisez pas Inline USD LOP comme méthode de modification par défaut. SideFX le présente comme une méthode de dépannage qui peut être utile au besoin.