Blender.jp

以前のViewport Plan of Action（英文）記事では、来たる Blender 2.8のレンダリングエンジン（ニックネーム Eevee）の簡単な紹介で締めくくりました。Eevee では（ゲーム）業界の PBR（Physically Based Rendering）の流行に乗り、レスポンシブなリアルタイムビューポートと結び付け、ハイエンドのグラフィックスに対応する予定です。

Sci-fi armor（Andy Goralczyk 氏作）? アウトライン選択のモックアップと Cycles でレンダリング、PBR の参考例

あの時はまだプロジェクト細部の議論には時期早々でした。時は過ぎ、アイデアが熟成した今、Eevee のロードマップについて率直に語る時がやってきたのです。

シーンライト

内部的なゴールはリアルな Blender 光源タイプ（要は Hemi（ヘミ）以外）のすべてに対応することです。

まずはディフューズ点光源の対応から始める予定です。PBR ブランチとは違い、シーンへの光源の追加・削除で速度が落ちるようなことはないようにします。技術的知識のある人向けにいうと、UBO（Uniform Buffer Object）とシーン光源データを使用し、シェーダーの再コンパイルを回避する予定です。

次にシェーダーの鏡面反射の対応と、光源対応にエリアライトを入れるための拡張ができます。この実装は、UBO データの主な用途となる GGX シェーダーの拡張を暗示しています。
また、光源のパネルもすべての設定がリアルタイム用途で有効とは限らないので、Eevee 設定用に作り直す必要があるでしょう。

ソフトシャドウ

私たちはみんな赤ん坊のおしりのようにすべすべした影が好きです。しかし、リアルなスムーズシャドウは演算的にはコストが高いのです。
Eevee のリアルタイムモード用には、現在 Blender にある、シャドウバッファの実装に従う予定です。オフライン Eevee レンダリング（要は Playblast）では全力を出し、水準を引き上げることができます。

通常のマテリアル

Uberシェーダー

灯りはうまく点きましたが、まだそれに反応するマテリアルが必要です。

Unreal Engine 4 PBR マテリアルに追従し、Uber シェーダーのコンセプトを実装する予定です。Eevee の目標は UE4と同等の機能にすることではないため、すべての UE4 Uberシェーダー（カーコーティング、人間の皮膚など…）がここで見られることを期待しないでください。

大抵の場合、Uber シェーダーは Output（出力）ノードになります。効率的に動作させるためには、PyNode シェーダーシステムも実装する必要があります。この方法ではエンジンから利用される GLSL シェーダーを各（Python）ノードで持つことができます。

マルチエンジンマテリアル出力の UI/UX ソリューション

一つのマテリアルで複数のエンジン、実現するにはどうすれば？

すでに Cycles 用にセットアップ済で、まだ Eevee PBR ノードがないマテリアルでも、多少見た目に違いはあれ、Eevee で動作すると思われます。それでも、私たちは Eevee 自身の出力ノードに対応したいと思っており、他のエンジン用ノードに対応するところで代替の解決策を処理させる計画です（これらのノードが前述の PyNode シェーダーシステムに追従すると仮定した場合）。

Blender 内部レンダーの変換・置き換え

Eevee によるパイプラインの作業後、旧 Blender レンダーファイルとの互換性に取り組まなくてはなりません。とはいえ、初期から Eevee に飛びつくユーザーには Cycles の代替オプションで十分だと思われます。

上級マテリアル

後で以下のようなもっと上級な技術に対応する予定です。

SSS

クリアーコート

ボリューメトリック

イメージベースドライティング

プリレンダ HDRI への対応の後、シーン内でオンデマンドで生成されたプローブに対応する予定です。これにより、シーンオブジェクトはお互いに影響しあうようになります（反射、ディフィーズ光のバウンドなど）。

ビューポートを常にレスポンシブにする必要があるため、プローブ計算中に何か表示させないといけません。プローブ生成中にすばやくロードするには、球状調和関数（つまりディフューズのみ）が .blend に格納可能です。

レスポンス性のためにはタイムキャッシュも考慮にいれるべきでしょう。

グロッシーラフシェーダー

Agent 327 Barbershop project（Blender Institute 作） - Cycles でレンダリング、ウッドフロアでの光沢テクスチャの参考例

プリフィルター（要はブラー）プローブなしの粗い反射を持つ光沢には対応できません。さもないとひどいパフォーマンス（PBR ブランチ参照）で、なおかつ非常にノイズの多い結果になります。

ディフューズの近似

実際の球状調和関数の最初のいくつかを視覚化したもの。wikipedia より

キューブマップや球状調和関数など、シーンの放射照度を表現する方法はいくつかあります。

より精度の高い方法はキューブマップを使用し、ディフューズシェーダーに結果を格納することです。しかし、これはテクセル毎にディフューズ計算が必要になるため、低速です。

既知の妥協案は、低周波数の照射情報を係数のセット（球状調和関数）に格納することです。これは高速（かつ作業が簡単）ですが、コーナーの（光が最終的に自身をキャンセルする）場合では失敗します。

Eevee は球状調和関数に対応し、キューブマップは単にベイク済みスペキュラのためだけに残す予定です。

プローブオブジェクト

Force Field（フォースフィールド）のように、プローブも専用の描画コードとともにエンプティオブジェクトになると思われます。

環境マップアレイ（Environment map array）

Unreal Engine 4の参考画像。ルームデザインは NasteX 氏。

大きなオブジェクト（フロアなど）では、環境を正しくレンダリングするのに複数のプローブが必要になるでしょう。Unreal の環境マップアレイは、対応したハードウェア上でそれを処理します。これは OpenGL 3.3コアとは互換性がありません。一応（ARB 拡張を通じて）この機能は最近のグラフィックカードで対応可能ですが、新旧のハードウェアで互換性のある代替案、例えば四面体マップなどに目を向けるべきでしょう。

ポストプロセスエフェクト

Siggraph の締切までに以下のエフェクトが必要です：

モーションブラー

ブルーム

トーンマップ

被写界深度

Ground Truth Ambient Occlusion

いずれ実装したい他のエフェクト：

Temporal Anti-Alias（一時的アンチエイリアス。光沢による輝点ノイズの修正用）

Screen Space Reflection（スクリーンスペース反射。より正確な反射、オブジェクトの接地に便利）

エピローグ

Blender 2.8 ビューポートのデザインモックアップ（Paweł Łyczkowski 氏作）。Cycles プレビュー上のフレネルワイヤ案

まとめると、ここで示した機能のコアは Siggraph 2017 までに実装され、さらに洗練された使用可能なバージョンは Blender Conference までに実装されます。

（Eevee がコアパートの一つである）ビューポートプロジェクトの開発は blender2.8 ブランチで行われています。まだ大規模なユーザーテストには少し早いですが、さらなる更新に期待していてください。

もっと技術的な表現による時系列順の Eevee のロードマップが Blender 開発者 Wiki にあります。