＜2＞内製フレームワークが支えた圧倒的なクオリティと物量
Image EngineはR&Dに強いスタジオで、アーティストの使用するツールの多くがインハウスのものだという。この素地を最大限に活用し、本件では技術的な面で徹底的な自動化・簡易化を実施、それに伴い、スーパーバイジングのやりかた、アーティストの仕事のしかたの変更も徹底して行われた。
技術面で特筆すべきは、Image Engineが誇る内製のVFXフレームワーク「Gaffer」の存在だ。ノードベースでデータのながれを定義・テンプレート化でき、アーティストをクリエイティブ以外のこまごまとした仕事から解放、これまでの同社のVFX業務を力強く支えてきた。本件では一歩踏み込んで、GafferとSHOTGUNを連携。主要なショット（"keyShot"）とそのライトリグを流用できるショット（"ChildShot"）をSHOTGUN上でタグ付けしておくことで、keyShotがファイナルになった時点で「社内パイプラインがSHOTGUNからChildShot情報を取得→Gafferテンプレートを使用してChildShotをレンダリング」というながれを自動化した。これによって、360ショットにおよぶライティング・レンダリング作業を約6名という少人数で成し遂げたという。
Introduction to Gaffer - GafferBot Lighting and LookDev／「Gaffer」は「照明係、おやっさん」といった意味。オープンソースで、ダウンロードすれば誰でも使用可能となっており、Linux版、Mac OS版がリリースされている
このライティング関連のフローについては、R＆Dチームが1年程度を費やして開発中であったものを使用。本来はあと6ヶ月ほどの開発期間を経て投入予定だったが、本作で実験的に稼働することとなった。「ライティングではテンプレートの使用を徹底しました。Gafferのテンプレートのアイデアは工程の自動化を進める中で浮上してきたものです。弊社ではここ数年、各部署のデータを『バンドル』というパッケージにしてやりとりしていました。ここにレンダリングしてほしいアニメーションやカメラ、エフェクトなどを梱包して出荷します。今回は、新しいバージョンのバンドルが送られてきたらテンプレートに沿って自動でレンダリングし、さらにSHOTGUNにデイリーを作成、アーティストやスーパーバイザーはこれを見ることで実作業前に必要な作業を洗い出すことができるようになりました」。
「このシステムの導入により、ライティングアーティストは各シークエンスに対してマスターライティングを行い、自動でシークエンス内の各カットのレンダリング→デイリーの作成、レビューを進めてから各カット内のライティングを更新するという工程を築くことができました。時間・予算の節約になっただけでなく、データの確認・更新などに煩わされることなくクリエイティブな部分に時間を割くことができるようになり、さらなるクオリティ向上に努めることができたのです」。
Gafferで組まれたノードのテンプレート
また、様々な部署で制作されるデータについても、クオリティチェック用のレンダリングは自動的に行われるようになっている。「Gafferがなかったらプロジェクトは終わらなかったと思いますね（苦笑）。それ以外にもシステムに委ねられる部分はすべて自動化できるよう徹底的に洗い出しました。また、社内に翻訳家を増員してコミュニケーションの円滑化にも努めています。とにかく、アーティストたちがクリエイティブなタスクに集中できるよう可能な限り努力しています」。
レンダラに関しては、Image Engineでは長年3Delightを使用している。ただしボリュームのレンダリングに関しては、もともと使用していたMantra（Houdiniに付属するレンダラ）から、『ジュラシック・ワールド』以降3Delightのパイプラインに切り替えたばかりで、大規模にエフェクトをレンダリングするという点では初のプロジェクトとなったそうだ。「想像したよりもレンダリング時間がかかってしまう箇所もありましたが、社内でVDBシェーダを書き直すなどの対応を経て、最終的には大規模破壊でもそこまで重たくならずにレンダリングすることができるようになりました」。
ライティングまで完了した状態（上）とコンポジットを施した完成映像（下）
＜3＞つくり込みの最適化を徹底したアセット制作
© 2016 SQUARE ENIX CO., LTD. All Rights Reserved.
他方、アセットのデータ仕様に関してはいくぶんかの困難があったようだ。第2BDから提供されたアセットはUVが0-1スペースに収まる"トラディショナルな"UVレイアウトだったが、Image EngineではUVが重ならないようUDIMを多用している。これは最終的なシェーダ数を減らすためにマテリアルごとにシェーディングを行なっているからだ。「特にシェーダ側でテクスチャをアニメーションさせている場合は、UVのポジションを変えてしまうと同じ結果が得られなくなってしまいます。このUVレイアウトのちがいをどのように弊社パイプラインに合わせるかの問題は、解決に少し時間がかかりました。可能な限りスクリプトで簡易化しましたが、最後はどうしてもアーティストの手作業が発生しました」。
冒頭にも触れた通り制作すべきアセットは膨大であり、「どこでつくり込みを止めるか」の線引きが最大の課題となった。そこで、それぞれのアセットのどの部分がどのように見えるかという「つくり込むべき箇所」の情報を徹底的に洗い出して共有、そこからつくり込みを開始し、必要以上に踏み込まずにショットへ受け渡すという作業をくり返した。このつくり込み箇所の精査も、後述する「ポストビズ」工程が担っている。最終的には、「体の特定の部分のみがクローズアップに耐えられる」といったような、効率的なつくり込みのアセットが存在することとなった。
プリビズとポストビズの間の工程として進められたのがレイアウトだ。プリビズではおおまかなロケーションを固めつつ、ポストビズの前工程として「背景に何が見えるか」などを具体的に決定していった。「レイアウトを進める中で一番驚いたのは、第2BD側が広大な都市の地図を制作していたということです。そして『この道から撮影すると、これが見えるはず』とユニットディレクターの山本氏もその街並みを完全に把握していたことに感銘を受けました」。地図だけでなく、3D上でおおまかな地区の配置も済んでいたため、そこからImage Engine側で必要な地区の制作を進めていくことができた。
© 2016 SQUARE ENIX CO., LTD. All Rights Reserved.
都市の街並みは、ストーリーが進むにつれて破壊されていく。一度配置した建物アセットを、ストーリーの進行に合わせて置き換えるのでは作業量が膨らんでしまうことが懸念された。「置き換え作業を省くために、『背景のビルの電気の有無』・『燃えたような痕跡の有無』・『壁が壊れた跡の有無』を、シェーダとコーディネイトシステムで切り替えられるようワークフローを組みました。アーティストがシーンに対して『この地区は燃えてしまった』、『この地区はまだ電気が通っている』などのルールを設定すれば、あとはレンダリング時にそれが反映されるしくみになっており、大幅な省力化に成功しました」。とはいえ、カメラの近くに映るビルに関しては専用につくり込む必要があったが、それを加味しても350ショット分もの背景アセットを2〜3名のアーティストでこなしたというから素晴らしい。練度の高い職人技とImage Engineの誇るR＆D力が遺憾なく発揮された事例といえるだろう。
