Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: So Mai 19, 2024 14:14

Foren-Übersicht » Programmierung » Mathematik-Forum
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 01, 2009 16:50 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Jan 04, 2008 21:29
Beiträge: 419
Wohnort: Lübeck
sau geil! Kannst du evtl mal ein wenig Code posten mit dem du die Stoß- und Dämpfungsreaktion realisiert hast? Das sieht super interessant aus!

_________________
Klar Soweit?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 01, 2009 17:53 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Kann ich tun :)

Ich hatte auf ner Webseite (war irgendein Forum, gamedev glaub ich) nen code schnipsl gefunden der wohl die DLG darstellt (denke ich xD)
Weil von dem Mathe kram hab ich echt null ahnung und "leider" auch nicht den willen es zu lernen.. ;)

Das ganze hab ich als Classe verpackt:

Code:
  1. class CRSpring
  2. {
  3. private:   
  4.     float dx(float v);
  5.     float dv(float x, float v);
  6.     float rk4(float t, float h);
  7. public:
  8.     float mass, stiffness, damping;
  9.     float time;
  10.     float position;
  11.     float velocity;
  12.    
  13.     CRSpring();
  14.     void simulate(float timeSteps);
  15.     void reset();
  16. };
  17.  
  18.  
  19. float CRSpring::dx(float v)
  20. {
  21.     return v;
  22. }
  23.  
  24. float CRSpring::dv(float x, float v)
  25. {
  26.     return (-stiffness / mass) * x - (damping / mass) * v;
  27. }
  28.  
  29. float CRSpring::rk4(float t, float h)
  30. {
  31.     float x = position;
  32.     float v = velocity;
  33.    
  34.     float dx1 = dx(v);
  35.     float dv1 = dv(x, v);
  36.    
  37.     x = position + (h / 2.0f) * dx1;
  38.     v = velocity + (h / 2.0f) * dv1;
  39.    
  40.     float dx2 = dx(v);
  41.     float dv2 = dv(x, v);
  42.    
  43.     x = position + (h / 2.0f) * dx2;
  44.     v = velocity + (h / 2.0f) * dv2;
  45.    
  46.     float dx3 = dx(v);
  47.     float dv3 = dv(x, v);
  48.    
  49.     x = position + h * dx3;
  50.     v = velocity + h * dv3;
  51.    
  52.     float dx4 = dx(v);
  53.     float dv4 = dv(x, v);
  54.    
  55.     position = position + (h / 6.0f) * (dx1 + dx2 * 2.0f + dx3 * 2.0f + dx4);
  56.     velocity = velocity + (h / 6.0f) * (dv1 + dv2 * 2.0f + dv3 * 2.0f + dv4);
  57.    
  58.     return t + h;
  59. }
  60.  
  61. CRSpring::CRSpring()
  62. {
  63.     reset();
  64.     mass = 0.5f;
  65.     stiffness = 3.0f;
  66.     damping = 2.0f;
  67. }
  68.  
  69. void CRSpring::simulate(float timeSteps)
  70. {
  71.     time = rk4(time, timeSteps);
  72. }
  73.  
  74. void CRSpring::reset()
  75. {
  76.     time = 0.0f;
  77.     position = 0.0f;
  78.     velocity = 0.0f;
  79. }


Tjoa und das war's eigentlich schon... die position ist halt immer die länge der Feder :)

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 01, 2009 19:22 
Offline
DGL Member

