Du bist nicht angemeldet.
Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
18.02.2005, 20:45
|
C-/C++-Quelltext |
1 |
abs(r) < 1.0f |
19.02.2005, 10:50
Zitat von »"Till"«
Es gibt doch sicher Physik-Engines mit Gravitation! Wie machen die das???
19.02.2005, 11:02
Ich vermute, das liegt daran, dass ich keine unendlich hohe Framerate habe und die Kraft nicht kontinuierlich mit der Zeit wirkt.
(Kann ich diese lineare interpolation "zwischen" den Frames vielleicht ausgleichen, indem ich die Kraft "quadratisch" zur Zeit anwende? Wie müsste ich es denn dann machen?).
. Daher hab ichs mir gerade überlegt, es müsste richtig sein, aber vielleicht nicht optimal. Ein paar Denkanstöße:
. Dann kannst Du mit der letzten Gleichung b0 berechnen (für diesen Schritt). Die Geschwindigkeit erhöht sich dann um a0 * t + b0 * t**2, wobei t die Schrittweite ist.
19.02.2005, 11:15
...oder Du testest bei jeder Aktualisierung der Positionen, ob zwei Teilchen aneinander vorbeigeflogen sind. Wenn dem so ist, dann sollen die beiden Teilchen die gleiche Entfernung zueinander haben, wie vor dem Vorbeiflug. Dann sind die potenziellen Energien beider Teilchen zueinander die selben, wie vor dem Vorbeiflug und es ist weder Energie dazugekommen, noch abgeflossen.
(Oder vertue ich mich da jetzt?)
Nein, es ist ja eine Simulation, bei der zu jedem Zeitpunkt wirkende Kräfte (und das können 'ne Menge sein!) die Teilchen beeinflussen. Also kann ich nicht "mogeln", indem ich Positionen anpasse.
19.02.2005, 11:32
.
Dort ist die Gravitation aber immer konstant (z.B. immer mit 9,81 m/s² nach unten). Mir ist keine Engine bekannt, die zwei sich anziehende Massen direkt simulieren kann.
19.02.2005, 12:24
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 |
const float Zeitwert=0.1f;//bissel ungenau, aber nur ein Bsp
float VergangeneZeit=0;
while(true)
{
//Nachrichten
VergangeneZeit+=????;
while(VergangeneZeit>Zeitwert)
{
VergangeneZeit-=ZeitWert;
Move(Zeitwert);
}
Render();
}
|
20.02.2005, 20:11
Wenn Du schon extrem nahe vorbeiflüge oder sogar r=0 hats, dann ist Till m.E. auf einem guten Weg. Die Zeit in Schritte aufzuteilen ist ja ein problem und eigentlich ein mogeln, aber beim digitalen Computer eben unumgänglich. Kleinere Schrittweite = weniger mogeln (bessere Annäherung an die Wirklichkeit), aber eben auch langsamere Simulation. Seh es so: Der Fall r=0 darf eigentlich nicht auftreten und m.E. ist Dein Fehler, dass er auftritt. So klein Du Deine Schrittweite auch machst, in dem Schritt über die Null (z.B. von x = - 0.0001 bis x = 0.0003) überspringst Du 100% der Physik, die geschieht. In dem Bereich ist die Änderung der Potentiellen Energie unendlich, ausserhalb endlich. M.E. ist Dein problem, warum Du immer eine Energiezunahmen (und nicht z.B. zufällig Zu- oder Abnahme) hast, dass beim letzten Schritt vor Null eine Riesen Kraft auftritt, daher auf der nächste Schritt auf der anderen Seite weiter von Null entfernt als dieser Schritt vor Null war, wie eben in meinem Beispiel Damit hast Du in diesem Schritt eine grössere positive Beschleunigung als im nächsten Schritt eine negative, was zu der Energiezufuhr führt. Wenn Du in diesem Schritt die Zeit so begrenzt, dass die beien x Werte abosolut gesehen identisch sind, dann hast Du die selbe negative Beschleunigung wie vorher positive und die Physik zwischen x und Null, die Du wegschmeisst, ist auf beiden Seiten die selbe, nur eben umgedreht.
20.02.2005, 21:12
OK, das Problem mit r=0 kann ja durch Überprüfen behoben werden, aber das Problem wird eben sein, dass bei einem Frame bei r fast 0 die Geschwindigkeit so hoch wird, dass des Teilchen beim nächsten Frame zu weit weg ist.
Aber um die potentielle Energien zu erhalten und die Frames "symmetrisch" zur Bewegung ablaufen, brauche ich ja irgendeine Synchronisierung, das blöde ist aber ja, dass das System groß ist und ich nicht wissen kann, wie viele Felder und Teilchen der Benutzer erstellt. Wie synchronisiere ich das dann also?
Aber mit DGLs kann ich nicht viel machen, ich bin erst Schüler in Klasse 12,
das Projekt soll nicht gerade mein Lebenswerk werden
PS: Ach ja, ich benutzte D3DXVECTOR3s und das sind doch FLOATs, oder (32 bit dachte ich)?
13.06.2024, 01:07
Zum Seitenanfang
