Kitsu Summitで、Normaal Studioのパイプライン責任者であるFélix Davidが、これまで3Dシリーズを制作したことのないスタジオの中から、ゼロから本番運用レベルの3Dパイプラインをどのように構築したのかを共有しました。
彼の講演では、「Woolly Woolly」（全52話のアニメーション・シリーズ）におけるパイプライン形成を形作ったツール、思想、そして厳しい学びが取り上げられました。
制作プロセスを拡張したいアニメーションスタジオは、ぜひ彼の経験をじっくり学ぶ価値があります!
登壇者について
Félix Davidは、数年にわたりパイプラインTDとして働いてきました。以前はSuper Prodで、その後Normaal Studioに入ってリード・パイプライン・デベロッパーとして加わりました。
Normaal Studioは、2D制作に深いルーツを持つフランスのアニメーションスタジオです。同スタジオが「Woolly Woolly」の制作を決めたときは、11分×全52話のストップモーションに着想を得た3Dシリーズでしたが、既存の3Dインフラはありませんでした。
Félixは、そのインフラをゼロから構築するために招かれました。やがてチームは5名のパイプラインTDへと成長し、アングレーム、パリ、ケベックの3拠点に広がるおよそ80名のアニメーターと協働する体制になりました。
中核の課題：2Dスタジオが「3Dも2Dのように感じること」を期待していた
Félixが受け取った制作ブリーフには、少し変わった要件が含まれていました。
Normaal Studioの監督やスーパーバイザーは2D出身だったため、制作のあらゆる段階で、最終レンダーに近いものが見えることを期待していました。
2Dアニメーションでは、描いたものがそのまま見えるのが本質です。
3Dでは、それはめったに当てはまりません。シェーディングパス、ライティング設定、カメラ補正、レンダリングキュー……。アニメーターの作業と最終フレームの差は、昼と夜ほどです。
Félixが説明したように、「常に、できるだけ最終レンダーに近い状態でプレビューを表示できるパイプラインが欲しかった」のです。
そこでチームは、低解像度ではあるものの、完全にライティングされたレンダーをアニメーションのパブリッシュ手順に直接組み込みました。
アニメーターが作業を提出すると、パイプラインは自動的に、単なるプレイブラスト（素早いビューポートプレビュー）だけでなく、セットにすでに組み込まれているライトを使って「本物のレンダー」も実行します。
「Woolly Woolly」は、舞台セットの演出に着想を得た、フラットで正面向きのビジュアルスタイルを採用していました。そのため、ライトは常にセットに合わせており、ショット間で移動する必要がありませんでした。結果として、低解像度レンダーは制作コストが安いだけでなく、最終ルックを確かな形で反映できていました。
パイプラインの思想：自動化するが、負担は増やさない
特定のソフトウェアを選ぶ前に、Félixはパイプライン全体の指針を定めました。自動化は手順を取り除くべきで、手順を増やすべきではありません。
この制約なしにパイプラインを構築すると、アーティストが余計なダイアログをクリックし続けたり、メタデータの入力フォームを埋めたり、理解できない工程が終わるまで待たされたりする結果になりがちです。
「メインの思想は、プロセスに“追加の痛み”を生まないことです」とFélixは言いました。「コンピュータが制作に付け加えてくる制約からの自由を得ることです。」
その考え方が、以降のあらゆる技術的判断の土台になりました。
なぜオープンソースのツールを選んだのか：KitsuとAYON
制作トラッキングにはKitsuを選びました。パイプライン管理にはAYON（OpenPype）を選びました。AYONは、ファイルのパブリッシュ、バージョン管理、アセットの読み込み、複数拠点間の同期などを扱う、オープンソースのパイプライン基盤です。Blenderは、3D作業の主要DCC（デジタル・コンテンツ制作）アプリケーションとして機能しました。
Félixは、独自スクリプトを作り込むよりも、既存のオープンソースツールを使うことを意識して決めました。「直面するであろうすべてのニーズを先回りして予測することはできません。すでにテストされ開発されているものを使うことが役に立ちます。というのも、あなたが扱うことになるユースケースの多くは、すでに解決済みだからです。」
3D制作が初めてのスタジオにとって、その主張は非常に重みがあります。ゼロから独自のパイプラインを作るということは、他のスタジオがすでに取り組んで解決済みの問題を何か月もかけて解くことを意味します。AYONやKitsuのようなオープンソースツールには、そうした課題の多くに対する解決策が最初から組み込まれています。
制作期間中、Normaal StudioがAYONに貢献したことの1つは、KitsuとAYONの間の同期システムでした。これにより、Kitsuの制作トラッキングデータが自動的にAYON側のパイプライン状態へ反映されます。この貢献は、メインのAYONコードベースへと提出されました。
Félixは、貢献していくこのプロセスについて、遅いが結果的に信頼性が高いと述べました。「受け入れられてマージされ、メインのコードベースで使われるようになった時点で、それがテストされていることが分かります。長く残るので、コードを慎重に設計するよう促されます。」
ノンデストラクティブなパブリッシュ＆パスベースのデータアクセス
データがNormaal Studioのパイプライン内を流れる仕組みには、2つの原則がありました。
1つ目は、ノンデストラクティブなパブリッシュです。いったんデータがパブリッシュされたら、後から改変しません。変更が必要な場合は、新しいバージョンを公開します。これにより、どのショットも、使ったアセットの正確なバージョンへ常に追跡でき、公開済みデータが後からの編集によって、静かに壊れてしまうことも防げます。
2つ目は、データ転送ではなくパス解決です。中央サーバーを介してファイルを配信するのではなく、AYONは要求に応じてファイルのパスを解決します。アーティストや自動処理がファイルを必要としたとき、AYONはそのファイルがファイルシステム上のどこにあるかのパスを返します。実際のデータ転送は、より遅いパイプラインサーバーを使う代わりに、標準のファイル同期メカニズムで行われます。
Félixは、この実務上の利点をインフラの観点で説明しました。「何かの“パス”だけを求めるなら、はるかに軽く済みます。制作を動かすのに、大きくて重たいインフラを必要としないんです。」付け加えて、回復力（レジリエンス）も強化されました。各ワークステーションが自分のデータをローカルにキャッシュしていたため、サーバーがダウンしても、作業者はローカルコピーで作業を続けられ、復旧すれば戻ってこられます。
アセット・ワークフローとショット・ワークフロー
Félixの講演で最も価値のある洞察の1つが、アセットとショットをパイプライン内でどう扱うべきかについての区別です。2つは、非常に異なる挙動をします。
アセットは、設計上“合成可能”です。たとえばキャラクターは、ジオメトリ、シェーディング、リグといった別々にパブリッシュされた成果物で構成されているかもしれません。リグはジオメトリとシェーディングの両方を参照しますが、ジオメトリだけを読み込むこともできます。これは、フルリグのオーバーヘッドなしにキャラクターを背景へ配置するときに役立ちます。
Félixは、ショット・ワークフローが当初、この合成可能な考え方をそのまま写して、ジオメトリ、リグ、カメラデータを各段階の個別のパブリッシュ成果物へ分散させる形になっていたことを説明しました。
しかし、そのアプローチは実運用では維持できませんでした。「成立はするけれど無意味です。アニメーションはレイアウトの直後に行われ、ほとんどの項目で同じ設定を使うからです。」
最終的にチームが採用したショット・ワークフローは、合成可能というより“段階的（インクリメンタル）”でした。ショットのパイプライン各ステージは、前のステージの作業ファイルを直接土台に構築します。レイアウトは、アニメーションの開始地点となる作業ファイルを生成します。アニメーションは、エフェクトとレンダリングの開始地点となる作業ファイルを生成します。各ステップで細かく分割して作り直すことはしません。
アセットが進化してもショットを最新に保つ
ロングフォームの制作で避けられない問題の1つが、アセットの進化です。
キャラクターのシェーダーが良くなります。リグが修正されます。セットは作り直されます。「Woolly Woolly」では、制作チームが定期的に、すでにアニメーション済みだがまだ承認されていないショットへ反映するための更新アセットを求めました。
Normaal Studioは、それを「ヒーローバージョン（hero versions）」という考え方で解決しました。
ヒーローバージョンとは、特定の番号が振られたアセットバージョンのことではありません。常に、いちばん直近にパブリッシュされたバージョンを指します。レイアウトシーンは、個別の番号付きバージョンではなく、各キャラクターのヒーローバージョンを参照しました。
つまり、キャラクターの新しいシェーダーがパブリッシュされたとき、そのキャラクターのヒーロー参照を使っているレイアウトシーンは、次に開いたタイミングで自動的に更新が取り込まれることになります。
すでにアニメーションに入っているショットについては、チームはBlenderベースの自動化ツールを構築しました。作業ファイルを開き、更新されたリグやアセットを差し替え、既存のアニメーションのトランスフォームやモディファイアを保持したまま、新しいアニメーションのバージョンを自動的に再パブリッシュします。このツールは、多くのショットに対して一度に動作し、各アーティストが個別に手作業でシーンを更新する必要はありませんでした。
ファイル依存関係と、リモートアーティストのための事前同期
3つの都市でアーティストが働くなかで、全員のローカル・ファイルキャッシュを常に最新に保つことも別の課題でした。Blenderの大規模な制作シーンは、キャラクター、セット、小道具など多くのリンクファイルに依存します。要求のタイミングでそれらが同期するのを待つのは時間の無駄になります。
Normaal Studioの解決策は、バックグラウンド同期サービスでした。これはKitsuのブレイクダウン機能からデータを使います。ショットがアーティストに割り当てられたら、パイプラインはブレイクダウンを読み取り、そのショットに登場するキャラクターやセットを特定し、タスクを開く前の段階で、関連するすべてのファイルをそのアーティストのワークステーションへ事前同期します。
アーティストが作業開始のクリックをする時点では、必要なものがすでにそこに揃っていました。
作業ファイルについても同じ事前構築のロジックが適用されました。レイアウト担当アーティストに「ビルド」ボタンをクリックさせて、システムが開始シーンを組み立つのを待つ必要はありません。パイプラインはタスクが割り当てられた直後から、その作業ファイルをバックグラウンドで生成します。タスクを開くことは、完全に準備されたファイルを開くことでした。
レンダーファームなしでのレンダリング
Normaal Studioには、クラウドレンダリングや専用のレンダーファームに回せる予算がありませんでした。
その代わりチームは、GoogleとSony Picturesが開発したオープンソースのレンダー管理ツールであるOpenCueを使い、アーティストのワークステーションでアイドル時間が発生している間にレンダリングを分散実行しました。
アーティストがそのワークステーションを使っていない1分ごとに、OpenCueはレンダージョブ、または自動ビルドタスクに割り当てることができます。
重要なポイント
Félixは、彼の特定の技術的な選択を超えてよく当てはまる振り返りで講演を締めくくりました。「誰もが使える“完璧なユニバーサルなパイプライン”は持てません。ですが、スタジオの文化に合い、制作に流動性をもたらす良いパイプラインは作れます。」
Normaal Studioにとってスタジオ文化に合わせるとは、2Dトレーニングを受けた監督にはOpenGLのプレイブラストではなく、ライティングされたレンダーを見せる必要があることを受け入れることでした。つまり、アーティストの考え方を変えることなく、技術的な負担を取り除く自動化を構築することです。そして、コミュニティの知見を何年も吸収してきたKitsuやAYONのようなツールを選ぶことで、パイプラインチームは実際に自分たちの制作で固有の課題に集中できるようになりました。
