Und nochmal Kollision - Ball zu Ball

[Airblader]

Hi,
hab leider wieder ein Kollisionsproblem.
Ich will, dass 2 Bälle kollidieren und dabei realistisch abgeprallt weiterfliegen.

Ich hab nun Code gefunden und versucht für mich umzuformen, Ergebnis:

Delphi-Quellcode:

CollisionVec.X := ((Self.FPosition.X + Self.FRadius div 2) / 2) + ((Other.FPosition.X + Other.FRadius div 2) / 2);
CollisionVec.Y := ((Self.FPosition.Y + Self.FRadius div 2) / 2) + ((Other.FPosition.Y + Other.FRadius div 2) / 2);

Self.FAngle := ArcTan2(CollisionVec.Y - (Self.FPosition.Y + Self.FRadius div 2), (Self.FPosition.X + Self.FRadius div 2) - CollisionVec.X);

Code wird ausgeführt, sofern die Bälle kollidieren.
Momentan fliegen die Bälle bei Kollision aber einfach nurnoch nach Rechts O_o

air

[ichbins]

Wie wär's wenn du auch den neuen Kurs des 2. Ball setzt? :gruebel:

[Airblader]

Zitat:

Zitat von ichbins

Wie wär's wenn du auch den neuen Kurs des 2. Ball setzt? :gruebel:

Da die Prozedur für jeden Ball ausgeführt wird, würde ich den Kurs pro Kreis dann ja 2x ändern -> weniger gut.

Übrigens: 0° in FAngle bedeutet nach rechts ;)

air

[ichbins]

Ich hatte auch mal Probleme mit den Winkelfunktionen. Da kamen dann immer die falschen Werte raus. Vllt. liegt es ja daran. Wie sieht denn der Ursprungscode aus?

[Airblader]

Zitat:

Zitat von ichbins

Ich hatte auch mal Probleme mit den Winkelfunktionen. Da kamen dann immer die falschen Werte raus. Vllt. liegt es ja daran. Wie sieht denn der Ursprungscode aus?

Welcher Ursprungscode :gruebel:

air

[xineohp]

moin,

- hast du an Gradmaß --> Bogenmaß gedacht?
- warum teilst du den Radius immer durch zwei?
- wie willst du eine Kollision simulieren, wenn du nirgends die Geschwindigkeit / den Bewegungsvektor der Kugeln verwendest?

[Luckie]

Zitat:

Zitat von Airblader

Zitat:

Zitat von ichbins

Ich hatte auch mal Probleme mit den Winkelfunktionen. Da kamen dann immer die falschen Werte raus. Vllt. liegt es ja daran. Wie sieht denn der Ursprungscode aus?

Welcher Ursprungscode :gruebel:

Den:

Zitat:

Zitat von Airblader

Hi,
Ich hab nun Code gefunden und versucht für mich umzuformen, Ergebnis:

[Cicaro]

Zitat:

Zitat von Airblader

Hi,
hab leider wieder ein Kollisionsproblem.
Ich will, dass 2 Bälle kollidieren und dabei realistisch abgeprallt weiterfliegen.

So, wie ich dich verstehe, arbeitest du mit normalen Vektoren, oder doch mit Polarkoordinaten ?

Aber zunächst würd' ich mir darüber Gedanken machen, dass die Bälle beim Aufprall Energien (kinetische Energien) austauschen. Es reicht nicht nur die Ausfallswinkel zu bestimmen.

Zitat:

Zitat von Airblader

Momentan fliegen die Bälle bei Kollision aber einfach nurnoch nach Rechts O_o

Das kann daran liegen, dass der ArcTan nur für Winkel zwischen -Pi und Pi definiert ist, wenn ich mich recht ensinne :gruebel: . Da müsstest du eine Fallunterscheidung vornehmen.

[Airblader]

Zitat:

Zitat von xineohp

moin,

- hast du an Gradmaß --> Bogenmaß gedacht?
- warum teilst du den Radius immer durch zwei?
- wie willst du eine Kollision simulieren, wenn du nirgends die Geschwindigkeit / den Bewegungsvektor der Kugeln verwendest?

Also bei der normalen

