Kitsu Submitで、Cube CreativeのCGスーパーバイザーであるAxel Tillementが登壇し、シンプルな問いに答えました。非常に異なるプロジェクトにまたがっても、大量のアセットをどう制作すれば、パイプラインを可能な限り安定させられるのか？ 彼の答えは、制作現場での長年の経験に裏打ちされたもので、混乱のないスケールを目指すあらゆるアニメーションスタジオに向けた、実践的なロードマップを提示しています。
Cubeの経験が学ぶ価値のあるものなのは、個々のプロジェクトの野心そのものではなく、3つすべてが同じパイプラインを通ったという事実です。そして、そのパイプラインは固定的なものでもありません。各制作が次の制作へ、能動的にフィードバックしていたのです。
「それぞれのプロジェクトが、パイプラインに対して独自の貢献をし、前のプロジェクトの上に積み上げていく形になります」とAxelは説明しました。「すべてのプロジェクトでゼロから始めるわけではありません。あるプロジェクトの成果が次のプロジェクトに受け継がれることで、より簡単になります。」
2つの柱：BlenderとKitsu
Cubeのパイプラインは2つのツールに支えられています。Blenderは、クリエイティブ面とテクニカルな制作作業を担います。そしてKitsuはCGWireが開発したオープンソースの制作トラッカーで、Axelが「プロジェクトの“集合的な記憶”」と呼ぶ役割を担っています。
Kitsuを知らないスタジオ向けに説明すると、KitsuはWebベースの制作管理ツールで、制作期間を通してすべてのアセットやショットのステータスを追跡します。アーティストやスーパーバイザーは、あるアセットがモデリング中なのか、検証待ちなのか、下流工程で使用できる状態なのかを把握するために利用します。CubeにおいてKitsuは、特定の瞬間におけるあらゆるアセットの到達状況を示す、権威ある唯一の情報源です。
「Kitsuは、プロジェクトの“集合的な記憶”です」とAxelは言いました。「すべてのアセット、すべてのショット、そして制作全体の状態を把握しています。」
パイプラインには他のツールも含まれています。Mayaはときどき車のモデリングを担当します。HoudiniはVFX作業でまだ登場しますが、CubeはますますBlenderのGeometry Nodesで置き換えています。Fusionはコンポジットの出力を担います。しかし、BlenderとKitsuがコアとなる入口であり、ほかのツールは別々に動くのではなく、それらにフィードしていく形です。
2つのスペースの物語
Kitsuがアセットを作成すると、Cubeのパイプラインは2つの明確な作業エリアに分岐します。
1つ目はユーザースペースで、制作のすべてのステップと、段階的なバージョンが格納されます。ここでアーティストが日々の作業を行い、Kitsuと直接つながっています。Kitsuは、セットが検証済みか、レビュー中か、承認待ちかを追跡します。制作において重要となるステータス変更はすべて、ここで発生します。
2つ目はプッシュスペースです。ここでは、アセットが完全に検証される前であっても、下流工程で利用できる状態にしておきます。Axelの言葉を借りると、プッシュスペースにあるアセットは「次の段階へ進むのに十分“健全”で、その後も更新できるが、破壊的ではない」状態です。重要なのは、このスペースがKitsuと通信しないことです。形式的なトラッキングのためというより、連続性を保つための独立した実務レイヤーとして設計されています。
プッシュスペースのBlenderファイルと並行して、CubeはJSONのディスクリプタファイルもプッシュします。これらには、メッシュ名、頂点数、サブディビジョンの指示など、メタデータが含まれます。要するに、各Blenderファイルの中身を機械が読める形で記述したものです。
レベル・オブ・ディテール（LOD）システム：制作の基本に立ち返る
Cubeのアプローチの真の核は、レベル・オブ・ディテール（LOD）システムです。技術的な都合に合わせて作るのではなく、各制作ステージで実際に何が必要かを起点に設計したのです。
- レイアウトでは、アーティストはショットをフレーミングして、セットを整える必要があります。アセットがどう見えるかを把握することは必要ですが、最終レンダリング品質までは不要です。カメラ操作の自由度は必要ですが、キャラクターや小物は比較的軽量でも構いません。
- アニメーションでは、良いフレームレートを維持できるほどシーンが軽くあるべきです。遅延しないシーンはより良くアニメートでき、それがアニメーターの作業品質に直結します。
- レンダリングでは、論理が完全に反転します。アニメーションは固定されてベイクされます。視覚品質が最優先となり、すべてが最大の定義度へ引き上げられます。
Cubeはこれを、モデリング、シェーディング、リギングの3次元にまたがる複数レベルとして、具体的なシステムに落とし込みました。
モデリング側では、ベースメッシュが中心に置かれます。これは、モデラー、制作、ディレクターによって検証されたリトポロジー版です。ディテールを上げると、レンダリング用のサブディバイド版や、さらに変位（ディスプレイスメント）を備えたよりサブディバイドされた版にアクセスできます。逆に下げると、遠景用のデシメート版や、ボリュームが不要な非常に遠い背景のフィギュア用のフラットプレーンがあります。
シェーディング側では、同等のレンジがフラットプレーン画像から始まり、オブジェクトごとのカラー（実質的なシェーダーではなく色情報のみ）のモード、アニメーション用に最適化されたビューポートシェーダー、本番レンダリング用のフルレンダーシェーダー、そして最後に変位マップと高解像度テクスチャを備えた高度なシェーダーへと広がります。
リギングは少し異なります。リギングにおけるLODは、常に別ファイルというわけではなく、アセットをインポートする方法を指示する形であることが多いです。最も低いレベルでは、アセットはシーンに単に参照され、ロックされます。次に上がると、アーティストはオブジェクト単位でアクセスできるようになり、レイアウトのタイミング用のシンプルな「ショートリグ」、それからフルのアニメーションリグへ進みます。そして場合によっては、特定のショットでのみ使う専門的な重いリグも存在します。
理論から『Pfffirates』へ
このシステムを具体化するため、Axelは『Pfffirates』のプロジェクトを詳細に説明しました。『Pfffirates』の世界観には、インフレータブル（膨らませる）なプラスチック製キャラクターが登場し、そこで特有のシェーディング上の課題が生まれました。インフレータブルの表面に小さなシワを足すために、変位マップが必要になる場合があったのです。
各キャラクターについて、モデリングのLODレンジはリトポロジーされたベースメッシュ、変位対応版、中距離用のデシメート版、そして背景用のフラットプレーンを含みました。シェーディングのレンジは、プレーン画像から始まり、軽量なJPEGマップを使った基本シェーダーへ進みます（シングルメッシュのインフレータブルキャラクターでは、オブジェクトごとのカラーシェーディングだけだと扱いが難しいため必要でした）。その後、レンダリング用のシェーダー、そして変位対応のヘビーシェーダーへと続きます。
リギングでは、各キャラクターが5つのレベルを持っていました。純粋な参照（シーンにロックされる）、キャッシュとポジション参照を適用するためのオブジェクトレベルのインポート、ショートのレイアウトリグ、フルのアニメーションリグ、そして各キャラクター固有の特殊な“スーパーパワーリグ”です。この最後のレベルは、フレームレートコストのため、すべてのショットで読み込まれるわけではありません。
同じ構造は小物にも適用されます。小道具でありながらセットとしても機能するボートでさえ、同様のロジックに従いました。キャラクターの遊び場として使われるため、Cubeはボートを4段階のLODに制限し、より高い定義が必要な場合には別のセットドレッシング用アセットを使いました。
Ronald Reglagesで一括設定する
このLODシステムを実際の制作設定へ落とし込むのは、Cubeが社内で「Ronald Reglages」と呼んでいるツールを通じて行われます。対応する仕組みがないスタジオに例えるなら、グラフィカルなインターフェースを備えた“プロジェクト単位の設定ファイル”のようなものです。Blenderのバージョン、アドオンのバージョン、レンダーファームのキュー名、カメラ命名の慣習、そして最も重要なのは、各アセット種別を各パイプラインステップで、どのLODレベルとして読み込むべきかを正確に定義するセクションです。
レイアウトでは、Ronald Reglagesは、セットドレッシング用にセットをオブジェクトレベルで読み込むこと、キャラクターや小物は基本リグ付きで読み込むことを指示します。一方でカメラはフルリグで読み込みます。カメラの動きはこの段階で確定させる必要があるためです。レンダリングでは、セットはファイルサイズを扱いやすくするため参照として入ってくる一方、キャラクターと小物は修飾（モディファイア）としてサブディビジョンなどを適用できるよう、オブジェクトレベルで入ってきます。
「これらはすべて、プロジェクトや各ステップごとに調整できます」とAxelは指摘しました。彼は、控えているXilamのレーシングカー案件の例を挙げました。そこでは最初からフルリグが必要になる可能性が高いからです。車両の中にデフォルトポーズのままキャラクターを配置すると、制作物をレビューするクライアントが混乱するからです。
ショット単位の非破壊オーバーライド
Axelが述べた、実務的に非常に強力な機能の1つが、ショットごと、またはバッチでLOD設定をオーバーライドできることだといいます。しかも、作業を失うことはありません。
レイアウトからアニメーションへ移行するとき、アーティストはすべてのリグをより高い定義度のレベルへ一括アップグレードできます。個々のショットの中では、アセットマネージャーが、現在のLODとともにすべてのアセットを一覧表示し、アーティストが個別の要素をアップグレード／ダウングレードできます。たとえば、フロントの手前にある1本のヤシの木だけがフレーミング検証のために少し高いモデリングレベルを必要とする場合、その1要素だけをアップグレードし、他はより軽いレイアウト設定のままにできます。
決定的なポイントは、このプロセスが非破壊であることです。アセットのリグレベルが変わると、システムはアニメーションのアクションデータと制約情報を保存し、新しいリグのバージョンに再適用します。これをきれいに機能させるには、リグのバージョン間でボーン名を一致させる必要があり、ダウングレードでは不可避的にある程度のデータ損失が起きますが、システムは可能な限り保持します。
次の段階へ：Geometry Nodes
Piggy BuilderはCubeが最も最近完成させたシリーズですが、彼らはBlenderのGeometry Nodesを使った、より手続き（プロシージャル）的なアプローチへ移行し始めました。
LODごとに別々のBlenderファイルを維持するのではなく、Cubeはすべてのレベルを1つのマスターシーンファイルへ統合しました。別ファイルはディスク上にも存在し、それをマスターシーンへインポートしますが、そこから先はGeometry Nodesによって、カメラからの距離やアクション内での役割に応じて異なるLODレンジを適用しながら、セットを手続き的に組み立てられます。ショットレベルで追加されるマイクロリグは、シーン側で必要とされる内容に応じて要素を動かし、Geometry Nodesの挙動を動的に再定義します。
その代償はメモリです。すべての表現が同時に読み込まれるため、RAM使用量は明確に増え、シーンのオープン時間は長くなります。「RAMのコストは実際にかかりました。でも、アーティストにとって使いやすさが上がることを考えれば、それだけの価値はありました。彼らは本当に楽しみながら、心から美しいセットを作れるようになったんです。」
目標は、このアプローチを今後のすべてのセットパイプラインに、きちんと統合していくことです。
主要なスタジオの学び
Axelは、講演をシステム全体を3つの原則に要約して締めくくりました。
- 1つ目は、「明確な唯一の情報源」を持つことです。CubeにおいてそれはKitsuです。すべてのアセットのステータス、すべてのショットのステータス、そして制作上の意思決定はそこに集約されています。アーティストは、何かがどこにあるのかを推測する必要がありません。
- 2つ目は、「制作ニーズに適応するアセットを作る」ことです。LODシステムは技術的に“便利だから”という理由ではなく、レイアウト、アニメーション、レンダリングが本当に別々のものを必要とするから存在します。その柔軟性を最初から組み込むことで、各工程でのスローダウンを防げます。
- 3つ目は、「パイプラインを生きた投資として扱う」ことです。Cubeでは、各制作が共有インフラに何かしらの改善を積み上げています。Tangranimoで行った作業が、Pfffiratesをやりやすくしました。Pfffiratesで行った作業が、7 Bearsをより扱いやすくしました。各プロジェクトを“新規スタート”として捉えるスタジオは、この複利的な価値をまったく手放してしまうことになります。
よりプロフェッショナルな制作実践へ向かうアニメーションスタジオにとって、Cubeの経験が示す明確な主張があります。重要なのはツールそのものよりも、それらの背後にある哲学だということです。Kitsuだけではパイプラインは自動的に安定しません。パイプラインを安定させるのは、すべてのアセットに対して明確な状態を定義し、それらの状態を一貫して伝達し、各ステップで制作ニーズに合ったワークフローを設計するという規律です。すべての工程に同じ「完了」の定義を押し付けるのではありません。そこでKitsuが大いに役立ちます。その柔軟なアーキテクチャとオープンソースであることにより、対応力が高いからです。
