
1)Font Textureのメモリ値が異常に高い
2)UWAレポートにおけるOverdrawの統計およびデータの解釈についての疑問
3)URP Androidプラットフォームでは、ハイライトにモザイクがある
4)Different Material Instanceが原因でUGUIのパッチが中断されている
5)UnityのTerrainDataでSplatAlphaの圧縮についての疑問
Font
Q:テストレポートでメモリの使用が高いFont Textureを発見しました。それに、最初にゲームに入ってからそこにあります。しかし、私が理解できないのは、256 * 256しかないなのに、61MBほど占めるのはなぜでしょうか。
バージョン:Unity 2019.4.3f1
A:2018にはこのような問題は発生していません。これはUnity2019のバグだと思います。そしてUnity2019.4.21で修正された。
Rendering
Q:UWAテストレポートでは、ゲームの全体的なOverdrawが比較的高いです。イントラネットでOverdrawデータを再テストしたいのですが、いくつか質問があります。
1.UnityOverdrawMonitorを使用して、Editorでシーン全体のOverdrawをテストしました。テスト結果はUWAの結果よりも小さく、複数の同じ画面をテストしましたが、相変わらずUWAの結果値がより高いです。つまり、このツールの統計値はUWAレポートのFill総数より小さいです。ゲームのある瞬間にOverdrawをどのようにテストするのか聞きたいですが。
2.Fill総数、平均Fill Times、ピクセルあたりのFill最大数など、UWAレポートのこれらのデータ間にどのような関係があるでしょう?
3.他のツールについては、ParticleEffectProfilerをイントラネットに取り込みました。これは、単一の特殊効果に対する単一のピクセルのFill最大数をカウントできます。いくつかの個別の特殊効果をテストした結果、一般的にOverdrawは2ですが、高いのは4、5、6までに達しました。Overdrawが高すぎる特殊効果は、アーティストに最適化させました。
PS:会社のプロジェクトはイントラネット上で開発されているため、Editorでプロジェクトのデータをキャプチャすることはできません。UWAレポートのスクリーンショットをいくつか投稿します。
A:
1. UnityOverdrawMonitorは次のオープンソースツールにある場合:https://github.com/Nordeus/Unite2017/
ここでの統計は不正確です。これは、Shader ReplacementでShaderを半透明のShaderに置き換えて、Overdrawを計算するからです。そういう基本的な原理のため、深度のオクルージョンやカリングなどの問題を考慮していません。そうしたら、計算された値が違って、時には不必要な誤解を招くことさえあります。
2.これらの値の具体的な説明は、https://blog.uwa4d.com/archives/PA_GPU.html
(中国語注意)を参照してください。
Fill総数の最大値
プロジェクトの実行中、1つのフレームのFillピクセルのピーク値。
Fill総数の平均値
プロジェクトの実行中、フレームあたりのFillピクセル数。
Fill Timesの最大値
プロジェクトの実行中、1つのフレームで、画面全体が充填されるFill Timesのピーク値。Timesが大きいほど、GPUへのストレスが大きくなります。
Fill Timesの平均値
プロジェクトの実行中、各フレームの平均Fill Timesです。Timesが大きいほど、GPUへのストレスが大きくなります。
スクリーンショットから、特殊効果のOverdrawのストレスはまだ小さくありません。特別な注意を払うことをお勧めします。
Rendering
Q:Unityのデフォルトの球体を含む最も単純なシーンでは、URPLitShaderを使用しています。
Editorで正常に表示されます。
プロジェクトがAndroidにエクスポートされた後、ハイライトのモザイクは非常に深刻です。
マテリアルにはカラーのみが設定されていますます。
どうすれば良いですか?
Unityバージョン:2021.1.9f1
URPバージョン:11.0.0
A:URPソースコードを変更する必要があります。
packages / com.unity.render-pipelines.core @ 11.0.0 / ShaderLibrary / Common.hlslファイルの1225行目:
// Normalize that account for vectors with zero length real3 SafeNormalize(float3 inVec) { real dp3 = max(FLT_MIN, dot(inVec, inVec)); return inVec * rsqrt(dp3); }
realをfloatに変更する必要があります
// Normalize that account for vectors with zero length float3 SafeNormalize(float3 inVec) { float dp3 = max(FLT_MIN, dot(inVec, inVec)); return inVec * rsqrt(dp3); }
したがって、やはりモバイルプラットフォームの精度設定に問題があると思います。
UGUI
Q:下図に示すように、同じマテリアルボールなのに、Different Material Instanceのバッチが中断されています。その理由は何ですか?
A1:マテリアル名が同じからだと思いますが、Debugモードを開いて、Instance IDが同じかどうかを確認したらどうでしょう。
A2:解決されました。テンプレートテストが原因です。
Rendering
Q:Unity TerrainDataのSplatAlphaは非圧縮形式であり、メモリ使用量が非常に高いですが、より良い圧縮方法はありますか?
A:この画像がUnityのネイティブTerrainで圧縮できるかどうかはわかりませんが、原則として可能であるようです(画像が実行時にメモリで生成されない限り)。
ただし、この画像には色情報が保存されていないため、ブレンドのエッジのモザイクなど、圧縮後の効果が低くなる可能性があります。T2Mを使用してMeshに変換した後、この混合テクスチャが圧縮されましたが、効果は非常に劣っていました。最終的に、メモリの半分を減らすために、いくつかの許容可能なプロットで16ビットを使用して、問題のあるプロットは依然として32ビットの元の画像を使用しています。
UWA公式サイト:https://jp.uwa4d.com
UWA公式ブログ:https://blog.jp.uwa4d.com
UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com
これも興味あるかも
-
原理から応用まで ゲームでの動的解像度
January 4, 2023 -
Unityゲームの使用メモリを最適化しよう
December 21, 2022 -
ASTC テクスチャ圧縮形式の紹介
December 14, 2022