Godot: ほとんどの場合、最も遅いデータ構造を使用します。

誰がパフォーマンスを必要としますか？ ：ドヤ顔：

あなたが何を測定するのか知りたいです。

それで、これは、Godotの単純なLight2Dノードがコンピューターを焼き付けることができる理由を説明できますか？

@Ranollerそうは思いません。 悪いライティングパフォーマンスは、Godotが現時点で2Dライティングを実行する方法に関連している可能性があります。すべてのスプライトをn回レンダリングします（nはそれに影響を与えるライトの数です）。

編集：＃23593を参照

明確にするために、これはコード全体のCPU側の非効率性に関するものです。 これは、godot機能やgodotGPUレンダリング自体とは何の関係もありません。

@ vblanco20-1ちょっとした接線で、あなたと私は、代わりにECSエンティティとしてモデル化されているノードについて話しました。 トリックは、ツリーと徐々に並行して機能する新しいentモジュールを使用してgodotの機能ブランチを実行することであるかどうか疑問に思います。 get_tree（）やget_registry（）のように。 entモジュールはおそらくツリー/シーンの機能の80％を見逃しますが、テストベッドとして、特に多数のオブジェクトを含む大きな静的レベルの作成（カリング、ストリーミング、バッチレンダリング）などに役立つ可能性があります。 機能性と柔軟性が低下しますが、パフォーマンスは向上します。

完全なECSに進む前に（私はそうするかもしれませんが）、実験としていくつかのぶら下がっている果物に取り組みたいと思います。 後で完全なデータ指向にしようとするかもしれません。

したがって、最初の更新：

update_dirty_instances：0.2〜0.25ミリ秒から0.1ミリ秒
octree_cull（メインビュー）：0.35ミリ秒から0.1ミリ秒

楽しい部分は？ octree cullの代わりにアクセラレーション構造を使用せず、すべてのAABBを含むダム配列を反復処理するだけです。

さらに面白い部分は？ 新しいカリングは10行のコードです。 私がそれを平行にしたいのなら、それはラインへの単一の変更でしょう。

ライトを使用して新しいカリングを実装し続け、スピードアップがどれだけ蓄積されるかを確認します。

おそらく、マスターブランチにもGoogleベンチマークディレクトリを配置する必要があります。 それは検証に役立つかもしれないので、人々はそれについて議論する必要はありません。

godotengine / godot-testsリポジトリがありますが、まだ多くの人がそれを使用していません。

新しいアップデート：

Iveは、2つのレベルで、かなり馬鹿げた空間加速構造を実装しました。 フレームごとに生成するだけです。さらに改善すると、再作成するのではなく、改善して動的に更新することができます。

画像では、異なる行は異なるスコープであり、色付きのブロックはそれぞれタスク/コードのチャンクです。 そのキャプチャでは、八分木カリングと私のカリングの両方を並べて行って、直接比較します

これは、加速構造全体を再作成する方が、単一の古い八分木カリングよりも高速であることを示しています。
また、それ以上のカリングは、現在の八分木の約半分から3分の1になる傾向があります。

私のダム構造が現在の八分木よりも遅いというケースは、最初の作成のコストを除いて、1つも見つかりませんでした。

もう1つの利点は、非常にマルチスレッドに対応しており、並列処理を使用するだけで、必要なコア数に拡張できることです。

また、メモリを完全に連続してチェックするので、それほど面倒なことなくSIMDを実行できるはずです。

もう1つの重要な詳細は、現在のoctreeよりもはるかに単純で、コード行がはるかに少ないことです。

あなたはゲーム・オブ・スローンズの終わりよりも多くの誇大宣伝を引き起こしています...

アルゴリズムを少し変更して、C ++ 17並列アルゴリズムを使用できるようにしました。これにより、プログラマーは、並列または並列ソートを実行するように指示することができます。
メインの錐台カリングで約x2のスピードアップがありますが、ライトの場合は以前とほぼ同じ速度です。

私のカラーは、メインビューのgodotoctreeよりも10倍高速になりました。

変更点を確認したい場合、主な重要事項は次のとおりです。
https://github.com/vblanco20-1/godot/blob/4ab733200faa20e0dadc9306e7cc93230ebc120a/servers/visual/visual_server_scene.cpp#L387
これが新しいカリング機能です。 加速構造はそのすぐ上の機能にあります。

これはVS2015でコンパイルする必要がありますか？ コンソールは、entt \内のファイルに関する一連のエラーをスローします

@Ranollerはc ++ 17なので、新しいコンパイラを使用していることを確認してください

ええと、Godotはまだc ++ 17に移行していなかったと思いますか？ 少なくとも私はこのトピックに関するいくつかの議論を思い出しますか？

GodotはC ++ 03です。この動きは物議を醸すでしょう。 @ vblanco20-1が休日を終えたら、フアンと話すことをお勧めします...この最適化は素晴らしいものであり、すぐに「これは決して起こらないTM」を望んでいません。

@ vblanco20-1

octree_cull（メインビュー）：0.35ミリ秒から0.1ミリ秒

オブジェクトはいくつですか？

@ nem0

@ vblanco20-1

octree_cull（メインビュー）：0.35ミリ秒から0.1ミリ秒

オブジェクトはいくつですか？

2200年頃。チェックが非常に小さい場合、godot octreeは早期に終了するため、パフォーマンスが向上します。 クエリが大きいほど、godotoctreeは私のソリューションと比較して遅くなります。 godot octreeがシーンの90％を早期に処理できない場合、オブジェクトごとにリンクリストを本質的に反復するため、非常に遅くなりますが、私のシステムは、各キャッシュラインが大量のAABBを保持する配列の構造であり、大幅に削減されます。キャッシュミス。

私のシステムは、2つのレベルのAABB、つまりブロックの配列を持つことで機能し、すべてのブロックが128のインスタンスを保持できます。

トップレベルは、ほとんどがAABBの配列+ブロックの配列です。 AABBチェックに合格した場合は、ブロックを繰り返します。 ブロックは、AABB、マスク、およびインスタンスへのポインターの構造の配列です。 このようにすべてがfaaaaastです。

現在、トップレベルのデータ構造の生成は非常に馬鹿げた方法で行われています。 より適切に生成された場合、そのパフォーマンスははるかに大きくなる可能性があります。 128以外の異なるブロックサイズでいくつかの実験を実行しています。

私はさまざまな数をチェックしましたが、ブロックあたり128は、どういうわけかまだスイートスポットのようです。

