Teilchensimulator in Echtzeit

[Minz]

Hallösche,

ich möchte auf dem Bildschirm Punkte umherfliegen sehen, die sich gegenseitig anziehen, so wie Himmelskörper im Weltraum.

1. Problem: Geschwindigkeit
Bei einer Darstellung der Geschwindigkeit in Pixeln, hat man das Problem, dass ein Teilchen bestimmte Pixel auslässt und von Position x auf Position x+Geschwindigkeit springt. Jedes Teilchen soll aber jede mögliche Position betreten um zu einem anderen Punkt zu kommen.
Ich habe mich daher entschlossen die Geschwindigkeit als zeitlichen Faktor zu verwenden. Dazu bekommt jedes Teilchen einen Timer dessen Intervall auf 1000/Speed gesetzt wird. Geschwindigkeit 5 bedeutet also eine Neuberechnung der Position alle fünftel Sekunde.
Die anstehenden Berechnungen, die von den Teilchen gemäß Timer angemeldet werden, kommen in eine Warteliste. Ich kann bis zu 50 Teilchen verwenden (Einfluss-Berechnung ausgenommen) ohne das die Warteliste ansteigt.

2. Problem: Einfluss
Einflüsse bedeuten unter Umständen eine Geschwindigkeitssteigerung, was sich sofort in einem Anstieg der Warteliste ausdrückt.

Was kann ich verbessern/verändern, um einen Anstieg der Warteliste zu verhindern, bzw. gibt es eine geschicktere Lösung der Geschwindigkeitsberücksichtigung.

So long
Minz

[jim_raynor]

Für jedes Teilchen ein Timer? Oh gott, was für eine Verschwendung. Würde lieber ein Teilchen nehmen und dann in einer Schleife alle Teilchen berechnen

[Minz]

Dann hast du vermutlich den Ansatz nicht verstanden...

[nailor]

jedem teilchen einen richtungs- und ortsvektor geben. wenn nötig noch beschleunigung. dann in einer endlosschleife die positionen updaten, unter verwendung der variablen "deltaT", die die zeit seit dem letzen durchlauf darstellt. da deltaT i.A. sehr klein ist, können i.A. bei polynomen alle summanden mit quadratisch oder höherm deltaT vernachlässigt werden.

[Minz]

Zitat:

jedem teilchen einen richtungs- und ortsvektor geben.

Hab ich bereits

Zitat:

wenn nötig noch beschleunigung

erstmal nicht

Zitat:

dann in einer endlosschleife die positionen updaten, unter verwendung der variablen "deltaT", die die zeit seit dem letzen durchlauf darstellt. da deltaT i.A. sehr klein ist, können i.A. bei polynomen alle summanden mit quadratisch oder höherm deltaT vernachlässigt werden.

Ahso meinst du: ich schaue jedes Teilchen in der Endlosschleife an, und vergleiche dann DeltaT(abgelaufene Zeit seit letzter Berechnung) mit der Geschwindigkeit(zeitlich), und entscheide dann ob das Teilchen wieder bewegt wird?

[nailor]

Zitat:

Zitat von Minz

Ahso meinst du: ich schaue jedes Teilchen in der Endlosschleife an, und vergleiche dann DeltaT(abgelaufene Zeit seit letzter Berechnung) mit der Geschwindigkeit(zeitlich), und entscheide dann ob das Teilchen wieder bewegt wird?

nein, die Vektoren sind Fließkomma-Zahlen. Bewegt wird immer. Nur beim Zeichnen wird gerundet.

[Minz]

Das ist doch genau das Problem !!

Dein Ansatz funktioniert wenn alle Teilchen weniger als 1 Pixel pro Berechnung zurücklegen.

Gibt es diese Begrenzung nicht, kann es sein, dass einzelne Teilchen 3 Pixel zurücklegen, aber die Pixel dazwischen nicht beschreiten...

[nailor]

a: ja und. dann bewegt es sich halt mehrere pixel weit
b: wenn du das nicht mit dem kopf rechnest, sondern mitm computer, wird das nie so lange dauern, dass was zwei pixel schafft.

[Minz]

Zitat:

a: ja und. dann bewegt es sich halt mehrere pixel weit

Eventuell gibt es Gründe, die das überspringen von Pixeln nicht wünschenswert machen. Es geht in diesem Thread wie bei jedem anderen auch nicht darum, seine eigenen Ideen durchzusetzen, sondern sich auf die des Fragenden einzulassen...

Zitat:

b: wenn du das nicht mit dem kopf rechnest, sondern mitm computer, wird das nie so lange dauern, dass was zwei pixel schafft.

hä?

[nailor]

b sagt aus, dass es praktisch nie vorkommen wird, dass ein pixel übersprungen wird.
a sagt aus, dass es noch nichtmal schlimm wäre.

ja, auf das problem eingehen und helfen. und meine methode ist jahrzehntelang erprobt und für fast alle derartigen probleme anwendbar. sag mir warum es nicht geht, und ich versuch mich weiter reinzudenken, aber so ganz ohne grund...

[Minz]

Ok, also nochmal...

Das Punkte übersprungen werden will ich NICHT, denn je nach Geschwindigkeit werden die übersprungene Distanz größer.

Angenommen ein Teilchen hat die Geschwindigkeit 100. Dann würde das Teilchen bei jeder berechnung 99 Pixel einfach auslassen.

