PDG-Procedural Dependency Graph -ポータルページ

現地時間2019年3月13日にHoudini17.5がリリースされました。
Houdini17.5にて新しく追加されたPDGという機能について、当ブログではポータルのページを作成しました。
PDG及びTOPネットワークについて、簡単な紹介や解説を行っている記事はこちらのページでアーカイブされております。

 

PDG入門動画の紹介

この記事では以前の記事でも簡単に触れた、SideFX社にて公開されているPDGの入門動画について簡単に紹介します。
SideFX社ページPDGイントロダクション(英語)

 このチュートリアルではPDGの紹介を行います。 Procedural Dependency GraphはHoudiniとPilotPDGアプリの両方で機能する新しいアプローチであり、PDGの初歩的な知識を身に着けるためのレッスンです。
また、こちらの動画につきましては、3/15現在、英語(字幕なし)となっております。概要はこちらのブログでも紹介しますが、あくまで概要であり、内容の詳細な対訳ではありません

詳細につきましては、動画をご覧いただきますようよろしくお願いいたします。

 

動画: CONCEPTUAL INTRODUCTION TO PDG (PDGの概念的な紹介)

PDGについて、内容をまだ理解をされていない方は、このビデオから見始めるのをお勧めします。 実際のPDGの画面は用いずに、PDGとは何か、PDGの用途、およびプロセス、ワークアイテム、スケジューラなどのすべてのコンポーネントの概念について簡単に説明しています。


 こちらの動画ではまず、Houdini内において、TOPノードとして使われるPDGと、
Houdiniの外において、PilotPDGとして使われるPDG、2つのPDGのとらえ方についての紹介を行っております。
 Houdini内部的にはWedgeノードを使ったパラメータの値による出力画像の変化の視覚化であったり地形や都市の形成、並列したシーケンシャルワークフローの確立などが挙げられ、外部的にはパイプラインの形成、キャラクターの組み立て、機械学習、パイプラインの自動スケーリングなどが挙げられています。

 PDGとは何なのか、を考える前に、まずはCGに限らず、ものづくりを行うときに大切な、ワークフローについて考えてみます。

 ここでは、昔の結婚式の招待状を作るワークフローについて考えます。あまり日本的ではありませんが、海外では上の画像のような結婚式の招待状が使われておりました。今回はこちらの作成を行う作業手順(ワークフロー)を以下のような形で書き起こしました。

 ここでは「何をするか」を「関数」と定義し、関数によって「得られたもの」と「結果」とします。このワークフローにおいては上記のような「関数」「結果」が書き出されています。通常のワークフローであれば、「結果」に焦点を置かなくても、「関数」だけあれば上図左のような作業の流れを作ることができます。

 ただし、招待状を1枚作ればよいのであれば、この流れの通りに作成すれば良いのですが、例えば招待状を500枚作る必要があった場合、このワークフローを500回繰り返さなければなりません。

この500回の繰り返しをもっと効率化できないか。これがPDGの発端になるわけです。

 

 ここでHoudiniの話に戻ります。Houdiniにおける「関数」「結果」はなんでしょうか。
 Houdiniにおける「関数」とはノードそのものであり、「結果」はOutputのドットです。
Houdiniは基本的には1つの関数に対しては常に1つの結果が返ってくるような仕組みになっております。
こちらではGridを作る「関数」でひとつのGridを作成し、それをTweak(引っ張る)「関数」でTweakしています。

一方、PDGはどうでしょうか。

 このPDGのノードではご覧の通り、1つのノードに対して10個の「結果」が出力されています。PDGにおけるノードは1つの「結果」を返す関数ではなく、複数の「結果」を生み出すことのできる「プロセス」と定義することができます。

 ここではまず上のノードが10個のGridを作るという「プロセス」を行い、10個のGirdという「結果」を出力し、それら全てに対して下のノードがそれをTweakという「プロセス」を実行しています。

 当然ですが、Tweakの「プロセス」はGridが存在しなければ、実行することができません。
しかしGridを作る「プロセス」は何もないところから作ることができます。どうやら、「プロセス」には

  1. 何もないところから実行できるもの
  2. 前の「プロセス」「結果」がなければ実行できないもの

の2種類があるようです。
この辺りはHoudiniのノードも同様かと思います。

 

ではここで、先ほどの招待状について、「関数」「プロセス」として考えてみた時に、
何が1.の「プロセス」で、何が2.の「プロセス」に該当し、また2.の「プロセス」の場合は、実行にどんな「結果」が必要なのでしょうか。

それを表したものが以下の図になります。

 例えば”Glue end caps onto doilies”(蓋とドイリーを接着する)の「プロセス」には”Aquire End Caps”(蓋を買う)という「プロセス」で得た「結果」である”EndCaps”が必要になりますし、”Place in Shipping Tube”(梱包する)の「プロセス」は、当然それまでの全てのワ-クが完了した結果がなければ行うことはできません。
Glue end caps onto doiliesはAquire End Capsがないと実行できない状況です。これをGlue end caps onto doiliesはAquire End Capsに依存している、と呼びます。つまり上記の図は、招待状作成における、各「プロセス」依存関係を表したグラフ、”Dependency Graph”となります。

PDGとはこの”Dependency Graph”をプロシージャルに応用したものであり、”Procedural Dependency Graph“の略となります。

 

