フル CG 長編アニメーションに適したレンダラとは

2009 年に行われたパイロット版「RITA」完成後（※第 1 回を参照）、MARZA ANIMATION PLANET（以下、MARZA）では、本制作に向けてプリプロダクションを行う時間が半年ほど設けられた。その一環として、当時の MARZA が主に使用していた RenderMan から次世代に向けた新たなレンダラの模索が始められた。
「世界的なレイトレーサーへの移行の波もありましたが、自分たちの環境や目指すルックを実現する上で、最適なレンダラを選定することが目的でした」と、レンダラのリサーチをリードした荒川孝宏テクニカル・ディレクターはふり返る。調査期間は約 3 ヶ月、本制作にあたり、MARZA は約 900 台、10,000 コアという日本随一と言っても過言ではない規模のレンダーファームを導入したが（後述）、その根底にあるのはハリウッドクオリティを日本の現場で実現するということ。ゆえにレンダラについても、単純なコストパフォーマンスの追求ではなく描画クオリティ、その中でもこれまで MARZA がこだわってきたヘアの表現力について注力しながら様々な検証が行われたという。

Arnold Showreel July 2013

比較対象となったのは、これまでメインとしてきた RenderMan 、社内の別プロジェクトにおいて確かな成果を上げていた V-Ray for Maya 、そして最終的に採用された Arnold の 3 レンダラであった。
「調査を行なった 2010 年時点では、日本ではまだ Arnold のリセラーが存在せず、開発元と直接交渉するほかありませんでした。ですが、当社には欧米の商慣習に精通するスタッフが在籍していること、そして開発元の Solid Angle が柔軟に対応してくれたことから候補に加えました」（荒川氏）。

検証方法は、「RITA」から屋外、屋内、キャラクター寄り、モブなどいくつかのカットを選定し、「RITA」（RenderMan）のデータから各レンダラごとにチューニングを行なった上で、V-Ray と Arnold の双方でライティングとコンポジットワークが試行された。「そして一連の結果の下、本番の総尺で描画した場合のレンダリングコストが見積もられた。
「コストパフォーマンスの面では V-Ray が優位でしたが、Arnold ではマシンパワーは求められるもののデザイナーの作業効率が非常に良く、レンダリング結果のクオリティにおいて優れた結果を得ることができました。これまで RenderMan でアセットやシェーディングの開発をしていたのですが、Arnold はそれらの技術が応用しやすく、開発の面でも優位性を感じました」（荒川氏）。
また、当時の V-Ray for Maya ではヘアの表現力において MARZA が求める域には達していなかったが、一方の Arnold では RenderMan で培ってきた一連の技法をそのまま転用できたことも大きかったという。検証結果は、荒川氏によって 20 ページにわたるレポートにまとめられ、最終的に Arnold の導入が決定した。
「本制作の際には、レンダリングは 1 フレームあたり上限 8 時間というルールを定めました。 最終的には 20 ～ 30 時間も要するジョブも出てきましたが、ショット単位で調整することでレンダリングの終了待ちで作業ができない、といった問題は発生しませんでしたね」（竹内謙吾CGスーパーバイザー）。

幅広い観点からのリサーチと検証
レンダラの検証は、上図にある7つの指標の下で進められた。＜1＞と＜2＞はデザイナーレベルのソフトウェアの使用検証であり、＜3＞～＜5＞は TD やテクノロジーレベルでのカスタム性や別ソフトとの相性に関する検証、そして＜6＞と＜7＞はマネジメントレベルでのコスト、実運用としての検証となる。注目したいのは、＜8＞の開発元サポートだ。インハウスでカスタマイズすることを前提とした MARZA の運用方法では、開発元がどの程度までオープンに技術的サポートが可能か、どれだけスピーディに対応ができるか、といった部分まで評価対象にしているのが興味深い