Wenn ich das noch mit DegToRad umziehe ändert sich garnichts ;)
Der Radius durch 2, weil in dem Beispiel, das ich gefunden hatte, der Mittelpunkt dastehen sollte, und Mittelpunkt ist eben (X + Radius/2 | Y + Radius/2).
Zum 3.: :gruebel: Die Kollision selbst funktioniert ja, nur eben der Abprallwinkel stimmt nicht.

Zu der Sache mit der kinetischen Energie:
Nunja, kommt drauf an wie man das berechnet. Momentan hätte ich einfach dazu tendiert, den Multiplikator für die Geschw. des anderen Balls zu setzn. Also Ball A hat 3, Ball B 5, dann hat danach Ball A eben 5 und Ball B 3.

Ich hatte in der Schule (leider) noch keine Trigo, kommt erst dieses Jahr am Ende, von daher kann ich mich nur an anderen Codes orientieren ;)

Den Thread finde ich übrigens grad leider nimmer :pale:

[Khabarakh]

Zitat:

Zitat von Cicaro

Zitat:

Zitat von Airblader

Momentan fliegen die Bälle bei Kollision aber einfach nurnoch nach Rechts O_o

Das kann daran liegen, dass der ArcTan nur für Winkel zwischen -Pi und Pi definiert ist, wenn ich mich recht ensinne :gruebel: .

Stimmt.

Zitat:

Da müsstest du eine Fallunterscheidung vornehmen.

Auch richtig. Und genau das macht ArcTan2, das im obigen Code verwendet wird :wink: .

@Airblader: Vielleicht solltest du langsam doch ganz auf Vektoren umstellen :wink: .

http://www.tobias-nopper.de/BillardG...physik-de.html

[Airblader]

Ich habe mir gestern schon den Vektorartikel auf wiki angesehen, aber irgendwie werde ich nich schlau draus, was ich groß anders mache.
Kenn mich mit Vektoren halt leider praktisch 0 aus *fg*

air

[Khabarakh]

Zitat:

Zitat von Airblader

Kenn mich mit Vektoren halt leider praktisch 0 aus *fg*

Dann hast du dir das falsche Thema ausgesucht ^^ . Hier wirst du um Vektoren nicht herumkommen, deshalb würde ich die Winkel liegen lassen und direkt mit Vektoren arbeiten. Du siehst ja, was das sonst für ein Chaos wird :stupid: .

[Airblader]

Zitat:

Zitat von Khabarakh

Zitat:

Zitat von Airblader

Kenn mich mit Vektoren halt leider praktisch 0 aus *fg*

Dann hast du dir das falsche Thema ausgesucht ^^ . Hier wirst du um Vektoren nicht herumkommen, deshalb würde ich die Winkel liegen lassen und direkt mit Vektoren arbeiten. Du siehst ja, was das sonst für ein Chaos wird :stupid: .

Naja gut, aber gibts dafür irgendwelche Tutorials? Ich hab den leisen Verdacht wir werden dieses Jahr in Mathe sicher keine Vektoren behandeln :stupid: ;)

air

Edit:
Ok, ich habe nun alles auf Vektoren umgestellt. Allerdings hilft mir das hier nicht viel weiter, denn ich hab in etwa keine Ahnung was das Skalarprodukt u.ä. ist und mein erster Ansatz mit Hilfe von wiki war da nicht arg viel hilfreicher ;)

BigEdit:
Also, nach etwas Hilfe hab ich es nun so:

Delphi-Quellcode:

VL2 := sqrt(VecLength);
SpeedVec.X := (1 / VL2) * DistVec.X; /// Speedvec = normiertes m
SpeedVec.Y := (1 / VL2) * DistVec.Y;

B := Self.FMoveVector.X * SpeedVec.X + Self.FMoveVector.Y * SpeedVec.Y;

VecB.X := B * SpeedVec.X;
VecB.Y := B * SpeedVec.Y;

D := Other.FMoveVector.X * SpeedVec.X + Other.FMoveVector.Y * SpeedVec.Y;

VecD.X := D * SpeedVec.X;
VecD.Y := D * SpeedVec.Y;

VecA.X := Self.FMoveVector.X - VecB.X;
VecA.Y := Self.FMoveVector.Y - VecB.Y;

VecC.X := Other.FMoveVector.X - VecD.X;
VecC.Y := Other.FMoveVector.Y - VecD.Y;

VecK.X := VecB.X + VecD.X;
VecK.Y := VecB.Y + VecD.Y;

