| On this page |
はじめに ¶
以下には、LOPとUSDに関連した一般的な用語を載せています。
Pixarの全USDドキュメントはここにあります。
このドキュメントは、Houdiniユーザーが使用頻度の高いUSD用語について調べて理解できるように作成しており、USDとHoudiniの両方で起きる用語の重複を明確化するのに役立ちます。 それぞれの見出しは、PixarのUSDドキュメントのリンクで始まっています。 見出しに何もテキストがない場合は、その用語が使用頻度の高い用語の一つでは ない と考えています。 USDリンクがない場合は、その用語はUSD用語ではなくてHoudini用語または補足用の用語です。
用語集 ¶
Active / Inactive(アクティブ / 非アクティブ)
ステージからPrims(と子Prims)を“Prune(取り除く)”することができる非破壊的な挙動。 合成されたステージ上で(その場で)これを実行します。 デフォルトでは、すべてのPrimsはアクティブです。これはHoudiniでいうオブジェクトノードのディスプレイフラグの概念と同様です。
USD Primsの重要な特性は、合成されたステージから永久にPrimsを削除することができないことです(たいていは一度ステージ上の何かになるので、誰でもそれを参照して何かを駆動させることができます)。 USDは、非破壊的な削除をする非アクティブ化に対応しています。 アクティブ化は、合成を介してPrimsが解決されることを意味した1つのオピニオンです。
これは、何かしらの効果を無効にしてシーンを可視化したい時によく使用します。 例えば、キャラクタに特化したライトを表示させたいのであれば、シーンのライティングを削除した方が良いでしょう。 Houdiniと同様に、アクティブ化と表示は考え方が異なります。 しかし、Houdiniでは、ライトの表示を無効にしても、そのライトのシーンへの寄与には何も影響しません。 LOP/USDでは、ライトの表示を無効にすると、実際にその寄与が 無効になります 。
LOPでは、“Configure Layer”または“Prune LOP”を使ってアクティブを設定します。
Muting(ミュート)とVisibility(可視性)も参照してください。
Note
HOUDINIメモ: HoudiniのBullet RBDシミュレーションでは、activePointアトリビュートを使って、オブジェクトのアクティブ/非アクティブを制御しています。
ほとんどのLOPノードは、1番目の入力からコピーされたUSDステージ上のデータに対して編集を行ないます。 これらの編集は、LOPノードのステージのルートレイヤー上で常に一番強いサブレイヤーである“アクティブレイヤー”内に作成されます。 ノードの“アクティブレイヤー”にアクセスすると、読み込み専用オブジェクトが返されます。 アクティブレイヤーに編集を加えたいのであれば、Python LOPを使用することで、“編集可能なレイヤー”が利用可能になります。
Python LOPを参照してください。
まったくUSDの一部ではありませんが、USDにはAlembic対応が含まれています。 しかし、USDは単なる“Alembicではないけれど、それよりも高速”です。 USDは、データを格納可能な独自フォーマットを搭載していますが、バリエーション、レイヤー、入れ子化できるサブレイヤー、表示別のPurpose、さらには独自データ形式を定義する機能を記述することができる非常に幅広いシーン記述ファイルです。 公式のAlembic USDプラグインのページには技術的な詳細がたくさん載っています。
SOPまたはOBJノードを使用してHoudiniに取り込まれたAlembicデータは、HoudiniのネイティブAlembicコードを使用します。 LOPノードまたはUSD Import SOPを使用してサブレイヤー化または参照されたAlembicファイルは、USDのAlembicファイルフォーマットプラグインに依存します。
複数の異なるタイプのPrimsに適用する必要がある関連プロパティ、メタデータ、場合によっては関連動作も用意したい時には、APIスキーマを作成することが選択肢になります。 例えば、あなたのパイプラインで、すべてのGPrimに対して編集する3個のアトリビュートがあって、それらのアトリビュートを編集/抽出するための堅牢なスキーマを用意したいのであれば、それ用のAPIスキーマを作成することができます。
スキーマも参照してください。
AOVとは、“Auxiliary Output Variable(補助出力変数)”のことで、USD用語ではありませんが、Houdiniでいう従来の“Extra Image Planes”を意味した一般的に広まっている業界用語です。 UsdRenderの仕様では、このような変数をRender Varsとして定義しています。 LOPコンテキストでも、Render VarsとかAOVsと呼んでいますが、Houdiniでは今でもどこかで“Extra Image Planes”を目にすることでしょう。
AOVは、レンダリング処理の一部を抽出してレンダリングされた画像(例:ディフューズ寄与度、スペキュラー寄与度)または任意のデータ(例:ID、depth、velocity)です。AOVは、“ビューティー”パスがレンダリングされている最中に作成され、個々のファイルまたはEXRレイヤーとして保存することができます。
AOVのことを“arbout”(Arbitrary Output)、“Deep Raster”、“Rendervars”とも呼んだりします。 AOVと“レンダーパス”を混同しないでください。“レンダーパス”は完全に分離されたレンダーを指します(これにはAOVも含まれます)。
“Render Variable(レンダー変数)”も参照してください。
Assemblyとはグループモデル、要するに、他のモデルを意味のある集合体に集めたモデルのことです。 Assemblyは主に他のモデルの参照で構成し、それらの参照自体はパブリッシュされたアセットです。
アセンブリ、グループ、コンポーネント、サブコンポーネントは、ステージの管理に役立つ体系化フレームワークです。 USDやHoudiniに同梱されている台所シーンのサンプルを見てみましょう。 このシーンでは、台所にたくさんの家具、電化製品などが配置されています。 これらの物を日常用語で意味のわかる方法でグループ化した方が明らかに都合が良いです。
体系名 |
例 |
モデルの種類は? |
描画モードを設定できるか? |
他の種類を含めることができるか? |
|---|---|---|---|---|
Assembly |
Kitchen |
Yes ✔ |
Yes ✔ |
Assembly, Group, Component ✔ |
Group |
Dining Table |
Yes ✔ |
Yes ✔ |
Group, Component ✔ |
Component |
Chair 1 |
Yes ✔ |
Yes ✔ |
Subcomponent ✔ |
Subcomponent |
Chair 1 Cushion |
No ⤬ |
No ⤬ |
No ⤬ |
サブコンポーネントには子サブコンポーネントまたはリーフPrims(例えば、クッションを構成している個々のポリゴン)を含めることができます。 サブコンポーネントに対して描画モード(シェード、ワイヤーフレーム、境界ボックス)を設定することはできません。
USDでは、Assemblyは一種のモデルです。
“Model Kind”とは何かについては、モデルを参照してください。
Asset(アセット)とかAsset Path(アセットパス)とは、コンテンツ制作パイプラインにおける、非常に一般的な構成概念のことです。 アセットは、単一ファイル(例えば、UVテクスチャ)を意味することもあれば、ある単一ファイルを基準として順々に他のファイルを参照するファイル群を意味します。 重要な品質のアセットは、一般的にはパブリッシュしてバージョン管理します。
アセットパスは、文字列から完全なパスを解決するAsset Resolver(アセット解決器)に依存しているので固有なパスになります。 USDには、通常文字列と簡単に区別できるようにアセット値文字列用の特殊構文があり、アセット値を区切る際には引用符ではなく“@”記号を使用します。
詳細は、Asset Resolver(アセット解決器)を参照してください。
USDには“Asset Resolver(アセットレゾルバ)”と呼ばれる特別な仕組みがあります。
これは、“Asset Paths”と呼ばれる独特な文字列アトリビュートに適用されます。
その文字列アトリビュート値は、ファイルパスを@@で閉じた文字列です。
アスキー形式のUSDシーンを開いて見たり、または、Scene Graph Detailsで値を調べてみると、Asset Pathsがあるのが確認できます。
アセットレゾルバは、USDファイルの中身を変えることなくデータまたはディスクファイルを表現するのに大規模または作り込んだUSDパイプラインに役立つ機能です。
アトリビュートとは、ほとんどのUSDシーンの編集で非常によく使用されるタイプのプロパティのことです。 (他のHoudiniのアトリビュートと同様に)アトリビュートは、単なる何種類かの値です(例えば、カラー、浮動小数点、トランスフォーム行列、値の配列)。 USDでは通常だとアトリビュートは、スキーマで定義されるPrimの必須部分であり、カスタムアトリビュートを作成することもできます。 アトリビュートはアニメーション可能であり、配列で各タイムサンプルを保存します。 アトリビュートはPrimvarよりも制限が強くて、親Primsからは継承されません。
アトリビュートは“強者が勝つ”ルールに基づいた解決をするので、指定したアトリビュートの値すべてが最強のPrimSpecから取得されます。 例えば、デフォルト値を持った“弱いレイヤー”は、アニメーションを持った強いレイヤーでマスクされます。 これは、レイアウト部署がシーン内にプロップを配置し、後でアニメーション部署がそのプロップをアニメーションさせたケースです。
USDに“デフォルト”時間における値を照会すると、デフォルト値が設定されていれば、その値が返され、設定されていなければ空っぽの値が返されます。 すべてのタイムサンプル値は無視されます。他の時間における値を照会し、デフォルト値またはタイムサンプル値が設定されていれば、その値が返されます。 この値は、デフォルト値(最初のタイムサンプルより前の時間で値を照会した場合)、最近接タイムサンプル値、2つの周辺タイムサンプル間の線形補間値のどれかです。
ブロック(阻止)は“元に戻せる削除”で、プリミティブの非アクアティブ化が元に戻せることと同様です。
Attribute Connection(アトリビュート接続)
シェーダPrimには入力と出力のコネクションがあります。 これらのコネクションは、シェーダPrimがマテリアルグラフを繋げて構築できるようにするための特別なリレーションシップタイプになっています。
これは、値を格納するPrim用ではあるものの、値が要求されない限りその値を走査させたくないPrim用のSpecifier(指定子)です。 Class PrimはHydraでビューポートに直接描画されません。
USDレイヤーでは、これらのPrimの頭にはclass接頭辞が付きます。
USDのコレクションは、Primのグループであると考えることができ、LOPsにはコレクションの操作を便利にするための仕組みがいくつかあり、 その仕組の一部は、ターゲットパターンセクションで説明しています。 これはHoudiniバンドルに似ています。
コレクションは、“Include”リストと“Exclude”リストで構成します。 Solaris内では、ターゲットパターンを使用してプロシージャルにコレクションターゲットを収集することができますが、 USDファイルにエクスポートされるコレクションはプロシージャル ではない ことに注意するのが重要です。
コンポジションとは、お互いにレイヤーを関係付ける コンポジションアーク によって複数の レイヤー を組み立てる処理のことです。 コンポジションは、最初にUsdStageを開いた時、そのステージ上のPrimをロードまたはアンロードした時、そのステージに寄与しているレイヤーを編集した時に実行されます。
時折、“コンポジション”とか“合成Prim”とか“合成シーン”と呼ぶこともありますが、どちらの呼び方でも、コンポジションを実行した結果のことを意味します。
LOPでは、Scene Graph Details内のCompositionタブがPrim/アトリビュート(それぞれ"PrimStacks、"PropertyStacksと呼びます)に寄与しているすべてのコンポジションアークを表示します。 PrimStacks/PropertyStacksは、Layer Stacksとは原理的に似ていますが少し異なります。
USDでのコンポジションは、非常に奥深いテーマなので、この概念が浸透し始めるまでにしばらく時間がかかることに驚かないでください。 Sublayer(サブレイヤー)、Reference(リファレンス)/Payload(ペイロード)、VariantSets(バリアントセット)からかなり多くの利用価値が得られます。 すべてのコンポジションアークを理解するもの良いでしょうが、これら3つのコンポジションアークは間違いなく一番使用頻度が高いです。 以下のコンポジションアークは、強い順で並べています:
LIVRPS Strength Ordering(LIVRPS強度順番決め)も参照してください。
コンポジションアークとは、USDでたくさんのレイヤーで構成されたリッチなコンポジションの作成を可能とする“オペレータ”のことで、強いレイヤーが弱いレイヤーをオーバーライドします。 コンポジションアークには、SubLayers(サブレイヤー)、Inherits(継承)、VariantSets(バリアントセット)、References(リファレンス)、Payloads(ペイロード)、Specializes(特別化)の6種類があります。
Composition(コンポジション)も参照してください。
コンテキストオプションとは、LOPネットワークのコンテキストを変更する際に使用可能な特別な変数のことです。 コンテキストオプションを使用することで、例えば、いくつかの異なるショット間でグラフを切り替えたり、異なるライティングセットアップをWedgeさせる際にグラフを切り替えることができます。 コンテキストオプションはグローバルで設定することができ、ネットワーク内に特別なブロックをセットアップすることでコンテキストオプションをローカルに設定することができます。 ForEach LOPはコンテキストオプションの特別なブロックのセットアップと考えることができます。
Crate File Format(木箱ファイルフォーマット)
USDファイルのバイナリフォーマットのことで、ファイル拡張子は.usdcです。
“.usd”ファイルフォーマットは特別で、その拡張子のファイルはCrateファイルやASCIIファイルのどちらにも使うことができます。
usdcatを使用することで、これらのファイルフォーマット間を変換することができます。
USDファイル内でPrimを作成(というか定義)するSpecifier(指定子)のことです。 必ずしも型を設定する必要はありませんが、通常では型を設定します。
アスキー形式のUSDファイルを調べると、頭にdefが付いているPrimがあります。
USDレイヤー内に設定される静的な値。
表示されているファイル、または、そのファイルのサブレイヤーのどれかから取得される値がDirect Opinionです。 Direct Opinionが最も強いオピニオンで、他のどのオピニオンも上書きします。 Solarisでは、1番目(または唯一)の入力からデータを作成/編集するLOPノードがDirect Opinionです。
USDで定義されているジオメトリカラー用の標準Primvar。
マテリアルのバインドは不要です。
これはHoudiniでいう@Cdアトリビュートに相当します。
USDで定義されているジオメトリ透明度用の標準Primvar。
マテリアルのバインドは不要です。
これはHoudiniでいう@Alphaアトリビュートに相当します。
CGでは一般的に“Draw Mode”とは、ビューポート内でジオメトリを描画する方法(ワイヤーフレーム、シェードなど)を指します。 USDでは、これは、有効なKind Model階層内のプリミティブ上に設定可能なメタデータで、そのPrimと子Primをフルジオメトリ、境界ボックス、テクスチャカード、Prim原点の座標のどれかによる描画を制御します。
明示レイヤーは、LOPネットワークの処理時にユーザーが新しいレイヤーを作成するように指示した結果として生成されたUSDレイヤーのことです。 このレイヤーには、“Start New Layer”に設定されたLayer Configureノードの後に作成されたレイヤーまたは保存パスが設定されたノードで作成されたレイヤーが含まれます。 明示レイヤーは、Flatten All LayersモードまたはFlatten Stageモードでない限りは、USD出力中に他のレイヤーと結合されません。
Implicit Layers(暗黙レイヤー)も参照してください。
Fallbackは、Primタイプで必須の値を意味します。 このような値は、本来はスキーマ側で必須であり、シーン内で他の値が指定されていない場合に常に存在します。 この例を挙げると、球の 半径 がそうです。 半径 の値がなければ、球を定義できないです。
USDファイルには、ライト、カメラ、マテリアル、レンダー設定、アニメーション、ジオメトリ、もちろん完全シーン記述を格納することができます。USDファイルは以下の形式で保存することができます:
-
.usda: ASCII(人が解読可能な形式で、通常では部署向けまたは上層レベルのレイヤーで使用します) -
.usdc: バイナリCrate(読み書きが高速で、通常では大規模キャッシュで使用します) -
.usd: 上記のどちらにもなることができます。
Note
usdcatユーティリティを使用することで、ファイルフォーマット間を変換することができます。
FXアーティストなら、上記のフォーマットのどれに対しても(1,2,3,4または1.25,1.50,1.75,2.0)のように選択したタイムサンプルを保存することができるのか興味があることでしょう。 そのような連番のサンプルで各タイムサンプルを別ファイルまたは1ファイルのどちらで保存するのか選択することもできます。
平坦化とは、複数のUSDレイヤーを単一USDレイヤーに結合することを言います。これは、一度合成されると、元のレイヤー構成と同じになります。 USDは、2種類の方法で平坦化を行なうことができます。 1つ目の方法はレイヤーの平坦化です。これは、レイヤーを合成する前にそれらのレイヤーを平坦化します。 つまり、ReferencesとVariantSetsのようなコンポジションアークは、この平坦化されたレイヤー内で存在し続けます。 2つ目の方法はステージの平坦化です。これは、すべてのコンポジションアークが既に適用済みの状態で合成されたステージを平坦化します。 つまり、ReferenceファイルまたはPayloadファイルすべての内容が、1枚に生成されたレイヤーに合成されます。 バリアントと他の内部コンポジションアークは、現行値にハード化されるので、プリミティブが今までバリアントコンポジションアークを持っていたことを知ることができません。
Prim(プリム)ジオメトリのサブセットを表現した特別なPrim。 GeomSubsetはフェースセットを表現し、必ずメッシュの子である必要があります。 この主な目的は、メッシュのフェースにマテリアルを割り当てることです。
Graftは、プリミティブをメインシーングラフ内のどこかにコピーします。 Graftは、コピーする実際のプリミティブが必要なので、レイヤースタック(要するに、サブレイヤー)を平坦化します。 リファレンスを介してでしか存在しないプリミティブは、まず最初にステージ全体を平坦化しないとGraftすることができません。 Solaris内では、Graftはまるでリファレンスのように見えますが、データを単に参照しているのではなくて、実際にデータをコピーしています。
Flatten(平坦化)とReferences(リファレンス)を参照してください。
Gprimは、PixarのRenderman用語に由来し、“Geometric primitive”の略です。 つまり、イメージ化/レンダリングによって何かが直接的に描画されるPrimのことです。
Gprimの例を挙げると、メッシュ、基本カーブ、球、円錐があります。
LOPステージは、USD ROPの保存工程の時、または、特定のLOPノードのクックメソッドで使用されるHoudini固有の追加メタデータを格納します。
このメタデータは、シーングラフ内の/HoudiniLayerInfoにある専用USDプリミティブ上に格納されます。
この/HoudiniLayerInfoは、'HoudiniLayerInfo'という名前のカスタムUSDプリミティブタイプです。
(明示的に保存工程がHoudini固有のカスタムデータを保持するように要求しない限り、とはいっても、通常はLOPネットワークの挙動をローレベルでデバッグする場合にしか役に立ちませんが)このプリミティブは保存工程の時に削除されるので、どの外部ツールもこの特別なプリミティブタイプについて知る必要はありません。
Houdini Proceduralsは、レンダリング時にステージ上にプリミティブを作成したり変更するためのレンダラーに依存しない仕組みです。 これは、与えられたUSDシーンが合成された後、且つ、Pre-Render Script/Pre-Frame Scriptが呼び出される前のレンダリング時に呼び出されます。
Hydraは、ビューポートでUSDステージを描画する時に使用される機構です。 レンダリングする際にHydraから情報を受け取るプラグインのことをレンダーデリゲートと呼びます。 HoudiniにはOpenGLデリゲート、一部のプラットフォームでStorm、あともちろんKarmaが同梱されています。
Karmaまたは他に対応しているレンダーデリゲートを使ってUSDシーンをレンダリングするツール。
これは、
USD Render ROPに相当するコマンドラインです。
huskユーティリティも参照してください。
暗黙レイヤーとは、LOPネットワークがメモリ内に作成したレイヤーのことで、これを(また別にLOPネットワークで作成された)他の明示レイヤーに平坦化させると、保存工程の時に無関係な要素として消されます(といっても、暗黙レイヤーが表現したオピニオンは、平坦化されても保持されるようにすることができます)。
暗黙レイヤーには、デバッグフラグを設定したLOPノードで作成されたレイヤー、Separate LayersモードでMerge LOPによって自動的に開始された新しいレイヤーが該当します。
Explicit Layers(明示レイヤー)を参照してください。
非永久的に“削除”された不活性プリミティブ。 非アクティブプリミティブの子プリミティブを評価する方法はありません。
アクティブ/非アクティブを参照してください。
Inherits(継承)は、ローカル参照と同様ですが、複数レベルの参照に至って“活動”させたままにすることができます。 継承されたオピニオンはリファレンスよりも強いです。 それどころか、継承されたオピニオンは、(直接のオピニオンを除く)他のどのオピニオンよりも強いです。 一般的には、Inherits(継承)を使って、アセットやマテリアルの“クラス”のすべてのメンバーに対してオーバーライドを広めることになります。
Prim上のメタデータであり、これによってUSDはステージ内の別々のPrim上で同じリファレンス/ペイロードの複数体の間で共通のリファレンス/ペイロードを共有できるようになります。 これが実施されると、“ネイティブインスタンス”が生成されます。
Instancing(インスタンス化)を参照してください。
USDでは、2つの方法のインスタンス化があります:
-
ネイティブインスタンシングは、効率的にアセットのコピーをたくさん表現できるようにするために、USDに単一の“プロトタイププリミティブ”を生成するように命令するプロパティです。
-
ポイントインスタンサーは、ジオメトリの膨大なコピーを効率的に表現できる特別なスキーマです。
どちらのタイプのインスタンス化も、各プリミティブのトップレベルのトランスフォームに対応しており、さらに、(各ネイティブインスタンスに対して、または、ポイントインスタンサープリミティブに対して)Primvarsを編集してインスタンス単位でマテリアルプロパティを設定することもできます。 ネイティブインスタンスは、各インスタンスの実トランスフォームで、各インスタンスはシーン内で固有のネームスペースとして表現されます。 ネイティブインスタンスは、簡単にインスタンスからヒーローに昇格することができます(単に“instanceable”プロパティを無効にするだけです)。
ポイントインスタンサーは高速ですが、すべてのインスタンスのトランスフォームは、ポイントインスタンサープリミティブ上の配列アトリビュートとして設定されます。 インスタンスからヒーローに昇格させるには、シーンをMutate(変異)させる必要があります。 生成させたいインスタンスの数が多いほど、たいていの場合はヒーローに昇格させるよりもポイントインスタンスのままにする方が望ましいです。
私どもは、Kindを使用してUSD内のPrimsをそのPrimのスキーマタイプで用意されたカテゴリよりももっと高いレベルのカテゴリに分類します。 これは主にUSDにおける体系化の概念である“Model Hierarchy”に応じて役割を割り当てるのに使用します。
Kindはパイプライン内で簡単に拡張することができるので、色々なアセットに対してもっと明確なラベルを付けることができます。
Model(モデル)とAssembly(アセンブリ)も参照してください。
レイヤーはPrimsとオピニオンのコンテナです。 レイヤーは、通常ではディスク上の個々のusd/usda/usdcファイルのどれかであり、他にも、後でディスクに書き出せるようにLOPノードによってレイヤーをメモリ内に作成することもできます。 シーン内に数百または数千ものレイヤーを持つことは、よくあることです。 これらのレイヤーがまとめて合成されて、ユーザー側に完全なシーングラフのビューを表示します。
例えば、モデリング部署からは、1つのモデルまたは複数のモデルを含んだ1枚以上のレイヤーが納品されることでしょう。 プロップ/キャラクタ/アセットは、だいたいそれ自身がレイヤーになりますが、アセットに関しては複数のレイヤーで構成されることもあります。 レイアウト部署は、それらの個々のアセットを参照したレイヤーを作成し、それらのレイヤーをシーンにアセンブル(組み立て)します。 アニメーション部署からは、それらのレイヤーの一部または全部にアニメーションを付けたレイヤーが納品されます。
レイヤーは、シーングラフ内のPrimsに関するオピニオンを含んでいます。 これらのオピニオンの一部は、Primsと値を定義し、それ以外のオピニオンは値をオーバーレイします。 レイヤーは、ディスク上のファイルから読み込むのですが、他にも単にメモリ内に存在するレイヤー(これを“Anonymous(匿名)”レイヤーと呼びます)もあります。
レイヤーまたはサブレイヤーをミュートすることができます。ミュートすると、そのレイヤーはシーンに何も影響を与えなくなります。 これは、レイヤーに何かを破棄させる時、または、レイヤーの再生や操作が遅くなった時に役立ちます。
LOPsでは、レイヤーのプロパティを設定する時は“Configure Layer LOP”を使用し、レイヤーにミュートを設定したり、シーンにマスクを追加する時は“Configure Stage LOP”を使用します。
レイヤーは、様々なファイルフォーマットプラグインで拡張することができます。
最も一般的なレイヤーはusd/usda/usdcファイルですが、USDにはAlembicファイルフォーマットプラグインも含まれています。
Solarisには、さらに追加されたファイルフォーマットプラグインが含まれており、これらのプラグインによって、ユーザはHoudiniがサポートしているほとんどのジオメトリフォーマットをサブレイヤー化、リファレンス、ペイロードすることができています。
.bgeoファイルの使用を除き、それらのほとんどのジオメトリフォーマットはおそらく制作では役に立ちません。
Implicit Layers(暗黙レイヤー)も参照してください。
Sublayer(サブレイヤー)とReference(リファレンス)は、自身に含まれているアニメーション値を再編集することなく、そのタイミングをずらすことができます。
LayerStackとは、USDのコンポジションを理解するための要石です。 LayerStackの定義は単純です:“レイヤーからすべてのサブレイヤーを再帰的に収集した順番通りのレイヤー群。ここには、そのレイヤー自体が1番目で最強として含まれます。”
LayerStackがコンポジションを理解する上で重要である理由が2つあります:
-
コンポジションアークは、レイヤーではなくLayerStackをターゲットにします。レイヤーが他のレイヤーをリファレンス(またはペイロードもしくはサブレイヤー化)した時、そのレイヤーが単一レイヤー内のデータだけでなく、そのターゲットレイヤーのルートのLayerStack内のすべてのデータも(強い順で)ターゲット(そしてコンポジット)にします。
-
LayerStackには、参照をリスト編集可能なコンテナが用意されています。多くのコンポジションアーク(とリレーションシップ)は、単一ターゲットだけでなく、順番付きでターゲットのリストを記述することができます。これらのターゲットは、コンポジションアークのタイプに応じて(順番に)処理されます。LayerStackのレイヤー間で参照を“リスト編集”することができます。これは、大規模スケールのシーン構造をパイプラインに流す際に、そのシーン構造を非破壊的に変更できる強力なメソッドです。
例えば、シーケンスレベルで汎用版の特別なエフェクトをシーンに追加したとします。 今、ショットレベルでshotFX.usdレイヤーがあります この特定のショットでは、そのショットが完全に異なるPrimを所有しているので、汎用乱流エフェクトを別のエフェクトに置換する必要があります。 そのため、turbulence.usdのPrimはまだ“存在”しているので、余分な参照を“追加”するだけでは不十分です。 つまり、弱い参照をさらに削除しなければなりません。これは、リスト編集で可能です。
キャラクタアニメーション、ショットライティング、カメラワークなどのショットに寄与するレイヤーは、通常ではサブレイヤーにします。
“リーフ”という用語はUSD用語ではなく、子を持たない分岐構造の末端を意味した一般用語です。 ファイルツリーだと、ディレクトリやファイルの入れ子リストの中の最後のファイルがリーフタイプです。 USDでの“Leaf Prims”は通常ではGprimsを意味します。
値リストの組み立て方法を制御するいくつかのUSD機構の機能のことです。 どのリファレンス、ペイロード、バリアントもこれを行なうことができます。 パラメータまたはオペレーション(“Prepend”や“Append”を含む)があるところにリスト編集があります。 “Prepend”が典型的に一番予想通りの結果が得られるので、通常ではSolarisではデフォルトになっています。 技術的な詳細はUSD用語集を参照してください。
ペイロードを使って編集されるPrimsはロードまたはアンロードによって、重いシーンの対話的な操作を高速化することができます。 実務では、まず最初にペイロードを使ってショットをアンロードで開き、次にアーティストがどのモデルを読み込みたいのかを決めます。 ペイロードの状態は操作時に決めるものなので、USDファイルにはエクスポートされません。
Payload(ペイロード)も参照してください。
リファレンス化またはサブレイヤー化されている散らばったファイルをすべて1箇所に集めて、特定のステージを生成します。 USD ROPには出力プロセッサがあります。この出力プロセッサは、非USDファイルをフォルダに収納することができます。 これは、色々なフォルダからテクスチャマップを1箇所に集める時に役立ちます。
Sublayer LOPまたはReference LOPの2番目以降のレイヤー入力からLOPノードの出力にアクセスする時、または、LOP Import SOPからLOPノードの合成ステージにアクセスする時、そのアクセス先のLOPノードで生成された合成ステージはロックする必要があります。 ロックされたステージは、そのLOPノードの共有ステージのコピーになりますが、そのアクティブレイヤーの内容はそのステージのルートレイヤーにコピーされます。 ロックされたステージは、変更されないことが保証され、ディスク上のファイルと同様に、クックチェーンの下流にある他のLOPノードからも修正することはできません。
Houdiniのライティング/ルックデブのコンテキストはLOPsで、Lighting Operatorsの略です。 LOPネットワークはSOPsに似ていますが、Houdiniのジオメトリモデルを使うわけではなくて、LOPsはUSDシーン記述を使います。
LOP Stage / Shared Stage(LOPステージ / 共有ステージ)
すべてのLOPは、合成されたUSDステージを生成することができます。 とはいえ、パフォーマンスとスケーラビリティの観点から、大元のUSDステージをチェーン内の複数のLOPノード間で共有させることができます。 そのため、LOPノードで生成された合成ステージのことを、そのステージを共有できるかどうかでLOP Stage(LOPステージ)またはShared Stage(共有ステージ)と呼びます。 しかし、どちらの用語も同じ意味です。
MaterialXは、レンダラー間で移植可能なマテリアルネットワークを記述するためのシステムです。 Karmaでは、UsdMtlXプラグインを使用してUSDエンコードされたネットワークのレンダリングのみに対応しています。
Prim、アトリビュート、レイヤーはどれもメタデータを持つことができます。 Solarisでメタデータを検査する主なUIはScene Graph Detailsペインです。ここにはメタデータペインが含まれています。 メタデータはPrim/アトリビュート値と同様に合成することができますが、レイヤーのメタデータは合成することができません。
USDでは、“Model”は単一コンポーネントでも複数グループコンテナでもありません。これは、単にコンポーネントとグループの中間である“抽象的な”共通性です。 通常では、Model(モデル)は出荷されたアセットを意味します。
USDモデルはスケールモデルキット(プラモデル)のようなものと考えると良いでしょう。つまり、モデルがプラスチック部品で、すべて組み立てた後にペイントしたりシールを貼ります。
Kind(種類)は、特定のPrimをモデルとしてラベルを付けて、大きなシーングラフをもっと管理可能な単位に分割するのに使用します:
Note
従来のコンピューグラフィックスの“ジオメトリ”の感覚でUSD “モデル”のことを考えないでください。 USD “モデル”は、大きなシーングラフをもっと管理可能な単位に分割する際に使用する抽象的な概念です。
Model(モデル)が有効になるために従うシーングラフ階層に関するルール。
Muting/Layer Muting(ミュート/レイヤーミュート)
レイヤーの重要な特徴の1つは、レイヤーをミュートすることができることです。 レイヤーをミュートすると、そのステージが再合成され、ミュートしたレイヤー(s)のすべてのオピニオンは、もはやシーンに何も影響を与えなくなります。 レイヤーがショット内の何かを壊してしまった場合、または、レイヤーに何かしらの望ましくない効果があった場合、そのレイヤーはサブレイヤーのリストから削除することなくミュートにすることができます。 レイヤーをミュートするには、そのレイヤーはサブレイヤーである必要はないのですが、一般的には本番環境で最終的にミュートすることになるレイヤーです。
例えば、FXがshot.usdaレイヤーより上のレイヤーで作業した場合、ショットの再生は非常に遅いです。
この場合、そのショットを読み込んだアーティストは、単にそのshotFX.usdレイヤーをミュートするだけで、USDはそのショットを再合成しますが、そのshotFX.usdレイヤーのすべてのオピニオンは無視されます。
アクティブも参照してください。
Primのネームスペースには通常は“Prim Path”を使用します。 コレクション、リレーションシップ、アトリビュート、Primvar名もネームスペースとして使用することができます。 一部のネームスペースはスキーマで定義しているものがありますが、単に慣例に従って定義されているものもあります。
例えば、すべてのPrimvarはprimvars:ネームスペース下にあります。
Karmaのオブジェクトプロパティは、primvars:karma:object:ネームスペース下に存在するPrimvarです。
レイヤーは、シーングラフ内のPrimsに関するオピニオンを含んでいます。 これらのオピニオンの一部は、Primsと値を定義し、それ以外のオピニオンは値をオーバーレイします。
オピニオンとは、USDのValue Resolution(値解決)に関与する原子的なエレメントです。 メタデータ、アトリビュート、リレーションシップの値を編集する度に、あなたは特定のレイヤー内のPrimSpec内のオブジェクトのオピニオンを表現していくことになります。 合成したステージ上では、異なるレイヤーの複数のオピニオンがオブジェクトに影響を与えます。
ここで例を挙げます: アセット部署で編集されたボールがあったとします。 そのアセット部署では、このボールを赤にすることに決めて、このボールに(1,0,0)のディフューズカラーを設定しました。 この場合、そのディフューズカラーが“オピニオン”です。 後で、ライティング部署で、そのボールを青にすることに決めて、ローカルレイヤースタック内で(0,0,1)のディフューズカラーを設定しました。 この“オピニオン”は、強いレイヤーに存在するオピニオンが優先されるので、そのボールが青でレンダリングされます。
“オピニオン”オペレータとか“オピニオン” LOPなるものは存在しません。 LOPノードを使ってオピニオンを編集し、それらのオピニオンをUSDで解析させて、ステージの合成を決定します。
レイヤー内のオピニオン用のSpecifier(指定子)で、特定のPrim上の弱いレイヤー内に定義されているデータを上書きするためのものです。 単純なOverはシーングラフ内に表示されますが、Primが定義されていないとあまり役に立ちません。
USDレイヤー内のOverは、頭にover接頭辞が付いたPrimになっています。
USD ASCII構文(とドキュメント)では、パスは、かぎ括弧で閉じます。例:
-
</Root/Child/Grandchild>は、入れ子化された3つのPrimの絶対Primパスを表現しています。 -
</Root/Child/Grandchild.visibility>は、Grandchild Primの“visibility”プロパティを指しています。 -
</Root/Child/Grandchild{modelingVariant=withCargoRack}/GreatGrandchild>は、“modelingVariant”バリアントセットの“withCargoRack”バリアント内で編集された“GreatGrandchild”子Primを表現しています。
ペイロードとは、最適化するためにアンロードが可能な特別な種類のReference(リファレンス)のことです。 この理由から、アセットの非常に重い部分(つまり、ジオメトリ)は、普段だとアセット内でペイロードとして読み込みます。 ペイロードはリファレンスよりも弱いです。ペイロードでファイルを合成しておけば、シーンのどの部分をメモリ内に読み込むべきなのか制御するのが簡単になり、 シーン内の興味のある部分だけを読み込んで注力することで、メモリ使用量と処理時間を抑えることができます。
デフォルトでは、Houdiniは、すべてペイロードとして読み込みます(この挙動はリファレンスとまったく同じです)。 しかし、Configure Stage LOPとシーングラフツリー内のLoad Masksコントロールでは、このデフォルトですべてのペイロードを読み込む挙動を無効にして、 どれをペイロードとして読み込むのかを指定することができます。
USDには独自のポイントインスタンサーモデルが搭載されています。 これは、非常に強力で、ジオメトリ、ボリューム、他の階層をインスタンス化することができ、さらには、他のポイントインスタンサーまでもインスタンス化することができます。
Point Instancerスキーマは、大量のジオメトリを可能な限り高速に描画できるように設計されています。 大量の瓦礫をシミュレーションしてアニメーションすることがよく求められるFXアーティスト用に主に設計し実装されました。 Point Instancer LOPは、Houdini標準のインスタンスPointアトリビュートを使って、各インスタンスのトランスフォームを調整します。
ポイント上にインスタンス化された各モデルのことを“プロトタイプ”と呼び、Point Instancer Primsはたくさんのプロトタイプを割り当てることができます。 Point Instancer Primsのアトリビュートを介してインスタンス毎のバリエーションを表現することができないのであれば、別のプロトタイプを使用する必要があります。 プロトタイプには、アニメーションジオメトリを含めることができ、Point Instancer Primsは他のPoint Instancersのプロトタイプを指定することができます。
この欠点は、Point Instancersはパイプラインで何かを処理する場合の柔軟性が非常に低いことです。 個々のPoint Instancerインスタンスを親子化するには、余計な作業が必要になり、個々のインスタンスへの変更は、そのスキーマから利用可能なアトリビュートに制限されています。 さらに、いくつもの固有なプロトタイプを使用することができるものの、あまりにもプロトタイプが多すぎると、Point Instancersを使用することによるパフォーマンスのメリットを相殺しかねないです。
LOPsでは、便宜的にPoint InstancersとNative Instancesを使って動作するLOPをいくつか用意しています:
-
Instance Variation - VEXスニペットを使ってインスタンスタンス別にプロパティをランダム化します。
-
Instance Retime - プロトタイプの時間を変更します。
-
Instance Extract - インスタンスを抽出して昇格させます。
-
Instance Transform - 個々のインスタンスを手動編集することができます。
Instancing(インスタンス化)も参照してください。
各LOPネットワークは、Pythonスクリプトによってセッションレイヤーを修正することができます。 これらの修正は、ビューポート内に表示されているLOPノードまたはScene Graph Treeがクックされた後に適用されます。 これらの修正をUSD ROPの出力ファイルに適用することもできて、USD Render ROPからレンダリングされた画像に影響を与えることができます。 詳細は、hou.LopPostLayerを参照してください。
PrimまたはPrimitiveとは、USDの基本オブジェクトのことです。
Primには、メッシュ、ライト、カメラ、シェーダなどのいくつかのタイプがあります(USDでは、これらのタイプのことをスキーマと呼んでいます)。 各スキーマは、各Primタイプが対応するプロパティのすべてを定義します。
Primsに他のPrimsを格納することで、ステージ上に“ネームスペース階層”を作成することができ、さらに、それらのPrimsには意味的なデータを保持したプロパティを格納することもできます。 Primsは、それらを関連付けて計算されたインデックスと一緒に、ステージがメモリ内に保持する唯一の持続シーングラフオブジェクトです。 Primsに作用するAPIは、UsdPrimクラスで用意されています。
Note
HOUDINI NOTE: 上記の説明だと、USDの“Prim”とHoudiniの“Primitive”は明らかに同じではありません。HoudiniのPrimitiveはレンダリング可能な最も単純な要素です(補足すると、Houdiniのポイントはレンダリング可能ですが、プリミティブではありません)。 例えば、これは1枚のポリゴンで球、1本のライン、さらには“プリミティブ球”を表現することができます。
プリミティブパスを表現または 指定 したPrim Specifier(指定子)。 このロケーションは、3つのタイプの指定子(def、over、class)のどれかで指定します。
Primの合成に使用されるオピニオンに寄与するすべてのPrimSpec(プリムスペック)のリスト。
Primvarは、PixarのRenderman用語に由来し、“Primitive variable”の略です。 Houdiniで言うと、 Primvarはジオメトリアトリビュートと等価です 。 ジオメトリアトリビュートと同様に、Primvarsはポイント単位、プリミティブ単位、頂点単位などで値を持つことができます。 もちろん、HoudiniとUSDでは、補間の方法によって、その呼び方が異なります。 単一値の定数補間のPrimvarは、親Primsから継承可能です。
Houdini |
USD |
|---|---|
Pointアトリビュート |
頂点補間をするUSD Primvar |
Vertexアトリビュート |
Face-Varying(フェース可変)補間をするUSD Primvar |
Primitiveアトリビュート |
Uniform(ユニフォーム)補間をするUSD Primvar |
Detailアトリビュート |
Constant(一定)補間をするUSD Primvar |
Primvarの識別には2つの重要な特徴があります:
-
Primvarは、それが定義されたプリミティブ上で、上記の補間の方法に基づいて値を定義します(これはHoudiniのアトリビュートと同様です)。
-
PrimvarはPrim上にまとめて取り込んで、そのPrimvarには、そのPrimにバインドされているシェーダ(s)に対する“プリミティブ単位のオーバーライド”を記述します(これもHoudiniと同様です)。
Note
HOUDINI NOTE: 繰り返しになりますが、PrimvarはSOPジオメトリアトリビュートと等価です。
プロパティとは、USDのもう1種類のネームスペースオブジェクトです(Primが最初のネームスペースオブジェクトです)。 Primは合成されたシーンの構成とインデックス化を提供するのに対して、Propertyには“実際のデータ”が含まれています。
Primのプロパティには、アトリビュートとリレーションシップの2つのタイプがあります。
ポイントインスタンサーも参照してください。
ProxyはPurposeの選択肢の一つで、通常ではHoudini GLやStormなどのビューポート用の軽量表現に使用されます。
Purposeは、特定の用途でPrimを分類します。 Purposeは、どのPrimが表示/レンダリングの対象なのかをレンダーデリゲートに伝えるためにHydraで使用されます。 Hydraに送信されるPrimとは異なるPurposeを持つPrimは、レンダラーと同期しません。
Default |
特別な目的はなく、常に表示/利用可能です。 |
Render |
最終品質表示の用途。 |
Proxy |
軽量表現。通常では render Primに関連付けられています。さらにレンダリングも可能です。 |
Guide |
視覚的な参照のみです。つまり、シーン内での対話的な操作に使用するものではなく、むしろデバッグ用途です。 |
Referenceは、よく使用するコンポジションアークの1つで、通常ではこれを使ってアセットとプロップをステージ内に合成します(例えば、セットにアセットを組むとき)。 Sublayerとは違って、Referenceはシーングラフ内の特定のPrimパス(ネームスペース)内に合成されます。
Referenceの主な用途は、小さな単位のシーン記述を大きな集合体に合成し、Referenceのターゲットであるシーン記述を合成して“カプセル化”した結果を含んだネームスペースを構築することです。 Referenceはカプセル化され、そのReference内に含まれていないリレーションシップターゲットは保持されません。
Referenceは、見た目はインスタンスかもしれませんが、実際はインスタンス化されていません。 Primをinstanceable(インスタンス化可能)として宣言すれば、USDは各インスタンス間でそれらのPrimsを最適化して共有するようにします。 しかし、インスタンスReferenceは、インスタンスルート下のPrimsに対して固有のオーバーライドを持つことができません。
Referenceは、シーン記述をコンパクトに再利用するための1種の“マクロ”と考えてください。 Referenceは、例えば本棚に本をしまう際に使用します。 本棚と本は、それぞれ本棚アセットと本アセットを参照します。
Referenceは、同じレイヤーファイルを1つのシーングラフ内の別々の位置に何回も読み込むことができる唯一の方法です。 対してSublayerだと、ファイルをシーングラフに何回もサブレイヤー化しても、その結果は、そのファイルを一度サブレイヤーに追加するのと変わりません(そもそも実際には、同じファイルを何回もサブレイヤー化するのは許可されていませんが)。 しかし、ファイルは、多くの異なるシーングラフ位置に何回も参照することはできます。
Reference LOPとStage Manager LOPは、Referenceを作成します。 Graft Stages LOPとGraft Branches LOPは、Rerefenceに似た処理をしますが、Referenceを作成するのではなくて、参照したシーングラフデータを実際にメインシーングラフにコピーします。 つまり、Graft LOPは“ハード”参照と考えることができます。 Graft LOPはディスク上のファイルを参照しないという点において、Referenceとは異なります。 LOPsで編集された他のシーングラフをGraft(接ぎ木)することしかできません。
Relationshipとは、シーン内のプリミティブまたはプロパティのことを指します。
ターゲットがまだステージ上に存在しない場合でも、サブレイヤー化されたリレーションシップは保持されます。
リレーションシップターゲットがリファレンス化されたPrimによってカプセル化されている限り、リレーションシップはそのリファレンスによって保持されます。 そうでない場合、リレーションシップターゲットはクリアされます。
プロパティも参照してください。
レンダーデリゲートは、Karmaなどのパストレーサー、さらには、Houdini GLやStromなどのGLビューポートまでの何かしらのタイプのレンダラーを指します。 このようなデリゲートは、Hydraを介して送られてきたUSDシーンをレンダリングすることができます。
Hydraを参照してください。
Render Productは、画像の出力を表現します。 Render Productは、EXRに書き出す時に、色々なチャンネル/AOVを記述した1つ以上のレンダー変数を参照します。
Render Variable(レンダー変数)も参照してください。
Render Variableは、レンダリング画像のピクセル、不透明度、他のデータチャンネルを表現します。
AOVも参照してください。
Primsはスキーマで定義されたタイプに分類されます。 スキームの例を挙げると、メッシュ、ライト、カメラ、シェーダなどがあります。 各スキーマは、各Primタイプが対応するプロパティのすべてを定義します。 独自のスキーマを作成することができますが、おそらくUSDに同梱されているスキーマで十分です。
APIスキーマも参照してください。
(LOPs以外の)ほとんどのUSD編集アプリケーションは、セッションレイヤー上で動作します。 これは、ステージを支えるファイルに含まれているデータを設定、オーバーライド、実験するための一種の“スクラッチ空間”です。
それとは対照的に、LOPsは常にステージ上の一番強いレイヤー上で動作します。 ディスクから(ReferenceまたはSublayerで)レイヤーを読み込むと、それを読み込んだLOPは、ディスクから読み込んだレイヤーよりも強いレイヤーを持ちます。 それより下流の各LOPは、ノードグラフ内で新しいレイヤーを宣言しない限りは、この一番強いレイヤー上で動作します。
Scene Viewerで使用されるセッションレイヤーとセッションステージなるものが存在しますが、そこに最終的に現在残る編集は、Scene Graph Treeを介して設定されたアクティブ/可視性のオピニオンだけです。
Inherits(継承)に似ていますが、ベースプリミティブの特別化を改良することができるように設計されています。 Specializes(特別化)は、最も弱いコンポジションアークです。 これは、何もスキーマ定義を再定義することなく、Prim、アセット、マテリアルのフォールバック値をカスタマイズする手段と考えてください。
Specifier(指定子)はUSDファイル内のプリミティブパス/ロケーションに関連付けられた値です。 たくさんのファイルからUSDオピニオンが収集されることから、各ファイルにはシーンへのその寄与を説明する方法が必要になります。 PrimパスがUSD Primを記述するための固有な識別子であるため、各レイヤー内に定義する各値は、必ずPrimパスに関連付けらていなければなりません。 Primとシーンをゼロから作成するレイヤーもあれば、非常にわずかなオピニオンを単にオーバーレイするだけのレイヤーもあります。
USDのシーンのことをステージと呼びます。
一般的にはUSDシーンは多くの異なるファイルで 構成 されるので、USDはそのステージを合成します。
Houdiniでは、/objにて普段からこれを“シーン”と呼んでいたと思います。
稀なケースですが、ステージ全体を単一の平坦なファイルに保存することがあります。
通常では、少なくとも2,3枚のレイヤー(ディスク上の各.usd/.usda/.usdcファイル)が存在し、これらのレイヤーがまとめて合成されて、ユーザー側に完全なシーングラフのビューを表示します。
合成されたステージは、Primsの階層になっていて、モデル、キャラクタ、プロップなどのすべてを表現します。
これは、ディスクからアセットを参照し、それらのアセットを3D空間でトランスフォームさせて、シーン階層を調整するといった事を一箇所で制御できるように設計された非常に便利なユーティリティLOPです。 このLOPは、独自にQtインターフェースとPythonステートを使ってUX部分を管理していますが、このノード自体がプリミティブを作成、移動、コピー、削除することができます。
Stage Managerは、入力のレイヤーを1枚のレイヤーに平坦化するので、どの入力に対してもそれらのオペレーションを実行することができます。 しかし、この機能を使用すると、レイヤースタック内のすべてのレイヤーが結合されるので、軽く処理できるようなものではありません。
ステージの合成されたシーングラフ内一部またはすべてのPrimにアクセスする工程。
レイヤーは、強い順で複数のサブレイヤーを持つことができます。 レイヤーとサブレイヤーのこのリストのことをLayerStackと呼びます。
LOPsで特定のPrimsに作用する構文を記述する時、それらのPrimsを識別する必要があります。 1つ以上のPrimsをターゲットにする最も直接的な方法は、手動でそれらのパスを入力することです。 パターンマッチングに関する詳細は、プリミティブマッチングパターンを参照してください。
Universal Scene Descriptionとは、3Dアセットとシーンを効率的に構築しコラボレーションするためのオープンソースのシーン記述のことです。 USDは、シーングラフを記述したファイルフォーマットです。 Houdiniでは、これをLOPsで実装しています。 LOPsを介してUSDを使用することで、複数のユーザー/部署が同じシーン上で非破壊的に作業をすることができます。 USDは、スタジオのパイプライン向けフレームワークだけでなく、ステージ(シーン)の構築、表示、検査、編集を高速且つ効率的に行なうことができる実際のインフラを提供します。 USDは、Photoshopのようなアプリケーションのレイヤーに非常に似た合成可能なレイヤーで動作します。
USDにはMaterialXプラグイン(UsdMtlX)が含まれています。 このプラグインによって、MaterialXシェーダをUSDシェーディングPrimとしてエンコードすることができます。 現在のところ、MaterialXの多くの機能が余剰なので(例えば、マテリアルの割り当ての機能)、UsdMtlXはMaterialXのすべての機能に対応していません。
USD用語ではありませんが、これはUSDファイルを検査するのに非常に便利なツールです。 これは、オープンソースUSDライブラリのスタンドアローンツールです。
このツールを使用することで、Hydraビューポートでステージを視覚的に検査したり、アニメーションを再生したり、プロパティとメタデータを検査したり、さらには、バリアントやプロトタイプを切り替えたり、シーンをデバッグすることができます。
Value Resolutionとは、プロパティ/メタデータの最終値をすべての様々なオピニオンから“構成”させるアルゴリズムのことです。 つまり、Value Resolutionは、潜在的に多くのデータを合成して単一値を生成します。
これは説明が複雑になるので、詳細はUSDのValue Resolutionのドキュメントを参照してください。
VariantSetは、個々のバリアントを含んだ仕組みのことです。 現行ステージ上で操作ができるようになっており、ユーザ(またはプロセス)は一度に1つのバリアントを選択することができます。 例えば、“tree” VariantSetがあって、そのセットの中に10本の異なる木(バリアント)が設定されているとします。 ユーザは、使用したい木をそのバリアントセットの中から選択することができます。
Houdiniでは、これは、サブネットの中で異なる木を読み込む色々なノードをSwitch SOPに接続して、そのスイッチコントロールをプロモートさせたデジタルアセットと考えることができます。
VariantSetには、そこに格納可能な要素について何も制限はありません。 VariantSetは、単にマテリアルを入れ替えたり、階層全体を変更することができます(バリアントレイヤーを参照)。 VariantSetは、アセット上で定義する必要はなく、下流のノードで取り込むことができます。 バリアントにはリファレンスやペイロードだけでなく、他のVariantSetまでも含めることができます。 サブレイヤーは、バリアント内に直接定義して含めることはできません。 バリアント内で作成されるリレーションシップは、VariantSet Prim外のPrimをターゲットにすることができます。 ただし、リファレンスと同様に、バリアントをカプセル化する必要がある場合がほとんどです。
バリアントは、そのVariantSetを所有するPrimまでのネームスペースを変更せずに動作します(そのため、ライトリンク、または、シーン内の本のインスタンス毎のトランスフォームが維持されます)。
Viewport Load Masks(ビューポートロードマスク)
ビューポートステージは、データの読み込みを制御できるように色々なUSDメソッドを設定することができます。 これは、ビューポート内に実際に読み込んで表示したい非常に大きなシーンの一部を選択することができます。 これらの色々な機能のことをまとめてLOPsでは“Load Masks”と呼びます。 Load Masksは、読み込みたいペイロードを選択したり、ステージに追加したいレイヤーのマスクを設定したり、レイヤーをミュートする機能を含みます。 これらの各機能の説明は、USDのドキュメントを参照してください。
Viewport Overrides(ビューポートオーバーライド)
ビューポートステージは、アクティブ、可視性、描画モードなどのUSDプリミティブの特徴に対するオピニオンを設定できるようにするために、セッションレイヤーに修正を加えることができます。 セッションレイヤー内のオピニオンは、ルートレイヤーまたはサブレイヤーのオピニオンよりも強いです。 これらのオーバーライドは、主にScene Graph Treeペインで制御しますが、Pythonスクリプトでも変更することができます。
各LOPビューアは、各自のステージを持っています。これが実際にビューポートに表示されるステージです。 このステージは、ディスプレイフラグが設定されたノードのLOPステージのコピーとして生成されます。 各ビューアが各自のステージを持っている理由の説明は、パフォーマンスの考察のセクションを参照してください。
可視性とアクティブ化は同様の概念です。 (アクティブ化と同様に)可視性は子Primsに影響します。 つまり、不可視のPrimの子Primsを可視にすることはできません(非アクティブのPrimorの子Primsをアクティブにすることはできません)。
LOPsでは、“Configure Primitives LOP”または“Prune LOP”を使用して可視性を設定します。
HoudiniのネイティブなSIMDで、シェーディング処理やジオメトリ処理に使用される“核となる”言語です。 SolarisにはVEXバインドまたはUSDデータを作成/修正するための関数が含まれています。
VEXも参照してください。
USDでのボリュームは、いくつかのフィールドで構成されたPrimitive(プリミティブ)であり、それ一式でまとめてレンダリングされます。
このフィールドとは、densityやtemperatureといった個々のボリュームのことを意味します。
フィールドは、OpenVDB、Field3D、Houdiniボリュームを参照することができます。
ボリュームデータはUSD内に直接 格納されず 、ディスク上のファイルで保持します。
Camp Fireのサンプルが参考になります。
Volume Primの/campsite/fireには2個のフィールドが宣言されています。
1つ目のフィールドは名前がdensityで、/campsite/fire/densityで宣言されています。
2つ目のフィールドは名前がtemperatureで、/campsite/fire/tempで宣言されています。
これらのフィールドのそれぞれが、SOPsの単一ボリュームまたはVDBプリミティブに相当します。
