Maya 2017から標準搭載となったArnoldをはじめ、対応レンダラの多さでは群を抜くMaya。本稿ではコロッサスの澤田友明氏に、長年様々なレンダラの検証に携わってきた立場からテストを実施してもらった。

※本記事は月刊「CGWORLD + digital video」vol. 224(2017年4月号)からの転載となります

TEXT_澤田友明(コロッサス
広告やBtoB関係のCG制作で長年R&Dを任され、グローバルイルミネーションレンダラが世に登場してきたころから3ds Max、Maya、その他アプリケーションのオリジナル、プラグインを問わず、様々なレンダラの検証を行なってきた。現在は株式会社コロッサスでCGディレクションやR&Dに携わる


EDIT_小村仁美 / Hitomi Komura(CGWORLD)、山田桃子 / Momoko Yamada

レンダラ2.0時代にMayaで使えるレンダラは?

1990年代初頭には新しいGIレンダラが台頭し、誰もがフォトリアルなレンダリングを得られる時代となったわけだが、2020年を目前とする今、単にフォトリアルなだけではなく、よりユーザーライクな操作性や現実的な処理速度を実現するレンダラの登場が、映像制作現場に変化をもたらしつつある。

ユーザーライクという点ではmental rayに変わってMayaに搭載されたArnoldが挙げられる。mental rayはGIレンダラ黎明期に登場し、Autodesk DCCツールの標準搭載レンダラとして広く使われてきたが、度重なるバージョンアップにより複雑で使いこなすことが難しいレンダラとなってしまった。Arnoldはその逆に、GIエンジンを一本化して複雑な設定項目を減らし、レンダラの調整というダウンタイムからアーティストを解放する新しいレンダラとして期待されている。

また、その一方、CPUに比べて単純な命令を素早くこなすことができるGPUの進化により、レンダリングの時間的制約から解放してくれるかもしれないGPUベースのレンダラが続々登場してきている。本稿では、それら「レンダラ2.0」と言うべき製品群と、老舗レンダラであるV-RayをMaya上で比較検証してみた。

テスト環境
● OS Windows 7 64bit
● CPU Intel Core i7-3770K 3.5GHz 4コア
● GPU Quadro 4000
● メモリ 32GB
● ストレージ 250GB SSD/2TB HDD
● 使用ソフト Maya 2017 Update 2/V-Ray 3.4.006/Arnold MtoA 1.4.1.2/OctaneRender 3.05.3/Redshift 2.0.81

CASE 01
単純なポリゴンで構成されたシーン

3つのポリゴンデータ、268万ポリゴンを1つのエリアライトでライティング
各レンダラの素性を確認する目的で、単純な物撮りライティングシーンを組んでみた。照明は頭上からのエリアライト1 灯。白背景による拡散反射光を利用。マテリアルは物理ベースシェーダを使用し、金、色つきガラス、カーペイント(レンダラプリセットがある場合はそれを使用)の質感を与えた。


設定のポイント

V-Ray


V-Rayのイメージサンプラーは3種類搭載されており、Adaptive(時間はかかるがノイズも少なく仕上がりが綺麗)、Adaptive subdivision(時間と品質の調整が容易)、Progressive(任意の時間までサンプリングを継続する)という特徴があるので、今回はAdaptive subdivisionを使用し、設定値をMin rate:2、Max rate:4とさせてもらった。GIはデフォルト設定のBrute forceとLight cacheを使用。システム設定はデフォルトから変更せず

Arnold

Arnoldのサンプリング数はデフォルトのまま。Ray DepthのDiffuseとRefractionのみそれぞれ4と6に増やしている。システムもデフォルトの値を使用

OctaneRender

OctaneRender(以下、Octane)のKernelはダイレクトライト、パストレーシング、PMCと3種類あるが、GIであるパストレーシングとPMCを使用。Octaneは設定したMaxサンプリング値に達するまでレンダリングを行うレンダラなので、他のレンダラの品質に合わせてサンプリング値を可変させている。Case 01の場合はMaxサンプル200。それ以外のパラメータはデフォルト値を使用

Redshift


Redshiftは飛びぬけて設定項目が多いのだが、サンプリングはデフォルトのまま。GIはIrradianceCacheとIrradiance Point Cloudを使用。Optとシステムはデフォルトのまま。メモリについてはレンダリングが途中で止まった場合のみ設定値を見直している

レンダリング結果

レンダリングサイズ:1,920×1,080



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

検証結果

レンダリング時間


4つのレンダラの中でもV-RayとRedshiftがアンバイアスタイプのGIエンジンを選択でき、それによって静止画であれば速度を稼げるため、レンダリング時間を見る限りは順当な結果になっていると思われる。RedshiftはGPUを活かしてレンダリング時間が最短となっているが、Octaneはレンダリング中のGPU使用率がなぜか8割程度に抑えられているため、用意したPCのハードスペックではパフォーマンスを出しきれていないと思われる。PMCとPath TraceモードではPMCの方が計算時間はかかるがレンダリングされた画像に差は見られなかったので、以下の検証はPath Traceモードのみとする

正しくレンダリングできているか

各レンダラのシェーダプリセットを使用した部分もあるため、色味などは若干異なっているがおおむね共通する結果が得られた。色付きガラスについては透過率の表現がCPUレンダラ(V-Ray、Arnold)とGPUレンダラ(Octane、Redshift)で異なる結果となっている。また、透過した光が床に影を落とす部分で、V-RayとOctaneにノイズが目立っている。

Maya上での扱いやすさ、表示状態

V-Ray、Arnold、RedshiftのPBRシェーダは共通したパラメータも多いため移行しやすいが、Octaneのシェーダは独自のノード群を使用する必要があるため、他のレンダラからの移植はかなり難しい。

次ページ:
CASE 02
高ポリゴン&大量オブジェクトシーン

[[SplitPage]]

CASE 02
高ポリゴン&大量オブジェクトシーン

24万もの個別のオブジェクトを用いた耐久ベンチマークテスト
レンダラの紹介記事では比較的簡易なシーンでテストされていることが多いが、それを鵜呑みにして業務で使用すると現実で痛い目をみることがある。そうならないために、Mayaの都市生成プラグインQTownを用いて大量の建物オブジェクトを用意し、実際にはどれくらいのシーンをレンダリングできるのかというレンダラにとっては大変負荷がかかるベンチマークテストを行なってみた。なお、このテストでは各レンダラが大量オブジェクトをレンダリングするための機能として搭載されているインスタンスやプロキシなど回避方法はいっさい使用を認めず、ガチンコ対決とした。


設定のポイント

各レンダラの設定は基本的にCase 01と同じ設定になっている。照明はイメージベースドライトを使用。マテリアルはMayaのランバートシェーダを与えている。

テストシーン詳細

  • シーンLv1
  • ポリゴン数:1,078万
  • オブジェクト数:80,600
  • シーンLv2
  • ポリゴン数:2,156万
  • オブジェクト数:161,200
  • シーンLv3
  • ポリゴン数:3,235万
  • オブジェクト数:241,800

レンダリング設定

  • V-Ray
  • Case 01と同じ
  • Arnold
  • Case 01と同じ
  • OctaneRender
  • Path Traceモードのみ。ライティングはシンプルなエクステリアシーンなのでMaxサンプルは100に下げた
  • Redshift
  • Case 01と同じ

レンダリング結果

レンダリングサイズ:1,920×1,080



  • V-Ray(シーンLv2)



  • Arnold(シーンLv3)



  • OctaneRender(539万ポリゴン、40,300オブジェクトシーン)



  • Redshift(シーンLv2)

検証結果

シーンレベルごとのレンダリング時間


グラフ上に値がない部分はレンダリングができなかったことを示す。32GBのメモリを搭載したPCで3,235万ポリゴンシーンをレンダリングできたのはArnoldのみ。V-Rayは2,156万ポリゴンシーンをレンダリングできたが、メモリをギリギリまで使用するので失敗する場合もあった。Octaneはさらに539万ポリゴンまで減らしたシーンでようやくレンダリングすることができた

レンダリング時間内訳


このような高ポリゴン、大量オブジェクトシーンではレンダリング時間といっても大きく2つに分けて費やされている。オブジェクトを計算可能な状態としてメモリ上に展開するジオメトリトランスポート時間と、実際のレンダリング時間である。それらを計測し比較してみた。ここからわかるように、このような高ポリゴン大量オブジェクトシーンではシンプルなレンダリングアルゴリズムを採用するArnoldが最も少ないメモリで速くレンダリングができる。V-Rayの場合はレンダリング自体は速いがメモリ転送効率が悪くレンダリングに入る前の時間もかなりかかっている。RedshiftはGPUメモリに収まりきらないようなシーンの場合はout-of-core機能を使って外部メモリにキャッシュを取ることができるが、そもそも外部メモリにも収まりきらない場合はレンダリングができなかった。またout-of-core機能を使った場合にはレンダリング速度が極端に低下し、GPUを利用しているメリットはないと言える。Octaneはout-of-core機能を搭載しているが、テクスチャキャッシュとしてしか機能せず、ジオメトリを外部メモリに渡す手段がないため、さらにサイズを減らしたシーンでしかレンダリングできなかった

また、実際レンダリングされた画像を比較し、品質を比べてみたのが下の画像だ。品質の比較はあくまで目安でしかない。レンダー設定を変えれば品質を良くすることはできるが、おのずとレンダリング時間もかかってしまう



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

次ページ:
CASE 03
複数のライトを使用したインテリアシーン

[[SplitPage]]

CASE 03
複数のライトを使用したインテリアシーン

業務での使用を想定したテスト
続いて、87個のエリアライト、53枚の4Kテクスチャ画像、148万ポリゴンのオブジェクト、GI全開という、実際の業務で使用される程度のインテリアシーンを使ってレンダリングテストを行なった。複数のエリアライトからの間接光が室内を照らす自然史博物館のモデルを用意し、テクスチャも4Kサイズのものを贅沢に使用。またレンダリング時に被写界深度計算を行い、さらに負荷をかけている。

設定のポイント

この場合も基本的にデフォルト設定を使用している。

  • V-Ray
  • Case 01と同じ
  • Arnold
  • Case 01と同じ
  • OctaneRender
  • Path Traceモードのみ。ライティングが複雑なインテリアシーンなのでMaxサンプルを2,000まで上げている
  • Redshift
  • Case 01と同じ

検証結果

レンダリング時間


正しくレンダリングできているか

ライトの照度パラメータやシェーダの設定が異なるため、限られた時間の中での調整ではまったく同じ画にすることはできなかったが、計算負荷としては同じレベルになっていたと思われる。ただし、Octaneだけは専用のスキンシェーダがないため(シェーダネットワークを駆使してSSSのようなものをつくることはできる)、恐竜の見え方が異なってしまったことを容認いただきたい。

Maya上での扱いやすさ、表示状態

ライト、マテリアルは各レンダラごとに異なるノードを使用するため、Maya上とはいえ各レンダラに対応するシーンに変換することは大変であった。特にOctaneはMayaのシェーダノードが使えないため、他のレンダラからのマテリアル移植には時間が必要となる。Octaneで最初からマテリアルを組む場合は慣れてしまえば問題ないと思われる。ライトに関してはPythonを使って自動的に各レンダラの専用ライトノードに入れ替えるようにした。

レンダリング結果

レンダリングサイズ:1,920×1,080



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

結果としては、Octaneを除いてはほぼ横並びのレンダリング時間となったことは興味深い。Quadro 4000程度のGPUではGPUレンダラとしてのメリットは発揮できなかったと言える。品質に関しては、アンバイアスなGIアルゴリズムを使用できるV-RayとRedshiftがノイズも少なく美しい。ただしアンバイアスなGIアルゴリズムは静止画用と考えておいた方が良いだろう。Arnoldもほぼノイズは気にならないが若干ファイアフライノイズがあるのでもう少し詰める必要がある。Octaneはまじめにパストレースするタイプのアルゴリズムなので、Maxサンプル2,000でもまだノイズが取りきれていない。インテリアシーンで使用するにはもっとパワーのあるGPUが必要だろう

次ページ:
EXTRA TEST
Mayaの各機能を正しくレンダリングできるか

[[SplitPage]]

EXTRA TEST
Mayaの各機能を正しくレンダリングできるか

Mayaの全てをレンダリングできるか!
レンダラの検証というとポリゴンシーンで行われることがほとんどだが、Mayaには様々な新機能やエフェクトなどがある。Mayaのプラグインというのならば、それらを正しくレンダリングできるかどうかを最後にテストしてみた。

設定のポイント

テストシーン詳細
● NURBSサーフェス+ビューポート
  サブディビジョンを使用した状態のポリゴン
● ヘア
● Fluidを用いた煙
● OpenVDBによるボリュームデータ
● Bifrostによる流体+Foamによる泡
● XGenによるプロシージャル形状

レンダリング設定
Case 01と同じ

レンダリング結果

レンダリングサイズ:640×540

NURBS+ビューポート サブディビジョン



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

ヘア



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

Fluid



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

OpenVDB



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

Bifrost+Foam



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

XGen



  • V-Ray



  • Arnold



  • OctaneRender



  • Redshift

検証結果

表にまとめると結果は下のようになった。▲について記述すると、Octaneは専用のヘアシェーダをもっていないため、Mixマテリアルでそれっぽいものをつくる必要がある。またRedshiftはXGenに対応しているとあるが、レンダリング結果はかなり異なったものとなった。Maya対応レンダラは数多いが、詳細に検証してみると今回のOctaneとRedshiftはまだまだ対応できていない機能がある。これからの改良に期待するか、あるいは静止画用途に限定して使用しても良いかもしれない。

正しくレンダリングできているか


検証を終えて

総合評価(10段階)


今回の検証ではGPUレンダラのスピードがどれほどのものかという点に期待をもたれた方も多いと思うが、検証に使用したハードではそこまでの性能差が出せなかった点が残念だ。その点についてだけはこちらのPR記事で検証しているので参考にしてほしい。しかしながら、比較的軽いシンプルなシーンではGPUレンダラの速さを体感できたし、カタログに使われるような物撮りシチュエーションでは、一定水準のハードを揃えることができれば威力をいかんなく発揮できると思われる。

RedshiftはV-Rayの機能をそのままGPU対応にしたかのようなレンダラと言える。そのため設定がV-Rayよりさらに複雑でレンダリングマニア向けだが、設定がピタッとはまった際にはGPUのパワーを活かした超高速レンダリングが可能。Octaneはパストレーサーとして設定がシンプルで扱いやすいが、Mayaへの対応力という点ではまだまだ足りていないと感じる。Octaneはプラグインレンダラとしての使い方より、スタンドアロンレンダラとして使う方が良いだろう。

mental rayに替わって搭載されたArnoldは、売り文句の通りシンプルな設定で、Mayaへの対応力もV-Rayと比べても非常に高い。さらに重いシーンでも問題なくレンダリングが可能ということは、この先より複雑になる映像制作の強い味方となるだろう。



  • 月刊CGWORLD + digital video vol.220(2017年4月号)
    第1特集:最新レンダラ徹底比較
    第2特集:デジタル作画 最新動向

    定価:1,512円(税込)
    判型:A4ワイド
    総ページ数:144
    発売日:2017年3月10日
    ASIN:B01MSB5L7Y