Notes concernant USD

Références

Avant-propos

USD a beaucoup de concepts. Je ne vais pas tous les décrire, mais me concentrer sur ceux que je considère les plus importants pour commencer à devenir autonome dans la documentation.

Cette page n’explique pas comment utiliser USD dans un pipeline, mais les subtilités nécessaires pour comprendre comment est structuré l’API.

Note : Je commence par un éclaircissement d’un concept que tout le monde connaît : La « scène », ou « hiérarchie ». La terminologie USD n’utilise pas le mot scene, sûrement pour ne pas prêter à confusion, ce mot étant très utilisé dans les logiciels. En fait, chaque fois qu’elle pourrait utiliser le mot scene pour désigner la hiérarchie, la documentation préfère parler de scenegraph. C’est le mot que j’utiliserai à partir de maintenant.

Concepts principaux

USD permet de construire un scenegraph (une hiérarchie de scène, donc) en empilant des layers. Par exemple, si on empile les deux hiérarchies suivantes :

# toto.usd
root/
└> mesh/
   └> toto
# tata.usd
root/
└> mesh/
   └> tata

On obtient la scène :

root/
└> mesh/
   ├> toto
   └> tata

Cette idée de base est à l’origine de l’icône d’USD.

En USD, un scenegraph est donc le résultat de la superposition de plusieurs layers.

Il y a une subtilité qu’il est important de comprendre avant de passer à la suite : En USD, toute superposition de layers (et donc scenegraph résultant) est fait depuis un layer root unique. Ce layer peut-être sur disque (un fichier .usd) ou en mémoire (quand on code ou quand on utilise Solaris) ; on parle alors d’un layer de session. Les layers dis anonymes sont reconnaissables par leur nom bizarre, comme anon:0x2bfe290:usd-session.usda.

C’est donc le root layer qui contient des références vers d’autres layers (fichiers .usd), qui eux-mêmes contiennent des références vers d’autres layers, etc.

Un layer n’est que la description de ce qu’il ajoute/modifie au scenegraph.

L’objet responsable de transformer le root layer (et tous les layers qui en découle) en scenegraph est le stage.

Cette « superposition » des layers depuis le root layer s’appelle la composition, mais j’y reviendrais.

Le rôle du stage est donc de composer le scenegraph depuis le root layer. En gros, le stage est une vue composée (c.-à-d. le résultat, la composition) de la description de scène présente dans le root layer.

Dernier gros concept avant d’aborder des choses plus subtiles : Là où une scène Maya est composé d’une hiérarchie de nœuds, un scenegraph USD est composé de Prims.

Une Prim est composé d’un nom et d’un type ; Scope, Xform, Mesh, Capsule, Cone, Cube, Cylinder, Sphere, NurbsCurves, PointInstancer.

Pour résumer :

C’est le moment où je pense qu’on peut aborder les deux gros groupes de concepts qui compose la lib USD :

Cette distinction est illustrée avec la dualité entre Prim et PrimSpec.

Pour faire court, une Prim est le résultat de la composition d’une ou plusieurs PrimSpec.

Clarification : Le suffixe « Spec » est une abbreviation de « specifier » et non de « specification ».

Dit autrement, si on a deux layers, chacun définissant (via def) une PrimSpec "toto" :

layer1.usd :

#usda 1.0

def Mesh "toto"
{
    int my_subdiv = 1
}

layer2.usd :

#usda 1.0

def Mesh "toto"
{
    string my_color = "red"
}

La composition de ces deux layers donnera la Prim suivante :

#usda 1.0

def Mesh "toto"
{
    string my_color = "red"
    int my_subdiv = 1
}

TODO

Résumé

Fichiers .usda, .usdc, et .usd

Tout est expliqué dans la (courte) documentation du format crate.

En résumé :

Tout comme le .ma de Maya, .usda est considéré comme inefficace.

Fonctions de base

Beaucoup de fonctions de base sont disponibles dans le tutoriel officiel ainsi que sur le site de Nvidia.

Des exemples plus complexes sont disponibles sur le repo de Colin Kennedy.

Récupérer la version d’USD

>>> from pxr import Usd
>>> Usd.GetVersion()
(0, 22, 11)

Dernière mise à jour : lun. 28 novembre 2022