アルゴリズムを変更して「大きな」オブジェクトを小さなオブジェクトから分離することにより、iveは、主にマップの中心を調べていない場合に、さらに30％の速度アップグレードを得ることができました。 これは、大きなオブジェクトが小さなオブジェクトも含むブロックAABBを肥大化させないために機能します。 おそらく3つのサイズが最適だと思います。

ブロック生成はまだまったく最適ではありません。 大きなブロックは、中央を見るとインスタンスの約10〜20％、マップの外側を見ると最大50％しかカリングしないため、必要以上に多くの追加のAABBチェックを実行します。

おそらく、現在の八分木を再利用するが、それを「平坦化」することで改善されると思います。

並列実行がなくても、私のアルゴリズムが現在のoctreeと等しいかそれより悪いケースは1つもありません。

@ vblanco20-1 releaseモード（ -O3 ）でコンパイルされたgodotとの比較を行っており、通常のエディタービルドインデバッグ（最適化がなく、デフォルト）ではないと思います。 ？
ばかげた質問なら申し訳ありませんが、スレッドにはそのことについての言及はありません。
とにかくいい仕事:)

@Falessそのrelease_debugは、いくつかの最適化を追加します。 ゲームを開くことができないため、完全な「リリース」をテストできませんでした（ゲームもビルドする必要がありますか？）

カリングをさらに改善し、すべてのフレームを再生成する必要をなくし、より良い空間最適化を作成する方法についてのアイデアがありました。 私が何を試すことができるかわかります。 理論的には、そのようなものは再生を削除し、メインカリングのパフォーマンスを少し改善し、カリングのパフォーマンスを大幅に向上させるポイントライト用の特定のモードを備えているため、コストはほぼゼロになります。 「半径内のオブジェクト」を取得するための安価なO（1）に変わります。

それは、私の実験の1つがどのように機能したかに触発されました。そこでは、400.000の物理オブジェクトが互いに跳ね返っています。

新しいカリングが実装されました。 ブロック生成がはるかにスマートになり、より高速なカリングが可能になりました。 ライトの特殊なケースはまだ実装されていません。
私はそれを私のフォークにコミットしました

現在のマスターブランチからのビルドでそのベンチマークツール（スクリーンショットのもの）を実行して、実装が現在の実装に対してどれだけのパフォーマンスを提供しているかについての参照ポイントを提供できるかどうか知りたいです。 私はダミーです、うわー。

@ LikeLakers2スクリーンショットで現在の実装と彼の実装の両方を見ることができます。

彼はこれをマスターフォークで走らせました

2018年12月12日（水曜日）には、MichiRecRoom [email protected]
書きました：

@neikeq https://github.com/neikeq説明しますか？ スクリーンショットだと思いました
投稿されたものは、投稿がどのように行われたかを考えると、彼の実装のみでした
スクリーンショット付きはこれまでのところ言葉で表現されています。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/23998#issuecomment-446831151 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ADLZ9pRh9Lksse9KBfWV0z5GmHRXf5P2ks5u4crCgaJpZM4YziJp
。

このトピックに関するニュースはありますか？

このトピックに関するニュースはありますか？

私はreduzと話しました。 プロジェクトに適合しないため、マージされることはありません。 代わりに他の実験をしに行きました。 たぶん私は後でカリングを4.0にアップグレードします

それが本当に有望に見えたことを考えると、それは残念です。 うまくいけば、これらの問題は時間内に取り組むでしょう。

おそらくこれは4.0マイルストーンを与えられるべきですか？ ReduzはVulkanfor 4.0での作業を計画しているため、このトピックはパフォーマンスについてですが、レンダリングに焦点を当てています。少なくともOPはそうです。

@ vblanco20-1彼はそれがどのように適合しないかを言いましたか？ c ++ 17への移行のためだと思いますか？

ただし、マイルストーンには他にも関連する問題があります：＃25013

あなたは興味があるかもしれません。 私はかなり長い間派手なフォークに取り組んできました。 現在の結果は次のとおりです。
4コアのIntelCPUとGTX1070を搭載した大型ゲーミングノートパソコンでキャプチャ
通常のgodot

https://github.com/vblanco20-1/godot/tree/ECS_Refactorの私のフォーク

どちらのプロファイルでも、赤は本質的に「GPUを待つ」ものです。 openglでのドローコールが多すぎるため、現在ボトルネックになっています。 バルカンやレンダラー全体を書き直すことなく、カントは本当に解決されます。

CPU側では、13ミリ秒フレームから5ミリ秒フレームになります。 「高速」フレームは5.5ミリ秒から2.5ミリ秒になります
「トータルフレーム」側では、13ミリ秒から8〜9ミリ秒になります
〜75 FPS〜〜115 FPS

より少ないCPU時間=ゲームプレイにより多くの時間を費やすことができます。 現在のgodotはCPUでボトルネックになっているため、ゲームプレイに費やす時間が長くなるとFPSが低くなりますが、フォークはGPUにバインドされているため、CPUは「無料」であるため、FPSを変更せずにゲームプレイロジックをさらに追加できます。かなり長い間すべてのフレーム。

godotが最新のC ++をサポートし、非常に安価な「小さな」タスクを可能にするマルチスレッドシステムを備えていれば、これらの改善点の多くはgodotにマージ可能です。
最大の利点は、動的オブジェクト＃25013でマルチスレッドシャドウとマルチスレッドライトマップの読み取りを実行することによって行われます。 これらは両方とも同じように機能します。 レンダラーの他の多くの部分もマルチスレッド化されています。
他の利点は、godotよりも10倍から20倍速いOctreeであり、カリングリストを繰り返す代わりに、深度プリパスとノーマルパスの両方のレンダリングリストを一度に記録するなど、レンダリングのフローの一部が改善されています2。時間、およびライト->メッシュ接続の動作方法の大幅な変更（リンクリストなし！）

現在、TPSデモ以外のテストマップを探しているので、他のタイプのマップでより多くのメトリックを使用できます。 また、これらすべてがどのように機能するかを詳細に説明する一連の記事を書くつもりです。

@ vblanco20-1これは完全に素晴らしいです。 共有してくれてありがとう！

また、Vulkanはかっこいいですが、GLES3のパフォーマンスが適切であれば、Godotにとって絶対的な勝利になることにも同意します。 GLES3にパッチを適用することは、ここにいる人々が今完全に実行可能であることが証明されている間、完全なVulkanサポートはすぐには着陸しない可能性があります。