Registriert: Mo Mär 16, 2009 10:22
Beiträge: 26
Naja das ist keine DGL-Lösung, sondern die numerische. Es wird einfach die Geschwindigkeit, Beschleunigung und Position berechnet, die nach jedem Zeitschritt "herrscht". Dabei interpoliert die gezeigte Numerische Lösung nicht linear zwischen den Zeitschritten (d.h. dazwischen konstante Beschleunigung), sondern berechnet verschiedene lineare Interpolationen (Hälfte der Zeit mit Anfangswerten, Hälfte der Zeit mit den zuerst berechneten Werten, dito, dann die ganze Zeit mit den letzen Werten) und bildet eine gewichtete Summe.
Ist nicht ganz physikalisch korrekt (ich wundere mich, weil die eine korrekte Lösung nicht mehr Rechenzeit benötigt), aber sieht ja anscheinend gut aus.
Das ganze ist nur frameratenabhängig. Desto höher die Framerate, desto genauer stimmt das Ergebniss mit einem echten Verhalten überein. Da sollte man vorsichtig sein später wenn das schaukeln Spielinhalt-relevante Dinge enthält.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 02, 2009 07:23 
Offline
DGL Member

Registriert: Do Mai 30, 2002 18:48
Beiträge: 1617
merlinschmidt hat geschrieben:
Das ganze ist nur frameratenabhängig. Desto höher die Framerate, desto genauer stimmt das Ergebniss mit einem echten Verhalten überein. Da sollte man vorsichtig sein später wenn das schaukeln Spielinhalt-relevante Dinge enthält.

Das kommt ganz darauf an, wie sie weiter vorgeht. Viele Physik-Simulationen arbeiten in einem fest vorgegebenem Zeitraster und die Grafik interpoliert zwischen den Physik-Frames und man bekommt im Prinzip kaum Probleme. Aber ich schätze dafür ist das gar nicht gut.... Aja in welcher Animation werden denn schaukelnde Autos auftauchen, falls Dus verraten darfst? ;-)

Zitat:
Ist nicht ganz physikalisch korrekt (ich wundere mich, weil die eine korrekte Lösung nicht mehr Rechenzeit benötigt), aber sieht ja anscheinend gut aus.

Bei den vielen Bildern pro sek. tut sich da denk nicht viel, spannend wirds, sobald die Bildfrequenz der Bilder die Schaukelfrequenz zu nahe kommt oder gar zu unterschreiten beginnt, aber dann ist sowieso hopfen und malz verloren, weil ich dann auch korrekt berechnet nicht mehr genug sehe, um das schaukeln zu erkennen - etwa der effekt wenn rotierende gegenstende animiere und bei bestimmten geschwindigkeiten drehen sie sich rückwärts. ausserdem gibts als gratisbonus ja noch ständig zusätzlichen Input über den Bodenbeschaffenheit. Wenn die Simulation nicht total daneben liegt, wirds deswegen keiner sehen und schätzen können, solange die dämpfung auch nur in etwa das macht, was sie soll. Wobei es natürlich kein grosser stress sein dürfte, die analytische lösung jetzt statt dem numerischen testweisen einzusetzen - durch den boden wirst du aber auch hier immer etwas numerik machen müssen...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 02, 2009 08:31 
Offline
DGL Member

Registriert: Mo Mär 16, 2009 10:22
Beiträge: 26
Zitat:
Das kommt ganz darauf an, wie sie weiter vorgeht. Viele Physik-Simulationen arbeiten in einem fest vorgegebenem Zeitraster und die Grafik interpoliert zwischen den Physik-Frames und man bekommt im Prinzip kaum Probleme. Aber ich schätze dafür ist das gar nicht gut.... Aja in welcher Animation werden denn schaukelnde Autos auftauchen, falls Dus verraten darfst? ;-)

Naja in dem gezeigten Codeschnipsel war nichts mit einem fest vorgegebenen Zeitraster. Wenn man das erweitert, und die Zeitabschnitte immer gleich groß wählt, ok. Du kannst gerne auf "viele Physik-Simulationen" verweisen, musst dann aber auch die jeweilige exakte Berechnung berücksichtigen, so ist das nur eine Pauschalaussage.

