Unityレンダリング最適化に関して、あう可能性のある問題――レンダリング編（弐）

この記事は、前回の記事「Unityレンダリング最適化に関して、あう可能性のある問題――レンダリング編(その壱)」の続きであります。

前回の文章をまだ読まれていない皆様は、是非移動してご覧ください。

キーワード

マルチレイヤーテクスチャレンダリング

Graphics.PresentAndSync

VBO

カメラ後処理特殊効果

三、マルチレイヤーテクスチャレンダリング

Q1:私たちのゲームはT4Mを使用しています。4層のTillingテクスチャと1層の融合テクスチャがあります。スマホの発熱が厳重で、パフォーマンス表現に影響することが分かりました。何か標準または参照できるデータありませんか？

ミドル/ローエンドマシンに対して、地形テクスチャがプリントされた層数は3以下をできる限りに制限することをお勧めします。ミドル/ローエンド設備に、テクスチャサンプリング回数が多いほど、GPUへの圧力が大きくなり、発熱効果がより明確になります。同時に、設備の温度表示では、温度の傾向グラフに急激な下降があるかどうかを注意してください。存在する場合は、設備が過熱による自動的に周波数を下げている可能性があります。

Graphics.PresentAndSync時間コスト統計

設備温度傾向

四、Graphics.PresentAndSync相関

Q1: Androidバージョンをコンパイルすると、一部の設備（Sony L36h、Xiaomi 4）でデバッグすると、Graphics.PresentAndSyncと呼ばれる時間のかかるアイテムがあり、パフォーマンスへの消費が非常に誇張です（レンダリング20ms、これは50msに達する可能性があります）。関連ドキュメントを確認したところ、この機能はAndroidデバイスの垂直同期に関連しているようですが、ほとんどのAndroidデバイスの垂直同期をオフにすることはできません。良い解決策はありますか？

一言で言えば、この値が高いとGPU負荷が重いと示します。面数の減少またはShaderの単純化から処理することができます。

Graphics.PresentAndSyncとは、メインスレッドがPresentを実行するときの待機時間と垂直同期の待機時間を指します。通常、ProfilerにこのパラメーターのCPU使用率が高く、リリースバージョンでのみ表示されます。この原因は、CPUとGPU間の垂直同期（VSync）が引き起こします。主にプロジェクトがマルチスレッドレンダリングをオンにするかどうかに関します。マルチスレッドレンダリングがオンにする場合はGfx.WaitForPresentですが、オンにしていない場合にはGraphics.PresentAndSyncであります。

原理は、私たちがこの関数に対して詳しく説明する記事「Profilerにある「嘘つき」について話しましょう」を参照してください。

五、VBO相関

Q1: 現在、１つのシーンがあり、DrawCallと面数が通常の範囲内にあり、Camera距離も他のシーンと同じですが、VBOが非常に高いです。下図は当シーンのデータ状況で、沢山の再利用されたモデルがあります。StaticをチェックしないとVBOが減少しますが、DrawCallが増加します。モデルを合併することを介してVBOを減らすことはできますか？

Staticをチェックすると、UnityはStatic Batchingを実行し、１つのより大きいVBOを生成してレンダリングし、同時にDraw Callを減らします。チェックしないと、エンジンはBatchできないため、VBOが低くなり、Draw Callが高くなります。

これに対して、UWAの提案は次とおります。

1、一般的に、Draw Callを減らすことの重要性はVBOを減らすことよりも大きいです。

2、現在の50+などのDraw Callがより低い場合、VBOの占用を減らすためにDraw Callを適応に増加することが考慮できます。一方では、帯域幅へのプレッシャーを減らすことができ、他方では、一部のメモリを適切に減らすことができます。

六、カメラ後処理特殊効果相関

Q1: アンチエイリアスとBLOOMに関して、お勧めできる優れた最適化案や優れたプラグインがありますか？

通常、ミドル/ローエンドデバイスでは、アンチエイリアスがより効率的なソリューションはありません。ハイエンドデバイスの場合、Unityの組み込みMSAA機能を直接使用してみることができますが、推奨されるのは2倍のみです。

Bloom効果に関して、以下は１つのモバイルに適しており、評価の高いプラグインです：BloomPro

Q2: モバイル設備で、どうすればBloomとフルスクリーンアンチエイリアスを最適化できますか？Unity自有標準リソースの効率は比較的低いです（Bloom(Optimized)はもう試しました）。

Asset Storeにあるモバイル端末に適応するBloom Shaderプラグインを使用することをお勧めします。たとえば、FxPro: Bloom&DOFやBloomProなど。

AAに対して、現時点では、モバイル設備で特別な最適化方法はありません。ローエンドデバイスでAA機能をオフし、ハイエンドデバイスで倍数のより低い(2x)MSAAをオンしてみることだけをお勧めできます。

七、Shader解析相関

Q1: 図にあるMaterial.SetPassFastの占用が高いで、これは私が初めに１つの特殊効果をインスタンス化する時の状況です。2回目にインスタンス化すると値はあまり高くなくなりました。これは最適化できますか？

この過程はShaderを処理しています。Unity5.3以降、初めて表示する時のみにShaderをWarmupするので、ピークジャムが発生します。

Q2: Shader.ParseとShader.CreateGpuProgramは一体何をしますか？彼らはいつ執行しますか？

Shader.Parseは、Shaderのロードと解析を具体化しています。Shader.CreateGpuProgramはShaderがGPUに入力したものを一回で提出し、GPUドライバーは特定のデバイスまたはプラットフォームに適応するようにそれをコンパイルします。Unity 5.xバージョンでは、Shader.ParseはShaderアセットがロードする時に執行しますが、Shader.CreateGpuProgramはGameObjectが最初にレンダリングする時に執行されます。

八、その他

Q1: 下図のように、WaitingForJobという関数のコストが高すぎでジャムを引き起こしたと発見しました。これはレンダリングの圧力が大きすぎるというものですか？

スレッドは最終的にCanvas.sortjobを待っています。これは、UIの並べ替えによって引き起こす消費です（Unity5.2バージョンから、UGUIの一部の計算はメインスレッドから移動されました）。

詳細はこちらを参照してください、http://blogs.unity3d.com/2015/09/07/making-the-ui-backend-faster/

したがって、理論的には、これはUIのcanvas.sortjobが指定された時間内に完了しないために発生する消費であり、レンダリングスレッドを待機させ、最終的にメインスレッドを待機させます。

UWA公式サイト：https://jp.uwa4d.com

UWA公式ブログ：https://blog.jp.uwa4d.com

UWA公式Q＆Aコミュニティ(中国語注意)：https://answer.uwa4d.com