Gut dass es Du das Problem mit der Rotation erkannt und behoben hast.

Zitat Zitat von robo.fr
http://www.cokeandcode.com/phys2d/
Witzig, man kann das Demo direkt im Browser starten. Allerdings: mir scheinen die Physik Engines sehr auf "Schwerkraft" ausgelegt. In unserer flachen Welt eigentlich nicht vorhanden. Die Frage wäre auch: wie viel Rechenzeit braucht so was?
Hab gerade etwas mit Phys2D rumgespielt, und es sieht so aus, als hätte es alles was wir brauchen, bis auf die Tatsache, dass da nur Polygone verwendet werden können. Wenn man sich auf Roboter mit einem Kreis- oder Rechteckprofil beschränkt, ist die Sache kein Problem. Da die API sehr einfach ist, kann man auch schnell selbst neue Formen erstellen. Ein großer Vorteil wäre halt, dass man sich über die Physik keine sorgen mehr machen muss, weil alle Parameter wie Reibung, Masse usw nur eingestellt werden müssten und die Engine erledigt den Rest.

Die Gravitation kann abgestellt werden.

Die Engine ist sehr schnell, 60fps bei einem Dutzend von bewegbaren und statischen Objekten und ca 28% CPU-Auslastung sind drin.

Zitat Zitat von robo.fr
Die Frage, ob man die Kollisionsdetektion über ein Kreisprofile oder über Farbpixel macht, ist nicht ganz einfach zu entscheiden.
Man könnte ja auch jedes Objekt rot umranden, damit es von einem andern Objekt detektiert werden kann.
Vorteil: Die Objekte können beliebig Formen und Größe annehmen.
Das Problem ist ja nicht die Kollisionserkennung an sich sondern die Berechnung der entsprechenden Bewegungen, die die Kollision zur Folge hat. Vielleicht stelle ich es mir zu kompliziert vor, aber ich wüsste nicht, wie man sowas nur anhand der Überschneidungen der Pixel berechnen kann.

Es gibt eine 2D-Engine für .net, die aus Bildern automatisch Polygone erstellen kann. Möglicherweise können wir etwas änliches in Java erstellen, sprich der Benutzer liefert eine Zeichnung vom Profil des Roboters und der Umwelt und die Software berechnet ihre Formen für die Physik-Engine.