Zweidimensionaler elastischer Stoß mit Kreisen

[VIKTOR_029fb4]

Hallo,

(wo es beim Fragesteller genau gehakt hat ist unbekannt)

Es geht mir darum:
Ich möchte etwas programmieren, man kann es sich vorstellen
wie beim Billard. Eine Kugel rollt auf eine andere Kugel,
beide Kugeln bewegen sich. Jede Kugel hat eine Position (x und
y), eine bestimmte Geschwindigkeit und einen Winkel, in
welchem sie rollt,

also zuerst dies - eigentlich der letzte Schritt.
Die Kugeln haben beim Stoß die Geschwindigkeiten
1.)v1x,v1y
2.)v2x,v2y
Die Richtung ist jeweils durch tan=vy/vx bestimmt.
Du willst nach den Stoß die entsprechend veränderten
Geschwindigkeiten für jede Kugel haben.
Für den geraden Stoß weißt Du wie das geht -nehme ich an.
Wie Du die Stoßposition ermittelst - da hast Du keine Probleme -
sagst Du (unten)
Dann gibt es diese Lösung.
Du mußt die Geschwindigkeitsvektoren beider Kugeln auf die
Verbindungsachse der Stoßpositionen projezieren.Es bleiben für
jede Kugel Geschwindigkeitskomponenten „rest“, welche den
Stoßvorgang nicht beeinflussen.
(Kenntnis von Vektorenzerlegung ist hier Pflicht)
Die Richtung der Verbindungsachse ist durch die Koordinaten der
Positionspunkte mit tan=(y1-y2)/(x1-x2) bestimmbar.
Da die Richtungswinkel der Geschwindigkeitsvektoren ebenfalls
bekannt sind, sind auch die Projektionswinkel bekannt.
Die Projektionskomponenten können wie ein gerader Stoß berechnet
werden. Die Ergebnisse sind wieder in die x/y Richtung für jede
Kugel zu zerlegen und zu den „Restkomponenten“ unter Beachtung
der Vorzeichen (Achtung !)zu addieren.
Dies ist verbal die Beschreibung des Vorgangs - ohne eine
entsprechend vollständige Skizze der Stoßposition welche Du
Dir machen solltest,schlecht nachvollziehbar
Es gibt noch Vereinfachungen - aber das geht ins Detail.
Ein Berechnungsvorgang wird hier präsentiert.
http://de.wikipedia.org/wiki/Schiefer_Sto%C3%9F#Zwei…

Es gibt also eine Funktion, die zum Beispiel alle 20ms
aufgerufen wird.

Nun - die Wahl des Zeitschrittes für die Berechnung kann nicht der
Realzeit (zBsp.Microsekundenzähler des Computer-Systems)entnommen
werden, sondern muß anderen Kriterien angepaßt werden.
Wenn Du eine Realsimulation erstellen willst müßte die Laufzeit
des Programms mit dieser harmonisiert werden, was nicht ganz
einfach ist.

Diese Funktion verschiebt jeweils die Kugeln
und prüft danach, ob es eine Kollision zwischen zwei Kugeln
gibt. Das zu überprüfen ist kein Problem (wenn Distanz der
Mittelpunkte kleiner oder gleich radius*2).

Es sollte schon ziemlich genau sein.Bei flachen Stößen wird sonst
der Fehler relativ groß.

Wenn dies der Fall
ist, dann sollen jeweils die Geschwindigkeiten und Winkel
dieser beiden Kugeln entsprechen geändert werden.

So ist es.Wenn die Geschwindigkeitskomponenten geändert werden
sind die Richtungswinkel automatisch enthalten.

Ich hoffe, ich habe es verständlich ausgedrückt.

Ja, das wußte ich vorher schon.Aber an welcher Stelle es genau
bei Dir „hakt“ weiß ich nicht.
Ich nehme mal die Stoßsituation an und Du weißt Durch meinen Beitrag
vorerst Bescheid. Fang einfach an zu programmieren nachdem Du
alle Bewegungs- und Zerlegungs-gleichungen (einschl. Stoß) mal
aufgeschrieben hast.
Die Detailprobleme kommen meist dann erst.
Wenn Du Anfragen dazu hast, dann stelle diese detailliert,
verständlich und vor allem vollständig, sonst macht es keinen Sinn.
Gruß VIKTOR

[Martin]

Hallo und einen angenehmen zweiten Weihnachtsfeiertag,

Es gibt noch Vereinfachungen - aber das geht ins Detail.

und wie… das lässt sich sogar derart vereinfachen, dass man nirgendwo mehr mit einem Winkel oder einer sin/cos/tan-Funktion rechnen muss.

Ein Berechnungsvorgang wird hier präsentiert.
http://de.wikipedia.org/wiki/Schiefer_Sto%C3%9F#Zwei…

Was dort steht, sollte man schnellstens vergessen. Diese Methode der Vektorzerlegung ist unnötig kompliziert, sie enthält numerisch problematische Subtraktionen und Divisionen, bei denen der Nenner Null werden kann (sowas ist immer verdächtig). Ich rate davon ab, das so zu machen, weil es viel besser geht.

Die Aufgabe lautet, den Geschwindigkeitsvektor \vec{v} orthogonal zu zerlegen in Bezug auf den Vektor \vec{d} = \vec{r}_2 - \vec{r}_1, d. h. in einen zu \vec{d} parallelen und einen dazu senkrechten Teil. Wie man das richtig macht, nämlich über das Skalarprodukt, hat Michael doch schon gesagt:

\vec{v}^{:\rm parallel}
= \frac{\vec{v} \cdot \vec{d}}{d^2} : \vec{d}
= \frac{v_x d_x + v_y d_y}{d_x^2 + d_y^2} : \vec{d}

\vec{v}^{:\rm senkrecht} = \vec{v} - \vec{v}^{:\rm parallel}

Kurz, unproblematisch (denn das d² im Nenner ist garantiert nicht Null) und ohne Trigonometrie. \vec{v}^{:\rm senkrecht} braucht man beim Stoß übrigens nicht mal zu berechnen.

Wenn Du eine Realsimulation erstellen willst

Huch, was ist denn eine Realsimulation?

müßte die Laufzeit des Programms mit dieser harmonisiert werden, was
nicht ganz einfach ist.

Die Aussage (auch) dieses Satzes will sich mir nicht so recht entschließen…

Gruß
Martin

[Michael_Bauer_c1319c]

Ach Viktor …

Jeder versteht diesen Oberbegriff. Nur Du willst hier wieder
ein
Problem daraus machen.Wenn Du dies nicht gleich verstanden
hast war
es Dein - und nur Dein - Problem. Das willst Du hier mit
auftrumpfen
kaschieren .

Du wirfst mir vor, es fehle was.
Ich frage nach, was das wohl sei.
Du sagst: Die Bewegungsgleichungen.
Daraus entsteht eine Diskussion darueber, die sich damit in Wohlgefallen aufloest, dass sich herausstellt, dass Du damit nicht die Bewegungsgleichungen meintest, sondern die Geschwindigkeitsdefnition. Die war aber von Anfang an drin in meiner Ueberlegung.