これにますます注目を集めるための私の巨大な+1。 ReduzがコミュニティにGLES3の改善を許可することに同意した場合、私は地球上で最も幸せな人になるでしょう。 私たちはGodotで非常に深刻な3Dプロジェクトを1。5年間行っており、Godot（寄付を含む）に対して非常に協力的ですが、60 FPSがしっかりしていないと、私たちは本当に意欲を失い、すべての努力を大きなリスクにさらします。

これが十分なクレジットを取得していないのは本当に残念です。 現在の（3Dに関しては非常に単純な）プロジェクトで今後数か月以内に60 FPSが得られない場合、プレイ可能なゲームを提供できず、すべての労力が無駄になります。 ：/

@ vblanco20-1正直なところ、私はあなたのフォークを本番環境のゲームのベースとして使用することも検討しています。

PSいくつかの考え：最後の手段として、たとえば、2つのGLES3ラスターライザー（GLES3とGLES3-コミュニティ）を持つことさえ完全に可能だと思います。

PSいくつかの考え：最後の手段として、たとえば、2つのGLES3ラスターライザー（GLES3とGLES3-コミュニティ）を持つことさえ完全に可能だと思います。

それは私には意味がありません。 修正とパフォーマンスの改善をGLES3およびGLES2レンダラーに直接取得することをお勧めします（既存のプロジェクトで主要な方法でレンダリングが中断されない限り）。

他の利点は、godotよりも10倍から20倍速いOctreeであり、カリングリストを繰り返す代わりに、深度プリパスとノーマルパスの両方のレンダリングリストを一度に記録するなど、レンダリングのフローの一部が改善されています2。時間、およびライト->メッシュ接続の動作方法の大幅な変更（リンクリストなし！）

@ vblanco20-1 C ++ 03を使用したまま、深度プリパスを最適化することは可能でしょうか？

@Calinou深度プリパスのものは、何も必要とせず、非常に簡単にマージできるものの1つです。 その主な欠点は、レンダラーが追加のメモリを使用する必要があることです。 1つだけではなく2つのRenderListが必要になるためです。 余分なメモリを除いて、マイナス面はほとんどありません。 1パスまたは2パスのレンダーリストを作成するコストはCPUキャッシングのおかげでほぼ同じであるため、プリパスfill_list（）のコストをほぼ完全に排除します。

@ vblanco20-1正直なところ、私はあなたのフォークを本番環境のゲームのベースとして使用することも検討しています。

@ and3rsonはしないでください。 このフォークは純粋に研究プロジェクトであり、完全に安定しているわけでもありません。 実際、並列STLを使用しているため、一部の非常に特殊なコンパイラーの外部でコンパイルすることすらできません。 フォークは主にランダムな最適化のアイデアと実践のテストベッドです。

Godotのプロファイルを作成するために使用しているツールは何ですか？ これらのサンプルを生成するために、godotソースにProfiler.BeginフラグとProfiler.Endフラグを追加する必要がありましたか？

Godotのプロファイルを作成するために使用しているツールは何ですか？ これらのサンプルを生成するために、godotソースにProfiler.BeginフラグとProfiler.Endフラグを追加する必要がありましたか？

Tracyプロファイラーを使用しており、ここで使用するさまざまなタイプのスコーププロファイルマークがあります。 たとえば、ZoneScopedNC（ "Fill List"、0x123abc）は、その名前と必要な16進色のプロファイルマークを追加します。

@ vblanco20-1-これらのパフォーマンスの改善のいくつかがgodotメインブランチにもたらされるのを見ますか？

@ vblanco20-1-これらのパフォーマンスの改善のいくつかがgodotメインブランチにもたらされるのを見ますか？

たぶんC ++ 11がサポートされているとき。 しかし、reduzは、vulkanが発生する前にレンダラーでこれ以上の作業を望んでいないため、決してそうならない可能性があります。 最適化作業の結果のいくつかは、4.0レンダラーに役立つ可能性があります。

@ vblanco20-1ブランチのコンパイラと環境の詳細を共有することを心がけています。私はそれのほとんどを理解できると思いますが、必要がなければ問題を理解するのに時間を無駄にしないでください。

また、AABBの変更をGodotメインに追加することはできませんか？

@ vblanco20-1ブランチのコンパイラと環境の詳細を共有することを心がけています。私はそれのほとんどを理解できると思いますが、必要がなければ問題を理解するのに時間を無駄にしないでください。

また、AABBの変更をGodotメインに追加することはできませんか？

@swarnimarun Visual Studio 17または19は、後の更新の1つであり、正常に機能します。 （ウィンドウズ）
sconsスクリプトは、cpp17フラグを追加するように変更されました。 また、現在、エディターの起動が壊れています。 私はそれを復元できるかどうかを確認するために取り組んでいます。

悲しいことに、AABBの変更は最大のものの1つです。 Godot octreeは、ビジュアルサーバー内の多くのものと絡み合っています。 カリングのためにオブジェクトを追跡するだけでなく、オブジェクトをペアリングするための独自のシステムを使用して、オブジェクトをライト/反射プローブに接続します。 これらのペアは、octreeのリンクリスト構造にも依存しているため、ビジュアルサーバーを大幅に変更せずに、現在のoctreeをより高速に適応させることはほとんど不可能です。 実際、私はまだいくつかのオブジェクトタイプのフォークで通常のgodot八分木を取り除くことができませんでした。

@ vblanco20-1 Patreonはありますか？ 私はパフォーマンスに焦点を合わせたフォークにいくらかのお金をかけます、そしてそれはそれ自体を古代のC ++に制限しません、そしておそらく私だけではありません。 3DプロジェクトのためにGodotをいじってみたいのですが、コアチームへのパフォーマンスと使いやすさへのアプローチを証明する概念の巨大な証拠がなければ、Godotが実行可能になるという希望を失っています。

@mixedCaseGodotのあらゆる種類のフォークをサポートすることを非常に躊躇します。 フォークと断片化は、多くの場合、オープンソースプロジェクトの死です。

より良いシナリオ、そして新しいC ++が大幅な最適化を可能にすることが実証された今では、GodotがC ++の新しいバージョンに正式にアップグレードすることです。 これはGodot4.0で発生し、3.2での破損のリスクを最小限に抑え、Godot4.0にVulkanが追加されて新しいC ++機能が利用されるのに間に合うと思います。 また、reduzがGLES 3レンダラーを削除したいので、GLES3レンダラーに大きな変更が加えられることはないと思います。

