Houdiniでの制作フローから見た今回の会合

This meeting from the viewpoint of production workflow at Houdini

（株式会社ポリゴン・ピクチュアズ / スタジオフォンズ）

(Polygon Pictures Inc. / Studio Phones)

本資料は会合後にディスカッションされた内容をもとに事後的に記載しています。今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。

■概要

■Overview

本会合ではHoudiniを例とした制作ワークフローの紹介が複数ありました。会合中に紹介された内容は各社の状況を色濃く反映した解説となっており、パイプラインのデザインやインフラの設計を行う上では、全体を通してどのようにそれらを捉えていくかが課題であると考えました。
そのため本資料では、ポリゴン・ピクチュアズでのHoudini用のパイプライン構成上開発したツールを紹介しつつ、Houdiniに代表されるプロシージャルなアプローチのDCCをどのようにパイプライン上で展開していけるのか、その可能性や課題に関してまとめていきたいと思います。
まとめて行く際には、可能な限り会合中の各社の工夫をふまえつつ、会合中のディスカッションに出ていた多くの課題を振り返っていきたいと思います。

under construction...

■Houdiniで一般的に用いられるワークフロー

■General workflow in Houdini

講演者の発表や参加者の意見などから、Houdiniを使ったワークフローとして共通してみられるのは、外部で制作されたガイドアセットをHoudini内にインポートして作業を進めていくフローが主流になっているという点でした。
つまり、インポートされたアセットをベースに、プロシージャルな処理で背景セットをモデリングしたり、シーンアッセンブルを行なって、エフェクト作業やライティング作業を行なっていくことが一般的となっていたということです。
映像制作では、主にエフェクト制作やライティング、レンダリング用途で用いられるケースが多く、一方ゲーム制作では、プロシージャルなアセット制作のために用いられることがほとんどで、Houdiniで作成したアセットをゲーム実行環境で構築し、ゲームコンテンツ内に実装していく方法が双方の分野で最も用いれられているフローと言えるものに思われました。
映像制作では、エフェクト制作やレンダリングのための、エフェクトキャッシュ、ジオメトリキャッシュ、レンダリング用シーン記述ファイルなど、多くの外部ファイルの入出力が発生するのに対し、ゲーム制作ではキャッシュファイルの利用は限定的なものにとどまっている現状がありました。
シーンアッセンブルのために、各社が外部のDCCツールとの連携のためのツール開発やパイプライン開発を行なっており、各社のワークフローや文化を反映した仕様となっており、会合中、スタジオごとの文化の違いを感じさせ、議論を育んでいました。
これまでHoudiniは映像制作の分野でされることが多く、かつ映像分野ではエフェクトなどの限定的な作業工程で利用されることが多く現在に至りますが、今後はゲーム業界でも広く普及していく予想が強く、そこでは、ゲームに組入れる上でのモデリングやアニメーション工程においても活用されることが予想されるため、映像用に特化し発展したAlembicやFBXなどの既存のデータ交換用のフォーマットでは対応しきれない部分など、今後のワークフロー上の課題も浮かび上がりました。
また今後のユースケースやワークフローの変化の中では、今後はモデリングからレンダリングまでHoudini上で一元的なワークフローが組まれるケースも出てくることも参加者からの意見としてありました。つまり、Houdiniそれ自体が今まで他社のソフトウェアと連携し用いることを前提に発展して来たと言えるわけですが、昨今のニーズから今まで扱って来ていない広範囲の機能を獲得し始め、ゲーム領域などの制作フローなどにも対応していくなかで、より柔軟性に富む発展を遂げたために今までと異なる展開が出始めそうであるということです。
加えて、今後映像制作、ゲーム制作のワークフローやパイプラインに大きな変革をもたらすことが期待されている機械学習やAIといった分野の技術者のような、今までエンタメ領域のソフトウェアを用いていなかったユーザー層も世界的には出始めていて、そのため、他分野のユーザーが利用する上で機能強化が進むなら、今まで以上に刺激ある展開と成り得る予感も出て来たように思われます。

under construction...

■Houdiniで扱われるデータフォーマット

■Data format handled by Houdini

