アセット管理方式

今回の主な話題:「アセット管理方式」、「 Unity 2017のUIカメラのパフォーマンスコスト」、「Standardシェーダーは効果を刷新していない」、「カメラHDRの開くがゲームパフォーマンスへの影響」。


レンダリング

Q1:たくさんの格好の良い効果はUnity後処理で実現されており、これはカメラにHDRをオンにすると要求されています。しかし、この機能のコストはよく分かりませんのため、ローエンドモデルで実行できますか。また、HDRを開いたら、本当にカメラのRendering PathはForwardを選択できませんか。

HDRを使用する時、Forwardも選択できます。Rendering Pathとお互いに影響しません。ただのHDR(fp 16)はパフォーマンスへの影響は大きくないですが、様々な後処理Passのコストは最適化の対象であります。一般的にHDRを開いたけど後処理が使用していない場合はあまりありません。発熱量などの要因を考えますと、ローエンドモデルでの使用は推薦しません。他のスマホに対してはHDRと後処理を同時に使用でき、また後処理に対するの基本的ま最適化も必要です。例えば:適当に処理解像度を下げ、なるべく複数の処理を一つのPassに合併しますなど。


レンダリング

Q2:Unity 5.5が実行時、シェーダーのGIオプションがベイクする時、Rendererモジュールが採用したMaterial属性、SetColor(“_EmissionColor”)、リアルタイムの効果リフレッシュはしていません。

コードは下記のように、

Renderer[] renderers = (Renderer[])mesh.GetComponentsInChildren<Renderer>();
foreach(Renderer r in renderers)
{
    r.sharedMaterial.SetColor("_EmissionColor", new Vector4(0.5f, 0, 0, 1));
}

テストでは、必ずエディターでこのシェーダーを選択しなければリフレッシュできないことが分かりました。

シェーダー中のGIを「Baked」に設定しますと、もし_EmissionColorの初期値が0であれば、Unityは直接にStandard Shaderの「_EMISSION」Keywordを閉じることになります。これで、_EmissionColorの設定がレンダリング結果への影響もなしになります。解決策は「_Emission」Keywordを同時に開くと設定します。すなわち、「r.sharedMaterial.EnableKeyword("_EMISSION");」を加えます。


レンダリング

Q3:下記の二つの図はmate9+OpenGLが我がチームのプロジェクトの最高画質を実行する時のProflierスクリーンであります(Unity 5.6.Op4)。図1の二番目のCamera.Renderには相当長いウェイトが観察され、これは私たちのUIカメラです。図から見えるのは、他のカメラがレンダリングタスクを完了するのを待って,自分のメインルートレンダリングタスクの実行を開始する。

そしてこれはほとんどのUIをオフしたとき、UIカメラはまたやっていますけど、あの異常のウェイトは出て来ませんでした。見えるのは、上記の図に二番目のCamera.Renderの最初の任務はWaitfofJogGroup。そしてJobThreadにも同時にParticleJobが出現しました。私たちは「このカメラにparticle systemが出たらこの状況が引き起こされます」と推測しますが、まだ確認していません。皆さんはこのような状況にあったことありませんか。そして本当にUnityにこの問題が存在していますか。もしこれは5.6バージョンの問題なら、次のバージョンに解決されましたか。

この状況はUnity5.6バージョンによく見られます。5.6.0でも最新の5.6.3でも、この問題は一切あります。下記の図には私たちが最適化した一つのプロジェクトのTimelineスクリーンショットです(Unity5.6.3)。5.6以前のバージョンにこのような問題はあまり見られません。

私たちから見ると、主な原因は二つあります。

⑴Unity5.6では、もっと多くのレンダリングコンピューティングをメインスレッドから子スレッドに移って処理します。メインスレッドは更に子スレッドの結果を待つ必要があり、それは図2のような「ウェイト」現象を引き起こします。つまりCamera.RenderのSelfコストであります。

⑵根本的な原因は単フレームのレンダリングの量は大きすぎです。例えば質問者があったUIレンダリング、粒子システムレンダリングやスキンメッシュなど。もしこれらの計算量が多きなら、子スレッドに大量のストレスを連れてあげる可能性があります。だから多くのプロジェクトがマルチスレッドレンダリング機能を開いたが、レンダリングの量に注意してください。

Unity 2017のプロジェクトとの接触はまだあまりありませんから、今は統計データを出すことはできません。質問者は先にUnity5.5の最新版に戻してやってみて、問題が解決できるかどうかを観察してください。

補充:

最後のテストが「Unity2017.1にも問題があります」と証明しました。ただウェイトのタイミングが変わりました:renderにはもうウェイトをしませんが、particlesystem.deactivateの時にウェイトをします。ですからこのようなtimelineは現れるかもしれません。

2017.2はテストしていませんけど、楽観はできませんと推測します。


ロード

Q4:下記の図のように、アセットが解放されていますが、テクスチャはまだメモリの中にあり、参照数は0であります。これはをのように破棄しますか。テクスチャのUIはDestroyで破棄しました、Resources.UnloadUnusedAssets();も執行しました。

Ref Countは0の場合にはResources.UnloadUnusedAssetsやResources.UnloadAssetでアンインストールできるはずです。この状況に私たちにアドバイスは:

⑴ Resources.UnloadUnusedAssetsをDestroy後の数フレームに執行してみます;

⑵ロード中にこれらのアセットを直接取得し、Destroy後にResources.UnloadAssetで指定されたアセットをアンインストールします。

 

⑴から試すのはUWAのおすすめです。


UWA Technologiesは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析最適化ソリューション及びコンサルティングサービスを提供している会社でございます。

UWA公式サイト:https://jp.uwa4d.com
UWA公式ブログ:https://blog.jp.uwa4d.com