In nächster Zeit möchte ich immer wieder mal Artikel veröffentlichen, die Designentscheidungen und Hintergrundinformationen zu Techniken aus der starLiGHT.Engine erklären und näher beleuchten. Dies ist sicherlich für den ein oder anderen ganz interessant und vermittelt Hintergrundwissen, nicht nur zur Verwendung mit der Engine.
In diesem, ersten Artikel dieser Art geht es um den PairManager des Kollisionssystems, und hat seinen Ursprung in OPCODE (“Optimized Collision Detection”), welches eine C++-Kollisions-Library ist, die z.B. von ODE, einer Physik-Engine, eingesetzt wird.
Warum benötigen wir nun einen PairManager und wofür werden überhaupt “Paare” benötigt?
Paare werden in der BroadPhase erzeugt und sind potentielle Kollisionen, die in der NarrowPhase genauer geprüft werden sollen. Je nach verwendetem Algorithmus gibt es hier ein paar kleine Herausforderungen, die durch den PairManager elegant gelöst werden. Zum einen ist ein Paar bestehend aus “ObjektA und ObjektB” logisch gesehen gleich mit einem Paar bestehend aus “ObjektB und ObjektA”. Dies klingt logisch, ist es auch und ist trotzdem sehr wichtig. Wenn dieser Fall nicht gesondert behandelt oder geprüft würde, dann würde es in diesem Fall unter Umständen zwei Narrow-Phase Prüfungen geben, die keinen Sinn machen, da auch immer ObjektB mit ObjektA kollidiert, wenn ObjektA mit ObjektB kollidiert ist.
Ein weiterer Punkt ist, dass Algorithmen wie “Sweep and Prune” “zeitlich optimieren” und je nach Implementation nicht alle Paare liefern, sondern nur welche, die sich geändert haben (inkl. neue Paare). Dies bedeutet, dass die Paare, die nach dem ersten Update erzeugt wurden, irgendwo zwischengespeichert werden müssen. Dies erledigt der PairManager.
Weiterhin ist die sogenannte Cache-Coherence bei modernen Prozessoren extrem wichtig. Vereinfacht ausgedrückt: Große Blöcke von vielen kleinen allozierten Objekten können deutlich schneller abgearbeitet werden, als viele kleine, fragmentierte Blöcke. Dies kommt auch zum Tragen, wenn um dies sicherzustellen zusätzlicher Verwaltungsoverhead anfällt. Dies ist ein wenig so wie bei modernen Grafikkarten. Wenn ich 2x 500 Objekte mit zwei Texturen rendere, dann ist dies schneller, wenn ich nach Textur sortiere.
Ein letzter, ebenfalls sehr wichtiger Punkt ist, dass einige BroadPhase-Algorithmen Duplikate liefern können. Ein gutes Beispiel ist hier eine Optimierung des “Sweep and Prune” Algorithmus. Dieser Algorithmus hat Performance-Nachteile, wenn die Objekte eine große Entfernung zueinander haben (auf einzelnen Achsen). Aus diesem Grund kann man mehrere “Sweep and Prune” Felder in einem Grid anordnen und den Algorithmus so einfach auf näher zusammen liegende Objekte anwenden. Das Problem steckt hier im Detail: Befinden sich Objekte genau auf dem Rand eines dieser Felder, so müssen diese in beiden Feldern geprüft werden. Dies ist wichtig, da es ja sein könnte, dass ein Objekt aus dem einen Feld und aus dem anderen Feld mit dem “überlappenden” Objekt kollidieren. Haben wir nun mehrere dieser überlappenden Objekte, die untereinander kollidieren, so werden diese doppelt erkannt. Der PairManager muss also auch noch effektiv solche Duplikate herausfiltern, um die Narrow-Phase nicht unnötig zu belasten.
Ich denke, dass diese Gründe sehr deutlich machen, dass ein PairManager definitiv hilfreich ist.
Nähere Informationen zu Kollisionen finden sich im Artikel Einfache Kollisionsbehandlung (Collision-Response).
Einsortiert unter:Grundlagen, Kollision, XNA
