ボクセルvsシャドウマップ：Roblox用の新しい照明システムの選択

ボクセルは、過去4年間、Robloxの世界で照明システムとして機能してきました。しかし遅かれ早かれ、変化の時がすべてにやってくる。そのため、開発者は次に何をすべきか疑問に思いました。



照明には注意が必要なため、新しいテクノロジーを選択する際には注意が必要な要素がたくさんあります。意思決定を容易にするために、Robloxは2つの将来のシステム、いわゆるボクセルとシャドウマップのプロトタイプを作成しました。両方の制限を理解するには、最初にそれらがどのように機能するかを理解することが重要です。

注：記事のスクリーンショットは、ボクセルが常に左側に表示され、シャドウマップが右側に表示されるように配置されています。

実装：ボクセル

この特定のシステムは、長い時間のためのゲームで働いているが、ここでは考慮オプションは多くの改良を施しました。



ワールドデータは、ボクセルグリッドのセットに変換されます。各グリッドは文字を中心とし、1〜16のボクセルサイズ（合計5グリッド）にすることができます。各ボクセルには、0〜100％の範囲の占有情報が含まれています。照明データは、その後、各メッシュこの膨満および光源/方向情報に基づいて、各ボクセルについて計算されます。上記のすべてはGPUで発生します。これは、中央のGPUは、非常に多くのボクセルをこのような高密度で更新するのに十分な速度ではないためです。



システムはすべてのデータをボクセルに保存します。特に、使用可能なボクセルごとに次のデータがあります。

• 満杯（各ボクセルがどれだけ満杯であるかを表す複数の値）;
• スカイライト（ボクセルから見える空の量）;
• 太陽の影（太陽のどれだけがボクセルによって隠されているか）;
• ライトオブジェクト/コーンの色（ボクセルに対するローカル光源の効果の色/コーンの近似）。

この情報は、後で特定の解像度で各ピクセルの色を計算するために使用されます。画面とボクセルの解像度は、互いに独立して調整できます。ボクセルメッシュの一部は、ライト/オブジェクトの移動に合わせてフレームごとに更新できます。

実装：シャドウマップ

この方法では、ラスター化を使用してほとんどのシャドウ効果を計算します。それは3段階で実行されます。まず、シャドウカーストごとに、シャドウマップを更新し、光源からシーンに複数のレイキャストを起動して、交差の結果を記憶します。次に、各可視光オブジェクトを埋め込む空間加速構造を構築します。これは、本質的にはフルストコニカルボクセルグリッド（フロクセルグリッドとも呼ばれます）です。



グリッドは、カメラから見たゲームの世界全体をカバーしています。各フロクセルで、それと交差するすべてのライトオブジェクトのリストを書き留めます。最後に、すべての光源の影響を計算するために、シーンをレンダリングするときに、各ピクセルについて、このピクセルを含むフロクセルを探し、すべての光源を繰り返し、各ライトについて、最初のステージで作成されたシャドウマップを使用してその影響を個別に計算します。



システムは、データを2つの構造に格納します。

• シャドウアトラス（すべての可視光シャドウマップが1つの大きなテクスチャにパックされています）;
• ライトメッシュ（カメラ内のポイントをライトのリストに効果的に変換するフロクセルメッシュ）。

各ピクセルの色は動的に計算され、明示的に保存されません。シャドウアトラスの一部は、ライト/オブジェクトの移動に合わせてフレームごとに更新できます。

パフォーマンス：ボクセル

ボクセル手法はスケーリングに適しています。出力品質を低下させるために、ボクセルグリッドの数を減らすか、フレームごとに更新するボクセルを少なくすることができます（これにより、「光の遅延」が発生します。オブジェクト自体の更新に比べて、オブジェクトの露光量の更新が遅くなります）。



ボクセルには、幾何学的複雑さ、光の複雑さ、ピクセル数の3つの複雑さの特性があります。幾何学的な複雑さはボクセル化のコストにのみ影響するため、オブジェクトを追加しても遅延は発生しません。光の複雑さは、それを計算するコストにのみ影響し、幾何学的な複雑さやピクセル数には依存しません。最後に、最終的なピクセルの色はボクセル/ライト/オブジェクトの数から計算されるため、照明の品質に影響を与えることなく解像度をスケーリングできます。



ボクセルのパフォーマンスは、O（G）+ O（L）+ O（P）として計算されます。ここで、Gは三角形の数（幾何学的な複雑さ）、Lはライトの数、Pはピクセルの数です。



