問題タブ [aabb]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - Box (center、halfSize、rotation) から AABB を計算する
Box クラスから AABB (軸に合わせたバウンディング ボックス) を計算したいと考えています。
ボックスクラス:
AABB クラス (ボックス、ローテーションなし):
ああ、いつrotation = (0,0,0), BoundingBox = Box
。しかし、Box のすべてを含む最小の BoundingBox を計算する方法はrotation = (rx,ry,rz)
?
誰かが尋ねた場合: 回転はラジアンで、私はそれを DirectX マトリックス回転で使用します:
c++ - オブジェクトの回転/移動後に AABB を正しく再計算する
ここでこのトピックを見てきましたが、問題を解決するのに実際には役立ちませんでした:(コードを同じように実装しようとしましたが、何かが正しく機能していません。残念ながら、 glLoadIdentity( を使用できません) libqglviewer を使用しているため、何か奇妙な理由で glLoadIdentity() を使用すると、オブジェクト (通常の立方体) が消えます :( したがって、私の回避策は、glPopMatrix と glPushMatrix を使用して、必要なたびにワールド マトリックスをそのまま維持することです。オブジェクトの平行移動/回転 元のマトリックスは保存されており、平行移動/回転が完了したら、もう一度ポップします。
これまでのところうまくいきましたが、バウンディング ボックスの再計算を実装しようとすると、ボックスは立方体と同じ位置から始まりますが、回転を開始するとバウンディング ボックスが「内破」することがあるため、最大値を確認する必要があります。 /min コーナーは立方体自体よりも小さくなりませんが、カメラを回転させるとバウンディング ボックスが片側または反対側に移動します。
私は GLM を使用してモデルをロードしていますが、残念ながらレガシー OpenGL を使用しています。レガシー OGL の仕組みにはある程度精通していますが、バウンディング ボックスが再計算されたときの計算に何か問題があると思います。
このコードは私のレンダー関数にあります:
これは、境界ボックスを設定するための私のコードです:
この最後の部分で、ボックスを再計算します。
私はこの投稿に従おうとしてきました 移動/回転後に軸に沿ったバウンディングボックスを再計算する方法は? しかし、上記のコードで動作させることができませんでした。
私がどこで間違っているのかについての指針は役に立ちます。
webgl - WEBGL Three.js 同じサイズのメッシュのボックスを作成するにはどうすればよいですか?
AABB 衝突したいので同じ大きさの立方体を作って MESH してみました。しかし、それはうまくいきません。
ボックスと同じサイズのメッシュを作成する方法?????
c++ - マップのキーとしての3daabb
マップのキーとして3DAABB(軸整列バウンディングボックス)が必要です。主な懸念事項は、マップ内に何らかの形で互いに交差するAABBキーのペアがあってはならないということです。どの構造/コンテナを使用すべきかわかりません。
助言がありますか?
algorithm - 高速軸に合わせたセル トラバーサル アルゴリズム
- 同じサイズの A、B、C、D の 4 つのセルに分割された、軸に沿った正方形が与えられます。
- 点 s1 から点 s2 に向かう線分があるとします。
トラバーサル順序でソートされたセグメント (存在する場合) によってトラバースされたセルを見つける最速の方法は何ですか?
上記の例では、正しい結果は次のとおりです。
- セグメント 1 : [D]
- セグメント 2 : [A, B]
- セグメント 3 : [C、D、B]
- セグメント 4 : []
- セグメント 5 : [C]
c - 軸に合わせたバウンディング ボックス チェックの最適化
私は現在、ポイントクラウドを多く扱っており、特定の最大距離でポイントをセグメントにクラスター化するセグメンテーションアルゴリズムを実装しました。
それを最適化するために、各セグメントに軸に沿ったバウンディング ボックスを与え、指定されたポイントがセグメントに一致する可能性があるかどうかを確認してから、ポイントを詳しく調べて反復し、距離を計算します (実際には octree を使用しますこれにより、ポイントの大部分を取り除くことができます。)
私は gnuprof を介してプログラムを実行しました。結果は次のとおりです。
ご覧のとおり、計算時間の大部分はotree_node_out_of_bounds
次のように実装されて費やされます。
ここでSEGMENTATION DIST
はコンパイル時定数で、gcc が一定の折り畳みを行えるようにします。_llf
および_urb
は型float[3]
であり、octree の境界ボックスを表します。
したがって、私の質問は基本的に、この関数でいくつかの卑劣な最適化を行うことは可能ですか、またはより一般的に言えば、AABB で境界チェックを行うより効率的な方法があるか、または別の言い方をすれば、高速化できますか? C/gcc マジックを使ってどうにかして比較?
この質問に答えるためにさらに情報が必要な場合は、お知らせください:)
ありがとう、アンディ。
c++ - オーバーヘッドがほとんどない C++ でのレイメッシュ交差または AABB ツリーの実装?
私をお勧めできますか...
- AABB ツリーの実証済みの軽量 C / C++ 実装ですか?
- または、代わりに、別の効率的なデータ構造に加えて、軽量の C / C++ 実装を使用して、多数の三角形と多数の光線が交差する問題を解決しますか?
「大きい数」とは、光線、三角形ともに数百万という意味です。
AABB ツリーが CGAL ライブラリの一部であり、おそらく Bullet のようなゲーム物理ライブラリの一部であることは承知しています。ただし、プロジェクトに膨大な追加ライブラリのオーバーヘッドは必要ありません。理想的には、小さな float 型のテンプレート化されたヘッダーのみの実装を使用したいと思います。また、プロジェクトに簡単に統合できる限り、CPP ファイルの束を使用することもできます。への依存boost
は問題ありません。
はい、グーグルで検索しましたが、成功しませんでした。
私のアプリケーション コンテキストはメッシュ処理であり、レンダリングではありません。簡単に言うと、参照メッシュのトポロジーを 3D スキャンからメッシュのジオメトリに変換しています。頂点から、参照メッシュの法線に沿って 3D スキャンに向かって光線を発射しています。これらの光線とスキャンとの交差を回復する必要があります。
編集
いくつかの回答/コメントは、最近傍データ構造を指していました。最近隣法を使用してレイ メッシュの交差にアプローチするときに発生する問題について、小さな図を作成しました。最近隣法は、多くの場合に機能するヒューリスティックとして使用できますが、AABB ツリーのように実際に問題を体系的に解決できるとは確信していません。
flash - AABBの元の幅と高さを見つける
元の幅と高さが分からない回転した四角形があります。現在の幅と高さは四角形をカプセル化するバウンディング ボックスにすぎないため、実際の幅と高さはどのように確認できますか? ありがとう。
raytracing - How to sort and compare in a Bounding Volume Hierarchy
I'm currently implementing a Bounding Volume Hierarchy for 3D-Triangles only. Sadly all explanations of BVH fall short on the part where you sort your Objects for splitting. For starters I want to aim for a balanced tree and use the median cut. This would require me to sort either the triangles or their bounding boxes(AABB) after a spatial criterion on the split axis of the current node. I'm really unsure if the maximum or minimum extend of a BB or triangle is enough for a proper separation as some triangles can be bigger. I'm also unsure if it's better to compare the bounding box or the triangle.
The second part of the problem is that sorting every step seems to be expensive. Other algorithms in computer-graphics employ presorted lists and then split those according to the splitting criterion. I don't see a way how you could efficiently compare triangles and assure that they belong to a list. Does that mean I have to sort the list every step?
c++ - まばらなAABBツリーはポインタで作られていますか?
物理シミュレーションを行うシーン内のスペースをセグメント化するために、軸に沿ったバウンディング ボックスの octree を使用しています。近距離にある小さなオブジェクトと同様です。実際には、シーンには数キロしか離れていませんが、数キロメートル離れているため、これは多くの空のスペースを意味します。基本的に、バウンディング ボックスを保存するために 2 ギガの RAM を浪費しています。空のセクターの場合。実際に何かを含むセクターにのみメモリを割り当てたい (AABB へのポインターにするため) が、それは octree を再作成するためにフレームごとに数千の割り当てを意味します。プールを使用する場合割り当てによる速度低下に対抗するために、アプリケーションに 2 ギガの RAM を割り当てていることを意味します。これを達成する他の方法はありますか?