USDは、 レイヤーを合成 することで3Dシーンを表現できるようにしたソフトウェアおよびファイル形式のシステムです。 例えば、台所シーンを表現したマスターUSDファイル(kitchen.usd)は、プロップ(chair.usd, table.usd)、照明、キャラクタなどを含んだレイヤーファイルを参照して、それら全体を単一 ステージ として合成することができます。

このレイヤーという概念の主力は、 非破壊的編集 ができることです。 既存シーンを開いて、新しいレイヤー上で編集を加えることができます。 ここで加えた編集は、同じシーンを利用している他の人がその新しいレイヤーを取り込まない限りは、その人には何も影響を与えません。 複数のレイヤー(例えば、新しいバージョンのアセットを含んだレイヤーや更新されたライティングを含んだレイヤー)のどれかを置換することで、その置換したレイヤーの上にある既存のすべての変更を自動的に再適用させることができます。 これによって、複数の部署間でお互いに干渉することなく、共同作業、データ共有、アセット更新をすることができます。

HoudiniでのUSD関連のツールとサポートのことを総称してSolarisと呼びます。 Solarisは、ビューポートのUSD対応、新しいネットワークタイプであるLOPs(Light Operators)を含んでいます。 LOPネットワークは、若干SOPsに似ています。 SOPsでは、各ノードが入力ジオメトリを受け取って、それを修正し、新しいジオメトリを出力します。 それに対して、LOPsでは、各ノードが入力USDシーンを受け取って、それを修正し、新しいシーンを出力します。

USDは非常に広範囲なフレームワークなので、そう単純ではありません。 LOPsは、ベースとなっているUSD構造について知る 必要がない ように設計されています。 しかし、あちらこちらでLOPパラメータでUSD用語が使用されており、中にはUSDに組み込まれている機能を簡単にラッパーしているものもあります。 USDの概念と機能の基本を理解すれば、LOPsの理解がもっと楽になることでしょう。

以下のページは、USDの基本について説明し、そこからSolarisがHoudini内でUSDの処理をどのように対応させているのかについて触れています。 LOPノードがUSDをどのようにして生成しているのかに関しては、LOPの挙動を参照してください。

普段だと、.usd(または.usdc)ファイルは効率性を良くするためにバイナリエンコードしますが、USDシーン記述フォーマットは、人が解読可能なプレーンテキスト(.usda)にも対応しています。 このドキュメント内では、以下の非常に単純な.usdaサンプルを使って、一部のUSDの概念について説明します:

#usda 1.0
def Cube "box" {
    double size = 4.0
}

このサンプル内のdefは、新しいPrimを定義するためのキーワードです(USDには他にもdefと同様のoverオペレータが存在しますが、overは新しいPrimが既存Primを オーバーライド(上書き) する方法を定義します)。 Cubeは、そのPrimの タイプ(型) です。 “Cubeである”が意味する事とそのCubeが用意しているプロパティは、 スキーマ で定義します。 boxは、そのPrimの名前です(このPrimは、シーンツリー内で/boxとして表示されます)。 このCube Primタイプは、ビルトインのUSD Geometryスキーマで定義されています。 他にもボリューム用、シェーディング用、ライティング用、スケルタルアニメーション用、レンダリング用のビルトインスキーマが存在します。 カスタムスキーマを作成して独自のPrimタイプを定義することで、USDを拡張することができます。

中括弧{ }内のコードでは、新しいPrimの 子Prim と プロパティ を定義します(このCubeにはたくさんのプロパティが用意されていますが、ここで指定しなかったプロパティは、そのタイプスキーマのデフォルト値が適用されます)。

USD用語で言えば、これは“/boxのサイズに関するオピニオンを編集します”と命令した短いコードです。 レイヤーを合成する時に、あるレイヤー内にプロパティ値に関する“オピニオン”が含まれている一方で、 強いオピニオンのレイヤーがそれと同じプロパティに対して別のオピニオン(値)を持っていた場合、弱いオピニオンのプロパティ値は強いオピニオンのプロパティ値で オーバーライド されます。

