2025年8月22日（金）に新御茶ノ水のワテラスコモンホールで「Houdiniで始めるUSD-Solarisワークフロー実践セミナー-」が開催された。

デジタル・フロンティアの柄木田 丞氏が登壇し、Houdiniユーザーを対象に、「Solaris × USD」導入の第一歩をわかりやすく解説。大規模プロジェクトでの豊富な経験から、初心者にもわかりやすい実践的な知見や用語を用いて、USDの基礎や効率的なワークフローを解説した。本稿では、2時間を超える豊富な講演内容を、前後篇にわたって紹介する。

※本セミナーはHoudini 20時点の情報の講演です。Houdini 21ではアイコンや機能が変わった部分がありますのでご注意ください。

関連記事：前篇はこちら

Information

USDの用語解説

セッションの後半では、USD用語についての解説から開始して、最後にサンプルデータを使ったデモが行われた。

LIVRPS（Opinion Strength）

USDには概念として、優先順位が存在している。個人で使う場合には関係ないが、パイプラインをつくる場合は理解が必要となる。デザイナーは気にすることではないので、存在することだけ覚えておけば良い。

なお、最新のOpenUSDの定義ではLIVeRPSに変更されていて、rElocates(リロケート）という非破壊的に階層変更が可能な機能が追加されている。

Stage / Layer

「Stage」はHoudini上ではフラグを立てている部分までの計算結果全てのこと。一方、「Layer」は読み込んでいるUSDファイルや、LOPが生成するIn-Memoryレイヤー、SOPレイヤーなどの構成要素のこと。

Sublayer / Reference（Payload）

「Sublayer」は中に入っているデータをまとめることができる。「Reference」と「Payload」は一番上のプリミティブだけ読み込むが、Default Primitiveという宣言をすることで、ほかのプリミティブをデータとして読み込むことができる。

Prim

階層のひとつひとつが「Prim」で、ジオメトリや階層、マテリアルなどの「Prim」がある。Typed SchemaとAPI Schemaで成り立っている。

例えば、SphereのTyped SchemaとAPI Schemaをライトに差し替えるとライトになる。また、ほかのソフトからSolarisにデータをもってきたときに変換が上手くいかず、意図しないタイプになった際に書き換えることもできる。Typed SchemaとAPI Schemaに関してはVEXやPythonを書くときに覚えておくと良い。

Specifiersについて

Houdini上でノードを作成すると、基本的にdefとして扱われるが、間にLayer Break LOPなどのノードを挟むと、over（上書き）として指定されるようになる。このちがいは普段の作業で大きく意識する必要はないものの、動作の背景として知っておくと役立つだろう。

Kind

「Kind」はファイルの種類と構造のこと。コンポーネントとしてアセットをつくり、結合してグループにしてからアッセンブルにする。デザイナーは覚えておいた方が良い。

「Kind」が適切につくられていると、Solarisでの選択が楽になる。後々、どう使うかによって「Kind」の区分けを上手くしておくと、ライティングチームが使いやすくなる。デザイナーは「Kind」を覚えて使いこなすべきで、チームでやり取りしやすいデータをつくるようにする。

Purpose

「Purpose」はプリミティブの設定でレンダリングと表示を分けるときなどに使う。巨大なデータでも表示を軽くすることが可能だ。Default（どんなときも表示される）、 Proxy（Viewport表示用のダミージオメトリに設定する）、Render（実際にレンダーされるときだけ使用したい場合に設定する）、Guide（Viewport上でしか表示されない）の4種類。

Variant Set

「Variant Set」はモデルやシェーディングのバリエーションを含めて、切り替えることができるしくみ。Scene Graph TreeでVariantsを変更してもSet Variantというノードが自動的に作成されるため、レンダーやエクスポートにも適応される。

Active / Visibility

USDはPrimの削除ができないが、「Active」をOFF（Deactivate）にすることで階層としては存在してもメモリに読み込まれないという軽い状態にできる。「Visibility」は表示されないがメモリとして存在するところが異なる。

Properties / Attributes / Relationships

Scene Graph Detailsは、選択したPrimの情報を表示するパネルで、Mayaで言うところのAttribute Editorに相当する。中には「Properties」項目があり、その下層に「Attributes」と「Relationships」が含まれる。

「Relationships」には、ほかのPrimとの接続に関する情報がまとめられている。例えば、マテリアルのアサイン情報などがここで確認できる。

一方で「Attributes」では、特にprimvar（Primitive Variable）が重要だ。これは、アセットチームが設定した情報をほかの工程、とりわけライティングチームが再利用するために活用される。primvarについては、後ほど詳しく解説する。

なお、「Properties」は基本的に削除できない。ただしBlock操作によって無効化し、結果的に「存在しなかったこと」にすることは可能だ。ただしこのBlockの挙動は少々クセがあり、トラブルを避けるためにも積極的な使用は避けた方が無難だ。

Time Sampling

「Time Sampling」は理解が難しい概念で、モーションブラーがかからない原因となる。ノードに時計のアイコン（time dependency）が表示される。

USDは時間軸のデータを一度に読んでいる状態が望ましいとされていて、フレームだけの情報であるtime dependencyになるとモーションブラーがかからなくなる。

解決するためにはCacheノードを使って、時間軸を保持したいフレーム数を与えるとtime dependencyアイコンが消えてモーションブラーがかかるようになる。ノード自体にもCacheノードと同じ機能のアトリビュートはあるが、確認しやすいCacheノードをつけるのを推奨。

レイヤーがひとつだと「Time Sample」を全て結合させないといけないため重くなっていく。「Time Sample」が原因の質問は多いことからも、解決しておくのは大事な点。

Instance

「Instance」にはMayaのInstanceのような「Native Instance (Instanceable Prim)」とHoudiniのCopy to Pointsと同様の「Point Instance」がある。「Instance」の元ファイルはPrototypeというPrimで、Native Instanceの場合はroot直下にできる。

Primvar

球体にテクスチャを割り当てた上で、Native Instanceを使って2つ読み込む。このとき、マテリアル側で「Primvar」を参照するように設定しておけば、同一マテリアルを使いつつ、インスタンスごとに異なる見た目を表現することが可能だ。

例えば、マテリアルは一緒でもテクスチャを変えるといった処理が行えるため、少ない処理でバリエーション豊かなビジュアルを実現できる。

Xform（Transform）

USDで「Xform（Transform）」を複数もつことができ、それぞれに名前を付けることができる。これらの順番はxformOpOrderで管理される。「Transform」ノードよりも「Xform」ノードの方が、より多くの「Transform」設定に対応している。

また、Mayaで複数の「Transform」をかけたい場合、グループを重ねて階層構造をつくる必要があるが、USDでは階層構造をつくらずに「Transform」を積み重ねて適用できる。加えてxformOpOrderの順番をVEXで制御したり、不要な場合は無効化もできる。さらにBakeでひとつにまとめることや、Resetでなかったことにもできる。ただし、Resetは上の階層の「Transform」まで影響を及ぼすため、注意が必要だ。

また、「Xform」に部署名などのsuffixをつけることで、どの部署が加えたかが明示でき、ライティング工程で管理に役立つ。

Render周りの用語

「Render Settings」（/Render階層下に置くレンダーに必要な設定全てをまとめたもの）、「Render Products」（レンダー画像の出力先や解像度など、出力情報をまとめたもの）、「RenderVars」（レンダーされる出力情報（AOV）ひとつ）が階層構造でまとめられている。

Collections / Selection Rules

Mayaのselection setのようなもの。「Collections」と「Selection Rules」のちがいはhip依存か、書き出されるかのちがい。「Collections」は書き出されるときに保存されるので再利用が可能。

「Collections」はレンダリングするときの区分けにしておくと使いやすい。アセット作成時に先に設定しておくと後工程でアセットとショットのやり取りが円滑になる。

「Collections」をつくるときにPrimitive Matching Patternsという機能を使えるが、種類が多いのでSideFXのヘルプで確認してほしい。アスタリスクや番号を使って固有の名前を入れずにHoudini的な選択が可能、Kindの自動選択もできる。

Variable Expressions

「Variable Expressions」はファイルパスに変数が宣言できる機能。変数を後から宣言できる。20.5から使えるようになった。

バージョン管理はAsset Resolverのほうがいいが、Asset Resolverはつくるのが大変なので、小規模プロダクションは「Variable Expressions」でバージョン管理することも可能。なお、Houdini 21では簡単なAsset Resolverが内包されたのでそれを使っても良いだろう。

LayerInfo

「LayerInfo」はデフォルトでは非表示だが、meta情報などを「LayerInfo」に書き込んでおくと、下流工程に引き継がれるので、呼び出して便利に使うことができる。

Insertion Point

「Insertion Point」はViewportやScene Graph Tree上の処理で作成されたノードを所定の箇所に作るための目印ノード。複雑なシーンで所定のラインにつなぎたい場合に重宝するデフォルトの機能だ。

例えば、ライティングしているときに、足したい場所にライトを指定した「Insertion Point」ノードを置いておくと、自動的にその場所にライトが設置される。

複雑なネットワークになったとき、「Insertion Point」をつくることによって、特定の場所にノードをつくることができる。

Output Processing

USD ROPを使うと、USDファイルへの書き出し前の処理をPythonで実装できる。これにより、クリーンなデータをアウトプットするための「Output Processor」（自動化処理）を用意しておくことが可能だ。例えば、以下のような処理を事前に組み込んでおくケースがある。

Save Source Scene File：書き出し時にHIPをバックアップとして、パブリッシュエリアの所定ディレクトリに保存する
Localize Texture to Output Directory：使用しているすべてのテクスチャをRAT形式に変換し、パブリッシュ先に書き出す。パスも自動で書き換える
Copy All Assets to Output Directory：参照されている全てのUSDファイル（SublayerやReferenceなど）を所定の場所にコピーし、リンクをつなぎ直す

なお、これらの「Output Processor」の記述方法はHoudiniの公式ヘルプにも記載されているが、基本的にはデザイナー向けではなくTD（テクニカルディレクター）寄りの内容になっている点には留意が必要だ。

VEX

「VEX」はHoudiniで使うプログラム言語で、ほぼ全てができる。ただし、個々のレイヤーに対する操作ができないのと、Time Samplingの制御が苦手で別途Cacheノードなどで解決しないといけない。「VEX」は重くなりがちなためWrangle LOPを3つ、4つ重ねると処理が重くなってしまうので、複雑な処理であればあるほど「Python」のほうがオススメとのこと。

Propertyの書き換え

Propertyを書き換えるときはusd_setattrib(0, @primpath, "アトリビュート名", 設定する値);のようなかたちにする。ほかにもいくつかあるusd_set~でできる。Time Samplingがついてしまう可能性があるため、単純な値の書き換えではWrangleノードは使わずに、Edit Properties LOPノードなどで書き換えるのが良い。

Solarisはノードを覚えたほうが良いというのはedit系のノードを使うときれいなデータになりやすいためでもある。簡単な値の書き換えであれば、WrangleやPythonよりもEdit ◯◯ LOPの方が良い。

「Python」も同じく、できないことはないが、HoudiniというよりもUSD自体の理解が大事。パイプラインをつくるなら必須だ。

Stage Lock

シーン内のアセットやトランスフォームを誤って変更しないための「Stage Lock」には、以下の3種類ある。

Read Lock：hou.LopNode.stageを使い、パラメータ内のPythonでStageにアクセスする場合に使われる読み取り用のオブジェクト。パラメータから直接PythonでStageを編集することはできない
Write Lock：hou.LopNode.editableStageをPython Script LOPで使う。Active Layerを編集対象にしてStageを編集する。編集できないレイヤーの場合はLOP Layerが追加され、そこに処理結果が記述される
Layer Lock：hou.LopNode.editableLayerをPython Script LOPで使う。Stage上にないSdfLayermにアクセスできるらしい

ワークフロー / パイプライン

「ワークフロー / パイプライン」をつくるときは、USDを直接オーサリング（編集）するというよりは、USDというフォーマットにデータを集約することによって各種DCCで同じデータを扱えるということのほうが大切。特定の工程（レイヤー）だけを別のDCCから書き出したりすることで、DCCに依存しないデータ、ワークフローへの第一歩にすることができる。SolarisはUSDを簡単に扱えるので、編集しがちだが注意したいところ。

また、ワークフロー≠パイプラインである点に注意。ワークフローはフローごとに別個のツールで行い、パイプラインをUSDにしてワークフロー間を同じデータを使ってやり取りする。

全ての工程をUSDに収めるには変換コストがかかる。しかし、各部署でそれぞれコストが増えたとしても、プロダクション全体を見るとコストは下がることが予想される。ただし、レンダラごとに最終結果が異なるため、レンダラはアセットからルックデヴ、ライティング、全て統一したほうが良い。

また、DCCのユニットスケールも重要になってくる。無変換のままスケールを変えてやり取りしているとレンダリングの結果が変わってしまう。どこで変換するかが問題になるが、とくに始めと終わりのルックデヴとライティングを一緒の環境にしないと、トラブルの基になってしまう。しかし、そうすると、MayaからHoudiniに変わっただけになってしまうが、それは別の課題だ。

Assetをつくる段階からショットワークを見越してデータをつくることが大事。実際はAssetをつくる段階ではUSDの恩恵は特になく、手間が増えるだけだが、それによって後工程が劇的に楽になり、プロジェクト全体への恩恵が大きくなる。そのため、ショットワークのためにAssetをつくるという意識が必要だ。

Asset / Shot

「Asset」と「shot」では考え方が異なる。Assetはタスクが固定され、ShotはタスクがShotごとに異なり、必要なAssetも変わってくる。

Asset
アセットを制作の段階ではUSD導入のメリットはほとんど感じられず、手間が増えるように思えるかもしれない。しかし、そのひと手間が、後工程を効率化する鍵になる。具体的にはUSDで管理されることで、ライブラリ化が容易になり、再利用がしやすくなる。

Shot
USDはマルチショットの管理に強いため、事前にどのような構造にするかを考えておくことが重要だ。Shotごとにタスクが異なるため、それぞれのタスクに対して「どんなものを読み込まないといけないのか」を考える必要がある。

Asset Hierarchy

「Asset Hierarchy」については、サンプルデータを用いた解説が行われた。

まずアセットの構築では、最上位でジオメトリをつくり、その後にマテリアルを作成してアサインを行う。このとき、Layer infoを活用して、ジオメトリとマテリアルそれぞれの最後のノードのパスを書き込んでおく。

また、アセット構築用のネットワークとは別に、パブリッシュのネットワークを用意する。こちらではFetchノードを使ってlayer infoの情報を関数で読み取り、必要なジオメトリを強制的にもってきている。最後にPayloadの処理を実行し、Classの設定を行っている。

こうすることで、アセットのネットワークは、ターンテーブルでのレンダリングチェックなど、独立して自由に使うことができる。

サンプルデータを使ったデモ

セミナーの最後はサンプルデータを使いUSDをHoudiniに集めてenviroment、animation、lightngなど担当ごとに並行して作業していくながれが紹介された。

shot.usdに各工程がそれぞれの作業内容だけを含んだレイヤーを書き出す。ショットワークの作業はshot.usdに全作業者がアクセスする（このときMute機能を使って自分以外のところを触れないようにしておく）。

shot.usdではshot loaderで自分の作業担当の設定をそれぞれ選び、必要ないレイヤーはミュートになる。これにより、他人のデータを壊さないで、自分の作業に集中できる。

デモではshot.usdの一連の制作方法の他、class、inherit、material　library、specializeなどの説明が行われた。

Solarisにアセットとしてground、mountain、tree、birdを読み込み、ショットワークとしてenvironment、animation、lightingが含まれたUSDを読み込む。Solarisでは、各工程を異なる担当者が並行して分業できる。

ショットワークの作業では全員同じshot.usdを読み込む。その際、例えばenvironmentの担当者が読み込む場合、ほかのanimation、lightingのレイヤーはMuteを使い、読み込まないようにできる。作業によっては任意のレイヤーを読み込むことも可能だ。

Element

nature_japanという「Element」をつくってGround、Mountain、Treeをまとめている。これによりnature_japan内のインスタンス元のパスを変更すれば、インスタンスで配置されたPrim全体が変更される。また、データ的にもシンプルになる。

また、Class PrimitiveとInheritの併用によって、特定のClassの処理を含むPrimに一括で伝搬させることが可能だ。例えばmountainのClassをつくり、そこで修正すれば、配置された全てのmountainに変更が反映される。

Material Library / Specialize

「Material Library」という階層にベースとなるマテリアルを保存し、その上で「Specialize」により特定のパラメータの調整をする。するとショットやアセット単位で、個別調整できる仕組みになっている。例えば、金属部分に後処理でサビを追加する、といった変更が可能だ。

まとめ

最後に主催のボーンデジタルからは、「USDは1社や1人の力だけでなく、複数の人々や企業が力を合わせて取り組んでいくことが不可欠です。ボーンデジタルは今後も皆様の挑戦を積極的に紹介し、世界に遅れをとらず日本からもUSDに取り組む企業をさらに増やし、日本全体の盛り上がりへとつなげていきたいと考えています」と挨拶があった。

内容が濃く、情報量の多いセミナーだったため、アーカイブを見直しながら実際にサンプルを触って復習してみるのも良いだろう。今後もUSDの展開に期待だ。