見出し画像

blender 4.4 EEVEE レンダープロパティまとめ

EEVEE は blender のデフォルトのレンダーエンジンで、3DCG では古くからある「ラスタライズ」方式を採用、処理負担が軽く描画が速いのが利点だ。

一方、cycles は新しく開発された「レイトレーシング」方式を採用、光の挙動を物理的に正確にシミュレートすることができ、フォトリアルなレンダリングに適しているが、反面、計算が膨大で描画が遅い。

そのどちらのよいところ(フォトリアルで描画が速い)を目指しているのが、4.2 から大幅なバージョンアップが行われた EEVEE だ。ただし、開発途上でもあり、ほぼデフォルトの設定でフォトリアルなレンダリングが可能な cycles に比べ、同様の表現を実現するには、やや細かな各種設定の調整が必要。

ここでは、それらの EEVEE のレンダープロパティ各値についてまとめてみたい。


環境 Blender 4.4.1 , Mac Mini M1 OS 14.4



EEVEE の得意なレンダリング。


EEVEE が得意とするのは、比較的シンプルな照明(下ではサンライトのみ)で、光の反射が単純(太陽光がオブジェクトに当たって照らし、影をつくる)な場合だ。

EEVEE(後述のレイトレーシング ON)レンダリング時間 1 秒以内
 cycles レンダリング時間 約 10 秒

ここでは、EEVEE の方がやや陰影が強い程度で、ほぼ同じ。オブジェクトの形状の複雑さはあまり影響を与えない。


EEVEE の不得意なレンダリング。


下では、フォトリアルなレンダリングによく用いられる HDRI による背景(環境)光を照明とし、一部のオブジェクトに、鏡のような金属や、ガラスのマテリアルを適用した。 

EEVEE(レイトレーシング ON)レンダリング時間 1 秒以内
cycles レンダリング時間 約 18 秒

ほぼ現実の同様のレンダリングを行っている cycles と比べ、EEVEE ではかなり不自然な表現になっている。ラスタライズ方式が不得意な、鏡などの間接光の反射、ガラスの光の屈折などは、まだ正確に処理されないためだ。

左 : 間接光の反射 右 : ガラス内部での光の屈折



EEVEE レンダープロパティ


これらの問題を可能なかぎり補い、解消するため、EEVEE では、いくつかの補助機能を備えている。それらをまとめてみよう。


セットアップ

あえて、EEVEE にやや不向きとされる、間接光の多い閉じられたインテリアシーンをセットアップした。

照明はサンライト 強さ 10 光が入るのは、3 つの窓からのみ。
内部。手前の球オブジェクトは金属マテリアル(メタリック 1.0、粗さ 0.0)

比較のため、cycles でレンダリング。

そのまま、EEVEE でレンダリング。

デフォルトの EEVEE では、照明(ここではサンライト)による直接光(Direct Light)が照らすエリアのみ明るくなる。cycles のように、直接光が壁などに当たって跳ね返り、他のエリアを照らしたり、鏡などに映り込む現実の現象、間接光(Indirect Light)が反映されないため、全体に暗く、手前の球オブジェクトの周囲の映り込みもまったくない。

サンプル数 128 ジッターシャドウ ON 影 > ステップ 12

なお、部屋の壁の隅に「光漏れ」が発生することがあるが、これらの多くは、上の設定と、部屋の壁をソリッド化モディファイア等で厚みをつけることで解決する。ただし、サンプル数を上げるとビューポートの動作に負担がかかるため、レンダーのサンプル数のみあげてもよいだろう。(レンダリング時間は増加する)


レイトレーシング

EEVEE のレイトレーシング機能(4.2以降)は、cycles のレイトレーシング機能を高速化のため簡略化して取り入れた機能だ。

レイトレーシング ON

間接光による影響が反映され、光が直接当たっていないエリアも、壁などに跳ね返った光によって照らされやや明るくなり、球オブジェクトへの映り込みも cycles より精密ではないが、反映されている。

レイトレーシング 解像度 1:1

なお、解像度は 1:1 がもっとも解像度が高く精密になる。動作に影響が出ない限り、1:1 を選択して問題ないだろう。

高速GI近似 - Fast GI Approximation

間接光による計算はやや複雑で時間がかかるため、より高速な代替手段として用いられているのが、高速GI(Global illumination)近似だ。デフォルトでは、より正確だが低速のレイトレーシングと50%で分担している。

しきい値が0.0 は100%高速GI近似が、1.0 ならば100%レイトレーシングが反映される
しきい値 1.0 レイトレーシングのみ。反射は正確だが、低速で、かなり暗い。
しきい値 0.0 高速GI近似のみ。反射は正確ではないが、高速で、一律に明るい。

EEVEE では、高速化のためのさまざまな工夫が施されていることがわかる。ただ、高速 GI 近似のみでは、印象としてややリアリティに欠けるので、通常はデフォルトの 0.5 が適当で、必要を感じる場合のみの調整だろう。


背景光、発光マテリアル

