Le problème avec un quad / octet dans les recherches du voisin le plus proche est que l'objet le plus proche peut se trouver juste au-delà de la division entre les nœuds. Pour les collisions, ça va, car si ce n'est pas dans le nœud, on s'en fiche. Mais considérons cet exemple 2D avec un quadtree:
Ici, même si l'élément noir et l'élément vert se trouvent dans le même nœud, l'élément noir est le plus proche de l'élément bleu. La réponse d’ultifinitus ne peut garantir que chez le voisin le plus proche, seul chaque élément de votre arborescence est placé dans le plus petit nœud possible pouvant le contenir, ou dans un nœud unique, ce qui conduit à des quadtrees plus inefficaces. (Notez qu'il existe de nombreuses façons d'implémenter une structure qui pourrait être appelée quad / octree - des implémentations plus strictes pourraient mieux fonctionner dans cette application.)
Une meilleure option serait un kd-tree . Les Kd-trees ont un algorithme de recherche très efficace que vous pouvez implémenter et peuvent contenir un nombre quelconque de dimensions (donc "k").
Une animation fantastique et informative de Wikipedia:
Si je me souviens bien, le plus gros problème lié à l’utilisation des kd-trees est qu’ils sont plus difficiles à insérer / supprimer tout en maintenant l’équilibre. Par conséquent, je recommanderais d'utiliser un arbre kd pour les objets statiques tels que les maisons et les arbres, qui est très équilibré, et un autre qui contient des joueurs et des véhicules, qui doivent être équilibrés régulièrement. Recherchez l'objet statique le plus proche et l'objet mobile le plus proche, puis comparez-les.
Enfin, les kd-trees sont relativement simples à implémenter, et je suis sûr que vous pourrez y trouver une multitude de bibliothèques C ++. D'après ce que je me souviens, les R-arbres sont beaucoup plus compliqués et probablement exagérés si tout ce dont vous avez besoin est une simple recherche du plus proche voisin.