明白なことを述べるリスクがありますが、すでにリポジトリ（ examples / js / Octre.js ）にあるバージョンのthreeocttreeを試しましたか？

three.jsでの空間探索木のハードワイヤード使用には投票しません。 このようなアルゴリズムのオーバーヘッド/複雑さは、多くのアプリケーションでのパフォーマンスの向上を過大にバランスさせます。

実際のレイキャストを行う前に、まずバウンディングボックスと球をチェックします

これは合理的であり、十分なはずです。 ユーザーがより高度なユースケースのコンテキストでより高いパフォーマンスを必要とする場合、ユーザーは前述の例を出発点として使用できます。 八分木は良い選択かもしれません。 しかし、そのアプローチは非常に洗練されているため、インタラクティブな3DアプリケーションでR-Treeソリューションを見たことがありません（アルゴリズムはスペース分割の代わりにデータを実行します）。

こんにちは、返信ありがとうございます。
@Mugen87私は多くのユースケースがそのような高速検索を必要としないことに同意します。 ただし、3Dオブジェクトと対話するためのメカニズムがあり（これが主に使用されていると思います）、最初に境界ボックス/球をチェックすることからのTHREE.Raycasterのステップ（これは完全に合理的であることに同意します） ）実際のレイキャストを行うときの線形時間の努力に対する一定の時間はかなり大きいとしましょう。 1つのグローバル検索ツリーではなく、一種の「ジオメトリ検索ツリー」を想像することができました。 ジオメトリが変更されない限り（多くの場合、ジオメトリの変更よりも変換の可能性がはるかに高くなります）、検索ツリーを更新する必要はありません。

そのため、空間探索木を使用したこのような最適化は、 three.jsのより不可欠な部分になる可能性があると思いました。 しかし、これにより複雑さとオーバーヘッドが増えることも理解しています。

@moraxyサンプルバージョンを見てみましょう。 そのような機能が意味をなすかどうかを知りたかっただけです。

よろしくお願いします

たぶん、もっと単純な探索木をTHREE.BufferGeometryに統合することができます。 たとえば、 computeBoundingBoxを呼び出すと、対応する頂点を参照する一種の読み取り専用検索ツリーを構築することもできます。 THREE.BufferGeometryは

ジオメトリをインスタンス化した後、ジオメトリをあまり操作する必要がない静的オブジェクトに最適です

この検索ツリーは、初期化後に変更する必要はありません。 これにより、更新/削除のオーバーヘッドがいくらか削減されます。 Octreeは良い出発点になります（ BabylonJSの同様の概念）。

ジオメトリをインスタンス化した後、ジオメトリをあまり操作する必要がない静的オブジェクトに最適です

FWIW、私はそれが本当の声明だとは思わない。

THREE.BufferGeometryドキュメントからの@WestLangleyの引用

THREE.BufferGeometryドキュメント

おそらく削除する必要があります。いずれにせよ、これは技術的な説明ではなく、作成後にユーザーがジオメトリを操作するのが難しいことを意味していると思います。

おそらく削除する必要があります

確実に。

PlaneBufferGeometryでレイキャスティングするためのより良いメソッドを実装しました。 farパラメーターを使用して、最初と最後のインデックス位置を見つけます。 インデックス配列はx/yの順序であるため、これはプレーンバッファで機能します。 x / yバウンディングボックスの外に出ると、すべての衝突は遠距離の外にある必要があります。 これをどこかにコミットしたいという願望はありますか？ 現在の実装は私のユースケースに固有ですが、必要に応じて、より一般的なものにしようと思っています。 大きなplaneBuffer（2.5秒から10ms）でレイキャスティングのパフォーマンスを大幅に低下させることができました

@kpetrowthree.jsoctreeの例で十分だと思います。 もちろん、他の人に役立つと思われる場合は、GitHubでコードを自由に共有できます。