© LEIJI MATSUMOTO / CAPTAIN HARLOCK Film Partners
Arnold の優位性
Arnold の強みは、非常に少ないレイヤー（レンダーパス）数で目指すルックが得られることだという。プリプロで行われた検証結果では、RenderMan が 20 レイヤー、V-Ray が 6 レイヤーに対して Arnold はわずか 2 レイヤー。つまりキャラクターと背景のパスという切り分けだけでレンダリングを行えるということだ。本作のように非常にハイクオリティな映像表現の場合、一般的に複数のパスを書き出し、コンポジットで調整していくものが王道と言えるが、素材レベルでのクオリティがすでに十分に高いため、結果としてプレビューが早く、画づくりのトライ＆エラーを数多く行える。また、本文で触れた通り Arnold では、MARZA がこれまで RenderMan で使用してきた veFur のアルゴリズムをスムーズに転用できたため、キャラクターと毛をひとまとめにレンダリングできたことも導入の大きな決め手となったそうだ。画像は、本編に登場する火星都市のロングショット。カメラワークとの兼ね合いで景観はフル 3D で作成されたため、1 フレームあたりのレンダリング時間が 20 時間を超える、ひときわ高負荷のショットになったとのこと

section 02：Management
長期的かつ安定的にハイクオリティを保つために

続いて、『キャプテンハーロック』の組織編成とプロダクション・マネジメントをみていこう。近年、3DCG 表現の高度・複雑化に伴い、制作進行の重要性が高まっている。本プロジェクトにおいて、MARZA はどのような管理体制を構築・運用していたのだろうか。

左から、宮本 佳プロダクション・マネージャー、三井智博氏、千葉隆司氏、森下健太郎氏、橋本典明氏、高橋あゆみ氏、槇野厚一郎氏、以上マネジメントチーム中核スタッフ

1 日のワークフローを明確に定め制作を安定化させる

クランチタイムは 150 名規模に達したそうだが、平均して約 100 名ほどの組織を、宮本 佳プロダクション・マネージャーの下に 7 名のプロダクション・アシスタントが 1 ～ 2 つのチームの進行管理をみるかたちで制作が進められた。
「当初は、Excel ベースでアセットや進行の管理を行なっていました。ですが、約 1,400 ショットという物量と各ショットに付随するあらゆる情報を管理し、共有する上ではどうしても限界がある。そこで途中から Shotgun を導入したのです」（宮本氏）。

Shotgun は、Double Negative／ダブルネガティブ や Blue Sky Studios／ブルースカイ をはじめ欧米の名だたるスタジオでも導入されている、映像制作に特化した Web ベースのプロジェクト管理ツールだ。アクセス権限に応じて、カットの情報や進捗、工数管理が行える。さらに、ユーザーごとのタスクの振り分けや進捗確認を関係者間で共有しながら制作が進められるようにもなっている。
「その他のツールも検討したのですが、イニシャルコストがかかり過ぎたり、柔軟性にかける、という問題がありました。その点、Shotgun は映像制作に特化して開発されているため、スムーズに導入することができました」（宮本氏）。

『キャプテンハーロック』組織図
全 12 部門に分かれて、約 100 名の規模で制作が行われた。注目したいのはアートとレイアウトが部門として確立されていること。スープが立っていない部門は竹内氏が直接監修した。アートワークに特化したチームを設けることでルックデブやコンセプトデザインを明確にし、本制作においてデザイナーが補完しなければいけない曖昧な部分を減らすことができる。そしてレイアウト部門を構えることによって、まずアニマティクスを作成し監督の OK をもらうことで、アニメーション工程における尺や構図の変更を極力減らすことができる。こうしたワークフローは日本ではまだ馴染みのない部分だが、制作規模が大きくなればなるほど、各チームの担当領域を明確にすることで生産性を上げることが可能になるのだ

さらに検索とフィルタリング機能が強力なこともメリットだという。
「Shotgun では一元的にデータベースで全ての情報を管理しているので、ヒューマンエラーによる情報のいきちがいや、申し忘れといった問題を格段に減らすことができました」（森下健太郎プロダクション・アシスタント）。
そして創り出される表現だけではなく、制作スタイルもワールドクラスが意識された。「監督チェックは週 2 回でしたが、何らかのデイリーが社内の 200 インチスクリーンの試写室で行われていました。そのほかにも、各チーム内でのチェックが日々で行われていましたが、チェックシステムを明確に定めることで 1 日のタイムテーブルにルールが生まれ、時間単位で行動ができるようになりました。われわれマネジメントチームにとっても格段に状況を把握しやすくなりましたね」（宮本氏）。
制作後半には、一部のショットワークを韓国の AZworks が担当することになったのに加え、外部パートナーが MARZA 内で作業を行うための サテライトオフィス と呼ばれるスペースが設けられたが、Shotgun をベースにした管理システムを構築したことで、最後まで過度なオーバーワークを生じさせることはなかったという。

