Hallo,
ich treibe mich gerade mal wieder im Sourcecode eines OpenGL-Programms herum und versuche, die Zusammenhänge annähernd zu verstehen. Dabei stolpere ich über den Begriff ODE. Die entsprechende Funktion wird wird in jedem Frame aufgerufen und berechnet anscheinend die Position bzw. Geschwindigkeit der bewegten Spielfigur. U. a. liegt auch die Kollisionserkennung in dieser Routine.

Die Suche im Internet hat eher für Verwirrung als Klarheit gesorgt. Schon die Erklärung: Mal ist die Rede von "Ordinary Differential Equations", mal (so auch in diesem Forum) von "Open Dynamics Engine". Sind das verschiedene Dinge oder verschiedene Namen für dasselbe? Zur Erläuterung: in dem o.g. Programm werden verschiedene Verfahren zur Auswahl angeboten: Euler, ode23, ode45 usw.

Kann mir jemand zu etwas mehr Durchblick verhelfen?
Dank im voraus
Reinhard

ich kenn das aus MatLAB ist ein Befehl um Differentialgleichungen zu lösen

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

In diesem Falle sind des wohl die Ordinary Differential Equations - die Gewöhnlichen Differentialgleichungen. Das sind gleichungen, in denen die Ableitungen einer Funktion auftauchen und die sich ganz gut numerisch lösen lassen. Darunter passt das Euler-Verfahren und die benennung der anderen Funktionen - sie legen nämlich nahe, daß dort der Fehlberg-Trick verwendet wurde - ein DGL Löser (Runge-Kutta verf.) wird zum Fehler-Schätzen verwendet (kontrolliert die Schrittweite), der andere rechnet Vorwärts. Das kann man sehr effizient verknüpfen.

Als kleine Erklärung zu gewöhnlichen Differentialgleichungen: Lass uns das Gesetz des Radioaktiven Zerfalls ableiten. Aus versuchen lernt man schnell, daß die Aktivität direkt Proportional (nennen wir den Faktor lambda < 0) zur Anzahl der noch vorhandenen Atome ist. Der Abfall=negative Steigung der Funktion gerade ein vielfaches des Funktionswertes ist. In Formel:

Wobei x(t) die Funktion ist, die die Anzahl der Atome beschreibt, die zum Zeitpunkt t noch vorhanden sind und x' die Ableitung dieser Funktion nach t ist. Diese Gleichung lässt sich eindeutig lösen. Aus der Differentiererfahrung aus der Schule ist sicher bekannt, daß gerade die e-Funktion diese Eigenschaft hat - die Lösung ist also:

Die Gefundene Funktion erfüllt also unsere DGL vom Anfang. Radioaktivität gelöst

Jedenfalls lassen sich viele Gleichungen dieser Art, sofern eindeutig, ..., prima numerisch lösen und die Lösung verhält sich auch noch in etwa so, wie man sich das vorstellt. Auch das drei- und mehrkörperproblem lassen sich damit beschreiben und numerisch lösen (Nur für das 2-Körper Problem sind schon seit Newton entsprechend schöne, analytische Lösungen bekannt, wie ich sie etwa gerade beim RA-Zerfall beschrieben habe). Mit Kollisionserkennung hat das aber nicht allzuviel zu tun, je nach Differentialgleichung ergibt sich das aber eventuell fast von sich aus, wenn die Kräfte und Beschleunigungen sehr hoich werden, wenn sich die Körper zu nahe kommen.
Als kleine Warnung: Das ganze steigt mathematisch für die meisten nicht mathematiker, physiker und einige ingenieurgruppen sehr tief in neue gebiete und bedarf für aussenstehende eventuell einiges an Einarbeitungszeit Bücher kann ich im bedarfsfall empfehlen.

Erm....ich denke mit ODESolver ist ODE=OpenDynamicsEngine gemeint....ne opensource Physik-Engine : www.ode.org

Gruss,
Thorsten

So wie die Funktionen genannt sind, würde ich fast darum wetten, daß es sich nicht um die ODEngine handelt, sondern um Runge-Kutta-Verfahren - besonders bekannt sind hier nämlich besonders das Euler-Verfahren, und die Eingebetteten RKV der Ordnung 2 und 3 sowie der Ordnung 4 und 5

Also ich tippe hier auch auf die Physik-Engine ODE, der Begriff Solver taucht in dem Zusammenhang ja auch öfters auf (man denke nur an IK (=Inverse Kinematik) Solver). Aber ist denn bei dem Code keine Unit dabei, in der weitere Erläuterungen sind?

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Nein, die Funktionen sind offensichtlich vom Programmierer selbst implementiert und kommentarlos in einem Programmodul zusammengefasst. Aber gehe ich richtig in der Annahme, dass die beiden "ODEs" verschiedene Sachen sind? Da das Programm die Bewegungsabläufe der Spielfigur anhand der Bodenneigungen, der verschiedenen Kräfteeinwirkungen usw. exakt physikalisch simuliert (es wird sogar mit der Gravitationskonstante 9.81 gearbeitet), wäre die ODE im Sinne der Physik-Engine schon naheliegend.

Aber nach Nicos Erläuterungen (und einer Nacht mit dem Quelltext unter dem Kopfkissen) bin ich nun sicher, dass damit die numerischen Verfahren gemeint sind. Alle Anzeichen sprechen dafür: Das Arbeiten mit Schätzwerten (z.B. update_estimate ...) oder eine Schleife, die solange durchlaufen wird, bis ein Fehler eine tolerierbare "Kleinheit" angenommen hat. Und auch der Zweck kristallisiert sich langsam heraus: Berechnet wird in "solve_ode_system" vor allem die neue Position der Spielfigur und ihr aktueller Geschwindigkeitsvektor. Ein wesentlicher Parameter ist dabei die seit dem vorherigen Frame vergangene Zeitspanne. Die Frage ist nun, ob dazu ein derart kompliziertes Verfahren notwendig ist. Es wäre nicht die einzige Stelle, wo sich der Programmierer an komplizierten Dingen berauscht ...