過去に、空間インデックスをthreejsに含めることを提案しました。 この方向でいくつかの作業が行われており、既存のoct-treeの例はその1つです。 結局のところ、この機能を3級の第一級市民として持つことに関して、コアコミュニティからの関心が欠如していると思います。

BVHコードをメインのディストリビューションに含めるのに十分な関心と意図がある場合は、プロジェクトにBVHコードを寄付できれば幸いです（例ではありません）。
私のコードは2つの側面に焦点を当てています：

• ダイナミックなシーン
  
  
  
  • 高速挿入
  
  
  • 高速削除
  
  
  • 再取り付け（ノードを再挿入せずに形状を変更する機能）
  
  
• クエリ速度

私には2つの実装があります：

• BinaryBVH
  
  
  
  • ByteBufferを使用した非常にコンパクト
  
  
  • DataViewを介したUintXタイプとFloatXタイプの組み合わせ
  
  
  • シリアル化に最適
  
  
  • lzmaライブラリなどの標準ツールを使用して圧縮できます
  
  
  • 不変
  
  
  • ビルド速度は高度に最適化されています
  
  
  • BufferGeometryでのみ機能します
  
  
  • SAHの最適化
  
  
  • レイクエリ
  
  
• BVH
  
  
  
  • 結果として、オブジェクトツリーはバイナリ実装よりもはるかに大きくなります
  
  
  • 可変
  
  
  • 高速バルクインサート
  
  
  • 高速単一アイテム挿入
  
  
  • 改修
  
  
  • スタック、再帰、およびスタックレストラバーサルの実装（さまざまなパフォーマンス特性）
  
  
  • SAHの最適化
  
  
  • 錐台クエリ
  
  
  • レイクエリ
  
  

個人的には、空間インデックスなしでは生きていけません。それはn ^ 2とlog（n）のパフォーマンスの違いです。 たとえば、私の現在のプロジェクトでは、次の部分が空間インデックスに依存しています。

• 葉システム（木、花、茂みなど）
• すべてのオブジェクトの配置（キャラクターと家）
• ピッキング（マウスクリックなどのインタラクションで使用）

http://server1.lazy-kitty.com/komrade

地形には約1mのポリゴンがあり、何千本もの樹木を配置し、その上でリアルタイムのレイキャストを実行することは、特にローエンドデバイスの場合は簡単です。

レイキャストを最適化するものは何でも見たいです。 複雑さを増やさずに最適化する余地はありますか？ Octreeには、すべての新しいライブラリと、すべての新しい追加や更新などが必​​要です。

私が気づいたことの1つは、ジオメトリがインデックス付きバッファ配列に変換されると、元のジオメトリのプロパティをスマートに使用しなくなることです。 上記のように、planeBufferのジオメトリは、arrayBufferがPlaneGeometryからのものであることを知ることで超最適化できます。 たぶん、MESH.raycast（raycaster、intersects）メソッドをジオメトリタイプに基づくように上書きしますか？

もう1つのアプローチは、Raycasterを個別のプラグインとして使用することです。インタラクティブコントロールとローダーも同様です。 次に、 @Usnulが提案するものと同様のパフォーマンスの高いレイキャスターを追加するのは素晴らしいことです。

プラグ可能なレイキャスターを使用するというアイデアは気に入っていますが、少し混乱していると思います。 私が役立つと思うのは、レイキャスター自体ではなく、空間インデックスです。 空間インデックスでは、次のようなことができます。

• 空間カリング（フラスタムカリングを考えてください）
• 可視性クエリの実行
• パストレーシングレンダラーの構築
• 高速ソート（データの局所性を活用）

現在、three.jsは、これらのうち2つを明示的に（ソートとカリング）、1つを例を介して（レイトレースレンダラー）実行します。

空間インデックスを内部的に維持すると、並べ替えとカリングが高速化され、インデックスの保存に必要な追加のRAMを犠牲にして、より大きなシーンに徐々に多くのメリットがもたらされます。