残念ながら、ボクセルの数はN3とGPUが必要な更新方法に理想的ではなく、適切なパフォーマンス管理を維持できないため、ボクセルのピークパフォーマンスは最適ではありません。GPUコンピューティングに関する十分な調査があれば、パフォーマンスの低下を補うことができますが、現時点では基本コストはかなり高いままです。

パフォーマンス：シャドウカード

シャドウカードは、ラスター化に基づいて設計されているため、GPUに適しています。シャドウアトラスの更新コストは、更新をキャッシュ/遅延することで部分的に削減できます（これにより論理的に追加の遅延が発生します）。ジオメトリ表現（メッシュの詳細レベルを含む）を最適化すると、メソッドのコストも削減されます。



ただし、複雑なシーンでシャドウを更新するには、幾何学的な詳細の量とシャドウを投影する光源の数の両方に依存するため、依然としてコストがかかります。建物の内部では、移動するライトの場合、そのライトのシャドウ情報を更新するために、フレームごとに建物全体を再レンダリングする必要があります。建物内で多くの動く光が投じられると、パフォーマンスが低下します。フレーム内のすべての光を一度に更新できないため、視覚的なアーティファクトが発生します。



さらに、この方法では、解像度パラメータを光の量から分離することはできません。ピクセルごとに、それをカバーするすべての光源の影響を再計算する必要があります。このステップもキャッシュできないため、明るいシーンでは高解像度でパフォーマンスの問題が発生します。4Kの部屋で20個の重複するライトには、1億6000万個のライトの見積もりが必要になる場合があります。



シャドウマップのパフォーマンスは、O（GL）+ O（LP）として計算されます。ここで、Gは三角形の数（ジオメトリの複雑さ）、Lはライトの数、Pはピクセルの数です。

パフォーマンス：評価

明確にするために、特別に選択されたゲームレベルには両方の方法が使用されました。これらは既存のレベルの実装であり、パフォーマンス評価用に特別に設計されたものではないことに注意してください。

パリ（太陽の影、影のない光源はほとんどありません）

• ボクセル：シャドウの更新-6ms、シーンのレンダリング-1.5ms;
• シャドウマップ：シャドウの更新-1ミリ秒、シーンのレンダリング-2.4ミリ秒。
• GPUが処理するのが難しいため、ベースボクセルシャドウの計算コストは​​高くなります。

洞窟（影を落とす多くの情報源）

• ボクセル：シャドウの更新-7ミリ秒、シーンのレンダリング-0.9ミリ秒;
• シャドウマップ：シャドウの更新-10ミリ秒、シーンのレンダリング-2.1ミリ秒。
• 大量のジオメトリと移動するライトがあるため、シャドウマップの更新にはコストがかかります。

ウエスタン（多くのシャドウキャスティングソース）

• ボクセル：シャドウの更新-8ミリ秒、シーンのレンダリング-1ミリ秒;
• シャドウマップ：シャドウの更新-15ミリ秒、シーンのレンダリング-2.5ミリ秒。
• 動くライトとたくさんの三角形があるので、シャドウマップの更新には費用がかかります。

影のない1000個の光源

• ボクセル：ライトアップデート-20ms、シーンレンダリング-0.5ms;
• シャドウマップ：ライトアップデート-0.5ms、シーンレンダリング-5ms;
• この場合、光とボクセルのオーバーラップの累積量により、ボクセルの更新が遅くなります。さらに、近い段階では、「各ボクセルに1つのライト」の近似が実行されていないことがわかります。

パフォーマンス：結論

シャドウマップはワークロードに合わせて拡張できますが、考慮すべき点が2つあります。

• 解像度が上がるとピクセルあたりのコストが高くなるため、これは中解像度（1080p）でのみ実用的なソリューションになります。1080pを超えるには、非常に優れたGPUが必要です。
• 多くの動的ライトの複雑なジオメトリの場合、シャドウのレンダリングのコストは非常に急速に増加します。これはカリングを改善することで補うことができますが、この段階では根本的な問題が残っています。

同時に、対照的に、ボクセルのパフォーマンスはレベルの内容にあまり依存しませんが、基本コストははるかに高くなります。これは、GPUアルゴリズムの改善とボクセルの削減によって補うことができます。

メモリ要件

シャドウマップとボクセルのメモリ要件は、必要な品質によって異なります。



