Unityベイク問題

今回の主な話題:UIアトラスの静的分離、Unityベイク問題、Unityレンダリング異常、Animation.RebuildInternalState。


UI管理

Q1: Unityの静的アトラスと動的アトラスの分離についていくつか質問があります。 当社のUI作成方法は以下になります。

●Prefab(UIHero)

●Prefabの静的アトラス(UIHeroAtlas)

●アバターなどのPrefabにおける可能な動的アトラス(UIHeroIcon)

生成されたBundle:

●PrefabはBundleを一つ(静的画像を含む)

●動的アトラスはBundleを一つ

後で、動的バッチでいくつかのDrawCallsを削減するために、静的アトラスに2〜3枚の画像があり、動的画像に小さな辺の背景として使用されます。次に、アーティストはそれを動的アトラスに配置します。これにより、画像が重なると、それと動的アトラスもDrawCallになります。

私たちの質問は、ABを使用してUI-prefabをロードするときに、動的アトラス(UIHeroIcon)を全体的にロードしますか?または、UIHeroIcon全体をロードするではなく、これらの2つの静的画像だけをロードしても、動的HeroIconはロードされませんか?この方式でUIHeroIcon動的アトラスをホットアップデートしますと、UIHero-prefabがこの2つの静的画像をロードできない状況を導く可能性がありますか?どのように選ぶべきですか?

 

1.ロードしますかどうかはあなた次第です。Unityは依存リストのみを提供し、ロードするかどうかは自分で制御します。

2.UIHeroIcon全体をロードしません。

3.こちらのDrawCallの数はほとんど同じです。ただし、前景は色々な可能性があり、アーティストが採用する方法も違います。私の理解では、静的アトラスに2つのSpriteAとBがあり、次に動的アトラスにAとBをコピーします。 重なっている場合、UIの深度が異なると、マージできない場合があります。 アセット構造も重要です。そうしないと、後でメンテナンスする時には 面倒になります。

 

UWAからの補充:上記の回答の3番目を補充します。DrawCallがどれだけ節約できるかを評価することをお勧めします。たとえば、10人のMOBAの場合、チームバトル中に10個のIconが重なるときがあります。それならDrawCallが20個になる可能性もあります。ローエンドの機器の場合、20個のDrawCallを節約できなら、価格/性能比は良いです。最悪の状況も10個未満の場合、そうする必要はありません。


レンダリング

Q2: Unity5.3でベイクして生成されたLightingData.asset、Lightmap-0_comp_dir.exr、Lightmap-0_comp_light.exrは別々に何かをできますか?パッケージ化およびロード時に実際に使用されるファイルはどれですか、またはすべて必要ですか?

LightingData.assetの紹介はこの2つのドキュメントで確認できます。

https://docs.unity3d.com/Manual/LightmapSnapshot.html

https://answer.uwa4d.com/question/5a4f4367e041ef3c50c9ce64

簡単に言うと、中に保存されたのはシーン内のLightmapの影響を受ける各オブジェクトの関する情報です。Editorでこのファイルは非常に大きい場合がありますが、実機では、precomputed giを使わない場合に携帯にパッケージ化のこの部分のデータは小さいすべきです(オブジェクトに対して、主なLightmap情報はlightmapIndexとlightmapScaleOffsetであります)。

なお、この部分の情報はシーンファイルにバインドされており、個別に管理することはできません。だからデフォルトでは、Lightmapはシーンでのみロードできます。ライトマップを動的にロードしたい場合は、この記事を参照してください:http://www.xuanyusong.com/archives/3807(中国語注意);後の2つの.exrファイルは、ライト情報を格納するテクスチャであり、_dirはライトの方向情報で、_lightはライトの強さ情報(最も簡単なモードでは一枚のみ必要です)。これらのファイルは実行時に必要ですが、exrはHDRをサポートする形式で、携帯では他の形式に変換され、サイズはexrとは異なります。


アニメーションシステム