GPUピッキングだけを使用してみませんか？ いくつかの例があり、実装はかなり簡単です。 公演は昼と夜です。 私たちのユースケースでは、100万を超えるポリゴンのモデルを使用して、モデル上で物事をドラッグしながら、ピッキングが1秒近くから60fpsでリアルタイムで実行されるようになりました。

https://github.com/brianxu/GPUPicker

@hccampos
GPUの選択は、CPUで実行するよりも必ずしも高速ではありません。GPUの場合、必要な精度に比例した解像度でレンダリングする必要があるため、ピクセルの精度が必要な場合は、1：1の画面解像度でレンダリングする必要があります。 これは個別のレンダリングパスであり、オブジェクトを個別の異なる色としてレンダリングしていることに注意してください。 追加のレンダリングパスは、グラフィックメモリの使用量を意味します（通常、遅延パイプラインの場合）。
バイナリ空間分割インデックスを使用すると、ピッキングのlog（n）タイミングプロファイルが得られるため、1,000,000ポリゴンの場合、光線クエリを解決するための約14の操作を確認することになります。 データ構造によっては、数マイクロ秒かかる可能性があり、フレームバジェットに凹みを作り始める前に何千ものクエリが可能になります。

比較してみましょう。たとえば、1mのポリモデルがあり、画面スペースからカメラの方向に沿って直接シーンに光線を投影したいとします（ユースケースを選択）。 バレル解像度の下限、「フルHD」、または1920×1080を使用していると仮定します。RGBのみ（ピクセルあたり24ビット）をレンダリングすると仮定すると、レンダリングには6220800バイト（約6 Mb）またはグラフィックRAMが必要になります。それ。 CPUソリューションを使用する場合、リーフごとに10ポリゴンのAABB BVHを使用するとします。つまり、約200,000ノードが必要です。たとえば、各ノードは座標用に約6 * 8バイト、中間ノードには子ポインター用に2*4バイトが追加されます。リーフノードには、ポリゴンポインタ用に10 * 4バイト、つまり14,400,000バイト（約14Mb）があります。 主な違いは、BVHクエリがGPUの場合と比較して、RAM帯域幅に対する要求がほとんどなく、完全な1mのポリジオメトリをレンダリングする場合と比較して、クエリごとに必要な操作がほんのわずかであるという事実を考えるときに関係します。
2560x1440など、デスクトップでより一般的な解像度を使用すると、最終的に11059200バイトのレンダリングターゲット（11Mb）になります。

グラフィックスRAM帯域幅の予算が大きく、シェーダーコア数がかなり適切な場合は、これがピッキングを行うためのシンプルで簡単な方法です。

@Usnulは絶対ですが、おそらく実装するのが最も簡単なソリューションです。 空間インデックスデータ構造の実装と保守は、おそらくthreejsメンテナにとって重要ではない負担になるでしょう。

そうは言っても、3つの一部として、または個別のnpmパッケージとして、十分にテストされ、維持されている優れた空間インデックスデータ構造が必要です。

使用するジオメトリにこのような空間インデックスを実装することに興味があったので、BufferGeomtryを分割する非常に単純なOctree（作成と検索のみ）を実装しました。 この単純なソリューションで、私は非常に有望な結果を達成しました。約500Kの頂点を持つジオメトリに適用すると、レイキャスト時間が約120ミリ秒から約2.3ミリ秒に短縮されました。 ツリーの構築には現在約500ミリ秒かかりますが、ジオメトリとツリーの作成はアプリケーションの起動時にWebワーカー内で1回だけ行われるため、これはそれほど問題にはなりません。

アルゴリズムはTHREE.BufferGeometryに非常に簡単に統合でき、 THREE.BufferAttributeのdynamicなどのフラグを使用してオンまたはオフに切り替えることができると思います。 このように、BufferGeometryが変更されない場合にのみ使用できます。 残念ながら、 THREE.Meshのraycastメソッドを上書きする必要がありましたが、変更する必要があるのは2行だけでした（Octree検索呼び出しと位置配列の反復）。

