秋山：3.0からはR&Dのエンジニアがパイプライン APIを提供してくれるようになったので、パベルのようなTDもパイプラインに密着したツールを開発できる体制になりました。現在は主にエフェクト工程で活用しているHoudiniを今後はほかの工程にも拡張し、パイプラインのユーザーも独自ツールをつくれる体制を構築していきます。

パベル：3.0からはGitHubを導入し、そこでHoudiniのバージョンやパッケージを管理するようになりました。Deadline、マルチショットのシーンビルド、PDG、PPixel（Non-Photorealistic Renderingに特化した自作レンダラ）などのツールごとにパッケージを分けてHSITEに登録し、バージョン管理やデプロイを行なっています。各ツールは別個のバージョンをもっており、並行して開発を進めているのですが、GitHubを使うことで管理が煩雑になるのを防いでいます。Houdiniに関してはプロジェクトごとにPPIランチャーでHSITEのバージョンを設定し、登録されたパッケージを全て読み込むというながれになっています。Mayaの場合は、全ての環境変数を設定ファイルに書き込んであります。

「新バージョンに乗り換えた後は古いバージョンを使わないこと、古い方法と新しい方法がある場合は後者に乗り換えることが、Houdiniを効率良く使うためのポイントです」（パベル氏）。

菊地：エフェクト工程以外では、Houdiniをどのように活用していますか？

パベル：キャラクターのヘアやクロスのシミュレーションではVellumを多用しています。ヘアのグルーミングはMayaで行い、Alembic経由でガイドをHoudiniに出力し、Vellumでシミュレーションした後にガイドをMayaに戻しています。ヘアやクロスのシミュレーションは反復作業が多いので、自動化のためのPDGノードを大量に用意してあり、修正が必要な部分だけアーティストが手を入れるワークフローにしています。パイプライン 3.0からはオブジェクトベースのマルチショットワークフローも導入しており、PDGで各ショットのメタデータを管理しています。ショットの尺、カメラのパス、Alembicファイルのパスといったショット依存の全てのメタデータをPDGで管理し、タスクに関連する全てのアセットをひとつのシーンデータにまとめて作業するので、手続きやデータの管理にかかる時間を大幅に短縮できます。

菊地：例えば複数のショットで似たようなエフェクトをつくる場合に、ひとつのシーンデータの中で作業をしたら、同じ作業が自動的に全てのショットへ反映されるしくみをPDGでつくったということですね？

パベル：そうです。先々では、同じしくみをSolarisで実現したいと思っています。

菊地：僕もアーティスト時代にまったく同じことをHoudiniでやっていました（笑）。一番しっかりやったのはWētā FXにいたときですね。「このネーミングのアセットがあったら、このエフェクトを適用してレンダリングする」というようなバッチ処理を手持ちの100ショットくらいに適用して、大量のジョブを自動生成していたんです。PPIのワークフローほど洗練されてはいなかったですが、すごく近い考え方をしていたと思います。これをやるとファーストテイクが滅茶苦茶早いし、上手くいっていないショットのシーンデータだけを開いて直せば良いから、クオリティアップに注力できます。このやり方は、エフェクトだけじゃなく、ライティングに対しても有効ですよね。

パベル：有効です。Solarisでの組み直しが完了したら、ライティング工程にも適用したいと思っています。

クリエイティブワークの開始・終了時には、必ず手続きが発生する。アーティスト自身が手続きをする場合、「スプレッドシートに書かれたショット情報を確認し、キャラクターなどのアセットを手動で読み込む」といった判断を頻繁に行うため、ミスが発生する可能性があるし、時間もかかる。ファーストテイク後の修正が何回も発生する難度の高いショットでは、手続きの回数も多くなる。一方で、難度の低いショットでは、クリエイティブワークよりも手続きに要する時間の方が長くなってしまう。これらの課題を解消するため、PPIのエフェクトチームでは、手続きの自動化に加え、PDGによるマルチショットワークフローの導入も開始した。

「マルチショットには、1. 作業用のシーンデータはひとつだけなのでOpen・Saveのオペレーションが少ない、2. データの受け渡し回数が減るためクオリティアップにかけられる時間が増える、3. まとめ修正が楽、などのメリットがあります。一方で、1. ヒーローショットには不向き、2. 15〜20ショットを超えるとひとりでは対応しきれない、3. 特別なセットアップが必要、などのデメリットもあるので、両面を理解した上で運用することが望ましいです」（パベル氏）。

菊地：PPIのUSDインテグレーションはどこまで進んでいるんですか？

パベル：3.0からはPDGによるキャッシュのパブリッシュサービスも始めていて、そこで生成されるマニフェストというメタデータはUSDファイルになっています。キャッシュ自体はまだAlembicやFBXです。

菊地：シーン自体は、まだUSDに置き換わっていないわけですね？

パベル：はい。ですからプロダクションでは使っていませんが、Solarisでマニフェストを開くと、ショットの基本設定やカメラ情報は読み込めます。

菊地：Houdiniはエフェクトやプロシージャルモデリングのツールとして使われるケースが多いと思います。でもPPIでは、パブリッシュ時のデータ加工のバッチ処理などでも積極的に使い始めているんですね。

