Ich weiß, ich weiß, ich schaffe es einfach nicht etwas Angefangenes zu vollenden, aber irgendwie hat es keinen Sinn an etwas zu arbeiten, an dem man grade kein Interesse hat (Wahrscheinlich wird das Interesse bald wieder vorne anfangen und sich an meiner ersten Idee festsetzen, aber egal)

Also, in den letzten Wochen hab ich mir sehr viele Gedanken (ich gebs ja zu, das war in mathe und physik größtenteils) über physik engines und deren umsetzung gemacht. Zur Information, ich hab mich eine Zeit mit GM Physics beschäftigt, finde aber dass es nicht so "physisch" ist, mir kommt es doch so vor als würde die engine nicht auf allgemeinen formeln basieren, sondern stark hingeschätzt sein. In meinen Gedanken hab ich mich aber auf Quader und Kugeln beschränkt. Nachdem ich herausgefunden hatte das die ganze Sache nicht ganz so einfach ist , auch mal gegoogelt und siehe da, ich sehe nichts. Es ist tatsächlich so, dass es zu diesem Thema praktisch nichts gibt. Sogar zur Dynamik und Kinematik gibt es kaum praktische Beispiele. Somit hab ich mir vieles "erarbeitet" = erdacht und frage jetzt einfach mal die jenigen, die eine Ahnung von Physik und Programmierung von dynamischer Physik und Mechanik haben, ob das die richtigen Ansätze sind und ob das in dieser Form Performancetechnisch umsetzbar wäre (fall jemand weiß wie das echte physik engines machen, dann nur her mit den infos).
Meine Ansätze:

Jeder Körper hat hat die Eigenschaften bzw Variablen:
mx = Mittelpunkt
my
mxp = Mittelpunkt des vorigen Schrittes
myp
r ; l1, l2 = radius oder Seitenlänge 1 und 2 des quaders
v = Geschwindigkeit
a = Beschleunigung
w = Winkelgeschwindigkeit
wp = Winkelgeschwindigkeit des letzten Schrittes
a = Winkelbeschleunigung
M = Masse
d = Dichte
q = Reibungskoeffizient für gleitende Reibung
q0 = Reibungskoeffizient für haftende Reibung
J = Trägheitsmoment (1/12*m (l1^2+l2^2) für quader; 1/2*m*r^2 für kugeln)
k = die Anteile an elastischen und unelastischen Impuls

...Ich schreib morgen weiter
könnt natürlich schon was dazu schreiben...

So und weiter gehts.
Also wie MewX schon sagte kann man keine Vektoren für die Flugbahnen benutzen, da bin ich auch schon recht schnell rein getappt Meine erste Lösung war die Kollision über die Parameter Form der Flächenformel zu berechnen - kein Erfolg, da das ganze ja immer den ersten Kollsisionspunkt betrifft. Nun bin ich dabei das ganze über Ungleichungen zu lösen. Das sollte eigentlich auch funktionieren, doch da komm ich gleich mal auf ein riesen Problem...welche Koordinaten verwende ich. Die vom lezten Step, dann wären natürlich alle Objekte gleich behandelt, doch dann würden sie auch ineinander stecken und ich müsste nachjustieren - schlechte Idee. Man könnte natürlich auch jeweils die neuen Werte benutzen, was aber heißen würde das nicht alle Objekte gleich behandelt werden. Nun deshalb überlege ich gerade über die Kollision der Verschiebungs "Vektoren" (eigentlich Flächen). Ich habe noch nicht getestet (natürlich am Papier und nicht progg technisch, nur zur Info, bevor ich irgendetwas programmiere will ich erstmal wissen wie und was alles nötig ist, sonst kann man gleich einpacken) ob ich die Flächenvektor Kollision auch über Ungleichungen lösen kann.

Das war mal das Kollisionsthema, aber damit was zum reden da ist schreib ich auch noch gleich den Rest den ich so "erarbeitet" habe:
Anderes Problem war, wie wandle ich die Momente eines Objektes in die Winkelbeschleunigung um. Zuerst dachte ich, dass das ganz einfach gehen müsste, hier was kürzen da was dividieren, denn die Trägheit brauch ich sowieso nicht einberechenen. Naja, so kommts dann doch nicht. Nach langen Denkens und Suchens (es ist wirklich fast unmöglich zu dem Thema was zu finden) hab ich diese wunderbare Formel gefunden:


Das ganze kann man jetzt natürlich einfach umstellen und erhält a. Das Trägheitsmoment ist ein Grund warum ich nur Kreise und Quader geplant habe.