Worueber diskutieren wir also? Du versteifst Dich darauf, dass eine falsche Bezeichnung verstaendlich sei, aber darum geht es doch gar nicht: Wenn man die Bewegungslgeichung (F=ma) nicht braucht, wo ist dann meine Loesung unvollstaendig?

Ich behaupte: Sie war es nicht. Und wenn Du immer noch behauptest, sie sei unvollstaendig, dann hast Du sie nicht verstanden.

Dein Dickkopf und Dein Stolz verbieten Dir, das einzugestehen.

Warum hast Du eigentlich ein Problem mit meinem Posting und nicht IGnow, loderunner oder Martin? Die Antwort darfst Du Dir gerne selber geben.

Michael

Glaubst Du wirklich Du kannst mich damit

beeindrucken ?
Alle anderen, welche genauso damit umgehen wie ich, sind
natürlich
Idioten, weil sie angebliche den „wissenschaftlichen“ Terminus
nicht kennen - den es garnicht gibt.
Du hast mir jedenfalls nicht gesagt, wo dies verbindlich
stehen
soll, es gibt ihn nicht.

Es geht hier nicht um das Wort.

Doch, es geht um ein Wort! Wenn Du behauptest, man bräuchte
die Bewegungsgleichungen und ich sage, man bräuchte sie nicht,
dann liegt es daran, dass wir unter dem Wort
„Bewegungsgleichung“ verschiedene Dinge verstehen.

Das ist Deine Privatsache.Andere wissen sofort was darunter zu
verstehen ist - genau meine Definition. Es ist einfach die
Deutsche Sprache.

Ich habe
versucht das zu klären. Aber Dein (Entschuldigung) Dickkopf
verbietet es Dir, einfach zu sagen: „Ja, stimmt, ich habe den
falschen Begriff verwendet. Gemeint habe ich …“

Ich kann nichts dafür, wenn Du die Fachbegriffe falsch
verwendest und dann missverstanden wirst.

Wo steht, daß eine Bewegungsgleichung nur die Grundgleichung
darstellt ?

Viktor, das ist jetzt echt lächerlich. Du hast keinen einzigen
belastbaren Beleg dafür, dass Deine Verwendung des Begriffs
„Bewegungsgleichung“ richtig ist. Was soll das also?

Du hast keine Beleg für Deinen Standpunkt.

Wenn Du
sagst, es würde gar nichts ändern, dann ist Dir der
Unterschied der beiden Lösungsstrategien überhaupt nicht
bewusst.

Die von mir verwendeten Bewegungsgleichungen nochmal:
Die Bewegungsgleichung ist wie folgt für alle Mittel-Punkte
x=X+vx*t+ax*t^2/2
y=Y+vy*t+ay*t^2/2
Was ändert dies zu Deiner Berechnung ?
t wird natürlich wie bei Dir in der „Schleife“ t=t+d_t
fortgeschrieben.Der Berechnungsgang ist hier nur weniger
anfällig
für Additionsfehler aus Rundung - ich habe dies in meinem
früheren
Beitrag schon erläutert.

Was die Genauigkeit anbetrifft hast Du vollkommen recht: Das
ist der große Nachteil von Schritt-für-Schritt-Simulationen.
Man versucht die Genauigkeit dadurch zu erhöhen, dass man das
Zeitintervall DeltaT immer kleiner macht. Dadurch wird das
Problem als solches aber nicht beseitigt.

Man kann es aber verringern. Mein Vorgehen tut dies schon mal
vorab. Ich wurde schon öfter mit solchen Problemen
konfrontiert.
Vor allem wenn man Vergleiche durchführen muß, welche
haargenau
gleich sein müssen.Es gibt programmiertechnische Trixs um
solche
Probleme anzugehen - doch dies ist ja nicht unser Thema.

Ihr großer Vorteil ist aber der, dass man die Bewegung
beschreiben kann, selbst wenn man die Gleichung für den Ort in
Abhängigkeit von der Zeit in ihrer expliziten Form gar nicht
kennt.

Das stimmt nicht. Hast noch nicht begriffen, daß prinzipiell
die Berechnung mit der Bewegungsformel die gleiche ist ob die
Distanz nun groß ist oder eine kleine „differentiale“ Größe
hat ?
Unser Vorgehen hier ist nur ein Hilfsmittel, weil wir uns
nicht
anders helfen können.

Dass Du also die Bewegungen mit den beiden Gleichungen
weiter oben angeben kannst, liegt nur daran, dass sich die
Kugeln gleichförmig bewegen…

Brauchen sie nicht, Beschleunigung ist eingearbeitet - bist Du
blind
oder schaust Dir dies nicht genau an ?
Unsere Aufgabe hier ist nur eine „Gleichzeitigkeitsproblem“ -
zur gleicher Zeit am gleichen (unbekannten) Ort.

Gib einfach mal bei Google „Bewegungsgleichung aufstellen“
ein.
Über 10000 Treffer.
Nur wegen dem von Dir oben:

Das ist Deine private, aber keinesfalls die allgemein
anerkannte Definition.

Dann schau mal nach, was bei diesen 10.000 Treffern so
geschrieben wird! Ich schließe nicht aus, dass es Menschen
gibt, die den gleichen Fehler machen wie Du, aber diejenigen,
die sich damit auskennen, verstehen unter einer
Bewegungsgleichung F = ma (bzw. diese Gleichung für ein
konkretes Problem umformuliert).

Nein Deine Formel ist hier grundsätzlich falsch. Wir haben es
hier
mit kinematischen Formeln zu tun und nicht mit dynamischen,
obwohl ich bei der Einbeziehung der Beschleunigung in der
Kinematik
auch eine Kraftwirkung sehe, eine formale Trennung also nicht
brauche - natürlich meine Privatansicht.
Auch die Umformulierung oder Erweiterung Deiner dynamischen
Grundgleichung ergibt weitere Bewegungsgleichungen.
Deine Haarspalterei, welche jeder „wissenschaftlichen“
Grundlage
entbehrt ist richtig lächerlich.

Aber ist ja auch egal, wie wir das Kind nennen

Ja, Du bist doch in die für Dich peinliche Diskussion
eingestiegen.

Die
Gleichungen, die ich ursprünglich aufgestellt habe sind (in
Verbindung mit dem Posting von IGnow) vollkommen ausreichend
für die numerische Lösung des Problems

Ich will mich nicht wiederholen. Ich habe schon ausgesagt was
an
Deiner Präsentation unvollständig war.

Ebenfalls frohe Weihnachten
Gruß VIKTOR

[VIKTOR_029fb4]

Hallo,

Es gibt noch Vereinfachungen - aber das geht ins Detail.

und wie… das lässt sich sogar derart vereinfachen, dass man
nirgendwo mehr mit einem Winkel oder einer
sin/cos/tan-Funktion rechnen muss.

so ist es, aber zur Veranschaulichung mit der gewohnten
Kräftezerlegung sollte doch erst mal dieser Weg gezeigt werden.
Die mathematische Aufbereitung ist dann ein weiterer Schritt.
Das „Skalarprodukt“ (s.unten) ist nicht besonders anschaulich.

