Ich habe eine funktionierende QuadTree implementiert. Er unterteilt den 2-d-Raum, um Objekte aufzunehmen, die durch ihre Begrenzungsbox (x, y, Breite, Höhe) auf der kleinstmöglichen Quadrate (bis zu einer minimalen Fläche) gekennzeichnet sind.QuadTrees - wie zu aktualisieren, wenn interne Elemente in Bewegung sind
Mein Code basiert auf dieser Implementierung (Mine in Lua ist anstelle von C#): http://www.codeproject.com/KB/recipes/QuadTree.aspx
Ich habe in der Lage erfolgreich zu Einfügungen und Löschungen zu implementieren. Ich habe jetzt meine Aufmerksamkeit auf die Funktion update() gerichtet, da sich Position und Abmessungen meiner Objekte im Laufe der Zeit ändern.
Meine erste Implementierung funktioniert, aber es ist ziemlich naiv:
function QuadTree:update(item)
self:remove(item)
return self.root:insert(item)
end
Yup, ich im Grunde jedes Element entfernen und wieder einsetzen, jedesmal wenn sie bewegen.
Das funktioniert, aber ich möchte es ein bisschen mehr optimieren; Schließlich bleiben bewegliche Objekte immer noch auf demselben QuadTree-Knoten.
Gibt es einen Standard-Weg, um mit dieser Art von Update umzugehen?
Falls es hilft, ist mein Code hier: https://github.com/kikito/middleclass-ai/blob/master/QuadTree.lua
Ich bin nicht für jemanden zu implementieren es für mich suchen; Hinweise auf eine bestehende Arbeitsimplementierung (auch in anderen Sprachen) wären ausreichend.
Dank für die Beantwortung. Die Geometrie wird außerhalb des Quadtree aktualisiert - die Elemente selbst sind dafür verantwortlich. Das Problem mit Ihrem Beispiel ist oldNode: contains() - selbst wenn es das Element enthält, könnte es sein, dass der neue Knoten einer von oldNodes Kindern ist; zum Beispiel, wenn der Artikel kleiner ist. Ich habe Schwierigkeiten, das zu modellieren. – kikito
Das ist ein guter Punkt, den ich nicht klar gemacht habe: contains, remove und insert können alle nicht-rekursive Implementierungen sein, weil der Knoten, an dem sie arbeiten, der richtige ist, dh sie arbeiten an einem Knoten, nicht an einem Baum ist keine eindeutige Knotenklasse.findNode muss rekursiv auf einem Baum arbeiten, ähnlich wie insert, aber ohne das eigentliche Einfügen. – richj
In zweiter Linie wäre es besser, wenn findNode einen Knoten, der voll ist, nicht aufteilen würde, weil nicht auf alle findNode-Aufrufe ein Insert folgt. Ich habe den Pseudocode aktualisiert, damit newNode.insert (item) einen Kindknoten von newNode zurückgibt. – richj