１．Shotgun 特有の「チケット」、「ノート」によるデータ管理
Shotgun では全ての情報を「チケットとノート」と呼ばれるデータで管理しており、全チケットとノートに ID が付加される。この仕様によって全てのデータが一元管理され、データの検索やソート、各データの関係付けが容易に行える。また、各ユーザーごとにアクセス権限が設定できるため、ユーザーごとのコスト管理まで行えるほか、外部パートナーとのやりとりもシームレスに行える

２．スケジュール管理機能
各ショットの作業内容を基に生成されたガントチャートの例。作業工程ごとにスケジュールを作成し、各カットの進捗状況をひと目で確認できる。また、用途に応じてサムネイルを表示してデザイナーにとって見やすくしたり、全体の進捗状況だけを表示してマネジメント側から見やすいようにしたりといった変更も容易だという。映像制作用途に特化したShotgunならではの強みと言えるだろう

３．レビュー機能「Screening Room」
Shotgun 上のレビュー機能の UI。ユーザーごとにコメントやチェックバックが簡単にできる仕様となっている。動画の編集も手軽に行えるため、監督に提出するためのデータの選定から再生まで、効率良く動画データの準備が行える

section 03：In-House Technology
画づくりを支えてこその自社開発ツール

最後に、プロダクション・パイプラインを技術面からみていく。MARZA におけるテクノロジーチームの役割は、自社開発ツールによるクオリティと制作効率の向上だという。『キャプテンハーロック』でも大小様々なツールが開発され、アーティストの画づくりに効率化をもたらした。

左から、松成隆正氏、ギデ・ガエトン氏、堀口直孝 CTO、守随辰也氏、脇坂 拓氏、以上テクノロジーチーム中核スタッフ

実データと創造性の架け橋となる

本プロジェクトでは、デザイナー、マネジメント、テクノロジーという、各部門が意見をもちより、ルールを考案し、ルールをサポートするツールが開発されていった。その主たるものが「mzAssetManager」 と呼ばれる Maya 用のシーン管理ツールである。これは全データをワークフローごとに適切に管理し、全てのデータをアセットとして読み込み、保存できるようになっている。そしてワークフローの面では「AssetPack（アセットパック）」と呼ばれる新たな概念が用いられた。例えば、体や服、持ち物といったキャラクターを構成する各種モデルデータをアセット（実データ）として保存し、それらを包括したものを「AssetPack」というデータベース上にしか存在しない"概念"として扱うことで、アーティストが直感的にデータ管理を行うことを可能にした。
「デパートメントによって各アセットの必要なレベルがちがいます。モデリングチームは各パーツレベルでの修正が必要ですが、アニメーションチームではキャラクター全体としてアセットを管理したい。そこで AssetPack を用いることで各チームのニーズに応じてシーンデータを編集できるようになるのです」（堀口氏）。

PIPELINE DATA FLOW
『キャプテンハーロック』プロダクション・パイプラインのデータの流れを示した図。本作ではアニメーションおよびシミュレーションを終えたデータは「bake」という工程を経て、ポイントキャッシュのような Gto 形式のデータに変換される。それによって前半は Maya データを中心としたアニメーション制作を行い、後半は rig を含まず純粋なジオメトリだけになった Gto データを仲介にして Maya、Houdini、3ds Max、NUKE などでライティング、エフェクト、コンポジット作業を行うことができる。また、この図における bake 以外の工程がそれぞれのデパートメントになっているのがわかるだろう。これだけ多くのスタッフの手を行き来するワークフローだからこそ、テクニカルチームによるサポートが必須と言える

