Hallo ich hab mich gerade gedanklich etwas festgefahren. Versuche im Moment eine einfache Physiksimulation zu schreiben bei welcher eine Kugel mit geraden Flaechen kollidiert. Das funktioniert auch soweit alles sehr gut. Wenn ich zum Beispiel die Kugel auf eine schraege Flaeche fallen lasse springt sie auf der Flache auf und ab und bewegt sich auf Grund der Neigung bis zur Kante, wo sie dann herunterfaellt. Allerdings sprang die Kugel immer gleich hoch, was auch einleuchtet, da bisher keine Energie beim Aufprall verloren gehen konnte und der Geschwindigkeitsvektor einfach nur an der Flaechennormalen gespiegelt wurde.
Kurzerhand hab ich etwas in der Art von im Kollisionsfall eingebaut.

Das Problem was jetzt aber auftritt ist, dass die Kugel zwar nach und nach an Sprunghoehe verliert, aber dann leider auch irgendwann einfach an der schraegen Flaeche kleben bleibt. Mir ist auch klar warum das so passiert, wenn die Geschwindigkeit stetig abnimmt und ich weiss auch noch dunkel ausm Physikunterricht dass hier die Hangabtriebskraft ins Spiel kommt (Ich wuesste sogar wie man die implementiert). Mein gedanklicher Knoten liegt jetzt halt an folgendem Punkt: Wann lass ich die Kugel abprallen und wann entscheide ich mich sie an der Flaeche entlanggleiten zu lassen?? Bzw muss man da ueberhaupt eine Fallunterscheidung machen? Mir waers naemlich lieber das elegant und einheitlich loesen zu koennen. Ich koennte ein paar Gedankenanstoesse gut gebrauchen

Uebrigens ist alles nur in 2D.

_________________
Flummi: Projektseite und Projektthread

hey
also ich hab sowas ähnliches mal programmiert(mit delphi und canvas), allerdings ohne schrägen die Hangabtriebskraft ist eigentlich nichts weiter als die schwerkraft - wenn du also generell eine schwerkraft einbaust ( auf den y-vektor addierst) dann solltest du auch den sonderfall "Hang" damit bewerkstelligen können - und zwar, dann wenn der ball bei dir nur noch liegen bleiben würde, würde er die schräge hinabrollen ... das ganze könnte aber naturgemäß etwas hakelig werden (wenn du die pixel als koordinaten system nutzt)

mfg grey

Moin,

du solltest anstatt einfach die Geschwindigkeit zu übernehmen und nur Richtung zu verändern einen Kollisionsimpuls ausrechnen. Diesen kannst du dann ja nach Materialeigenschaften
skalieren, danach wird er erst auf die Geschwindigkeit addiert. Das hat den Vorteil, dass du Masse und Härte des Körpers berücksichtigen kannst.
Ich würde dir davon abraten irgendwelche Fallunterscheidungen zu machen, weil bei einer einigermaßen korrekten Physiksimulation sowieso alles so berechnet wird, wie es in der
Realität passiert. Wenn du deine Simulation also erweitern möchtest wirst du mit Fallunterscheidungen irgendwann wieder zu Problemen kommen, deswegen würde (und habe) ich gleich
"richtig" anfangen.

Markus

Ja das hab ich mir auch gedacht. Das mit dem Impuls war ein sehr guter Tipp. Hab mir jetzt nochmal einiges durchgelesen und ne Menge ausprobiert. Es rutscht jetzt
Muss den Code nur mal ein bisschen aufraeumen, um mich dann das naechste Mal das ich Zeit habe an Rotationen zu wagen

_________________
Flummi: Projektseite und Projektthread

Nebenbei ist genau diesem Punkt ein nicht geringer Teil der Kollisionstutorialreihe gewittmet worden. Hast du dir die mal durchgelesen?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Naja, was im dem Tutorial beschrieben wird hat aber nicht viel mit Physik zu tun, sondern ist eher was für ein einfaches Spiel, wo es nicht auf wirkliche Physik ankommt.

Kannst du das näher begründen?

Ich sags mal so. Wer realistische Bewegungen haben will, der kommt mit einfacher Gamephysik gut hin. Und das wird im Tutorial beschrieben.

Wer ne Physiksimulation haben will, sollte eine passende Engine wie z.B. Newton nehmen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hallo,