（しかし、私はGodotの開発者のために話しません、これは私の推測です）

@aaronfranke同意します、パーマネントフォークは理想的ではないと思います。 しかし、彼の言ったことから私が集めたもの（私が間違っている場合は訂正してください）は、 @ reduzは、これらの新しい機能は概念を学ぶ価値のある重要なものをもたらさないため、使用すべきではないと信じているということです。それらのいくつかをコードを「読めない」ものとして認識します（少なくとも、C ++がほぼ10年前にあった「拡張C」に慣れている開発者にとっては）。

フアンは非常に実用的な人物だと思います。そのため、最新の抽象化とより効率的なデータ構造を使用して、エンジニアリングのトレードオフに価値があることを彼に納得させることの利点を示す大きな概念実証が必要になるでしょう。 @ vblanco20-1はこれまで素晴らしい仕事をしてきたので、彼がそのようなことをしたいのなら、私は個人的に毎月いくらかのお金を彼に向けて置くことを躊躇しません。

Godotの開発者が、優れたアイデア、パフォーマンス、進歩にアレルギーがあるように振る舞うことに、私は絶えず驚いています。 これが引き込まれなかったのは残念です。

これは、最適化について、正確にはデータ構造の使用法について取り組んでいる一連の記事の一部です。

GodotはSTLコンテナとそのC ++ 03を禁止しています。 これは、コンテナに移動演算子がなく、コンテナがSTLコンテナ自体よりも悪い傾向があることを意味します。 ここに、godotデータ構造の概要とそれらの問題があります。

事前に割り当てられたC ++配列。 エンジン全体で非常に一般的です。 そのサイズは、いくつかの構成オプションによって設定される傾向があります。 これはレンダラーでは非常に一般的であり、適切な動的配列クラスがここでうまく機能します。
誤用の例： https ：
この配列は、正当な理由もなくメモリを浪費しています。動的配列を使用すると、コンパイル定数による最大サイズではなく、必要なサイズのみになるため、ここでは非常に優れたオプションになります。 MAX_INSTANCE_CULLを使用する各Instance *アレイは、0.5メガバイトのメモリを使用しています

Vector（vector.h） std :: vector動的配列と同等ですが、深い欠陥があります。
ベクトルは、コピーオンライトの実装でアトミックに再カウントされます。 あなたがするとき

ベクトルa = build_vector（）;
ベクトルb = a;

refcountは2に移動します。BとAはメモリ内の同じ場所を指し、編集が行われると配列をコピーします。 ベクトルAまたはBを変更すると、ベクトルコピーがトリガーされます。

ベクトルに書き込むたびに、アトミックrefcountをチェックする必要があり、ベクトル内のすべての書き込み操作が遅くなります。 godotVectorは少なくともstd :: vectorより5倍遅いと推定されています。 もう1つの問題は、ベクターからアイテムを削除すると、ベクターが自動的に再配置され、制御不能なパフォーマンスの問題が発生することです。

PoolVector（pool_vector.h）。 ベクトルとほぼ同じですが、代わりにプールとして使用します。 Vectorと同じ落とし穴があり、理由もなくコピーオンライトと自動ダウンサイジングがあります。

リスト（list.h）std :: listと同等。 リストには、2つのポインター（最初と最後）+要素カウント変数があります。 リスト内のすべてのノードは二重にリンクされており、さらにリストコンテナ自体への追加のポインタがあります。 リストのすべてのノードのメモリオーバーヘッドは24バイトです。 ベクターは一般的にあまり良くないため、godotではひどく酷使されています。 エンジン全体でひどく誤用されました。

大きな誤用の例：
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L129
これがリストである理由は何もありません、ベクトルであるべきです
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L242
このケースのすべてが間違っています。 繰り返しますが、それはベクトルまたは類似のものでなければなりません。 これは実際にパフォーマンスの問題を引き起こす可能性があります。
最大の間違いは、カリングに使用される八分木でリストを使用することです。 このスレッドでは、godotoctreeについてすでに詳しく説明しました。

SelfList（self_list.h）は、boost :: intrusive_listに似た侵入型リストです。 これは、自分自身も指すため、ノードごとに常に32バイトのオーバーヘッドを格納します。 エンジン全体でひどく誤用されました。
例：
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L159
これは特に悪いです。 エンジン全体で最悪の1つ。 これは、理由もなく、エンジン内のすべてのレンダリング可能なオブジェクトに8つの太さのポインターを追加します。 これがリストである必要はありません。 繰り返しになりますが、スロットマップまたはベクターにすることができ、それを置き換えました。

Map（map.h）赤黒木。 ほとんどすべての用途でハッシュマップとして誤用されています。 使用法に応じて、OAHashmapまたはHashmapを優先して、エンジンから削除する必要があります。
私が見たマップのすべての使用は間違っていました。 意味のある場所で使用されているマップの例が見つかりません。

ハッシュマップ（hash_map.h）は、リンクリストバケットに基づくクローズド

OAHashMap（oa_hash_map.h）新しく作成された高速オープン

CommandQueueMT（command_queue_mt.h）ビジュアルサーバーなどのさまざまなサーバーとの通信に使用されるコマンドキュー。 これは、ハードコードされた250 kb配列をアロケータープールとして機能させることで機能し、すべてのコマンドを仮想call（）およびpost（）関数を使用してオブジェクトとして割り当てます。 ミューテックスを使用して、プッシュ/ポップ操作を保護します。 ミューテックスのロックは非常にコストがかかるため、代わりにmoodycamelキューを使用することをお勧めします。これは、桁違いに高速である必要があります。 これは、多くの移動オブジェクトのように、ビジュアルサーバーで多くの操作を実行するゲームのボトルネックになる可能性があります。

これらは、godotのデータ構造のコアセットです。 適切なstd :: vectorに相当するものはありません。 「動的配列」データ構造が必要な場合は、Vectorに悩まされ、書き込み時のコピーとダウンサイジングに欠点があります。 DynamicArrayデータ構造は、godotが今最も必要としているものだと思います。

私のフォークには、外部ライブラリのSTLやその他のコンテナを使用しています。 2つのハッシュマップを除いて、パフォーマンスの点でSTLよりも悪いため、godotコンテナーは避けています。

4.0のvulkan実装で見つかった問題。 私はその作業が進行中であることを知っているので、それを修正する時間はまだあります。