このように"パーツ"（Asset）ごとのデータの管理とそれをまとめる"パーツ"（AssetPack）という、各々のレベルのデータを個々にバージョン管理することで、合理的なデータベースによるファイル管理を実現した。
個々のデパートメント向けにも様々なツールが開発された。「HUBble（ハブル）」は、ライティング作業専用のシーン管理ツール、シーンごとのライティングやレンダリングデータを他のシーンにコピー＆ペーストし、Maya のデータを開くことなく直接ディスパッチャーにレンダリングジョブを投げられるというものだ。以前は、各アーティストが Maya のデータをいちいち開いていて、場合によってはシーンが展開されるまで 10 分以上も待たなければいけないこともあったそうだが、HUBble 導入後はデータ展開に要する時間は実質ゼロとなり、ライティングの作業効率は飛躍的に向上したそうだ。
HUBble を開発したギデ・ガエトン氏は、ライティングチームに専従して自らもショットワークを手がけたというが、チームに入り実作業に携わったからこそ、アーティストのニーズを適確に汲んだツールを開発することができたと語っている。これだけ大規模なプロジェクトでは全体的なスケジュールが読みづらく、制作期間の延長やマンパワーによる力技の巻き返し等の問題が発生しやすい。その中で、本作はさほど大きな問題も発生することなく無事完成に至ったという。
「2011 年の夏、プロジェクト開始までがテクノロジーチームの最大の山場でした。それまでの半年間、基幹部分のツール類を開発する時間をしっかりと確保できたことで、本制作時の問題を最小限に抑えられたと思っています」と、守随辰也氏はふり返る。Arnold についても言えるが、本プロジェクトでは一見回り道と思える手間暇を事前に行うことで本制作を効率的に行うことに成功している。
堀口氏いわく、MARZA のテクノロジーチームは、"画づくりを意識できるエンジニア集団"だという。プログラムを書くことが目的ではなく、画づくりにメリットをもたらすことを最優先に考えるからこそ、実用性の高い、デザイナーに歓迎されるツールが開発できるというわけだ。そして、適確な制作管理の下でアーティストたちはいかんなくそのクリエイティビティを発揮していく。これこそが MARZA のハイクオリティな画づくりの根幹となっているのだろう。

ある shot での Subscribe レベルから Scene File への展開例（Scene Construct）
『キャプテンハーロック』制作データの管理概念図。「Asset」は、Layout 用、Animation 用、Lighting 用など用途別に用意されている。さらに部位ごとのジオメトリやシェーダなどに細分化され、それぞれのバージョンが DB によって管理されている。それらの膨大な Asset をデザイナーが集めてシーンを構築することはほぼ不可能なため、実際には 1 つのキャラクターなどを構成するのに必要な Asset を集めたものを「AssetPack」と呼ばれる DB 上にだけ存在する抽象単位としてバージョン管理、アプルーブの管理、データチェックなどを行なっている。また、各ショットの DB にはどのキャラクターが何体必要なのかなどが管理されている「Subscribe 情報」というものが登録されており、これらのSubscribe 情報と AssetPack 情報から、Layout 用、Animation 用、Lighting 用など用途別の具体的な Asset ファイルに瞬時にブレイクダウンすることができるようになっている。パイプラインではこの仕組みを利用し、「Scene Constructor」と呼ばれるツール（「mzAssetManager」を構成する1ツール）を使用することによって、自動的にデパートメントごとに必要な Asset を集めたシーンファイルを Maya を介することなく生成することができる。また、そのままレンダリングサーバにジョブ投入することも可能なので、Lighting などでは、Maya のファイル I/O 時間をスキップしてアーティスティックな作業に集中することができる環境を実現している

インハウスツール 1：harvester
「harvester」と呼ばれる約 1,000 台のレンダリングサーバを統括的にコントロールするために開発されたディスパッチャーの UI（左図）。各ジョブがサブジョブのディペンデンシーをもちながら、スレッド数、メモリ使用量、ライセンス数などのリソース管理を行い、効率的にディスパッチを行えるようになっている。パイプラインではデータ変換や 出荷作業など、ファイル I/O に時間を消費してしまう作業の多くが harvester によって処理されている。右図グラフは、その稼働状況や CPU 稼働率などを監視しているグラフ（グラフ上段）とジョブ数の変化グラフ（グラフ下段）。一気に大量に投入されたジョブが、時間経過と共に効率的に消化されている様子が見てとれる

インハウスツール 2 mzAssetManager
Maya での作業環境。各ショットの Subscribe 情報を登録する UI（上図右上）と、その情報と AssetPack 情報を使用して実際のシーンファイルを Construct する UI（上図左上）。Construct 時に別バージョンを使用してシーンファイル生成を行いたいなどの細かい要求にも応える。そして、デザイナーのファイル I/O を担う AssetManager の UI と作業画面（上図下段）

インハウスツール 3：HUBble
HUBble と呼ばれる Lighting 作業用の Scene Constructor の UI。HUBble では、シーン生成はもちろん、シェーダアトリビュートやレンダリング設定などをショット間でコピーしたり、harvesterにレンダリングジョブを投入したりと、煩雑になりやすいショット作業を統合的に効率良く行えるようになっている。また、それらの作業は Maya のファイル I/O を介さずに行えるため、大量のレンダリング作業をストレスなく行うことができる