Ein Berechnungsvorgang wird hier präsentiert.
http://de.wikipedia.org/wiki/Schiefer_Sto%C3%9F#Zwei…

Was dort steht, sollte man schnellstens vergessen.

Nein,nicht ganz.

Diese
Methode der Vektorzerlegung ist unnötig kompliziert, sie
enthält numerisch problematische Subtraktionen und Divisionen,
bei denen der Nenner Null werden kann (sowas ist immer
verdächtig). Ich rate davon ab, das so zu machen, weil es viel
besser geht.

Na prima

Die Aufgabe lautet, den Geschwindigkeitsvektor \vec{v}
orthogonal zu zerlegen in Bezug auf den Vektor \vec{d} =
\vec{r}_2 - \vec{r}_1, d. h. in einen zu \vec{d} parallelen
und einen dazu senkrechten Teil. Wie man das richtig macht,
nämlich über das Skalarprodukt, hat Michael doch schon gesagt:

\vec{v}^{:\rm parallel}
= \frac{\vec{v} \cdot \vec{d}}{d^2} : \vec{d}
= \frac{v_x d_x + v_y d_y}{d_x^2 + d_y^2} : \vec{d}

\vec{v}^{:\rm senkrecht} = \vec{v} - \vec{v}^{:\rm parallel}

Kurz, unproblematisch (denn das d² im Nenner ist garantiert
nicht Null) und ohne Trigonometrie. \vec{v}^{:\rm senkrecht}
braucht man beim Stoß übrigens nicht mal zu berechnen.

Fertig sind wir aber erst, wenn die Geschwindigkeitskomponenten
vx,vy für jedes Objekt nach dem Stoß ermittelt sind.
Ohne \vec{v}^{:\rm senkrecht} geht das nicht.
Dieser Anteil wird wieder mit dem Stoßergebnis überlagert.

Wenn Du eine Realsimulation erstellen willst

Huch, was ist denn eine Realsimulation?

Huch, Probleme mit diesem Begriff ?
Eine Realsimulation läuft auch zeitlich (Realzeit)auf dem Bildschirm
so ab wie die errechneten Zeiten dies vorgeben.
Wenn also ein Stoß nach 1.25s rechnerisch erfolgt dann tut er dies
dann auf dem Bildschirm auch.Die Strecken sind hier natürlich nicht
real darstellbar sondern in einem bestimmten Maßstab.
Nun gut - Realzeitsimulation wäre vielleicht besser ausgesagt, doch
wenn man sich nicht dumm stellt,kann man auch mit dem ersten Begriff
was anfangen.
Wenn Du trotzdem Schwierigkeiten mit den Begriffen hast,dann google
mal z.Bsp. hier:
http://realsimulation.ch/

müßte die Laufzeit des Programms mit dieser harmonisiert werden, was
nicht ganz einfach ist.

Die Aussage (auch) dieses Satzes will sich mir nicht so recht
entschließen…

Nun, dann versuche mal eine grafische Simulation (Animation)
in Realzeit zu programmieren (zBsp.einen Schwingungsvorgang)
Dann wird sich Dir diese Aussage erschließen.
Gruß VIKTOR

[VIKTOR_029fb4]

Hallo Michael,

Jeder versteht diesen Oberbegriff. Nur Du willst hier wieder
ein
Problem daraus machen.Wenn Du dies nicht gleich verstanden
hast war
es Dein - und nur Dein - Problem. Das willst Du hier mit
auftrumpfen
kaschieren .

Du wirfst mir vor, es fehle was.
Ich frage nach, was das wohl sei.
Du sagst: Die Bewegungsgleichungen.
Daraus entsteht eine Diskussion darueber, die sich damit in
Wohlgefallen aufloest, dass sich herausstellt, dass Du damit
nicht die Bewegungsgleichungen meintest, sondern die
Geschwindigkeitsdefnition.

Mir ist die Lust auf weiteren Disput vergangen.
Wo gibt es hier Geschwindigkeitsdefinitionen von mir? v=s/t ??
(auch das wäre eine Gleichung innerhalb der Kinematik)
oder v=ds/dt (Differentialquotient)
Mit Gleichungen wird gerechnet nicht mit Definitionen, egal ob sie
interativ gelöst werden oder analytisch.Dies scheinst Du nicht
zu begreifen.
Aus meinem Beitrag kopiert:
Hier müssen die „Bewegungsgleichungen“ beider Kugeln berücksichtigt
werden(Ort(x,y) = Funktion von Zeit)welche unabdingbar sind.
Deine Antwort:
Sie sind sehr wohl abdingbar.
Belassen wir es dabei.Da fällt mir nix mehr ein.
Gruß VIKTOR

Die Bewegungsgleichung ist wie folgt für alle Mittel-Punkte
x=X+vx*t+ax*t^2/2
y=Y+vy*t+ay*t^2/2

Ortsveränderung in der Zeit - das ist Bewegung, v oder a sind
Größen innerhalb der Gleichungen.
Nochmals aus Wiki:
Die Kinematik (gr.: kinema, Bewegung) ist die Lehre der Bewegung von Punkten und Körpern im Raum, beschrieben durch die Größen Weg s (Änderung der Ortskoordinate), Geschwindigkeit v und Beschleunigung a,

[Michael_Bauer_c1319c]

Hier müssen die „Bewegungsgleichungen“ beider Kugeln
berücksichtigt
werden(Ort(x,y) = Funktion von Zeit)welche unabdingbar sind.
Deine Antwort:
Sie sind sehr wohl abdingbar.

Wenn Du mit Bewegungsgleichung F = ma meintest: Das braucht man nicht (in diesem Fall, weil es abgesehen vom Stoß kräftefrei ist und der Stoß selbst wird als instantan angesehen).

Wenn Du mit Bewegungsgleichung eine explizite Funktion der Zeit meinst, die den Ort der Kugel angibt: Die braucht man auch nicht, denn die Position der Kugeln wird durch die Simulation ja berechnet.

Wenn Du mit Bewegungsgleichung die Definition der Geschwindigkeit meinst (v = dx/dt): Die ist in der Tat unabdingbar. Sie war aber von Anfang an in meinen Überlegungen mit drin, und zwar in der Gestalt von Pos1 = Pos1 + v1*DeltaT (vektoriell). Ich gebe zu, dass diese Zeile in meinem ursprünglichen Vorschlag noch nicht vorkam. Ich hielt sie aber für selbstverständlich.

Für David war hier auch nicht das Problem, wie durch sein späteres Posting klar wurde:

„Es gibt also eine Funktion, die zum Beispiel alle 20ms aufgerufen wird. Diese Funktion verschiebt jeweils die Kugeln und prüft danach, ob es eine Kollision zwischen zwei Kugeln gibt. Das zu überprüfen ist kein Problem (wenn Distanz der Mittelpunkte kleiner oder gleich radius*2). Wenn dies der Fall ist, dann sollen jeweils die Geschwindigkeiten und Winkel dieser beiden Kugeln entsprechen geändert werden.“