ここで少し現状整理を行いたいと思います。今回の会合の中では、映像制作領域においてはレイアウトやアニメーション以降のアセットデータをHoudiniにインポートすることが多く、AlembicやOpenVDBといったデータフォーマットを利用するケースがほとんどという状況でした。一方、ゲーム制作領域では、ゲームエンジンとの相性からデータ交換のフォーマットとして、FBXが広く使われていました。しかしながら、双方の領域での使われ方や制作フロー上求められるものは、会社ごとにも大きく違う上、事業の違いにより要求する事柄が大きく違うせいか、異なる展開をデータフォーマットの取り扱いにも反映していました。
これまでデータの出力という面においては、キャッシュファイルベースで出力されることが主だったHoudiniですが、今後はゲーム制作向けやその他の利用目的のために、ベイクされたキャッシュデータのみにならずアニメーションデータやマテリアルデータなど、より柔軟なデータファイル入出力が必要になると思われ、ある意味、多分野向けのソフトウェアとしての柔軟性を出していく流れの中、今まで以上にユースケースそのものが多岐に渡り始める予感もあり、それらが求めるストレージ要求に関しても考えさせてくれる結果となっていました。
また会合中、Houdiniからの出力とゲームエンジン側とのデータ交換にUSDといった新しいフォーマットを活用していく話題もありました。参加者からもDCCツールに依存したファイルフォーマットはアセットの長期保存の面で不安があり、OBJやUSDといった、ユニバーサルかつオープンなフォーマットを利用していくことで、そういったリスクを回避していく傾向も見受けられました。
つまり今まで以上に、個々の分野がデータの長期保管に目線を向け始めたようにも思え、それらはストレージの可用性とのバランスも同時に考えることを要求し、新たな展開を感じました。

under construction...

■ポリゴン・ピクチュアズでのHoudiniツール

■Houdini tools in Polygon Pictures

ここでは、会合中ポリゴン・ピクチュアズからの講演であった、前述のアセットデータのインポートやシーンアッセンブルのためのツールをいくつかご紹介します。あくまでポリゴンピクチュアズ社内での例として解説しますが、比較的一般的なユースケースに反って考えつつ取り入れて頂けるよう、解説をしたいと思います。

●Alembic Publisher


アニメーション作業が完了したMayaデータからはキーフレームのアニメーションデータが出力されますが、リギングされたアセットはMaya上でのみ存在するため、エフェクト作業でアニメーションされたジオメトリを利用する場合、Alembic等のジオメトリキャッシュデータが必要となります。
そのAlembicファイルを生成にあたり、手作業によるキャッシュデータの書き出しは作業コストがかかってしまう点から、ポリゴン・ピクチュアズではAlembicファイルを生成するためのツールが用意されています。
パイプラインのデータベース上に登録された、ファイルサーバー上に存在するアセットデータとアニメーションデータの最新リビジョンを取り出し、ローカルでいちどシーンをアッセンブルします。その後Alembicに変換してファイルサーバーにデータを書き出します。
ツールでは変換処理をキューイングすることも可能で、変換処理を自動化することでアセットデータの選択ミスといったヒューマンエラーを低減させています。
キャッシュデータの生成は比較的処理負荷が高く時間がかかってしまうため、変換を自動化してツール化することのメリットはアーティストにとって非常に効果が高いものとなっています。


●Scene Manager


エフェクト作業開始時に、シーンアッセンブルするためのツールとなります。
パイプラインのデータベース上から必要なデータを収集し、ショットデータを構築します。カスタムプロセスの実行により、ショットごとに異なる事前処理を実行することも可能です。
またパイプラインデータベース上に格納されているメタ情報も、追加の情報として付加して、Houdini内に読み込むことが可能です。
アーティストは自分が作業をするショットに対して、迷いなくシーンを構築できるため、特にアセット点数が多いショットなどではこのツールが非常に重宝します。
このようなツールがない場合は、アーティストが作業を開始するまでの準備に多くの時間を費やすこととなり、非常に生産性を低下させてしまいます。またアセットひとつひとつのデータサイズも大きいことから、何かしらのエラーがあった際の手戻りにかかる時間も非常に大きな時間的ロスが発生することとなります。
Houdiniでパイプラインを構築する際には、このようにシーンアッセンブルを自動化するようなツールが効率化のために必須となりますが、機能追加のための開発環境も整備されており、パイプラインフレンドリーなDCCツールとなっています。
シーンアッセンブルして、そのままディスパッチャーへレンダリングジョブを送信するこも可能で、DCCツールを立ち上げる必要がないため、ジョブ送信までの待ち時間を大幅に短縮できます。


●Data Manager


