なぜなにリアルタイムレンダリング
- 3. 本日のお品書き • はじめに • レンダリング基礎 • レンダリング手法Q&A – Deferred Renderingが昔は使われなかったのはなぜ？ – Forward RenderingでG-Bufferは使えない？ – Deferred Renderingで多光源を扱えるのはなぜ？ – Deferred Renderingはなぜ半透明が弱いのか？ – Deferred RenderingでMSAAが使いたい！ – Deferred Renderingで描画の自由度を高めるにはどうすればいい？ – Deferred ShadingとDeferred Lighting その違いは？ – Z Pre-Passって何？ – Tile-based Renderingとは？ – Clustered Renderingって何？ • これからの話
- 4. はじめに
- 5. はじめに • 最近は猫も杓子もDeferred Rendering！ – 光源がいっぱい置けるようになった！ – ポストプロセスで使える情報が多くなった！ • その一方で… – 半透明をできるだけ使わないでと言われる – 不透明マテリアルより半透明マテリアルのほうが出来ることが 少ない – 描画の自由度が低すぎない？ • キャラ固有のライトが使えない or 使えるけど制限あり • キャラを描画する前にパーティクル描画したいのに出来ない
- 6. はじめに • Deferred Renderingってそんなにいいの？ – 利点は間違いなくある – 欠点も間違いなくある • Deferred Renderingを使うべきか？ – 作品による – アニメ系だとDeferredじゃなくてもいいんじゃない？ • 大量のライトを使うと逆に陰影がおかしくなってしまう • 作品の目指すところとレンダリング手法はマッチしている？ – たいていはエンジニアがヒアリングの結果、決定している – 提案したいけど、よく知らないから提案できない
- 7. はじめに ならば知ろう！
- 8. レンダリング基礎
- 9. ポリゴンラスタライザ • 現在のリアルタイムレンダリングで最もよく使われて いる手法 • 処理順序 – ポリゴンの頂点をスクリーン空間に変換 – 処理を行うべきピクセルを選択 – 各ピクセルの色を決定 – レンダーターゲット(描画バッファ：RT)に描画 • 半透明などの手法でブレンディングする場合は RTの内容をフィードバックする
- 10. ポリゴンラスタライザ
- 14. ドローコール • 描画プログラムの命令でDraw～という命令を発行すること、 もしくはその発行の単位 – 通常、同じモデル、同じマテリアル、同じカメラ、同じRTに対し て1ドローコールが行われる • 昔はハードの制約の問題で同じマテリアルだけど複数回のドローコー ルということもあった – ドローコール発行のタイミングで描画に必要な各種設定を収集、 問題がないか検証を行ってGPUに命令を伝える • GPUが処理できる“コマンド”を生成 • これはCPUが行うので、ドローコールはCPU負荷となる
- 15. 描画パス • 同じような描画設定で発行される複数のドローコールをまと めたもの – 例えば、モデル、パーティクル、UIはそれぞれに描画設定が異な るので、すべて描画した場合は3パス – モデルでも、背景モデル、キャラクタモデルを別々に描画してパ スを分けることもある • 描画レイヤーとも呼ばれる – 同じモデルでも描画する属性の違いによりパスは分割される • トゥーン系レンダリングで、カラーの描画とアウトライン用背面モデ ルの描画を別のパスとして考えることもある
- 16. カリング • 処理の不要なモデル/ポリゴン/ピクセルを排除すること – cull：摘む、淘汰する、捨てる – 最も高速なプログラムとは？ • 何もしないプログラム • 処理が不要なら処理しない方が高速 – フェーズによっていくつかの種類が存在する • フラスタムカリング • バックフェースカリング • オクルージョンカリング
- 17. カリング • フラスタムカリング – frustum：錐台、円錐などの頭頂部を切断した物体 – CGにおいてはカメラから見える範囲は通常 この形状をしている • この範囲に入らないものは描画処理が不要 – モデルのカリングは主にこれ • モデルの境界箱との衝突判定をとることが多い • ハードウェアが自動では行わないので、ソフトウェアで処理する • 処理速度は比較的速い
- 18. カリング • バックフェースカリング – ポリゴンの裏面を描画しない手法 – ポリゴンオブジェクトが“閉じた”状態である場合、ポリゴンの 裏面は描画不要 • カメラがポリゴンオブジェクト内部に入ることがある場合は別 – このカリングはラスタライザで行われる • カリングされた場合はピクセル処理が走らないので高速 – 不要な両面描画は控えましょう
- 19. カリング • オクルージョンカリング – 遮蔽物によって描画されないものを描画しない手法 – ピクセル単位の処理はZバッファを使う • Zバッファはそのピクセルの最もカメラに近い位置の深度値を保存 する • すでに保存されている深度値より奥にあるピクセルは描画不要 • 半透明などの特殊な描画ではこのルールが適用されないこともあ る • ハードウェアで実装されているので使用は簡単 – 最近は階層型Zバッファによる高速化も行われている
- 20. カリング • オクルージョンカリング – モデル単位で遮蔽チェック • 多くは背景に対するキャラやプロップなどの小物チェック – 簡易モデルを低解像度のZバッファに描画してモデルの境界箱 とZバッファのチェックを行う • Frostbite Engineがこの実装 • CryEngineは前回のZバッファを低解像度に落として利用 – これらはCPUで行っている – 最近はGPUからドローコールを制御できるようになったので、 GPUで遮蔽チェックを行うことも • トライアングル単位でのカリングも？
- 21. Forward Rendering • Traditional Forward Rendering – 従来タイプの手法は区別するためにこのように呼ばれる • 通常、モデル中の各マテリアルを1ドローコールで描画 する手法 – ピクセルシェーダでライティング/シェーディングを行う – シャドウマップを描画する場合はドローコールが増える • 不透明と半透明で同じシェーダが使用できる – 違いはRTに描き込む際のブレンド設定
- 23. Forward Rendering スクリーン空間に変換 頂点シェーダ 塗るピクセルを選択ラスタライザ レンダーターゲット(RT) ピクセルシェーダ 色を塗る ここでライティング/シェーディングを行う
- 24. Forward Rendering • PS2までは主流の方法 – ハードウェアの制約上、この手法しか取れなかった – 現在のハードウェアでは3DSがこの手法しか使えない – 日本のゲームではPS3でも主流だった • 使用可能なライト数に制限がある – これも主にハードウェアの制約による – 固定シェーダの頃はライト数がハード固定 – プログラマブルシェーダでもシェーダに渡せるパラメータ数に 限界があった
- 25. Deferred Rendering • PS3中期くらいから使用されだした手法 – 現在ではほぼ主流と言っていい • 1回のドローコールでG-Buffer(Geometry Buffer)にモデル のジオメトリ、マテリアル情報を描き込む – この段階ではライティング/シェーディングは行わない • ジオメトリパス – すべてのメッシュをG-Bufferに描画したらライティングを行う • ライティングパス – ジオメトリパスでライティング結果を求めず、遅延(Deferred)さ せてライティングを行うのでこう呼ばれる
- 26. Deferred Rendering • G-Bufferの例 – 画像はUE4のG-Buffer – 実際にはこれより多くの情報が描画されている – 情報が圧縮されて格納している場合もある • 少ないG-Bufferで多くの情報を格納するため • 情報の使用時にデコードコストがかかる Base Color Roughness World Normal Depth
- 29. Deferred Renderingのライティングパス • ピクセル単位のライティングを行う – 各ピクセルのG-Bufferとライト情報から計算を行う – ライト形状を描画して、その範囲のみライト計算を行う G-Buffer レンダーターゲット(RT) ライティング
- 30. Deferred Rendering • メリット – 光源を多く使用できる – G-Bufferの情報をあとで利用できる • デメリット – 半透明が弱い – MSAAが使えない – シェーダのバリエーションを多く出来ない – 描画レイヤーなどの自由度が低い
- 31. レンダリング手法Q&A
- 33. Deferred Renderingの歴史 • 元になったのはSIGGRAPH 1988の論文 – Michael Deering氏による – この時はDeferred Renderingとは呼ばれず、G-Bufferも使ってい ない • G-Bufferに言及した論文はSIGGRAPH 1990の論文 – 斎藤隆文氏、高橋時市郎氏による – この時もDeferred Renderingとは呼ばれていない • 実際に使われ始めたのはPS3/Xbox360世代 – 最初の商用ゲームは『Killzone2』？ – なぜこの世代まで使われなかったのか？
- 34. Deferred Renderingが使われなかった理由 • 固定シェーダでは実装が難しい – G-Bufferに適切な情報を適切な形で描画できない – G-Bufferから適切な情報を適切な形で取得できない – ピクセルシェーダの実装は初代Xbox • この世代以降なら使える？ • 複数のG-Bufferに描画する機能がない – 1回のドローコールで描画可能なRTは1枚だった – 複数のG-Bufferに描画するには複数回のドローコールが必要 – マルチレンダーターゲット(MRT)の実装
- 35. マルチレンダーターゲット(MRT) • 1回のドローコールで複数のレンダーターゲットに同時 に描画を行う機能 – PS3/Xbox360世代以降のGPUに追加された機能 • PS3/Xbox360世代は最大4つ • 現在のハイエンドGPUはもっと多い – 同じ解像度のバッファに、同じスクリーンに投影したポリゴン のみ使用できる • 例えば画面4分割をMRTで処理するとかは出来ない – カメラが違うのでスクリーンが違う
- 37. Deferred Renderingが使われなかった理由 • 日本のゲームにはDeferredは合わないと言われていた – DeferredのデメリットがPS2時代の日本のゲーム作りと合ってい なかった • 特に半透明問題は顕著 – CEDEC 2010のパネルディスカッションでも話題に上がっていた • ここでも日本のゲームに合わないと言われていた • しかし、現在は多くのゲームが採用 – バイオハザード7 – ファイナルファンタジー15 – UE4採用タイトル など
- 39. G-Bufferの使用用途 • Deferred Renderingで作成するG-Bufferの使用用途は多岐 にわたる – 通常のライティング計算 – SSAO、SSRなどのスクリーン空間ライティング処理 – アウトライン描画などのポストプロセス – シェーディングモデルIDを調べて特殊なポストプロセス • Screen Space Subsurface Scatteringなど • Forward Renderingでは深度バッファとカラーバッファの み使用可能 – 深度がわかれば位置もわかるので、これも使える – Deferredに比べると使える情報は少ない
- 40. Forward RenderingではG-Bufferは使えない？ • NO！ • MRT自体はハードウェアの機能であり、Deferredでなけ れば使えないということはない – ライティングを行うのと同時に別のバッファに必要な情報を出 力すればよい • 実例：新生DOOM(Bethesda Softworks/id Software) – 不透明のForward Rendering時に2枚のG-Bufferを描画 • Specular & Smoothness • Normal – 薄いG-Buffer(thin G-Buffer)と呼んでいる – ただし、実装はClustered Forward Rendering
- 42. 多光源が使える理由 • 現行のGPUではForward Renderingで多光源を扱えない？ – ハードウェア的制約は存在しない • 十分な数のライトパラメータをシェーダに送れる – しかし、Traditional Forward Renderingで多光源を扱うことはほ とんどない • では何が問題？ – 比較する前に各手法のライティング戦略を知ろう
- 43. Forward Renderingのライティング戦略 • シーン内の光源の中から影響を受ける光源を選択する – バウンディングボックスとライトの接触判定 • 赤の球が接触しているポイントライト • 緑の球は接触していないのでシェーダに送られない – より詳細な衝突判定は？ • CPUとGPUのコストバランスによる
- 44. Forward Renderingのライティング戦略 • ピクセルシェーダでモデルをライティングする – ラスタライザで選択されたピクセルすべてにおいて、 すべてのライトとの計算を行う • 緑のピクセルはどのライトとも接触していない しかし、計算処理は行われる
- 45. Forward Renderingのライティング戦略 • 無駄なピクセル処理が多すぎる – バウンディングボックスに接触しているが実際のモデルに接触していない 光源 – 影響を与えるピクセルが極小の光源 – 光源と一切接触していないピクセル 境界箱に接触しているので選択される しかし効果範囲外なので影響は受けない しっかりとライトの影響を受ける が、描画されるピクセル数は多くない ライトの影響を受けるがほんのちょっとだけ 影響がない範囲のライトは選択されない これらのピクセルはライトの影響を受けない
- 52. ポイントライトの範囲は球 Deferred Renderingのライティング戦略 裏面のみ描画描画されたピクセルのみステンシル値が”1”表面描画が行われ、ステンシル値が”0”の ピクセルが描画される
- 54. Deferred Renderingのライティング戦略 • ディレクショナルライト – シーン全体に影響を与えるライティング – 画面全体を覆う板を描画し、画面内のすべてのピクセルでライ ティング計算を行う このように画面全体を覆う板を描画する 画面すべてのピクセルでシェーダが動作する そのピクセルシェーダ内でライティング計算を行う
- 55. Deferred Renderingのライティング戦略 • ポイントライト、スポットライト – 影響範囲を示すメッシュを描画する • 球、コーン – 減衰なしだと無限範囲になってしまうので注意 ポイントライトなら球、スポットライトならコーンを描画 深度テストを行い、描画されたピクセルのみ計算する 特殊な形状のライトも効果範囲を示すモデルで対応できる →CEDEC2010 「Eidosの最新ゲームエンジン詳解」参照
- 56. Deferred Renderingのライティング戦略 • IBL(キューブマップ) – グローバルキューブマップならディレクショナルライトと同様 • シーン全体に影響するため – ローカルキューブマップなら範囲ボックスを描画 • ポイントライト、スポットライトと同様 – 両方使いたい場合 • ローカルキューブを描画して、その範囲をマスク • マスクされていない部分にグローバルキューブ描画 • ブレンドしたい場合はもうちょっと工夫する必要がある
- 57. Deferred Renderingのライティング戦略 • 前述の方法はあくまでも一例 – エンジンによっては別の方法が取られていることもある • 極小の光源が多い場合はスプライトで描画する手法も • Deferredの戦略では不要なピクセルに対するライティン グ計算はほとんど行われない – ピクセルシェーダを軽くすることができる • ほとんどのゲームではピクセルシェーダがネックになりやすい – ライティング計算自体も軽い処理ではない • ピクセルシェーダが重くなる原因の1つ
- 58. Deferred vs Forward：多光源 • 実例：昔作ったサンプル – 1024個のライティングサンプルのフレームレート比較 – 境界箱との接触判定なしだが、この数だと差が大きい Deferred Forward
- 59. Deferred vs Forward：多光源 • ライティング計算を行うピクセルを減らす工夫が Deferred Renderingには存在する – Traditional Forward Renderingでは不要な計算が多い – しかし、現在は不要な計算を減らす手法が存在している • Forward+ Rendering • Clustered Rendering • 詳細は後述 • ライトの影響範囲が大きいと速度差は小さくなる – 計算する必要があるピクセル数が近づくため – Deferred Renderingの際にはライトの影響範囲に注意
- 61. 半透明の問題 • 半透明は昔から問題だらけ – 描画順序の問題 • 誰もが一度は苦労する • 通常はカメラから見て奥にあるものから描画していく • 例：水に下半身が浸かっているクリスタルボーイ – 水とクリボー、どちらを先に描画します？ – 処理負荷の問題 • 描画対象のRTから今のカラーを取得する • 描画するカラーとRTのカラーをブレンド • 描画対象のRTにブレンドしたカラーをコピー • RTへのアクセスが2回発生する • Deferredでの問題はこれらではない
- 62. Deferredでの半透明の問題 • 半透明とはどういう状態か？ – レイトレや現実世界の場合 • 奥にある物体が光を反射 • 手前の半透明物体を反射光が通過した結果 ＋ 半透明物体のライティング結果 ＋ 奥にある物体 手前の物体 (透明度80%) 結果 奥の物体の色は半透明物体である程度吸収される 半透明物体の反射光はそのまま
- 63. Deferredでの半透明の問題 • ラスタライザではPhotoshopのレイヤーブレンドに近い – 物体をそれぞれライティング – ライティングした結果の画像をブレンディング • 実際にはポリゴン単位で行われるので正確ではない ＋ 奥にある物体 手前の物体 (透明度80%) 結果 反射光も半透明化している
- 64. Deferredでの半透明の問題 • Forward Renderingでは？ – 不透明物体はピクセルシェーダでライティングされている • RTにはライティング結果が保存される – 半透明物体もピクセルシェーダでライティングされている • ブレンドステージにライティング結果が送られる – RTの内容もピクセルシェーダの結果もライティング済み • そのままブレンドが可能
- 65. Deferredでの半透明の問題 • ジオメトリパスではライティングされていない – この段階ではブレンドができない • ライティングパス後にブレンドする？ – G-Bufferには1ピクセルにつき1つのジオメトリ/マテリアル情報 しか保存できない • 不透明と半透明の同居はできない – 不透明か半透明の情報はG-Bufferに存在しない • 双方のライティング結果を参照できない → 半透明に対して何らかの戦略が必要
- 66. Deferred Renderingの半透明戦略 その1 • 半透明だけForward Rendering – 多くの描画エンジンで採用している手法 – Forwardでも描画順序は不透明→半透明 • この不透明描画部分のみDeferredに置き換えた印象 • メリット – 屈折表現が可能 – 半透明に関してのみ描画レイヤーの調整は比較的しやすい • デメリット – Deferredのメリットは活かせない • 多光源の実装は難しい • G-Bufferを使うポストプロセス対応が難しい – シェーダが増える • 同じ処理でもForward用とDeferred用を用意する必要がある
- 67. Deferred Renderingの半透明戦略 その2 • ディザによるアルファ抜きを使う – 16色時代のドット絵の半透明表現と同じ手法 – 時間軸方向にディザパターンを変えていけば穴が開いているだけには見えなくなる • この場合はTemporal AAを使う必要がある – UE4ではDitherTemporalAAと呼ばれている • http://monsho.blog63.fc2.com/blog-entry-148.html • メリット – Deferred Renderingのライティング機能がフルに使用可能 – ポストプロセスにも対応 – 戦略 その1と共存可能 • デメリット – 透明度が変化する状況に弱い – Temporal AAによるゴースティングが目立つ • 動きの激しいVFXでは使用しづらい
- 68. Deferred Renderingの半透明戦略 その3 • 半透明を使用可能なDeferred Rendering手法を用いる – 代表例：Deep G-Buffer • G-Bufferをレイヤー化する手法 • Depth Peelingという手法で各ピクセルごとに異なる深度でレイヤ ー分けが可能 – http://marina.sys.wakayama-u.ac.jp/~tokoi/?date=20081123 • 半透明順番問題、SSAOの隠れた部分の精度問題にもある程度対応 できる • レイヤー数分のG-Bufferが必要なのでメモリが厳しい – 2～3レイヤーが限界では？ – 不透明レイヤー以外は薄いG-Bufferを使う手もあり
- 69. Deferred Renderingの半透明戦略 その4 • G-Bufferの段階でブレンドしてしまう – 正しい結果にはならない – 使い道を限定すれば悪くない手法 • 代表例：バイオハザード7の水 – ベースカラーと法線を不透明物体に対してブレンド可能 • ブレンド値はそれぞれの要素ごとに設定可能 – 深度バッファは描き込む • ライティングは水の位置を用いて行われる – https://cedil.cesa.or.jp/cedil_sessions/view/1488
- 70. Deferred Renderingの半透明戦略 その5 • Order Independent Transparency (OIT)を使う – 半透明の順番を正しく処理するための手段 – リンクリスト方式なら各ピクセルの正しい情報を保持できる • http://www.slideshare.net/hgruen/oit-and-indirect-illumination-using-dx11- linked-lists • メリット – 正確なライティングとブレンドが可能 – 半透明の描画順序問題も解消できる • デメリット – 屈折の対応は少し難しいか？ – 重すぎて使い物にならな…げふんげふん
- 71. Deferred Renderingの半透明戦略 その6 • パストレーシングを使う – いわゆるレイトレ – 半透明のみ、不透明はDeferredで • メリット – ブレンドはかなり正確にできる – 屈折にかなり正確に対応できる – 実装は比較的やりやすそう • デメリット – ライティングは限定的にしないとリアルタイムは難しそう – スプライトパーティクルに対応すると速度は厳しそう • ソリッドオブジェクト限定なら検証の価値はあるかも
- 72. Deferred Renderingの半透明戦略 まとめ • やはり、その1・2が安定して使いやすい – デメリットもあるがほとんどの場面で対応できる • その3・5は現在のハードでは難しい – 今後の4K、8K解像度を考えるとより難しい印象 • その6も速度的な問題は抱えそう – スケーラビリティは確保しやすそうなので、実現可能性は低く ないと思う • その4の可能性を探りたい – 条件と使いどころを限定すれば効果高いかも
- 74. MSAAとは？ • Multi Sample Anti Aliasingの略 – 各ピクセルに複数個のサブピクセルを設定し、それぞれにピク セルシェーダの結果を格納する手法 – Super Sampling Anti Aliasing (SSAA)の簡易版
- 77. MSAAとは？ • もう少し詳しく処理を見ていく – RTと深度バッファはサブピクセルの数だけバッファサイズが倍率 されている • 4xMSAAの場合、4倍のバッファが取られる – 各ピクセルではピクセルシェーダの起動は一度だけ • サブピクセルを複数内包していても一度 • SSAAの場合はサブピクセルごとにピクセルシェーダが起動する – 内包されているサブピクセルすべてにピクセルシェーダの出力を 保存する • 内包していないサブピクセルには格納されない – すべての描画が終わった後、すべてのサブピクセルのカラーの平 均を求める • リゾルブ処理
- 78. MSAAが使えない理由 • なぜDeferredではMSAAは使えないのか？ – 使えないわけではない • 単純に費用対効果が悪すぎるだけ – G-BufferをすべてMSAA用に変更する必要がある • 4xMSAAの場合はすべてのG-Bufferが4倍 – ライティングはサブピクセル単位で行わなければならない • Forward+MSAAの場合は1ピクセルにつきライティングは一度 • Deferred+MSAAの場合は1ピクセルに付きライティングはサブピクセル 分の回数 – ライティングした後にリゾルブ • 半透明のブレンドと同じで、ライティング後のカラーでなければリゾ ルブできない – SSAAとほとんど変わらない
- 79. Deferredで使えるAA手法 • ポストプロセスAA – FXAA、MLAAなど – FXAAは特に軽量なのでよく使われる – サブピクセルの処理はされないので細い物体の接続が切れる問題 が発生しやすい • Temporal AA – 時間軸方向にサブピクセルを増やしていく方法 – 現行世代の標準的なAA技法となっている – 激しい動きや半透明部分でゴースティングが発生しやすい • 前のフレームの情報が激しく残ってしまう問題 – 最近、SMAAがちょっと話題 • Temporal AA＋MLAAのような技術
- 80. • サブピクセルを利用するAAと利用しないAA –MSAA、Temporal AAなどはサブピクセルを使用する –FXAA、MLAAはサブピクセルを使用しない • サブピクセルを利用することの利点 –細いジオメトリが途切れない！ •電線など おまけ サブピクセルなし サブピクセルあり
- 83. • シェーディング手法はいろいろ –拡散反射：Lambert、Oren-Nayar –鏡面反射：Blinn-Phong、Ward、GGX –髪：Kajiya-Kay、Marschner –肌：Pre-Integrated Skin、Separable Subsurface Scattering –NPR：Cell-Shading • Deferredではライティングパスで処理される –基本はG-Bufferにシェーダの種類を格納しておく –ライティング時にその情報からシェーダ内で分岐 シェーダの自由度
- 84. • PS3/Xbox360世代はシェーダ内の分岐が非常に遅い –分岐するより、2種類の計算を行って0 or 1でブレンドする方が速い くらい –Forwardなら特定の計算を行うシェーダに切り替えるだけ • シェーダ数が爆発的に増えるが、動作は高速 –特殊なシェーダは半透明じゃなくてもForwardで実装していた • PS4/XboxONE世代では普通に使えるくらいに速い –階層の深い分岐・ループはパフォーマンスが悪化しやすい –シェーディングモデルが多いとパフォーマンスが悪化しやすい • シェーダ命令数が増えてしまう シェーダの自由度
- 85. • 高速化例：Uncharted 4 –16x16のブロック単位で使用されるマテリアルをカウント –すべて同一のマテリアルならこのブロックでは単一マテリアル 用のシェーダを使用する –ライティングはコンピュートシェーダを使い、DispatchIndirectで GPU側からシェーダの選択を行う –20～30%高速化したらしい –詳しくはSIGGRAPH 2016「Deferred Lighting in Uncharted 4」を参 照 •http://advances.realtimerendering.com/s2016/s16_ramy_final.pptx シェーダの自由度
- 86. • 通常の描画順序は不透明→半透明→ポストプロセス –ForwardでもDeferredでも同じ • しかし、こういう場合はどうする？ –背景のみに適用したいポストプロセスがある –キャラクタの背後にのみ表示されるパーティクルエフェクトが ある • こんな時こそ描画レイヤーの出番 描画順序の自由度
- 87. • Forward Renderingでは描画レイヤーを分けるのは簡単 –レンダリング時点でライティングカラーが求められているため • 例えば –背景不透明/半透明→背景エフェクト→キャラ不透明/半透明 →キャラエフェクト→手前背景半透明→ポストプロセス •割とよくある3Dゲームのレイヤー –奥側背景不透明/半透明→キャラ不透明/半透明→エフェクト →手前側背景不透明/半透明→ポストプロセス •横スクロールゲームのレイヤー Forward Renderingにおける描画レイヤー
- 89. • 現実的な方法 –不透明は背景・キャラ関係なくすべて描画 • ただし、レイヤーごとにステンシル値を入れる –半透明・エフェクトを描画する際に必要なステンシルでマスク • 背景エフェクトなら背景のみに描画されるようにする –この方法では背景のみのポストプロセスが難しい • キャラ不透明で隠れてしまう部分が出てくるため • Deep G-Bufferを使う –より良い方法だが現実的かどうか疑問 • レイヤー数による Deferred Renderingにおける描画レイヤー
- 90. • 特定キャラ、もしくはレイヤーにのみ影響があるライト –アクションゲームなのでキャラを目立たせたいとか –カットシーン中の女優ライトとか • ライトマスクを利用する –G-Bfferにライトマスクのチャンネルを用意する –不透明描画時に影響を受けるライトチャンネルのフラグを立てる –ライティングパスでライトチャンネルをチェック –4ビットくらいでたいていなんとかなる • 背景、キャラ、主人公、特殊 ライトの自由度
- 92. • Wikipediaより –https://ja.wikipedia.org/wiki/遅延シェーディング –遅延ライティング(Deferred Lighting) •ALAN WAKE •Halo:Reach など –遅延シェーディング(Deferred Shading) •KILLZONE 2, 3 •Battlefield 3 など –Deferred Shadingは多量のメモリを使用するため人気がない •えっ、ほんとう？ Deferred ShadingとDeferred Lighting
- 93. • そもそもこの2つの違いは？ –使い分けてない場合もあるのではないか？ –Light Pre-Pass Renderingと名乗る場合は明確に別 • Light Pre-Pass Renderingとは？ –各ピクセルにおける光のエネルギーの総量をライティングパスで求 める方法 –描画パスは2パスではなく3パスで行う • G-Buffer描画、ライティング、シェーディング –シェーディングパスはモデルをもう一度描画する • ライティングパスで求めた光の強さとマテリアル情報からシェーディ ングの結果を求める Deferred ShadingとDeferred Lighting
- 94. • ライティングパスの計算 –Lambertの拡散反射 • 𝐶 𝑑𝑖𝑓𝑓 = 𝐶 𝑚𝑎𝑡 𝐶𝑙 1 𝜋 (𝑁 ∙ 𝐿) • 𝐶 𝑑𝑖𝑓𝑓 = 𝐶 𝑚𝑎𝑡 𝐶𝑙1 1 𝜋 𝑁 ∙ 𝐿1 + 𝐶𝑙2 1 𝜋 𝑁 ∙ 𝐿2 + ⋯ = 𝐶 𝑚𝑎𝑡 1 𝜋 𝑖=0 𝑛 𝐶𝑙𝑖 𝑁 ∙ 𝐿𝑖 – 𝐶 𝑚𝑎𝑡はマテリアルカラー → マテリアルに依存 –それ以外の部分は法線、座標とライト情報がわかっていれば求めら れる Light Pre-Pass Rendering ① ②
- 95. • G-Bufferには法線のみ描画 –シーンの形状はこれで求められる • ライティングパスでは前述の式の②だけ求める –これをライティングバッファに保存する –各ライトごとに加算していけばいいので、ライティングバッファの ブレンドは加算合成 –スペキュラは強度のみ保存 → 詳しくは後述 • シェーディングパスでもう一度モデルを描画 –この際にライティングバッファの情報を取得 –前述の式の通り、マテリアルカラーと乗算して求められる Light Pre-Pass Rendering
- 96. • Deferred Shadingに対するメリット – G-Bufferは法線のみなので1枚で済む – 光のエネルギーに対してマテリアルがどう反応するかをシェーディングパ スで決定できる • シェーダを切り替えることで様々なマテリアルを表現可能 – PS3/Xbox360世代でもMSAAと併用できる • Deferred Shadingほどバッファサイズが増えない • Deferred Shadingに対するデメリット – 描画パスが増える • Z Pre-PassをG-Bufferパスと一緒にすればさほど問題はない – スペキュラ成分の計算が不正確 • PBRでは最大の問題 Light Pre-Pass Rendering
- 97. • Light Pre-Pass Renderingの発表当時のL-Buffer –Diffuse RGBは前述のLambert式の② –Specularはスペキュラ強度 • 例：Blinn-Phong 𝐶𝑠𝑝𝑒𝑐 = 𝐶 𝑚𝑎𝑡_𝑠𝑝𝑒𝑐 𝑖=0 𝑛 𝐶𝑙 𝑖 𝑁 ∙ 𝐻𝑖 𝑝 • 赤枠内をライティングパスで計算したい Light Pre-Pass Renderingのスペキュラ成分 Diffuse R Diffuse G Diffuse B SpecularL-Buffer 1
- 98. • RGB 3チャンネルを保存できない –Specularに割り当てられているのは1チャンネルのみ –ライトカラー𝐶𝑙 𝑖 をあらかじめ計算式に入れられない –Diffuse RGBからライトカラーの総和を推定する or ライトカラーを考慮しない • 𝑝はマテリアルのパラメータ –スペキュラの鋭さを指定するパラメータ –定数にする or ( (𝑁 ∙ 𝐻𝑖)) 𝑝 の計算式で対応 –どちらの手法でも相当問題あり Light Pre-Pass Renderingのスペキュラ成分
- 99. • Cook-Torranceモデルではより問題は複雑に 𝐼 = 𝐷 ∗ 𝐺 ∗ 𝐹 𝑁 ∙ 𝑉 • フレネル項(F項)を考える 𝐹 = 𝐹0 + 1 − 𝐹0 1 − 𝐿 ∙ 𝐻 5 • マテリアルパラメータとライト情報から求められる値を分離 できない – 𝐹0はマテリアルパラメータ – 𝐿 ∙ 𝐻はライト情報から求められる値 • 分布関数(D項)もラフネスなどのマテリアルパラメータが影響 する Light Pre-Pass Renderingのスペキュラ成分
- 100. • 多分、もう使われていない技術 –PBR全盛の今ではスペキュラが不正確すぎて使えない –L-Bufferを求める段階でライティング計算が決まってしまうので、 髪、布、肌、金属といったライティング計算自体が違うマテリ アルに対応できない –大量のオブジェクトを使用するシーンではジオメトリ描画を2回 行うのはコストが高い •Z Pre-Passと同時にG-Bufferを描画すれば少しはマシだが… • PBRを使わないゲームならまだ使えるかも… Light Pre-Pass Rendering
- 101. Z Pre-Passって何？
- 102. • 不透明描画パスにおいて、あるモデルが別のモデルに隠 される場合がある • 不要なピクセルのピクセルシェーダは起動したくない –しかし、ピクセルシェーダは起動してしまう Z Pre-Pass このピクセルでは後ろの赤い板は前面のグレーマンで隠される
- 103. • 理由その１：描画順序 –手前のグレーマンが描画された後に赤い板が描画されるなら隠され ることがわかる –しかし、赤い板から描画してしまうとグレーマンがどこに描画され るかわからない –では、手前の不透明モデルから描画すればいい？ • 理由その２：深度テストの処理順序 –描画パイプラインは以下のようになる Z Pre-Pass 頂点シェーダ ラスタライザ ピクセルシェーダ 深度テスト 描き込み –ピクセルシェーダの方が先に処理される！
- 104. • Early Depth Stencil Test –ピクセルシェーダよりも前に深度テストを行ってしまう機能 Z Pre-Pass 頂点シェーダ ラスタライザ ピクセルシェーダ深度テスト 描き込み – 深度テストを行う段階で深度バッファへの書き込みも行う – 現代のGPUではこの機能を有しているものが多い – 使用の際に注意しなければならない場合がある • ピクセルシェーダで深度値を修正する場合 • アルファテストを行う場合 • UAVを使用する場合 • 詳しくはCEDEC 2016「Unreal Engine 4のレンダリングフロー総おさらい」参照 – http://www.slideshare.net/EpicGamesJapan/cedec2016-unreal-engine-4
- 105. • Early Depth Stencil Testを最大限に活用する –手前から奥にモデルを描画するだけで対応できる？ •同一モデル内では効果がない –細かくドローコールを分ける？ •ドローコールが増えすぎてCPU負荷が高くなる •描画順序のソートもタダではない Z Pre-Pass このピクセルは左手・左足・右足が描画されている 同一ドローコールなので、左手のポリゴンが先に 描画される保証はない
- 106. • 重いピクセルシェーダが動く前に深度バッファが生成されて いればいい –これがZ Pre-Pass • 描画の開始時に深度バッファだけを描画する –ピクセルシェーダは基本的に起動しない • 深度値の修正、アルファテストをする場合のみ起動 • ドローコールが2倍になって重くならないか？ –Forward Renderingではほとんどの場合で効果絶大 –Deferred Renderingでは状況による？ • 経験上、Z Pre-Passを使った方が高速 • ドローコールが多すぎる場合にCPUコストが大きくなる恐れ Z Pre-Pass
- 108. • Deferred Renderingのボトルネックは？ –1つのライトが影響を与えるピクセルすべてでピクセルシェーダが 起動する –ピクセルシェーダ1回の処理ごとに1回のG-Bufferアクセスが発生す る • 複数ライトが1つのピクセルに影響を与えた場合、 G-Bufferサンプリングはライトの数だけ発生 • サンプリング回数が増えるとメモリ帯域を大量に消費 –同一ピクセルでのG-Bufferサンプリング結果は同一 • 無駄なサンプリングは減らしたい • Tile-based Deferred Rendering誕生 Tile-based Rendering
- 109. • 図のようなフラスタムを仮定する Tile-based Deferred Rendering
- 110. • 図のようなフラスタムを仮定する • スクリーンをタイル状に分割する –タイルの大きさは16x16ピクセルなど Tile-based Deferred Rendering
- 111. • 図のようなフラスタムを仮定する • スクリーンをタイル状に分割する –タイルの大きさは16x16ピクセルなど • タイルごとに小さなフラスタムが作成される Tile-based Deferred Rendering
- 112. • 図のようなフラスタムを仮定する • スクリーンをタイル状に分割する –タイルの大きさは16x16ピクセルなど • タイルごとに小さなフラスタムが作成される • タイルフラスタムごとにライトとの接触判定を取る • タイル内のすべてのピクセルで接触したライトを計算する Tile-based Deferred Rendering
- 113. • ジオメトリパス – 通常のDeferred Renderingと同様 • ライティングパス – ライト情報を配列としてバッファに保存しておく • シェーダからアクセスできるように – 画面すべてのピクセルに対してコンピュートシェーダを起動する • ピクセルが所属するタイル内の最大・最小深度を求める – これらがフラスタムの最大・最小深度となる • タイルのフラスタムとライトの接触判定を行う • 接触したライトの情報を共有メモリに保存する – コンピュートシェーダのスレッド単位で参照可能なメモリ • 各ピクセルが所属するタイルのライト情報を参照し、ライティング計算を行う Tile-based Deferred Rendering
- 114. • タイルの最大・最小深度を求め Tile-based Deferred Rendering
- 115. • タイルの最大・最小深度を求める Tile-based Deferred Rendering 塗りつぶし範囲外のライトは計算不要
- 116. • フラスタムとライトの接触判定 Tile-based Deferred Rendering 接触しているので計算される 最大・最小範囲外は計算されない
- 117. • 接触したライトを共有メモリに出力 –ここまでタイルごとの処理 Tile-based Deferred Rendering 1 2 3 4 5 6 7 8 2 3 4 5 6 共有メモリ
- 118. • ピクセルごとにライティング Tile-based Deferred Rendering 2 3 4 5 6 共有メモリ ライト 1 ライト 2 ライト 3 ライト 4 ライト 5 ライト 6 ライト 7 ライト 8 ライト情報 ライティング！ タイル内のすべてのピクセルにて
- 119. • この手法で高速化可能なのか？ –条件によっては高速化するが、逆に遅くなることもある • ライティング計算を行うピクセル数は増える –図の赤のピクセルはライト計算の必要がない –深度方向でも同様の問題は発生する Tile-based Deferred Rendering
- 120. • G-Bufferのサンプリング回数は減る –各ピクセルごとにG-Bufferのサンプリング回数は1回 • コンピュートシェーダは各ピクセルごとに1回しか起動しない • この1回で影響のあるライトすべての計算が終了する • 昔試したサンプルでの話 –通常とTile-basedを比較すると、ライト数に大きく左右された –数100のオーダーではTile-basedが有利 • 数10のオーダーでは通常のDeferredが有利 • 1024個の場合はTile-basedが圧倒的に速い(500fps→800fps) –ライトの影響範囲も関わってくる • 概ね、ライト数が多くなるとTile-basedの方が有利 Tile-based Deferred Rendering
- 121. • タイルごとにライトをリストアップできるなら、 Forward Renderingでもそのリストを使用できないか？ –AMD 原田隆宏氏らがEurographics 2012でForward+を発表 •https://sites.google.com/site/takahiroharada/storage/EG2012takahiroHa rada.pdf –また、後に同氏らによって改良版であるForward++が発表されて いる •https://sites.google.com/site/takahiroharada/storage/2012SA_2.5DCullin g.pdf Forward+ Rendering
- 122. • Forward+のレンダリングの流れ –Z Pre-Passは必ず行う • タイル毎のフラスタムサイズを最小にするため –ライトリストはリンクリストで保存される • 必要な情報はライトのインデックス番号のみ –Forward Renderingパスでは基本Early Depth Stencilを有効 • 余分なピクセルの計算を行わないため –各ピクセルが所属するタイルのライトリストに従って 必要なライトの計算を行う • 通常のForwardより計算量は圧倒的に少ない Forward+ Rendering Z Pre-Pass タイルごとのライトリスト作成 Forward Rendering
- 123. • Tile-basedのライトカリングで最悪な状況とは？ –タイルごとに最大・最小深度の差が大きい場合 –例：樹の葉、草など • このような状況を回避するためにForward++が生まれた Forward++ Rendering 手前の葉っぱと奥の壁までのサイズの タイルフラスタムが作成される
- 126. • 深度の存在するセルとライトの接触判定を行う –ビット演算で比較的高速な判定が可能 • 接触したライトのみライトリストに追加 –以降の処理はForward+と同様 Forward++ Rendering 0 6 2 3 4 5 1 7 接触していないと判断されるライト
- 127. • どちらが高速か？ –Tile-based Deferredの方が高速な印象 • シーンによるかも • 以前作ったサンプルではTile-based Deferredの方が高速 • Forward+にはForward Renderingのメリットがある –デメリットである多光源もDeferredほどではないが十分高速に動作 する • 半透明に対してもライトリストは利用できる –ただし、その場合はForward++は利用できない • Forward+は採用事例が存在しない？ –自分が知る中では –知ってる人がいらっしゃいましたら教えてください Forward+ vs Tile-based Deferred
- 128. • Tile-based DeferredとForward+は共存が可能 –不透明はTile-based Deferred、半透明はForward+ • コンピュートシェーダでのライティングパスで、 ライトリストを共有メモリとバッファに出力 –共有メモリ側はTile-based Deferredで使用 –バッファ側はForward+で使用 • 某社のゲームエンジンで採用していたとか –残念ながらそのエンジンは日の目を見ていない… Tile-based DeferredとForward+の共存
- 130. • Tile-basedの改造版 –HPG 2012で発表された論文 「Clustered Deferred and Forward Shading」 • http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication &id=clustered_shading –タイルより細かなクラスタという単位でライトリストを生成 • タイル分割した後、深度方向にフラスタムを分割 • 各ピクセルの深度情報からクラスタに割り当て • クラスタごとにライトリストを作成 • 実際にはデータ圧縮など、ちょっと複雑な手法を採用している –Deferred、Forwardの両方に対応できる –100万光源をリアルタイムに処理できる Clustered Rendering
- 131. • ゲーム向けの簡易な実装 –Avalanche StudiosのEmil Persson氏がサンプルを公開している •http://www.humus.name/index.php?page=Articles&ID=7 –同社の『Just Cause 3』で実装 –日本では『バイオハザード7』で使用されている •https://cedil.cesa.or.jp/cedil_sessions/view/1488 –フラスタムを3次元に分割してクラスタを作成する •ピクセルをクラスタに割り当てる前にライトリストを作成する •ライトリストを使ってDeferred or Forward Rendering •ライトリストは半透明にも使用可能 Clustered Rendering
- 132. • フラスタムを3次元で分割 –スクリーン平面は一律に分割 •通常のタイル分割 –深度方向は対数分割 •一律分割より効率が良い • ライトとクラスタの接触判定 –深度バッファやG-Bufferは不要 •非同期コンピュートで ラスタライザと並列動作可能 Clustered Renderingの実装
- 133. • ライトリストの作成方法 –Forward+と同様のリンクリスト • アトミック操作が頻繁に発生 –複数スレッドでの同期操作のようなもの • ライト数を柔軟に変更できる • バッファサイズが確定しづらい –ライトインデックスに対応するフラグ操作 • Emil Persson氏の実装 • ライトの最大数は固定され、あまり多く取り扱えない –バイオハザード7では512個まで • バッファサイズも固定されるので扱いやすい • 速度はリンクリストより(多分)高速 Clustered Renderingの実装
- 135. これからの話
- 136. • 4k, 8k時代の到来 –PS4 Proでは4kに対応、来年末予定のScorpioも4k対応 PCはすでに4kでゲームが動いている • 8kも割と近い未来？ • VR HMDへの対応 –PSVRの発売で一般化する可能性 –解像度は両目を合わせるとフルHD以上 • その上、高フレームレートとその安定を要求される –スタンドアローンHMDも今後出てくる • Hololens, Sulon Q, Oculusの試作機など • PC接続のHMDよりスペックは低くなる？ これからの話
- 137. • Deferred Renderingで対応できる？ –厳しくなってくる可能性が高い –Oculus社はVR用にUE4にClustered Forward Rendererを組み込んだ •現在はEpic社が自らForward Rendererを組み込んでいる •まだ使うのは控えた方がいいらしいが… –4kになるとG-Bufferのサイズは4倍 •消費するメモリ帯域も単純計算で4倍 –新しいレンダリング手法が求められている •例：Visibility Buffer これからの話
- 138. • GDC Europe 2016で発表されたForward Renderer –発表者はWolfgang Engel氏 • Light Pre-Pass Renderingを発表した方 • GPU Proの編纂者 • いろんなゲームエンジンのレンダリングに関わってるらしい –CryEngineとか –http://www.gdcvault.com/play/1023792/4K-Rendering-Breakthrough- The-Filtered • 4k時にDeferred Rendererの半分のバッファサイズで済む –比較対象は現在のFrostbite Engine –使用するバッファは32ビットのVisibility Bufferと頂点バッファ • 頂点バッファは解像度に依存しない Visibility Buffer
- 139. • Visibility Buffer生成パス –モデルを描画 –Visibility Bufferにそのピクセルに描画されたトライアングルの情 報を格納 •論文によると –Alpha masked bit：1ビット –Draw ID：8ビット –Primitive ID/Triangle ID：23ビット Visibility Bufferの実装
- 140. • シェーディングパス –Visibility Bufferの内容を取得 –トライアングル情報から座標、法線、UVなどを計算 –頂点情報内のマテリアルIDから必要なマテリアル情報を取得し、 シェーディングを行う • ライトの選択は？ –Clustered RenderingかTile-basedで選択しておくと良い Visibility Bufferの実装
- 141. • デフォームするモデルはどうする？ –ボーンによる変形、頂点ブレンドなど –コンピュートシェーダで変形したトライアングルを毎フレーム 生成する •同じオブジェクトを大量に描画する場合は頂点バッファサイズが心 配 • テッセレーションは？ –Visibility Buffer生成パスでトライアングルになっているので、こ れを頂点バッファに出力する？ Visibility Bufferの疑問
- 143. • 論文より • 速度面ではDeferredより高速 –ESRAMの制約があるXboxONEでも使用できる • サンプル公開するって話だったけどまだぁ？ Visibility Bufferの有効性
- 144. • パーティクル描画が重くなる –高解像度では特に問題 • パーティクル量が増えると同じピクセルに何度も描画が行われる • 消費メモリ帯域アップ • ピクセルシェーダの起動回数アップ –縮小バッファを使う • 4kに対する1/4縮小バッファは1080p • 現在でも1080pフルにパーティクル描画するの大変なのに… • ボリュームのあるパーティクルでは顕著に –厚みを出すためにパーティクル量が増える –ライティングをして重厚感を出すため、ピクセルシェーダが重い これからの話
- 146. • 新生DOOMの例 – テクスチャアトラスを利用してパーティクルライトバッファにライティン グ結果を描画 • パーティクルごとに重ならないようにバッファにアトラス化 • パーティクルライティングの結果をバッファに描画 – フレームバッファへの描画時にライティング結果を参照 • ライティングが解像度に依存しない • 下の画像は1パーティクルにつき64x64サイズ – http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/ パーティクルの描画
- 147. • レイトレで解決する未来 –レイトレが使用できると半透明、シャドウなど、様々な問題が一気 に解決する –しかし、まだ来ない • 解像度の影響が非常に大きいため、4k, 8kが厳しい • ソフトウェアレンダラの未来 –GPUが完全に汎用的になる • ラスタライザがハードで対応しない • 必要なレンダラは自分で作る –CEDEC 2008でTim Sweeney (Epic Games) が10年後の未来と言ってた • あと2年！ これからの話
- 148. まとめ
- 149. • Deferred Renderingは全盛だけど万能ではない –欠点多い –しかし、多光源を扱う上では圧倒的に高速 •Traditional Forwardでは逆立ちしても対抗できない • 最近は多光源を扱えるForward Renderingも登場 –Tile-based, Clustered –速度だけを考えるとDeferredの方が速いかも •Forwardの特徴を活かせる利点とのトレードオフ まとめ
- 150. • 4k, 8kへの対応は近い将来、確実にやってくる –4kはもう対応し始めなければならない –8kも割と近いかも？ • VRへの対応も必要 –両目用の映像を別々に生成しなければならない –立体視特有の問題もある –高フレームレートを維持しなければいけない まとめ
- 151. • 他にも考えなければならないことも –Global Illumination –Shadow • 最終的に重要なこと –自分が表現したいものに合わせて技術を選ぶこと • 表現したいものが曖昧だと適切な選択は難しい • すべてが決まっている必要はないが、軸がぶれるとあとで困る –困ったらエンジニアに相談 • ～って出来る？と聞くのはあまりお勧めしない • こういう表現をしたい！と聞くとアイデアを出してくれることが多い まとめ
Editor's Notes
- ヒアリングはエフェクト班にはあまり行われないか、行われても優先度が下がる傾向にある気がする エフェクトの人はどんな環境でも割と何とかしてくれるからね、とか思ってるエンジニア、実は多いんじゃない？ …ごめんなさい
- 補足 ドローコールは様々な理由で分割される 例えば、メッシュ単位の表示/非表示を行う場合にドローコールを分ける 手にボーンが入っていないのでグーとパーの手を切り替えたい場合、腕と一緒に描画できたとしてもドローコールは分ける必要が出てくる
- 補足 英語ではRender Passと、Render Pathで記述が分かれる どちらでググっても出てくるが、どちらも似たような意味 また、描画全体の流れを描画パスと呼ぶ場合もあって、会社や人によって微妙に意味が違ってくるかもしれない しかし、Deferred RenderingではG-Bufferを描画する処理をジオメトリパス、ベースパスと呼び、ライティング/シェーディング処理をライティングパス、シェーディングパスと呼ぶことが多い
- 1回の描画の流れで絵が出来る モデルを描画パイプラインに投入すると最終的な絵がそのまま出てくる
- この段階では最終的な絵は描画されない このあとにライティングパスが走って最終的な絵が出来る
- ここまででForwardとDeferredの特徴を軽く見ていきました。 ここからはQ&A形式で、より詳しく掘り下げていきたいと思います。
- 頂点シェーダからピクセルシェーダまでの流れはRT枚数に関係なく1回だけ行われる 複数のRTへの出力はピクセルシェーダで指定する ブレンド手法はRTごとに変更することが可能
- 個人的にはPS2の呪縛だったのかな、と思っている
- 裏面描画の場合は後ろ側の半球だけが描画される
- 3本のラインのうち、球の裏面が描画されるのは一番上のみ 一番上だけがステンシル値を1に変更する
- 表面の描画では上2本のラインが描画される 下の1本は描画されない また、一番上はステンシル値が1で、真ん中はステンシル値が0
- ステンシル値が0であり、かつ表面が描画されるピクセルのみライティングが行われる この例では真ん中のラインだけが条件を満たしている
- この画像はmodoでレンダリング。 レイトレーシングの結果だが、現実の現象に則している。
- この画像はPaint.netで加工。 ポリゴン単位ではこのようにならないが、イメージはこんな感じ。
- 全く無関係の2つ以上のモデルが1つのピクセルのサブピクセルに存在した場合、そこに格納されている法線には連続性がないので、この段階でリゾルブできない
- 資料から読み取った結果ですが、間違ってたら教えてください。
- 横スクロールゲームでは多重スクロールっぽい表現がやりやすくなる
- Pre-Zとも呼ばれる UAVはUnordered Access Viewの省略形 DX11以降で使える、シェーダで読み書きを自由に行えるバッファ 通常は使わないが、特殊な描画を行う場合に使用されることがある
- このような1つのタイルのフラスタムを考える このフラスタムにおいて、奥のオブジェクトは見えないが、手前2つのオブジェクトは見えている つまり、奥側のオブジェクトにしか当たらないライトは計算の必要がない
- 実際に必要なフラスタムの範囲はこうなる
- 手前と奥の不要な部分を除いたフラスタムとライトの接触判定を行う
- 接触したライトの番号を共有メモリに出力する
- タイルの情報はここまでで取得できたので、タイル内のすべてのピクセルでタイルに接触したライトとのライティング計算を行う
- この図は対数分割していない
- バイオハザード7はEmil Persson氏の実装を参考にしている Oculus社が独自のForward RendererをUE4に実装したときもEmil氏のものと同じような実装