Statt einfach nur die Zeile zu ergänzen, wirfst Du mir vor - ohne dafür einen Anhaltspunkt dafür zu haben - dass ich die Lösung nicht abliefern könne. Denn eigentlichen Kern der Lösung (das mit dem Skalarprodukt) hast Du dabei jedoch nie verstanden.

Belassen wir es dabei.Da fällt mir nix mehr ein.

Dann ist ja gut.

Michael

[Michael_Bauer_c1319c]

Hallo David!

Schau Dir mein Posting vom 22.12. nochmal genau an und frag nach, wenn Du daran etwas nicht verstehst. Gegebenenfalls hilft Dir auch das Posting von Martin, das inhaltsgleich aber anders formuliert ist.

Gruß, Michael

[VIKTOR_029fb4]

Hallo,

Wenn Du mit Bewegungsgleichung eine explizite Funktion der
Zeit meinst, die den Ort der Kugel angibt: Die braucht man
auch nicht, denn die Position der Kugeln wird durch die
Simulation ja berechnet.

ich steige nochmals ein.
Es ist nicht zu fassen !
Was ist denn die Basis dieser iterativen Berechnung ?
Irgendeine geheimnisvolle „Simulation“ ? Quatsch.
Wenn Du den Ort über deltaT verschiebst dann mit den gleichen
Gleichungen wie x=X+vx*t,( t=t+dt) bei Dir POS=POS+v*deltaT.
Es ist einfach lächerlich wie Du hier etwas hinweg diskutieren
willst.Ohne diese Orts- Geschwindigkeits- Zeit-Beziehung geht garnix

Wenn Du mit Bewegungsgleichung die Definition der
Geschwindigkeit meinst (v = dx/dt): Die ist in der Tat
unabdingbar. Sie war aber von Anfang an in meinen Überlegungen
mit drin, und zwar in der Gestalt von Pos1 = Pos1 + v1*DeltaT

Quatsch.Hier wird ein Ort(x,y) errechnet mit v und t.
Ich habe mehrfach gesagt was ich meine - deutlich.
Was soll diese Pseudo-Hinterfragung , was ich wohl gemeint haben
könnte ? Du weißt genau was gemeint war, hast Dich verrannt mit
sinnloser Kritik und willst dies kaschieren.

(vektoriell). Ich gebe zu, dass diese Zeile in meinem
ursprünglichen Vorschlag noch nicht vorkam. Ich hielt sie aber
für selbstverständlich.

Offensichtlich nicht.Denn nur sie ermöglicht, auch Beschleunigung
einzubauen.Dies geht natürlich auch indirekt, indem man v als
Variable gestaltet und mit jedem Schritt fortschreibt, wie Du dies
ja auch später angegangen bist.(Mehraufwand ?)
Der formale(und auch praktische)Fehler liegt aber darin, daß dies
zwar bei der Integralrechnung funktioniert, wenn man eine explizite
Lösung anbieten kann - wir können dies hier nicht.
Ansonsten ist schon die Positionsbestimmung mit einem Fehler
behaftet da der Anteil des Weges aus Beschleunigung eben
deltaS=a*deltaT^2/2 beträgt.
Sicher ist dies je nach Aufgabenstellung oft vernachlässigbar.
Aber jede Präsentation ist unvollständig und gebiert Fehler
wenn nicht auch, wie hier, die vollständigen Ausgangs-
Gleichungen angegeben werden.

Für David war hier auch nicht das Problem, wie durch sein
späteres Posting klar wurde:
Statt einfach nur die Zeile zu ergänzen, wirfst Du mir vor -
ohne dafür einen Anhaltspunkt dafür zu haben - dass ich die
Lösung nicht abliefern könne. Denn eigentlichen Kern der
Lösung (das mit dem Skalarprodukt) hast Du dabei jedoch nie
verstanden.

Binomische Formeln sind formal ja auch „Skalarprodukte“
(x1-x2)^2+(y1-y2)^2=x1^2-2*x1*x2+x2^2 + y1^2-2*y1*y2+y2^2
Daraus die Wurzel= Abstand
Deine „Berechnung“
Skalarprodukt := x(1) * y(1) + x(2) * y(2)
Betrag := Wurzel(Skalarprodukt(x,x))
Abstand := Betrag(y-x)
habe ich tatsächlich nicht verstanden oder ist dies Dein erwähnter
Pseudo-Cod.
Jedenfalls ist x1*y1+x2*y2 nicht (x1-x2)^2+(y1-y2)^2.
Der „Kern“ der Lösung ist dies nun wirklich nicht sondern nur
Abstandsberechnung der Positionen, welche mit dem Pythagoras
anschaulicher ist.

Gruß VIKTOR

[DrStupid]

Was dort steht, sollte man schnellstens vergessen.

Nicht alles. Der Ansatz über die Erhaltungssätze ist völlig in Ordnung. Damit kommt man recht schnell zu den gesuchten Gleichungen. Da der Spezialfall für gleiche Massen bereits mehrfach vorgerechnet wurde, mache ich das hier mal für unterschiedliche Massen. Um die Impulserhaltung zu gewährleisten, nehme ich an, dass beim Stoß ein bestimmter Impuls \Delta \vec p von einer Kugel auf die andere übertragen wird. Das führt schon mal zu

\vec v’_1 = v_1 - \frac{{\Delta \vec p}}{{m_1 }}

und

\vec v’_2 = v_2 + \frac{{\Delta \vec p}}{{m_2 }}

Wenn es sich um glatte Kugeln handelt, hat der übertragene Impuls keine Tangentialkomponente:

\Delta \vec p: = k \cdot \Delta \vec r

(mit \Delta \vec r: = \vec r_2 - \vec r_1)

Dieser Schritt ersetzt die in den bereits geposteten Ansätzen erfolgte Zerlegung der Geschwindigkeiten in Radial- und Tangentialteil und erfüllt ganz nebenbei die Drehimpulserhaltung. Die Energieerhaltung

{\textstyle{1 \over 2}}m_1 \cdot \vec v_1^2 + {\textstyle{1 \over 2}}m_2 \cdot \vec v_2^2 = {\textstyle{1 \over 2}}m_1 \cdot \left( {\vec v_1 - \frac{{k \cdot \Delta \vec r}}{{m_1 }}} \right)^2 + {\textstyle{1 \over 2}}m_2 \cdot \left( {\vec v_2 + \frac{{k \cdot \Delta \vec r}}{{m_2 }}} \right)^2

liefert schließlich den noch fehlenden skalaren Faktor

k = - 2 \cdot \frac{{m_1 \cdot m_2 }}{{m_1 + m_2 }} \cdot \frac{{\Delta \vec r \cdot \Delta \vec v}}{{\Delta \vec r^2 }}

(mit \Delta \vec v: = \vec v_2 - \vec v_1)

[Martin]

Hallo,

so ist es, aber zur Veranschaulichung mit der gewohnten
Kräftezerlegung sollte doch erst mal dieser Weg gezeigt werden.
Die mathematische Aufbereitung ist dann ein weiterer Schritt.

