昔に別れを告げる
前の 2 つの記事を読んだ後、開発者はもう冷静ではなく、多くの友人が Qilinzi に個人的にメッセージを送り、「
これほど多くの機能が追加されたので、パフォーマンスを実行できるでしょうか?」と言いました。
それは機能し、低下しなかっただけでなく、いくつかの面で大幅に改善されました。
なぜなら、「パフォーマンスの向上」は、Cocos Creator の重要なマイルストーン バージョンとして 3.6 が完了する必要がある目標でもあるからです。
この記事では、Cocos Creator 3.6 でのパフォーマンスの向上について見てみましょう。
Cocos Creator 3.x は、発売以来、開発者からパフォーマンスの向上を求められてきました。主に次のようないくつかの側面に焦点を当てます。
- ネイティブパフォーマンス
- 粒子の特性
- 2Dレンダリングパフォーマンス
これらの問題を心配している友人の皆さん、シャンパンを開け、Cocos Creator 3.6 を起動して、彼らに別れを告げる時が来ました。
続いて、3.6による性能向上を実測結果とエンジンの変更点の2段階から解説していきます。
ネイティブパフォーマンス
テストデータ
複雑な実行環境を可能な限りシミュレートするために、エンジン チームは静的シーン + アニメーション モデルの混合のテスト ケースを選択しました。
上の図から、同じテスト ケースでは、v3.6 が v3.5 より 50% 以上高いことが明確にわかります。
エンジンネイティブ
エンジンチームとやり取りした結果、得られた答えは「方法は比較的シンプルで、元々TS層にあったシーン管理やリソース管理などのモジュールをC++で再実装するというものです。」でした。
方法はシンプルですが、作業量が少ないというわけではありません。エンジンチームは 1 年以上にわたって懸命に取り組んできました。
Cocos Creator 3.6 以降、Cocos エンジンは「デュアルコア エンジン」、つまりネイティブ プラットフォーム上の C++ コアと非プラットフォーム上の JS/TS コアと呼ぶことができます。ネイティブプラットフォームです。
非常にコストがかかるため、この方法は業界ではまれです。2 つのエンジン コアの同じアーキテクチャを維持し、同じレンダリング効果を維持する必要があります。
しかし、この方法によってのみ、対応するプラットフォームをより適切に提供し、極端な場合には対応するプラットフォームに対して最高の最適化を行うことができます。
V3.3 vs. V3.6
左の図は Cocos Creator 3.3 のネイティブ化ステータスを示しており、青が C++ 部分、赤が TS 部分であり、v3.3 のステータスは次のとおりであることがわかります。
- TS モジュール: SeneGraph、Data Driven、AssetManager、Assets
- C++&TSモジュール：RenderScene
- C++ モジュール: RenderPipeline、GFX、FrameGraph
右の図は Cocos Creator 3.6 のネイティブ化ステータスを示しており、緑色が C++ 部分、青色が TS 部分であり、v3.6 のステータスは次のとおりであることがわかります。
- TSモジュール：AssetManager
- C++&TS モジュール: アセット、データドリブン
- C++ モジュール: SeneGraph、RenderScene、RenderPipeline、GFX、FrameGraph
この比較から、RenderScene モジュールと SceneGraph モジュールの完全なネイティブ化が、このパフォーマンスの向上に大きな役割を果たしたはずであることがわかります。
進行状況の観点から見ると、Assets と Data Driven のネイティブ化がほぼ完了しており、AssetManager も今後のバージョンで解決されるはずです。完全ネイティブ化という目標もそう遠くないので、その頃にはCocos Creatorのネイティブ側のパフォーマンスもかなり向上していると思います。
粒子の特性
上のスクリーンショットは、チームの同僚が Cocos Creator を使用して作成したプロジェクトからのもので、地面の各キャンドルと各炎は、複数のパーティクル エミッターで構成されています。v3.5 では、このシーンの実行が特に難しく、一部のパーティクル エフェクトはオフにすることしかできません。ただし、v3.6 バージョンでは、シーンの特殊効果が完全にオンになっているときでも、非常にスムーズです。
開発者らは、パーティクル システムのパフォーマンスによってアートが再生されるスペースが制限され、ゲーム効果が制限されることについて何度も言及しており、パフォーマンスを向上させるためにパーティクルのバッチ処理を追加したいと考えています。
3D レンダリングでのバッチ処理には 2 つのオプションがあります。
- 頂点バッファのマージ
- ジオメトリのインスタンス化 (GPU のインスタンス化)
ジオメトリのインスタンス化にはハードウェアとシステムのサポートが必要なため、これまでのシステムでは、エンジンはサポートされているデバイスではジオメトリ ソリッド化スキームを使用することを選択し、サポートされていないデバイスではメッシュ マージ スキームにフォールバックして最大限の使いやすさを確保していました。
ただし、DrawCall 自体によって引き起こされるパフォーマンスのボトルネックは主に CPU 側にあり、グリッドのマージは CPU のコンピューティング負荷を増加させるという犠牲を払っています。DrawCall を置き換えるためにグリッドのマージを使用することは、CPU リソースを CPU リソースに交換することと何ら変わりません。 、裏目に出る可能性があります。
ハードウェアの機能強化と新しいグラフィックス API の人気の高まりにより、ジオメトリ インスタンス化のカバー率は 100% に近づいています。したがって、パーティクル システムのマージでは、バッチ ソリューションとしてジオメトリのインスタンス化が選択されました。
注: Cocos Creator 3.6 以降の CPU パーティクルと GPU パーティクルは両方とも、ジオメトリ インスタンス化 (GPU インスタンス化) のバッチ処理をサポートしています。
同時に、メッシュ パーティクルもバッチ処理をサポートしており、パーティクル システムの場合、ビルボードであってもメッシュであっても、両者のバッチ処理に違いはありません。
Qilinzi は、エンジン グループが提供したテスト ケースを使用してテストしました。以下に示すように、545 CPU パーティクルの場合でも、30 フレーム以上を維持できます。
自分で試してみたい友人は、自分でテスト ケースをダウンロードできます: https://github.com/cocos/cocos-benchmark 、ロビーシーンから入ります。
2Dレンダリングパフォーマンス
Cocos Creator 3.x の 2D レンダリング性能が注目を集めていますが、開発者が最も期待しているのは、いつか 3.x の性能が 2.x バージョンに追いつくことです。
驚くべきことに、ネイティブ プラットフォームの 2D レンダリング パフォーマンスの最適化が、7 月 22 日のコミュニティのパブリック ベータ版に組み込まれました。以下に示すように:
抜粋せずにはいられません: 2D パフォーマンスは、ネイティブ プラットフォームでのさまざまなパフォーマンス テストで 2.x に追いつきました。
下の図から、ローエンドデバイス (HUAWEI-Honor v9 Android、iPhone 6s iOS) およびミッドレンジデバイス (XIAOMI8 Android、iPhone 11 iOS) で満足のいくパフォーマンスを達成していることがわかります。
多大な努力の末、Qilinzi は、この 2D レンダリング最適化アップグレードを担当するエンジン エンジニアの 1 人である同級生の Yatong を見つけました。2D パフォーマンスの向上に関するいくつかの主要な取り組みについて学びました。
エンジンネイティブ
エンジンのネイティブ化の恩恵を受けて、多くの計算が TS から C++ に変更され、言語コンピューティング機能のレベルからのみ大幅なパフォーマンスが向上しました。
モジュールが C++ に変更されると、C++ 自体の言語機能により、エンジン チームはより多くのメソッドを使用してパフォーマンスを最適化できるようになります。この部分には多くの改善がもたらされました。
メモリの最適化
おっしゃるとおり、2D のメモリ使用量も最適化されました。メモリの最適化がパフォーマンスの最適化に現れるのは、C++言語の特性によってもメモリの最適化がもたらされるためです。
バイト アライメント (Byte Alignment) と Union (Union) を使用した後、2D オブジェクトのメモリ使用量は元の半分だけになります。
TS層の最適化
エンジンがネイティブ化されると、TS 層がより簡潔になり、構造を最適化する機会も生まれます。このプロセスでは、いくつかの冗長な操作が削除され、遅延更新メカニズムが追加されます。コンポーネントのプロパティが変更されていない場合、計算は実行されません。
パイプラインの最適化
統一性を維持し、失敗率を減らすために、バージョン 3.x の初期の 2D オブジェクト レンダリングは共有 3D オブジェクト レンダリング プロセスですが、3D オブジェクト レンダリング プロセスの複雑さにより、CPU オーバーヘッドとメモリ オーバーヘッドの両方が 3.x よりも高くなります。純粋な 2D あまり多くありません。
ネイティブ化を行う際に、この問題も最適化され、特別な 2D パイプラインが再配置されました。2D オブジェクトと 3D オブジェクトのレンダリングは完全に独立しており、2D レンダリングが最小限のオーバーヘッドで実行されることが保証されます。CPU コンピューティングオーバーヘッド、DrawCall、大幅メモリ使用量、消費電力、過剰な IOによる発熱が改善されました。
要約する
パフォーマンスの向上は通常の作業であり、バージョンごとに繰り返し強化される部分です。
Cocos Creator 3.6 は完璧ではありません。たとえば、パッケージ本体、メモリ、読み込み速度などの点で改善の余地がまだ多くあります。公式のパフォーマンス テストではプロジェクトのすべての条件をカバーできません。より多くの実データを検証する必要があります。開発者自身がフィードバックを提供します。
しかし、最適化を続ける限り、将来的には必ずあらゆる面で 2.x を超え、優れた 2D&3D 統合デュアルコア エンジンになると Kirinzi は信じています。
ネイティブ パフォーマンス、パーティクル パフォーマンス、2D レンダリング パフォーマンスのいずれであっても、開発者はプロジェクト内で回避できないハードルに遭遇することが多く、エンジンが完成して初めて開発者は製品をより良くすることができます。
モバイル、ポータブル、ウェアラブルデバイスがますます洗練されていくこの時代において、究極のパフォーマンスと効果の追求は、最も矛盾しているが厳格な要求となっています。
Cocos Creator は、デュアルコアエンジン (ネイティブと Web)、スケーラブルなアーキテクチャ (高性能、低コスト) を維持しながら、エディターの機能改善と開発効率の向上に努力を惜しまないことが嬉しいです。消費電力、簡単なカスタマイズ）。
それが「ゲーム開発を容易にする」ことであっても、「テクノロジーを利用してデジタル コンテンツ業界の効率を高める」ことであっても。生産効率の向上という重要なポイントについて、ココスは初志を変えることなく邁進してまいりました。
最後に書きます
これまでのところ、Cocos Creator 3.6 の新機能の一覧は終了しています。
前述したように、このバージョン 3.6 の機能一覧の本来の目的は、新機能を分析する時間がない友人に詳細な説明を提供し、3.6 での重要な機能と機能改善の価値を掘り起こして提示することです。プロジェクトの選択とアップグレードの決定について、十分な情報に基づいた参照情報を提供します。
驚くべきことに、Qilinzi もこの在庫を通じて多くの利益を得ました。
インベントリのプロセスにおいて、Qilinzi は関連する詳細を慎重に調査および整理し、3.6 のアップグレード プロセスと対象となる主要なポイントを十分に理解したため、将来的には開発者とのコミュニケーションがより効率的かつ正確になります。
詳細を整理する過程で、不足している情報や問題点も多く見つかりましたが、関係者とコミュニケーションをとるうちに、作業状況や計画の検討事項がより詳しくなり、エンジンの開発ルートや次のステップの計画についての理解が深まりました。 。同時に、私のために邪魔をしてくれた同僚にも感謝したいと思います。誰もがすべてを知っていて、新しい機能の使い方を教えてくれた人もいました。
次のエンジン バージョンを楽しみに、Qilinzi はこのような記事を書き続けたいと考えています。