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

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

現実的な落としどころを探る

理想的なゴールと、今ある環境で実現できる内容が一通り手元に揃いました。これらを眺めながら、現時点で実現可能なながれを考えていきます。

まず、レンダラは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月末を予定しております。

プロフィール

  • 痴山紘史
    日本CGサービス(JCGS) 代表

    大学卒業後、株式会社IMAGICA入社。放送局向けリアルタイムCGシステムの構築・運用に携わる。その後、株式会社リンクス・デジワークスにて映画・ゲームなどの映像制作に携わる。2010年独立、現職。映像制作プロダクション向けのパイプラインの開発と提供を行なっている。新人パパ。娘かわいい。
    @chiyama

その他の連載