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
検証結果
シーンレベルごとのレンダリング時間
グラフ上に値がない部分はレンダリングができなかったことを示す。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機能を搭載しているが、テクスチャキャッシュとしてしか機能せず、ジオメトリを外部メモリに渡す手段がないため、さらにサイズを減らしたシーンでしかレンダリングできなかった
また、実際レンダリングされた画像を比較し、品質を比べてみたのが下の画像だ。品質の比較はあくまで目安でしかない。レンダー設定を変えれば品質を良くすることはできるが、おのずとレンダリング時間もかかってしまう