Ich denke, man versucht besser, gleich eine einfache Lösung zu finden, statt bewusst einen Umweg über eine komplizierte Zwischenstufe zu wählen. Solche Zwischenstufen können leicht so komplex werden, dass daraus einfachere Lösungen gar nicht mehr zu gewinnen sind. Wer bei dem Stoßproblem hier anfängt, mit Winkeln zu hantieren, hat gute Chancen, in diese Falle zu tappen. Wahrscheinlich wird er bald mit irgendwelchen trigonometrischen Additionstheoremen operieren, viele Seiten mit immer wüsteren Formeln vollschreiben, und schließlich in dem Glauben, das Problem sei wahnsinnig schwierig, aufgeben.

Das „Skalarprodukt“ (s.unten) ist nicht besonders anschaulich.

Remember: \vec{a} \cdot \vec{b} ist letztlich nur eine Abkürzung für a b \cos \varphi mit φ = der von den Vektoren eingeschlossene Winkel. Wie lang der gesuchte Projektionsvektor
\vec{v}^{:\rm parallel} ist, weiß man (v cos α lang) und wohin er zeigt, auch (da wo \vec{d} hin zeigt). Damit ist die Sache klar:

\vec{v}^{:\rm parallel}
= v \cos \alpha :\frac{\vec{d}}{d}
= \frac{v d \cos \alpha}{d^2} :\vec{d}
= \frac{\vec{v} \cdot \vec{d}}{d^2} : \vec{d}

Projektion, Kosinus und Skalarprodukt gehören so stark zusammen, dass man am besten immer sofort auch an die anderen beiden Begriffe denkt, wenn man einen davon hört oder liest.

Ohne \vec{v}^{:\rm senkrecht} geht das nicht.

Doch, das geht ohne. Bei einem Stoß gegen eine Wand ist die Geschwindigkeit nach dem Stoß einfach

\vec{v}:’ = \vec{v} - 2 \vec{v}^{:\rm zentral}

(Skizze malen und sehen!) Warum soll ich mich um den Tangentialteil kümmern, wenn mit dem beim Stoß garnix passiert? Du willst wahrscheinlich erst v^zentral und v^tangential berechnen, danach v^zentral zu –v^zentral umklappen und schließlich wieder v^tangential dazuaddieren. Das geht, aber statt erst v^tangential aus v rauszuziehen um es am Schluss unverändert wieder hinzuzufügen, kann man es genausogut auch gleich in v drinlassen, und dann braucht man es nicht mehr berechnen.

Beim Kugel-Kugel-Stoß kommt dann noch ein Summand dazu:

\vec{v}:’ = \vec{v} - 2 (\vec{v}^{:\rm zentral} - \vec{v}_S^{:\rm zentral})

worin der dazugekommene Summand

\vec{v}_S^{:\rm zentral}

\frac{m_1 \vec{v}_1^{:\rm zentral} + m_2 \vec{v}_2^{:\rm zentral}}
{m_1 + m_2}

der Zentralteil der Schwerpunktsgeschwindigkeit ist. Die zentrale Richtung ist beim Kugel-Wand-Stoß die senkrecht zur Wand, und beim Kugel-Kugel-Stoß die der Mittelpunkts-Verbindungslinie.

Eine Realsimulation läuft auch zeitlich (Realzeit)auf dem
Bildschirm so ab wie die errechneten Zeiten dies vorgeben.

Was für errechnete Zeiten? Der Sinn solcher Simulationen liegt doch gerade darin, keine Zeiten berechnen zu müssen, weil das zu kompliziert oder sogar unmöglich ist.

Wenn also ein Stoß nach 1.25s rechnerisch erfolgt dann tut er
dies dann auf dem Bildschirm auch.

Na klar, aber das ist doch selbstverständlich. Wenn ich beispielsweise ein Fadenpendel mit einem 158 cm langen Faden simulieren möchte, dann will ich, dass der Punkt auf dem Bildschirm synchron läuft mit einem echten 158 cm-Pendel, das an der Decke herabhängend vor dem Monitor hin- und herschwingt. Ich will im Code eine Variable g und eine Variable l haben, die ich auf 9.81 bzw. 1.58 setze, und erwarte, dass der Punkt auf dem Bildschirm dann mit der korrekten Periodendauer T = 2 π/√(g/l) = 2.52 Sekunden harmonisch schwingt, ohne dass im Programmcode irgendwo ein sin oder cos oder der Wert 2.52 steht. Ich wüsste aber nicht, was daran schwer sein soll, das zu erreichen.

Die Strecken sind hier natürlich nicht real darstellbar sondern in
einem bestimmten Maßstab.

Wieso nicht? Wenn man weiß wieviele Bildschirmpixel auf einen Meter kommen, kann man sogar Strecken real darstellen (was natürlich keinen Sinn macht, wenn die zu groß oder zu klein für den Monitor sind. Dann skaliert man die Ausgabe passend). Es sind übrigens ungefähr 2600 bis 2800 (Rechenbeispiel: Auflösung 1280x720 und 48 cm Displaybreite ergibt 1280/0.48 = 2666 Pixel pro Meter).

Nun, dann versuche mal eine grafische Simulation (Animation)
in Realzeit zu programmieren (zBsp.einen Schwingungsvorgang)

Ich habe den Code unten angehängt. Ist für Delphi, aber auch auf jedes andere Pascal leicht anpassbar.

Gruß
Martin

UNIT Form\_Main;

INTERFACE

uses
 Windows, Messages, Classes, Graphics, Controls, Forms,
 ExtCtrls, ComCtrls, Menus, SVATimer;

type
 TFormMain
 = class(TForm)
 StatusBar: TStatusBar;
 Panel1: TPanel;
 PaintBox: TPaintBox;

 procedure FormCreate (Sender: TObject);
 procedure FormDestroy (Sender: TObject);
 procedure TimerTick (Sender: TObject);
 procedure PaintBoxPaint (Sender: TObject);

 private
 Timer: TSVATimer;

 PixelPerMeter: DOUBLE;

 FactorT: DOUBLE; // time scale factor
 FactorL: DOUBLE; // length scale factor

 g : DOUBLE; // gravity strength
 l : DOUBLE; // pendulum length
 x : DOUBLE; // position
 v : DOUBLE; // velocity
 a : DOUBLE; // acceleration
 dt: DOUBLE; // time step
 end;


var
 FormMain: TFormMain;


IMPLEMENTATION

{$R \*.dfm}

procedure TFormMain.FormCreate (Sender: TObject);
begin
 Timer := TSVATimer.Create(NIL);
 Timer.OnTimer := TimerTick;

 // set refresh rate to 40/s
 // interval of class TTimer has unit millisec
 Timer.Interval := 25;
 Timer.Enabled := TRUE;

 PixelPerMeter := 2600;

 FactorT := 1.0;
 FactorL := 1.0;

 // start position and velocity
 x := 0.1;
 v := 0.0;
end;


procedure TFormMain.FormDestroy (Sender: TObject);
begin
 Timer.Destroy
