UGUI Atlasバッチ処理時のInclude in オプションをどうのように理解しますか?

今回の主な話題:UGUI Atlasバッチ処理時のInclude in オプションをどうのように理解しますか、Android端末のジャムを指定する方法、フォグ効果を実現する方法、シリアライズ化されたファイルの冗長な引用をクリーンアップする方法。


UGUI

Q1: UGUIのバッチ処理についていくつかの疑問があります。

1)UGUIのバッチ処理はいつ行われましたか?バッチ処理はEditorで合併された大きな画像なら、AssetBundleをパッケージする時にアトラスファイルと関連する小さな画像のみがパッケージされて、合併した大きな画像は見ていませんでした。では、これはUnityがLate in bindingを行う時に合併しましたが?

2)Include in Buildにいったい何が含まれていますか?私の理解では、チェックすると生成した大きな画像が含まれ、チェックしないと含まれません。では、まだ質問1に戻ります。チェックしない場合、大きな画像は実行中に生成しましたか?

3)小さな画像のサイズはパフォーマンスに影響しますか?まず、小さな画像のソースはパッケージ本体のサイズに確実に影響します。

質問1と質問2に基づいて、大きな画像は実行時に生成されなら、大きな画像を生成する時に、I / Oはバイトストリームの形式で空白の大きな画像に入力、合併しますか?そうであれば、実行中大きな画像を生成するボトルネックはソースファイルのサイズと形式はずでしょう?(アトラスとソースの圧縮形式は違うと仮定します。)

回答は以下になります。

1、Unityのバッチ処理のタイミングは設定次第です。

上図のように、パッケージ化時でもエディターの実行時でも合併することができます。Editorで合併された大きな画像はキャッシュディレクトリLibraryAtlasCacheに配置されます。

2、About “Include in Build” behaviourを参照できます。

私の理解では、Include in Buildをチェックすると、アトラスリソースがAppにパッケージされます(AssetBundleパッケージではない)。アトラスはAssetBundleパッケージに管理させている場合、チェックしないほうがより良いです。そうしないとリソースは2倍になります。どちらのリソースは2倍になれるのは、テストする必要があります。

3、Unityは最終的に合併した大きな画像のみを使用し、小さな画像自体はリリースされたAppまたはAssetBundleパッケージに入らないため、小さな画像のソースファイルのサイズはパフォーマンスに直接影響しません。ただし、通常、小さな画像のサイズとSpriteの設定は、合併されたアトラスに影響を与えるため、最終的なパフォーマンスに間接的な影響を及ぼします。

Sprites Atlasが違うSprite Packer Modeオプションでパッケージすることについて、実験をしました。結果は次通ります。

1.最初の3つのオプション(Disabledと2つのLegacy Sprite Packer)の結果は同じ場合

パッケージしたAssetBundleに何もありません。この状況で、散図までもありませんはずです、完全にリソースをロードできません。

さらに、UnityのBugの疑いが見つかりました。新しく作成されたAtlasとすでにパッケージ化されているAtlasでは、禁止オプションでパッケージ化の結果が異なります。

2.後の2つのオプションの結果は同じ場合

AssetBundleパッケージを生成すると、アトラスがすでに作成されました。


制作

Q2: マテリアルのShader、またはGameObjectコンポーネントのMonobehaviorは、開発中に一つのShaderのPropertyまたはコードのシリアライズ化パラメータを削除する場合があります。これらのパラメータが削除された後、マテリアルまたはGameObject Prefabファイルにある、このパラメータのシリアライズ化データは削除されていません。

たとえば、下図にあるTestGetDependencyという名前のコンポーネント。パラメータtestSubjectがコードからもう削除されていました。

ただし、このGameObjectのPrefabに、testSubjectのレコードがまだ存在します。

これにより、AssetDataBase.GetDependenciesみたいな方法を使用してアセット依存を取得する時、testSubjectによって引用されるオブジェクトを取得するため、パッケージ化時に不要なリソースが含まれることになります。スクリプトを使用してSerializedObjectをスキャンする方法でこれらの引用をクリアできますが、これには違う状況ごとに個別のスクリプトが必要です(現在はShaderのみがマテリアルに対応し、コードファイルはPrefabに対応します)、遺漏または不適切な処理が行われる可能性があります。

ですから、Unityネイティブのクリーニング方法はあるかどうかを知りたいです。または、業界でスクリプトによってこのようなシリアライズ 化引用問題を処理する一般的な方法を知りたいです。

もう一度保存したら大丈夫です。

さらに厄介なのはShaderです。serializedObjectを自分で分析してからクリーンアップする必要があります。


レンダリング

Q3: 下図のように、パフォーマンスレポートで、Camera.Render下CreateVBOのオーバーヘッドが高いことがわかりました。これはどのように発生しますか?

これは基本的に、メッシュの再構築が引き起こします。非UGUIのUI再構築、テキストメッシュ再構築などで良く見られます。再構築する時のCPU時間コストは、主にメッチュ再構築の量に影響されます。ただ1フレームの場合、問題ありませんが、頻繁にオーバーヘッドが発生する場合は、特別な注意を払う必要があります。


制作

Q4: 図のように、インターフェイスフォグ効果を実現したいです。UIで実現するほうがいいでしょうか?それともそのようなシーンを作って実現するほうがいいでしょうか?現在の星図は3DのPrefabでアリ、黒いベースマップで覆い、影響範囲に応じてベースマップの明るい領域を変更する予定です。何か関するプラグインありますか?どこから始めればいいのでしょうか?

RenderTextureを作成できます。ピクセルとマップを1対1で対応させ、RenderTextureカラーの変更に介して、Shaderに対する計算を行って、効果を得ます。Unity 5.4以降、配列をShaderに渡すことでこの効果を実現できます。


メモリ管理

Q5: 異なるAndroidとApple設備で(1G、2G、3G、4G…)、クラッシュが発生しないように、ゲームのメモリピーク値をどのぐらい高く設置したら良いですか?

ここである人がiOSのメモリピークを更新し続けます。投稿の下で誰かがメモリピークをテストするためのツールも投稿しました。非常に使いやすく、参照できます。

https://stackoverflow.com/questions/5887248/ios-app-maximum-memory-budget.


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

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

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