Lorsque vous rencontrez des problèmes d'indexation spatiale, je recommande en fait de commencer avec un hachage spatial ou mon préféré: la vieille grille simple.
... et comprendre ses faiblesses avant de passer à des structures arborescentes qui permettent des représentations clairsemées.
L'une des faiblesses évidentes est que vous pourriez gaspiller de la mémoire sur un grand nombre de cellules vides (bien qu'une grille décemment implémentée ne devrait pas nécessiter plus de 32 bits par cellule, sauf si vous avez réellement des milliards de nœuds à insérer). Un autre est que si vous avez des éléments de taille moyenne qui sont plus grands que la taille d'une cellule et couvrent souvent, disons, des dizaines de cellules, vous pouvez perdre beaucoup de mémoire en insérant ces éléments de taille moyenne dans beaucoup plus de cellules que l'idéal. De même, lorsque vous effectuez des requêtes spatiales, vous devrez peut-être vérifier plus de cellules, parfois beaucoup plus, que l'idéal.
Mais la seule chose à raffiner avec une grille pour la rendre aussi optimale que possible contre une certaine entrée est cell size
, ce qui ne vous laisse pas trop de choses à penser et à tripoter, et c'est pourquoi c'est ma structure de données préférée. pour des problèmes d'indexation spatiale jusqu'à ce que je trouve des raisons de ne pas l'utiliser. C'est très simple à mettre en œuvre et ne vous oblige pas à jouer avec autre chose qu'une seule entrée d'exécution.
Vous pouvez tirer le meilleur parti d'une ancienne grille simple et j'ai en fait battu beaucoup d'implémentations d'arbres quadruples et kd utilisées dans les logiciels commerciaux en les remplaçant par une ancienne grille simple (bien qu'elles ne soient pas nécessairement les meilleures implémentées) , mais les auteurs ont passé beaucoup plus de temps que les 20 minutes que j'ai passées à concocter une grille). Voici une petite chose rapide que j'ai fouettée pour répondre à une question ailleurs en utilisant une grille de détection de collision (même pas vraiment optimisée, juste quelques heures de travail, et j'ai dû passer la plupart du temps à apprendre comment fonctionne le pathfinding pour répondre à la question et c'était aussi ma première implémentation de détection de collision de ce type):
Une autre faiblesse des grilles (mais ce sont des faiblesses générales pour de nombreuses structures d'indexation spatiale) est que si vous insérez beaucoup d'éléments coïncidents ou se chevauchant, comme de nombreux points avec la même position, ils vont être insérés dans la même cellule exacte (s ) et dégrader les performances lors de la traversée de cette cellule. De même, si vous insérez de nombreux éléments massifs qui sont bien, beaucoup plus grands que la taille des cellules, ils voudront être insérés dans une cargaison de cellules et utiliser beaucoup, beaucoup de mémoire et dégrader le temps requis pour les requêtes spatiales dans tous les domaines. .
Cependant, ces deux problèmes immédiats ci-dessus avec des éléments coïncidents et massifs sont en fait problématiques pour toutes les structures d'indexation spatiale. La vieille grille simple gère en fait ces cas pathologiques un peu mieux que beaucoup d'autres car elle ne veut au moins pas subdiviser les cellules de manière récursive encore et encore.
Lorsque vous commencez avec la grille et que vous vous dirigez vers quelque chose comme un arbre quadruple ou KD, le problème principal que vous souhaitez résoudre est le problème avec les éléments insérés dans trop de cellules, ayant trop de cellules, et / ou devoir vérifier trop de cellules avec ce type de représentation dense.
Mais si vous pensez à un quadruple arbre comme une optimisation sur une grillepour des cas d'utilisation spécifiques, il est alors utile de penser encore à l'idée d'une "taille de cellule minimale", pour limiter la profondeur de la subdivision récursive des nœuds à quatre arbres. Lorsque vous faites cela, le pire des scénarios du quad-arbre se dégradera toujours en une grille dense au niveau des feuilles, seulement moins efficace que la grille, car il faudra du temps logarithmique pour passer de la racine à la cellule de la grille au lieu de à temps constant. Pourtant, penser à cette taille de cellule minimale évitera le scénario de boucle / récursion infinie. Pour les éléments massifs, il existe également des variantes alternatives comme des arbres quadruples lâches qui ne se divisent pas nécessairement également et pourraient avoir des AABB pour les nœuds enfants qui se chevauchent. Les BVH sont également intéressants en tant que structures d'indexation spatiale qui ne subdivisent pas également leurs nœuds. Pour les éléments coïncidents contre les structures arborescentes, l'essentiel est d'imposer simplement une limite à la subdivision (ou, comme d'autres l'ont suggéré, il suffit de les rejeter ou de trouver un moyen de les traiter comme s'ils ne contribuaient pas au nombre unique d'éléments dans une feuille lors de la détermination du moment où la feuille devrait subdiviser). Un arbre Kd peut également être utile si vous prévoyez des entrées avec beaucoup d'éléments coïncidents, car vous n'avez besoin de prendre en compte qu'une seule dimension pour déterminer si un nœud doit être divisé en médiane.