「遅延レンダリング」の版間の差分
Administrator (トーク | 投稿記録) |
Administrator (トーク | 投稿記録) |
||
| (同じ利用者による、間の3版が非表示) | |||
| 8行目: | 8行目: | ||
ドローコール数 = モデル数 x ライト数 | ドローコール数 = モデル数 x ライト数 | ||
| − | + | 一方、シンプルな遅延レンダリングでは以下のような感じになる。 | |
ドローコール数 = 初期化x3 + モデル数x3 + ライト数 + 結合処理 | ドローコール数 = 初期化x3 + モデル数x3 + ライト数 + 結合処理 | ||
| − | 太陽光など[[平行光源]]が1個しかない状況では[[フォワードレンダリング]] | + | ちなみに「x3」の部分は[[マルチプルレンダーターゲット]]を利用すれば「x1」にすることができる。 |
| + | ドローコール数 = 初期化 + モデル数 + ライト数 + 結合処理 | ||
| + | |||
| + | |||
| + | 太陽光など[[平行光源]]が1個しかない状況では[[フォワードレンダリング]]の方が圧倒的に有利だが、街灯などの[[ポイントライト]]が何個もある状況では遅延レンダリングの方が有利である。 | ||
{| class="wikitable" | {| class="wikitable" | ||
|+ | |+ | ||
| 81行目: | 85行目: | ||
| − | + | この遅延レンダリングの特性から2000年代中頃あたりに「夜中に作戦行動する[[右下から銃の生えたゲーム]]」で大流行した。遅延レンダリングといえばだいたい「夜」である。採用例のほとんどが非常に暗いゲームばかりなので日本では人気がないものばかりです。 | |
== 欠点 == | == 欠点 == | ||
| 91行目: | 95行目: | ||
=== メモリ使用量が多い === | === メモリ使用量が多い === | ||
| − | + | シンプルな遅延レンダリングの実装でもざっくり[[フォワードレンダリング]]の4倍の[[メモリ]]が必要になる。 | |
実装によっても異なるが、だいたい以下のような構成のスクリーンサイズの[[レンダーターゲット]]が必要になる。 | 実装によっても異なるが、だいたい以下のような構成のスクリーンサイズの[[レンダーターゲット]]が必要になる。 | ||
| 103行目: | 107行目: | ||
=== メモリ帯域が必要 === | === メモリ帯域が必要 === | ||
| − | + | 前述の遅延レンダリングではメモリ使用量が多い問題に関連して、遅延レンダリングではメモリに頻繁に読み書きするためメモリの速度が遅いとかなり残念な結果になります。 | |
| − | + | ||
| − | とくに[[ | + | とくに[[スマートフォン]]では非常に低速な[[メインメモリ]]の一部を[[VRAM]]として利用するため問題になることが多いです。むしろまともに使える機種は無いと考えた方がいいです。 |
| + | |||
| + | [[ローエンド]]や[[ミドルレンジ]]の[[スマートフォン]]や[[タブレット]]の[[コストカット]]はだいたい「カタログスペックに現れにくいメモリ帯域周り」と相場が決まっています。素人は「メモリ容量」しかみないからね。 | ||
==手順== | ==手順== | ||
2023年9月12日 (火) 02:05時点における最新版
遅延レンダリング（英語：Deferred Rendering）とは、3DCGにおいて、物体の描画とライティングを別々に行う技法である。こいつの登場により従来型のレンダリングは「フォワードレンダリング」と呼ばれるようになった。
目次
利点[編集 | ソースを編集]
ドローコールの削減[編集 | ソースを編集]
遅延レンダリングではシーンの中にポイントライトなどを多数配置してもドローコールがあまり増えないという特徴がある。
フォワードレンダリングでのドローコール数は以下のようなモデルとライトの掛け算である。
ドローコール数 = モデル数 x ライト数
一方、シンプルな遅延レンダリングでは以下のような感じになる。
ドローコール数 = 初期化x3 + モデル数x3 + ライト数 + 結合処理
ちなみに「x3」の部分はマルチプルレンダーターゲットを利用すれば「x1」にすることができる。
ドローコール数 = 初期化 + モデル数 + ライト数 + 結合処理
太陽光など平行光源が1個しかない状況ではフォワードレンダリングの方が圧倒的に有利だが、街灯などのポイントライトが何個もある状況では遅延レンダリングの方が有利である。
| モデル数 | ライト数 | ドローコール数 | 備考 | ||
|---|---|---|---|---|---|
| フォワード | デファード | デファード+MRT | |||
| 1 | 1 | 1 | 8 | 4 | |
| 10 | 1 | 10 | 35 | 13 | ライトが少ないときはフォワードレンダリングが有利 |
| 10 | 2 | 20 | 36 | 14 | MRTありが逆転 |
| 10 | 4 | 40 | 38 | 16 | MRTなしも逆転 |
| 10 | 8 | 80 | 42 | 20 | |
| 10 | 16 | 160 | 50 | 28 | |
| 10 | 32 | 320 | 66 | 44 | |
| 10 | 64 | 640 | 98 | 76 | |
この遅延レンダリングの特性から2000年代中頃あたりに「夜中に作戦行動する右下から銃の生えたゲーム」で大流行した。遅延レンダリングといえばだいたい「夜」である。採用例のほとんどが非常に暗いゲームばかりなので日本では人気がないものばかりです。
欠点[編集 | ソースを編集]
MSAAが使えない[編集 | ソースを編集]
遅延レンダリングでのライティング処理は「2D画像処理」であり、その時点で「ポリゴンのエッジの情報」は喪失している。このため「ポリゴンのエッジの情報」を用いてアンチエイリアシングを行うMSAAは使えない。
フォトショップなんかにある「エッジ抽出」をリアルタイムに行い、強引にアンチエイリアシングするという手法もあるが絶望的に効率が悪い。そのような状況下で少しでも性能を向上させようと、MLAA、FXAA、TXAA、SRAA、DSAA、ポストMSAAなど様々な手法が考案されている。
メモリ使用量が多い[編集 | ソースを編集]
シンプルな遅延レンダリングの実装でもざっくりフォワードレンダリングの4倍のメモリが必要になる。
実装によっても異なるが、だいたい以下のような構成のスクリーンサイズのレンダーターゲットが必要になる。
- Gバッファ
- Color
- Normal
- Depth
- Lighting処理用バッファ
遅延レンダリングが流行りだしたころのパソコンやゲーム機は「メインメモリ256MBのVRAM32MB」などであったため結構悩ましい問題であった。最近ではパソコンどころかスマホでさえもアホみたいにメモリを積んでいるので問題になることはまずない。
メモリ帯域が必要[編集 | ソースを編集]
前述の遅延レンダリングではメモリ使用量が多い問題に関連して、遅延レンダリングではメモリに頻繁に読み書きするためメモリの速度が遅いとかなり残念な結果になります。
とくにスマートフォンでは非常に低速なメインメモリの一部をVRAMとして利用するため問題になることが多いです。むしろまともに使える機種は無いと考えた方がいいです。
ローエンドやミドルレンジのスマートフォンやタブレットのコストカットはだいたい「カタログスペックに現れにくいメモリ帯域周り」と相場が決まっています。素人は「メモリ容量」しかみないからね。
手順[編集 | ソースを編集]
1. Clear GBuffer[編集 | ソースを編集]
Color, Normal, Depthなどからなる「GBuffer」を初期化する。
2. Draw GBuffer[編集 | ソースを編集]
GBufferに描画する。この時点ではまだライティングは行わない。描画時にライティングを行わないから「遅延レンダリング」という。
3. Lighting[編集 | ソースを編集]
GBufferと各種ライトを掛け合わせて「ライティング結果」を生成する。
4. Combine[編集 | ソースを編集]
GBufferとライティング結果を合成して最終的な絵が完成する。