では、2つ目の.usdaファイルを見ていきましょう:

#usda 1.0
def "box1" ( references = @box.usda@ ) {

}
def "box2" ( references = @box.usda@ ) {
    float size = 2.0
}

このファイルでは、上記のbox.usdaファイルの内容を2回インポートして、/box1と/box2の2個のPrimを定義しています。 /box1は、参照レイヤーからsizeアトリビュートを継承します。 /box2は、新しい値でsizeを オーバーライド します。

Houdiniでは、一般的にはプリミティブ上のアトリビュート値を直接的に操作することはしないでしょう(たしかにローレベル編集をするためのノードは存在しますが)。 直接的な操作をしなくとも、LOPノードにもっとハイレベルなオペレーション(例えば、“このジオメトリを取り込め”、“このライトがこのオブジェクトを照らせ”、“このプロップをこの机の上に物理学に基づいて配置せよ”といったオペレーション)を指定すれば、そのLOPが自動的に該当するUSDを編集してくれます。

実際にInline USD LOPを使用することで、LOPネットワークで構築されたステージ内にプレーンテキストのUSDコードを挿入することができます。この方法は、時にはデバッグで役に立つものの、普段あなたが作業するべきやり方ではありません!

USDにおけるアトリビュートは、Primの“設定”を含んだスカラー値を指すことが多いです。 Sphere Primを例にすると、radiusアトリビュートは球のサイズを制御します。 この意味では、アトリビュートはHoudiniでいうノードパラメータ、Mayaでいうアトリビュートに近いです。

USDでは、ポイント単位の変数などのジオメトリ設定 も Prim上のアトリビュートとして格納します。 このようなジオメトリ設定は、1コンポーネントにつき1エレメントの 配列 として格納します。 例えば、メッシュPrim上のpointsアトリビュートには、座標配列でポイントポジションを格納します。 これは、Houdiniのジオメトリアトリビュートと同じです。

他にも、USDは Primvar と呼ばれる特別なタイプのアトリビュートを認識します(このPrimvarはRendermanが語源で、“Primitive variable(プリミティブ変数)”の略です)。

基本ツリーレベルでは、このPrimvarは、単にprimvars:スキーマネームスペース接頭辞が付いたアトリビュートにすぎないです。 このPrimvarが特別なアトリビュートになるのは、Hydraがレンダリング時にそのアトリビュートを扱う時です。 Primvarの主な目的は、マテリアルパラメータをオーバーライドすることです。 とはいえども、このPrimvarの挙動は他にも活かせることができて、マテリアルとは別にジオメトリレンダリングに影響するオブジェクト単位のプロパティを表現する際にも使用します。 例えばKarmaでは、Primvarを使用して、オブジェクト単位でモーションブラーのフレーム数を指定することができます。

どのUSDファイルも完全な“シーン”を含んでいます。 USDファイルは、他のUSDファイルの内容を レイヤー として取り込むことができます。

USDライブラリには、トップレベルのファイルで生成されたフルシーン(ステージ)内に複数のレイヤーをコンポジット/オーバーレイするためのソフトウェアが入っています。 ここで言うコンポジションは、以下のレイヤー間の違いを考慮した結合を含みます:

• 新しいPrims。

• Primの順番決め。

• Primがアクティブなのか非アクティブなのか。

• バリアント。

• 新しいプロパティ(アトリビュートとリレーションシップ)。

• アトリビュート値(上層のレイヤーほどアトリビュート値を“ブロック”(未設定)しやすいので、アトリビュート値が割り当てられてないかのように見えてしまいます)。

• メタデータ値。

Houdiniは、色々なディスク上のレイヤーとUSDを編集すると生成されるIn-Memoryレイヤーを自動的に合成します。 他にも、ツールを使用することで、各レイヤーの内容とレイヤーの合成の方法を理解することができます。

#usda 1.0
(
    subLayers = [
            @shotLighting.usd@,
            @shotFX.usd@,
            @shotAnimation.usd@,
            @shotSetDressing.usd@,
            @sequence.usd@
    ]
)