Zitat:
Bei den vielen Bildern pro sek. tut sich da denk nicht viel, spannend wirds, sobald die Bildfrequenz der Bilder die Schaukelfrequenz zu nahe kommt oder gar zu unterschreiten beginnt, aber dann ist sowieso hopfen und malz verloren, weil ich dann auch korrekt berechnet nicht mehr genug sehe, um das schaukeln zu erkennen - etwa der effekt wenn rotierende gegenstende animiere und bei bestimmten geschwindigkeiten drehen sie sich rückwärts. ausserdem gibts als gratisbonus ja noch ständig zusätzlichen Input über den Bodenbeschaffenheit. Wenn die Simulation nicht total daneben liegt, wirds deswegen keiner sehen und schätzen können, solange die dämpfung auch nur in etwa das macht, was sie soll. Wobei es natürlich kein grosser stress sein dürfte, die analytische lösung jetzt statt dem numerischen testweisen einzusetzen - durch den boden wirst du aber auch hier immer etwas numerik machen müssen...


Man müsste es mal testen. Es kann, insbesondere wenn innerhalb der Berechnung große oder sehr kleine Zahlen auftauchen, schon erhebliche Unterschiede machen, ob das ganze mit 30 oder 60 fps läuft.
Ich habe ja auch geschrieben, dass es beim anschauen bestimmt ziemlich egal ist, ob es stimmt, deterministisch ist, oder korrekt - solange es gut aussieht. Wenn man aber z.B. mit einbezieht, dass ein Auto auch vom Untergrund abheben kann - z.B. bei extremen Bodenwellen - oder dass das Auto auch bei zu rasanter Fahrweise mal aufsetzen kann (was dann Nachteile für den Spieler hat), das ganze dann also irgendwie einen relevanten Spielinhalt hat, sollte man sichergehen, dass es auf jeden Fall Frameratenunabhängig ist. [/quote]


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 02, 2009 08:52 
Offline
DGL Member

Registriert: Sa Aug 09, 2008 09:07
Beiträge: 112
Ich hab mich in letzter Zeit auch sehr viel mit Federn beschäftigt, hab aber schlussendlich nur F = k * x verwendet...
Um das ganze noch realistischer zu machen sind die Federfunktionen glaub ich noch geeigneter und bilden ein exaktes
Ergebnis. Ich hab das selbst noch nicht ausprobiert, aber es wird bald da zu kommen, weil ich unbedingt ein exakes Ergebnis
will^^.

Mathematisch bin ich leider noch nicht so weit (bzw. ich habs noch nicht gelernt). Man hat mir gesagt dass man da Differenzieren
muss, aber am Ende kommt man genau auf diese Funktionen...
Schwierig wird es dann aber bei mehreren Federn die sich gegenseitig beeinflussen. Ich hab mir noch nicht den Kopf darüber
zerbrochen aber wie gesagt... bald :)
Ich glaube aber nicht dass ich bei so einem komplexen System wo sich die Federn beeinflussen auf ein exaktes allg. Ergebnis komme...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 02, 2009 09:44 
Offline
DGL Member

Registriert: Mo Mär 16, 2009 10:22
Beiträge: 26
F=k*x beschreibt aber auch nur die Federkraft bei einer Auslenkung x aus der Ruhelage, und wird auch immer benutzt. Bei der Sim. die hier gefragt wurde, gibt es aber eine ganze Menge weiterer Kräfte, durch z.B. Stoßdämpfer, Randbedingungen wie feste Position des Rades auf der Strasse, festgelegte Masse und Geschwindigkeit des Autos auf der Feder etc.

Wenn du viele aneinander gekettete Federn analytisch berechnen willst, kommst du eigentlich nicht um einen http://de.wikipedia.org/wiki/Lagrange-Formalismus (Lagrange-Formalismus) herrum um solltest dich doch tiefergehen mit Mathe beschäftigen, oder eine einfach numerische Schritt-für-Schritt Lösung vorziehen :-).


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 22 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Foren-Übersicht » Programmierung » Mathematik-Forum


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.008s | 14 Queries | GZIP : On ]