レンダリングAPIでのMapの使用。 https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L350
私がコメントしたように、マップの適切な使用法はなく、マップが存在する理由もありません。 そのような場合はハッシュマップにする必要があります。
配列などだけでなく、リンクリストの乱用。
https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L680
幸いなことに、これは高速ループではない可能性がありますが、それでも、使用すべきでない場所でリストを使用する例です。

レンダリングAPIでPoolVectorとVectorを使用します。 https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L747
レンダリングAPIの抽象化の一部として、これら2つの欠陥のある構造を使用する本当の理由はありません。 それらを使用することにより、ユーザーは他のデータ構造を使用する代わりに、欠点を伴ってこれら2を使用することを余儀なくされます。 これらの場合はポインタ+サイズを使用し、必要に応じてベクトルを受け取る関数のバージョンを使用することをお勧めします。

このAPIがユーザーに害を及ぼす実際の例は、頂点バッファーの作成関数です。 GLTF形式では、頂点バッファーはバイナリファイルにパックされます。 このAPIを使用すると、ユーザーはGLTFバイナリバッファーをメモリにロードし、各バッファーのデータをコピーしてこの構造を作成してから、APIを使用する必要があります。
APIがポインタ+サイズ、またはSpan <>構造体を使用した場合、ユーザーは変換を実行せずに、ロードされたバイナリバッファからAPIに頂点データを直接ロードできます。

これは、ボクセルエンジンのように、手続き型頂点データを扱う人々にとって特に重要です。 このAPIを使用すると、開発者は、開発者が使用する内部構造から直接頂点データをロードするのではなく、頂点データにVectorを使用する必要があり、パフォーマンスに多大なコストがかかるか、データをVectorにコピーする必要があります。

このトピックについてもっと知りたい場合、私が知っている最高の話はCppConからのこれです。 https://www.youtube.com/watch?v=fHNmRkzxHWs
他の素晴らしい講演はこれです： https ：

Godotにはパフォーマンスの大きな問題があります... godotチームへの良いアドバイスになるでしょう、それを考慮してください！

貢献したり助けたりする正しい方法ではないと思うので、このスレッドを閉じます。

@ vblanco20-1繰り返しになりますが、あなたが善意を持っていることを本当に感謝していますが、エンジンの内部動作やその背後にある哲学を理解していません。 あなたのコメントのほとんどは、それらがどのように使用されているか、それらがパフォーマンスにとってどれほど重要であるか、またはそれらの優先順位が一般的に何であるかを本当に理解していないことに向けられています。

あなたの口調も不必要に攻撃的です。 何がわからないのか、なぜ何かが特定の方法で行われるのかを尋ねる代わりに、あなたはただ傲慢になります。 これは、このコミュニティにとって正しい態度ではありません。

最適化に関してあなたが言及していることのほとんどは、Godot 4.0で最適化を計画したアイテムの量のごくわずかな表面にすぎません（私のリストにはもっとたくさんのものがあります）。 これは数ヶ月前から何度か書き直されるだろうと私はすでに言いました。 私を信じないのなら大丈夫ですが、これで自分の時間を無駄にし、明白な理由もなく多くの人を混乱させているように感じます。

仕事が終わったら、フィードバックを歓迎しますが、今しているのは死んだ馬を倒すことだけなので、しばらく冷やしてください。

繰り返しになりますが、Godot 4.0のアルファ版が公開されたら（できれば今年の終わりまでに）、すべての新しいコードのプロファイルを作成し、それをさらに最適化する方法についてフィードバックを提供してください。 私たちは皆、恩恵を受けると確信しています。 今のところ、既存のコードは4.0で廃止され、3.xブランチでは何もマージされないため、ここで他のことを議論する意味はあまりありません。この時点では、最適化よりも安定性が重要です。

多くの人が技術的な詳細に興味があるかもしれないので：

• すべての空間インデックスコード（vblancoが書き直したもの）は、複数のスレッドでカリングするための線形アルゴリズムに置き換えられ、階層的オクルージョンカリングのためのオクツリーとオーバーラップチェックのためのSAPが組み合わされます。あらゆる種類のゲームでのパフォーマンス。 これらの構造の割り当ては、新しいRID_Allocator（O（1））と同じように行われます。 以前に@ vblanco20-1とこれについて話し合い、彼のアプローチはすべてのタイプのゲームにうまく対応できるわけではないことを説明しました。これは、ユーザーが微調整するためにある程度の専門知識を必要とするためです。 また、オクルージョンカリングを追加するための良いアプローチでもありませんでした。
• リストは断片化のリスクがゼロで小さな時間割り当てを行うため、リストを使用できる場合は配列を使用しません。 場合によっては、常に拡大し、縮小しない（RID_Allocatorや2DエンジンのVulkanブランチの新しいCanvasItemのように、アイテムを再描画できるようになった）セクション化された配列（ページに揃えられるため、断片化が0になる）を割り当てることを好みます。多くのコマンドを非常に効率的に使用します）が、これにはパフォーマンス上の理由が必要です。 Godotでリストを使用する場合、パフォーマンスよりも小さな割り当てが優先されるためです（実際、リストを使用すると、コードの意図が他の人にわかりやすくなります）。
• PoolVectorは、連続するメモリページを使用した非常に大規模な割り当てを対象としています。 Godot 2.1までは、事前に割り当てられたメモリプールを使用していましたが、これは3.xで削除され、現在の動作は間違っています。 4.0では、仮想メモリに置き換えられます。これは、やるべきことのリストに含まれています。
• GodotのVector <>をstd :: vectorと比較することは、ユースケースが異なるため意味がありません。 主にデータを渡すために使用し、高速アクセスのためにロックします（ptr（）またはptrw（）メソッドを介して）。 std :: vectorを使用した場合、不要なコピーが原因でGodotの速度が大幅に低下します。 また、さまざまな用途でコピーオンライトメカニズムを活用しています。
• Map <>は、大量の要素に対して単純で使いやすく、断片化を引き起こす急成長/震えについて心配する必要はありません。 パフォーマンスが必要な場合は、代わりにHashMapが使用されます（それは本当ですが、おそらくOAHashMapをもっと使用する必要がありますが、それは新しすぎて、それを行う時間がありませんでした）。 一般的な哲学として、パフォーマンスが優先されない場合、オペレーティングシステムのメモリアロケータが小さな穴を見つけてそれらを入れるのが簡単であるため、小さな割り当てが常に大きな割り当てよりも優先されます（これはほとんど設計されています） 、効果的に少ないヒープを消費します。