ボクセルの場合、ステージごとに複数のテクスチャがメモリに保存されるため、それらの合計サイズはステージの数と各ステージのサイズによって異なります。現在、それぞれ128x64x128ボクセルの4つのステージ（ボクセルサイズ1..8）があり、合計で最大128MBの使用済みVRAMが使用されます。さらに2つのステージ（0.5ボクセルと16ボクセル）を作成するか、既存のステージを再構成して、この値を192MBに増やすことができます。逆に、メモリが限られているシステムでは、カスケードの数を減らす（いくつかの近いカスケードを削除する）ことができます。そうすると、メモリへの最小の影響は、2つのカスケード（4..8）で約64 MB、3つのカスケード（4 ..）で約96MBになります。 16）。



シャドウマップの場合、シャドウマップアトラスとフロクセルグリッドが使用されます。後者は部分的に解像度に依存します。パフォーマンス/メモリを向上させるためにシャドウの品質を下げる必要がある場合は、シャドウアトラスのサイズを小さくすることができます。現在のシステムは73MBのビデオメモリを使用しており、そのほとんど（64 MB）はシャドウアトラスによって占められています。あなたはそれを減らすことができ、それによって暗くなる光の数や影の質を制限することができます。半透明性をサポートするためにより多くのメモリを必要とするシャドウマップのいくつかのオプションを検討することもできます。これは、より多くのスペース（最大130 MB以上）を使用することを意味します。システムメモリへの影響を最小限に抑えるには、シャドウアトラスのサイズを小さくし、約25MBかかるより単純なバージョンを使用することで達成できる可能性があります。



比較すると、現在の照明システムには、高品質（PC）と低品質（モバイル）の2つのモードがあります。PCバージョンは約40MB（24 MB RAM、16 MB VRAM）を必要とします。モバイル-〜11 MB（6 MB RAM、5 MB VRAM）。



実際、どちらの方法もメモリへの影響という点ではかなり近いですが、シャドウマップは、同じ光/シャドウ範囲に対していくらかスケーラブルです。

モバイルの互換性

ゲームのオーディエンスはますますモバイルになっています。つまり、選択した実装を比較するときは、さまざまなゲームデバイスも考慮する必要があります。ハイエンドデバイスでは、両方のメソッドを実装するのに十分なAPI機能が必要ですが、もちろん、メモリとパフォーマンスの点でそれほど実用的ではない場合があります。



既存のボクセル照明システムはモバイルデバイスに最適です。多くの複雑な照明機能（ライトシャドウ、スカイライトなど）をサポートし、CPUで複雑な計算のほとんどを実行するため、GPUのパフォーマンスと機能セットの要件が最小限に抑えられます。 ..。このシステムは、当面の間、低コストのモバイルデバイスとPCで引き続きサポートする必要があるため、デバイスの大規模なプールをサポートするためのいくつかのオプションが登場しました。

• 既存のシステムをモバイル形式で維持します。新しいシステムはPC /コンソールのみになります。これは、ユーザーベースの大部分が新しいシステムにアクセスできないことを意味します。
• ( , ), /.
• low-end , , .

プラットフォームの主な約束の1つは「コンテンツを一度ダウンロードしてどこでも実行する」ことであるため、これらすべての場合において、コンテンツの互換性に関する質問に答える必要があります。私たちはまだこれに取り組む必要があります。最初は、新しいボクセルソリューションは、古いシステムから新しいシステムへの品質/動作の一貫性を提供するという意味で優れているように見えます。シャドウマップは、別の品質へのより急激な移行を表しますが、同時に、モバイルデバイスの限られた機能に対応する可能性が高くなります。

品質：光源

シャドウマップソリューションは、光源のシミュレーションに関して信頼できる情報を提供します。シャドウマップの場合に1000個のライトを使用した以下のスクリーンショットでは、完全に再現されたスペキュラーハイライトを確認できます。BRDFでモデル化されているため、必要な光の反射が得られます。



ボクセルソリューションは、各ボクセルに対する光の影響を1つのソースからのものであるかのように近似するため、根本的に悪化します。このことから、スペキュラー反射の品質が低下していることがわかります。







したがって、スペキュラーハイライトのある領域のボクセルの場合、色は1：1の比率でマージされ、シーンに黄色のライトすらありませんが、緑と赤の代わりに黄色のライトが作成されます。対照的に、シャドウマップソリューションは色の組み合わせを正確にシミュレートします。



場合によっては、まったく説得力のない結果が得られますが、将来的には改善される可能性があります。







上記の例では、湾曲した、細長い、歪んだミラーハイライトが表示され、オブジェクトの1つの下にあるいくつかのボクセルでは、光の情報がまったくありません。シャドウマップの同じスクリーンショットは、はるかに良い結果をもたらします。