/Lights/
    light1
    light2
/Models/
    tableside_lamp
        

/lamp/
    base
    bulb
    shade
    socket
    switch

/Lights/
    light1
    light2
/Models/
    tableside_lamp/
        base
        bulb
        shade
        socket
        switch

#usda 1.0
(
   defaultPrim = "TrashCan"
)

def Xform "TrashCan" (
   kind = "component"
)
{
   def Cylinder "Can"
   {
       token axis = "Y"
       bool doubleSided = 0
       double height = 2
       double radius = 1
   }
}

#usda 1.0
()

def Xform "Scene"
{
   def Xform "Set"
   {
       def "BathroomTrashCan" (
           append references = @./trashcan.usda@
       )
       {
           double3 xformOp:translate = (2, 0, 1.4)
           uniform token[] xformOpOrder = ["xformOp:translate"]
       }

       def "KitchenTrashCan" (
           append references = @./trashcan.usda@
       )
       {
           double3 xformOp:translate = (16.01, 5, -43.072)
           uniform token[] xformOpOrder = ["xformOp:translate"]
       }

       def "OfficeTrashCan" (
           append references = @./trashcan.usda@
       )
       {
           double3 xformOp:translate = (-7.12, 0, 11.9)
           uniform token[] xformOpOrder = ["xformOp:translate"]
       }
   }
}

単一シーングラフ位置におけるプリミティブに対する最終オピニオンを生成するために複数レベルのサブレイヤー化と参照がどのように動作しているのかを追跡するのは困難を極めます。Scene Graph Detailsペインの Layer Stack と Composition のタブを使用することで、どのレイヤーがどのプリミティブに寄与しているのか、それらの異なるレイヤーがどのように合成されているのかを調べることができます。

# props.usd
/Materials/
    plastic1
/Things/
    Toy/
        geom
        toy_shader (/Materials/plastic1をリファレンスしてオーバーライド)

# scene.usd
/Materials/
    plastic1
/Models/
    Props/
        Toy/  <– このPrim上にリファレンス
            geom
            toy_shader

• usda形式のコードを書き出し、それを評価し、その結果のPrimsをInline USDノードを使ってIn-Memoryシーングラフツリー内に直接挿入することができます。

• Python Script LOPを使ってPython Usd APIを利用することで、In-Memoryステージを直接制御することができます。

以下の2通りの方法で、HoudiniでカスタムファイルフォーマットプラグインとAsset Resolverを使用することができます:

• Houdiniに同梱されているUSDのヘッダとライブラリを使ってプラグインをビルドします(これらのヘッダとライブラリは、HDKの一部として含まれています)。

• HoudiniバージョンのUSDライブラリをあなた自身のバージョンに置換します。これをするには、SideFX GitHubからHoudiniUsdBridgeリポジトリをダウンロードする必要があります。このリポジトリには、USDでコールするHoudiniソースコード一式が含まれています。あなた自身のUSDライブラリを使って、このコードをリビルドして、その結果を使って、Houdiniインストール先の該当するライブラリを置換します(まるまるコピーするかLD_LIBRARY_PATHを編集します)。

Solarisの出力プロセッサは、ファイルの保存方法をカスタマイズすることができます(例えば、$HIPを基準としたパスを受け取り、そのパスをルートUSDファイルのパス基準に変換し、ファイル拡張子を調整することができます)。

USDでは、ジオメトリを表現したPrimのことを Gprim と呼びます(これは、レンダリング時に実際に画像内で描画されるPrimであり、その対義語としてトランスフォームPrimがあります)。このようなPrimタイプ(UsdGeomGprim)のスキーマには、境界ボックス検索などの便利メソッドが用意されています。

USDは、数学的に定義された形状(カプセル、円錐、立方体、円柱)を表現したPrim一式を含んでいて、さらには、ポリゴンメッシュやサブディビジョンサーフェスなどのジオメトリを格納するもっと複雑なPrimも持つことができます。