end;


procedure TFormMain.TimerTick (Sender: TObject);
begin
 g := 9.81;
 l := 1.58;
 dt := FactorT\*0.001\*Timer.Interval;
 a := -(g/l)\*x;
 v := v + a\*dt;
 x := x + v\*dt;
 PaintBox.Invalidate
end;


procedure TFormMain.PaintBoxPaint (Sender: TObject);
var px, py: INTEGER;
begin
 px := 300 + Round(FactorL\*PixelPerMeter\*x);
 py := 300;
 PaintBox.Canvas.Ellipse(px-5, py-5, px+5, py+5)
end;

END.

[Martin]

Hallo,

Nicht alles. Der Ansatz über die Erhaltungssätze ist völlig in Ordnung.

selbstverständlich. Gegenstand meiner Kritik war nur die im Anfangsteil im Abschnitt „Zweidimensionaler elastischer Stoß“ angegebene Methode der Orthogonalzerlegung der Geschwindigkeitsvektoren.

und erfüllt ganz nebenbei die Drehimpulserhaltung.

Sehr interessant! Ich habe den Drehimpulsen bisher keine Aufmerksamkeit geschenkt, werde mir aber über diesen Aspekt noch Gedanken machen.

Gruß
Martin

[DrStupid]

Es gibt also eine Funktion, die zum Beispiel alle 20ms
aufgerufen wird. Diese Funktion verschiebt jeweils die Kugeln
und prüft danach, ob es eine Kollision zwischen zwei Kugeln
gibt.

Bei wenigen Kugeln funktioniert das sehr gut. Aber je mehr es werden, um so größer wird die Wahrscheinlichkeit, dass eine oder mehrere innerhalb der 20 ms gleich mehrmals kollidieren. In dem Fall geht die Simulation gegen den Baum. Um das zu verhindern, darf die Schrittweite höchstens so groß werden, wie die Zeit bis zur nächsten Kollision. Dann ist auch sowas kein Problem mehr:

Achtung: Bitte nicht direkt im Browser öffnen (mein Opera stürzt dabei ab), sondern über Kontextmenü (rechte Maustaste) herunterladen:

http://www.drstupid.de/temp/6401Spheres.mp4

[DrStupid]

und erfüllt ganz nebenbei die Drehimpulserhaltung.

Sehr interessant! Ich habe den Drehimpulsen bisher keine
Aufmerksamkeit geschenkt, werde mir aber über diesen Aspekt
noch Gedanken machen.

Urprünglich dachte ich, dass ich die Drehimpulserhaltung extra berücksichtigen muss, weil ich das von anderen starren Körpern (z.B. zusammenstoßenden Würfeln) so in Erinnerung hatte, aber als ich dann \Delta \vec p: = k \cdot \Delta \vec r in die Drehimpulserhaltung eingesetzt hatte:

m_1 \cdot \vec r_1 \times \vec v_1 + m_2 \cdot \vec r_2 \times \vec v_2 = m_1 \cdot \vec r_1 \times \left[{\vec v_1 - k \cdot \frac{{\vec r_2 - \vec r_1 }}{{m_1 }}} \right] + m_2 \cdot \vec r_2 \times \left[{\vec v_2 + k \cdot \frac{{\vec r_2 - \vec r_1 }}{{m_1 }}} \right]

habe ich überrascht festgestellt, dass das immer gilt. Nach kurzem Nachdenken ging mir aber auf, dass das ohne tangentiale Kraftkomponente kein Drehmoment wirkt. Das kommt erst ins Spiel, wenn zwischen den Kugeln Reibungskräfte wirken.

[Michael_Bauer_c1319c]

Hallo!

Wenn Du den Ort über deltaT verschiebst dann mit den gleichen
Gleichungen wie x=X+vx*t,( t=t+dt) bei Dir POS=POS+v*deltaT.
Es ist einfach lächerlich wie Du hier etwas hinweg diskutieren
willst.Ohne diese Orts- Geschwindigkeits- Zeit-Beziehung geht
garnix

Was Du anscheinend immer noch nicht begriffen hast oder begreifen willst:

1. v = ds/dt ist die Definition der Geschwindigkeit und gilt für jede Bewegung, die es überhaupt gibt.

2. s = 1/2 at² + v0 * t + s0 ist das Weg-Zeit-Gesetz für eine gleichmäßig beschleunigte Bewegung (oder falls a=0 für den Spezialfall gleichförmige Bewegung). Mathematisch handelt es sich dabei um die Lösung der Differenzialgleichung ma = const. unter den Anfangsbedingungen v(t=0) = v0 und s(t=0) = s0.

Gleichung 1) brauche ich in jeder kinematischen Simulation, weil ich dem Computer erklären muss, was ich mit Geschwindigkeit meine. Ich werde diese Gleichung verwenden, egal, ob es sich um Würfe, Planetenbewegungen, Schwingungen oder - wie in diesem Fall - Stöße handelt.

Gleichung 2) gilt nur für den Fall, dass ich eine konstante äußere Kraft oder gar keine äußere Kraft habe. In den allermeisten Fällen kann ich sie gar nicht verwenden, in diesem Fall muss ich sie nicht verwenden.

Ansonsten ist schon die Positionsbestimmung mit einem Fehler
behaftet da der Anteil des Weges aus Beschleunigung eben
deltaS=a*deltaT^2/2 beträgt.

Nein. Fangen wir mal beim Urschleim an: Die Grundidee der Differenzialrechnung ist, dass man jede Kurve - und sei sie noch so kompliziert - mit beliebiger Genauigkeit durch eine Gerade annähern kann, wenn man nur die Intervalle hinreichend klein (mathematisch: infinitesimal klein) wählt.

Oder anders ausgedrückt: Für hinreichend kleine Zeitintervalle kann man jede Kurve durch ein Polynom annähern, wobei nur das Absolutglied und das lineare Glied einen Beitrag liefern, während alle anderen Terme gegen Null streben. (Insofern ist die von Dir hier genannte Gleichung „deltaS=a*deltaT^2/2“ nicht nur unnötig, sondern sogar falsch).

Binomische Formeln sind formal ja auch „Skalarprodukte“
(x1-x2)^2+(y1-y2)^2=x1^2-2*x1*x2+x2^2 + y1^2-2*y1*y2+y2^2
Daraus die Wurzel= Abstand
Deine „Berechnung“
Skalarprodukt := x(1) * y(1) + x(2) * y(2)
Betrag := Wurzel(Skalarprodukt(x,x))
Abstand := Betrag(y-x)
habe ich tatsächlich nicht verstanden oder ist dies Dein
erwähnter
Pseudo-Cod.
Jedenfalls ist x1*y1+x2*y2 nicht (x1-x2)^2+(y1-y2)^2.

Soll ich Dir nun eine Nachhilfestunde in Vektorrechnung und Programmierung geben oder was soll das werden?

Ich habe zwei Vektoren:

x := (x(1), x(2)) und y := (y(1), y(2))

Von denen bilde ich die Differenz

d := (d(1), d(2)) = (y(1)-x(1), y(2)-y(2))

