CocosCreator最適化DrawCallの詳細な説明

序文

ゲーム開発において、DrawCall はゲーム全体のパフォーマンスに直接影響を与える非常に重要なパフォーマンス指標です。
Cocos Creator、Unity、Unreal などのゲーム エンジンであっても、ゲーム パフォーマンスの最適化には DrawCall が不可欠です。
この記事では、DrawCall とは何か、なぜ DrawCall を減らす必要があるのか​​、そして Cocos Creator プロジェクトで DrawCall を減らしてゲームのパフォーマンスを向上させる方法を紹介します。

ドローコールとは

DrawCall は、CPU がグラフィックス ライブラリ (DirectX や OpenGL など) のグラフィックス描画インターフェイスを呼び出して、GPU にレンダリング操作を実行するよう指示するものです。

DrawCall はパフォーマンスにどのような影響を与えますか?

例を挙げてみましょう:
1024 個の 1kb ファイルを http 経由でサーバーから取得するのと、1 つの 1M ファイルを取得するのとでは、どちらの方が時間がかかりませんか?
回答: 1 MB のファイルを 1 つだけプルする方が確実に高速です。
その理由は、各リクエストの前に、http はファイルが正常に送信できることを保証するために多くの準備を行う必要があるためです。そして、この余分な作業が、多くの時間とパフォーマンスのオーバーヘッドを引き起こします。

CPU は描画するたびに DrawCall を呼び出しますが、DrawCall を呼び出す前に、レンダリング ステータスの検出、レンダリングに必要なデータの送信、レンダリングに必要なステータスの送信など、多くの準備作業を実行する必要があります。
GPU 自体は非常に強力な計算能力を備えており、レンダリング タスクを非常に高速に処理できます。一般的に、100 個の三角形を描くのにかかる時間は、1000 個の三角形を描くのにかかる時間とほぼ同じです。
ただし、DrawCall が多すぎると、CPU に準備作業のための余分なオーバーヘッドが多く発生し、CPU 自体に負荷がかかり、GPU がアイドル状態になる可能性があります。

**つまり、CPU は各レンダリングの前に一連の準備を行う必要があり、CPU のメモリの読み書き、データ処理、レンダリング状態の切り替えごとに一定のパフォーマンスと時間の消費がもたらされ、それが時間の経過とともに蓄積され、GPU はほとんどの時間怠けているからです。
そのため、DrawCall が多すぎるとラグが発生すると考えられます。

ドローコールを減らす方法

前述のように、一度に CPU に多くの作業を割り当て、一度にレンダリングするコンテンツを増やし、割り当ての数を減らすことで目標を達成できます。
そうは言っても、実際にどのように実装すればよいのでしょうか?下を見る

画像リソース

静止画像

これは、断片化された写真を 1 つの大きな写真に統合することを意味します。これは、写真アルバムと呼ばれることもあります。
しかし、アトラスはランダムに作成されるわけではなく、大きな画像に小さな画像が多ければ多いほど良いというわけではありません。ここには特定のトリックが関係しています。

同じインターフェース（UI）内の同じレンダリングステータスを持つ隣接するフラグメントをアトラスにパックするようにしてください。

Creator の場合、ゲームの実行中、エンジンはノード階層の順序に従って上から下へ、浅いものから深いものへとレンダリングします。理論的には、レンダリングされた画像ごとに DrawCall が必要です (テキストも最終的には画像になります)。
レンダリング状態は、テクスチャ状態 (プリマルチプライケーション、ループ モード、フィルター モード) またはマテリアル、ブレンドなどを指すため、カスタム シェーダーを使用するとバッチ処理も中断されます。

したがって、隣接していて、同じレンダリング状態を持つことが重要なポイントです。
ヒント: 画像リソースのサイズが 2048*2048 を超えることはお勧めしません。そうしないと、読み込み関連の問題が発生する可能性があります。

写真コレクションを作成するには、次の 2 つの方法があります。

オートアトラス

Cocos Creator に組み込まれている自動アトラス リソースを使用して、フラグメントをアトラスにパックします。
プロジェクトがビルドされると、エディターは、すべての自動アトラス リソースが配置されているフォルダー内の要件を満たすすべての画像を、構成に従って 1 つ以上のアトラスにパッケージ化します。
自動アトラス リソースは非常に柔軟に使用できます。エディターは、アトラスをパッケージ化するときにサブディレクトリに自動的に再帰します。サブディレクトリに自動アトラス リソース (.pac ファイルなど) もある場合は、そのディレクトリはスキップされるため、同じディレクトリの異なる部分に異なるパラメータを設定できます。

