Problem mit dem unelastischem Stoß mehrerer Kugeln
-
Hallo, ich bin's mal wieder und habe nun ein Problem, von dem ich denke, dass es ziemlich schwer ist: Ich schreibe grad ein Simulation für kollidierende Kugeln im 3D-Raum. Die Folgende Darstellung beschreibt mein Problem:
B = Ball
B1.v = 1
B2.v = 0
B3.v = 0Von rechts an zählen...
oo <-o
So wenn nun B1 auf B2 trifft, dann haben bei einem unelastischem Stoß und gleicher Masse die Kugeln B1 und B2 die hälfte der Anfangsgeschwindigkeit.
So nach dem B2 ins rollen gekommen ist, erkennt mein Algorithmus für die Erkennung von Kollisionen eine neue Kollision, undzwar zwischen B2 und B3...So wieder wird die Geschwindigkeit von B2 halbiert, und auf B2 und B3 übertragen. Nun wird wieder eine Kollision erkannt, undzwar zwischen B1 und B2, da B1 ja nun schneller ist, als B2 (und auch B3). Und nun bekommt B2 noch die Häfte der Differenz zwischen den Speeds B1 und B2 dazu addiert und B1 bekommt diesen Wert subtrahiert. Nun ist B2 wieder schneller als B3 UND SO WEITER...
Ihr seht worauf das hinausläuft. Mein Algorithmus rechnet solange, bis ALLE 3 die selbe Geschwindigkeit haben, nämlich 0.33333 * SpeedAmAnfang. So, Java rechnet solange, bis die Genauigkeit der floats aufhört... Irgendwann bei E-15 oder so. D.H. meine Schleife ist solange in einer Dauerschleife, bis dieser Fall eintritt, und aus Sicht der gerundeten floats alle 3 Werte gleich sind.
Klar man könnte nun ehr runden usw... Aber das Hauptproblem bleibt ja !
Wie wird sowas gemacht ? Geht das überhaupt ohne eine Supercomputer zu benutzen
Spaß bei Seite, Ich dachte schon daran, im Vorfeld ALLE Kollisionspartner zu ermitteln, und dann allen die selbe Geschwindigkeit zuzuweisen. Nämlich1/n * SpeedAmAnfang. Aber dadurch kommen ja wieder neue Probleme auf!
So, ein Dankeschön an die, die sich den Kram von mir hier durchgelesen haben!
Gruß Chris
-
Interessant, sehe allerdings keinen Algorithmus.

-
Doch, nur in Pseudocode :p
Wollte fragen, ob es da ne bessere Möglichkeit gibt, als immer zu schauen, welcher Ball mit welchem im nächsten Schritt kollidieren wird... Und dann so lange anpassen, bis die maximale Rundung erreicht ist.
-
Müsste nicht die gesamte Geschwindigkeit von B1 auf B3 übergehen?
Wie bei dem Kugeldings (ich komm jetzt nicht auf den Name, sieht so aus)____ ____ ____ /||| |||\ /||| o ooo ooo o o ooo
-
Ja klar ! Aber eben NUr bei 100% elastischen Stößen...
Bei unelastischen, kannst du es mit Knettgummi verlgeichen!
-
Foxx90 schrieb:
Ihr seht worauf das hinausläuft. Mein Algorithmus rechnet solange, bis ALLE 3 die selbe Geschwindigkeit haben, nämlich 0.33333 * SpeedAmAnfang.
bist du dir da sicher dass das richtig ist? ich haette vermutet, dass die verteilung der energie nicht gleichmaessig ist.
ich wuerde an deiner stelle, wenn die kugeln elastisch sind, das ganze in kleinen, aber konstanten zeitabschnitten simulieren und es akzeptieren, dass die kugeln minimal ineinander stecken, abhaengig dann von der tiefe der penetration, wuerde ich die energie der kugeln aufeinander uebertragen.
manche simulieren sowas uebrigens mit doubles, das kann ein wenig helfen, kann ein wenig langsammer sein, aber das ist ja nur fuer die simulation, die darstellung kannst du weiter mit float betreiben.
-
Vielleicht könnte man die jeweils kollidierten Kugeln eben nach der Kollision als eine auffassen. Also nach einer Kollision von zwei Kugeln entsteht quasi eine neue fuer die naechste Kollision relevante mit doppelter Masse und halber Geschwindigkeit.
-
Daran hab ich noch garnicht gedacht! Ja, stimmt das könnte ich so machen. Hmm, muss ich nur mal schauen wie ich das "allgemein" in einen Algorithmus packe! Da ja auch teilelastische Stöße vorkommen, sprich nur die Hälfte der Energie geht verloren.
Trotzdem super Antsatz danke !Gruß Chris
-
Mein Gedanke waere:
Kugel (eine richtige Kugel) und VirtuelleKugel (nur ein Container fuer mehrere 'Kugel'-Objekte); beide haben gemeinsame Basisklasse (-> Composite Pattern)
Nun kannst du in einem Algorithmus beide Faelle abdecken.Bei teilelastischen Stoessen darf natuerlich keine VirtuelleKugel entstehen, die bleiben in dem Sinne auch nicht aneinander "kleben".
-
Also, if, else if xD Alles klar danke. Das Problem das entsteht, wenn Kugeln in einander stecken ist, dass nachdem sie erstmal in einander stecken, ich nicht mehr merke, dass diese in einander stecken... Das war halt die Logik des Algorithmus (Es erst garnicht soweit kommen zu lassen).
Also, ansich "normal" berechnen, aber wenn nach einem Stoß, 2 Kugeln exakt diesselbe Richtung haben und exakt aneinander stehen, soll ich sie, also von den Vektoren her wie eine behandeln richtig ??
Gruß Chris
-
Deine Kugeln lassen dir keine Ruhe, was?

Ich verstehe nicht ganz, was dir diese Containern bringen soll. Das was du da
willst und wegen der Effizienzgeschichte brauchst, artet in ein Gleichungssystem
aus.Da ich nicht weiß, ob du eine 100% realistische Simulation willst, oder eher
einbisschen Show, wo es eben nicht auf alles ankommt, sondern eher auf Speed,
dann würde ich dir eine Abschwächung deines Kollisionserkennungssystems
vorschlagen.
-
Das Wichtigste ist, dass es mathematisch gesehen komplett i.O. ist! Diese Container bringen einem den Performancevorteil, der durch den Kollisionserkennungsalgorithmus entsteht. Dieser Algorithmus ist nicht falsch, nur er ist so genau, dass die Kugeln nie ineinander stecken, aber auch nicht kollidieren, obwohl sie sich noch garnicht berühren ! Mit Hilfe diesen "Containern" kann ich bei der Kollision mehrerer infolgestehender Kugeln, immer nur 2 "Teilnehmer" berechnen, anstatt, bei der kleinsten Wertänderung immer vom Anfang an zu rechnen ! Der Algorithmus zur Erkennung ist ein Gleichungssystem, sogar ein ziemlich großes. (Für ein Spiel würde ich das aus Performancegründen sowieso nicht machen !) Aber es geht wirklich um eine realistische Simulation.
-
Okay. Ich finde zwar das hier die Performance nur in einem beschränkten System
(3 Kugeln oder mehr exakt hintereinander) zu erwarten ist, aber wenn du
schon eine Verbesserung merkst.