er will ja auch Rotationen haben, die werden in den Tutorials garnicht behandelt. Eine Kugel, die ne schiefe Ebene nicht runterrollt, wäre wohl ein bisschen komisch
Abgesehen davon wird im Kollisionstutorial auf keine Eigenschaften wie Masse, Reibung ect. eingegangen. Für Spiele, die keinen solchen Anspruch haben ist das ja vollkommen ausreichend,
aber ich habe den Threadstarter eher so verstanden, dass er eine kleine Physiksimulation schreiben möchte. Mit den Berechnungen aus dem Tutorial wird man da aber nicht sehr weit kommen.

Markus

Ja genau ich wollte (bzw will immer noch ) eine kleine Physiksimulatin schreiben. Das ich damit quasi das Rad neu erfinde und auch auf fertige Produkte wie Newton zurueckgreifen koennte ist mir bewusst.

@flash: Ja die Tutorialreihe hab ich natuerlich gelesen. Zumindestens die ersten beiden Teile und den dritten dann ueberflogen. Meine Kollisionserkennung basiert auch vollstaendig auf den Tutorials aus dem Wiki, nur fuer meine Kollisionsverarbeitung habe ich dort nichts recht passendes finden koennen.

_________________
Flummi: Projektseite und Projektthread

Hallo,

als Verfasser der Kollisions-Tutorials sollte ich mich mal kurz melden.

Die Tutorials befassen sich hauptsächlich mit den geometrischen Aspekten von Kollisionen und Bewegung. Bei einem realistischen Spiel kommen natürlich die physikalischen Dinge hinzu, dich ich - schon aus Platzgründen - nur andeuten konnte. Was mit beiden Dingen nichts zu tun hat, ist z.B. die Darstellung des Rollens, das ist eine Frage der Orientierung des Objektst. Für die Physik ist nur der Massepunkt interessant, für die Geometrie die äußere Form des bounding volumes. Aber das nur am Rande.

Ich melde mich deshalb, weil ich den in den Tutorials beschriebenen Algorithmus inzwischen weitgehend in ein Rewrite des Spiels Tuxracer eingebunden habe. Das Ganze funktioniert sehr sicher und stabil, erfordert allerdings, dass das Programm timergesteuert läuft. Nur so lassen sich auf verschiedenen Computern vergleichbare Spielbedingungen schaffen. Ich will jetzt nicht in die Einzelheiten gehen, nur so viel: In dem genannten Testprogramm habe ich die Geometrie in einer Klasse gekapselt und dabei die Reaktion auf verschiedene Kollisionen verfeinert. So ist z.B. einstellbar, wie stark die Bewegungsrichtung bei unterschiedlichen Aufprallwinkeln beinflusst werden soll usw. usw.

Das Ganze ist wiederum in eine komplett neu geschriebenen Physik-Engine eingebunden, bei der alle Einflüsse auf Kraftvektoren zurückgeführt werden, auch die Steuerungsimpulse. Was die fertigen Libraries anbetrifft: Es liegt natürlich nahe, so etwas einzubinden, aber ich habe festgestellt, dass sie keineswegs ein Allheilmittel sind. Je nach Zweck kann es besser und einfacher sein, die Physik selber zu schreiben.

Kurz und gut, wer Interesse hat, kann sich ja die die Testversion von meiner Webseite herunterladen. Leider kann ich das Programm nur in C++ und für Linux anbieten, aber wer sich den Code anschauen möchte ... Die Physik ist in physics.cpp, die Kollision in collision.cpp und die Objektbehandlung in models.cpp untergebracht. Die Physik basiert auf folgenden Komponenten:

- Gravitation und Masse (natürlich)
- Reibungskoeffizient in Abhängigkeit von der Oberfläche
- Luftwiderstand
- Beschleunigungsvektor
- Bremsvektor
- Steuerungsvektoren

Das Programm ist noch eine Baustelle, und viele Dinge sind noch nicht richtig justiert. Die Ausrichtung des Pinguins wird nach guter alter Tuxracer-Manier mit Matrizen und - sofern es um Interpolationen geht - mit Quaternionen vorgenommen. Vielleicht lohnt es sich, den Code auch daraufhin mal zu untersuchen (siehe rollende Kugel). Module: tux.cpp, character.cpp und keyframe.cpp. Allerdings ist der Pinguin mit 80 Knoten, 16 Joints und rund 30 sichtbaren Teilstrukturen wesentlich komplizierter aufgebaut als eine texturierte Kugel, aber das Prinzip lässt sich ebenso auf ganz einfache, starre Figuren übertragen.

http://www.erinacom.de/tux/bunnyhill/bunnyhill.html

Frohe Feiertage

Hallo,