自動アトラスに関するいくつかの提案

単一の画像の読み込み時間が長くならないように、アトラスの最大サイズを適切に制御します。大きすぎる画像（背景画像など）は、アトラスに含める必要はありません。 Sliced をうまく活用すると、多くのスペースを節約できます (これにはアートの専門家の協力が必要です)。画像の切り取りエラーや黒いエッジを回避するために、デフォルトの間隔 2 を維持し、余白拡張オプションをオンにしておきます。スペースを節約するために未使用の画像を自動的に除外するには、「参照されていないリソースを含めない」オプションをオンにします (このオプションはプレビュー中は無効です)。開発中にアトラスをプレビューし、結果に基づいて調整を行い、最適な最適化効果を実現します。

テクスチャパッカー

TexturePacker を使用してアトラスをパックする場合、特定の画像に隣接する画像のピクセルが表示される状況を回避するために、「Shape Padding (Auto Atlas の間隔に対応)」を構成する必要があります。

比較する

オートアトラス

• Cocos Creatorが内蔵されており、便利
• 機能は多くないが、必要なものはすべて揃っている
• アトラスはプロジェクトが構築されたときにのみ生成され、開発中に自由に変更する必要はありません。
• アトラスのサイズはスペースを節約するために生成時に適応されます
• 自動テクスチャ圧縮をサポート

テクスチャパッカー

• サードパーティのソフトウェアは自分でインストールする必要があり、あまり便利ではない
• 非常にプロフェッショナルだが基本的に必要のない有料機能が多く、無料機能で十分である
• 最初にアトラスを生成してから使用してください。画像を変更する場合は、アトラスを再生成する必要があります。
• 固定サイズは自分で設定する必要があります
• 自動テクスチャ圧縮と動的マージはサポートされていません

作成者の公式説明:

Cocos Creator は、プロジェクトをビルドするときに静的アトラス メソッド「Auto Atlas」を提供します。しかし、プロジェクトが大きくなると、テクスチャの数が非常に多くなり、テクスチャを 1 つの大きなテクスチャにまとめることが難しくなります。このとき、静的なテクスチャの組み合わせでは、DrawCall を削減するという要求を満たすことが困難です。
そのため、Cocos Creator はバージョン 2.0 で「ダイナミック アトラス」機能を追加しました。この機能により、プロジェクトの実行中にテクスチャを動的に 1 つの大きなテクスチャにマージできます。テクスチャをレンダリングする際、ダイナミックマージシステムは、テクスチャがアトラス（画像コレクション）にマージされているかどうかを自動的に検出します。 マージされていない場合、テクスチャがダイナミックマージの条件を満たしていれば、アトラスにマージされます。
動的画像組み合わせ公式ドキュメント:
https://docs.cocos.com/creator/manual/en/advanced-topics/dynamic-atlas.html

動的アトラスには 2 つの制限があります。

• ダイナミックアトラスの最大サイズは2048 * 2048です
• フラグメント化された画像のサイズは、デフォルトでは 512 を超えることはできませんが、API を通じて変更できます: cc.dynamicAtlasManager.maxFrameSize = 512

ヒント: 動的イメージのマージを有効にするとメモリ消費量が増加し、異なるプラットフォーム間でのメモリ使用量が不一致になります。デフォルトでは、ミニゲームとネイティブ プラットフォームでは動的画像合成は禁止されています。 API を介して自分で有効にすることができます: cc.macro.CLEANUP_IMAGE_CACHE = false; cc.dynamicAtlasManager.enabled = true;
また、動的バッチ処理を実現する前に、テクスチャの Premulyiply Alpha、Wrap Mode、Filter Mode などの情報が動的アトラスと一致していることを確認する必要があります。

さらに、静的アトラスも、動的マージの要件を満たしている限り、動的マージに参加できます。
ヒント 1: Auto Atlas リソースの場合、プロパティ インスペクター パネルのテクスチャ列の Packable オプションを有効にする必要があります。このオプションはデフォルトでは無効になっています。
ヒント 2: 画像を動的に結合するには、スプライトでも Packable オプションを有効にする必要があります。このオプションはデフォルトでオンになっています。
ヒント 3: シェーダーを使用する場合は、スプライトの Packable オプションを無効にする必要があります。

ラベル用