繰り返しになりますが、不正になって文句を言う代わりに、いつでも計画や設計について質問することができます。これはプロジェクトを支援する最善の方法ではありません。

また、このスレッドを読んでいる多くの人が、なぜ空間インデクサーが最初から遅いのか疑問に思っていると思います。 その理由は、おそらくあなたはGodotに不慣れなのかもしれませんが、ごく最近まで3Dエンジンは10年以上前のものであり、非常に時代遅れでした。 OpenGL ES 3.0でそれを最新化するための作業が行われましたが、OpenGLで見つかった問題と、Vulkanで非推奨になった（そしてAppleがそれを放棄した）という事実のために、やめなければなりませんでした。

これに加えて、Godotはそれほど昔のPSPのようなデバイスで実行されていました（エンジンとゲームの両方で使用できるメモリは24 MBしかないため、多くのコアコードはメモリ割り当てに関して非常に保守的です）。 現在ハードウェアが大きく異なっているため、これはより最適でより多くのメモリを使用するコードに変更されていますが、この作業を行う必要がない場合は無意味であり、パフォーマンスが向上する多くの場所で使用されるリストが表示されるのは問題ありません。問題にならない。

また、GodotをC ++ 11（インラインアトミックのサポートがはるかに優れているがサポートされていない）に移行できるようになるまで、実行したい多くの最適化（ミューテックスコードの多くをアトミックに移動してパフォーマンスを向上させる）を保留する必要がありました。名前空間全体を汚染するwindowsヘッダーを含める必要があります）。これは、安定したブランチでは実行できませんでした。 C ++ 11への移行は、Godot 3.2が分岐して機能がフリーズした後に行われます。そうしないと、Vulkanマスターブランチの同期を維持するのが非常に困難になります。 現在、Vulkan自体に焦点が当てられているため、急いでいることはあまりありません。

申し訳ありませんが、時間がかかりますが、急ぐよりもきちんとやっていることをお勧めします。 それは長期的にはより良い結果をもたらします。 現在、すべてのパフォーマンスの最適化に取り組んでおり、すぐに準備が整うはずです（Vulkanブランチをテストした場合、2Dエンジンは以前よりもはるかに高速です）。

こんにちはreduz、
私はあなたのポイントが有効であるとほとんど見ていますが、私が同意しない2つについてコメントしたいと思います。

• リストは断片化のリスクがゼロで小さな時間割り当てを行うため、リストを使用できる場合は配列を使用しません。 場合によっては、常に拡大し、縮小しない（RID_Allocatorや2DエンジンのVulkanブランチの新しいCanvasItemのように、アイテムを再描画できるようになった）セクション化された配列（ページに揃えられるため、断片化が0になる）を割り当てることを好みます。多くのコマンドを非常に効率的に使用します）が、これにはパフォーマンス上の理由が必要です。 Godotでリストを使用する場合、パフォーマンスよりも小さな割り当てが優先されるためです（実際、リストを使用すると、コードの意図が他の人にわかりやすくなります）。

リンクリストが、指数関数的に増加する動的配列よりも、速度やメモリ効率など、全体的なパフォーマンスが向上するかどうかは非常に疑わしいです。 後者は実際に使用するスペースの最大2倍を占めることが保証されていますが、 List<some pointer>は正確に3倍のストレージ（実際のコンテンツ、次のポインター、前のポインター）を使用します。 セクション化された配列の場合、状況はさらに良く見えます。

適切にラップされている場合（そして、godotコードについてすでに見たものからわかる限り）、プログラマーにはほとんど同じように見えるので、「それらの[リスト]コードの意図をより明確にします。」

私見、リストは次の2つの条件で正確に有効です。

• コンテナの中央で要素を頻繁に消去/挿入する必要があります
• または、要素の一定時間（および償却された一定時間だけでなく）の挿入/削除が必要です。 つまり、時間のかかるメモリの割り当てが不可能なリアルタイムのコンテキストでは、問題ありません。

• Map <>は、大量の要素に対して単純で使いやすく、断片化を引き起こす急成長/震えについて心配する必要はありません。 パフォーマンスが必要な場合は、代わりにHashMapが使用されます（それは本当ですが、おそらくOAHashMapをもっと使用する必要がありますが、それは新しすぎて、それを行う時間がありませんでした）。 一般的な哲学として、パフォーマンスが優先されない場合、オペレーティングシステムのメモリアロケータが小さな穴を見つけてそれらを入れるのが簡単であるため、小さな割り当てが常に大きな割り当てよりも優先されます（これはほとんど設計されています） 、効果的に少ないヒープを消費します。

libc-allocatorは通常非常にスマートであり、OAHashMap（またはstd :: unordered_map）はストレージを時々再割り当てするため（一定時間で償却）、アロケーターは通常、メモリブロックをコンパクトに保つ​​ことができます。 OAHashMapは、Mapのような単純なバイナリツリーマップよりも多くのヒープを効果的に消費しないと確信しています。 代わりに、Mapの各要素の巨大なポインターオーバーヘッドは、実際にはOAHashmap（またはstd :: unordered_map）のヒープフラグメンテーションよりも多くのメモリを消費すると確信しています。

結局のところ、これらの種類の議論を整理するための最良の方法は、それをベンチマークすることだと思います。 確かに、これはGodot 4.0にとってはるかに有用です。なぜなら、あなたが言ったように、そこでは多くのパフォーマンスの最適化が行われ、とにかく4.0で完全に書き直される可能性のあるコードパスを改善することはあまり使用されないからです。

しかし@reduz、あなたは@ vblanco20-1が（3.1、多分今でも）を示唆していること、すべてのこれらの変更をベンチマークをどう思いますか。 @ vblanco20-1（または他の誰か）がそのようなベンチマークスイートの作成に時間を費やし、vblancoの変更に対するGodot3.1のパフォーマンス（速度と「断片化を考慮したヒープ消費」の両方の観点から）を評価する意思がある場合はどうでしょうか。 実際の4.0の変更について貴重なヒントが得られる可能性があります。

そのような方法論は、あなたの「急ぐのではなく、適切に行われる」ことによく合っていると思います。

@ vblanco20-1：実際、私はあなたの仕事に感謝します。 あなたの変更が実際のパフォーマンスの改善であるかどうかを実際に測定できるように、そのようなベンチマークを作成するように動機付けられますか？ とても興味があります。

@Windfischいくつかのことを読み間違えたり誤解したりしたので、上記の私の投稿を

