ここで分かりやすいのは、まず、シャドウ マップの解像度が低い場合、シャドウ マップ自体のエッジがギザギザになります。そして、このノコギリ歯をシャドウマップにサンプリングして影の過程を計算するのですが、実際にはシャドウマップのシルエットに光を当てることで生成される影とみなすことができます。
シルエットに光を当ててもシルエット自体がギザギザになり、生成される影も自然とギザギザになります。または、サンプリングしたシャドウマップがギザギザであることを直接理解するだけです。これは、シャドウが突然変化することを意味します。これにより、エイリアシングが導入されます。
または、生成されたスクリーン スペース シャドウ マップがギザギザであることを直接理解するため、乗算後にギザギザが発生します。
ここで、このようなギザギザの影を得るには、1 つの操作はシャドウ マップの解像度を下げることであり、もう 1 つのポイントはカスケードではありません。カスケードは分類を意味するため、近くのオブジェクトには比較的解像度の高いシャドウ マップが使用され、遠くのオブジェクトには低解像度のシャドウ マップが使用されます。これは、エイリアシングをある程度軽減するのにも役立ちます。
ここでの効果を改善する方法は、影の距離を調整することです。
シャドウ距離は、シャドウ マップの生成時にキャプチャされるシーンのサイズに影響します。
この値がそれほど大きくない場合は、シャドウマップでどのくらい離れたシーンが見えるかを考慮する必要がないため、正投影時にこれらの遠くのシーンを考慮する必要はありません。
このようにして、周辺全体のシャドウ マップが大きくなります。これは、近くのシャドウ マップのより高い解像度に相当します。同じ解像度でより少ないコンテンツをレンダリングしているため、そのコンテンツはより高い解像度を使用します。
解像度が高くなると、シャドウ マップ自体のエイリアシングが緩和され、自然に生成されるシャドウのエイリアシングも緩和されます。
この品質の向上はカスケードの使用によるものであるため、近距離シャドウマップの生成には比較的高い解像度が使用されます。したがって、エイリアシングの影響は少なくなりますが、距離が長くなるにつれて、サンプリング解像度が徐々に低下し、エイリアシングが徐々に明らかになります。ただし、遠くになるほどシーン ビューに表示されるサイズが小さくなり、結果がわかりにくくなりますが、それでも効果は大幅に向上します。
ここで話しているのは、カスケード レベルを表示することです。
ここで表示モードを変更できます。
ここでは、カスケード グレーディング基準を設定できます.前者はカメラからの距離に基づいており、これは直接深度に基づいています. カメラ空間の z 値である必要があります。
カメラの動きの場合の 2 つの構成の違いを次に示します。最初の安定したフィット感としては、効果は比較的良好で、レベルの端に注意を払わない限り、問題はありません。
しかし、ぴったりとフィットしているとうまくいかず、運動中にシャドー エッジ スイミングが発生します。
ここで光源は上から下にあると考えることができ、灰色の上面は光源に最も近い点と見なすことができますが、それは点ではなく、テクセルであり、テクセルは領域. これは問題です. 上部は 2D に投影されたものです.上面を見てください, そのうちのいくつかは表面に直接突き刺さったり, 通り抜けたり, 表面から出たりしています, つまり, 灰色の上面の線, その一部はグリーンの外にあり、一部はグリーンの内側にある。
このように、カメラの視点から緑色のオブジェクトを見ると、実際には上部の 2 つの面が直接光に照らされており、影がないはずですが、奥行きと奥行きを比較すると、ある場所の深さを、保存されているシャドウ マップに従って判断すると、影にあると判断されます。
そのため、表面の影のバグがあります。
ShadowMap での影ニキビ現象の説明 - Zhihu (zhihu.com)
こちらの方が分かりやすいのですが、
グラフィックス レンダリングの基本 (6) リアルタイム シャドウ - ナゲット (juejin.cn)
ここでのもう 1 つの理由は、精度の問題です。ここではフロートが前後に変換され、必然的に精度がいくらか失われるため、影での判断ミスにつながる可能性があり、上のニキビにもつながります。しかし、上記は、短い距離を使用する場合、これを取得するのは実際には非常に簡単ではないことを述べています
もちろん、解決策はバイアス オフセットを使用することです。また、各ライトは独自のバイアスを個別に設定できます。
ここでのバイアスの設定も注意が必要です. 大きすぎると, 上記の効果, ピーターパンニングにつながります. 主な理由は、シャドウマップにバイアスオフセットを作成したことです. 実際には, それはシャドウ マップ全体の深度が遠ざかると、自然に生成されたシャドウも遠くに押し出され、オブジェクトとシャドウが接続されますが、それらは接続されません。
バイアスオフセットについてです。もう 1 つは、通常の考え方に沿ったもので、対応する欠点もあります。
最後に、バイアスの選択方法と具体的な値の設定は、状況に応じて決定する必要があります。統一基準はありません。
ここでのアンチエイリアシングの問題は、基本的に、MSAA が三角形のエッジのないスクリーン スペースのシャドウマップには役に立たないように見えることを示しています。理解できない
ここで強調しておくべきことが 1 つあります. 実はバイアスがもたらすものは影のオフセットとは言えません. 上記によると, 彼はボールを光の方向に沿って押します. 影はどのような動作を引き起こしますか?
実は現在のボールが実空間で光の方向に沿って移動していることに相当します.このときの影はバイアスのオフセット後の影に相当します.移動すると,ボールは直接地面に触れます.その後、徐々に水没するので、彼の影は徐々に小さくなり、最終的には消えます。
また、ボールが十分に高い場合、床に投影された影は、バイアスが増加しても効果がありません。十分に高いので、光の方向に沿って移動し、光の方向に沿って投影すると、結果は同じですが、光の方向に沿った距離が床との接触に達すると、バイアスが再び増加し、影のサイズと位置がそれに応じて変化します。
実際、線形バイアスを実装する場合、それは
UnityApplyLinearShadowBias — Unity でシャドウ バイアスを計算する方法 |
Unity 標準シェーダーのテクニカル分析 - Zhihu (zhihu.com)
おそらくここで理解できます。最初に一般的なプロセスについて話しましょう。Shadow Caster で何をするつもりですか?
プロセス全体が最初にシャドウ マップを生成し、シャドウ マップが生成されると、このパスが機能し、このパスがシャドウ マップの生成に使用されることをフレーム デバッガーで確認できます。
シャドウ マップは光源に向けられているため、光源に面しているすべてのオブジェクトは、シャドウキャスター パスを持っている限り、この時点でシャドウ キャスターを通過し、深度テストもここで実行され、結果は次のようになります。やっとシャドウマップに書き込めました。
次に、オブジェクトごとに、頂点をクリッピング空間に変換し、バイアスをオフセットしてワールド空間に戻し、深度値を判断して生成に参加するかどうかを決定します。深度マップ。
したがって、バイアスのタイミングは射影空間にあり、当然次のようになります。
最初の文は分かりやすく、透視投影を補うための文です。
詳細に関係なく、バイアスは遠近空間のオフセットであるため、オブジェクトがこの空間のどこにあるかに関係なく、オフセットは同じである必要がありますが、非線形空間のため、直接オフセットする場合は異なる必要があります。 1つの補償が必要です。
補償が完了した後、アウトオブバウンズを防ぐという問題もあります。最後のポイントは、光源の種類の分類です。
次に、法線を使用してバイアスを実行します。これは、法線の方向に沿って内側に収縮することです。
特定の収縮は、主に光と法線の間の角度に関係しています。
私たちの影ニキビは傾きが原因なので、正対すればかなり緩和されるので、ここでは傾きが比較的大きい場合はオフセットのバイアスが大きくなり、角度が小さい場合はその逆になります。
そのため、ここでは角度に比例する sin 関数をスケーリング比として使用します。
さらに、ここでの解決策は、ワールド空間で通常のオフセットの後に線形オフセットを実行することです。
ここで ShadowScreen を定義し、Attenuation を再度入力すると、影関連の計算が行われます。サンプリングの際、ここで問題が発生します。これは、0 を渡したため、その時点では影が考慮されていないためです。
彼のセットは、Unity 独自のシャドウ アルゴリズムです。
理由はわかりませんが、影を受け入れるように記述し、オブジェクトに近づいた後、影マップを直接レンダリングします。
上記の状況は、ForwardBase を追加することで解決できます. 前述のように、これを定義しなくても実行できますが、一部のマクロが異常に割り当てられることがよくあります。
複数の影の問題については、まず、複数の光源を使用する場合、設定を確認する必要があります: ピクセルごとのライトの数. 複数の光源で遊ぶ場合、0に変更されました. その後、システムはデフォルトではピクセル単位のライトを 1 つだけ与えるため、その他は頂点ごとまたは球面調和ライトであり、影がないように見えます。
とにかく、実験の結果、標準マテリアルは頂点の影や球面調和照明をサポートしていません。次に、ピクセルあたりのライトの数を 4 に変更すると、標準マテリアルに複数の影を直接設定できます。
すべての球はすべての頂点 + メインの平行光 (平行光である必要があります。そうでない場合は 0 と見なされ、空のベースを通過します) と調和し、ベース パスを通過し、残りのピクセルごとのライト、それぞれに追加パスがあります。
光源を追加した後、デフォルトで影がない場合がありますが、これには注意が必要です。
次に、独自のマテリアルでこの種のマルチ シャドウをサポートする場合は、次を追加する必要があります。
ここで SHADOWS_SCREEN または上記のプリコンパイル済み命令を追加できます。違いは、前者は平行光のマルチ シャドウのみを提供し、後者は任意の照明タイプを使用できることです。
点光源の影はSHADOW_CUBEが必要なので、ここにプリコンパイル命令を追加します。
くそー、ここにヘッダーファイルを含めると混乱する可能性がありますが、幸いなことに、今では明らかです。注意すべき点は次の 2 つだけです。
まず、インクルードの順序が最初に A、次に B であることがわかりますが、実際には必ずしもそうではありません.おそらくファイルのネストのために、B は以前にインクルードされており、別のものを最初にインクルードする場合は Aそして B の場合、最終結果は依然として B ファーストです。そのため、インクルードする前に、以前のヘッダー ファイルをインクルードすることに注意してください。
第二に、ここでのデコード コードは実際には明示的に呼び出されたわけではありません. この関数は誰によって呼び出されますか? これは base と add のパスで呼び出される必要があります. これにはシャドウマップのサンプリング操作が含まれます.このパスのヘッダー ファイルに苦労しましたが、結局役に立ちませんでした。
Unity のいわゆるソフトシャドウはフィルターですが、ここではフィルターでさえありません。
これはキューブマップに格納されているため、フィルタリングする方法はありません。ここで使用された 4 つのサンプリングと平均の検索は、実際にはある程度フィルタリングされていますが、4 つのサンプリングはフィルタよりも多くを消費します。
これが実際のフィルターの結果です。
Unity によってパッケージ化された一連のマクロを使用する代わりに、自分でサンプリングを実装する場合、一般的なプロセス: サンプリングの座標を宣言し、次にサンプリング座標としてクリップ スペース座標を取得する必要がありますが、いくつかの変換が必要です。クリッピング スペースへの注意 パースペクティブ分割はなく、最終的な目標はサンプリング用の画面座標を取得することです。
しかし、ここでは補間と透視分割を行います。まず補間を行い、次に透視分割を行う必要があります。必要な画像は遠近法であるため、遠近法空間で補間してから除算します。（具体的には、私はあまり明確に考えていません）
ハイライトについて：
事前操作のない深度パスは、深度マップを生成します。事前にシャドウマップのみを生成してください。
これは特定の場所と関係があるため、投影も透視投影であり、当然カスケードは使用できません。
投影に関しては、主なものは、バイアスが少しあるということです.通常のバイアスは平行ライトでのみ使用でき、ポイントライトとスポットライトは線形バイアスのみです.の効果)
サンプリングに関しては、スクリーン座標空間にシャドウ マップはなく、通常のシャドウ マップのみであるため、モデルからワールドに変換し、ライト パースペクティブの下でパースペクティブ空間に変換してサンプリングを行う従来のものです。
線形バイアスの場合: 最初にモデル空間からクリッピング空間に変換し、次にバイアスし、最後に出力します。
ノーマル バイアス、モデル空間、ワールド空間、ノーマル バイアス、クリップ空間に、リニア バイアス インターフェイスを適用し、クリップ空間からリニア バイアスを出力します。
————————————————————————————————————————————————— —————————————————————————————————————————————
レンダリング 8
まず第一に、これが私たちがこれを研究したい理由です。つまり、以前の PBR によって書かれた材料は、粗い表面には非常に良い効果がありますが、滑らかで金属が高いと腐ってしまいます。効果が完全になります。
実際、核となる質問は次のとおりです。
滑らかな金属オブジェクトの場合、拡散反射はほとんどなく、鏡面反射は特定の小さな角度でのみ観察できます。これは、主に次の理由で確認できます。無数の周囲光、あらゆる方向からの周囲光は、反射によって人間の目に入ります。
正確には、環境光または間接光の鏡面反射部分です. 間接光は実際にはさまざまなソースからのものであるため. ここで言及されている滑らかな素材の場合、間接光は主に鏡面反射部分です. ここで見ることができます.間接照明なので、あらゆる方向から光が届きます。
ここでは、以前は考慮されていなかったアンビエント ハイライトを考慮して、赤に設定します。設定後、赤は実際に反射率を表します。赤はアンビエント ハイライトの色なので、色が赤くなるほど反射が多くなるということは、反射率が高いということではありません。
また、上部のエッジに強いフレネル効果があります。これは、pbr シェーダーが、書かれたフレネルを含む、unity によってパッケージ化されたものを使用しているためでもあります。
ここでの意味は次のとおりです。ライトが影の影響を受ける場合、ライト自体がキャストされた影によって暗くなるからです。つまり、影の影響を受ければ影の部分のアンビエントハイライトも暗くなるはずなのに影響を受けず、影と明暗のコントラストがあるため明るく見えるということです。
最初のサンプリングを完了します。
ここで、HDR フォーマットは比較的明るいことがわかり、明るくするための係数が存在します。ハイライトなしで RGB フォーマットを取得したい場合は、それをデコードする必要があります。
ここでデコードしたら、問題が発生しました.デコードしなくても正常です.デコード後:
シェーダで HDR テクスチャをサンプリングするには? - ユニティ フォーラム
インターネットでデコードを読み取った後、同じことを行います。めちゃめちゃ珍しい。
上記は通常のサンプリングで反射とは関係ありませんが、ここで反射について紹介します。
反射を導入した後、空のボールの反射だけでは不十分です。ここでは、実際の周囲のオブジェクトの反射を追加する必要があるため、反射プローブを追加します。
ここのアイコンは少し邪魔なので、彼のためにオフにすることができます。
以上は主にこのプローブの紹介であり、そのリアルタイム性はチェック後にさらに設定があるようです。
最初のパラメータは、プローブによって取得されたキューブマップをいつ更新するかを制御するためのもので、もう 1 つはプローブがアクティブになるたびに更新するためのものです。(このアクティブな状態は不明です)。
一般的な外観の後、C# のいくつかの設定について説明します。次に、2 番目はフレームごとに更新され、3 番目はユーザー スクリプトによって完全に制御されます。
2 番目のパラメーターは、よりインテリジェントです. キューブマップを取得するプロセスを一度更新し、それを複数のフレームに分散させることができます. 9 フレームのものもあれば、14 フレームのものもあれば、分散していないものもあります. 各フレームでキューブマップ全体を更新します. .
キューブマップの計算では 6 フレームをレンダリングして立方体にする必要があるため、これは非常に大量の消費であり、リアルタイムの消費はさらに大きいため、これらのアトリビュートは基本的にリアルタイム レンダリングの負荷を軽減するために使用されます。
ここで言及されている編集モードは、このようなものでなければなりません。
要するに、彼は最終的にベイクを選択しました. 実際、基本的にはベイクで十分です.
また、このベイクは静的オブジェクトのみを対象とするため、静的に変更する必要があります. static を変更する場合は、一度に確認するか、細分化された多くのアイテムに応じて、特定のアイテムを個別に静的に設定することができます.
ざらつき感や金属感を調整してボケ具合に影響を与えず、調整後は照明に大きな影響を与えます。
実際、これは不合理です. 実際の状況では、滑らかさの変更は反射のぼやけに影響を与えるはずです. これにより、PBRの内部について疑問が生じます. これはPBRで行うべきではありません. ライブ? なぜそれをしなかったのですか？
実は、あいまいさの原理を考えてみればわかるのですが、あいまいさの本質は、周囲のものとの明確な境界がなく、混ざり合ってぼんやりと見える感覚にあるのです。通常、ぼかしを実現するために畳み込みフィルタリングを使用します。
GPU で PBR がどれほど強力であっても、それは 1 つのピクセルでしか動作しないため、効果をぼかすために彼ができることは何もありません。
しかし、滑らかさはぼかしやその他の操作には使用されません。
そのため、ミップマップは不完全な反射をシミュレートするために使用されます。
しかしここでは、Unity は別のアルゴリズムを使用して、さまざまな程度のぼかしの間の適切な移行を検討します。
滑らかさから粗さを得る。使用する必要があるミップマップのレベルを決定します。
粗さとぼかしの間には線形関係がないため、ここでは単純に粗さによって決定されるわけではありません。
次に、上記のラフネスの非線形変換について、キューブマップのサンプリング、HDR 操作はすべて unity でカプセル化された関数に含まれます。
彼はここで再度 HDR を実行しましたが、以前のように効果が異常になることはありませんでしたが、比較したところ、HDR をデコードせずにそのマクロを使用した場合と同じ結果が得られました。私のために働きます。
ここには、主にさまざまなプラットフォームの内部的な考慮事項のために、理解できない追加のアルゴリズムがいくつかあります。