パベル：私たちはHoudiniをただのCGツールだとは思っておらず、ハイレベルプログラミング言語であり、統合開発環境でもあると認識しています。3.0の開発を始めてからは、「こういう使い方もあったのか」という発見をくり返しながら進んでいる感じです。パブリッシュサービスでは、DeadlineジョブがPDGネットワークを読み込んで全ショットの差分を確認し、毎日1回、夜の時間帯に自動的にキャッシュとマニフェストをパブリッシュしています。

菊地：PDGネットワークは、そのままDeadlineにもっていけるんですか？

パベル：もっていけますが、Houdiniのデフォルト機能では、ひとつのDeadlineに投げると、全てのタスクがひとつのジョブとして出力されます。それだと使い勝手が悪いので、ノードごとに別々のジョブとして出力されるようにカスタマイズした上で使っています。

菊地：キャッシュのベイクはMayaで行うのですか？

パベル：Maya用のLGTとUnreal Engine（以下、UE）用のRTAの2種類のパブリッシュを行うので、Houdini EngineからMayaとUEを走らせて、ベイクされたキャッシュをHoudini Engineでまとめています。ただしキャッシュをPPI Malaysiaなどにクラウド経由で共有すると通信料が跳ね上がるので、マニフェストだけ共有し、キャッシュは現地で再生成します。

菊地：キャッシュをつくるための材料だけ共有し、"調理" は現地で行えば、通信料やストレージの圧迫を防げますね。すごくスマートなやり方だと思います。様々なバッチツールがある中で、あえてPDGを使う理由は何ですか？ パベルさんがHoudiniを熟知しているからという理由は当然として、PDGを使うメリットがあれば伺いたいです。

パベル：私はHoudiniをバージョン8の時代から使っていますからね（笑）。これまでに大小様々なプロジェクトに携わり、自分でツールをつくり、 Pythonもたくさん書いてきました。PDGを使う一番大きなメリットは、Houdiniのデータも、それ以外のデータも扱えることだと思います。エフェクトアーティストたちはPDGでショットのメタデータを管理しているので、まったく同じノードで、マルチショットワークフローにも、パブリッシュサービスにも対応できるのは大きなメリットです。加えて、Houdini EngineのライセンスでPilotPDGのUIが立ち上がるので、ライセンス負担を抑えられるというメリットもあります。

アニメ作品では3コマ打ちのアニメーションスタイルを基本としているため、ひとつのショットデータから、シミュレーション・エフェクト用の［Linear］（コマ打ちなし）データと、ライティング・レンダリング用の［Stepped］（コマ打ちあり）データがパブリッシュされる。いずれもキャッシュとマニフェストが生成されるが、現時点のクラウドベースのパイプラインでは通信料が課題になっているため、マニフェストのみ社外スタジオと共有し、キャッシュは各スタジオで改めて生成するワークフローを採用している。「パブリッシュ時のPDGネットワークや、データの依存関係を記録するしくみをつくっておけば、ほぼ同じキャッシュを再生成できます。どうしてもトラブルの起こるショットだけキャッシュを共有すれば、大抵の問題は回避できると思います」（パベル氏）。

毎日1回、夜の時間帯にLGT（Maya用）とRTA（UE用）のパブリッシュサービス（Deadlineジョブ）が自動的に実行される。プロジェクトでのUEの使用はまだ限定的だが、様々な使い方を試しているとのことだ。

菊地：PDGはプロシージャルにバッチ処理を組むためのインターフェイスのような性格が強いから、正しくPDGを使っているのだろうと思います。

パベル：先ほど秋山が言っていたパイプラインのユーザーが独自ツールをつくれる体制も、PDGを使えば可能となります。実際のパイプライン運用では、各プロジェクトのニーズに合わせた調整の要望が頻繁に上がってくるのです。現状だと、要望を受けてからTDが対応するまでにかなり時間がかかっているのですが、PDGで簡単にノードを組めるライブラリなどを整えれば、ユーザーの方でもツールを自作できるようになると思います。そういうプロシージャルパイプラインの実現を目指しています。

秋山：PPIのプロジェクトは多種多様でスタイルのちがいも大きいので、常に細かい調整が必要で、ツールの仕様もどんどん複雑化してきたという経緯があります。だからユーザー側でもある程度は対応できる余地をつくっておけば、現場も助かるし、開発側も助かるだろうと考えています。

菊地：そうすることで、エンジニアはコア部分の開発に集中できますしね。

パベル：その一環でエフェクトグループをTAグループという名前にして、ほかの工程のスタッフが必要とするツールの開発も引き受ける体制にしました。

菊地：パイプライン 1.0の時代はリガーがツール開発を担っていた、という話に通じるものがありますね。

秋山：確かに。時代が変わって、今はエフェクトが担うようになりました。

菊地：プロシージャルに慣れているエフェクトが、パイプライン開発の一翼を担うという変化は時代を象徴していると思います。パイプライン APIや、PDGライブラリの提供によって、ユーザー側からのアクセスの敷居を下げ、パイプラインへの積極的なアプローチを可能にする。長い歴史を重ね、多くのエンジニアを抱えるPPIだから可能な、極めてモダンなパイプラインだと思います。

パベル：私がHoudiniで一番気に入っている点は、無限にカスタマイズできて、容易に変更を加えられる点です。セットアップに少し多めの時間を費やし、優れたネットワークを用意すれば、非常に迅速な変更が可能になり、定時に帰宅できます。私たちの仕事において、これは非常に良いことです（笑）。今後も理想的なパイプラインとワークフローを追求していきたいです。