シーングラフツリー内で、他のGprim下にGprimを置かないでください 。 アクティブ化、可視性、PurposeなどのUSDの多くの主な特徴は階層的に適用されます。 このようなオペレーションを個々のGprimに適用できなくするのは、無意味で生産性を下げてしまいます。

Kindsは、理解するのが難しいUSDの概念の1つです。 ジオメトリを持ったどのPrimにも“Kind”を持たせてください。

“Model Kinds”は、modelとよばれる“抽象”Kindのサブクラスです。 modelをKindとして割り当てないでください。 “Model Kinds”は3種類あります:

Kindsは、シーン内のジオメトリを モデル階層 にまとめることができます。 これは、シーン内のモデルの“目次”です。 この階層を適切に維持することで、ソフトウェアパッケージは、例えば選択に対してもっと良いUIを提供することができ、シーン内のモデルをもっと効率的に走査することができます(例えば、ソフトウェア側でユーザーにシーン内のすべてのモデルを表示させたい場合、ルート内でKindを持ったツリーだけの検索を開始するだけで済んで、componentKindが見つかった時にそのツリー以降の検索を停止することができます)。

シーングラフツリー内のモデル階層は、以下のように見えます:

/Models ← group
    /Characters ← group
        /Lady ← assembly
            /Skin ← component
                /mesh
            /Purse ← component
                /mesh
        /Dog ← assembly
            /Skin ← component
                /mesh
            /Collar ← component
                /mesh
    /Props ← group
        ...

モデル階層を維持するには、シーンが以下のようになっている必要があります:

• (下流まで見据えて)ジオメトリを扱うPrimすべてには、ルートPrim(例えば、/Models)含めて最初からKindを持たせてください。

• group/assembly Kindsのみに他の“Model Kinds”を含めることができます。component Kindsには、group、assembly、modelを含めることができません(component KindにはsubcomponentKindだけ含める ことができます )。

Houdiniでは、プリミティブを作成/編集するノードに、そのPrimのKindを設定するパラメータが用意されています。Houdiniは、モデル階層ルールに準じてmodelをKindとして使用することを許可していません。 現在のところ、Houdiniは、モデル階層を維持するために何かユーザーに手助け、または、強制させるための処理をしていません。

USDでは“インスタンス化”(効率的なコピー)の方式が色々あります。

本来のUSDは、ツリー内のPrimが他のPrimを軽量で 参照 するという概念を持っています。 この概念は、ブランチ内のすべてのPrimsを実際にコピーするよりも非常に効率的であるものの、サブPrimsをオーバーライドする機能を維持するには、USDはその参照下のサブPrim毎に参照を作成しなければならないことも意味します。

膨大な数のコピー/バリエーションでシーンをもっと効率的に構築できるようにするために、USDには2つの方法の インスタンス化 があります。

instanceable Primsは、ポイントインスタンサーを扱うよりも簡単です。 しかし、Primのコピーと比べて各“エイリアス”は非常に少ないメモリ使用量で済むものの、非常に膨大な数のインスタンスになると、その使用量が積み上がってしまいます。 ポイントインスタンスは、一定のメモリ使用量で 数十億 ものインスタンスの制御ができるように設計されています。

どちらのタイプのインスタンスも、各プリミティブのトップレベルのトランスフォームに対応しており、さらに、(ネイティブインスタンスまたはポイントインスタンサープリミティブに対して)Primvarを使ってインスタンス単位でマテリアルパラメータをオーバーライドすることができます。

Houdiniは、Instancerでインスタンス化する方法、色々なTabメニューツールでインスタンサーノードを調整してインスタンス化する方法のどちらの方法でもインスタンス化することができるので、 たいていは必要なインスタンスの数に基づいて、そのインスタンス化の方法を選択します。 さらに、Houdiniは、 入れ子化されたポイントインスタンス (1レベル以上に入れ子化されたインスタンサーは、インスタンスサーを含んだプロトタイプをインスタンス化します)、“実”モデルにするインスタンスの ヒーロー化 にも対応しています。

