膨大な計算を必要とするシミュレーションやレンダリングにおいて、どのように作業を自動化・並列化し、制作の手を止めずに結果を得るか？ 多くのCGスタジオが解決策を日々模索しているだろう。本講演では、そのためのキーテクノロジーであるHoudini EngineとPDG（Procedural Dependency Graph）の基礎と実践が、爆発エフェクト、および海面表現を題材にしたネットワーク構成や、実制作の現場を見据えた工夫と共に紹介された。

講演冒頭で、 Luca氏はHoudini EngineとPDGの関係性を解説した。Houdini Engineは、HoudiniのノードネットワークをGUIなしで実行するしくみで、例えばほかのマシンやサーバ上で処理を行いたいときにも活用できる。

このHoudini Engineと密接に結びついているのがPDGだ。PDGでは、処理の単位をWorkItemとして定義し、それらをノードで接続しながら依存関係を明示できる。講演では、資料内の「緑のドット」がそれぞれWorkItemを表しており、これを複数マシンで同時に処理することで並列化が可能になるという説明があった。

「もし自分のマシン1台でこの作業を全て行えば、RAMやCPUが不足する可能性がある。しかし、Houdini Engineを使って処理を分散すれば、アーティストはその間に別の作業に集中できる」とLuca氏。これは、単なる高速化ではなく、制作フロー全体の効率化につながる発想だ。

PDGのWorkItemを処理する場所は、Schedulerノードで制御される。代表的なSchedulerは以下の通り：

・Local Scheduler：現在作業しているマシン上で実行する際に使用
・HQueue Scheduler：SideFXが開発・提供する無償のジョブ管理ツール
・Deadline Scheduler：ThinkboxのDeadline用のジョブ管理ツール。大規模スタジオでの運用実績が多い
・Tractor Scheduler：PixarのRenderMan用のジョブ管理ツール

講演では、約200行のPythonスクリプトを記述すれば、独自のスケジューラも作成可能である点が紹介された。各プロジェクトやスタジオの環境に合わせて、柔軟に設計できるのがPDGの強みといえる。

より具体的な活用例として、Houdiniのシェルフツールで制作した爆発エフェクトのPDGネットワークが解説された。

構成は以下の通り：

1. ファイルキャッシュ用ノード：pyroのボリュームを、ジオメトリデータとしてキャッシュ
2. USD出力：Solaris（USDベースのライティング・レンダリング環境）で使うために変換
3. レンダリング：Karma XPUによる最終画像の生成

注目すべきは、USD出力とレンダリングが別ノードとして明確に分離されている点だ。これは、USD出力にはHoudini Engineのライセンスが必要である一方、レンダリングには不要であることに起因しており、ライセンス使用の最適化につながっている。

また、Hydraに対応したレンダラであれば、Karma以外でも同様の処理が可能である点も触れられた。

次に紹介されたのが、海面表現を扱うGuided Ocean Layerを用いたPDGネットワーク構成だ。ここでは、Flipシミュレーションによる複雑な水面挙動をメッシュ化したものと、広域的な波のスペクトラ情報（spectra）を組み合わせる処理が、段階的にノードで分けられている。

PDG上では以下のようなながれで処理されていた：

・wavetank：Substepsも含めた、Flipシミュレーション前のキャッシュ処理
・Partition by Frame：Substeps単位のデータをフレーム単位に統合
・flip_sim：フレーム間に依存関係があるため、逐次的にシミュレーションを実行
・メッシュ化：フレームごとに独立しており、並列処理が可能
・mask処理：Flipの結果と、広域の波を組み合わせるためのマスクを生成
・Filter by Range → spectra：データをフィルタリングし、波のスペクトラ情報を生成

Partition by Frameノードでは、FlipシミュレーションのSubsteps（サブフレーム）を、最終的なフレーム単位のWorkItemに変換している。こうすることで、複数のサブフレームを効率よく統合できるようになっている。

また、spectraは複数の正弦波を合成したような海面ベース波形を生成するため、計算対象はひとつで良い。ここではFilter by Rangeでひとつだけを選別する設計が用いられていた。

海面表現に加えて、泡やしぶきなどを生成するwhite waterもPDG上で制御されている。ネットワークは以下の3ステップで構成されていた：

1. ww_source：Flipシミュレーションの結果からsourceをキャッシュ
2. ww_sim：white waterのパーティクルシミュレーション（逐次処理）
3. ww_volumes：パーティクルを、レンダリング用のボリューム形式に変換

ここでも、ww_sourceとww_volumesはフレームごとに独立した処理であり、並列化が可能。一方で、ww_simは時間的な依存を伴うため、PDGが自動的にフレーム順に処理を進める。

また、Flipとwhitewaterの間には明確な依存関係があるため、PDGは後段が先行しないよう自動的に処理の順番を調整する。この「自動待機」機能により、処理の破綻を防ぐことができる。

講演では、PDGがもたらすもうひとつのメリットとして「中間結果の確認」が挙げられた。例えば、300フレームの処理中に100フレームまで完了した段階でも、その結果をチェックすることが可能。問題が見つかれば、対象のWorkItemのみ再実行（dirty）したり、キャンセルを行なったりできる。

このように、ノード単位ではなく、WorkItem単位で制御できる点が、PDGの大きな強みであると紹介された。

最後に、PDGの処理対象がHoudini内に留まらず、外部ツールにも拡張可能である点が紹介された。USDや画像、テキスト、JSONなどのファイルを処理対象に設定できるほか、Pythonスクリプトを用いてMayaやNukeの処理をキックすることもできる。

これは、PDGがHoudini専用ではなく、汎用的なジョブフロー構築ツールとして設計されていることを意味する。ショット管理やアセットの自動変換、さらには外部データベースとの接続など、様々な場面に応用が期待される。

Luca氏の講演は、Houdiniにおけるシミュレーションやファイル出力の効率化を軸に、Houdini EngineとPDGの活用によって何が可能になるかを、具体例と共に丁寧に解説する内容だった。

WorkItemによる処理分解、依存関係の管理、USDやKarmaとの連携、さらには他DCCツールとの接続まで、制作現場で即戦力となる知識が詰まった講演だった。今後、シーン構築から出力までのながれを俯瞰的に設計し、よりスマートに回していくために、PDGは重要な選択肢となっていくだろう。