ビットマップフォント (BMFont)

Creator では、ラベルでシステム フォントまたは TTF フォントを使用すると、特にラベルとスプライトが重なり合ってインターレースされている場合に、レンダリング バッチが中断されます。各ラベルはバッチを中断し、DrawCall を追加します。

したがって、TTF またはシステム フォントの代わりに BMFont を使用し、BMFont と UI フラグメントを同じアトラスにパックする (または「動的な組み合わせをオンにする」) ことをお勧めします。これにより、ほとんどのテキストによって発生する DrawCall の増加を回避できます。

キャッシュモード

Creator 2.0.9 バージョンでは、システム フォントと TTF フォントによって発生するパフォーマンスの問題を解決するために、ラベル コンポーネントにキャッシュ モード オプションが追加されました。
CacheMode には 3 つのオプションがあります。

• NONE (デフォルト) 各ラベルは個別のビットマップとして生成され、動的マージには参加しないため、各ラベルはレンダリング バッチを中断します。
• BITMAP BITMAP モードをオンにすると、テキストもビットマップとして生成されますが、動的マージの要件を満たしている限り、動的マージに参加して周囲のスプライトと DrawCall をマージできます。 BITMAP モードは頻繁に変更されないテキストにのみ適しており、そうでない場合はメモリが爆発的に増加することに注意してください。
• CHAR CHAR モードがオンの場合、エンジンはラベルに表示されるすべての文字をグローバルに共有されるビットマップにキャッシュします。これは、BMFont を生成することと同じです。テキストが頻繁に変更される状況に適しており、パフォーマンスとメモリに最も優しいです。ヒント: このモードは、フォント スタイルとサイズが固定されており、未使用の文字が大量に頻繁に表示されないラベルにのみ使用できます。共有ビットマップの最大サイズは 2048*2048 であるため、いっぱいになると新しい文字をレンダリングできなくなり、シーンが切り替わったときにのみ共有ビットマップがクリアされます。

概要: 頻繁に変更される大量のテキストの場合、CHAR モードを使用することで得られるパフォーマンスの向上は非常に明白です。
同時に、CHARモードの限界も明らかです。これは通常、経験値の増加や体力の減少などの特殊効果と同様に、シーンに大量のデジタルテキストが表示される場合に使用されます。

唯一の方法 – UI階層の順序を調整する

原則として：

画像ノードとテキスト ノードを分離します。テキストには BMFont または Cache Mode オプションを使用し、テキストがレンダリング バッチを中断しないようにしてください。FBI 警告: Mask コンポーネントとそれが制御するレンダリング ノードには、少なくとも 3 回の Draw 呼び出しが必要です。テンプレート テストが初めてオンになり、テンプレート バッファーを更新するために Draw 呼び出しが呼び出されます。 2 番目の図では、テンプレート テストに合格する必要がある領域を設定します。 3 回目は、実際のサブノード コンテンツが描画され、描画が完了したらテンプレート テストが閉じられます。したがって、 Mask コンポーネントを使用する場合、他の隣接するノードとバッチ処理することはできませんが、Mask コンポーネント内の連続するノードは、マージ ルールが満たされていればバッチ処理されます。

要約する

テクスチャ状態 (プリマルチプライケーション、ループ モード、フィルタリング モード) の変更や、マテリアル、ブレンドの変更など、レンダリング状態を変更するとレンダリング バッチが中断されるため、カスタム シェーダーを使用するとバッチも中断されます。デフォルトでは、アトラスは動的マージに参加しません。自動アトラス リソースの Packable オプションを手動でオンにした後、最終的なアトラスが動的マージの要件を満たしている場合は、動的マージに参加することもできます。テクスチャで Packable オプションが有効になり、動的マージに参加した後は、動的マージによって元のテクスチャの UV 座標が変更されるため、カスタム シェーダは使用できません。キャッシュモードのBITMAPモードを使用する場合は、メモリ状況に注意する必要があります。CHARモードを使用する場合は、テキストコンテンツが多すぎないように注意する必要があります。 Cocos Creator 2.0.7 より前のバージョンでは、ノードの色や透明度を変更したり、Sprite コンポーネントで Sliced を使用したりすると、バッチ レンダリングが中断されます。

以上がCocosCreatorのDrawCallの最適化についての詳しい説明です。CocosCreatorのDrawCallの最適化についてさらに詳しく知りたい方は、123WORDPRESS.COMの関連記事もぜひご覧ください！