今回の主な話題：大きすぎる動的フォントFont Textureを回避する方法、シーンObjectが異なるマウスボタンに異なる応答イベントを生成することの実現方法、UGUIで、Canvasの下にあるUIを変更すると全てのUIを再描画させますか？、Idleアニメーションを再生するとキャラクターが移動します、更新後にシーンのテクスチャが黒くなる問題の解決方法。

UI

Q1: Failed to update dynamic font (arial) texture; all the needed characters do not fit onto a single texture (max size 4096). Try using less text or a smaller font size.
プロジェクトでは、フォントサイズを４つ（16、22、26、30）に制御しています。理論的には多くなくで、Android設備でも発生しません。調べでも問題がどこにあるのがわかりません。

FairyGUIを使用し、デフォルトで高解像度フォントモードを使用します。エディターでデザイン解像度とデザインフォントサイズを使用します。スマホで実際の解像度に応じて拡大します。たとえば、デザイン解像度が1280×720で、スマホ解像度が1920×1080の場合、フォントサイズは1.5倍に拡大されます。また、フォントコントロールには自動適応モードを使用しています。テキストの長さがコントロールの長さを超えると、フォントサイズが一致するために自動的に縮小されます。しかし、これでまたフォントサイズの数を制御できなくなります。

現在の解決策は、
1、高解像度フォントモードをキャンセルします。
2、プロジェクトに、偶数のフォントサイズのみを使用することを約束します。ソースコードを変更すると自動的に拡大縮小するフォントサイズも偶数のみを生成します。

Input

Q2：シーン内のオブジェクトをインスタンス化すると、オブジェクトはマウスポインターの出入りに応答します（たとえば、ポインターがオブジェクトを指すと色が変わり、移動すると色が復元されます）。同時に、マウスボタンの状態によって対応する必要もあり、左ボタンと右ボタンで異なる動作を行います。ObjectスクリプトのUpdateで判別すること以外に、何かもっと効率的な実現方法はありますか？

IpointerClickHandlerインターフェースを使用できます。
https://docs.unity3d.com/ScriptReference/EventSystems.IPointerClickHandler.html

using UnityEngine;
 using UnityEngine.EventSystems;
 using UnityEngine.Events;
 public class RightClick : MonoBehaviour, IPointerClickHandler
 {
     public UnityEvent leftClick;
     public UnityEvent middleClick;
     public UnityEvent rightClick;
     public void OnPointerClick(PointerEventData eventData)
     {
         if (eventData.button == PointerEventData.InputButton.Left)
             leftClick.Invoke ();
         else if (eventData.button == PointerEventData.InputButton.Middle)
             middleClick.Invoke ();
         else if (eventData.button == PointerEventData.InputButton.Right)
             rightClick.Invoke ();
     }
 }

上記のスクリプトをObjectに掛けたら大丈夫です。

UGUI

Q3: Canvasにある特定のUIが変更または移動された場合、または特定のUIが追加または削除された場合、Canvasにある全ての要素をRebuildしますか？

インターネットにあるほとんどの例では、Canvasをルートノードとして使用し、次にPanelをあるインターフェイスの親ノードとして使用し、Canvasの下に置きます。少し質問があります。UIの任意の変更がCanvasのRebuildやMeshの再計算などを引き起こされたら、Canvasが１つだけあるインターフェイスのレイアウト方法は、無意味のコストをたくさん導きませんか？

このようにデザインしたいです。各機能インターフェイスは、独立Canvasをコンテナーとして使用します。これで、このインターフェイスでのUIの変更は、他のCanvasに影響を与えず、すべてのUIが再描画されるわけではありません。このような考え方に問題はありますか？ Canvasが多い場合、追加のパフォーマンスコストが発生しますか？（私はDrawCallを考慮しましたが、許容範囲内です。）

他に何かできる方法ありませんか？

①

まず、UWAブログにある、UGUI最適化に関する記事をお勧めします。
「Unity UGUI最適化に関して、あう可能性のある問題」
次に、UI要素の位置、色、サイズを変更すると、Canvasが更新または再構築されます。再構築を回避するために、複雑なCanvasから頻繁に変化しているUI要素をできる限りに分離します。動的UI要素の変化が引き起こすメッシュ更新や再構築の範囲を狭くなさせ、導くパフォーマンスコストを低下させます。

もっと次に、通常、ゲーム全体にCanvasが１つしかない場合、確かに無意味のパフォーマンスコストがたくさん発生します。

最後に、各機能インターフェイスは、コンテナとして独立した小さなCanvasとして存在し、規模の小さなゲーム（ゲーム全体が10インターフェイスを超えることはありません）で使用したことがあります。すべてのプロジェクトで使用できるかどうか、詳細に分析する必要があると思います。

②

Canvasの分割に関しては、まず、各機能に独立したCanvasがあるはずで、表示/非表示をコントロールする時に便利です。そして、インターフェースの複雑な機能については、状況次第でサブCanvasを分離する必要があります。分離条件は、基本的に動的と静的の分離であり、UWAの記事を参照できます。

UGUIでは、Canvasが少ないほどDrawCallが少ないとは限らないため、この方面にあまり注意を払う必要はありません。また、インターフェイスが肥大な場合、再構築のコストはいくつかのDrawCallよりはるかに高くなります。

アニメーション

Q4: Idleアニメーションを再生するときにキャラクターモデルの位置を維持したいです。Apply Root Motionをオンにすると、キャラクターはわずかに変位して回転します。Apply Root Motionをオフにすると、キャラクターの位置は変わりませんが、動きは変になります。両足が地面に接触しなくなり、空中に浮かんでいるように足を振るのは不思議です。

Humanoidモードの場合、ここのBake Into Poseオプションを試すことができます。

Genericの場合、まずにここの設置がNoneであるかどうかを確認できます。

Noneであってもが問題はまたある場合、アニメーション圧縮をオフにして、精度の問題かどうかを確認してください。

テクスチャ

Q5: 2017.4.17f1から2017.4.18f1に更新した後（19f1と20f1にもこの問題が発生します）、Android 4で実行すると、シーンにある一部のテクスチャが黒くなりますが、一部のテクスチャは変えません。
問題のあるテクスチャもないテクスチャも、ETC1形式であり、マテリアルはDiffuseであります。

問題が発生したデバイスは次のとおりです。
Redmi Note1（4.4.4）、Redmi 2（4.4.4）、Samsung G3608（4.4.4）、Samsung Galaxy S3（4.3）、Oppo 1107（4.4.4）。

UWAが持っているRedmi 2（5.1.1）にこの問題は発生していませんでした。

@deviljz さんが「2018.2で黒くなるBugに遭遇した」と言って、下記の４つの要件に満たされたらテクスチャが黒くなれます。

1.アスペクト比が1：1ではありません。
2.Mipmapを開きます。
3.ETC圧縮を使用します。
4.Android 4.4。

私たちが遭った問題と同じだと思いますが、何かUnityバージョンを下げる以外に解決策はありますか？

解決策は、要件2または3を不満足になさせば十分です。

たとえば、OnPreprocessTextureを書いて、アスペクト比が1：1でないと判断すると、压缩形式を強制的にETC2にし、ETCではありません。

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

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