Notes concernant USD

Références

Anecdotes

Il semble qu’USD trouve son origine dans le logiciel d’animation de Pixar Presto :

Our animation software Presto was designed around the concepts that would eventually be refined and extracted to become USD.

Source : Stories | Pixar USD Pipeline

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 dit 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 : {#description-et-résultat}

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
}

Différence entre property, attribute et relationship

Une Prim est composée de Property. Une Property est soit de type Attribute, soit de type Relationship :

Property est une classe de base de Attribute et Relationship :

       Property
      .----|----.
     /           \
Attribute   Relationship

Dis autrement une Property est soit un Attribute, soit une Relationship.

TODO

Différence entre un root et un PseudoRoot

Dans USD, un PseudoRoot est une Prim virtuel dont les enfants sont les roots du scenegraph courant.

Dans la hiérarchie suivante, toto et tata sont des roots :

/
├> toto/
│  └> totoShape
└> tata/
   └> tataShape

Le PseudoRoot est donc la Prim / dont les enfants sont toto et tata.

Résumé

Et l’API dans tout ça

Comme dit dans la section avant-propos, le but de cette page est d’essayer de vous rendre autonome avec l’API. Vous remarquerez qu’elle est assez dense et composée de nombreux espaces de noms.

Les deux principaux sont :

En plus avancé :

À cette étape, vous devriez être en mesure de pouvoir lire la partie details des pages :

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.

Qu’est-ce qu’un payload

Si vous avez déjà entendu parler d’USD, vous avez surement entendu le mot payload.

TODO.

Cas spécifiques

Les UVs incompatibles avec la géométrie.

USD ne réagit pas quand on injecte des UV dans une géométrie incompatible. Pour lui, ce n’est qu’un tableau de valeurs. Ce sont les logiciels ingérant ces données, qui sont supposés y réagir en fonction de ce qu’ils supportent.

Dans le meilleur des cas, c’est votre pipeline qui détecte/remonte ce genre de problèmes, avant que les USDs en question ne passent dans les mains des logiciels.

Dans le cas d’arnold, le très explicite message suivant s’affiche :

2022-06-18 22:34:22:  0: STDOUT: 00:00:00   325MB ERROR   |  [polymesh] /world/myasset/geo/body: wrong number of UV indices (found 1088, expected 1280)
2022-06-18 22:34:22:  0: STDOUT: 00:00:00   325MB ERROR   |  [polymesh] /world/myasset/geo/sock: wrong number of UV indices (found 15232, expected 14428)
2022-06-18 22:34:22:  0: STDOUT: 00:00:00   325MB WARNING |  [kick] render aborted due to earlier errors

Dernière mise à jour : mer. 15 février 2023