Nun bilde ich davon den Betrag. Das kann ich entweder müßsam über den Pythagoras machen (wie Du) oder elegant mit dem Skalarprodukt:

|d| = √Skalarprodukt(d,d) = √(d(1) * d(1) + d(2) * d(2))

(Wenn Du es mir nicht glaubst, kannst Du gerne mal d(1) und d(2) einsetzen und das Ganze ausmultiplizieren. Es kommt das gleiche raus, wie bei Deiner Pythagoras-Methode - ganz ohne binomische Formeln!)

Der „Kern“ der Lösung ist dies nun wirklich nicht sondern nur
Abstandsberechnung der Positionen, welche mit dem Pythagoras
anschaulicher ist.

Das ist vielleicht die Geschmackssache. Ich behauptete auch nicht, dass dies der Kern meiner Lösung ist, sondern die Projektion der Geschwindigkeiten:

v1_ax = (v1 * eDif) * eDif

Nochmal langsam für Dich:

Die beiden Mittelpunkte haben die Koordinaten

Pos1 := (Pos1(1), Pos1(2)) und Pos2 := (Pos2(1), Pos2(2))

Man bilde den Differenzvektor …

Dif := (Dif(1), Dif(2)) = (Pos2(1) - Pos1(1), Pos2(2) - Pos2(1))

… und normiere ihn …

eDif := (eDif(1), eDif(2)) = (Dif(1)/|Dif|, Dif(2)/|Dif|)

… wobei man den Betrag |Dif| berechnet wie oben beschrieben.

Der Richtungsvektor eDif wird nun für die Komponentenzerlegung von v1 verwendet. Dabei gibt eDif die Richtung der axialen Geschwindigkeitskomponente vor und das Skalarprodukt aus eDif und v1 den Betrag dieser Geschwindigkeitskomponente. Mathematisch spricht man hier auch von einer orthogonalen Projektion. In Vektorschreibweise sieht das so aus:

v1_ax = Skalarprodukt(v1, eDif) * eDif

… in Komponentenschreibweise so:

v1_ax(i) = (v1(1) * eDif(1) + v1(2) * eDif(2)) * eDif(i) |i = 1,2

Martin hat das alles ganz hübsch in seinem Posting in Latex gesetzt. Das kann ich aber nicht. (Bei ihm heißt axial = parallel und tangential = senkrecht).

Ach ja, eh ich’s vergesse: Die tangentiale Komponente erhält man entweder, indem man einen Normalenvektor zu eDif bildet und dann erneut die orthogonale Projektion durchführt, oder man macht sich einfach zunutze, dass die tangentiale Komponente das ist, was übrig bleibt, wenn man vom Geschwindigkeitsvektor die axiale Komponente abzieht:

v1_tan = v1 - v1_ax (vektoriell)

Mit dem Vektor v2 verfährt man genau gleich.

Nun hat man das Rüstzeug, das man braucht, um die Folgen der Kollision zu berechnen. IGnow hat schon ganz zu Anfang geschrieben, dass dies für den fall von gleich großen Kugeln gleicher Masse sehr einfach ist: Die axialen Geschwindigkeitskomponenten werden vertauscht, die tangentialen werden beibehalten.

(Beachte bei dieser ganzen Betrachtung, dass Ziffern in Klammern die unterschiedlichen Komponenten des Vektors angeben, während Ziffern außerhalb der Klammern die Vektoren nummerieren:

v(1) und v(2) sind die beiden Komponenten des Vektors v
v1 und v2 sind zwei verschiedene Vektoren!)

Wenn noch etwas unklar ist, kannst Du gerne nachfragen, aber fang nicht mehr an, mir Dein eigenes Unwissen vorzuwerfen.

Michael

[DrStupid]

Die Grundidee der
Differenzialrechnung ist, dass man jede Kurve - und sei sie
noch so kompliziert - mit beliebiger Genauigkeit durch eine
Gerade annähern kann, wenn man nur die Intervalle hinreichend
klein (mathematisch: infinitesimal klein) wählt.

Man muss hier allerdings dazu sagen, dass das nur bei stetig differenzierbaren Funktionen funktioniert und die Kurven, der zwei starre Kugeln folgen, erfüllen diese Bedingung zum Zeitpunkt ihres Zusammenstoßes leider nicht. Bei diesem Problem stößt die Differentialrechnung an ihre Grenzen. Anders sieht das bei meinem zweiten Ansatz aus, den ich oben gepostet habe.

[Michael_Bauer_c1319c]

Hallo1!

Ja, das ist klar. Hier ging es aber über die Beschreibung der Bewegung, nicht um das Stoßereignis selbst.

Wie man das Problem umgeht hat … wer war’s? Ich glaube: loderunner in einem früheren Posting erörtert: Entweder man behandelt das Stoßereignis separat davon, z. B. in einem Unterprogramm (evtl. so wie ich das gemacht habe) oder man sorgt dafür, dass die Bahnkurven differenzierbar werden, indem man die Stoßpartner nicht als starr ansieht, sondern sie durch einen bestimmten Potenzialverlauf darstellt.

Michael

[VIKTOR_029fb4]

Hallo,

so ist es, aber zur Veranschaulichung mit der gewohnten
Kräftezerlegung sollte doch erst mal dieser Weg gezeigt werden.
Die mathematische Aufbereitung ist dann ein weiterer Schritt.

Ich denke, man versucht besser, gleich eine einfache Lösung zu
finden, statt bewusst einen Umweg über eine komplizierte
Zwischenstufe zu wählen.

darum geht es doch nicht.Für eine elegante mathematische Lösung
hast natürliche Du (und auch die anderen) recht.
Das ist letztendlich das Ziel.
Eine solche Lösung setzt aber erst einmal entsprechende mathemat.
Kenntnisse voraus und einigen mathematischen Formalismus, welcher
meist eben nicht anschaulich ist.Die Fragesteller hier erwarten
wohl eine solche Anschaulichkeit. Wenn sie wissen würden wie es
geht und im mathemat. Formalismus bewandert wären, brauchten sie
keine Fragen zu stellen.Komplexe mathemat. Formeln sind meist nie
anschaulich(nur für geübte Mathe-Spezialisten).Ihre Präsentation
hat auch noch kaum einen Fragesteller hier „schlau“ gemacht weil
seine „Verständnissuche“ meist elemetarer war.
Die Reaktionen (oder nicht Reaktionen) der Fragesteller hier am
Brett hast Du ja auch verfolgen können.

Das „Skalarprodukt“ (s.unten) ist nicht besonders anschaulich.

Projektion, Kosinus und Skalarprodukt gehören so stark
zusammen, dass man am besten immer sofort auch an die anderen
beiden Begriffe denkt, wenn man einen davon hört oder liest.

Ja - der Kosinussatz hat ja formal ein ähnliches Bild.

Eine Realsimulation läuft auch zeitlich (Realzeit)auf dem
Bildschirm so ab wie die errechneten Zeiten dies vorgeben.