da würde ich dir widersprechen. Für die Physik ist natürlich nicht nur der Massenpunkt wichtig, sondern selbstverständlich auch die Geometrie, nämlich um den Trägheitskoeffizienten (2D) bzw. den Trägheitstensor (3D) auszurechnen (Den Massenpunkt bekommt man auch nur durch die Geometrie und die Dichte der einzelnen Teile des Körpers). Ich habe mir dein Spiel jetzt nicht angeschaut, aber ich gehe einfach mal davon aus, dass du sowas nicht brauchst, denn bei Tuxracer gab es sowas wie Rotation ja auch nicht, jedenfalls keine, die durch die Trägheit beeinfusst werden würde. Bei seiner 2D Simulation sieht das aber schon wieder ganz anders aus.

Zu den Boundingvolumes: Ich glaube damit kann der Threadersteller nichts anfangen, weil es ja in 2D ist und man sich dort keine Ungenauigkeiten leisten kann, da muss man schon die wirkliche Geometrie testen.

Ich glaube man kann die ganze Sache nicht so einfach Pauschalisieren, es hängt einfach viel zu sehr davon ab, was man denn simulieren möchte. Manchmal kann dann ein einfaches Modell bessere Ergebnisse liefern als ein vermeindlich besseres. Deswegen kann man Tuxracer und seine 2D Simulation jetzt auch nicht wirklich vergleichen.

Markus

Ok, andere Schwerpunkte, und wahrscheinlich reden wir aneinander vorbei. Mir schien es, als wollte Avarage Idiot eine realistisch erscheinende (!) Kugelbewegung simulieren. Dass es vielmehr um Rotationsbewegungen geht, die soweit gehen, dass u.a. auch Dichteverteilungen im Körper exakt einbezogen werden, habe ich auf die Schnelle nicht aus dem Thread herausgelesen. Auch dass es sich um eine 2D Simulation handelt, habe ich überlesen. Aber es spricht ja nichts dagegen, die Kugel auf der Basis von Trägheitstensoren rollen zu lassen (oder eiern, damit man den Unterschied zu einer platten Game-Physik erkennt?)

Im übrigen ist es eine interessante Frage, wie weit eine Simulation gehen muss und was sie leisten soll. Sollen physikalische Gesetze so genau simuliert werden, dass man aus den Ergebnissen Erkenntnisse ableiten kann, oder geht es darum, Abläufe nachzubilden, die aufgrund unserer Erfahrungen als physikalisch korrekt erscheinen? Insofern gebe ich dir recht, bei einer Simulation geht es auch um den Zweck, und da kann man nicht pauschalisieren. Sorry, ich habe die Absicht des Fragestellers wohl nicht richtig eingeschätzt.

Hallo,

ja, interessanter Aspekt. Als ich eine Physiksimulation geschrieben habe, wollte ich genau das tun, nämlich aus den Daten, die mein Programm liefert, auf physikalische Grundsätze
kommen. Trotzdem habe ich das nicht wirklich wissenschaftlich aufgebaut, aber im Endeffekt bin ich eigentlich sehr zufrieden damit gewesen.

Das eine ist die korrekte Kurve, das andere die der Simulation.



Was der Threadstarter genau möchte ist mir auch nicht ganz klar, aber ich glaube wir kommen etwas vom ursprünglichen Thema ab

Was der Threadstarter genau will, ist ihm selbst noch nicht klar

Grob gesagt habe ich eine noch etwas verschwommene Idee zu einem einfachen Spielchen, bei welchem man einen Flummi durch ein Hindernisfeld schiessen muss, bis er (hoffentlich) am Ziel ankommt. Es soll halt einfach sein, da ich wirklich nicht viel Zeit zum coden hab.
Mein Plan war halt erstmal die physikalischen Grundlagen zu schreiben, aus welchen ich dann spaeter schnell das Spiel erschaffen kann. Zudem denke ich, dass wenn man dann so ein bisschen mit der Simulation herumspielt, fallen einem moeglicherweise noch weitere Spielideen ein. Da das ganze wie gesagt mehr eine Art Minigame werden soll, wollte ich lieber auf eine in meinen Augen dafuer zu aufgeblasene Engine wie Newton verzichten. Ausserdem macht es Spass die Physiksimulation zu schreiben (zB erstmal selbst versuchen und dann schauen/fragen wie andere Loesungen aussehen).
Kurz gesagt ich muss keine wissenschaftlich exakte Simulation schreiben, solange es gut aussieht und halbwegs allgemeingueltig ist (nicht zu sehr auf ein spezielles Spielszenario zugeschnitten).

_________________
Flummi: Projektseite und Projektthread