Plasma Effekt für LED Matrix

  • ich kenn da noch einen der C Programme in ASM wandeln kann

    Ja, den kenn' ich auch! :D


    Mir geht's aber eher drum, das gleich so zu haben, wie man es eben von Hand in asm schreibt ;) - bzw. auch, was eigenes zu machen, wie gesagt, Dein Plasma probiere ich dann mal gleich wie es ist in C aus... den Compiler-Output schaue ich mir aber trotzdem mal an, interessiert mich schon, wie der das so "schreibt"


    "Mein erstes Plasma" :D ist jetzt auch fertig:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    das ist toootal simpel, nur zwei Funktionen überlagert - dementsprechend "wabert" es auch nicht richtig, sondern "fließt" nur in eine Richtung, und ist auch noch sehr "gerade", eher "Blasen" als "Plasma"... da schau' ich jetzt weiter, wie ich noch ne schöne Verzerrung rein bekomme...


    die 8-Bit-Sinus-Tabelle ist von Mikrocontroller.net, hat lange gedauert, eine zu finden, Google liefert viel Foren-Threads, wo über sowas *gelabert* wird, aber kaum dass dann mal echt einer *eine anhängt*... :D


    am längsten gebraucht habe ich für die Farbtabelle - die ist liebevoll von Hand getippt :P (ich muss mich jetzt echt mal mit dem Excel anfreunden...) - und auch in 8 Bit, weil modulo 256 ist in asm viel einfacher als moulo 768 ;)


    hier auch der Gedankengang, ob bei meiner geringen Auflösung ne größere Farbtabelle überhaupt was bringt - ist halt so, ich habe z.B. 4 Pixel Abstand zwischen Rot und Blau, mithin 4 Farbwerte, da bringt's mir auch nix, wenn in der Tabelle 200 Werte zwischen Rot und Blau sind, ich "picke" ja doch nur ein paar raus...


    klar, bei ner höheren (Bild-)Auflösung spielt das wieder eher ne Rolle, wenn so ne Blase gleich 50 Pixel Durchmesser hat, dann braucht man natürlich auch mehr Farben in der Tabelle... ich stelle hier jedenfalls keine Stufugkeit oder "Ausgefranstheit" fest...


    witzig: ich hatte mir in der Tabelle erst mal ein paar "Stützpunkte" rein gemacht, der Rest war noch schwarz - damit gibt es auch einen sehr coolen Effekt:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    in der Theorie (siehe Bilder im verlinkten Thread) müssten bei sowas ja dann farbige "Ringe" entstehen, aber das Blitzen kommt eben dadurch, dass die Tabelle "durchgesprungen" wird, gar nicht fein aufgelöst Wert nach Wert entnommen wird - das würde mit ner 768-Werte-Tabelle hier genauso blitzen...


    Aber ich denke du wirst da etwas enttäuscht sein, weil einfach die Variablentiefe nicht besonders groß ist und damit die Animation sich nicht soooo viel verändert...

    Ja, wie gesagt, hängt halt von der Auslegung ab, da werde ich mal rumprobieren - im Video oben ist übrigens gar keine Paletten-Rotation dabei, hatte ich mit auch schon, das ist schon ein Unterschied, ohne hat es mir hier besser gefallen...


    In GCC gibt es leider keine 24 Bit Variable und in 8 Bit ASM schreibt man sich ja so was eh selbst. ;)

    Ja - das ist aber immer ne "große Umstellung" ob ich was in 8 Bit mache oder mehr - hier z.B. kann ich alle Parameter innerhalb der Routine in Registern halten, bei 24 Bit-Rechnungen müsste ich dann wieder viel in's RAM schubsen...


    ich glaube, ich konzentriere mich jetzt mal auf die Optimierung meines 8-Bit-Plasmas - bringt wohl mehr, als wenn ich versuche, Deinen Algo auf meine 6x5 Pixel zu pressen... ;) - dann haben wir beide Varianten schön ausgefeilt, meine in asm für 8 Bit, und Deine für höhere Auflösung in C


    Kommst Du eigentlich auch zum AOS nach Dresden..? - bzw. ich besuche den Nino dann mal, da könnten wir uns ja auch in Leipzig treffen, und ich mir Deine Matrix und Plasma mal in echt ansehen...

  • hehe, ja sieht ganz witzig aus :)


    Was brauchst du denn für ne Tabelle, soll ich dir schnell eine schicken? Aber Open Office und nen bissel Tabellenkalkulation könnte man sich schon mal angucken =)


    Hab auch mal schnell nen Video aufgenommen... Habs mal sehr schnell laufen lassen, ist normal natürlich viel langsamer. Die Kerze ist für den Fokus der Kamera, dass hat ganz gut geklappt ;)


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Grüße


    Basti


    P.S: Wie heißt das eigentlich im Englischen, wenn man ne 8 schreibt heißt es doch eight und dann schreibt man doch "on an 8 bit..." ?! Oder ist das an hinfällig wenn man das nicht ausschreibt? =)

  • k.A., mein Englisch ist auch nicht so gut... ;)


    das sieht ja schon mal wirklich toll aus! :thumbup: - ich bin gerade dabei, das erst mal gedanklich zu durchsteigen, und per try&error nachzuvollziehen, wie sich das Plasma ändert, wenn ich hier und da was drehe... ;)


    ideale Beschäftigung gerade, was macht man an Neujahr sonst, ausser auf der Couch flaggen, nen Klassiker in die Glotze zu werfen, und da man den eh' schon kennt, nebenbei bisschen zu programmieren :thumbup:


    Was brauchst du denn für ne Tabelle, soll ich dir schnell eine schicken?

    Na, jetzt hab' ich die ja schon ;) - es wäre halt viel einfacher gwesen, Excel das rechnen zu lassen, als die 3x256 Farbwerte per Hand zamzutippen... :D


    aber, wenn's Dir nix ausmacht: Mal ne andere Tabelle zum ausprobieren wäre auch interessant - also die nicht so gleichmäßig nen Verlauf hat, sondern eher so "gescheckert" ist wie hier:


    [Blockierte Grafik: http://lodev.org/cgtutor/images/plasmapalette4.jpg]


    also dann eher so ein Plasma erzeugt:


    [Blockierte Grafik: http://lodev.org/cgtutor/images/plasma6.jpg]


    da sieht's dann ohne Änderung des Algorithmus gleich wieder ganz anders aus - also wenn das ginge, irgendwie so ne Tabelle, die auch "zirkular" ist (also bei 0 und 255 wieder die selbe Farbe), aber dazwischen doch irgendwie "unruhiger" verläuft... oder z.B. eine mit nur Rot und Blau, das ist bei meinen Farbkonzepten immer sehr beliebt..


    (wobei, das könnte man ähnlich wie in Glediator einfach per "maskieren" machen, also ich schreibe für Grün dann einfach immer "0" in's screen-RAM statt dem Wert aus der Tabelle, muss ich gleich mal ausprobieren... ;))


    ansonsten schaue ich jetzt mal, wie ich selbst andere Tabellen erzeugen kann, die könnten wir dann auch hier austauschen... ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hab's mal ausprobiert, einfach Grün immer auf Null, das ist ja praktisch das selbe, wie wenn man in Glediator das Plasma mit Magenta "Intensity-Verknüpft", sieht auch genauso aus:


    www.youtube.com/watch?v=fTpLD3l-q1M


    das eröffnet natürlich weitere Variationsmöglichkeiten, man könnte z.B. in einer extra Routine noch die Farbkanäle sinusförmig dimmen, und so die Farbigkeit auch schwanken lassen (also z.B. Wechsel von Rot/Blau nach Grün/Blau, o.ä.) :thumbup:


    hier übrigens schon geändert: Statt den Plasmacounter zu x zu addieren, addiere ich hier den Sinus des plasmacounters zu x, daher läuft das nun nicht mehr nur in eine Richtung, sondern hin und her...


    Hier mal ein Vergleich zwischen statischer und rotierender Palette - erst statisch:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    das sieht praktisch so aus, Du hast "rote Blasen", die in ner "blauen Suppe" schwimmen - das bleibt immer gleich...


    mit rotierender Palette:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    da ändern also die "Blasen" auch noch ihre Farbe, das sieht schon deutlich anders aus!


    und mit getrennten Variablen für Form-Wabern und Paletten-Rotation hat man da eben doch sehr unterschiedliche Gestaltungsmöglichkeiten, also z.B es sieht ja deutlich anders aus, wenn nun die Blasen immer in der selben Geschwindigkeit "wandern", aber entweder kaum oder aber sehr schnell ihre Farbe wechseln - evtl. wär's noch ganz lustig, das ebenfalls noch mit nem Sinus zu modulieren, also dass die Farben mal schnell und mal langsam wechseln...


    da kann man echt rumspielen, gibt "1.000 Möglichkeiten" ;)


    ach, o.t.: ich war erst traurig, dass meine Videokamera kaputt gegangen ist - aber mit Handy ist das eh' cooler, winzige Dateien, gleich raufgeladen und verarbeitet, Qualität reicht für sowas auch - da wird's also von mir wieder mehr Videos geben, war zuletzt doch etwas faul, mit der "großen" Kamera immer erst über Firewire importieren, schneiden, konvertieren, riesige Datei raufladen...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ja, stimmt! - Das wünsche ich auch!


    Und wie geht die Formel? =)

    Keine Ahnung.. ?( - Du bist der Excel-Mann... :P


    ich meinte auch nicht, dass Du *genau diese* Palette nachbaust, sondern halt *irgendwas in der Art*, also das nicht so nen glatten Verlauf hat wie der "Regenbogen"... ;)


    z.B.: Für Rot nen kompletten Sinus nehmen von 0-255 - für grün nen halben (also bei 0 ist grün Null, steigt dann bis 128 auf 255 an, und fällt wieder bis 0 ab bei 255 Eingabe) - und Blau dann zwei komplette Sinuswellen...


    das sollte dann auch irgendwas gestreiftes geben...


    k.A., wie man dem Excel das beibringt, aber praktisch:


    R = sin (x)
    G = sin (x/2)
    B = sin (x*2)


    wobei halt x eine volle Periode durchläuft, also irgendwie müsste man das so umrechnen, dass 0-255 für x dann 0 - 2pi ergibt für den Winkel im Excel... evtl. x/40, das gibt bei 255 dann 6,375, also (fast genau :D) 2pi...


    und da der Sinus im Excel wohl von -1 bis +1 geht natürlich noch auf 0-255 umrechnen, also wohl y = 128 + 128*ausgerechneter_Sinus...?


    Ist mir noch eingefallen: Der André hat mir mal so ne SW gegeben, die direkt Farbwerte aus nem .bmp in ne Textdatei schreibt - das könnte ich natürlich auch nehmen, im Photoshop als Bild 256x1 Pixel direkt die Palette "malen", als .bmp speichern, durch die SW jagen, und schon habe ich sie als Tabelle... ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Also, die streifige Tabelle funktioniert bei mir nicht (mit Photoshop und Konverter gemacht) - die Streifen sind einfach zu "dünn" (bzw. die Auflösung meiner Matrix zu grob), die "verschwinden" einfach, bzw. blitzen immer nur kurz auf...


    dafür habe ich mal noch zwei andere Paletten gemacht:




    die sehen auch ganz gut aus:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    die sind halt nicht zum durchscrollen geeignet, weil sie ne harte Kante haben - aber mir gefällt das ohne Paletten-Rotation ehrlich gesagt eh' besser...


    was mir jetzt noch eingefallen ist: Im Prinzip muss man ja gar keine Palette im Flash ablegen, man kann die ja zur Laufzeit durch ne Rechenvorschrift erzeugen (mehr oder wneiger komplex, je nachdem wie's aussehen soll).


    Da hätte man dann nämlich auch noch die Möglichkeit, die "Formel" über de Zeit zu ändern, so dass sich die Farben ganz ällmählich ändern - z.B. eben von der Rainbow-Palette zu Türkis/Magenta, dann Magenta/Orange, dann nur Orangetöne, dann Grün und Orange etc. - also dass alle paar Minuten die Farben anders aussehen...


    sollte gar kein sooo großer Aufwand sein, man muss die Palette ja nur einmal pro Frame (oder sogar nur alle paar Frames mal bei ganz langsamer Änderung) neu erzeugen, nicht bei jedem Pixel... ;)


    hier anbei noch die 2 oben abgebildeten Tabellen für die 8-Bit-Fraktion :D

  • Wird langsam ein Monolog hier.... :D


    ich hab' jetzt mal noch 2 weitere Generatoren dazu gemacht, jetzt sieht es (für meine Begriffe) schon deutlich besser nach Plasma aus:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    kann natürlich täuschen, weil ich ja letztlich nur nen kleinen Ausschnitt sehe - brauche echt ne größere Matrix :D


    das ist hier jetzt mit Paletten-Rotation, gefällt mir da nun besser - mir ist aufgefallen, diesen Modulo braucht man ja auch nur für die Rotation, bei mir aber gar nicht, weil's dank 256 Werten bei 8 Bit eh' überläuft... ;)


    ebenso brauche ich hier auch noch keine Divison, die bei nem 8-Bit-AVR ja immer aufwändig in SW gemacht werden muss - nicht dass das nun ein großes Problem wäre, aber mir gefällt sowas einfach, wenn mir das Ergebnis taugt, owohl es nur ganz simpel gemacht ist - hier mal der Algorithmus:



    der "Plasmacounter" (heisst bei mir PLASMA_MOVE, weil ja die Rotation noch extra soll) wird da nun in der Routine weitergezählt, die erzeugt also einfach bei jedem Aufruf nen neuen Frame...


    mir ist hier aufgefallen: PLASMA_MOVE ist ja das einzige, was sich ändert (bei dir plasmacounter) - d.H. es ist fest verknüpft, für jeden Wert gibt es immer das selbe zugehörige Bild... egal ob nun rotiert wird oder nicht


    deswegen wiederholt sich die Animation bei mir alle 256 Frames, und bei Dir alle 768 Frames - wie gesagt, egal ob Rotation oder nicht...


    daher werde ich auf jeden Fall die Paletten-Rotation noch getrennt machen - das gibt dann mehr Abwechslung, weil eben nicht der selbe Fleck an der selben Stelle immer die selbe Farbe hat, sondern bei jedem Durchlauf ne andere...


    und wie gesagt, evtl. noch ne zeitliche Variation der Farben dazu, z.B. Grün langsam rauf- und runter dimmen, dann gibt's noch mehr Abwechslung - die sollte dann aber auch wirklich für den simplen Zweck reichen :thumbup:


    anbei noch der Algo als Datei, sowie die zugehörigen Funktionen _sine und _set_pixel, die nix anderes machen, als den Sinus aus der Tabelle zu holen bzw. die zu nem Wert zugehörige Farbe in's Screen-RAM zu schreiben...


    EDIT: Böser Fehler in Zeile 122: temp2 muss natürlich zu XL addiert werden, sinst rotiert die Palette gar nicht - hatte mich schon gewundert, warum da "kaum ein Unterschied" zu sehen war... :whistling: :wacko:


    gerade noch mal mit ausprobiert, ist auch ganz schön, da kommt dann öfter Rot, Orange und Magenta vor...

  • Hallo Pesi,


    ein kleiner Tipp: Gerade deine beiden zuletzt verwendeten Paletten sind ja mehr oder weniger Teilbereiche der gesamten Hue-Palette. Solche Sachen lassen sich auch recht einfach durch Verringern der Modulationstiefe des Plasma-Algos auf die Palette und Verschieben des Offsets der Modulation bewerkstelligen :) .
    Oder um es mal in der Sprache der Plasma-Sinüsse :D zu schreiben: Farbpalettenmodulation = a + b * sin(x, y ,t) ... , wobei b die Modulationstiefe und a den Offset bestimmt.


    Gruss und schönes und glückliches Neues Jahr an alle
    Neni

  • Hi Neni,


    ja, so in der Art hatte ich mir das auch gedacht, z.B. einfach den Bereich vergrößern und verkleinern und hin- und her schieben zur weiteren Variation...


    ist natürlich wieder mehr Aufwand, also ich erzeuge ja Zahlen von 0-255 - wenn die nun z.B. nur von 0-240 gehen sollen, muss ich ja dividieren, und zwar bei jedem Pixel...


    was aber auch kein Problem sein sollte, bei der von mir maximal angestrebten Größe von 16x16 (256 Pixel)... werde ich auf jeden Fall auch mal einbauen :thumbup:


    EDIT: Noch ne Variation: statt direkt den Plasmacounter zum Palette rotieren zu verwenden, hier mal der Sinus vom Counter für's Shiften - dadurch wechselt (bei meinem Algorithmus und 6x5-Ausschnitt) die vorherrschende Farbkombi zwischen Gelb/Grün/Blau und Orange/Rot/Magenta:


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    das gefällt mir nun schon ziemlich gut, das lass' ich jetzt mal so und geh in's Bett ;)


    anbei noch das komplette Projekt, die Ausgaberoutine müsste man wohl ersetzen, die gibt hier an 5 Pins gleichzeitig aus, weil meine kleine Matrix so verkabelt ist (war zum testen für die Kugelmatrix) - wer das direkt wie's ist nachbauen möchte: einfach 5 Streifen WS2801 á 6 Pixel waagrecht, Einspeisung links, unterster Streifen an PC0, oberster an PC4, Takt an PC5... .hex für nen Mega16 auf 16 MHz

    Dateien

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()

  • So, habe jetzt auch mal ein kleines Video meines SynPlasma Algos gemacht. Alles wird live in Processing berechnet und mit einem OpenGL-Renderer (in Processing integriert) mit Smoothing (simuliert in etwa eine diffuse Platte vor der Matrix) dargestellt. Die virtuelle Panel-Grösse ist hier 32 x 32 Pixel gross, was vier meiner geplanten Module entspricht. Generell benötigt der SynPlasma Algo schon mindestens eine Grösse von 16 x 16 Pixel, um überhaupt 'aufblühen' zu können :) , also genau eins meiner Module.


    Der Vorteil der Sache mit dem µC pro Modul ist, dass die Performance ja mit der Panel-Grösse mitskaliert, da jedes Modul seinen eigenen Ausschnitt des Plasmas berechnet. So sind zumindest theoretisch beliebig grosse Panels möglich. Ein Mastercontroller (kann ein beliebiger, auch schwachbrüstiger µC sein) übermittelt einfach die zu verändernden Parameter und den Sync-Wert (den plasmacounter sozusagen) via RS485 z.Bsp alle 20 ms (= 50 fps) an alle Module, was den Datenstrom relativ klein und unabhängig von der Panelgrösse (Anzahl Pixel) macht. Wie gesagt benötigt ein LPC1768 mit meinem C-Code für 16 x 16 Pixel (ein Modul) inkl. Rausschieben der Daten via SPI und Matrix-Multiplexing mit ca. 9600 Hz Zeilenfrequenz (also ca. 600 Hz Bildwiederholrate) ca. 8 ms für ein Frame des SynPlasma Algos in der aktuellen Ausprägung (wie im Video).


    Das Video ist etwas ruckelig. Das liegt zum einen an der Youtube-Konvertierung und zum anderen daran, dass bei gleichzeitiger Screen-Bereichs-Aufnahme (mit MPEG4 Codec) der Processing-Code (weil da natürlich auch noch die Kontrolle aller Schieberegler drin ist) etwas ins Stocken gerät. Auf der tatsächlichen Hardware (Module) würde das natürlich absolut smooth laufen. Ausserdem ist ein etwas 'hässliches' Aliasing zu sehen, was vor allem daran liegt, dass die virtuellen Pixel quadratisch sind (ein virtueller Pixel entspricht 16 x 16 Bildschirmpixel) und das OpenGL-Smoothing dann eben nicht sphärisch verläuft. Aliasing wird man zwar aufgrund der begrenzten Auflösung auch in Hardware haben, aber das wirkt sich dort weniger 'hässlich' aus. Dass Aliasing ausserdem manchmal auch ganz nette Effekte produziert, sieht man im Video bei etwa 7'30.


    Das Video beginnt mit einem relativ klassischen, einfachen Plasma, welches dann immer komplexer wird. Ich habe in meinem Processing-Code ein ganzes Arsenal Schieberegler (je einen für jeden einstellbaren Parameter des SynPlasma Algos), welche ich im Video live bediene, um das Plasma entsprechend zu beeinflussen. Manche Parameter sind eher zum manuellen Einstellen gedacht, da sie ein eher sprunghaftes Bild beim Verstellvorgang erzeugen. Andere eignen sich aber auch gut zur automatisierten, kontinuierlichen Manipulation (z.Bsp vom Mastercontroller aus), da das Plasma bei diesen ganz weich von einem in einen anderen Zustand kommt. Das sieht man auch im Video. Allerdings verstelle ich im Video nur einen kleinen Teil der rund 40 Parameter.
    Und bevor jemand fragt ;) , nein, ich verwende keine Palettenumschaltung und keine anderen Paletten im SynPlasma Algo. Alles wird immer aus dem HSV-Farbraum berechnet.


    Hier also das Video (zur Erinnerung: es entspricht einer 32 x 32 Pixel Matrix mit Diffusorplexi)
    g-Mvh8OePE0


    Gruss
    Neni

  • Pesi, ja sieht schon gut aus :thumbup:


    Die Kunst ist es dann, das ganze schön langsam werden zu lassen... weil ja die Auflösung so gering ist, fängt alles mit dem Plasmacounter an zu springen... :wacko:


    synvox... klasse, dass würde ich dann auch gern mal live auf der Matrix bewundern wollen :) Das mit schwarz in der Platte fand ich erst störend, aber nach 2 Minuten gucken, fand ichs dann auch gut :D
    Aber was mir noch nicht so zusagt sind die vielen Rotationen... Ich mag es, wenn das Plasma augenscheinlich in eine Richtung "wegwabbert". Wahrscheinlich braucht man es nur langsamer stellen und ist ja auch Geschmackssache ;)


    Wie bekommst du eigentlich den Processing-Code auf den ARM? Gibts da ne C Exportfunktion oder hast du nen Java Interpreter drauf? :D


    Achso, hab mal nachgemessen. Die Math.h Funktion sin() mit Fließkommazahlen braucht bei 24 MHz ca. 75 us. Also theoretisch sind damit auch Operationen möglich, wenn man wie du Neni die Module auf 16*16 Pixel beschränkt gibt es auch noch ganz gute Frameraten. Aber kommt halt aufs Plasma an, dass was du hier im Video gezeigt hast geht da sicher nicht :D

  • Neni, das sieht schon super aus, ist halt ne ganz andere Liga!


    Und, ich mag' zwar im Prinzip diese "künstliche Auflösungserhöhung" durch diffuses Plexi nicht so (denke mir da immer, da kann man dann gleich ne Glotze nehmen ;)), aber beim Plasma rentiert sich das echt, also wenn ich irgendwo ne Matrix anbringen würde, die hauptsächlich Plasma (oder auch Wolken, Wasserwellen, ...) darstellen soll, würde ich wohl auch diffuses Plexi drüber machen...


    Und bevor jemand fragt ;) , nein, ich verwende keine Palettenumschaltung und keine anderen Paletten im SynPlasma Algo. Alles wird immer aus dem HSV-Farbraum berechnet.

    modulierst Du dann BRI und SAT auch noch per Algorithmus, also dem Plasma-Algorithmus, oder rechnest Du das irgendwie um, also die Ausgabewerte vom Plasma dann in *Kombinationen* von HUE, BRI und SAT..?


    Die Kunst ist es dann, das ganze schön langsam werden zu lassen... weil ja die Auflösung so gering ist, fängt alles mit dem Plasmacounter an zu springen... :wacko:

    ja, das ist das Problem - im Video oben sind's sogar nur 16 fps, läuft aber trotzdem "geschmeidig" - viel langsamer ist dann aber nicht mehr drin ohne ruckeln...


    das war nun auch das Problem bei Form und Farbrotation unabhängig: ich wollte das so machen, dass das "Wabern" diese Geschwindigkeit behält, aber die Farben langsamer rotieren für mehr Kombinationen - da der Farbwechsel dann nur noch mit max. 8 fps stattfindet, sieht man aber den "ruckeln" :wacko: - also müsste ich insg. die Geschwindigkeit erhöhen, dann ist mir aber das "wabern" zu hektisch... so wie im Video oben passt's mir für allgemeine Deko-Zwecke schon, muss gar nicht unbedingt langsamer gehen


    nächster Versuch: damit nix "springt" muss ja nur die Palettenrotation bei jedem "Start" (FRAME_MOV == 0) auch auf 0 sein - was dazwischen passiert ist mehr oder weniger egal. Werde das also mal so versuchen, bei einem Durchlauf zählt die Palette einfach hoch, beim anderen runter, beim nächsten Sinus-Modulation, dann ein halber, usw. - also bei jedem Waber-Durchlauf ein anderer Verlauf der Paletten-Rotation, das gibt dann auch wieder mehr Abwechslung...


    bei Dir ist das natürlich besser, mit den 768 Farben in der Tabelle - da ist mir aufgefallen: bei der *Form* hast Du aber doch auch nur ne Sinus-Tabelle mit 256 Werten, und "plasmacounter" ist das einzige, was da durchgezählt wird, wird zu nem Wert addiert (läuft ggfs. über), und dann davon der Sinus genommen - d.H. bei 256 und 512 muss die Form wieder genauso sein wie bei 0, also wiederholt sie sich 3x während plasmacounter von 0-767 durchläuft... damit hast Du letztlich auch schon getrennte Geschwindigkeit für Wabern und Palettenrotation... (Während die Palette 1x durchläuft, läuft das wabern 3x durch).


    für gaaanz laaaangsam hilft dann nur, die Auflösung beim Plasmacounter/Sinus zu erhöhen, eben wie Du schon gesagt hast per Fließkomma und Sinus-Berechnung... nächter Hemmschuh ist dann die Auflösung der LEDs, da sieht man bei 8 Bit dann halt auch irgendwann ein Ruckeln, wenn der Farbwert von 2 auf 1 oder von 1 auf 0 geht... da wird Neni bestimmt auch ne höhere Bittiefe verwenden, nehme ich mal an...?


    das merke ich bei mir auch schon minimal, also wenn das Pixel z.B. von 3/0/250 auf 0/0/255 wechselt, da "zuckelt's" ein *bisschen* - da könnte man natürlich auch "bescheissen", indem man die untersten Helligkeits-Stufen ganz weg lässt, also LED nie auf 0, sondern immer minimal 3 oder so - aber da werden die Farben dann natürlich auch etwas "pastelliger", nicht mehr so "rein"...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Das mit schwarz in der Platte fand ich erst störend, aber nach 2 Minuten gucken, fand ichs dann auch gut


    Ja, das hat so etwas von Blobs, die aus dem Nichts langsam auftauchen und dann wieder verschwinden :) .


    Aber was mir noch nicht so zusagt sind die vielen Rotationen... Ich mag es, wenn das Plasma augenscheinlich in eine Richtung "wegwabbert". Wahrscheinlich braucht man es nur langsamer stellen und ist ja auch Geschmackssache


    Die Geschwindigkeit der einzelnen Modulationen hab ich im Video nicht verändert und sie eher mittelschnell wabern lassen, so dass man in nützlicher Zeit (Video) auch etwas sieht ;) . Diese kann man aber natürlich noch viel langsamer einstellen. Der Vorteil der wie 'Rotatonen' aussehenden Richtungswechsel (komplexer Algo) ist der, dass sich praktisch nie ein Frame wiederholt. Natürlich, die Grundstruktur bleibt schon die Gleiche, wenn man's bei fixen Einstellungen stundenlang laufen lässt, aber man bekommt auch dann wirklich praktisch nie genau das gleiche Frame nochmal zu Gesicht. Ausserdem sieht's bei höherer Zoomstufe (mehr ins Detail gehen) auch wieder weniger hektisch aus, bringt aber enorme Variation ins Bild. Ich habe den Zoom im Video so gewählt gehabt, dass man auch etwas Überblick hat ;) . Dadurch dass ja praktisch alles parametrisiert ist, kann man sich's auch je nach Geschmack, Lust und Laune einstellen, von einer uniformen Fläche, welche einfach die Farbe fadet, bis eben zu sehr komplexen Plasma-Animationen ;) .


    Wie bekommst du eigentlich den Processing-Code auf den ARM? Gibts da ne C Exportfunktion oder hast du nen Java Interpreter drauf?


    Iiiiiiiiih, Java-Interpreter :D . Nein, ich setzte es 'von Hand' um. Ist aber auch keine so grosse Sache, denn Java ist ja von der Grundnotation her nicht so weit von C++ entfernt. Die ganzen Klassen und Methoden für's OpenGL-Rendering auf dem PC-Bildschirm und die Schieberegler etc. brauche ich ja nicht umsetzen, sondern nur den reinen Algo-Code, und das ist ja im Grossen und Ganzen einfach eine Ansammlung mathematischer Operationen und Funktionen. Natürlich gilt es dabei auch, Optimierungen für den µC zu machen (wie eben die Trigo-Funktionen mit entsprechenden Fliesskomma-LUTs zu ersetzen), aber das ist mehr oder weniger Erfahrungssache und trickreiche Programmierung (das kann einem sowieso keine Soft abnehmen). Ich habe zum Beispiel erst in Processing mittels Rundungen etc. getestet, wie weit ich eine SinusTab für meinen Algo diskretisieren darf, ohne dass dabei auch bei höchster Zoomstufe visuelle Artefakte (Auflösungsverluste) entstehen. Dabei habe ich gemerkt, dass selbst bei ein 20stel Grad Winkelschrittweite noch leichte Artefakte sichtbar sind. Deshalb verwende ich eben dann eine Sinustabellen-Auflösung in C von einem 100stel Grad (9000 Werte für eine Viertelperiode).


    Achso, hab mal nachgemessen. Die Math.h Funktion sin() mit Fließkommazahlen braucht bei 24 MHz ca. 75 us. Also theoretisch sind damit auch Operationen möglich, wenn man wie du Neni die Module auf 16*16 Pixel beschränkt gibt es auch noch ganz gute Frameraten


    Hmmm, das wäre aber dann gerade mal ein einzelner Sinus, und bei 256 Pixel mit einem Sinus pro Pixel wären das schon rund 19 ms. Und da hat man dann aber noch kein Plasma ;) . Ich hatte ja vor Jahren auch mal mit AVRs rumexperimentiert (AVR Mega), und dabei ist herausgekommen, dass bei einigermassen sinnvoll komplexem Plasma-Algo (weit entfernt vom heutigen SynPlasma) mit der Sin-Funktion aus math.h bei 20 MHz bei 49 Pixel (7 * 7 Matrix) in etwa Schluss ist, wenn man unter 30 ms pro Frame bleiben will.


    Gruss
    Neni

  • modulierst Du dann BRI und SAT auch noch per Algorithmus, also dem Plasma-Algorithmus, oder rechnest Du das irgendwie um, also die Ausgabewerte vom Plasma dann in *Kombinationen* von HUE, BRI und SAT..?


    Es werden BRI und SAT auch moduliert per Algo, zwar schon in Abhängigkeit vom jeweiligen Hue-Wert, damit's zum Plasma-Muster passt, aber es sind ansonsten unabhängige Modulationen.


    da wird Neni bestimmt auch ne höhere Bittiefe verwenden, nehme ich mal an...?


    Eigentlich habe ich in Processing den Farbraum extra auf ca. 23.5 Bit (Hue: 6 * 7 Bit = 6 * 127 = 762, Sat: 7 Bit = 127, Bri: 7 Bit = 127) beschränkt, weil ich's am Ende im C-Code in je 7 Bit RGB (21 Bit) umwandle und eine 7 nach 10 Bit Gammakorrektur mache. Nach den Erfahrungen mit dem Processing-Code kann ich sagen, dass Farbauflösungen von 7 und 8 Bit Pro Farbe absolut ausreichend sind, man sieht da kaum Nachteiliges. Viel wichtiger ist aber wie schon gesagt die diskrete Auflösung der Trigonometrischen Funktionen. Diese hat extremen Einfluss auf die 'Weichheit' der Animationen und den sinnvollen Einstellbereich der Modulationstiefe und -geschwindigkeit.


    Gruss
    Neni