Was für errechnete Zeiten? Der Sinn solcher Simulationen liegt
doch gerade darin, keine Zeiten berechnen zu müssen, weil das
zu kompliziert oder sogar unmöglich ist.

Eine Realsimulation mit Animation macht dies aber.Die errechneten
Zeiten für einen animierten Bewegungsschritt müssen bei der
grafischen Ausgabe (z,Bsp. einer „Virtuellen Maschine“)eben der
Systemzeit des Computer entnommen werden, dh. dort abgefragt
werden.
Dies geht so, daß ich entweder alle Orts-Daten der Bewegung vorher
berechne, in einer Datei ablege und in Realzeit ausgebe (was kaum
machbar ist für aufwändige Animationen)oder die Systemzeit ständig
in der Laufzeit abfrage.
Die Laufzeit des Programms für eine Positionsberechnung ist entweder
bedeutend schneller als der gewünschte darzustellende Zeitschritt,
dann muß ich in die Laufzeit „Warteschleifen“ einbauen, oder die
Berechnung aller Daten zu Ausgabe eines Bildes zu einer realen Zeit
braucht länger als der gewünschte Zeitschritt. Um dies alles zu
harmonisieren, dann sind wohl Spezialisten gefragt welche dies auch
in Assembler realisieren können. Schnelle Rechner, gut Grafikkarten
usw. natürlich auch.
Du hast ja unten einen Weg aufgezeigt.
Es gehört wohl mehr dazu, als nur mal die Timer-Abfrage aus der
Sytemzeit zur Bestimmung des Zeitpunktes der grafischen Ausgabe.

Wenn also ein Stoß nach 1.25s rechnerisch erfolgt dann tut er
dies dann auf dem Bildschirm auch.

Na klar, aber das ist doch selbstverständlich.

Warum hältst Du dann hier dagegen ?
Aber auch nicht jede Animation muß in Realzeit präsentiert werden.

Ich wüsste
aber nicht, was daran schwer sein soll, das zu erreichen.

Schwer ist relativ - und von der Aufgabe abhängig.

Die Strecken sind hier natürlich nicht real darstellbar sondern in
einem bestimmten Maßstab.

Wieso nicht? Wenn man weiß wieviele Bildschirmpixel auf einen
Meter kommen, kann man sogar Strecken real darstellen (was
natürlich keinen Sinn macht, wenn die zu groß oder zu klein
für den Monitor sind. Dann skaliert man die Ausgabe passend).

Was hältst Du schon wieder dagegen ?
Das sagt doch in „einem bestimmten Maßstab“ - ohne unnötige lange
Rede, ist das so unverständlich ?

Nun, dann versuche mal eine grafische Simulation (Animation)
in Realzeit zu programmieren (zBsp.einen Schwingungsvorgang)

Ich habe den Code unten angehängt. Ist für Delphi, aber auch
auf jedes andere Pascal leicht anpassbar.

Danke, daß Du Dir die Mühe gemacht hast. Es geht aber an der Sache vorbei.
Erstens kann ich nicht jeden Code sofort verstehen (kann nur etwa
2-3 Programmiersprachen)weshalb ich dies hier nicht durchgehend
aufnehmen will. Zweitens weiß ich wie dies prinzipiell geht
(s.oben) und deshalb auch,daß die Harmonisierung eben nicht so ohne
weiteres gelingt.Für das einfache Pendel eventuell schon.
Ich hatte es mal versucht für einen „Saitenschwinger“ , welcher ja
unter Beschleunigung seine Frequenz verändert.Eine
Realzeitanimation ist mir mit meinen Bordmitteln nicht ganz
gelungen(ist auch schon länger her).
Gruß VIKTOR

[Martin]

Hallo,

darum geht es doch nicht.Für eine elegante mathematische
Lösung hast natürliche Du (und auch die anderen) recht.

das wollten wir hören
(Kleiner Scherz…)

Komplexe mathemat. Formeln sind meist nie
anschaulich(nur für geübte Mathe-Spezialisten).Ihre
Präsentation hat auch noch kaum einen Fragesteller hier „schlau“
gemacht weil seine „Verständnissuche“ meist elemetarer war.

Da ist wohl was Wahres dran. Wäre mal interessant zu erfahren, ob dem Fragesteller hier diese Diskussion letztlich was gebracht hat.

Die Laufzeit des Programms für eine Positionsberechnung ist entweder
bedeutend schneller als der gewünschte darzustellende Zeitschritt,
dann muß ich in die Laufzeit „Warteschleifen“ einbauen, oder die
Berechnung aller Daten zu Ausgabe eines Bildes zu einer realen Zeit
braucht länger als der gewünschte Zeitschritt.

Ahhh… jetzt verstehe ich! Richtig: Wenn man z. B. einen Flugsimulator programmieren will, dann darf man nicht zuviele und will nicht zuwenige Details berechnen. Zuviele nicht, weil sonst der Prozessor eventuell nicht fertig ist, wenn der nächste Frame auf den Monitor muss, und zuwenige nicht, um keine Rechenpower zu verschenken. Man muss deshalb irgendwie rausbekommen, welche Szeneriekomplexität man sich ungefähr leisten kann. Hier kombiniert man verschiedene Konzepte. Einen groben Anhaltswert kann man erstmal durch Messung gewinnen. Dann gibt man dem Prozessor absichtlich immer ein bisschen zu wenig zu tun, um noch Luft für unvorhergesehene Extrabelastungen zu haben. Wird er trotzdem mal kurzzeitig überfordert, nimmt man das einfach in Kauf (dann ruckelt die Simulation ein bisschen). Alles zusammen ergibt eine akzeptable Lösung. „Weiches“ Echtzeitsystem nennt man sowas.

Bei der Fadenpendel-Simulation bleibt man von dieser Problematik von vornherein verschont, weil es bei einem einzigen Massenpunkt ja fast nix zu rechnen gibt. Das kann sich allerdings schnell ändern, z. B. wenn man eine aus sehr vielen Massepunkten modellierte Saite simulieren will.

Warum hältst Du dann hier dagegen ?

Es war eher als Bestätigung gemeint

Zweitens weiß ich wie dies prinzipiell geht
(s.oben) und deshalb auch,daß die Harmonisierung eben nicht so
ohne weiteres gelingt.Für das einfache Pendel eventuell schon.

Ich habe in meinem Beispielprogramm einfach einen Timer (im Code: „Timer“) installiert, der alle 25 ms „feuert“ und dadurch die mit diesem Event verknüpfte Prozedur „TimerTick“ periodisch aufruft. 25 ms ist für die darin stattfindende Mini-Berechnung eine Ewigkeit.

Ich hatte es mal versucht für einen „Saitenschwinger“ ,
welcher ja unter Beschleunigung seine Frequenz verändert. Eine
Realzeitanimation ist mir mit meinen Bordmitteln nicht ganz
gelungen(ist auch schon länger her).

Du denkst an die Echtzeitsimulation einer mit akustischen Frequenzen schwingenden Saite? Das wäre Physical Modeling - ein junges und spannendes Gebiet. Sag Bescheid, wenn Du die Saite hörst.

Gruß
Martin