OpenUSD

Bien plus qu'un format de fichier

OpenUSD (Universal Scene Description) est assez souvent décrit comme un format de fichier pour que l'étiquette colle, mais cela sous-estime ce qu'il est réellement. Là où FBX ou OBJ sont des conteneurs de données, USD est une architecture complète : une spécification de données, un ensemble de bibliothèques logicielles open source, et un écosystème ouvert gouverné par une alliance industrielle.

Le format de données est une spécification standardisée pour décrire des scènes 3D de façon hiérarchique - l'interopérabilité vient de la spécification elle-même, pas de conventions ad hoc entre studios. Les bibliothèques forment une API C++ complète avec des bindings Python, plus des outils pour inspecter, valider et manipuler les données USD, le tout open source. L'écosystème est l'Alliance for OpenUSD, fondée par Pixar, Adobe, Apple, Autodesk et NVIDIA, qui gouverne le standard et coordonne son développement.

USD a été construit chez Pixar pour répondre à des besoins de production internes - des scènes d'une échelle et d'une complexité que les formats existants ne pouvaient pas gérer. Il a été ouvert en open source en 2016 après avoir fait ses preuves sur certaines des productions les plus complexes de l'industrie, et son adoption n'a cessé de s'accélérer dans l'industrie 3D depuis.

Prims, Stages et Layers

L'architecture d'USD repose sur trois concepts qui forment une hiérarchie claire.

Prim

Le Prim (primitive) est l'unité de base d'USD - n'importe quel élément de scène : géométrie, caméra, lumière, matériau. Les Prims s'organisent en une hiérarchie avec des chemins uniques, similaires à des chemins de fichiers : /World/Characters/Hero/Geometry/Body. Chaque Prim est typé selon un schéma défini (UsdGeomMesh, UsdLuxLight, UsdShadeMaterial), ce qui permet à toute application compatible USD de savoir comment l'interpréter.

Les attributs sont les propriétés typées attachées à un Prim - elles peuvent être animées dans le temps et contenir des valeurs simples (float, string, matrice) ou complexes (tableaux, relations). Les relations expriment des connexions entre Prims : liaisons de matériaux, hiérarchies de squelette, dépendances entre éléments.

Stage

Le Stage est la vue unifiée de la scène complète - le point d'entrée principal pour lire les données USD. Il résout et compose chaque layer en une seule vue cohérente, prête pour la visualisation ou le rendu. Le Stage ne stocke pas de données lui-même ; c'est le résultat de la composition de tous les layers qui l'alimentent.

Layer

Un Layer est un fichier USD individuel contenant un ensemble d'« opinions » sur des Prims. Le concept d'opinion est central : plusieurs layers peuvent contenir des opinions sur le même Prim, et le système de composition d'USD résout les conflits selon des règles de priorité définies. Les modifications dans un layer sont non destructives pour les autres - c'est ce mécanisme qui rend possible la collaboration simultanée entre plusieurs artistes sans qu'ils ne se marchent dessus.

Composition Arcs

Les Composition Arcs sont la façon dont USD combine les layers en un Stage cohérent - ils définissent comment les opinions de différents layers fusionnent et se surpassent les unes les autres.

References

Une Reference importe un asset USD externe dans la scène courante. L'asset source reste intact ; la Reference conserve un lien actif vers lui, et des surcharges locales peuvent s'ajouter par-dessus sans modifier la source. C'est le mécanisme central de réutilisation d'assets dans USD : Character.usd définit un personnage complet, Shot001.usd le référence et ajoute des surcharges de position, rotation et matériau propres au plan. Quand l'équipe de modélisation met à jour Character.usd, chaque plan le référençant récupère automatiquement le changement.

Payloads

Les Payloads fonctionnent comme des References avec une différence critique : le chargement est différé jusqu'à une demande explicite. Un Payload n'est pas chargé en mémoire tant que rien ne le demande. Pour les scènes massives, c'est essentiel - les zones lointaines ou hors champ peuvent être déclarées comme Payloads et ne coûter de la mémoire que lorsqu'elles sont réellement nécessaires.

Variants

Les Variants définissent plusieurs versions alternatives d'un même Prim - LODs, variations saisonnières, états alternatifs - sans dupliquer les données. Sélectionner une variante est dynamique et peut être piloté par le pipeline.

Inherits et Specializes

L'Inherit permet à un Prim de récupérer des propriétés depuis une classe d'asset définie séparément ; les changements sur la classe se propagent automatiquement à tout ce qui en hérite, ce qui convient bien aux modèles d'assets. Le Specialize est une forme d'héritage plus faible, permettant des surcharges sélectives à une priorité de composition inférieure.

Formats de fichier : USDA, USDC, USDZ

USD se décline en trois formats de fichier, chacun adapté à un usage différent.

.usda (ASCII) est lisible et éditable dans n'importe quel éditeur de texte - le choix naturel pour le débogage, l'apprentissage du format, le versioning via Git et le prototypage. Son coût est la taille de fichier et la performance de lecture, ce qui le rend mal adapté à la production sur de grandes scènes.

.usdc (binaire Crate) est le format binaire optimisé d'USD : rapide à lire et écrire, compact, non lisible par un humain. C'est le standard pour la production et le runtime, et le format à privilégier dans tout pipeline automatisé traitant des scènes complexes.