とにかく、私のVRアプリケーションでは、マウスクリックで1回だけでなく、レンダリングループ中にオブジェクトとコントローラーの衝突を検出する必要があります。 したがって、現在のソリューションに依存する必要があります。 さらに改善できるか試してみます。

更新レイキャスト時間を測定するのを間違えました。 正しい値は〜2.3msです（〜0.3msではありません）。 それに応じて上記の値を変更しました。

three.js上に構築された最も複雑なアプリケーションでは、高速な空間ルックアップをオプトインする方法が必要だと思います。 たとえば、3Dエディタ。 私はそこにいくつかの実装をいじくり回しましたが、それらはうまく統合されていないか、または特定のバージョンのthree.jsにあまりにも緊密にラップされています。 したがって、誰かが新しいバージョンのthree.jsへのアップグレードパスを壊すことなくそれを行うオプトインの方法を持っているなら、それは素晴らしいことです。

@ matthias-w objモデルのraycasterを試しましたが、コントローラーが何も検出していません。 光線はモデルを通過しています。 その問題をどのように修正したか教えてください

オプションの空間インデックスを持つことについて。 レンダラー自体（カリングなど）がエンジンの不可欠な部分である場合でも、十分に役立つと思います。 関連するディスカッションは次のとおりです。

13909

おい！ 私もこれに少し興味がありましたが（レイキャストのニーズに対して他の解決策を見つけましたが）、実験のいくつかにも貢献したいと思いました。 少しラフですが、数か月前にまとめました。

https://github.com/gkjohnson/threejs-fast-raycast

3つのジオメトリオブジェクトにcomputeBoundsTree関数を追加し、それを使用するためにraycast関数をオーバーライドします（追加の最適化として最初のヒットのみを返します）。 これは、静的で非常に複雑なメッシュにのみ本当に有益であり、シーンを空間的にセグメント化するために何もしません。 これは、80,000の三角形メッシュでのレイキャストパフォーマンスの違いを確認できるデモです。 境界ツリーの計算は少し遅いですが、少しの作業でおそらくもっとスムーズになるでしょう。

これについての私の意見に関しては、私は少し矛盾していると感じています。 これは、THREEの拡張としてかなりうまく構築できるもののように感じます。 そして最終的には、複雑なメッシュやアニメーション化されたメッシュに対して三角形ごとのチェック/衝突/キャストを行うのが最適ではないようです。 単純なケースでは問題ないかもしれませんが、複雑なケースで超高速のレイキャスティング（またはオクルージョンカリング、衝突など）を有効にするには、一般的な平面/立方体/球/カプセル表現または簡略化されたメッシュを使用する方が適しているようです。 もちろん、ピクセルパーフェクトなキャストを探している場合、これはうまく機能しませんが、適切なソリューションは実際にはユースケースによって異なります。

@Usnul @matthias-w octree / BVHの実装はオープンソースですか、それともオンラインで入手できますか？ ぜひ見てみたいです！

@gkjohnson

octree / BVHの実装はオープンソースですか、それともオンラインで入手できますか？ ぜひ見てみたいです！

現在、コードはオープンソースではありません。 あなたが私に個人的に連絡すれば、私はあなたに情報源を提供することができます。

インスタンス化されたメッシュに対して行った例があります。
http://server1.lazy-kitty.com/tests/instanced-foliage-1mil/
上記の例には、次のものが含まれます。

• 新しいインスタンスがツリーに挿入されると、BVHは動的に更新されます
• BVHは、深さ1〜2回転をオンザフライで使用して段階的に最適化されます
• BVHは、レンダリングするインスタンスの錐台クエリでサンプリングされます

私が取り組んでいるゲームで実行しているバージョンがあります：
http://server1.lazy-kitty.com/komrade/

