[OC] UPDATE – Ich habe eine Stunde lang Bounce DVD Logo simuliert, die Flugbahnen visualisiert und daraus eine vollwertige Physiksimulation mit drei speziellen Engines gemacht.

Für diejenigen, die den ursprünglichen Beitrag verpasst haben oder keine Gelegenheit hatten, ihn zu lesen: Beginnen Sie hier.

Hallo nochmal alle zusammen,

Vielleicht erinnern Sie sich an mich als den Mann, der so gelangweilt und unter Schlafmangel war, dass er sich entschied, die Frage zu beantworten "Könnte ich eine Stunde lang springendes DVD-Logo simulieren, die Flugbahnen verfolgen und die Anzahl der perfekten Ecken zählen?"

In meinem letzten Beitrag ist vielen Leuten ein gewisses seltsames Verhalten in meiner Simulation aufgefallen. Insbesondere waren die Flugbahnen zur Mitte hin geneigt und folgten auch nicht einer 45-Grad-Flugbahn, wie es die Simulation des springenden DVD-Logos erfordern würde.

Die Frage nach dem Studienabschluss war eigentlich meine Absicht. Ich hatte den 45-Grad-Winkel simuliert und festgestellt, dass es keine perfekten_Ecken gab, daher brachte eine Stunde Simulation kein interessantes Ergebnis und zu diesem Zeitpunkt hatte ich mich auch gefragt, ob eine Änderung des Startwinkels das Logo in eine höhere Anzahl verschieben würde "perfekte Ecken" übereinstimmen.

Das zweite Problem, Flugbahnen, die eine Tendenz zur Mitte zeigen, war auf die Logik hinter meiner DT-Simulation zurückzuführen. Der von mir verwendete dt-Parameter versuchte, einen 60-Hz-Bildschirm nachzuahmen, indem er die Flugbahnposition in diskreten Zeitschritten betrachtete, und erreichte mit der Einstellung 0,0167 einen Wert, der näher an 60 FPS lag (obwohl es sich um eine Näherung und nicht um eine genaue Messung von 60 Hz handelte).

Auf dem ersten Bild können Sie sehen, was passiert ist, als ich in meiner ersten Simulation 45 Grad als Startwinkel eingestellt habe.

An diesem Punkt kam mir jedoch eine andere, interessantere Frage in den Sinn. "Könnte ich eine Zufallssuche verwenden, um den Winkel zu finden, der die Anzahl der perfect_corners optimiert?"

Um diese Frage zu beantworten, musste ich jedoch von einem monolithischen Codierungsansatz abrücken und einen objektorientierten Ansatz verwenden, um eine richtige Engine mit einem zugrunde liegenden Satz physikalischer Regeln zum Durchlaufen zu entwickeln. Das gesamte System ist folgendermaßen aufgebaut:

– Physikkern – Funktion mit einem Satz physikalischer Regeln für ein geschlossenes System, das eine geradlinige Bewegung in einem Raum mit reflektierenden Grenzen simuliert

– Drei verschiedene Funktionen mit drei verschiedenen Engines, die die etablierten physikalischen Regeln durchlaufen, um drei verschiedene Logiken zu testen

– Funktion zur Berechnung von Metriken, die die Ergebnisse unabhängig protokolliert

– Plotfunktion, die visuelle Ergebnisse lieferte.

Warum aber drei verschiedene Motoren?

Ich habe dir gesagt, wie die Initiale ist "DT-Motor" hatte Probleme und brachte auch eine Voreingenommenheit mit sich. Darüber hinaus wurde mir klar, dass die Anzahl der perfekten Ecken aus zwei Gründen falsch war:

– Zuerst habe ich den DT-Parameter so eingestellt, dass mein Motor "schaute nach oben" für die Position der Flugbahn in bestimmten Zeitintervallen, sodass die Flugbahn überschießen und dann innerhalb des Systems neu positioniert werden konnte, wodurch die Anzahl der perfekten Ecken übertrieben wurde;

– Zweitens habe ich bei der Messung der perfekten Ecke in der ursprünglichen Simulation versucht, die Logo-Ecke mit der Randecke abzugleichen und dabei ein Toleranzmaß eingeführt, um als perfekte Ecke zu protokollieren, auch wenn die Übereinstimmung nicht präzise war;

Um dieses Problem zu klären, habe ich beschlossen, zwei neue Engines einzuführen:

– Eine ereignisgesteuerte Engine, die lediglich die Flugbahn simuliert und sich dann selbst fragt "Wo wird die nächste Kollision passieren?"und bringt das System dann dorthin und fährt mit der nächsten Kollision fort;

– Eine pixel_snapping-Engine, die dieselbe ereignisgesteuerte Engine-Logik verwendet und dann "schnappt" die Flugbahn zu einem Pixelgitter, das die Pixel eines LCD-/LED-Bildschirms simuliert. Hierbei handelt es sich um eine visuelle Quantisierung und nicht um eine Änderung der Physik. Daher stimmen die zugrunde liegenden Flugbahnergebnisse mit denen der ereignisgesteuerten Engine überein. Die Anzahl der verwendeten Pixel ist ein Hyperparameter.

An diesem Punkt habe ich neu definiert, wie ich eine perfekte Ecke protokollierte, indem ich die Seiten des Logo-Felds ein gleichzeitiges Kollisionsereignis mit den Raumrändern registrieren ließ, was bedeutete, dass es sich unweigerlich einer der Ecken näherte. Eine Kollision auf der x- und y-Achse bedeutet gleichzeitig, dass Sie eine perfekte Ecke erhalten.

Die obigen Bilder wurden fast alle mit diesem Simulationssystem extrahiert:

Bild 1 – Originalsimulation mit einem DT-System im 45-Grad-Winkel.

Bild 2 – Neue Physiksystemsimulation für das Bounce-DVD-Logo, die zeigt, was passiert, wenn Sie 45 Grad auf der DT Engine einstellen, die auf dem Physikkern läuft

Bild 3 – 45 Grad bei ereignisgesteuertem Motor

Bild 4 – 45 Grad auf der pixel_snapping-Engine

Bild 5, 6, 7 – Ergebnisse der zufälligen Suche in einem 360°-Startwinkelraum, um die Anzahl der „perfect_corners“ zu optimieren. Die zufällig ausgewählte Ecke beträgt 279,4613° und erzielt das beste Ergebnis bei perfekten Ecken.

Das Ergebnis, das ich beobachtet habe, ist, dass die Systeme im Wesentlichen quasiperiodisch oder nichtperiodisch sind, es sei denn, Sie wählen ein bestimmtes aus "besonders" Satz von Startwinkeln wie 45°, 90° usw. und dann erhalten Sie eine periodische Flugbahn, die es möglicherweise völlig vermeidet, perfekte Ecken zu ergeben.

Das System, das ich codiert habe, protokolliert die Flugbahnen weiterhin wie zuvor und visualisiert sie insgesamt. Ich entschuldige mich dafür, dass ich mich nicht besonders auf die Datenvisualisierung mit den Diagrammen konzentriere, aber dieses Mal wollte ich nur ein funktionierendes, plausibles System bekommen.

Bitte beachten Sie: Die pixel_snap-Visualisierung ist in der Darstellung kleiner, da ich vermeiden wollte, dass das Logo am Containerrand einrastet und eine mehrdeutige Visualisierung entsteht.

Auf vielfachen Wunsch ist die Simulation nun auf Github verfügbar hierkommentiert und erklärt im .ipynb-Notizbuch.