STL sort und "sweep & prune"
Verfasst: 16.11.2019, 18:40
Abend Zusammen
Ich versuche gerade mein kleines Kollisions-Projekt mit einem Vorselektions-Algorithmus auszustatten.
Eigentlich hatte ich geplant, ein "sweep & prune" Algorithmus dazu einzusetzen. So, wie er mir damals von joeydee netterweise erklärt wurde.
Nur stelle ich jetzt fest, dass dies, in dieser Form wohl nicht möglich sein wird (glaube ich zumindest).
Meine ganze Programm-Struktur beruht nämlich darauf, dass die Spielfiguren Zug-um-Zug bewegt werden.
In einer Momentaufnahme also zu entscheiden, welche Objekte sich untereinander in ihrem Kollisionsbereich schneiden, ist damit eigentlich schon wieder zu viel Information. Ich müsste eher in der Lage sein, möglichst schnell zu entscheiden, welche Spielfiguren für die aktuell behandelte Spielfigur ein "Hindernis" darstellen könnten - um dann möglichst schnell mit dem nächsten Charakter (Spielfigur) weiterzufahren.
Nach längerem Nachdenken bin ich nun auf folgende Idee gekommen: Für die Figuren erstelle ich nicht eine einzelne Liste, sondern mache die Anzahl davon abhängig, wie viele unterschiedliche Charaktergrössen (Charakteren sind immer als Kreise abstrahiert) vorhanden sind. Die Elemente innerhalb der einzelnen Listen werden dann wiederum nach der X- oder (alternativ) Y-Position sortiert.
Folgende Grafik zeigt, was ich meine:
Die zentrale Idee: Kennt man den Radius der Kreise, kann man entscheiden, wo man in der Liste einsteigen - und wieder aussteigen kann, ohne dabei die ganze List durchlaufen zu müssen. Denn noch schneller als ein einfacher Vorabtest, ist es, gar nicht testen zu müssen.
Der "kritische Streifen" ist in der Grafik aufgehellt dargestellt. Liegt ein Kreiszentrum innerhalb dieses Streifens (X-Position), muss also weiter (genauer) geprüft werden. Sobald man aber auf das erste Kreis-Element stösst, dessen X-Wert grösser ist, als der höhere Grenzbereich des Streifens, kann man aus dem Vorselektions-Algorithmus aussteigen.
Extrem cool wäre, wenn man diese Idee so kombinieren könnte, dass es zeitgleich auch einen "kritischen Streifen für die Y-Werte geben würde. Aber eine Liste kann man halt Prinzip bedingt nicht gleichzeitig nach zwei gleichwertigen Kriterien sortieren. Oder seht ihr da vielleicht doch eine Möglichkeit, wie das gehen könnte?
Zudem sind noch weitere Fragen offen:
1) Nachdem eine Figur bewegt wurde, muss sie natürlich in ihrer Liste neu einsortiert werden. Wie schnell dies dann der STL-Algorithmus für ein einzelnes Element ausführen kann, ist für mich nicht abzuschätzen. Vielleicht werden ja sämtliche Zeiteinsparungen gleich wieder aufgefressen - und es wäre möglicherweise schneller gewesen, stattdessen einfach alle Elemente mit einem simplen Vortest abzuklären.
2) Eigentlich müsste man die ganze Idee immer doppelt ausführen - einmal für den kritischen Streifen der X-Werte und einmal für die Y-Werte. Denn wenn man Pech hat, erwischt man die Achse, auf welcher die Verteilung der Figuren bezüglich diesem Selektions-Algorithmus deutlich ungünstiger ist.
Im fertigen Spiel rechne ich eigentlich mit einem Maximum von 1000 Figuren. Oder anders formuliert: Ich wäre sehr glücklich, wenn es mit dieser Anzahl noch gut lauffähig wäre.
Was denkt ihr zu diesem Ansatz?
Gruss, starcow
Ich versuche gerade mein kleines Kollisions-Projekt mit einem Vorselektions-Algorithmus auszustatten.
Eigentlich hatte ich geplant, ein "sweep & prune" Algorithmus dazu einzusetzen. So, wie er mir damals von joeydee netterweise erklärt wurde.
Nur stelle ich jetzt fest, dass dies, in dieser Form wohl nicht möglich sein wird (glaube ich zumindest).
Meine ganze Programm-Struktur beruht nämlich darauf, dass die Spielfiguren Zug-um-Zug bewegt werden.
In einer Momentaufnahme also zu entscheiden, welche Objekte sich untereinander in ihrem Kollisionsbereich schneiden, ist damit eigentlich schon wieder zu viel Information. Ich müsste eher in der Lage sein, möglichst schnell zu entscheiden, welche Spielfiguren für die aktuell behandelte Spielfigur ein "Hindernis" darstellen könnten - um dann möglichst schnell mit dem nächsten Charakter (Spielfigur) weiterzufahren.
Nach längerem Nachdenken bin ich nun auf folgende Idee gekommen: Für die Figuren erstelle ich nicht eine einzelne Liste, sondern mache die Anzahl davon abhängig, wie viele unterschiedliche Charaktergrössen (Charakteren sind immer als Kreise abstrahiert) vorhanden sind. Die Elemente innerhalb der einzelnen Listen werden dann wiederum nach der X- oder (alternativ) Y-Position sortiert.
Folgende Grafik zeigt, was ich meine:
Die zentrale Idee: Kennt man den Radius der Kreise, kann man entscheiden, wo man in der Liste einsteigen - und wieder aussteigen kann, ohne dabei die ganze List durchlaufen zu müssen. Denn noch schneller als ein einfacher Vorabtest, ist es, gar nicht testen zu müssen.
Der "kritische Streifen" ist in der Grafik aufgehellt dargestellt. Liegt ein Kreiszentrum innerhalb dieses Streifens (X-Position), muss also weiter (genauer) geprüft werden. Sobald man aber auf das erste Kreis-Element stösst, dessen X-Wert grösser ist, als der höhere Grenzbereich des Streifens, kann man aus dem Vorselektions-Algorithmus aussteigen.
Extrem cool wäre, wenn man diese Idee so kombinieren könnte, dass es zeitgleich auch einen "kritischen Streifen für die Y-Werte geben würde. Aber eine Liste kann man halt Prinzip bedingt nicht gleichzeitig nach zwei gleichwertigen Kriterien sortieren. Oder seht ihr da vielleicht doch eine Möglichkeit, wie das gehen könnte?
Zudem sind noch weitere Fragen offen:
1) Nachdem eine Figur bewegt wurde, muss sie natürlich in ihrer Liste neu einsortiert werden. Wie schnell dies dann der STL-Algorithmus für ein einzelnes Element ausführen kann, ist für mich nicht abzuschätzen. Vielleicht werden ja sämtliche Zeiteinsparungen gleich wieder aufgefressen - und es wäre möglicherweise schneller gewesen, stattdessen einfach alle Elemente mit einem simplen Vortest abzuklären.
2) Eigentlich müsste man die ganze Idee immer doppelt ausführen - einmal für den kritischen Streifen der X-Werte und einmal für die Y-Werte. Denn wenn man Pech hat, erwischt man die Achse, auf welcher die Verteilung der Figuren bezüglich diesem Selektions-Algorithmus deutlich ungünstiger ist.
Im fertigen Spiel rechne ich eigentlich mit einem Maximum von 1000 Figuren. Oder anders formuliert: Ich wäre sehr glücklich, wenn es mit dieser Anzahl noch gut lauffähig wäre.
Was denkt ihr zu diesem Ansatz?
Gruss, starcow