パイプラインデータベースと連携し、ファイルサーバー上のデータをインポートしたり、パブリッシュするためのツールとなります。
パブリッシュ時に、後工程で必要となるデータを所定の場所に格納したり、適宜最適なデータフォーマットに変換したりするような処理もパブリッシュ時に自動的に実行されるようになっています。
インポートについては、多くの作業で前述のScene Managerを使用しますが、追加のアセットなどが必要な場合は、このツールを使用してパイプライン上のデータにアクセスします。
ポリゴン・ピクチュアズでは、エフェクトデータについてもHDAなどでアセット化することも多く、アセットデータベースに登録されたデータに対しても素早くアクセスし必要なデータをインポートすることが可能です。


●File Open/Save


アーティストのワーク作業ファイルのOpen/Saveをサポートするツールとなります。
パブリッシュ前にアーティスト側では様々なイテレーションを行うことになりますが、通常、様々な試行錯誤を繰り返すなかで、その作業ファイルの管理が煩雑になっていきます。
それらの作業ファイルがリビジョン管理も含め、正しい場所に、命名規則に従ったファイル名で保存され、ファイル管理が煩雑にならないように設計されています。
また、作業ファイルを他のアーティストが引き継ぐケースも制作フロー上発生しますが、データが一定のルールで整理されているため、引き継ぎを受けたアーティストが迷いなくそのファイルから作業を継続することが可能となります。


●Update Variable Revision


読み込んだアセットのリビジョンを変更するためのツールとなります。
作業開始時にScene Managerでシーンアッセンブルを行いますが、作業中に新しいアセットがリリースされたり、またはリビジョンが古いアセットに戻して作業をするといったことが可能となります。
シーンアッセンブル後も柔軟にアセットの入替えが行えることにより、アーティストのイテレーション作業に効率化をもたらします。


これらのツールはあくまで一例となりますが、ワークフロー効率化やデータ容量の低減のために、パイプラインのインフラ設計に則したかたちでツールの設計、開発をしていくことが重要です。

under construction...

■Houdiniの制作フローからみたインフラへの要件

■Requirements for infrastructure as seen from production flow of Houdini