シーン全体がやや暗いので、背景(環境)光に、強さ 0.5 の HDRI を設定、窓の外から照明を増やし、また、部屋の天井照明には、放射(強さ 15)の発光マテリアルを適用し、室内照明とした。

なお、部屋の壁の「粗さ」を少なくし反射を強くし、サンライトの「角度」をやや上げ( 3°)、影をソフトに、の微調整を行っている。なお、HDRI は PolyHaven の Paul Lobe Haus を使用した。

EEVEE レンダー > サンプル数 256

なお、サンプル数が少ないと、下のようなノイズが発生しやすいので、ここでは 256 に設定。

レンダー > サンプル数 32

また、とくに奥の壁のアンビエントオクルージョン風(おそらく高速GI近似の影響)が気になる場合は、高速GI近似の影響を減らしてもよいだろう。

レンダー > サンプル数 256 高速GI近似 > しきい値 0.9

全体として、比較的リアルな光の反射が行われるようになった。


ライトプローブ


たとえば、上の、EEVEE と、cycles でレンダリングした球オブジェクトのクローズアップを比較してみる。

左 : EEVEE 右 : cycles

球オブジェクトの反射をみると、EEVEE では、当然映り込んでいるはずの部屋の壁が映ってなく、外のHDRI背景がそのまま映っている。また、床付近の反射がやや不自然だ。

これらの原因の一部は、EEVEE のラスタライズ方式の「カメラに映っていないオブジェクトは存在しないものとみなす」という性質のためだ。部屋の壁は、カメラに映っている範囲しか「存在していない」ので、球に映り込まないのだ。

たとえば、下は、サンライトや背景光をほぼゼロにし、発光オブジェクトによる室内光のみとした場合。

発光オブジェクトがカメラに映っている場合は、ソファや周囲を照らす。
カメラの視点角度を変えた。発光オブジェクトが映っていないと、
それは存在しないものとみなされ、なにも照らさない。

これは、間接光による照明も同じだが、サンライトや、ポイント、エリアなどライトオブジェクトは当然、カメラの視野に入っていなくとも反映される。

これらの欠点を補うのが各種ライトプローブで、カメラの範囲外の光の反射などの処理を事前に計算し、正確さを反映しながらレンダリングの高速化を実現する機能だ。


Light Probe > Sphere

ライトプローブ > 球状 を追加し、球オブジェクトを包むように配置する。

レンダープレビュー。球に周囲の部屋の映り込みが入る。

レイトレーシングのみでは反映されない周囲の光が、球状ライトプローブに記録され、それが球オブジェクトに映り込む。

Light Probe > Plane

ライトプローブ > 平面を追加し、部屋の床に設置する。

床に映り込みが現れる位置へ、平面ライトプローブの高さ位置を調整。

背後のソファを含む、床への映り込みが自然になった。ただ、球の床への映り込みが鏡マテリアルにみえないのは、現状で EEVEE の制約と思われる。

cycles での反射


Light Probe > Volume

ライトプローブ > ボリュームを追加し、部屋のサイズにスケールを合わせ、「ライトキャッシュをベイク」を実行する。

各ドット(プローブ)がなるべく均等に配置されるよう、解像度の各値を調整。

各プローブに周囲が記録(ベイク)され、おもに間接光のリアルな表現に役立つ。

左 : 適用前 右 : 適用後

このシーンではあまり差が見られないが、フロアランプの側面が、隣の壁の間接光を受け、やや明るく照らされる現象が再現されている。

ライトプローブ設置前。
ライトプローブ設置後。球や床への映り込みも比較的正常に。
比較用 cycles でのレンダリング。

ライトプローブを併用することにより、ある程度、物理的に正確な光の反射を再現することができている。


まとめ


このように、デフォルトの EEVEE では、おもに間接光などのリアルな光の描画を省き、多くの場合、1 秒に満たないレンダリング時間を実現していますが、各種のオプション機能を加えることで、cycles に近いフォトリアルな表現もまた可能にしています。

ただし、現状ではやや細かな設定が多く、フォトリアル的な機能を加えた場合、上のサンプル画像ではレンダリング時間が 12 秒と長くなり、cycles の 26 秒 に比べ圧倒的に短いとはいえなくなりました。

総じて、あくまでフォトリアルなレンダリングを求めるならば、細かな調整が必要のない cycles がいまも適しているといえるかもしれませんが、EEVEE には、cycles とはまた異なる独特な表現もありますし、また、手軽な「リアル」感をEEVEE に付与したい場合にも、上での各種設定の理解は役立つでしょう。参考まで。


参考

ひさしぶりに Guru の動画をみたけど、さすが Blender系 No.1 ユーチューバーの職人芸は健在。でもすこし歳とった? ひとのことはいえないけど。

EEVEE では、カメラに映っていないオブジェクトは存在しないものとみなしている、と書きましたが、現実世界でも、素粒子レベルに限れば、われわれが見ていないモノは実は存在していない(存在している、していない、の状態が重なり合っている)のだそうです。現実でも、極小の世界では、すこし省力化を図りたいのでしょうか。


いいなと思ったら応援しよう!