あなたの実装に関して。 私はそれが好きです、私のものは2つの主要な点で異なります：

• 私はパフォーマンスに焦点を当てています
• メモリーフットプリントに焦点を当てています
• 多くの場所でガベージコレクションを避けています

より具体的なポイント：

• また、BVHで何をしたいかに基づいて、分割戦略を透過的に組み合わせて使用​​します
• 私のBVHはAABBベースです
• 改修によるノード境界の更新をサポートします

@Usnulあなたのメールアドレスなどはわかりませんが、空間インデックスソリューションの研究に非常に興味があります。

現在、関連するすべてのシーンオブジェクトをループして、カメラからの距離を計算しています。 最適なアプローチではありません。

@titansoftime
これは
travnick at gmail com
公開されていないことに気づいていませんでした。 私の悪い。

@Usnul私も100万プロジェクトに興味があります。 可能であれば、おそらく1,000万から2,000万です。 私にメールしてください：kaori.nakamoto。 [email protected]

どうもありがとうございました！

http://server1.lazy-kitty.com/tests/instanced-foliage-10mil/
これは1000万のバージョンです

返事が遅くなってごめん。
@gkjohnsonコードはオープンソースではありません。 さらに、あなたのソリューションは私のものよりもはるかに洗練されているように聞こえます。 したがって、私のソリューションから学ぶことはそれほど多くないと思います。

@sid3007あなたの問題を理解しているかどうかわかりません。 私のアプローチを説明することができます。 多分それは役に立ちます。

私のユースケースは非常に単純です。 アプリケーションが起動すると、さまざまなモデルのジオメトリが読み込まれます。 これらのモデルは、ユーザーが変換できます。 形状は変わりません。 ジオメトリの変形はありません。 したがって、アプリケーションの起動時にすべてのジオメトリに対して1回作成される非常に単純なOctreeを実装しました。 八分木は動的ではありません。 これは、指定されたジオメトリのバウンディングボックスと頂点の配列に基づいて構築されます。 構築中に、オクタントに頂点が含まれているか、オクタントのBox3バウンディングボックスが三角形（インデックス付けされていないジオメトリの3つの連続する頂点）と交差しているかどうかをチェックし、頂点配列参照をoctreeのノードに格納します。
メッシュごとの八分木は、メッシュと一緒に保存されます。 また、実際にoctree交差テストメソッドを呼び出すために、メッシュインスタンスのTHREE.Meshのraycastメソッド（1行のみ）を上書きします。 これにより、メッシュのデフォルトの交差ロジックで使用できるジオメトリ面の頂点インデックスが返されます。
私は1つの最適化を行いました。octreeの作成は、WebWorker（実際にはワーカーのプール）内でアプリの起動時に1回行われます。 その理由は、大きなジオメトリのツリー作成にはかなりの時間（数秒）がかかるためです。 これによりブラウザのUIがブロックされるため、別のスレッドに移動しました。
私のアプローチが明確になることを願っています。

@ matthias-wすばらしい仕事のようですね！ 私は独立してほぼ同じことをしましたが、パフォーマンスの大幅な向上は達成できなかったと思います。 https://discourse.threejs.org/t/octree-injection-for-faster-raytracing/8291/2 （オブジェクト指向のoctree実装、およびMesh.raycastへのあまりクリーンでない変更）

Octreeの実装をオープンソース化/貢献して、他の人によるより多くの実験を可能にすることは可能でしょうか？

@EliasHasleありがとうございます。 実は、最初の対策を間違えたので、パフォーマンスの向上はそれほど良くありません。 値を修正しました（上記の私の投稿を参照）。 Octreeの対数探索の複雑さに関しては、タイミングがより理にかなっています。 残念ながら、現時点ではコードを利用できるようにすることはできませんが、おそらく今年の後半になります。 とにかく、私の実装は非常に簡単です（そしてそれほどクリーンなところではありません;））。 したがって、特別な洞察はないと思います。

