Ja.. Es geht um die Kollision von konkaven Polygonen im 2D Raum.
Nun hatte ich mir zuerst überlegt die einzelnen Bewegungsvektoren und / oder Begrenzungslinien der Polys auf Kollision mit einander zu prüfen - allerdings dürfte das zu den unperformantesten Lösungen zählen, die es gibt.

Delfiphan hat den mit den Vorschlag der "Penalty method" gemacht. Dabei bewege ich die Polys entsprechend ihrer derzeitigen Geschwindigkeit und prüfe sie dann erst auf Kollision mit einander und berechne daraus die neuen Kräfte -> Geschwindigkeiten.
Dabei sehe ich 2 Probleme:
a) Kleine, schnelle Objekte können durch andere hindurchfliegen
b) Bei der Ausgabe eine Frames kann es vorkommen, dass sich 2 Polygone noch in einander befinden
Meine (fragwürdigen^^) Lösungen:
a) Ich prüfe nicht nur die Polygone nach dem Bewegen aus Kollision, sondern baue aus der alten Position und der neuen Position ein großes Polygon, welches die ganze "Flugbahn" in diesem Frame abdeckt. (siehe Anhang)
b) Ich schiebe die 2 Polygone nach der Berechnung der Kräfte wieder auseinander.
Allerdings bringen meine Lösungen wieder neue Probleme mit sich:
a) Keine Ahnnung wie ich ein solches Polygon rechnerisch und performant erstelle (Bei der einfachen Transformation geht das ja, aber wie bei der Drehung?).
b) Bewege ich die Polygone im nachhinein wieder aus einander raus, so kann es sein dass sie plötzlich in anderen Polys stecken (Rücken an Rücken sozusagen^^).

So weit meine Gedankengänge - was sagt ihr dazu? Gibt es bessere Möglichkeiten? Ist mein erster Gedanke vlt doch nicht so schlecht? Gibts Tutorials dazu (möglichst deutschsprachige, denn zB das bissl was ich über die "Penalty method" gefunden hab kann ich nur sehr schlecht verstehen, denn es ist auf Englisch und ziemlich praxisfern)

Danke und mfg

*push* Es muss doch jemanden geben der wenigstens ein bissl Ahnung davon hat?

Ho,

Also was auf alle Fälle gehen dürfte ist wenn du deine Konkave in Konvexe Polygone zerlegst.

Ich schreibe grad nen Raytracer ist also fast das selbe ;). Nur das ich halt Strahlen auf Polygone schiese.

und wenn dir die RechenGeschwindigkeit egal ist dann kannst du ja sämmtliche Schnittgeraden ausrechnen und die punkte vergleichen. ( Wat ein Glück das das bei einem Raytracer so ist ;) ).

Ansonsten gibts da noch das Separating Axes ( www.geometrictools.c...OfSeparatingAxes.pdf ) Problem das hat auch schon viel geholfen ( bei denen die es Verstanden haben.

Also egal ist mir die Rechengeschwindikeit nicht^^ Wenn ich dich richtig verstehe soll ich das vom Prinzip her so machen wie Delfiphan vorgeschlagen hat.
Die Kollision soll ich dann mit Zerlegen und SAT lösen - jo das is denke ich recht sinnvoll.

Allerdings bleiben da noch meine 2 oben beschriebenen Probleme, ich möchte mich nicht zu sehr auf diese Lösung festlegen so lange ich noch nicht weiß was ich mit denen anstelle...
Ich werde aber auf jeden Fall in diese Richtung weiterdenken, sie scheiont ja gängig zu sein

Zitat:

Ja.. Es geht um die Kollision von konkaven Polygonen im 2D Raum.

blubplayer.de/tipppunktinpolygonb.html
Die Funktion noch so modifizieren das meherer Punkte auf einmal getest werden können.

Fabian W. hat folgendes geschrieben:

Dabei sehe ich 2 Probleme: a) Kleine, schnelle Objekte können durch andere hindurchfliegen b) Bei der Ausgabe eine Frames kann es vorkommen, dass sich 2 Polygone noch in einander befinden

Wie bereits gesagt ist die Penalty-Methode die wohl einfachste Methode, eine Physikengine zu schreiben.

Auch wenn du die genannten Probleme löst, wirst du weitere bekommen. Kontinuierliche Kollisionserkennung ist nur bedingt eine Lösung und wird in bestimmten Situationen sehr schlecht funktionieren (denk z.B. an ein Stapel Kisten). Wenn du alle Probleme lösen willst, dann musst du etwas tiefer in die mathematische Trickkiste greifen und es bleiben dir nicht viel andere Lösungen als die komplizierten Ansätze in kommerziellen Engines.

Kollisionserkennung würde ich nicht unbedingt selbst von Null programmieren. Ansonsten eignet sich Scanline-Methoden oder noch einfacher du speicherst dir gleich ein "schwarzweiss"-Bitmap, welches jedes Objekt umgibt. Abfragen, ob ein Punkt in einem Objekt ist, gehen dann sehr schnell, dafür hast du nur begrenzte Genauigkeit. Wenn du die Tiefe eines Punktes in einem Objekt für Berechnungen brauchst, kannst du auch ein Graustufenbild nehmen, statt ein Schwarzweissbild.

Hm joah - das hört sich in der Tat besser an als rein mathematische Lösungen.. Kennste da irgendwelche "speziellen" Methoden - also stichwörter reichen