『ソニック × シャドウ TOKYO MISSION』マーザ・アニメーションプラネットが使いこなすFlow Production TrackingとArnold

USDパイプラインへの新たな挑戦とハイブリッドなフロー構築

マーザが『ソニック３』で担当したのは作品のエンドロール後に流れる約２分間の１シークエンス。本編のドラマに幕を下ろした後に続きの物語を感じさせる予告編的な内容だ。

まず、本作におけるプロジェクトで最大の挑戦について聞くと、クライアントであるパラマウント社から提供された主要なアセットが、USD（Universal Scene Description）形式だったことが語られた。USDとは、ピクサー社が開発した3Dシーン記述のためのオープンソースフレームワークであり、大規模なVFXプロジェクトにおけるデータ連携と共同作業の効率を飛躍的に高める技術として注目されている。マーザにおいて導入の構想は以前からあったものの、他の開発との兼ね合いで実現には至っていなかったという。しかし、映画『ソニック・ザ・ヘッジホッグ』シリーズを通して少しずつ進めてきた新パイプラインへの移行期に、USD対応が必須要件として浮上。本作で初めて大規模なUSD運用をすることとなった。

「簡単なアセットから流れを全部テストして、少しずつ進めました。そしてクライアントから本番用のデータが大量に送られてきて、それをまたテストするという流れで、手探りで進めていった感じです」と木瀬氏は振り返る。USDデータの仕様そのものを解析しながら進めるという、まさに試行錯誤の連続だった。

木瀬孝晃氏：レイアウトSV

この新しい挑戦は、パイプラインの思想そのものにも変化をもたらした。従来はパイプライン側でタスクフローを定義し、アーティストの作業手順（ワークフロー）を導く形を取っていた。しかし、今回はUSDという明確なフレームワークが存在するため、パイプラインはデータ管理だけに徹する体制で行われた。データのパス管理など、ワークフローの根幹を支えるデータベースとしての機能に特化。アーティストが柔軟に作業を進められるよう、あえて介入を最小限に留めた。

ソニック3で採用されたレンダリングパイプライン

キャラクターレイアウトやアニメーション、カメラワークは操作性に優れたMayaで行い、その位置情報などをUSDファイルとしてSolaris（Houdini独自のレイアウト、ルックデブ、ライティング用環境）に渡し、最終的なレンダリングはArnoldで完結させる。このハイブリッドなフローを円滑に動かすため、データの受け渡しとバージョン管理に徹するという、成熟したパイプライン思想への進化がそこにはあった。マーザでは本作での経験を経てUSD取り扱いのレギュレーションを決めており、現在のウォーターフォール型のフロー設計からUSD的なタスク管理ができるよう拡張し、併用していきたい考えだという。

自社製レンダリングディスパッチャー"harvester"の進化

マーザでは長年、自社開発のレンダリングディスパッチャー（レンダーファームに計算処理を分配・管理するシステム）である「harvester」を運用してきた。しかし、プロジェクトの規模拡大に伴い旧バージョンは安定性に課題を抱え、一時は商用ソフトウェア「Deadline」への移行も検討されたという。だが、『ソニック3』の制作に合わせ、新たに開発された「harvester」のディペンデンシーを投入した。

「harvester」のディペンデンシー

その理由について松成氏は、長年の運用で培った依存関係（ディペンデンシー）制御のしやすさといった「使い慣れ」を挙げつつ、他にはない独自の利点を強調する。

「harvester」の最大のメリットは、その柔軟なリソース管理にある。「プロジェクトによってプライオリティを設定したり、ユーザーの使用頻度によってプライオリティが動的に変わったりするロジックがあります」と語る。吉沢氏。松成氏も「harvesterは全体的にリソースを平均的に使うようなロジックなので、これは他のディスパッチャーにはない特徴だと思います」と続ける。

多くのディスパッチャーがプロジェクトごとに計算リソースを固定的に割り当てるのに対し、「harvester」はレンダーファーム全体を一つの大きなプールと捉え、状況に応じて動的に優先度を調整する。これにより、急ぎのジョブや使用頻度の低いアーティストのジョブであっても、滞ることなくスムーズに処理が進む環境を実現している。これは、制作全体の効率とアーティストの満足度を直結させる、マーザならではの最適解と言えるだろう。

Arnoldレンダリングに際してはオンプレミス環境に加え、クラウドコンピューティングサービスのAmazon Web Services（AWS）を使用した。本作では進行の都合上、１日に起動するのが80台のときもあれば５台のときもあったという。３ヶ月という制作期間において、こうした使用機会のバラつきが発生するケースにおいては自社でレンダーサーバーを購入するよりも、都度で使用できるクラウドコンピューティングで賄う柔軟な方法が合理的だった。

秋重有希氏：システム アドミニストレーター

