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

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

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

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

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

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

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

>1、Unityのバッチ処理のタイミングは設定次第です。
![1-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/ca9cad59-0a54-7c9f-db0c-02625fd2ebff.png)
上図のように、パッケージ化時でもエディターの実行時でも合併することができます。Editorで合併された大きな画像はキャッシュディレクトリLibraryAtlasCacheに配置されます。

>2、[About “Include in Build” behaviour](https://forum.unity.com/threads/about-include-in-build-behaviour.481433)を参照できます。

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

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

>Sprites Atlasが違うSprite Packer Modeオプションでパッケージすることについて、実験をしました。結果は次通ります。
![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/e8a24c3e-3f46-a407-5d67-bbc7bdbe4264.png)
>1.最初の3つのオプション（Disabledと２つのLegacy Sprite Packer）の結果は同じ場合
![3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/23e06ab0-fd46-5bb5-ce86-4b60c2adb3fb.png)
パッケージしたAssetBundleに何もありません。この状況で、散図までもありませんはずです、完全にリソースをロードできません。

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

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

>AssetBundleパッケージを生成すると、アトラスがすでに作成されました。
![4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/01638bb3-5d9e-0c33-6995-3912347e5f17.png)

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

たとえば、下図にあるTestGetDependencyという名前のコンポーネント。パラメータtestSubjectがコードからもう削除されていました。
![5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/a69ced3c-9d9a-9e36-b007-dce9560c017f.png)
ただし、このGameObjectのPrefabに、testSubjectのレコードがまだ存在します。
![6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/11093fd3-8fa4-bb98-369f-64edac2a7604.png)
これにより、AssetDataBase.GetDependenciesみたいな方法を使用してアセット依存を取得する時、testSubjectによって引用されるオブジェクトを取得するため、パッケージ化時に不要なリソースが含まれることになります。スクリプトを使用してSerializedObjectをスキャンする方法でこれらの引用をクリアできますが、これには違う状況ごとに個別のスクリプトが必要です（現在はShaderのみがマテリアルに対応し、コードファイルはPrefabに対応します）、遺漏または不適切な処理が行われる可能性があります。

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

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

---
###レンダリング
Q3: 下図のように、パフォーマンスレポートで、Camera.Render下CreateVBOのオーバーヘッドが高いことがわかりました。これはどのように発生しますか？
![7-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/7b2460cb-dffc-fc58-1e78-8c44ab0c6694.png)
>これは基本的に、メッシュの再構築が引き起こします。非UGUIのUI再構築、テキストメッシュ再構築などで良く見られます。再構築する時のCPU時間コストは、主にメッチュ再構築の量に影響されます。ただ1フレームの場合、問題ありませんが、頻繁にオーバーヘッドが発生する場合は、特別な注意を払う必要があります。

---
###制作
Q4: 図のように、インターフェイスフォグ効果を実現したいです。UIで実現するほうがいいでしょうか？それともそのようなシーンを作って実現するほうがいいでしょうか？現在の星図は3DのPrefabでアリ、黒いベースマップで覆い、影響範囲に応じてベースマップの明るい領域を変更する予定です。何か関するプラグインありますか？どこから始めればいいのでしょうか？
![9.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/65d81d50-8d4c-e4be-78f2-91dda381a4b7.jpeg)
>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.
![10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/212ba7df-612d-499d-e29b-241d4147c23a.png)
![11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653855/18800ea3-c446-5e92-0fcf-3ccd0f0b3f2e.png)

---
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、**パフォーマンス分析**と**最適化ソリューション**及び**コンサルティングサービス**を提供している会社でございます。

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