spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Der Vorschlag von Blue Cobold funktioniert wunderbar für konstante und analytisch beschreibbare Bewegungen. Sobald nur ein Parameter jedoch nicht mehr näherungsweise stationär sind muss man auf iterative Verfahren zurückgreifen.

Die hier immer besprochene Methode zur iterativen Berechnung ist die Euler Methode, welches ein Verfahren erster Ordnung ist und das ungenauste von allen. Sollte man damit ein Problem haben lassen sich Integrationsverfahren höherer Ordnung verwenden.

Wenn ich mich recht erinnere ist es in den Simulationen bei uns am Institut üblich für solche Probleme die Runge Kutta Methode 4ter Ordnung zu verwenden. Es behebt nicht das Problem, dass iterative Methoden in ungünstigen Fällen instabil sind, jedoch erreicht man damit eine wesentlich höhere Genauigkeit als mit der Euler Methode und kann bei Verwendung konstanter Abtastraten (fixed time step) die Verteilung der Fehler sehr genau bestimmen.

Jedoch ist das denke ich mehr Aufwand als in der Spieleentwicklung idR nötig ist. In Spielen geht es um Wahrnehmung nicht um Genauigkeit. Die Kugel die man abfeuert muss nicht dann treffen wenn es physikalisch 100% korrekt ist, der Spieler sollte bloß das Gefühl haben dass es physialisch korrekt ist.

Ja, aber sie muss immerhin treffen Und das ist nicht unbedingt bei jeder Framerate gegeben, wenn ein instabiles, iteratives System verwendet wird (Tankwars mit Lag oder low-FPS z.B.). Bei anderen Dingen als einem Schuss kann es auch zu anderen ungewollten Ergebnissen kommen.

Runge Kutta ist nett, zumindest was ich noch so aus der Numerik-Vorlesung weiß Aber wer baut das schon in sein Game ein?

Eben gerade bei komplexer Physik gehts nurmehr iterativ. Sobald es komplexer wird als z.B. ne Wurfparabel kannst du analytisch knicken. Die "großen" Engines arbeiten natürlich sicher alle iterativ mit fixem Timestep...

Zitat von »Elmaron«

Dafür ist nach eigenen Tests ein iteratives System ideal und deutlich stabiler als sonstiges Floatzeitfaktorgepansche.

Dir ist aber schon klar, dass iterative Systeme auch das so genannte "Floatzeitfaktorgepansche" nutzen müssen? Denn wie willst du sonst den nächsten Schritt der Iteration berechnen?

Und ich dachte immer Multiplikation (Floatzeitfaktor) sei numerisch stabil und Addition (Iteration) wäre das numerisch instabile Problem