複雑化する要求に応える―ACEScgを軸としたカラーマネジメント戦略

従来のシリーズと比べて本作での大きな変化は、レンダリングのカラースペースだ。これまではARRI LogCリニアでレンダリングを行っていたが、今回は業界標準の色管理システムであるACES（Academy Color Encoding System）に準拠した「ACEScg」が採用された。

シリーズ当初からOCIOを使ったカラーマネージメント・フローを採用しており柔軟な対応が可能となっている。今作の変化のひとつとしてレンダリング・カラースペースが変更された。これまでは撮影カメラのカラースペースに合わせARRI LogC3リニアでレンダリングを行っていたが、今回から撮影カメラと共にグレーディングベースがARRI LogC4となった事に伴い仕様が変更され、業界標準の色管理システムであるACES（Academy Color Encoding System）に準拠した「ACEScg」が採用された。

ACES CENTRALよりAWG4 primaries
https://community.acescentral.com/t/arri-alexa-35-and-the-new-awg4/4466/3

具体的なフローとしては、まず制作の全工程をACEScgで統一。チェック用には一般的なPCモニタで正しく表示される「sRGB」に、クライアントへの確認用ムービーは放送規格である「Rec.709（ガンマ2.4）」に、そして最終的な納品データはカメラフォーマットに合わせた「ARRI LogC 4」へと、それぞれの用途に応じて正確な色変換を行う必要がある。多岐にわたる色変換をミスなく効率的に行うため、マーザは自社で専用のムービー生成ツールを開発。アーティストが所属する部署や用途に応じて、適切なカラースペースに変換されたデータを自動的に出力できる体制を整えた。

制作コミュニケーションの中心「Flow Production Tracking」と自社パイプライン「picore（パイコア）」の連携

プロジェクト管理のデファクトスタンダードツールである「Flow Production Tracking」（旧ShotGrid、Shotgun。以下本文では「Flow PT」と表記）。マーザでは『キャプテンハーロック』（2013年公開）制作時から導入した、日本国内での最初の大規模ユーザーだ。

ハリウッド大作ではグローバルな制作体制が行われるため、厳格なセキュリティが求められる。そこでマーザでは社内で進行する様々なプロジェクトから本作の「Flow PT」のみを切り離し、関係者のみがアクセスできる環境を構築して運用を行った。

『ソニック・ザ・ムービー』のCGスーパーバイザーはオーストラリアに拠点を置いている。この物理的な距離を超え、円滑な制作進行を実現する上で、Flow PTはコミュニケーションの中心的なハブとして機能した。まず、日本にいるアーティストが成果物をパブリッシュし、チェック用のプレイリストを作成・共有。海外のCGスーパーバイザーはFlow PTにログインし、そのプレイリスト上で直接内容を確認、ステータス更新やフィードバックのコメントを記入する。全てのやり取りがFlow PTの「ノート」機能上に記録されるため、誰がいつ、どのような指示を出したかが明確になる。

マーザのFlow PT活用の特徴は、自社開発の制作パイプライン「picore（パイコア）」との高度な連携にある。これはデータベースを中核とし、各種DCCツールと連携するツール群の総称で、新たに『ソニック３』から使用され始めた。このpicoreとFlow PTが密接に結びつくことで、制作フローの劇的な自動化が実現されている。

「アーティストがMayaやNukeなどのツールから成果物を社内のパイプラインにPublishすると同時にpicoreのデータとリンクし、Flow PTにも同じデータをパブリッシュさせるという流れです。パイプラインを使用しているプロジェクトでは、ほぼ全てのバージョン作成が全自動で行われます」（傘木氏）。

データがサーバーにアップロードされると同時に、プレビュー用のムービー（バージョン）が自動生成される。この一連のプロセスが完全に自動化されているため、アーティストはバージョンアップのたびに手動でムービーを作成し、アップロードするといった煩雑な作業から解放される。フィードバックやチェックはすべてFlow PTで行われるため、各アーティストが使用するツールに依存することはない。

マーザのアーティストたちは長年「Flow PT」を使い慣れているため、カスタマイズもページレイアウトのカスタマイズをする程度のみで、大きな変更はなかったという。マーザでは「チケットフロー」と呼ばれる、社内でアーティストとSVが遣り取りをするチケットがあり、それを本作の協力会社との遣り取りが可能になるよう実装し、レビューログや議事録の共有に活用を行なった。

ページレイアウトも個人の裁量に任されており、その結果として一度作成したパイプラインを長く使い続けられるという利点に繋がっている。マーザではアドミンとマネージャーの中間にあたる権限を作成し、その権限を持つPMが責任を持ってレイアウトやR&Dを行ない、ショットのステータスをどこまで見せるかカスタマイズした。アドミン権限自体はテクノロジーチームだけで保持し、要望があった際に、必要な権限を提案したり、Autodeskのサポートに相談をしたりしている。

