タグ付けされた質問 「space-partitioning」

Minecraftの素晴らしい大きな世界は、クアッドコアと肉付きのグラフィックカードを使用しても、ナビゲートが非常に遅いことがわかりました。 Minecraftの遅さは次の原因によるものと思われます。 Java。空間分割とメモリ管理がネイティブC ++で高速であるため。 弱い世界分割。 私は両方の仮定で間違っている可能性があります。しかし、これは大きなボクセルの世界を管理する最良の方法について考えさせられました。それは、ブロックは、世界の任意の部分に存在することができる真の3D世界は、であるように、それは大きな3Dアレイ基本的には[x][y][z]世界の各ブロックタイプを有する（すなわちBlockType.Empty = 0、BlockType.Dirt = 1等） このような世界をうまく機能させるには、次のことが必要だと思います。 さまざまなツリー（oct / kd / bsp）を使用して、すべてのキューブを分割します。三角形ごとではなくキューブごとにパーティション分割できるため、oct / kdの方が適しているようです。 ユーザーに近いブロックが背後のブロックを難読化し、それらをレンダリングすることを無意味にする可能性があるため、いくつかのアルゴリズムを使用して、現在どのブロックが見えるかを判断します。 ブロックオブジェクト自体を軽量にしておくと、ツリーにすばやく追加したり削除したりできます。 これに対する正しい答えはないと思いますが、このテーマに関する人々の意見を見てみたいと思います。 大きなボクセルベースの世界でパフォーマンスをどのように改善しますか？

76 procedural-generation  optimization  terrain  voxels  space-partitioning 

さまざまな形と色の長方形のグリッドがあり、同じ色のレイアウトを表す長方形の数を減らしたい（最適に近いほど良い、最適である必要はない）とします。 上の画像は非常に単純化されたケースであり、長方形間の空白は視覚化のみを目的としています-実際には密に詰め込まれています。 これを行うのに役立つアプローチまたはアルゴリズム名（Googleに満足）とは何ですか？

13 algorithm  geometry  space-partitioning 

KDツリーを実装する方法を見つけようとしています。 エリクソンによる「リアルタイム衝突検出」の322ページ リンクをクリックしたときにGoogleブックのプレビューで表示できない場合に備えて、テキストセクションを以下に示します テキストセクション 関連セクション： 光線または有向線分とkdツリーの交差の背後にある基本的な考え方は簡単です。線はノードの分割平面と交差し、交差のt値が計算されます。tが線の間隔（0 <= t <= tmax）内にある場合、線は平面にまたがり、ツリーの両方の子が再帰的に下降します。そうでない場合、セグメントの原点を含む側のみが再帰的にアクセスされます。 だからここに私が持っているものがあります：（レタリングが表示されない場合、新しいタブで画像を開きます） 論理ツリー オレンジ色の光線が3Dシーンを通過しています。xは平面との交差を表します。左から、光線が当たります： シーンを囲むキューブの前面、 （1）分割面 （2.2）分割面 シーンを囲むキューブの右側 しかし、上記のEricsonの基本的な説明に素直に従うと、次のようになります。 分割面に対してテストします（1）。光線は分割面（1）に当たるため、分割面（1）の左右の子は次のテストに含まれます。 分割面（2.1）に対してテストします。レイは実際にその平面にぶつかるので（右に向かって）、両方の子が次のレベルのテストに含まれます。（これは直感に反します-最下位ノードだけを後続のテストに含めるべきではありません） オレンジ色の光線がシーンを正しく通過したときに何が起こるかを説明できますか？

12 space-partitioning  kd-tree 

3Dスペースをランダムな軸で整列したボックスの形状に分割する方法が必要です。とりあえず、テストのために2Dスペースを分割しています。私が思いついた最も直接的なアプローチは、サイズ（1、1）の長方形を定義し、既存のすべての長方形をX軸とY軸が交互に並ぶ2つの不均一な長方形に再帰的に分割することでした。 ここでの問題は明白です。このアプローチでは、長いストレッチ線（赤でマーク）が発生します。 私が望むのは、もっと有機的な見た目です（私は例を含めました） 見てください、上から下へ、または左から右への長い直線はありません。 唯一の制約は、サイズの粒度に影響を与えずに、長方形の最小サイズを制限したい場合があることです。つまり、最小の四角形が秒より1平方センチメートル小さい場合、最小の部屋は2平方単位であってはなりません。 したがって、理想的には、アルゴリズムは次の3つの制約すべてを満たす必要があります。 長方形は無限に小さくはありません。 四角形のサイズは、最小の四角形のサイズの離散的な乗算ではありません。つまり、最小の長方形が3平方単位である場合、大きい長方形は6、9、12などの正方形単位に制限されず、代わりに3.2または4.7になります。 アルゴリズムは多項式時間で実行されます（高速で計算する必要があります）。

11 algorithm  procedural-generation  random  space-partitioning 