次に、この招待状作成のワークを何十人もの大人数で実行することを考えます。

 PDGでは同時に1プロセスで作業させられる最大人数のことをワークアイテムと呼びます。この例では1プロセス内では同時に最大5人で作業ができると仮定しているため、5つのワークアイテムが作成されることになります。実際のPDGではワークアイテムとはGridなどのインスタンスを指すので、ワークアイテムの数は作成されたインスタンスの総数となります。


 上の図で黄丸が現在実行されている/実行が終わったTask、茶丸が実行待ちのタスクとなります。この図からわかるように、上流の「プロセス」のワークアイテムは、その全てが完了していなくても、下流の「プロセス」のワークアイテムが実行されています。これは、各ワークアイテム同士の依存関係がPDGによって計算されることで、どのワークアイテムを先に実行する必要があるのかを知ることができるからであり、これがPDGの大きな特徴です。

 この単一のワークアイテムの依存関係の流れをタスクと呼び、その流れを示したもの(上記画像では黒矢印)をタスクグラフと呼びます。
また、この図はあくまで概念的なものであり、実際のPDGの依存関係とは表記が異なることにご留意ください。

 では、ここで実際のPDGの画面を見てみましょう。PDGにおいてはこれまでのことは、このような形で表示されます。
 ノード内の複数の点はワークアイテムを示し、実行(クック)中のものは緑色に光ります。実行済みになると、濃い緑色に変化します。また、ワークアイテムををクリックすると、そのワークアイテムのタスクグラフが表示されます。

 PDGにおいては、レンダリングプロセスを利用するとフレームの数だけワークアイテムが生成されるので、膨大なワークアイテムが作成されることが多々あります。
 上記の図は、10フレームのレンダリングのネットワークですが、Seedを3パターン、orbitを4パターン作成し、それらすべての組み合わせ、12パターンのレンダリングシーンを用意し、Mantraで10フレームのレンダリングを行っています。
この時点で3:4*10=120個のワークアイテムが作成されます。

 レンダリング後はSeedの値によってパーティションを行っています。これはSeedの値だけが異なる(つまりorbitとフレーム数が同じ)ワークアイテムを1つのワークアイテムとして結合するものです。これによって各SeedのパターンのSeedが1つのワークアイテムとなるので、ワークアイテムの総数が120/3=40となります。
そしてImageMagickノードでその3枚の画像を並べて1枚の画像にしています。

 同様に今度はorbitの値が同一のワークアイテムをひとつのワークアイテムとしてパーティションしています。これでワークアイテム数は40/4=10となり、またImageMagickノードでその4枚の画像を並べて1枚の画像にしています。

 この時点で作られている画像は3*4=12パターンのレンダリング結果が並べられた1枚の画像*10フレームとなります。最後にこれを結合して動画として書き出す、というネットワークです。最後に出力されるのは1つの動画になる為、最後のワークアイテムはひとつになっていることがおわかりになるかと思います。

 

 ここで重要なのは、各ワークアイテム間において、依存関係がないワークアイテム同士は並列に処理を行うことができる、という点です。招待状の例をとれば、例え何十人も作業者がいたとしても、材料の準備が終わっていない段階でその材料を加工するプロセスに人を割いても、それは何の意味もありません。どこのプロセスを最初にやるべきで、それに依存するプロセスがどれかがわかっていれば、最大限リソースを活用することができるわけです。

 これをCGに置き換えればDeadlineなどのスケジューラへのタスク分散への効率性に直結します。
 依存性が正しく計算されることで、他への依存がゼロのものから順番にタスクを自動的にスケジューラに流すことができます。PDGによって依存関係が明確になれば、レンダリングなどの分散がより効率的になり、圧倒的な制作進行の改善が見込めるはずです。

 

 PDGの概要はこのようなものとなります。既存のROPを用いてこれだけのことをするのは非常に労力のいる作業となりますが、TOPネットワークのPDGであればこれだけ簡単に複雑なレンダリングネットワークを作成することができることになります。

 以上がこの動画の簡単な説明となります。
 前述したように動画の翻訳ではなく概要説明となり、実際の動画とは説明の内容が前後していること、完訳されているわけではないことについてはご了承ください。

Deadline Scheduler for PDG

この記事では、Deadlineスケジューラの統合、設定、使用方法、および機能の拡張について紹介します。
※3月18日現在、Deadlineの最新バージョンはHoudini17.5をサポートしておりません。
PilotPDGからではなく、Houdini17.5からTOPノードを用いてジョブを送信する際はDeadlineの最新の対応状況をご確認ください。
続きを読む

コマンドサーバ

この記事では、PDGのコマンドサーバについて紹介します。コマンドブロックを使用すると、リモートプロセス(HoudiniMayaインスタンスなど)を起動し、サーバコマンドを送信したり、サーバをシャットダウンすることができます。
続きを読む

よく利用されるTOPノードの紹介

この記事では、よく利用されるTOPノードについて簡単な紹介を行います。

 ここには、全てのTOPノードは掲載されておりません。
ここで紹介する、よく使われるTOPノードを把握することで、TOPの一般的なワークフローを理解、発想しやすくなります。
全てのノードの一覧はSideFX社のTOPノードページをご参照ください。

続きを読む