USDは、複数の名前が付いたプリミティブの バリアント をプリミティブ上に保存することができます。 バリアント毎に異なるアトリビュート、リレーションシップ、子Primsを持たせることができます。 レイヤー別に異なるバリアントでプリミティブを切り替えることができます。 各プリミティブは、名前の付いた バリアントセット 内に複数のバリアントのグループを保存することができます。

以下にバリアントの一般的な使用方法を載せています:

• 異なるジオメトリのファミリー(例えば、異なるタイプのツリーを切り替えることができるプリミティブ)。

• Levels of Detail(同じジオメトリを段階的に解像度を下げたバージョンをバリアントとして保存し、カメラまでの距離に基づいて切り替える)。

  Houdiniには、このワークフローを自動化するためのCreate LODノードとAuto Select LODノードが入っています。

• マテリアルの割り当て(異なるマテリアルを割り当てたバリアントを保存することで、プリミティブのルックを簡単に切り替えることができます)。

以下に、ownerという名前のバリアントセットを含んだレイヤーのサンプルを載せています。 各バリアントのカラーは、そのボールを所有するストーリー内のキャラクタに呼応しています:

#usda 1.0
()

def Sphere "toyBall" (
    variants = {
        string owner = "blake"
    }
    append variantSets = "owner"
)
{
    double radius = 1
    variantSet "owner" = {
        "andy" (
        ) {
            color3f[] primvars:displayColor = [(1, 0, 0)] (
                interpolation = "constant"
            )


        }
        "blake" (
        ) {
            color3f[] primvars:displayColor = [(0, 0, 1)] (
                interpolation = "constant"
            )


        }
        "sally" (
        ) {
            color3f[] primvars:displayColor = [(0, 1, 0)] (
                interpolation = "constant"
            )


        }
    }
}

PixarのUSD用語集のバリアントセットを参照してください。

Houdiniのアニメーションが時間可変のノードパラメータで制御するのと同様に、USDのアニメーションは、時間可変のアトリビュート値で制御します。

• 各アトリビュートは、単一の“デフォルト”値を持てるだけでなく、“タイムサンプル”のコレクションを持つこともできます。これは、時間をインデックスとした値のリストです。そのアトリビュート上のメタデータで、それらのサンプルの補間方法を指定します。

• USDに“デフォルト”時間における値を照会すると、デフォルト値が設定されていれば、その値が返され、設定されていなければ空っぽの値が返されます。すべてのタイムサンプル値は無視されます。他の時間における値を照会し、デフォルト値またはタイムサンプル値が設定されていれば、その値が返されます。 この値は、デフォルト値(最初のタイムサンプルより前の時間で値を照会した場合)、最近接タイムサンプル値、2つの周辺タイムサンプル間の線形補間値のどれかです。

LOPノードのHoudiniパラメータはアニメーションさせることができ、USDをディスクに書き出す時、Houdiniは、そのアニメーション値をタイムサンプルとして書き出します。

• スキーマは、新しいPrimタイプを定義したり、新しいアトリビュートの意味/挙動を定義することができるカスタムエクステンションです。

  “ツリー”レベルでは、USDは非常に汎用的で“自由形式”です。 アトリビュートに任意のタイプの値を直接設定することができます。 スキーマは、制約と不変条件を強制することができます。 よりハイレベルなAPIを使用することで、アトリビュートを“正しく”編集することができます(値を特定の範囲内に抑えたり、ありえない設定ができないようにすることができます)。

• USDでは、独自のPrimタイプを定義したスキーマのことを Typed Schema(型決めスキーマ) と呼びます。

• USDでは、異なるタイプのPrim上に適用可能なAPIだけを定義したスキーマのことを APIスキーマ と呼びます。このタイプのスキーマは、通常では名前がAPIで終わります。

  APIスキーマは、さらに 単体適用 と 複数適用 に分かれます。

  • 単体適用スキーマの例がUsdLuxShapingAPIです。ライトPrimにシェイピングコントロールを追加するかしないか制御することができます。 適用済みのすべての単体適用APIスキーマのリストを記録したメタデータがPrimsにあります。

  • 複数適用スキーマの例がCollectionAPIです。指定したPrim上に必要なだけcollection:が付いた固有な名前のアトリビュートを定義することができます。

