お世話になっております。
背景アーティストから
といった要望が来ているのですが、マテリアル側のレイヤー数を増やすだけでもテクスチャ分のVRAM増加が確認されており、またLandscapeに重ね塗りするレイヤー数が増えるとSRVの枯渇や処理負荷・VRAMの増加が確認されています。
そのため、現実的な運用方法としては
とならざるを得ないのかなと思っているのですが、認識に齟齬はないでしょうか？
また、Landscapeのブレンド数を減らすとどうしても品質の担保が難しい部分が出てくるように思いますが、マテリアルの組み方や他の対処法などはありますでしょうか？
お忙しいところ恐縮ですが、ご回答いただけますと幸いです。
以上よろしくお願いいたします。
[Attachment Removed]
実際にランドスケープのマテリアルがレンダリングされる際にはLandscapeのコンポーネント毎にレイヤーの組み合わせを合成したマテリアルのインスタンスでレンダリングされます。
全てのランドスケープレイヤーが含まれる「ウーバーな」マテリアルでレンダリングされるわけではないことにご注意ください。
そのコンポーネントがどの程度の数のレイヤーを含んだマテリアルで描画されているかは、レベルビューポートのビューモードのLandscape>Layer Usageで確認できます。
例えば下の画像の例では6の数字が見えているところでは6つのレイヤーが有効になったマテリアルのバリエーションで描画されています。
[Image Removed]この順列の組み合わせによってハードウェアリソースの利用量や描画負荷が変化します。
以上の動作から、コンポーネント毎の「Landscapeの重ね塗りは極力抑える」ことができると効率的です。
またペイント情報を含んだWeightMapも4レイヤー毎に割り当てられるテクスチャが増えるので最大4または8レイヤーに制限することで無駄なWeightMapの増加を避けることも検討できます。
ランドスケープ編集モードのペイントモードではPaintingRestriction設定によって最大のレイヤー数を制限したりAllowListモードでコンポーネントに対するレイヤーの追加と削除時に明示的なキー入力が必要にするなどの管理方法を利用することができるのでこれらの機能を使って重すぎるマテリアルの組み合わせが出来ないように制限する運用を検討できます。
非常に細かくペイントを行う必要があるのであればランドスケープのコンポーネントのサイズを予め小さくすることも検討できますが、ランドスケーププロキシ数の増加もレンダリングパフォーマンスに影響を与えるため慎重に設定を行う必要があります。
このような管理を行うことである程度パフォーマンスをコントロールすることが出来ますが、レイヤー数が増えることによって、ロードされているテクスチャは間違いなく増加するためテクスチャの使用量に関しては十分に注意する必要がございます。
[Attachment Removed]
ご回答ありがとうございます。
いただいた情報をアーティストにも共有のうえ、方針検討いたします。
申し訳ありません、追加の質問になってしまうのですが⋯
現在開発中のプロジェクトがオープンワールドでして、ランドスケープマテリアルで使用するテクスチャをVT化しており、それによってDXT1のテクスチャプールの20%程度を占めています。
ページテーブルの上限に引っかかってしまい、DXT1のプールサイズが一定以上増やせない状況になっており、これも相まってDXT1のテクスチャプールが圧迫されてVTを使っている配置物のテクスチャが溶けた見た目になってしまう問題が発生しているため、ランドスケープのVTの使用量を減らせないか⋯というのも調べているのですが、こちらに関しても対処法があればご教示いただけますと幸いです。
お手数ですが、よろしくお願いいたします。
[Attachment Removed]
VTに関してですが RuntimeVirtualTexture(RVT)は利用されておらず、StreamingVirtualTextureをランドスケープ等の広範囲で利用されており、そのDXT1用のタイルが上限に達しているという理解でよろしいでしょうか。
具体的にはコンソールコマンドを使って調査した際に
r.VT.ListPhysicalPools でのTilesおよびTiles Allocatedが上限に張り付いていて、
r.VT.DumpPoolUsage でランドスケープ用のテクスチャのタイルが大量のタイルを消費している
ような状態でしょうか？
タイル数上限を超えることは難しいので特に大量のタイル数を消費しているテクスチャのサンプリング密度やテクスチャサンプリング時のLODBias等にマイナスの値が入っていて必要以上のタイルリクエストが行われていないかを確認いただくのがまずはよろしいかと思います。
すでにご利用頂いているかもしれませんが念のために他のコンソール変数についても紹介させていただくと ”r.VT.Residency.Notify 1" による MipBias調整の確認や "r.VT.Residency.Show 1"によるページ消費の確認も有用かと思います。
‘
すでにご検討済みかもしれませんがRVTはランドスケープマテリアルのキャッシュを作成してパフォーマンスを改善する機能です。シーンによっては活用できる可能性がございます。
[Attachment Removed]
返信遅くなり申し訳ありません、ご確認ありがとうございます。
VTに関して、SVTのみを使用しておりDXT1のタイルが上限に達しております。
具体的な症状についてはご記載いただいた通りです。
担当の方でサンプリング密度やLODBias等も一応確認したものの不審な点はなさそうという状況のようでした。
RVTを使用することで動的に作成したVTを参照するためページテーブルを節約できる、という理解で合ってますでしょうか？
ParallaxOcclusionMappingを使用しており、Nanite Tesellation もプロジェクト的な事情から利用が難しそうなのでRVTが使えないのかな、というところではあるのですが⋯。
常時大量のページテーブルを消費するようであれば、LandscapeのテクスチャのVT化をやめてTextureStreamingにしたほうがいいのかなとも思いましたが、TextureStreamingにする場合に気をつけるべき点などはありますでしょうか？
[Attachment Removed]
> RVTを使用することで動的に作成したVTを参照するためページテーブルを節約できる、という理解で合ってますでしょうか？
RVTのキャッシュにアクセスすることになるのでその間SVTへのアクセスは無くなりますが、根本的な問題としてRVTのタイルを更新するときに適切なSVTまたは非SVTテクスチャの適切なMIPレベルを保証する仕組みがありません。ストリーミングプールやページテーブルがひっ迫しページアウトが起こる場合適切な解像度でのレンダリングが難しくなりえます。そもそも前提としてParallaxOccusionMappingを利用されているとなるとRVTはフィットしなそうです。
>常時大量のページテーブルを消費するようであれば、LandscapeのテクスチャのVT化をやめてTextureStreamingにしたほうがいいのかなとも思いましたが、TextureStreamingにする場合に気をつけるべき点などはありますでしょうか？
4kを超えるテクスチャをご利用の場合は解像度が低下してしまうことがデメリットになります。
VTはフィードバックにより必要なタイルだけをメモリに乗せることが出来ることがメリットなので、基本的に大部分が常時メモリに乗ってしまう場合SVTにするメリットはかなり薄くなります。またテクスチャサンプルにあたってページテーブルを経由したアドレス計算が必要であったりフィードバック用の追加書き込みが発生するなどのオーバーヘッドがあります。
[Attachment Removed]
ご回答ありがとうございます。
やはりParallaxOcculusionMappingを使用している場合RVTを利用するのは難しいのですね。
ひとまずTextureStreamingにすることで改善できるか調べてみます。
本件についてはひとまず解決済みとさせていただければと思います。
お忙しいところ、ご対応ありがとうございました。
[Attachment Removed]