Es gibt neben der Float-Implementierung (für Teensy 4 oder ESM32S3) auch eine Fixed Point Integer Version für die kleineren Controller die keine FPU haben, also die Arduinos beispielsweise.
Die Animation ist eine Neuauflage von diesem Konzept, welches ich vor 11 Jahren mal gezeigt habe:
Damit kann man u.a. sowas machen
Oder so:
Ich experimentiere auch mit anderen FlowField Methoden, aber es ist noch nicht klar, was davon wirklich Teil von FastLED wird. Sind erstmal nur Experimente zum schauen, ob ich das auch auf kleineren Mikrocontrollern performant hinbekomme.
Beste Grüße in die Runde!
P.S. Ich war lange nicht hier. Ist momentan jemand mit LED Projekten beschäftigt?
Meine Holzwerkstatt ist gerade noch in einem Schiffscontainer eingelagert, also immer noch Drechselpause.
Ja, sorry für den Typo, ich meine den ESP32 S3, der hat eine (rudimentäre) Hardware Fließkomma Unit, und die Teensy 4.x haben eine ordentliche.
Aber da viele Leute ja auch die kleineren Controller verwenden, haben wir noch eine Fixed Point Version gebaut, das müsste theoretisch auch auf auf den 8 und 16 Bit Controllern gut laufen. Jedenfalls ist das dort ca. 3x schneller als float.
Bin neu hier,
nicht direkt mit LEDs sondern ich baue gerade ein Projekt mit Fluorescent Indicator Panel Display auf, die schlachte ich aus alten CD Playern aus bevorzugt die farbigen.
Ich habe zum ersten Mal eine "richtige" Fluid Simulation basierend auf den Navier Stokes Equations geschrieben. Das sieht echt vielversprechend aus und ich liebe die Detailtiefe die das produziert. Mal schauen, ob wir es irgendwie hinbekommen, dass ein ESP32 das stemmen kann. Beim Teensy bin ich optimistisch, beim ESP werden wir wahrscheinlich ein paar Berechnungen durch Approximationen ersetzen müssen.
Hier der erste Versuch:
Und hier die mathematisch etwas stabilere 2. Version:
Hallo Klaus, Dankeschön! Ich finde das selbst auch faszinierend, was man aus einem Set von Differentialgleichungen rausholen kann.
V.a. bin ich fasziniert, dass wir das soweit auf die Essenz reduzieren konnten, dass es überhaupt auf einem Microcontroller läuft.
Hier ist noch ein aktuelles Demo von heute, diesesmal mit einem Linienemitter anstelle eines Jets.
Mir ist gerade aufgefallen, dass das ja eine richtige Fluid Simulation ist - also kann ich die Buchstaben auch einfach als Hindernisse definieren und damit den Rauch zwingen wirklich um den Text herumzufließen!
Das sieht auf der ersten Blick überwältigend aus, aber wenn man sich erstmal eingelesen und reingedacht hat, wird es überschaubar. Ich erkläre es mal kurz ohne Formeln:
Der Solver ist ein gitterbasierter Stable Fluids-Ansatz auf einem festen 64x64-Raster. Pro Zelle speichert er:
vertikale und horizontale Geschwindigkeit
Farbdichte in R, G, B
Pro Simulationsschritt passiert grob diese Reihenfolge:
Emission
Neue Farbe und neuer Impuls werden an den Quellzellen eingespeist. Das ist die "Energiezufuhr" ins System. In diesem Fall die Buchstaben selbst. Ein Bitmap.
Externe Kräfte
Zum Beispiel Gravity. Damit bekommt das ganze Geschwindigkeitsfeld einen zusätzlichen Bias nach oben oder unten. Außerdem Wind zur Seite.
Velocity diffundieren
Die Geschwindigkeit wird leicht geglättet. Das verhindert zu harte, rauschige Sprünge und macht die Strömung visuell flüssiger.
Projektion
Das Geschwindigkeitsfeld wird auf “annähernd inkompressibel” korrigiert. Ohne diesen Schritt würde das Fluid unnatürlich aufblasen oder kollabieren.
Velocity advektieren
Die Geschwindigkeit wird von sich selbst transportiert. Das heißt: die Strömung bewegt ihre eigene Strömung weiter. Dadurch entstehen die typischen gebogenen, mitgerissenen Flow-Strukturen.
Projektion nochmal
Nach dem Transport ist das Feld wieder etwas inkonsistent, also wird nochmal auf inkompressibles Verhalten zurückprojiziert.
Vorticity confinement
Hier werden kleine Wirbel künstlich wieder verstärkt. Der Stable-Fluids-Ansatz ist robust, dämpft aber oft zu stark. Dieser Schritt bringt wieder Details und “Leben” rein.
Dye diffundieren
Die Farbe wird leicht in Nachbarzellen verteilt. Das steuert, wie weich oder scharf der Rauch aussieht.
Dye advektieren
Jetzt wird die Farbe durch das aktuelle Geschwindigkeitsfeld transportiert. Das ist der eigentliche sichtbare Rauchfluss.
Dissipation
Geschwindigkeit und Farbe werden etwas abgeschwächt, damit das System nicht immer weiter Energie aufsummiert.
Obstacles erzwingen
Im konkreten Beispiel werden die Buchstaben als Hindernisse behandelt:
Geschwindigkeit in den Buchstaben wird gelöscht
Bewegung durch ihre hindurch Kanten wird unterdrückt
dadurch fließt der Rauch um die Formen herum
Bitmap neu stempeln
Zum Schluss wird das sichtbare Logo wieder in die Farbfelder geschrieben, damit die Buchstaben lesbar bleiben und nicht komplett verwischen.
Ich habe heute stundenlang Simulation Papers gelesen und plötlich hatte ich eine wilde Idee:
Was passiert eigentlich, wenn ich nicht nur die Geschwindigkeit der Fluidbewegung simuliere, sondern zusätlich auch noch Temperaturverteilung UND Rauchbewegung - alles vom selben System und das alles ineinander rückkoppeln lasse...
Das Ergebnis ist: FEUER!
Ich habe jetzt echt zu lange nicht mehr geschlafen und mein Urteilsvermögen ist gerade stark eingeschränkt. Aber ich bin geflashed wie geil das aussieht. Vor allem der Feuerpilz beim Anzünden.
Ich hatte nur wenig Zeit heute. Da ist noch viel zu tun, aber ich denke, ich habe schonmal einen vielversprechenden Ansatz, wie man die Lava Lampen Mechanik vielleicht mit den begrenzten Ressourcen eines Microcontrollers modellieren könnte.
Die konkreten Parameterwerte sind alle noch falsch, aber das könnte möglicherweise trotzdem funktionieren - ein System aus Oberflächenspannung, Viskosität, Temperatur, Auftrieb, Interner Strömung, Trägheit usw.
Nur die Blasenablösung klappt bisher noch gar nicht.
Mal schauen, ob ich damit weiterkomme.
Numeric Solver sind jedenfalls ein absolut faszinierendes Thema und ganz ehrlich - wenn man die Basics einmal kapiert hat, ist das ein potentiell sehr mächtiges Werkzeug für die Simulation von physikalischen Systemen aller Art....