Self.FMoveVector.X := VecC.X + VecK.X;
Self.FMoveVector.Y := VecC.Y + VecK.Y;

Dass momentan noch etwas unnötiges berechnet wird, weiß ich, aber so scheinen die vektoren zwar in der richtung zu stimmen, jedoch zu lang zu sein (bälle werdn verdammt schnell).
Ich häng mal noch die Grafik an, die ich von Master of the Wind bekommen habe und nach der ich das gemacht habe.

Edit:
Ok, die Richtung stimmt auch nicht :|

Ganz großes Edit:
Ich glaube nun hab ichs - basierend auf dem Source von BillardGL :) *freu*
Ich werd den Code nochmal etwas sortieren, variablen ändern etc. und ihn dann morgen online stellen ;)

[Master of the Wind]

jo glaub hab den Fehler, du musst:

VecA.X := VecB.X - Self.FMoveVector.X;
VecA.Y := VecB.Y - Self.FMoveVector.Y;

für VecD das selbe, schuldigung hab mich vertan...Jetzt müssten aber die Richtungen stimmen...

achja und du hast das vergessen:

Other.FMoveVector.X := VecA.X + VecK.X;
Other.FMoveVector.Y := VecA.Y + VecK.Y;

[Airblader]

Das Setzen für den anderen Ball hatte ich auch drin, aber änderte nicht wirklich was ;)

Habs ja nun wie gesagt mit Hilfe des BillardGL Source selber hinbekommen, aber trotzdem Danke für die Hilfe ;)

Werde nachher den Code posten.

air
Edit:
So hier isser...hab mich entschlossen, die Variablennamen doch so zu lassen, wie sie in BillardGL auch heißen.

Delphi-Quellcode:

dx, dy, dx2, dy2, richtung, abstand2, skalarp, kraftx, krafty: extended;

...

dx2 := Other.FPosition.X - Self.FPosition.X;
dy2 := Other.FPosition.Y - Self.FPosition.Y;
abstand2 := sqrt(dx2*dx2+dy2*dy2);
dx := dx2 / abstand2;
dy := dy2 / abstand2;

richtung := (Other.FMoveVector.X - Self.FMoveVector.X) * dx2 + (Other.FMoveVector.Y - Self.FMoveVector.Y) * dy2;

if richtung < 0 then
begin
        skalarp := 0.9 * (Self.FMoveVector.X*dx+Self.FMoveVector.Y*dy) - (Other.FMoveVector.X*dx+Other.FMoveVector.Y*dy);
        kraftx := dx * skalarp;
        krafty := dy * skalarp;

        Self.FMoveVector.X := (Self.FMoveVector.X - kraftx) * 1;
        Self.FMoveVector.Y := (Self.FMoveVector.Y - krafty) * 1;

        Other.FMoveVector.X := (Other.FMoveVector.X + kraftx) * 1;
        Other.FMoveVector.Y := (Other.FMoveVector.Y + krafty) * 1;
end;

Bei dem *1 kann man jeweils einen Verlustfaktor angeben.

Nu muss ich das für mich noch umschreiben, dass die Kreise ihre Geschw. behalten und nicht, dass sie immer geändert wird - aber das sollte ich hinbekommen :stupid:

Edit: Oder auch nicht :gruebel: Ich müsste doch eigentlich nur diesen Vektor auf der Mittelpunktlinie (im obigen Bild Vektor b also Beispiel) gleichlang haben wie den Bewegungsvektor des Kreises (also V2), oder?
Und im BillardGL Code wäre das dann wohl skalarp. Soweit zur Theorie...die Praxis hängt bei mir grad etwas *fg*

(Übrigens: Was soll denn das 0.9 als Faktor vor skalarp darstellen? Ein Verlustfaktor kanns eig. nich sein, da der ja später erst dazukommt...)

air

[Master of the Wind]

Also die 0,9 damit wird der Energieverlust beim Stoß eingerechnet...

[Master of the Wind]

Hab den fehler bei mir gefunden *schäm* hehe, ja beim elastischen massegleichen Stoß tauschen sich einfach die Geschwindigkeitsvektoren, das hab ich falsch gemacht. hier die änderung:

VecK.X := VecB.X + VecD.X;
VecK.Y := VecB.Y + VecD.Y;

Self.FMoveVector.X := VecC.X + VecK.X;
Self.FMoveVector.Y := VecC.Y + VecK.Y;