• リストは、あなたが説明するユースケースに正確に使用されており、パフォーマンスが優れているとは決して主張していません。 それらは小さな割り当てで構成されているという理由だけで、ヒープを再利用するために配列よりも効率的です。 スケールで（意図されたユースケースでそれらを頻繁に使用する場合）、これは本当に違いを生みます。 パフォーマンスが必要な場合は、より高速で、よりパックされた、またはより優れたキャッシュコヒーレンシを備えた他のコンテナーがすでに使用されています。 良くも悪くも、ビクターは主に古いエンジン領域の1つに焦点を合わせました（実際には最も古いものではないにしても）。これは、PSP用のゲームを公開するために使用される社内エンジンであったため最適化されていませんでした。 これは長い間書き直しが保留されていましたが、他の優先事項がありました。 彼の主な最適化は、最近追加したCPUベースのボクセルコーントレースでした。正直なところ、3.0リリースの近くで急いでいたため、それで悪い仕事をしましたが、これに対する適切な修正は完全に異なるアルゴリズムであり、彼がしたように並列処理を追加します。
• @ vblanco20-1の作業のパフォーマンスについては決して議論しませんでしたし、率直に言って気にしません（したがって、ベンチマークを行うのに時間を無駄にする必要はありません）。 彼の作品をマージしない理由は、1）彼が使用するアルゴリズムは、ゲーム内のオブジェクトの平均サイズに応じて手動で調整する必要があるためです。これは、ほとんどのGodotユーザーが行う必要があります。 私は、微調整を必要とせずに、少し遅くてもスケーリングが優れているアルゴリズムを好む傾向があります。 2）彼が使用するアルゴリズムは、オクルージョンカリングには適していません（階層的な性質があるため、単純なオクトツリーの方が適しています）。 3）彼が使用するアルゴリズムは、ペアリングには適していません（SAPの方が優れていることがよくあります）。 4）彼はC ++ 17と私がサポートしたくないライブラリ、または不要だと思うラムダを使用しています5）私はすでに4.0用にこれを最適化することに取り組んでおり、3.xブランチは安定性を優先しています。できるだけ早く3.2をリリースする予定なので、これは変更されたり、そこで機能したりすることはありません。 既存のコードは遅くなる可能性がありますが、非常に安定しており、テスト済みです。 これがマージされた場合、バグレポートやリグレッションなどが発生します。すでに4.0ブランチで忙しいため、作業したり、Victorを支援したりする時間はありません。 これはすべて上記で説明されているので、投稿をもう一度読むことをお勧めします。

いずれにせよ、私はビクターにインデックスコードをプラグインできると約束したので、最終的にはゲームの種類ごとに異なるアルゴリズムを実装することもできます。

Godotはオープンソースであり、彼のフォークもオープンソースです。 私たちは皆ここでオープンで共有しています。あなたがそれを必要とするならば、あなたが彼の作品を使うのを妨げるものは何もありません。

その最適化はgdscript、レンダリング、または「吃音」の問題に影響を与えないようであり、人々が不平を言うことがあるので（私が含む）、おそらく最適化が人々を幸せにすることを達成すると（私が含む）...必要ありませんルアジット速度..。
「コピーオンライト」での作業は、私のプラグインでの非常に大きなパフォーマンスの最適化でした（スクリプト解析の25秒から7000行のスクリプトのわずか1秒まで）...この種の最適化は私たちがgdscriptで、レンダリングで、吃音の問題を達成する必要があります...それだけです。

ご説明いただきありがとうございます@reduz 。 それは確かにあなたのポイントを以前の投稿よりも明確にしました。

空間インデックスコードがプラグイン可能であるのは良いことです。なぜなら、非常に異なるスケールで多くのオブジェクトを処理するときに、実際に前に足を踏み入れたからです。 4.0を楽しみにしています。

私もそれについて考えていました。空間インデックスの最適化に関するアイデアを共有ドキュメントに入れて、より多くの貢献者がこれについて学び、アイデアを投げたり、実装したりできるようにするのは良い考えかもしれません。 何をする必要があるかについては非常に良い考えがありますが、ここにはさらに最適化を行い、興味深いアルゴリズムを考え出す余地がたくさんあると確信しています。

アルゴリズムが満たさなければならないことがわかっている非常に明確な要件を設定できます（たとえば、世界サイズの平均的な要素に対してユーザーが可能な限り微調整する必要はなく、可能であればスレッドを総当たり攻撃する必要はありません-それらは無料ではありません、他の部分エンジンも物理学やアニメーションのようにそれらを必要とし、モバイルでより多くのバッテリーを消費します-再投影ベースのオクルージョンカリングとの互換性-したがって、何らかの形の階層が必要な場合がありますが、ブルートフォースに対してもテストする必要があります-、スマートであるシャドウバッファの更新について-何も変更されていない場合は更新しない-、方向性シャドウの再投影ベースのオクルージョンカリングなどの最適化を検討します）。 いくつかのベンチマークテストの作成についても説明できます（TPSデモにはオブジェクトやオクルージョンが少ないため、良いベンチマークではないと思います）。 @ vblanco20-1コーディング/言語のスタイルと哲学に従おうと思っているなら、もちろん大歓迎です。

残りのレンダリングコード（RenderingDeviceを使用した実際のレンダリング）は多かれ少なかれ簡単であり、それを行う方法は多くありませんが、インデックス作成は最適化のために解決するためのより興味深い問題のようです。

空間インデックスの参照用の@reduz 。 元のタイルベースのカリングは削除され、このスレッドの約半分でオクトリーに置き換えられました。 私がそこに持ってきた八分木はWIPです（いくつかの再フィット機能がありません）が、結果はプロトタイプにとってかなり良いです。 そのコードはプロトタイプの性質からはそれほど良くないので、この種のoctreeがtps-demoなどの複雑なシーンでどのように機能するかを確認するためにのみ役立ちます。
これは、非現実的なエンジンの八分木がどのように機能するかに触発されていますが、フラットな反復の可能性など、いくつかの変更が加えられています。

主なアイデアは、オクトツリーのリーフのみがオブジェクトを保持し、それらのオブジェクトはサイズ64の配列に保持されるということです（コンパイル時のサイズは異なる場合があります）。 八分木の葉は、65個の要素に「オーバーフロー」したときにのみ分割されます。 オブジェクトを削除するときに、親ノードの各リーフが64サイズの配列に収まる場合は、リーフをマージして親ノードに戻します。これがリーフになります。

