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へと成長し、Angoulême、パリ、Québecの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へ提供した貢献の一つが、KitsuとAYONの間を同期させる仕組みでした。これにより、Kitsu上の制作トラッキングデータが、AYONのパイプライン状態に自動的に反映されます。この貢献は、メインのAYONコードベースに提出されました。
Félixは「貢献を戻す」プロセスについて、遅いが最終的にはより信頼できると説明しました。 「それが受け入れられてマージされ、メインのコードベースで使われるようになれば、テストされていることが分かります。長い間そこに残るので、コードを丁寧に設計せざるを得なくなるんです。」
ノンデストラクティブなパブリッシュ＆パスベースのデータアクセス
データがNormaal Studioのパイプラインをどう移動するかには、2つの原則がありました。
1つ目はノンデストラクティブなパブリッシュです。いったんデータがパブリッシュされると、以後それは変更されません。何かを変える必要がある場合は、新しいバージョンをパブリッシュします。これにより、どのショットも、使用した“そのアセットの正確なバージョン”へ常に遡れることが保証され、さらに後からの編集によって、パブリッシュ済みデータが知らないうちに壊れることも防げます。
2つ目の原則は、データ転送ではなくパス解決です。中央サーバー経由でファイルを配信するのではなく、AYONは要求に応じてファイルパスを解決します。アーティスト、または自動化プロセスがファイルを必要とすると、AYONはそのファイルがファイルシステム上でどこにあるかのパスを返します。実際のデータ転送は、遅いパイプラインサーバーを介さず、標準的なファイル同期の仕組みで行われます。
Félixは、このインフラ上の実用的な利点を「何かの“パス”だけを要求するなら、要求が軽くなり、制作を回すために大きく重いインフラは必要なくなる」と表現しました。もう一つの利点はレジリエンス（復元力）です。各ワークステーションは自分のデータをローカルにキャッシュするため、サーバーが落ちても、サーバーが復旧するまでアーティストはローカルコピーで作業を続けられます。
アセットワークフローとショットワークフロー
Félixの講演から得られた最も価値ある洞察の一つが、パイプラインにおいてアセットとショットをどう扱うべきかの違いでした。両者は振る舞いが大きく異なるからです。
アセットは設計上“組み合わせ可能（composable）”です。たとえばキャラクターは、ジオメトリ、シェーディング、リグといった別々にパブリッシュされた成果物で構成され得ます。リグはジオメトリとシェーディングの両方を参照しますが、ジオメトリだけを読み込むことも可能です。これは、リグ全体のオーバーヘッドなしにキャラクターを背景へ配置するときに役立ちます。
Félixは、最初のショットワークフローが、この組み合わせ可能な考え方をそのままなぞっていたことを説明しました。ジオメトリ、リグ、カメラデータが、各段階で別々のパブリッシュ成果物へ分散されていたのです。
しかし、そのアプローチは実運用ではうまくいきませんでした。 「機能する可能性はありますが、役に立ちません。アニメーションはレイアウトの直後に行われ、ほとんどの項目について同じ設定を使うからです。」
彼らが最終的に落ち着いたショットワークフローは、組み合わせ可能な考え方ではなく、インクリメンタル（段階的）でした。ショットパイプラインの各段階は、前段階の“作業ファイル”から直接積み上がっていきます。レイアウトは作業ファイルを生成し、それがアニメーションの開始点になります。アニメーションは作業ファイルを生成し、それがエフェクトとレンダリングの開始点になります。各ステップで分割して作り直すことはありません。
アセットが進化してもショットを最新に保つ
長編制作で避けられない問題の一つが、アセット進化（evolution）です。
キャラクターはより良いシェーダーになります。リグは修正されます。セットは作り直されます。「Woolly Woolly」では制作チームが、すでにアニメーション済みだがまだ承認されていないショットに対して、更新されたアセットを適用するよう定期的に求めていました。
Normaal Studioはこれを「ヒーローバージョン（hero versions）」という考え方で解決しました。
ヒーローバージョンは、アセットの“特定の番号付きバージョン”を指すのではありません。常に、直近でパブリッシュされた最新バージョンを指します。レイアウトシーンは、各キャラクターについて“番号付きの特定バージョン”ではなく、ヒーローバージョンを参照していました。
これにより、そのキャラクターの新しいシェーダーがパブリッシュされたとき、キャラクターのヒーロー参照を使っているレイアウトシーンは、次に開いたタイミングで自動的に更新内容を取り込むことができました。
すでにアニメーションに入っているショットについては、チームはBlenderベースの自動化ツールを構築しました。このツールは作業ファイルを開き、更新されたリグやアセットへ差し替え、既存のアニメーションのトランスフォームやモディファイアを保持したまま、新しいアニメーションのバージョンを自動的に再パブリッシュできます。さらに、このツールは多数のショットに対して同時に動作し、個々のアーティストが各シーンを手作業で更新する必要がありませんでした。
ファイル依存関係＆遠隔のアーティスト向け事前同期
3つの都市でアーティストが作業するため、全員のローカルなファイルキャッシュを最新に保つことが別の課題になりました。Blender上の大規模な制作シーンは、多数のリンクファイル（キャラクター、セット、小道具など）に依存しており、必要になるたびに同期を待つのは時間の浪費です。
Normaal Studioの解決策は、Kitsuのブレイクダウン機能のデータを使ったバックグラウンドの同期サービスでした。ショットがアーティストに割り当てられると、パイプラインはブレイクダウンを読み取り、そのショットに登場するキャラクターやセットを特定し、タスクを開く前から必要な関連ファイルをアーティストのワークステーションへ事前同期できるようにしました。
アーティストが作業開始をクリックした時点で、必要なものはすべて揃っていました。
同じ考え方は作業ファイルの事前構築にも適用されました。レイアウト担当アーティストが「ビルド」ボタンをクリックしてシステムが開始シーンを組み立てるのを待つのではなく、タスクが割り当てられた瞬間に、パイプラインがその作業ファイルをバックグラウンドで構築します。タスクを開くということは、完全に準備されたファイルを開くことを意味しました。
レンダーファームなしでのレンダリング
Normaal Studioには、クラウドレンダリング予算や専用のレンダーファームがありませんでした。
そこでチームは、GoogleとSony Picturesによって開発されたオープンソースのレンダーマネジメントツールであるOpenCueを使い、アーティストのワークステーションで“アイドル時間”を活用してレンダリングを配分しました。
あるワークステーションがアーティストに使われていない毎分、OpenCueはレンダージョブ、または自動化されたビルドタスクにそのマシンを回すことができました。
要点
Félixは講演を、彼の特定の技術選択を超えて当てはまる振り返りで締めくくりました。 「誰もが使える“完璧な万能パイプライン”を持つことはできません。ですが、スタジオのカルチャーに合い、制作に流動性をもたらす“良いパイプライン”は作れます。」
Normaal Studioにとってカルチャーに合うとは、2Dトレーニングを受けたディレクターがOpenGLのプレイブラストではなく、ライティング済みのレンダーを見る必要があることを受け入れるという意味でした。つまり、アーティストの考え方を変えることなく、技術的な負担を取り除く自動化を構築することです。そして、長年にわたるコミュニティの知見をすでに吸収しているKitsuやAYONのようなツールを選ぶことで、パイプラインチームは実際の制作に固有の問題へ集中できるようになりました。