Was mir daran nicht gefällt:
1. es wird eine ruckelige Angelegenheit
2. das Teilchen würde bei jeder Position ein anderes Teilchen beeinflussen und auch selbst beeinflusst werden. Befindet es sich auf Position 10 und springt plötzlich auf 20 werden 9 Einfluss-Berechnungen nicht berücksichtigt.

Apropos: wieso kommt das praktisch nie vor, das ein Teilchen übersprungen wird?

[Minz]

AHHHHH

jetzt kapier ich, was du meinst...

die Positionen updaten, unter berücksichtigung von DeltaT:

Ich führe ein Update durch mit z.B. Geschwindigkeit 10, da allerdings z.B. nur 1/100 sek vergangen sind,
beträgt die neue Position z.B +10/100

Schade, das hätte ich nach dem 5. Beitrag gebraucht :D aber danke...

[Luckie]

Kuck mal in der Freeware oder OpenSource Sparte, da hatte mal jemand so ein Programm vorgestellt.

[gekmihesg]

so ein programm gabs hier doch schonmal oder?
vielleicht mal suchen...

[nailor]

ja genau. das rechnen mit Fließkomma (für die genauigkeit auch bei kleinen zeitschritten) und beim anzeigen auf integers runden.

übersprungen wird dabei nichts, es sei denn du hast tausende von punkten oder machst ne gigantische grafische darstellung. bei ersterem wäre dann die überlegung, doch nicht echtzeit zu gehen, bei zweitrem ist das motto optimieren, optimieren, optimieren. aber ohne visualisierung solltest du millionen von durchgängen pro sekunde schaffen. das heißt, in einer sekunde müsste mehr als ne million pixel zurückgelegt werden, damit nich jeder berechnet wird (unwahrscheinlich).

[negaH]

Was er will ist das ausgehend vom nächsten anzusteuerenden Pixel der Flugbahnen der Zeitpunkt der Neuberechnung ermittelt wird. Statt also alle Bahnen mit fester zeitlicher Schrittweite zu berechnen, möchte er eine Formel haben wie man auf Grund einer festen geographischen Schrittweite == Pixelraster, den Zeitpunkt des Ausführens dieses Schrittes zu ermitteln.

Gut, das geht zu machen und würde die geammte Simulation enorm beschleunigen, da man so direkt auf die grobe Auflösung der gepixelten Anzeige direkt Bild für Bild berechnen kann. Statt also alle Bahnen permanent bei jedem zeitlichen Schritt erneut zu berechnen und somit in der Anzeige unsinnige 0-Pixel Bewegungen zu berechnen, wird bei dieser Methode immer zu einem Zeitpunkt nur die Pixel neu beerechnet die sich auch tatsächlich ändern würden.

Man berechnet ausgehend von der aktuellen Pixelkoordinate die nächste zu setzende Pixelkoordinate + den Zeitpunkt dazu. Der Zeitpunkt ist relativ zu einer Einheitszeit. Die Einheitszeit ist mindestens so klein wir die kleinste zeitliche Schrittweite der schnellsten Bewegung innnerhalb der Flugbahnen. Man baut eine Liste von zu löschenden und zu setzenden Pixelkoordinaten auf zu denen ein Timerwert gespeichert wird. Dieser Timerwert wird pro Einheitszeit um1 dekrementiert. Sobald dieser Wert 0 erreicht wird der alte Pixel gelöscht der neue Pixel an der neuen Koordinate gesetzt und auf Grund der Formel der Bewegungsbahn der nächste zu setzende Pixel berechnet samt seinem Counter.

Diese Vorgehensweise ist ideal für Priority Listen geeignet und erlaubt die freie Scalierung der Bewegungsabläufe auf untersichiedliche Rasterungen. Zudem ist die in fakt die Methode die die Simulation am schnellsten ausführen wird, aber eben OHNE an Informationen einzubüsen.

Der Weg dahin ist relativ einfach. Angenommen du hast eine Formel die zu einem Zeitpunkt die Pixelkoordinaten berechnet. Diese Formel wird nun so umgestellt das sie den Zeitpunkt = Schrittweite zur nächsten Pixelkoordinate berechnet. Damit dies funktioniert wird einfach eine virtuelle Einheitszeit eingeführt. Die zeitliche Schrittweite zur nächsten Pixelkoordinate wird durch diese Einheitszeit dividiert und ergibt den Counter für die List der abzuarbeitenden Pixelkoordinaten. Nun hat man einen einzigsten Timer der im Takt der Einheitszeit arbeitet. Bei jedem Ereignis werden die Zähler in der Priority Liste um 1 dekrementiert. Geht ein Zähle auf 0 so ist der exakte Zeitpunkt eingetreten um nun den Pixel zu setzen. Die Koordinaten dieses Pixel werden aus der Priority List gelöscht und in die Lister der nächsten Berechnungen eingefügt. So arbeitet man die Priority Liste komplett ab. Danach kommt die Berechnungs-Liste dran. In dieser stehen die Formeln der Bewegungsbahnen und deren letzer gerade abgearbeiteter Pixelkoordinate. Nun wird diese Liste abgearbeitet indem man die nächsten Pixelkoordinaten + Zeitpunkt berechnet und die neue Koordinate in die Priority List sortiert nach Zähler eingefügt. Dies geht alles iterativ.

Gruß hagen

[dizzy]

Zitat:

Zitat von gekmihesg

so ein programm gabs hier doch schonmal oder?
vielleicht mal suchen...

Da! :zwinker:

[Minz]

@Hagen

das sieht schon ganz ähnlich nach meinem Ansatz aus. Vielen Dank, ich werde beide Ansätze mal ausprobieren.