das ist falsch und muss wie folgt sein:

Self.FMoveVector.X := VecC.X + VecB.X;
Self.FMoveVector.Y := VecC.Y + VecB.Y;

Self.FMoveVector.X := VecD.X + VecA.X;
Self.FMoveVector.Y := VecD.Y + VecA.Y;

So gut, habs nachgecodet, und so funktioniert es (zumindest bei mir) hehe...naja...also Frohe Weihnachten euch allen

[Airblader]

Zitat:

Zitat von Master of the Wind

Also die 0,9 damit wird der Energieverlust beim Stoß eingerechnet...

Aber da kommt später ja nochmal ein Verlustfaktor mit rein -> etwas sinnlos ?!

Naja...ich würde eig. nurnoch gern rausfinden, wie ich es anstellen kann, dass sich die Geschw.vektoren eben nicht tauschen *fg* Also wenn sie aufeinanderprallen, soll jeder seine Geschw. behalten.
Ich denke, die Theorie dafür hab ich (siehe Seite 1 unten), aber irgendwie verzweifel ich an der praktischen Seite.

air

[Khabarakh]

Zitat:

Zitat von Airblader

Naja...ich würde eig. nurnoch gern rausfinden, wie ich es anstellen kann, dass sich die Geschw.vektoren eben nicht tauschen *fg* Also wenn sie aufeinanderprallen, soll jeder seine Geschw. behalten

Was gibt das denn für einen Sinn :gruebel: ? Damit sie trotzdem beibehalten werden, kannst du einfach die entstehenden Vektoren jeweils mit dem Quotient aus alter und neuer Vektorlänge multiplizieren.

[Airblader]

Danke, werd ich mal probieren ;)

Der Sinn ist, dass das ganze ein simpler Teilchensimulator werden soll und da lernt man ja, dass Teilchen
beim Aufprall nicht langsamer werden, keine Reibung entsteht etc.

air

Edit: Danke, scheint zu funktionieren :thumb:

[Master of the Wind]

Also ich hab das mal programmiert was du da haben willst..so einen Teilchensimulator. Ich frag mich gerade, wie du das hinbekommen hast, dass das funktioniert, ohne das Stoßgesetz zu beachten. Denn um es wirken zu lassen tauschen sich nunmal die Geschwindigkeiten (actio=reactio). So! Und bei meinem Simulator hab ich lustige Effekte entdeckt. Durch die Ungenauigkeit der Berechnungen, fehlen die Zwischenrechnungen, zum Stoß. Er rechnet quasi mit den Positionen, wenn sich die Kugeln überschneiden, und nicht mit den Positonen, wo sich die Kugeln berühren. Das führt zu Paarbildung, zumindest bei mir. Es bilden sich kurzzeitig paare, aufgrund von wiederholten stößen ineinander, die sich meistens im Kreis drehen. Nach einer gewissen Zeit reicht die neue Geschwindigkeit dann aus, die eine Kugel wieder zu verlassen. Naja ist aber nicht sinn und zweck der sache. Du müsstest anders heran gehen. Etwas komplizierter.

Du musst testen welche Kugeln sich bei der nächsten Rechnung berühren würden. Für diese dann genau den Zeitpunkt und die Koordinaten berechnen lassen, den Stoß berechnen lassen. Ich sehe gewisse Probleme mit der Synchronisierung. Da steckt dann bissl Physik dahinter. du musst halt wissen, wie viel zeit eigentlich zwischen einer Berechnung und der nächsten vergeht, und dementsprechend die obigen Rechnungen ausführen. So das war mein Beitrag. Wenn du willst kann ich dir ja mal mein Programm schicken.

[Airblader]

Jap, bei bestimmten Berechnungen habe ich tatsächlich auf diese Paarbildung.

Ist ein ganz simpler Trick:
Erst in einer Extraschleife die neuen Positionen berechnen und in einer 2. dann erst die ganzen Kollisionen etc.

So können die sich zwar überschneiden, aber die Paarbildung fällt weg, da vor der "Fehlkollisionsberechnung" der Kreis ja wieder entfernt ist.
Schwer zu erklären ;)

Ich kann dir das Projekt ja schicken, wenn du willst. Ist eh nur ein Test gewesen, das eigentliche Programm schreib ich neu :)

air