Houdiniで扱うアセットデータやキャッシュデータのほとんどは大容量のものが多く、映像制作スタジオでは、これらのキャッシュファイルを共有ストレージに配置してシミュレーションやレンダリングといった分散処理を行うため、ストレージシステムに対して、高いI/O性能への要求がありました。
それらのキャッシュデータを利用する際に、ファイルすべてのデータをオンメモリにロードすることは、データ容量の観点から現実的ではないため、キャッシュファイルから必要なデータを部分的にロードする必要があり、これらの要求に対して高速にレスポンスを返すためにオールフラッシュ（SSD）のストレージを採用するケースもありました。
会合中、Houdiniを動作させるOS環境についても意見交換がありました。Linux環境ではWindows環境に比べ、アプリケーションの起動のみならず、NFSプロトコルなどデータI/O面でも速度的な優位性がありますが、国内の多くのスタジオではWindows環境が主流のため、WindowsとLinuxが共存できるようなインフラ環境の構築の必要性が高いというように感じられました。
また、データそのものの容量削減についての必要性にも触れられ、BLOSC圧縮などのデータ圧縮をパイプライン上で自動で実行する仕組みや、Wedgeを使い複数のバリエーションのシミュレーションやレンダリングをキャッシュレスで行うことにより、無駄なキャッシュファイルを生成しないフローの紹介がありました。
Houdiniを使わないスタジオでも、同様の仕組みを内製で構築し扱っているとの発表もあり、商用DCCに依存しない形でスタジオごとに個別のプロシージャルなアプローチをパイプライン上に導入している様子も感じ取れました。これら内製のソフトウェア開発でもプロシージャルなアプローチは進展していて非常に刺激ある発表が多かった会合でしたが、内製の柔軟性を生かし、サーバサイドでのそれらの機能の実装などがいち早く進んでいることも印象的でした。これらは次回の会合でも特集していきたい課題であるとして、多くの意見が会合後に寄せられました。
bgeoファイルはHoudini内で標準機能として構築されているキャッシュフォーマットです。今回の会合では、これらのキャッシュをパイプライン上で個別に管理していく意味でもストレージのIOの速度などが議題に登りましたが、スタジオによってはOBJ,OpenVDBなどの汎用高速データフォーマットを柔軟にハンドリングする仕組みを構成し、そのことでパイプライン上での細かいデータの調整や、新機能の追加などを容易にする環境などを構築しているとのことでした。
例えば、スタジオによってはOpenVDBのPythonラッパーを用いて、OpenVDBを直接触る前提でそのような機能を実装しているという話もありました。つまり、HoudiniからOpenVDBなどへデータを一旦出力し、pythonラッパー越しに様々な機能をコントロール出来る機能などを構成したり、メッシュのいわゆるブーリアン演算などの機能をVDBにあらかじめ搭載されている様々な関数を駆使して構築するなど、TDの仕事がよりパイプラインの構成そのものに近いあたりで展開されている様子が伺えました。
シミュレーションという面からは、Houdiniは分散処理にも対応したソルバーと分散処理のためのディスパッチャー(Hqueue)が用意されています。しかし、それらを効率的に処理していくためには、計算クラスターの設計やそれにともなう、ストレージやネットワークの性能も重要となり、インフラ設計の良し悪しが計算時間に大きな影響を与えることになります。会合中はそれらの全てを説明はしないまま議論が高度に進みましたが、今後の映像制作パイプラインの構築の際には、様々なキャッシュフォーマットの使い分けや個別に計算クラスタ内に処理を分散させる仕組みを、今まで以上に高度なものにしないといけない、そのような動向を感じさせる意見が多かったように思います。
その背景では、キャッシュのトラベリングのための様々な工夫がスタジオに合ったかたちで提供されないとなかなか運用は厳しいという、パイプラインやインフラを扱う方であれば周知の事実がそこにあったのは言うまでもありません。しかしながら、各社それぞれが、ストレージへの要求を的確に把握し工夫をしていく準備をしている様子が伺いして、より高度に様々なキャッシュを平易にトラベリングするための仕組み作りを課題にしている点が今回の会合では非常に印象に残ったことのひとつであったように思います。
また、新しいバージョンのHoudiniではOpenCLを直接プログラミングすることが可能になるわけですが、今まで速度に悩まされて来たSOP処理などでもOpenCLを使用したCPU/GPUアクセラレーションを利用することも可能になっていく時代に入ろうとしており、巨大なポイントデータに対して処理を行う際などに効果的に扱える時代に入りつつあるとも言える状況にいます、しかし、それらを最大限プロダクションユースで用いようとすると、GPUを含めた計算クラスターのハードウェア構成の再設計さえ必要になって来ると思います。
つまり、CPUのみで大規模な分散処理を行うに適したインフラを現時点で保有していたとしても、CPUとGPUが混在利用されるこれからの時代では、インフラレベルからの大幅な見直しが必要になって来る可能性があると言えるかと思います。言い換えれば、Houdiniなどでこれから複雑化する様々な機能をうまく使いこなしていく意味でも、その効果的なワークフロー達成するための環境を構築するためには、一台のマシン内での計算速度の向上などを意識することに留まらないかたちで、インフラ内の全ての計算資源を自在に低コストな稼働形態で運用するためにも、高度なインフラ構成を設計・運用していく体力作りが各スタジオに求められていくことになると思われました。

under construction...

■Houdiniの制作フローからみたインフラへの今後の課題

■Future tasks for infrastructure as seen from production flow of Houdini

Houdiniにおいて、I/O性能の低下はアーティストのイテレーションや制作期間そのものへの影響が大きくなるため、用途に応じた正しいインフラ設計および、データフォーマットやワークフロー上の工夫といった両面での対応が重要になると考えられます。
それに伴い、Houdiniを中心としたデータ交換フォーマットは多様化し、用途に応じて使い分ける必要が出て来るものと考えられます。
会合では、Houdiniの制作フローを中心に、それを効率よく運用していくためのインフラ面についてのディスカッションがありましたが、フォーマットの選択やパイプラインとのデータI/Oツール開発を担うテクニカルアーティストもファイルフォーマットの特性やI/Oに対するインフラ要件を深く理解し、インフラエンジニアとコミュニケーションをとりながらワークフローを設計していく重要性を強く認識しました。
アーティストからのニーズでツール開発を行う際も、ユーザービリティとインフラの両面を加味して、ソリューションとして提案していける人材が、今後のTA/TDという職種に求められて行くと考えられます。
TA/TDのかたがたは、主にDCCツールやその周辺でのツール開発スキルを習得していくことが主流になっている思いますが、それらとは多少性質の異なるインフラ面での技術知識やスキルをどのように獲得していくかなどが今後課題となっていくものと考えられます。
加えて、講演したスタジオの中では、ハードウェアのエコサイクルを意識し、例えばラックマウント用のケース設計をうまく行っていくことで、リサイクルなどを意識した運用はできないか思案しているという紹介もありました。
実際のところ、エンタメ領域で扱うPC台数は多いと思われ、その機器の破棄まで含めて考えていくことは、とくに大手スタジオレベルでは考えていくべき課題に思われました。

under construction...