工程別インフラ要求の目安
Estimated infrastructure requirements by process
（株式会社ポリゴン・ピクチュアズ / スタジオフォンズ）
(Polygon Pictures Inc. / Studio Phones)
今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。
この資料は2018年の前半に書かれたものですので、システム上のスペックを読まれる際はご留意下さい。
■概要
■Overview
under construction...
■モデリング
■Modeling
モデリング工程では、キャラクター、クリーチャー、プロップ、背景セットなどをモデリングしていきますが、キャラクターやクリーチャーなどはマケットを制作するケースがほとんどですので、スカルプトが行えるツールが必要となります。またデータサイズを低減するためにサブディビジョンサーフェスなどを利用し、メッシュのデータ容量を減らしたり、ディテールをディスプレイスメントマップなどのテクスチャ情報に置き換えるといった作業を行います。
プロップひとつひとつは大きなデータではありませんが、プロップをセットドレッシングし背景アセットを構築していくため、背景アセットのデータ量は必然的に大きくなってしまいます。セットドレッシングではプロップをインスタンスしたり、リファレンスすることによって、データサイズが肥大化しないよう工夫しながら背景セットを作成していきます。背景アセット制作ではアセットライブラリの存在も重要で、大量のプロップデータをライブラリとして管理し、それらがセットドレッシングのツールなどから自由にアクセスできるような環境も必要となってきます。
また、それらの容量の大きいデータをプレビューする際には、各オブジェクトをそのまま表示すると大量のVRAMを必要とする場合もあるため、バウンディングボックスやプロキシ化されたアセット表示など、抽象化された表示モード機能を使い、UI上のレスポンスを軽量にし作業を効率化するような対応も行われています。背景セットのモデリング作業時には、12GB以上のVRAMがあるとGPUがボトルネックとなるようなこともほぼ発生しないように思われます。
キャラクターモデリングなどではメインキャラクターなどは数万〜十数万ポリゴン程度になることが一般的ですが、その程度のデータではファイルサーバーなどのストレージシステムに配置して作業を行ってもストレスはなく、インスタンシングやリファレンシングできない大規模アセットのハンドリングを除けば、モデリング工程は他の工程と比べ特別なインフラを必要としないことが特徴であるとも言えます。
under construction...
■ルックデブ / サーフェシング
■Look Development / Surfacing
ルックデブやサーフェシングでは、テクスチャの作成やマテリアルのパラメータ調整、ライティング時に使用するレンダラーを用いてレンダリング結果をカタログ化していきます。テクスチャの生成は画像処理ソフトによる単純な2D処理から、近年では3Dペイントやプロシージャル処理といった作業を専用のソフトウェアで実行していきます。それらの多くは処理の高速化のために、GPUと一定サイズ以上のVRAMを必要とする場合が多く存在します。テクスチャのサイズも4Kや8Kといった解像度が求められたり、UDIMなどによってテクスチャの容量は近年増える一方となってきており、多くのメモリを消費します。GPUのVRAMは8GBや10GBなどが近年のGPUでは一般的ですが、3Dペイント系のソフトウェアでは、それらのメモリ容量でも十分ではない場合もあり、理想的にはCPU側のメモリと同程度のサイズのVRAMが搭載されていると、VRAMがボトルネックとなるようなケースも絵低減されるものと思われます。
マテリアルパラメータの調整では、変更後のルックを都度確認しながら作業を行うため、他の工程と比べてイテレーション回数も比較的多く、プレビュー環境のレスポンス速度が重要となってきます。また複雑なシェーディングノードを構築するケースもあり、それらをノードベースなどで組み上げるためのUIの使いやすさも大切です。レンダリングはターンテーブル程度のフレーム数となりますが、レンダリングはライティング時と同等な設定が用いられるため、ライティング工程とほぼ同様なスッペックのレンダリング計算のための計算クラスターなども必要となってきます。
また、この工程で作成されるアセットデータは後工程のショット作業で繰り返し利用されるデータとなり、特にライティング作業においては、これらのマテリアルパラメータやテクスチャが、レンダリング時間や品質に大きな影響を与えるものとなるため、データの最適化やエラーのチェックについても事前に丁寧に行う必要がある工程となります。
under construction...
■リギング
■Rigging
リギング作業はプロダクション工程のなかでは最も大きなインフラを必要としない工程です。生成されるデータもボーンやコントローラーのパラメータ情報、スキニングのためのウェイト情報などで、データサイズも小さなものとなります。データサイズは小さいですがパラメータの数は多く、データの構造も複雑になります。それら複雑なデータを効率的に扱うにはUI上の工夫も必要で、階層構造を持ったデータアクセスを高速に行える、また階層表示を展開(Expand)したり折り畳み(Collapse)できるようなUIが重宝します。
モジュラーリギングなどでは、スクリプトによるビルド処理などが発生することなどから、スクリプティングが行える環境も必須となりますが、計算クラスターなどは一般的には必要としません。アーティストが作業するマシンもCPUが4コア、メモリも16GB〜32GB程度のスペックで十分に作業が行えます。
そもそもリギングは、アニメーターがアニメーションをつけるための仕組み（リグ）を構築する工程となりますが、リグの設計やそのパフォーマンスなどがアニメーターの作業効率に直結するため、動作の軽量化のための様々な工夫を講じながらリギングを行っていく必要があります。アニメーション時のリグの評価などは、その動作が高速であるほど、アニメーターにとって使いやすいリグシステムとなります。
under construction...
■アニメーション
■Animation
アニメーション工程では、キーフレーム等でアニメーション付されたモデルを高速にプレビューできる仕組みとインフラが重要となります。リグシステムの性能とも密接な関係がありますが、プレビュー再生に時間がかかったり、そもそもフレームレートの速度が十分でない場合は、アニメーションの確認を行うこともできません。また実際にキーフレームアニメーション付けを行っている際のレスポンスが遅い場合は、アニメーション工程の生産性を著しく低下させてしまうことになります。
プレビューを高速化するために、近年ではGPUキャッシュを利用したり、そもそもGPUと親和性の高いデータ構造でプレビュー再生を行うといったソリューションも存在します。また、テクスチャなどGPU負荷を上げるようなデータを削除した、アニメーション作業用に最低限必要なデータに軽量化したアセットデータを別途用意し、アニメーション作業の効率化を図るワークフローも一般的です。
群衆シーンなどでは、アニメーションライブラリなどから、サイクルアニメーションのデータを呼び出し、それらをうまく組み合わせることによって、動的にアニメーションを生成してくといったワークフローもよく利用されるため、アニメーションをアセット化し、データベースとして格納していくインフラも必要となります。
前述のとおり、リグシステムとアニメーション作業は密接な関係があり、アニメーション時のプレビュー時には、24fpsや30fpsなど作品の最終的なパッケージのフレームレートと同じ速度が理想的となります。
また、アニメーターが表現のために必要となる機能とパフォーマンスとのバランスを、リグシステムがうまく調整する必要があり、動作性能を上げアニメーターがアニメーションを付けやすい環境をサポートしていくことが重要となります。
アニメーターの作業マシンは、メモリは32〜64GB程度で十分ですが、リグ動作の高速化のためにCPUのコア数などは6〜8コア程度あったほうがよく、GPUを利用した高速なプレビューを行うには、VRAMが8GB以上でnVIDIA社のGPUで考えた場合は、MaxwellやPascal世代以上のGPUが望ましいです。
under construction...
■エフェクト / シミュレーション
■FX / Simulation
すべての工程のなかで、データ量、計算リソースの両方でインフラへの要求が大きくなるのがこのエフェクト/シミュレーション工程となります。別途の関連資料でもエフェクト工程のデータについて説明していますので、ご参照いただけますと幸いです。
Houdiniの一般的なデータI/O
https://a-film-production-technique-seminar.com/fppat/materials/ppi_houdini_io/index.html
エフェクトやシミュレーションの工程では、そのアニメーションを物理シミュレーションなどの手法を用いて計算されるため、大きな計算クラスターが必要となります。物理シミュレーション計算の特性から、直前のフレームでの計算処理結果が必要となるケースが多く、計算クラスター上での効率的な分散処理にも課題があります。
またシミュレーションで得られた結果をフレーム毎にファイルにキャッシュしていくことが一般的ですが、映像を高精細化が進むなかでそのファイルサイズは肥大する一方です。一つのフレームのキャッシュファイルのサイズが数十GB〜数百GBになることも珍しくなく、それらを保存しておくための大容量なストレージシステムも必要なります。当然ながら大きなデータサイズのやりとりが発生するため、ネットワークトラフィックも多くなり、それらがボトルネックとならないよう、10Gbps以上のネットワークインフラやSSDディスクで構成されたストレージアレイなどが要求されていきます。
また実際にシミュレーションを行うマシンでは、計算時に大きなメモリサイズを必要とする場合も多く、クラスター内の個々のマシン性能も高いものが要求されます。
DCCツールの設計にも依存しますが、分散処理がしづらい機能も多いことから、クラウドインフラなどを想定した場合は、課題が多い工程でもあると思います。
under construction...
■ライティング / レンダリング
■Lighting / Rendering
ライティングの工程では、それまでの各工程で作成されたデータをアッセンブルし、ライティングを行いレンダリング計算から画像を生成する作業を行います。近年では、ライティングの工程はショット単位での作業から、幾つかのショットをまとめた一連のシーケンスベースで行う場合も多く、シーケンス全体でマスターライティングされたものをショット単位にブレークダウンしていくワークフローが用いられることによる効率化や、レンダラーの性能により少ないライトの数で高品質なライティング結果を得られるため、ライティング作業コストは低減されてきていますが、それとは逆にレンダリング計算のコストは増加傾向で、エフェクトやシミュレーションと同じように大きな計算クラスターを必要とします。
コア数の違いにより変わってはきますが、1フレームのレンダリングに数十分〜数時間かかるものもあり、1フレームあたりのレンダリング画像データサイズも数十MB〜数百MBになるケースも存在します。
この工程では、前述のエフェクト/シミュレーション工程と同様に、計算時間かかかる処理のプレビューを行いながら作業を進めていくため、そのレスポンスが作業効率に直結することから、アーティスト作業用にスペックの高いマシン構成が望ましいです。CPUコア数も8〜16コアでメモリも64〜128GB、GPUレンダリングなども行うことを考えると、1台のマシンにGPUを2枚利用したり、VRAMを12〜24GB搭載したグラフィックボードが利用できることが理想的です。また計算時に一時的にローカルディスクにキャッシュファイルを生成することもあるため、ローカルディスクをSSDで構成することにより、より計算速度を向上させることができます。
またレンダリング時には、シミュレーションキャッシュのデータや背景セットデータなど、すべてのデータを読み込んでレンダリングを行う必要があるため、それらをハンドリングするために、広帯域なネットワークや高速なストレージシステムも当然必要となります。コンポジット時には複数の要素がレイヤー階層として格納されたレンダリング画像を、ファイルサーバー上から直接読み込んで作業を行うことがほとんどのため、1Gbpsのネットワーク帯域などではリアルタイムにシーケンスを再生することが難しく、場合によっては帯域不足がボトルネックになるケースもあり、ストレージシステムも含め高性能なスループットを要求することになります。
特にセルルックCG表現を始めとするNPR的なな表現では、コンポジット作業時に細かなポスト調整ができるよう、マスクや輪郭線を別のデータとして出力したり、別々に多くの要素画像をAOVとしてレンダリング時に出力する傾向も強く、一般的なCG表現のレンダリング画像と比べ、レンダリング画像データ量が肥大化するケースも想定されます。
under construction...