Nun ein nächstes Gebiet, Impulse.
Wie übergebe ich Ruckartige Bewegungen und kann sollte ein Objekt eigentlich zurück springen wenn es wo aufkommt. Dazu gibt es doch genügend im Internet, und ich hab eigentlich alles was ich brauche nur noch das ganze mit dem Kollisionssystem (das noch nicht fertig ist ) verbinden, dann kann ich über k, das Verhältnis von elastischem und unelastischem Impuls die neuen Geschwindigkeiten und Bewegungsrichtungen ermitteln.

Eine andere Sache, die Reibung. Da muss ich sagen, bin ich durch Mechanik geschult, das ist kein Problem.
DOCH, kann das ganze bei exakter Kollisions Ermittlung bei eigentlich beliebiger Gegebenheiten, bei exakter Impuls Ermittlung überhaupt laufen und zwar in Echtzeit.

Fragen an euch:

Nun hab ich noch was von Dämpfung gehört, falls jemand weiß wie die funktioniert kann er das gerne posten, dazu gefunden hab ich nichts wirklich brauchbares.

Ist es sinnvoll (damit meine ich ob es viel Performance schluckt) anstatt der Newton'schen Mechanik auch auf die Einsteins zurück zu gehen, dh. das wenn sich ein Körper schneller bewegt, er auch mehr Masse hat, oder können solche Geschwindikeiten sowieso nicht mehr berechnet werden.

Falls jemand weiß, wie herkömmliche physik engines iterieren und integrieren wäre das sehr hilfreich und ob es vielleicht möglich ist, dass die berechnung von nur Quadern und Kreisen auch exakt funktioniert.

Ich bin das Wochenende nicht da, aber egal. Mein Ziel ist es im übrigen eine Physik Engine zu entwickeln, die in 99% aller Spiele anwendbar ist die sie benötigen. Zum einen soll sie sehr Benutzer freundlich sein (sie würde ja auch nur quader und kreis beeinhalten), aber auch relativ schnell. In Bezug auf Schnelligkeit - da ich jetzt schon eine Zeit gezwungener Maßen mit C++ beschäftigt werde, überleg ich das ganze als DLL zu schreiben, die Geschwindigkeit wäre sicherlich schneller. Aber wär was besseres weiß, nur raus damit. Zusätzlich sollte sie, wenn schon denn schon Bug frei sein. Also eine CCD oder wie man das nennt, keine Iterationen (ich war da schon am überlegen), sondern genaue Berechnungen über Vektoren (besser gesagt Flächenvektoren). Achja sie ist natürlich 2d.
Ich finde ja, dass so eine simple Engine (mit simpel mein ich die unterstützten Formen) schon im GM enthalten sein sollte. Verbindungen (Joints) sind zu weit weg um über sie nachzudenken (von meinem Standpunkt aus). Überhaupt wird (finde ich) im Forum sehr wenig über Physik diskutiert und das gehört doch auch zum Proggen dazu.
Ich bin gespannt was so alles kommt, wie ihr das lösen würdet. Achja ich hab den 1. Post editiert...

uh, schattenphönix danke für den hinweis. Ich meine natürlich Kreise und Rechtecke
Und ja das ganze ist in 2d...
Zur info, ich bin schon weiter gekommen. Damit will ich sagen ich weiß, wie ich die Vektor Kollisionsprüfung im Detail mache. Jetz bin ich gerade am tüfteln wie ich die Kollisionsprüfung bei Rotation mache...
Das ganze werde ich Geometrisch Lösen, was heißt keine Iterationen = hohe Genauigkeit, aber nur anwendbar auf eben Kreis und Rechteck.
So langsam hab ich alles Wissen zusammen, somit werd ich bald mit dem proggen beginnen...mal schaun ob was draus wird.

@Senmur: Ja klar, Punktkollisionsberechnungen sind ja niemals ein Problem. Überleg dir mal eine Lösung für flächige Objekte...das wird dann schon etwas komplexer.
Achja dieses Problem ist wie gesagt in meinem Kopf schon gelöst.
Impulsgesetze hab ich auch schon getestet,...die funken.

Das stimmt eigentlich gar nicht, dass Kollisionspunkte immer auf den Eckpunkten liegen müssen...und ja wenn man auf Kugeln zurück geht, dann ist das sehr einfach.
...Mein Problem war anfangs nur: "Gibt es eine möglichkeit bei Parameter Gleichungungen zweier beliebiger Flächen, wobei eine um einen bestimmten Vektor verschoben wird, den ersten Kollisionspunkt zu berechnen, bezogen auf die Zeit, wenn die Zeit gleich die Position auf dem Geschwindigkeitsvektor darstellt?"
Und meine Antwort: Keine Ahnung...wahrscheinlich, ich löse es aber lieber geometrisch.