Q3: Camera.RenderのAnimation.RebuildInternalStateは時間がかかり、頻繁にコールされますが、どのような状況でコールされますか?

UWA:このアイテムには2つの主な理由があります。

(1)問題主のプロジェクトは古いバージョンのアニメーションシステムを使用しています。

(2)Animationコンポーネントを含むGameObjectsで頻繁にActiveまたはInstantiate操作を実行します。通常、この状況は特殊効果、UI HUD、キャラクター/モンスターなどでよく見られます。

これについて、開発チームに上記の2つの点を確認することをお勧めします。


UI管理

Q4:UIの最適化に、各アトラスのメモリ使用量はパフォーマンスに影響が大きいですが、またはアトラスの数(draw call)の方に影響が大きいですか?たとえば、8 枚の1024アトラスと2枚の 2048アトラスはどちらが優れていますか?

実には、どちらが優れているかを示す統一された標準はありません。たとえば、4つの1024テクスチャが常に同じUIに表示され、同時にロードおよびレンダリングされる場合、通常は一枚の2048に合併することはもっと合理です。また、1〜2枚のテクスチャが同時に表示される状況も少ない場合、2048のテクスチャに合併することはメモリの浪費です。

この極端な状況に対する方法は問題主が考えることができますと思いますが、この部分は必要次第です。「どちらはいい」を判断できません。具体的な選択基準は、プロジェクトのメモリがより緊張であるか、UIのDrawCallがより緊張であるかによって異なります。

個人的な提案は、メモリに常駐する可能性のある汎用的なアセットに対して、最大2048または4096の一枚など、より大きいアトラスサイズ制限を与えることができます。単一ゲーム内の特有アトラスについては、UIを1024以内に提案します。使用量が3 枚の1024のレベルに達すると、2048のテクスチャサイズが採用できます。理論的に、1枚のテクスチャを加えると 1つのDrawCallしか増加しないことができますが、2枚のため2048テクスチャを使用すると、余白が増えたり、不当な合併が発生したりして、メモリ使用量が無駄になります。


レンダリング

Q5: Unity 5.5.2f1バージョンのプロジェクトで、いくつかのモデルがCull BackのShaderを使用するとき、レンダリングが異常になりました。新しいUnlit Shaderを作成し、Cull Backタグを追加しました。このShaderを使用してキャラクターをレンダリングすると、下記の問題が見つかりました。

Cull BackをCull OffまたはCull Frontに変更しても、効果は正常に戻りました。

ですから、モデルの表と裏が逆になっていると思いますが、同社のアーティストが「3dmaxのメッシュの表と裏は法線方向によって決定され、法線方向は正しいため、モデルアセットの問題ではありません。」と言いました。

だから、シェーダーを変更し、法線をフラグメントシェーダーの出力として使用すると、次の結果が得られます。

上の画像を見ると、法線に問題はないようですが、原因は何ですか?

三角形のfrontとbackは法線で決定ではなく、三角形の3つの頂点がスクリーンに投影される順序によって決まります。デフォルトでは、glesは反時計回りの面をfront、時計回りの面をbackとして認めています。上記の法線方向は正しいですが、face cullingとは関係ありません。問題を見ると、アーティストが出力した時に三角形の面の頂点の順番が逆になっているようですので、変更すれば問題を解決できます。

face cullingに関してはこの二つの関数を参照できます。

https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glCullFace.xml

https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glFrontFace.xml

実には、face cullingと法線は逆になっていることは違う現象であります。

1.face cullingの場合、そのShaderにCull Offの文を追加します。表示が上記のように正常である場合、それは面が逆になったと説明しました。

2.法線が逆になった場合、モデルを選択すると右下隅のプレビュー(またはシーンに直接lightを加えます)に黒で表示されます。なぜですか?dot(lightdir、normal)、法線が反転しているため、この値は基本的に0であり、diffuseとこの値の掛け算の結果も0になります。


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

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

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