そうすることで、八分木が深くなりすぎないため、ノードでのテスト時間を最小限に抑えることができます。

私がやっていたもう1つの良い点は、リーフノードもフラット配列に格納されていることです。これにより、カリングでの並列処理が可能になります。 このようにして、ポイントシャドウのカリングやその他の「小さな」操作を行うときに階層的カリングを使用でき、メインビューにフラットな平行カリングを使用できます。 もちろん、すべてに階層を使用することもできますが、速度が遅くなり、並列化できない可能性があります。

ブロック構造は少しのメモリを浪費しますが、最悪のシナリオでも、ノードが量を下回るとマージされるため、大量のメモリを浪費するとは思いません。 また、ノードとリーフの両方が一定のサイズになる場合は、プールアロケータを使用できます。

また、フォークには複数の八分木があり、いくつかのものを最適化するために使用されます。 たとえば、シャドウキャスターオブジェクト専用のオクトツリーがあります。これにより、シャドウマップをカリングするときに「シャドウをキャストできる」に関連するすべてのロジックをスキップできます。

レンダリングAPIに関するVectorやその他の懸念について、この問題は私が懸念していたことを説明しています。 https://github.com/godotengine/godot/issues/24731

ライブラリとフォークのC ++ 17のものについて..それは不要です。 ライブラリの一部が必要だったため、フォークは多くのライブラリを使いすぎています。 本当に必要で、godotが必要だと思うのは、業界で強力な並列キューだけです。私はそれにムーディキャメルキューを使用しました。

ラムダでは、それらの使用法は主にカリングに使用され、チェックに合格したオブジェクトを出力配列に保存するだけでよいため、大量のメモリを節約するために使用されます。 別の方法は、イテレータオブジェクトを実行することです（これは、Unreal Engineがoctreeで実行することです）が、最終的にはコードが悪くなり、記述が非常に困難になります。

私の意図は「不正になる」ことではなく、「デモ用のフォークを自由に作成できる」という頻繁なコメントに答えることでした。これはまさにiveが行ったことです。 スレッドの最初のメッセージは少し警戒心が強く、あまり正しくありません。 私の唯一の目標は最も人気のあるオープンソースゲームエンジンを支援することなので、失礼に思われた場合は申し訳ありません。

@ vblanco20-1それは素晴らしいですね、そしてあなたが八分木が機能することを言う方法は非常に理にかなっています。 私は正直に並列キューを実装することを気にしません（外部依存関係を必要としないほど単純であり、それを適切に行うにはC ++ 11が必要なので、Vulkanブランチでのみ発生すると思います）。 これをコミットしている場合は、ぜひ見てみたいと思いますので、Vulkanブランチでのインデクサーの書き換えの基礎として使用できます（ほとんどのものを書き換えているだけなので、とにかく書き換える必要があります） ）。 もちろん、実装を支援したい場合（おそらく、新しいAPIでさらに多くのことが行われている場合）、それは大歓迎です。

フラット化された配列を使用した並列バージョンの使用は興味深いですが、それについての私の見解は、オクルージョンカリングにはそれほど有用ではなく、通常のオクトツリーカリングよりもどれだけ改善されているかを測定することは興味深いでしょう。使用されるコアの余分な量を考慮します。 （物理学のように）より効率的に（ブルートフォースが少ない）使用できる複数のスレッドを使用している可能性のある他の多くの領域があることに注意してください。したがって、このアプローチで比較的わずかな改善が得られたとしても、必ずしもそうとは限りません。 CPUの使用から他の領域を飢えさせる可能性があるため、最善の利益になります。 多分それはオプションかもしれません。

また、Bullet 3のdbvtの実装は非常に興味深いものであり、インクリメンタルセルフバランシングと線形割り当てを実行します。これは私がもっと調査したかったことの1つです（このアプローチが独自のエンジンに実装されているのを見たことがあります：P）、アルゴリズム的には、バランス二分木は設計上、八分木よりもはるかに冗長性が低く、ペアリングテストとオクルージョンテストの両方でうまく機能する可能性があるため、適切な有用性を提供することを考えると、プラグ可能なブロードフェーズ/カリングアプローチは実際には良い考えかもしれませんベンチマークシーン。

いずれにせよ、あなたは非常に頭が良く、一緒に取り組むことができれば素晴らしいのですが、私たちが持っている既存のデザイン哲学の多くを理解し、尊重してください。 。 プロジェクトは巨大で、慣性力が大きく、好みのために物事を変えるのは良い考えではありません。 使いやすさと「正しく機能する」ことは常に設計に関するリストの最初であり、コードの単純さと読みやすさは通常、効率よりも優先されます（つまり、領域が重要ではないために効率が目標ではない場合）。 前回話し合ったとき、あなたはほとんどすべてを変えたいと思っていて、推論に耳を傾けたり、実際の問題に焦点を合わせたりしたくありませんでした。それは私たちが通常コミュニティや貢献者と協力する方法ではありません。よく意図されています。

誰がパフォーマンスを必要としますか？ ：ドヤ顔：

パフォーマンスとソースモデルが、Godotを維持している理由です。

編集：申し訳ありませんが、私は少しオフトピックかもしれませんが、オープンソースの利点を明確にしたいと思いました。

@mixedCaseGodotのあらゆる種類のフォークをサポートすることを非常に躊躇します。 フォークと断片化は、多くの場合、オープンソースプロジェクトの死です。

そうは思いません。 オープンソースの性質は、コードを自由に使用および再利用できることです。 したがって、これで一部のプロジェクトは終了するのではなく、ユーザーにとってより多くのオプションが提供されます。
あなたが言うことは独占であり、それはオープンソースを擁護するものではありません。 何かを完全に制御する方が良いとあなたに見せかけるふりをしている会社にだまされてはいけません。 少なくともオープンソースの世界では、それは嘘です。他の誰かがコードを持っている場合、あなたもコードを持っているからです。 彼らがしなければならないことは、コミュニティをどのように扱うか、またはそれで大丈夫になる方法を世話することです。

とにかく、元の開発者はフォークからの改善をマージすることができます。 彼らはいつでもそれを自由に行うことができます。 それがオープンソースの世界のもう一つの性質です。

そして最悪の場合、フォークは元のフォークよりも優れており、多くの貢献者がそこに行きます。 誰も負けず、すべて勝ちました。 ああ、すみません、会社が元の会社に遅れをとっている場合、おそらく彼らは失ったでしょう（または彼らはフォークからの改善をマージすることもできます）。