みなさんこんにちは。以前pixivで大きな話題になって単行本化された『映画大好きポンポさん』の続編が『映画大好きポンポさん2』として出版されました。前作の人気が出たのでそれに乗っかって出した気の抜けた作品かと思いきや、そんなことはまったくなく、全編気合いの入ったストーリーがミッシリと詰まっていてとても面白いので未読の方にはおすすめです。
個人的に「おおっ！！」となった部分はシナリオの発想方法をポンポさんがジーン君に教えているところです。「なるほどなぁ」と思うと共に「自分が記事を書くときにどうやって構成を考えていたっけ？」というのを振り返るいいきっかけになりました。
※ ちなみにこの情報は未読の方が知ってもネタばれにはならないのでご安心を :-)
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
これまでのふりかえり
前回まででUSDを使用してアプリケーション間のデータをやりとりするということをベースに、Mayaでアセット制作とレイアウトをし、GafferとArnoldでルックデヴ＆ライティング、そしてレンダリングを行うまでのながれを体験することができました。
Linux化や、Docker、USD、Gafferといった技術をいちから導入してレンダリングまで行うことができたのは大きな成果ではあるものの、ソフトウェアの制限や記事執筆時点での見識不足が原因で強引に乗り切った部分も多々あります。また、一通りやってみたからこそ見えてくる改良点もあります。そこで、これまでの総括として改めて映像制作のながれを整理し、見直しを行います。
映像制作には実写撮影やコンポジット、編集といったたくさんのプロセスがありますが、ここでは一旦横に置きます。今回はプリレンダーの3DCG映像制作、特にアセット制作からレンダリングまでのプロセスを考えます。これらは、前回までの本連載で一通り確認したところですね。
ゴールを決める
映像制作のながれを見直すにあたって、本記事では何を重視するのかゴールを決めます。
とっかかりとして、「3DCG映像を制作してお金を稼いでいる場合、最終的にお金に変換できる価値を生み出しているものは何か？」というところから考え始めます。プリレンダー作品の場合、間違いなくレンダリングされた成果物である連番画像になります。途中の制作プロセスがどれだけ素晴らしくても、モデルデータが綺麗でも、納品物である連番画像がきちんと生成でき、それがクライアントの要求を満たすものでなければ一銭の価値も生み出しません。では、連番画像を生成するのは誰でしょうか？ はい、レンダラです。レンダラの生成した画像をお金に換えて、われわれは作品をつくり生活をしているのです。レンダラが効率よく仕事できれば、その分コストが圧縮できます。一方で問題のあるデータをレンダラに処理させてしまうと、エラーが起きたり処理に時間がかかりロスが大きくなります。
つまりわれわれは、レンダラ様に気持ち良く働いてもらい、価値を生み出していただくための環境とデータを用意する下僕に過ぎないと言っても過言ではないのです。そのため、今回は下僕であるわれわれがレンダラ様に気持ち良くお仕事をしていただくためのながれをつくることを目標にします。
※ とは言っても、映像制作で最も高コストなのは人間なのでそのバランスを考えたりする必要があるため、実際にはもっと複雑なんですけど。
方針を決める
レンダラ様に気持ち良く働いていただくために何をすべきか考えます。
まずは、レンダラに渡すデータを極力綺麗に、シンプルにすることが挙げられます。DCCツールで制作されたデータは、不必要なゴミが残っていたり、アプリケーションやプラグインのバグで不正なデータが生成されていたりします。このようなデータが残ったままでは、いろいろなところに無理がかかって気持ち良く働いていただくことはできません。レンダリングをするとエラーになるのに、新しいシーンにマージしたらなぜかレンダリングが回るようになったという経験をしたことのある方も多いでしょう。
次に、レンダラが処理しやすい形でデータを渡すことが挙げられます。モデルデータやテクスチャデータ、それからキャッシュデータなどはレンダラ推奨の形式に変換することで、最高のパフォーマンスを発揮してくれます。キャッシュデータであれば最近のレンダラならばAlembicやOpenVDBに対応していることが多いです。日本のプロダクションで広く採用されているV-Rayの場合、 vrmeshが以前からあるので使っている方も多いのではないでしょうか。また、RenderManの場合はUSDに対応しているため、より一貫性のあるながれをつくることができそうです。
また、レンダラの能力をフルに発揮するという点ではSubdivision SurfaceやDisplacement Shaderも有効利用していきたいところです。ただ、このあたりは今回の話の本筋から外れてくるので議論しないことにします。
理想的なながれ
前述の方針に従う場合、どのようなながれが理想的でしょうか。まずは、レンダラが直接扱うことができるデータ形式をながれの中心に据えるようにしましょう。その上で、レンダラが直接扱うことのできるデータを可能な限り上流工程で生成し、それ以降はそのデータを極力そのまま使い回すことができると良さそうです。データ変換を行えばその分手間がかかりますし、自動で行なったとしても処理時間やメモリ、ストレージを余計に消費することになります。また、管理するデータフォーマットが増えれば、それだけフローも複雑になりトラブルが起きやすくなります。
そこで、以下のようなながれを考えます。
アセット
・キャラクターなどのリグ付きアセットは、アプリケーションネイティブな形式で保持
・背景などのアニメーションをしないアセットは、AlembicやUSDのような共通フォーマットに変換
・シェーダ情報はモデルデータと分離してレンダラに近い部分で管理
ショット
・アニメーションを付け終わったら、共通フォーマットでキャッシュデータに変換して保存。その際、リグなどの余分な情報は極力消しておく
・ライティング以降は共通フォーマットのデータを読み込んで処理
・レンダラに渡す際も、共通フォーマットのデータをそのまま使用
ショットのアニメーション制作時に使用するリグ付きアセットのように、後から加工されるものは中間データと考えます。このようなデータは、アプリケーションで扱いやすい形式で保存するのが良いでしょう。エフェクト用のセットアップも同様です。それに対して、レンダラで使用されるデータは成果物とし、共通フォーマットで格納するようにします。
検証
以上の内容が実現できるか、実際の環境で検証を行なっていきます。現実世界は理想とは程遠く、カタログ上では実装されている機能がまったく使い物にならなかったり、ある日仕様が変わって動かなくなって困ってしまうことが多々あります。理想と現実のギャップを如何に埋めるかが楽しいところであり、胃の痛いところでもあります。
Gafferを使用してレンダリングする場合、上記のながれはある程度行えることが確認できているので、もう少し細かい部分の検証がメインになります。
・ArnoldやMtoAの対応状況
ArnoldはAlembicを直接読み込むことができ、Mayaも2018 Update3から対応しています。gpuCacheノードで.abcファイルを指定するとArnoldが直接処理できるようになっています。
この機能がきちんと動いているか確認するためには、Render SettingsのRender TypeをExport Assに変えてレンダリングします。すると、画像の代わりに.assファイルが出力されるので中を確認します。.assファイル内には以下の記述があり、確かにArnoldで直接処理されていることがわかります。また、フレーム指定も行われているため、アニメーションに対応していることも確認できます。
（前略）
alembic
{
name Zombie_OnFire_2B
visibility 255
matrix
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
id 1148746815
namespace ""
filename "/home/chiyama/Documents/Zombie_OnFire_2B.abc"
nameprefix ""
objectpath "/"
frame 50
fps 24
shutter_start 0
shutter_end 1
（後略）
.assファイルのサイズを比較すると、MayaでGPUCacheを使用して読み込んだ場合は3KB、.abcファイルをリファレンスした場合は1,418KBとなりました。もちろん、レンダリング時には.abcファイルも読み込むので3KBでレンダリングが終わるわけではないですが、.abcファイルは必要になったときに初めて読み込まれるため、レンダリングが始まるまでの処理時間やメモリの使用量の軽減、ひいてはシステム全体への負荷の軽減につなげることができます。
ArnoldはUSDには未対応です。OpenSubdivといい、USDといい、元がRenderMan国発祥の技術なので対応が遅れるのはしかたないですね。ただ、まったく手がないわけでもないようです。例えば、LumaPicturesがusd-arnoldを開発しています。また、rodeofxも OpenWalterを開発しています。このようなサードパーティーの開発したソフトウェアを使用すれば、より良い環境をつくることができるかもしれません。
・Gafferからのレンダリング
Gafferでも.abcや.usdを使ってレンダリングを行えることは前回確認しました。では、ここでレンダラに渡される情報がどうなっているのかも確認してみましょう。GafferではArnold Renderノードの実行モードをScene Descriptionに変更することで、.assファイルを出力できます。
出力された.assファイルの中身を見てみると、ジオメトリが展開されていて.abcファイルを参照するようには書かれていません。これはしかたないなと思う反面ちょっと残念です。
それから、どうやらImage Engine内ではAlembicを使用していないようです。開発チームとしてはAlmbicもきちんとサポートしてくれていますが、細かいところでの漏れはあるかもしれません。そのような場合は開発チームとコンタクトをとって問題解決をしていくようにしましょう。
[[SplitPage]]現実的な落としどころを探る
理想的なゴールと、今ある環境で実現できる内容が一通り手元に揃いました。これらを眺めながら、現時点で実現可能なながれを考えていきます。
まず、レンダラはArnoldを使用するとします。ArnoldではなくRenderManを使う場合、Alembicにこだわる必要がないので話がかなり変わってきます。もっとUSDを活用したものになるでしょう。
レンダラの次に大きな分岐点はGaffer（もしくはKATANA）を使用するかどうかです。Gafferを使用することでルックデヴやライティングを特定のアプリケーションから分離することができ、シェーダの管理やショットごとの調整も劇的にやりやすくなります。トラブルの温床、RenderLayerとも決別できることを泣いて喜ぶ人も多いのではないでしょうか。3ds Maxユーザーにとってはもっと影響が大きいです。Scene StateやState Setからお別れできるのです！！
反面、アセット制作からレンダリングまで、レンダラネイティブなものと同じデータを使うことを考えると、AlembicファイルをUSDシーン内で参照できないことと、Gafferから出力した.assファイル内でジオメトリが展開されてしまっていることが残念です。
もうひとつ、モデルデータとシェーダを分けてしまうことは、現状あまり行われていないので、アーティストからの強い反発が予想されます。特にアニメ調の作品を手がける場合、モデルデータとシェーダが密接に関わってくることが多いので注意が必要です。
・Gafferを使用するケース
USDシーン内でAlembicをリファレンスできるようにすることは、Gafferで対応する価値のある内容なので、必要であれば開発元にバグレポート（と、できればパッチ）を送り、きちんと対応して使用するのが良いでしょう。Arnoldにシーンデータを渡すときにジオメトリが展開されてしまうのは、アプリケーションの特性上しかたないのかなという気がします。ここにこだわるなら自前でGafferを改造して対応する必要がありそうです。この場合、Gaffer上でのノードの組み方にもいくつか制限を設ける必要があるかと思います。ここの仕様は、KATANAなどの別のアプリケーションではどうなっているのか気になるところです。
結局、Gaffer → Arnold間でジオメトリ情報が展開されてしまうことを良しとしてしまえば、その前段階は全てUSDで統一することもできそうです。少し気になるのはHairのようにサードパーティーのプラグインを使用して表現する少し特殊なデータの扱いです。もしUSDに上手く出力する方法が確立できなかったときは、Alembicを使用することになるかもしれません。いずれにしてもレンダリングをGaffer経由で行うと、シェーダの設定はアプリケーションとは関係なくなるので要注意と言えます。
この方法の場合、レンダラが処理しやすいような形でデータを渡すという当初目標は達成できませんが、ルックデヴやライティングでの取り回しのしやすさ（＝プロダクションでの人的コストの削減）を考えると、現時点ではベターな選択肢だろうと思います。
・Gafferを使用しないケース
Gafferを使用せずルックデヴやライティングまでMayaで行う場合、Alembicデータを極力使い回す方法が採用できます。この場合、MayaでGPU cacheを読み込むとひとつのノードとして扱われてしまうため、シェーダの管理方法を検討する必要があります。ここさえ固めることができれば、アニメーション制作後、Alembicでジオメトリキャッシュ化してライティングを行い、ArnoldでもAlembicデータをそのまま使ってレンダリングするながれをつくることができます。
この方法の場合、シェーダ周りの管理が最も困る部分なので悩ましいところです。ただ、普段行なっていることと基本的に変わらないので、とりあえずは良いんじゃないかという割り切りをするのも良い気がします。
まとめ
今回は理想的な目標を決め、現在手元にある技術の範囲内で実現可能なケースを考えてみました。ここから先は実際に手を動かして環境をつくり、検証と改良を繰り返していく段階になります。Gafferを使用してもしなくても、何となくモヤッとする、理想的な環境にはまだまだ程遠いなと感じる状況ですが、理想と現実のギャップを埋めようとすると大体こんな感じになります。
しかし世界中の開発者が似たような悩みをもち、それを解決するために日々がんばっているので、状況はものすごい勢いで変化しています。実際、MayaからArnoldでレンダリングするときに.abcをリファレンスできる機能はホカホカのできたてですからね。技術をきちんとキャッチアップし、誰かが見つけた解決方法を取り入れられる体制を整えていれば、今回上がった問題も、もしかしたら近いうちに解決策が見つかるかもしれませんし、オープンソースソフトウェアであれば自分が貢献することも可能なのです。
次回予告
次回は心機一転して新しいテーマに取り組んでいきます。CG制作を行う場合、必ずと言って良いほどレンダーファームを構築し、レンダリングをそちらに任せるようにします。しかし、それだけではもったいないです。せっかく高性能な計算機を大量に用意するのであれば、もっとほかのことにも活用していきたいですよね。そのための技術について議論を進めていきたいと思います。
第7回の公開は、2018年11月末を予定しております。
プロフィール