.usdz (archive ZIP) empaquette une scène et toutes ses dépendances - textures, matériaux, références - dans un seul ZIP non compressé, choisi spécifiquement parce qu'un ZIP non compressé permet un accès aléatoire rapide aux fichiers qu'il contient. USDZ est le standard d'Apple pour l'AR sur iOS, visionOS et Quick Look, et il simplifie la distribution d'assets autonomes.

Avantages et limites

Les avantages d'USD sur les formats traditionnels se répartissent en trois domaines. Interopérabilité : en tant que standard ouvert, l'échange de données entre applications est standardisé plutôt que basé sur des conventions - un asset construit dans Houdini et exporté en USD s'ouvre dans Maya, Unreal ou Blender en conservant hiérarchie, matériaux et animation, dans les limites du niveau de support de chaque application. Collaboration : le mécanisme de layers permet à plusieurs artistes de travailler simultanément sur différents aspects d'une même scène sans conflit, chaque département sur son propre layer, composé automatiquement en une vue cohérente. Échelle : le chargement différé via les Payloads, les variants pour les LODs, et la composition non destructive via des surcharges permettent à USD de gérer des scènes que les formats monolithiques ne peuvent tout simplement pas gérer.

Rien de tout cela n'est gratuit. La courbe d'apprentissage est réelle - Prims, Layers, Stages, Composition Arcs, Variants et Payloads sont des concepts abstraits qui demandent un véritable investissement en formation, et déboguer un Stage mal composé peut être difficile. Adopter USD dans un studio n'est pas une simple mise à jour logicielle : les pipelines existants doivent être adaptés ou reconstruits, un outillage sur mesure est souvent nécessaire, et migrer une bibliothèque d'assets établie a un coût réel. Certaines parties du standard sont encore en maturation - le support du skinning en particulier - et l'implémentation varie entre applications, de sorte qu'un workflow qui fonctionne proprement dans Houdini peut présenter des lacunes à l'import dans Maya ou Blender. Pour des projets petits, mono-outil, sans besoin de collaboration, le surcoût d'USD n'est généralement pas justifié.

Support logiciel

Houdini (SideFX) a le support USD le plus complet de l'industrie - le contexte Solaris est entièrement construit autour de la manipulation de Stages USD via des nœuds LOP, avec un viewport Hydra qui prévisualise de façon cohérente avec le rendu Karma final. NVIDIA Omniverse est construit sur USD dès l'origine, ajoutant la collaboration temps réel, la simulation physique RTX et le rendu path-tracé avec des connecteurs pour les principaux DCC. Blender supporte l'import/export USD pour la géométrie, les hiérarchies de transformation, et les caméras et lumières basiques, mais le support des matériaux reste limité et les Composition Arcs avancés ne sont pas encore exposés dans l'interface. Maya dispose d'un plugin USD officiel avec une intégration qui s'approfondit progressivement, Unreal Engine importe nativement les Stages USD et interopère avec Omniverse, l'écosystème Apple traite USDZ comme un format natif ARKit et Quick Look, et Adobe Substance 3D exporte les matériaux vers USD avec intégration MaterialX.

Houdini Solaris

Solaris est le contexte USD dédié de Houdini, construit autour de nœuds LOP (Layout Operators) qui manipulent un Stage USD plutôt que de la géométrie brute.

Le workflow Solaris typique se découpe en quatre étapes : Import référence des assets ou fait entrer de la géométrie SOP via un SOP Import LOP, Layout positionne et assemble les Prims, Look Dev assigne les matériaux MaterialX, et Export produit les fichiers USD de production via un USD ROP. Combiner le workflow procédural de Houdini avec la standardisation d'USD est ce qui en fait le choix par défaut pour les pipelines VFX et animation complexes.

MaterialX et USD

MaterialX est le complément naturel d'USD pour le look development - là où USD décrit la scène, MaterialX décrit les matériaux d'une manière portable et indépendante du moteur de rendu. USD l'intègre via le schéma UsdShade : un matériau créé dans MaterialX vit dans un fichier .mtlx ou directement dans un layer USD, et se lie à la géométrie via le mécanisme de liaison standard d'USD. Le résultat est une portabilité du look-dev que les systèmes de shading propriétaires (VEX, RSL, OSL) ne peuvent pas offrir seuls - un graphe construit dans Substance ou Houdini s'exporte en .mtlx, se lie à la géométrie via UsdShade, et se rend correctement dans n'importe quel moteur supportant MaterialX : Arnold, Karma, RenderMan.

USD vs FBX

USD a du sens pour les productions complexes multi-outils, la collaboration en grande équipe, les scènes hiérarchiques massives, et le look-dev avancé basé sur MaterialX. FBX garde sa place pour les assets simples et isolés, les exports de jeu basiques, et les pipelines legacy où la compatibilité ascendante est la contrainte. USD supplante progressivement FBX dans les pipelines modernes, mais FBX ne disparaît pas pour les échanges simples et les systèmes legacy.

Ressources

• Documentation OpenUSD : openusd.org
• Alliance for OpenUSD : aousd.org
• PixarAnimationStudios/OpenUSD sur GitHub : github.com
• Documentation MaterialX : materialx.org
• Page produit SideFX Solaris : sidefx.com
• NVIDIA Omniverse : nvidia.com