品質：影

シャドウマップの定義品質は正確さですが、ボクセルシャドウはソフトです。シャドウマップは、できるだけ詳細ではなく、キャラクターに説得力のあるシャドウを作成するのに十分な精度で、かなり鮮明なシャドウを提供します。一方、ボクセルアルゴリズムは、非常にソフトなシャドウを作成するのに非常に適していますが、細部からのシャドウはまったく登録されていないか、不規則な形状になっています。







このため、現在、シャドウマップのバリアントを使用してキャラクターのシャドウをレンダリングしていますが、これはよりクラッチであり、太陽を投げかけるキャラクターのシャドウにのみ適用されます。他の光源は考慮されていません。



また、ボクセルを加速するための重要な手法は、カスケードを使用することです。しかし、満腹データは、シーン内のポイントからの距離が粗くなることが、この手段は、私たちに関心があります。この場合、シャドウのソースとレシーバーの間の距離が大きくなると、シャドウの品質も低下します







。上のスクリーンショットでは、最小のボクセルのサイズでブリッジから高品質のシャドウをレンダリングできますが、ブリッジが水面から離れすぎているため、ボクセルが粗すぎることがわかります。水面近くのボクセルがかなり良い場合。

品質：天窓

ボクセルパイプラインの重要な機能は、現在のボクセルから見える空の量を決定するスカイライト係数の計算です。屋内と屋外の照明を組み合わせるために使用され、品質の向上に非常に効果的です。下のスクリーンショットでは、影のある場所でも、家の外側は内側よりもはるかに明るくなっているはずです。ボクセルソリューションはこの係数を適切に計算して再現しますが、シャドウマップの場合は存在しないため、シャドウを暗くする可能性はありません。

品質：幾何学的精度

ボクセルとシャドウマップのジオメトリ表現の基本的な違いに注目する価値があります。



ボクセルは、ライトエンジンでサポートされているすべてのオブジェクトを「ボクセル化」できると想定しています。つまり、ゲームワールドのすべてのボクセルについて、オブジェクトとボクセルの交差量をすばやく計算する方法があります。これはプリミティブシェイプではうまく機能しますが、CSGやMeshPartsなどの複雑なオブジェクトはすでに深刻な問題です。現在、効果的なボクセル化のための大まかな分解と他の一連のハックはこれを部分的に助けますが、これはしばしば目に見えるアーティファクトにつながります。同時に、シャドウマップは、レンダリングに関係するのと同じポリゴン表現を使用するため、すべてのオブジェクトの形状を完全に表すことができます。

品質：光漏れ

影の形状が非常に重要であるが、それはおそらくもっと重要な目に見えないピクセルが適切に処理されなければならないということです。さまざまな近似がこれに違反すると、いわゆる光漏れ（目に見える縞模様）が発生します。これは、たとえば、明るい外太陽のある建物の内部など、高コントラスト環境で最も問題を引き起こします。光漏れの例を次に示します。







これは、壁の真向かいにある床の薄く照らされた部分です。シャドウマップは、光の遮蔽をはるかによく維持し、この問題と戦います。



ボクセルのリークの原因はいくつかあります。それらのいくつかは、異方性の膨満感を維持しながら柔らかくすることができます：たとえば、メモリはボクセルごとに3つの値を保存し、3つの軸すべてについて「軸に沿ったボクセルの投影にどれだけの問題があるか」を示します。残念ながら、これは厚みに関係なく微妙なディテールが影を落とすのに役立ちますが、すべてのリークを修正するわけではありません。この側面で光を完全に遮断することを保証する唯一の方法は、パーツをボクセルの2倍の厚さにすることです。さらに、漏れはボクセルのサイズとともに大きくなります。つまり、品質レベルが低いほど、および/または遠くにあるほど、漏れが目立ちます。



シャドウマップは完全に密閉されていませんが、リークの問題ははるかに少なくなります。たとえば、この実装では、厚さが0.4ボクセルのオブジェクトは可視光を透過しません（厚さが0.2ボクセルの場合、光の一部を透過できますが、これからも透過できます）。あなたは将来取り除くことができます）。

品質：結論

シャドウカードは、品質のほとんどの面で優れています。大幅に低下する唯一の領域は、天窓の比率の計算です。または多分、この問題への代替ソリューションがある - これは、ボクセルパイプラインにいくつかのヒッチを紹介天窓のためのボクセル化を使用したハイブリッド方式が必要な場合があります。また、シャドウマップのアルゴリズムにいくつかの拡張を行うことができるソフトシャドウをサポートできるようにするとよいでしょう。