この質問は少しトリッキーですが、私はそれを明確にするように努めます。 私がオンラインゲーム（MMOスケールではない）を構築しているとしましょう。しかし、それは信頼できるサーバーアプローチで可能な限り多くのプレイヤーをサポートします。AIシミュレーションの敵がたくさんいる本当に大きな世界が欲しいです。 スペースを分割して処理の必要がないものを処理しないことにより、サーバーのCPUを節約するいくつかの戦略を知っています。ロードタイムと小さなトランジションを必要とする地域ですでに世界を分割しています。ローカルで（単独で、または数人の友人と一緒に）プレイするときにゲームプレイの品質を維持することが重要だと思います。プレイヤーが1つまたは2つ以上のリージョンにいるとは思わない。 問題は、リージョンがかなり大きくなり、一度に多くのNPCをシミュレートできることです。プレイヤーの経験に影響を与えずにこれをどのように処理しますか？地域ごとに1つのサーバーなどのアプローチは、この表には含まれていません。 私は主に敵の大群、さらには平和なNPCを保持するためのデータ構造を探しています。質問を完成させるために、車両が存在するため、リージョン内を移動するのがかなり速く、エリアを間引く「タイミング」に影響を与えることに注意してください。

10 multiplayer  performance  data  architecture  space-partitioning 

オブジェクトを移動、描画、衝突させるゲームスペースを作成するときは、（0,0）ポイントまたは（0,0,0）ポイントをスペースの真ん中に置いて、ワールドの境界は（-halfSize、halfSize）ですか、それともスペースの端にある方が良いので、境界は（0、サイズ）ですか？ それぞれの長所と短所は何ですか？それぞれにどのような問題がありますか？それとも本当に重要ではないのですか？ 細かいことのようですが、見落としている可能性のある大きな問題があるかどうかを確認したいと思いました。

9 geometry  coordinates  space-partitioning 

バックグラウンド 私は友達と一緒に、宇宙を舞台にした2Dゲームに取り組んでいます。可能な限り没入型でインタラクティブなものにするために、何千ものオブジェクトが自由に浮遊し、一緒にクラスター化されたり、空のスペースに漂っていたりしたいと思っています。 チャレンジ レンダリングと物理エンジンに負担をかけないようにするには、ある種の空間分割を実装する必要があります。私たちが克服しなければならない2つの課題があります。最初の課題は、すべてが動いているため、データ構造の再構築/更新はフレームごとに実行する必要があるため、非常に安価でなければならないということです。2つ目の課題は、オブジェクトの分散です。前述のように、オブジェクトのクラスターと膨大な空きスペースがあり、さらに悪いことに、スペースの境界はありません。 既存のテクノロジー 私はBSPツリー、クワッドツリー、kdツリー、さらにはRツリーなどの既存の手法を見てきましたが、他のセルに移動した多くのオブジェクトを更新しているため、これらのデータ構造は完全には適合しません比較的高価です。 私が試したこと 私は、クエリに基づいて可能な最小のヒットを返すよりも、迅速な挿入/更新を目的としたデータ構造が必要だと判断しました。その目的のために、セルを暗黙的にしたので、各オブジェクトは、その位置を指定すると、どのセルにあるかを計算できます。次に、HashMapセル座標をArrayList（セルの内容）にマップするを使用します。「空の」セルでメモリが失われることがなく、検査するセルを簡単に計算できるため、これはかなりうまく機能します。ただし、これらすべてのArrayLists（最悪の場合N）を作成するとコストがかかるためHashMap、多くの時間をかけて成長します（ただし、初期容量を大きくすることで多少軽減されます）。 問題 わかりましたので、これは機能しますが、まだそれほど高速ではありません。これで、JAVAコードをマイクロ最適化することができます。ただし、プロファイラーはセルの格納に使用するすべてのオブジェクトの作成にほとんどの時間を費やしていると私に言っているので、あまり期待していません。これを大幅に高速化する他のトリック/アルゴリズムがいくつかあることを願っています。理想的なデータ構造は次のようになります。 最優先事項は、データ構造全体の高速更新/再構築です オブジェクトを同じサイズのビンに細かく分割することはそれほど重要ではありません。更新が少し速いことを意味する場合、いくつかの追加のオブジェクトを描画し、いくつかの追加の衝突チェックを実行できます。 メモリはそれほど重要ではありません（PCゲーム）

8 java  space-partitioning 

大きな非線形レベルをファイルベースのチャンクにオフロードし、それらをオンデマンドでロードすることは意味がありますか？レンダリングのパフォーマンスを向上させるためにレベルチャンキングを実装しましたが、すべてのレベルオブジェクトは引き続きRAMに保持されます。 もしそうなら、どのように私たちは生きている/変化する世界の幻想を維持するのでしょうか？レベルは線形ではなく、むしろそれ自体が世界のようであるので、通過したものが永遠に過ぎ去ったと偽ることはできません。 レベルを十分に複雑にするだけでなく、常にメモリに永続化するのに十分最適化し、完全に離れたポイント（つまり、まったく新しいレベル）にジャンプできるようにするマイクロ/マクロジャンプポイントを実装することをお勧めします。世界の一貫性、そして変化する世界の幻想について。また、これにより、一見非線形の世界でわずかに線形のストーリーをたどることができます。プレイヤーを元の状態に戻す場合は、「遠い」レベルの既存の状態に新しい状態を適用するだけで十分です。

8 optimization  levels  level-of-detail  space-partitioning