>   >  痴山紘史の日本CG見聞録:第6回:レンダラ様が気持ち良く働ける、理想的なデータのながれを検証する
第6回:レンダラ様が気持ち良く働ける、理想的なデータのながれを検証する

第6回:レンダラ様が気持ち良く働ける、理想的なデータのながれを検証する

みなさんこんにちは。以前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国発祥の技術なので対応が遅れるのはしかたないですね。ただ、まったく手がないわけでもないようです。例えば、LumaPicturesusd-arnoldを開発しています。また、rodeofxOpenWalterを開発しています。このようなサードパーティーの開発したソフトウェアを使用すれば、より良い環境をつくることができるかもしれません。


・Gafferからのレンダリング

Gafferでも.abcや.usdを使ってレンダリングを行えることは前回確認しました。では、ここでレンダラに渡される情報がどうなっているのかも確認してみましょう。GafferではArnold Renderノードの実行モードをScene Descriptionに変更することで、.assファイルを出力できます。


出力された.assファイルの中身を見てみると、ジオメトリが展開されていて.abcファイルを参照するようには書かれていません。これはしかたないなと思う反面ちょっと残念です。

それから、どうやらImage Engine内ではAlembicを使用していないようです。開発チームとしてはAlmbicもきちんとサポートしてくれていますが、細かいところでの漏れはあるかもしれません。そのような場合は開発チームとコンタクトをとって問題解決をしていくようにしましょう。

次ページ:
現実的な落としどころを探る

その他の連載