ボクセルは許容できる品質を提供しますが、シャドウマップと比較すると、特にシャドウとスペキュラーハイライトの忠実度が大幅に低下します。現在のソリューションを使用すると太陽からの影しか得られないため、プレーヤーから美しい影を提供できるボクセルライティングを実装できるようにするには、これらの問題を何らかの方法で解決する必要があります。これは、ゲームの将来の世界のビジョンとは相容れないようです。

可視性：半透明

影のレンダリングは、不透明なオブジェクトについてはかなりよく研究されている問題ですが、半透明性はまったく別の問題です。ボクセルシステムの場合、光は満杯値に基づいてボクセルセルを通過するため、粒子効果やシーン内の他の半透明オブジェクトからの低周波（ソフト）シャドウが与えることができる半透明シャドウを維持することはそれほど難しくありません。粒子効果自体：







以下は、この効果の動きのビデオです：





現在、シャドウマップの半透明性はサポートされていません。つまり、影を落とす粒子やその他の透明なオブジェクトをサポートする場合は、別の解決策を見つける必要があります。このユースケースに役立つ可能性のある代替のシャドウマップ表現に関するいくつかの研究がありますが、これがどれほど効果的であるかはまだわかりません。

可視性：植生

シャドウマップは、半透明性では特に効果的ではありませんが、ジオメトリまたはテクスチャでモデル化されているかどうかに関係なく、オブジェクト（植生など）の詳細を表示できます。ボクセルは、このユースケースに対応するのに十分な小ささではありません。さらに、この場合、ボリュームではなくメッシュサーフェスの正確なモデリングが必要になるため、テクスチャに関する情報にアクセスするのは簡単ではありません。このスクリーンショットに示すように、シャドウマップは既存のコンテンツでもこれを提供できるのに対し、ボクセルを使用して植物から美しい影を取得できるかどうかは疑わしいです。

可視性：自己照明

ボクセルの実装方法により、パイプラインの他の部分のパフォーマンスに影響を与えることなく、任意の形状と量のライトをメッシュに注入するのは比較的簡単です。ただし、シャドウマップに多くのライトを追加する一方で、不規則な形状のライトを作成すると、アーキテクチャ上およびパフォーマンス上の問題が発生します。特に、ボクセルを使用すると、真の自己発光を実現するのがはるかに簡単になります。現在、ネオンマテリアルは「発光」に使用されていますが、実際には近くの他のオブジェクトに発光しません。







はい、ライトを追加することはできますが、すべて自動的に追加すると便利です。シャドウマップはこれにはあまり役立ちませんが、ボクセルは必要に応じて任意の形状のボクセル化をサポートするため、自発光オブジェクトからの発光をサポートすることは非常に簡単です。

可視性：グローバルイルミネーション

グローバルイルミネーション（GI）は、壁で2回跳ね返るランプからの光など、直接光線が届かない領域に追加の照明を提供するための二次照明効果の計算を指します。



RobloxのGIは非常に複雑であり、それに関するほとんどの決定は、動的な照明、動的なジオメトリ、パフォーマンス、大規模なシーンから何かを犠牲にする必要があります。これらの犠牲のいずれも許されません。



コンテンツの制約が厳しい場合、どのGIソリューションが実用的であるかは不明です。これまでのところ、ボクセルベースのGIは他のアプローチよりも有望であるように思われます。



もちろん、ボクセルベースのGIがあるからといって、直接照明がそれらを使用して計算されるわけではありません。今日のほとんどのボクセルベースのGI研究では、シャドウマップを使用して直接光を計算し、ボクセルで結果を改善しています。

概要

上記の分析に基づいて、両方のソリューションの有効性に関する要約表をまとめます。イタリック体のセルは、さらなる研究がこの領域を改善できることを示唆しています。表の等級は次のとおりです。ひどい<悪い<普通<良い<すばらしい。







したがって、ボクセルは間接照明のモデリングには最適ですが、直接照明に関してはそれほど優れていません。同時に、それらは非常にリソースを大量に消費するため、デバイスの幅広いプールを維持するタスクとの相関性は低くなります。



これにより、直接照明用の​​シャドウマップシステムを作成することになりました。スカイライトとグローバルイルミネーションの問題の解決策はまだ明確に見つかっていませんが、おそらく、両方のシステムの一種のハイブリッドであることが判明するでしょう。