@matthias-w 500k頂点メッシュでのレイキャストの2.3ミリ秒対120ミリ秒は、まだ大幅な改善であると思います。たとえば、ゲームで発射された弾丸のリアルタイム解決が可能になります（計算のかなりの部分で）フレームあたりの予算）。

レイトレーシングも試しましたか？

実装はJSオブジェクトのツリーに基づいていますか？ リテラルオブジェクトまたはプロトタイプのインスタンス？ 鉱山は完全に自己相似であるため、すべてのノードはメソッドとすべてを備えた八分木です。

@EliasHasle

静的ジオメトリに対するレイキャスティングに興味がある場合、私や他の人は、BVHを使用して三角形にインデックスを付け、静的な複雑なジオメトリに対する交差検出だけでなく、高性能のレイキャスティングを可能にする3メッシュbvhに多大な努力を払っています。 ツリー構築プロセスはより複雑であるため、少し時間がかかりますが、数十万の三角形を持つジオメトリに対してレイキャストする場合、1ミリ秒未満、多くの場合0.1ミリ秒未満のレイキャストが必要になります。

ビルド時間はいくつかの異なる方法で改善できますが、それで私がやりたかったことには十分でした-しかし、それを改善することはリストにあります。

動的なシーンベースの八分木を構築して、メッシュの多いシーンのレイキャスティングと衝突検出を改善したいと思いますが、私自身は良いユースケースを持っていませんでした。 多分いつか！

@EliasHasle私の実装はJSクラスオブジェクトのツリーです（私はES6クラス、つまりプロトタイプインスタンスを使用しています）。 基本的に、ノードは私の実装ではツリーです。 ただし、ルートノードを保持し、ツリーを構築および検索（およびデバッグと視覚化）するためのメソッドを提供する追加のOctreeクラスがあります。

ツリーノードの最大レベルとリーフノードあたりの頂点の最大数の値については、あまり実験しませんでした。 たぶんもっと良い組み合わせがあります。
また、交差テストを高速化するために、バウンディングボリューム階層を使用します。 そこで、メッシュジオメトリの八分木を実際にチェックする前に、メッシュのバウンディング球とバウンディングボックスをテストします。

衝突検出アプローチの非常に優れたコレクションである本をお勧めします：C。Ericson、Real-Time Collision Detection、CRC Press、2004

@gkjohnsonよさそうだ！ パフォーマンスは印象的です。 どんなBVHを使っていますか？

@ matthias-wありがとう！

いくつかの分割戦略オプションがありますが、最も長い側の中央でBVHノードを分割すると、ツリーが最も速く構築されます。 三角形は境界の中心に基づいて辺に分割され、ツリーノードは子三角形を完全に含むように拡張されます（したがって、ツリーノードのオーバーラップがわずかにあります）。

@gkjohnsonでは、BVHの実装は、ボックスの形状に依存する軸の選択を伴う一種の不均衡なKdツリーです。 もしそうなら、私はルートBBが立方体から遠すぎる場合にそのようなことをして、条件付き分割の後に八分木を使用することを考えていました。 これはおそらく、 @ Usnulのマップワールドなど、最初の分割が2つの「マップ」次元で行われ、その後の分割が3Dで進行する場合に適しています。 ルートBBを同じ中心を持つ境界キューブに拡張し、その後、八分木分割を使用するという私の解決策よりもはるかに優れた解決策だと思います。

PlaneBufferGeometryでレイキャスティングするためのより良いメソッドを実装しました。

@kpetrow PlaneBufferGeometryでレイキャストを最適化すると、頂点の位置が変更されないという仮定は、線形探索が不十分な高解像度のジオメトリでは有効でない可能性が非常に高くなります。 私の知る限り、高解像度のPlaneBufferGeometryの主な用途は、地形を維持しながら、頂点を移動して形状を変更することです。たとえば、地形を構築するためです。

＃13909を支持して閉会。