Performance 2.7
~修正予定~
レンダリングパフォーマンスに関する設定を行います。
Threads
レンダリング時に利用する PC のコア数に関する設定を行います。
PC のコア数を自動で検出する Auto-detect か、使用するコア数をユーザーが固定する Fixed のどちらかを選択します。
Auto-detect
PC のコア数を自動検出し、そのすべてのコアをレンダリングに使用します。
負荷の状況を見て自動的に使用するコアを減らしたり…ということはしてくれません。
※48 スレッドある PC で Blender を 3 つ起動し、それぞれ別のシーンを同時にレンダリングしようとした場合、すべての Blender を "Auto-detect" にするよりも "Fixed" にして "Threads = 16" にした方が結果的に早く終わりました。
Fixed
PC がマルチコア CPU の場合に、CPU レンダリングで使用するコア数を制限します。
CPU レンダリングをしながら他の作業を行いたいときに、ここでスレッド数を制限しておくと便利です。
Threads
Fixed が選択されているときに、レンダリング時に使用するコア数 (1 - 64) を指定します。
※実際の PC のスレッド数よりも多く設定できてしまいますが、レンダリングが速く終わることはなく、逆に若干遅くなりました。
Tiles
Cycles では、シーンをレンダリングする際に、シーン全体を一度にレンダリングするのではなく、いくつかのタイル状に分割し、そのタイル毎にレンダリングを実行することができます。適切なタイルサイズでレンダリングすることで、レンダリング時間を短くすることができます。また、シーンを分割することで、レンダリング中のメモリの節約のためにバッファの保存が行われ、全イメージを GPU メモリに上置く必要がないため、GPU でも非常に大きな解像度をレンダリングすることが可能となります。
ここでは、そのタイルのサイズや、そのタイルでのレンダリングを行う順番を設定します。
GPU レンダリングの際に、「The NVIDIA OpenGL driver lost connection with the display driver」というエラーが発生する場合、タイルサイズを小さくすることで問題を軽減できることがあるそうです。
分割数と GPU/CPU によるレンダリング時間の関係は「Tiles とレンダリング時間の関係」を参照してください。
Tile Order
タイルレンダリングが進む方向を設定します。
Hilbert Spiral
カスタム設計された空間充填曲線ヒルベルトスパイラル状にレンダリングします。
シーン中央から外側に向かって螺旋状に、タイルに分割されたブロック単位でレンダリングが進行ます。各ブロック内のタイルは[[ヒルベルト曲線::https://ja.wikipedia.org/wiki/ヒルベルト曲線]]のパターンで進行します。
螺旋の方向に応じてパターンを回転させることにより、連続的な曲線はキャッシュの一貫性に役立ち、結果、レンダリング速度が向上します。
Bottom to Top 等のライン状に進むレンダリングよりは若干遅くなる傾向があるものの、Center の様にシーン中央の重要なエリアからレンダリングを始めることができ、Center よりも速くレンダリングを行うことができます。
※黄色いラインはレンダリングの進行イメージです。
Bottom to Top
下から上にレンダリングします。
※黄色いラインはレンダリングの進行イメージです。
Top to Bottom
上から下にレンダリングします。
※黄色いラインはレンダリングの進行イメージです。
Left to Right
左から右にレンダリングします。
※黄色いラインはレンダリングの進行イメージです。
Right to Left
右から左にレンダリングします。
※黄色いラインはレンダリングの進行イメージです。
Center
シーン中央から外側に向かって、円形にレンダリングしていきます。
※黄色いラインはレンダリングの進行イメージです。
X/Y
タイルサイズの水平方向 (X) および垂直方向 (Y) のピクセル数 (8 - 65536) を設定します。
※傾向として、CPU レンダリングの場合は小さい値 (10 とか)、GPU レンダリングの場合は CUDA エラーが発生しない程度の大きい値の方が速く終わります。
Progressive Refine
このオプションを有効にすることでプログレッシブリファインモードとなり、イメージ全体に対して徐々にサンプリング数を上げていく方法となります。
イメージ全体に対してサンプル数を上げていくため、品質に問題が無いと判断できればレンダリングを途中で止めることができ、時間の節約ができる可能性があります。
サンプル数がどの程度必要か分かっていない状況でサンプル数を探りながらレンダリングする場合に、有効なオプションです。
ただし、このオプションを有効にすることで、タイルごとにレンダリングを行った場合よりも、約 1.5 倍ほどレンダリングに時間が掛かるため、サンプル数が決まっている場合にはこのオプションは無効にしたほうが良いでしょう。
また、品質が十分と判断でき、レンダリングを途中で止める際には、その時点のサンプル数を「UV/Image Editor」のヘッダー部分で予め確認してください。レンダリングを止めてしまうと、サンプル数をいくつまで計算したのか、後で確認することができません。
内部的には各タイルをスレッド毎に計算しているようなので、画面全体の処理とは言え Tiles の値は処理時間に影響してきます。
各タイルの計算はマルチスレッドで行い、イメージ全体の更新はシングルスレッドで行っているようですが、描画更新中にレンダリング処理を停止しても全体の更新が終わってから停止します。
Save Buffers
メモリを節約するため、すべての RenderLayers、SceneNodes のタイルを、temp ディレクトリ (初期値では "C:\Users\<ユーザー名>\AppData\Local\Temp") 内の "blender_*" フォルダ (Blender の起動毎にフォルダが作成され、終了時に削除されます) に OpenEXR ファイルとして保存します。
Viewport
Viewport BVH Type
レンダリングエンジンによって実行される BVH (Bounding Volume Hierarchy : バウンディングボリューム階層) プロセスに関する設定を行います。
レンダリングの時間を犠牲にして BVH の再構築に時間をかけないようにするか、BVH 再構築の時間を犠牲にしてレンダリングを速めるかを選択します。
オブジェクトの数や、モデリングの詰め具合で設定を切り替えるのが良いのかもしれませんね。
Dynamic BVH
レンダリング時間は遅くなりますが、BVH はオブジェクト毎にアップデートされるため、BVH の再構築が速くなります。
Static BVH
いずれかのオブジェクトが変更されるとすべての BVH が再構築されますが、より速くレンダリングできます。
Start Resolution
3D View で Viewport Shading を Rendered にした際にレンダリングし始めの解像度 (8-16384) を設定します。
補足 :
大きい値は最初から綺麗にプレビュー表示されますが、表示されるまでに時間がかかります。
プレビュー表示したままビューの操作を行うことも考えると、小さな値から操作性と表示のバランスを見たほうが良さそうです。
Final Render
Cache BVH
※このオプションは、v2.76b まではありましたが、v2.77 以降からなくなりました。
このオプションを有効にすることで、最後に構築された BVH をディスクにキャッシュし、ジオメトリに変更がなければ、それを再レンダリングに利用してレンダリングを速めます。
ジオメトリに変更がなくカメラの位置等だけが変わる場合にとても有効です。
ただし、ジオメトリの形が変わらなくても、位置が変わるだけで再構築となってしまうようです。
Persistent Images
Cycles はレンダリングが終了するとすべてのデータを解放しますが、このオプションを有効にすることによりレンダリングに使用するためにロードした画像をメモリ上に維持し、次のレンダリング実行時にロードしなおさずにメモリ上の画像を使用し、ロード時間を短縮することができます。
テクスチャ等にイメージファイルを多く利用していたり、大きなイメージファイルを利用していたりする場合に、このオプションは有効です。
Aceleration Structure
Use Spatial Splits
このオプションを有効にすることで、BVH の構築に時間がかかりますが、レンダリングを速めることができます。
- 最終更新:2017-08-25 16:07:45