プレイリストベースの納品自動化システム「SGデリバリー」

納品プロセスにおいてもFlow PTが活用されている。マーザではPMが納品対象のショットを決めることになっており、その際にFlow PTで作ったプレイリストをデリバリーデータに変換する。このときに使用されるツールが自社開発のシステム「SGデリバリー」だ。

ツールを実行すると、プレイリスト内の各ショットデータからEXR連番ファイルのパスを取得し、OpenImageIOやFFmpegといった画像・映像処理ライブラリを駆使して、カット名やレンズ情報などを記したスレート（タイトルカード）を生成。さらに、最終納品フォーマットであるARRI LogC 4への正確な色変換を行い、指定された命名規則に沿ったムービーファイルとして書き出す。これら一連の処理が、ボタン一つで完結する。「SGデリバリー」も、原型は以前から存在していたが実戦投入されたのは『ソニック３』から。

「以前は違うバージョンを送ってしまうといったミスがよくありましたが、プレイリストベースで対象のバージョンを確定することで、そういった間違いを防げるようになりました」（吉沢氏）。

マ―ザの映像美を長年支えるArnold

マーザの映像美を長年支えてきたレンダラーは「Arnold」。導入したのは、約13年も前のことだ。当時、先進的な技術に造詣の深いリーダーの主導のもと、様々なレンダラーが試された結果、最終的にArnoldが同社の制作基盤として定着した。その最大の魅力について、松成氏は「Arnoldはパストレーサーなので、純粋なレイトレーシングによって、以前のmental rayなどよりもリアルなグローバルイルミネーション（GI）などが元々作りやすい」とその物理ベースの正確性を挙げる。しかし、それ以上に重要なのは「一番大きいのはやはり『使い慣れている』という点でしょう」という言葉に集約される。長年培ってきたノウハウの蓄積が高品質な画作りを安定して行うための礎となっている。

本作では、USDをベースとしたHoudiniのSolaris環境からArnoldを運用する必要があった。その際、レンダリングを実行するプロセスとして二つの選択肢が浮上した。

一つは、Houdiniが標準で提供するレンダリング実行コマンド「husk」。そしてもう一つが、Autodesk提供のHoudini用Arnoldプラグイン（HtoA）に含まれる、よりArnoldに特化した実行コマンド「kick」である。当初は「husk」経由での運用を試みたが、「途中でメモリ消費が非常に厳しくなることが判明し、そんな時に、kickの方を試してみたらスムーズに処理できた」と松成氏は語る。最終的に、メモリ効率に優れた「kick」が採用された。

マ―ザのレンダリングスタイル「ベイクフロー」がもたらす効率化と安定化

マーザのレンダリングは、「ベイクフロー」で行われる。これは、MayaなどのDCCツールで作成した3Dシーンを直接レンダリングするのではなく、レンダリングに必要な情報だけをフレームごとに抽出・固定化（ベイク）した専用のファイル「.ass（Arnold Scene Source）」を書き出すこと。これはArnoldデータ、これをArnoldのコマンドラインレンダラー「kick」によって実際に画像へと変換する。

Mayaなどのシーンファイルには、キャラクターを動かすためのリグやコントローラーなど、レンダリングそのものには不要な情報が大量に含まれている。ベイクフローでは、これらの情報を全て削ぎ落とし、純粋な形状、シェーダー、ライティングといった描画に必要なデータだけで構成されるため、メモリ効率が良いとされる。

また、「.assファイル」は、特定のDCCアプリケーションに依存しない。そのため、MayaやHoudiniがインストールされていないレンダーファームでも、「kick」コマンドさえあればレンダリングを実行できる。これにより、ライセンスコストの最適化や、システム全体の安定性向上に繋がる。書き出された「.assファイル」は、再びMayaやHoudiniなどでリファレンスすることも可能だ。また、レンダリングで問題が発生した際も、シーンファイル全体を再読み込みする必要がなく、問題解決を迅速に行うことができる。

松成氏は、「弊社のMayaのリグは普段かなり重いことが多いのですが、ベイクフローを採用しているからこそ、アーティストが『メモリ効率が良い』と感じられるのだと思います。逆にデメリットを挙げるとすれば、フレームベースでの管理になるため、多少手間がかかるという点くらいでしょうか。ある程度の規模のプロジェクトになればなるほどメリットが出てくると思います」と、その効果を語る。

最後に本作のアーティスト・エンジニアから、CG業界の現状における課題や展望、そしてAutodeskに向けた要望を率直に語っていただいた。

松成隆正氏：テクノロジーチーム・リーダー

傘木奈都美氏：テクノロジーチーム・エンジニア

吉沢康晴氏：コンポジットSV