SRP複数のカメラの同時描画
今回の主な話題：SRP複数のカメラの同時描画、2つまたは以上のNavMeshを新しいNavMeshにマージする方法、UGUI ScrollRectがImage or RawImageを動的にロードします、Text.get_cachedTextGeneratorメモリ占用、Profiler与StatsとFrame Debuggerにあるデータの異なり。
SRP
Q1: 2台のカメラを使用して同じオブジェクトを観察しました。GraphicsのRenderPipelineAssetを設置していません場合、Gameビューでは2つのモデルが正常に表示されますが、一度設定されると、2つではなく１つのモデルだけは正常に表示されます。解決するために、このRenderPipelineに何か特殊な設置が必要ですか？
図に示すように、下部のGameビューでは、1つ目のカメラの内容だけが見えます。２つのカメラが既にdepth onlyを設置しました。
問題主はLWRPを試用していますか？LWRPは、built-inの中にある複数のカメラ内容を同じviewに合併して描画するような方式をサポートしていませんが、各カメラが各viewに描画する（view port rectの調整を介して）ことはまだ正常に機能しています。公式がこのMulti-Camera Trackingという方式をサポートしていない原因を告知しました、http://t.cn/EKEnqPi。
したがって、前に試用した問題を避ける方法は、１つのカメラが先にRTまで描画することですが、新しいバージョンのLWRPは、同じような機能を実現するためにCamera Tracking Systemを作成したようです。参考はこちら、http://t.cn/EKEn8eS
Navmash
Q2：ここで１つ要件があります。１枚の大きいマップを若干の小さなピースに分割したいです。目標はアーティストの操作を容易にし、そして各ピースのマップをベイクしてNavMeshを生成します。Unityが提供するNavMeshLinkには点を配置する必要があるので、操作には不便です。他に何かアイデアがありませんか？感謝します！
UnityのネイティブシステムはまだAPIが少なすぎます。このプラグインA * Pathfinding Project Pro(http://t.cn/EKEr86T)を試すことができます。これは１つのC#バージョンの完全なRecastNavigation実現であり、従来のGridパスファインディングも含まれ、さらに制御することができます。この動的なNavMeshについては、TileMeshを試すことができます。具体的にはRecastDemoにあるTileMeshを確認でき、要件によってTileを１つずつに創建できます。
UI
Q3: UGUI ScrollRectで、サーバーから大量の画像（画像のサイズは大きくありません）をロードして表示するために、RawImageを使用して表示するか、Spriteを作成してImageで表示しますか？これらの画像はユーザー自身がアップロードする可能性があるため、事前にアトラスにパッケージ化することはできません。この場合、一般的な方法は何ですかを聞きたいです。
1.まず、LoopScrollRect、SuperScrollViewなどのより効率的なScrollRectを使用します。
2.次に、サーバーはユーザーがアップロードした画像を前処理し、画像のサイズと形式を標準化する必要があります。
3.UIインターフェイスがユーザーによって頻繁にスワイプされる場合、アトラスの動的生成は考慮しません。RawImageはImageより優れています、原因はSpriteとは、Texture上の抽象的な領域であり、Textureに基づいて作成する必要があるからです。Textureを直接に使用するとこの一歩を省略できます。
4.UIインターフェイスが長時間に止まり、そしてDrawCallの圧力も高い場合は、RuntimeAtlas方案を採用してDrawCallを低下にすることができます。この度Imageを使用します。
Q：3と4に対して、私はこのように理解できますか。
RawImageを使用すると、実際にはSprite.Createの消費が節約され、実行中に創建したSpriteはPacking Tagを指定することはできませんから、アトラスに直接パッケージ化することはできず、batchさせられません。ここで１つの質問があります。UIに対して、Sprite.Create()が創建するSpriteは合併できないために、このやり方は根本的に無駄ですか？確定にアトラスにパッケージ化したい場合には、Runtime Atlasのような方案を採用して解決する必要があります。
その通りです。Textureは１つのサイズの同じSpriteのみがある場合、確かに無駄にしました。Spriteは、Textureアレアのカプセル化利用と見られます。例えば、borderで９マスの拡大縮小、アンカーポイントの設置などを実現したい時、単に画像全体を表示し、Textureを使用すれば大丈夫です。
UI
Q4: 質問があります。この「Text.get_cachedTextGenerator」は何ものですか？なぜこんな高いメモリを占用していますか？
これは、毎回TextがInstantiateまたはActive時にコールするものです。スタック情報から推測できます。クリックすると多数のTextコンポーネントがActiveになり、より高いMonoメモリの割り当てを引き起こします。Monoメモリ割り当ての図で確認し、具体的なスクリーンショットに従ってこの割り当ては適当かどうかをチェックすることをお勧めします。
Editor
Q5: 同じフレームなのに、ProfilerとStatsまたはFrame Debuggerにあるデータは異なることがわかりましたが、これはどうしてですか？
Stats、Frame Debuggerは理論的に、ProfilerのTotal Batchesと対応することができはずです。何か特殊なルールが異なり可能性があり、例えばClear操作はBatchですかではないかとか。２つ組のデータを見ると、実際に差があまり大きくないです。
ProfilerのDrawCallとTotal Batches間の差別に関しては、これを参考しなさい。
https://answer.uwa4d.com/question/59ddc3fa43cf099e2d2295be（中国語注意）
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com
UWA公式Q＆Aコミュニティ(中国語注意)：https://answer.uwa4d.com