Das kommt ganz stark drauf an, was das Programm machen soll. Und die üblichen Physik-Engines und Kollisions-Erkennungen übersteigen einen einfachen DGL-Löser (nicht DelphiOpenGl sondern Differentialgleichung ist gemeint ) bei weitem und wenn man mal ein bischen mit DGLn rumspielen wollte, dann ist sowas in einem Projekt natürlich geradezu Optimal . Ausserdem gibt die ein oder andere DGL nen ganz tollen Zufallszahlengenerator für fliesskommazahlen ab - die bilder
hier oder hier sagen denke ich einiges darüber aus, was da so abgehen kann

Und wenn man sich mal ein wenig damit beschäftigt hat, dann ist numerische Mathematik an DGL eingentlich gar nicht so super kompliziert und man bekommt plötzlich Entdeckerdrang

Deine Beiträge lassen eine gewisse Begeisterung für die Problematik erkennen, und ich kann sie ganz gut nachvollziehen. Aber ich bin noch absoluter Neuling in der Grafikprogrammierung und bemühe mich, erst mal die Zusammenhänge zu verstehen. Wenn man weiß, wozu ein Schritt notwendig ist, lässt sich der Weg plausibler aufschlüsseln. Ich versuch's mal ganz einfach; wenn ich falsch denke, berichtigt mich:

1. Das DGL-Verfahren (ODE) ist ein numerisches Verfahren.
2. Numerische Verfahren kommen dann ins Spiel, wenn eine Größe berechnet werden soll, die sich nicht explizit in eine Formel auflösen lässt. Dann wird, ausgehend von einem möglichst sinnvollen Schätzwert, das Ergebnis schrittweise angestrebt, bis der Abweichungsfehler vernachlässigbar gering ist. Also eine Art "Vorwärtsberechnung".

Ich versuch mal, die Gedanken an einem ganz simplen Beispiel zu demonstrieren. Wenn ich bei gegebenem Flächeninhalt die Seite eines Rechtecks ausrechnen will, kann ich die Formel danach auflösen, etwa:

Wenn ich jetzt numerisch an die Sache herangehen würde, dann würde ich für a zunächst mal die Wurzel aus A als ersten Näherungswert einsetzen und dann nach der "Vorwärtsformel"
die Fläche berechnen, die Abweichung vom bekannten Flächeninhalt auswerten, a entsprechend korrigieren usw.

Übertragen auf das 3D-Programm: Da kommen so viele Faktoren zusammen, die sich auch wechselseitig beeinflussen, dass eine "Geradeausberechnung" ausscheidet: unterschiedliche Zeittakte, Kräfte (Bodenfriktion, Wind, Gravitation), Auswirkungen von Kollisionen usw. Das wird nun genauer zu untersuchen sein. Jedenfalls kommt keine Langeweile auf.

Danke für die Antworten
Reinhard

fast nicht ganz.
zu 1) bei DGLen handelt es sich um mathematische Gleichungen, die wie lineare Gleichungen lösbar sind, oder eben nicht. Zu gewöhnlichen Differentialgleichungen existiert eine schöne, ausgereifte mathematische Theorie. Ausserdem lassen sich gewöhnliche, eindeutig lösbare DGLn gut durch numerische Verfahren lösen. Für einen kleinen Einblick:
[link entfernt]
In diesem Skript wird in das Thema (analytisch) eingeführt, zur Numerik werden auch ein paar Worte genannt. Allein mit der Numerik beschäftigt sich z.B. das Buch "Numerik gewöhnlicher Differentialgleichungen" von Hermann.
zu 2) Ja so ist das meistens. Prinzipiell fallen aber auch Interpolationsverfahren mit Splines und ähnlichem darunter, das hat aber mit DGLn fast nichts zu tun.

Es ist aber so, daß DGLn sehr viel mit Physik zu tun haben. Es hat primär nichts mit 3D Grafik zu tun - wenn Du dich trotzdem damit beschäftigen willst, will ich dich nicht davon abhalten, aber wenn Du dich erstmal mit 3D beschäftigen willst, würde ich das Thema DGLn erstmal auf die sehr lange Bank schieben - ist nicht das übliche obwohl man es bei der heutigen Rechenleistung in Spielen durchaus verwenden könnte und bei Physikengines sicherlich stellenweise auch im Einsatz ist (Gewöhnliche Differentialgleichungen werden häufig auch als "die Klassische Mechanik" bezeichnet, wobei die Objekte/Massen oder was auch immer [bei Radioaktiven Zerfall war es die Anzahl der Atomkern] meistens als Punktförmig angesehen werden). Ich würde dir also empfehlen, DGLn erstmal aus dem Bereich Grafik zu streichen und es als Physik/Mathematik ablegen - es sprichts aber nichts dagegen sich mit DGLn zu beschäftigen und die Ergebnisse ggf. mit OpenGl darzustellen.

Das muss er sagen

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

Es bietet sich stellenweise aber auch an: wenn Du das Dreikoerprerproblem (Sonne, Erde, Jupiter z.B.) darstellst, dann laesst sich das in 3D prima darstellen - aber in dem Moment wo die Erde dann in die Sonne faellt, nicht erschrecken

...

Bruzelbruzel.