一般的にHoudiniはカスタムアトリビュートを使用しません。代わりに、Primのメタデータで“カスタムデータ”辞書に情報を保存することが多いです。この空間は、ソフトウェアパッケージでの利用やスタジオ独自の利用向けにあります。 Houdiniは、ここではUSDをディスクに保存したりシーンをナビゲーションするのに役立つを簿記情報を保存しますが、このカスタムデータは通常ではディスクに書き出されたUSDから抜き出します。

レイヤー内に記述されているすべてのPrimには、合成シーン内でのそのPrimの解釈方法に関して作成者の意図を伝える指定子があります。 指定可能な値が3つあります:

• Define (def): 合成シーン内に常に存在すべきConcrete(具現)Prim。

• Over (over): 合成シーン内に既に存在するオピニオンのオーバーライドを保持するためだけに存在するPrim。このPrimが他のレイヤーで定義されていなければ、Concrete(具現)Primになることはなく、Scene Graph Treeに表示されることはほとんどありません。

• Class (class): InheritまたはSpecializeのコンポジションアークのターゲットとして意図します。このPrimはHydraで無視されますが、通常ではScene Graph Treeに表示されます。

USDは、特定の時点でUSDシーンから画像を生成するためのAPI(Hydraと呼びます)を定義します。 (Houdini、usdview、レンダラーなどの)プログラムがこのAPIを実装している限り、このAPIを使用してUSDシーンを表示/レンダリングすることができます。

このAPIを実装したソフトウェアのことを、 レンダーデリゲート と呼びます。

Houdiniでは、このAPIの素晴らしい恩恵のおかげで、HoudiniのOpenGLビューア、PixarのStrom OpenGLビューア、Karma IPRなどの利用可能なレンダーデリゲート間でシーンビューを切り替えることができます。 さらに、Hydra APIを実装した サードパーティ製レンダラー を使ってシーンをビューイングすることできます。 特にHoudiniと統合するための余計な作業は必要ありません。

• 一般的には、“トップレベル”のUSDファイルは ショット を表現します。 スタジオでは、このトップレベルのファイルは通常では 部署 別に分けられたファイル(キャラクタ、セット/プロップ、ライト)を参照します。各ファイル自身も個々のアセットを参照します。 小規模または個人の環境では、このトップレベルのファイルは、直接アセットを参照する場合もあるでしょう。

• USD参照の深度を“遅さ”(複雑さ)の尺度として見るのは役に立ちません。USDのコンポジションエンジンは非常に高速です。 (ロード時間などの)パフォーマンスは、参照のレベルの深さよりも、レイヤーの内容や(ファイルをローカルまたはネットワークで読み込む)インフラに左右されます。

• USDドキュメントでは、シーンツリーのことを ネームスペース と呼んでいます。

• 絶対ファイルパスの使用を避け、Windowsでもスラッシュを使用してください。

  相対パス参照(例えば、./chair.usd)は、参照を含んだレイヤーファイル(例えば、/Users/Aisha/Work/kitchen.usd)が基準です。

  大規模スタジオまたは複雑なファイル管理のケースでは、おそらく複雑なファイルパスを使用するよりも、アセットIDとカスタムレゾルバを使用した方が良いです。

  Houdiniでは、通常だと$HIP(シーンファイルを含んだディレクトリ)や$JOB(プロジェクトディレクトリ)やスタジオ固有変数などの環境変数で指定されたディレクトリを基準にファイルを保存します。HoudiniがUSDを書き出す時は、出力プロセッサをコールしてファイルパスを変換します。 デフォルトの出力プロセッサは、$HIPを基準としたファイルパスを、USDの慣例に従ってトップレベルのUSDファイルを基準としたパスに変換します。

• USDの紹介(Pixar)

• USD用語集(Pixar)

• USDのよくある質問(Pixar)