Plasma Effekt für LED Matrix

Counterfeiter · 28. Dezember 2012

Hallo Forum, hab mir gerade für meine Matrix nen kleinen Plasmaeffekt ähnlich wie in Glediator erstellt.
Möchte natürlich nicht immer den PC dafür anhaben.

Infos dazu gibts hier:

http://lodev.org/cgtutor/plasma.html

Natürlich sind Fließkommazahlen und sinus Funktionen ganz schön harter Stoff für so nen kleines 8 Bit Rechenwerk.

Habe mir auch mal den Sourcecode von Glediator angeschaut, aber zwei Sinusfunktionen pro Pixel und noch eine pro Line lassen die Performance auch schnell sinken...

Komme mit dem Source von Pepe auf ca. 6 Bilder die Sekunde bei 24 MHz und ohne Prozessorlast um die Daten in die Matrix zu schauffeln, was bei ATMegas noch dazu kommt.

Also gibts jetzt stat Fließkommazahlen, ganze Zahlen und für die Sinusfunktion gibts ne LUT im Flash. Der Farbraum liegt auch im Flash wie die Gammakorrektur...

Letztendlich Schupst man ein paar Bits und schaut nur noch in den Tabellen nach den richtigen Werten...
Wie schnell das jetzt auf dem 24 MHz 8 Bitter läuft habe ich nicht gemessen. Aber irgendwas über 100 Bilder die Sekunde, denn ich seh die LED nicht mehr toggeln

Hier nun die Funktion:

Code

void float_the_plasma(uint16_t plasmacounter,uint8_t _x,uint8_t _y,type_rgb *buffer)
{




	for(uint8_t x=0;x<_x;x++) {
		for(uint8_t y=0;y<_y;y++) {

			uint8_t temp1 = (x<<4) + plasmacounter;

			uint8_t temp2 = (y<<5) + plasmacounter;

			uint8_t temp3 = ((x<<4) + (y<<4)) + (plasmacounter>>1);

			uint8_t temp4 = ((x*x)<<3 + (y*y)<<3) / (x+y+1);

			uint16_t color = 
			(((
			+ sin_lut(temp1)
			+ sin_lut(temp2)
			+ sin_lut(temp3)
			+ sin_lut(temp4)
			) >> 4) + plasmacounter) % 256*3;

			buffer[mapper(x,y)].r = gamma(add_color(color*3));
			buffer[mapper(x,y)].g = gamma(add_color(color*3+1));
			buffer[mapper(x,y)].b = gamma(add_color(color*3+2));


		}

	}

}

Alles anzeigen

Kann natürlich nach belieben angepasst werden, einfach die Funktionen in Temp1 bis 4 verändern...

Die Sinus_LUT und den Farbraum hänge ich mal als Datei an... die gamma LUT sollte klar sein und die mapper lookup table ist für die Anordnung meiner Matrixpixel zuständig. Das hängt ja dann auch von euch ab...

Ich poste das hier, weil ich noch keinen "schnellen" Source für 8 Bit Mirkrokontroller im Netz gefunden habe, aber vielleicht gibts auch schon was?!

Viel Spaß damit

Grüße

Basti

Pesi · 28. Dezember 2012

Coole Sache!

Neni hatte hier schon mal sowas veröffentlicht, war eben auch mit Ganzzahlen und dann LUT für den Sinus.... finde ich aber nicht mehr... (kann auch sein, dass er es mir mal per PN geschickt hat...)

damit das hier nicht auch untergeht, was dagegen, wenn ich es nach hier verschiebe....?

witziger Weise hatte Neni auch die selbe Quelle verlinkt - wo ja noch mehr Effekte drauf sind, wie das Feuer z.B. und auch ein "3D-Tunnel", das ist schon interessant, mal zu sehen, wie man sowas mit wenig Aufwand macht...

EDIT:

Zitat

Habe mir auch mal den Sourcecode von Glediator angeschaut

Ich dachte, das wäre nicht open source...

Counterfeiter · 28. Dezember 2012

Zitat von Pesi

damit das hier nicht auch untergeht, was dagegen, wenn ich es nach hier verschiebe....?

Klar, wenns da sicherer ist =)

Zitat von Pesi

witziger Weise hatte Neni auch die selbe Quelle verlinkt - wo ja noch mehr Effekte drauf sind, wie das Feuer z.B. und auch ein "3D-Tunnel", das ist schon interessant, mal zu sehen, wie man sowas mit wenig Aufwand macht...

Hab die Seite verlinkt, weil ich finde dort ist es super erklärt... gibt aber auch noch viele andere Seiten...

Die Seite erklärt aber leider nichts von Festkommazahlen, Sinus LUTs und Datentypenverwendung im 8 Bit-Raum... das kam dann von mir dazu... natürlich ist das alles etwas eingeschränkt auf dem Controller. Ich denke da kann man schon noch nen paar Berechnungen machen und auf 16 Bit hochgehen ohne das es große Einbußen gibt... Ist halt immer die Frage, was macht der Controller noch so und wie groß ist die Matrix

Zitat von Pesi

Ich dachte, das wäre nicht open source...

Hab ja auch nur den Source mal angetestet... werde da nix kopieren von (bringt ja eh keine Punkte auf dem auf nem Mega oder XMega). Aber prinzipiell ist Java eine Interpreter-Programmiersprache und der Bytecode lässt sich sehr gut rückübersetzen...

Grüße

Basti

Counterfeiter · 28. Dezember 2012

Na nu sieht die Unterhaltung ja komisch aus... kopieren geht wohl nicht

Pesi · 28. Dezember 2012

da ist wohl was schief gegangen...

hab's mal korrigiert, und diesen Thread dort verlinkt, falls jemand Nachfragen hat o.ä.

synvox · 29. Dezember 2012

Hallöchen,

ich befasse mich ja jetzt schon sicher mehr als drei Jahre mit dem Plasma-Effekt, auch im Bezug auf mein aktuelles Projekt, gerade weil ich eben diesen Effekt (durch einen Diffusor hindurch) als ideal für Lounge- und Stimmungs-Leuchten-Anwendungen und für entsprechende Leucht-Möbel (Tische) empfinde. Vorraussetzung ist natürlich, dass der Algorithmus komplex genug ist, um liquid aussehende, sich kaum wiederholende Animationen zu produzieren und trotzdem mathematisch so trickreich umgesetzt ist, dass ein µC es mit mindestens 30 - 50 fps berechnen kann (je nach Matrix-Grösse natürlich).
Mein Konzept ist in diesem Zusammenhang aber etwas anders, da bei mir auf jedem Matrix-Panel-Modul ein µC sitzt und 'nur' den jeweiligen Teilbereich des Gesamtpanels berechnen muss. In der aktuell in Entwicklung befindlichen Ausprägung umfasst ein einzelnes Matrix-Panel-Modul aber auch immerhin schon 16 x 16 RGB-Pixel, welche von einem µC berechnet werden müssen. Ein ARM Cortex M3 mit 100 MHz Core Clock schafft dabei ein Frame meines SynPlasma Algos in aktueller Ausprägung in weniger als 7 ms bei 16 x 16 Pixel. Ein popeliger 8-Biter wie der AVR wäre dabei gnadenlos überfordert.

Ich kann/möchte den SynPlasma Algorithmus aber nicht öffentlich machen (zumindest nicht solange ich kein fertiges Produkt habe), da es sich praktisch um mein wichtigstes 'Baby' und Frucht intelektueller Arbeit der letzen Jahre (natürlich nicht durchgehend) handelt. Es ist natürlich auch der Hauptbestandteil des aktuellen Projektes. Ich mein, die Hardware ist ja keine grosse Sache, die kann ja schnell mal einer kopieren, wenn er genügend Ahnung von Elektronik hat. Ich kann nur soviel sagen, dass der Algo einiges komplexer ist, als die Algos, die man üblicherweise auf Plasma-Info-Seiten findet(oder auch der Basis-Code in Processing etc.). Deshalb habe ich meinem Algo auch einen eigenen Namen gegeben .

Pesi, den Code den du gemeint hast, habe ich glaub nur dir persönlich mal geschickt, ist aber auch schon lange her. Da hatte ich ja auch noch mit AVRs rumexperimentiert. Mittlerweile ist das Ganze schon noch deutlich komplexer geworden. Die SynPlasma-Animation kann mittlerweile mit fast 40 Parametern beeinflusst, gesteuert und moduliert werden .

Basti, dein Ansatz gefällt mir. Zumindest ist es das, was man mit einem AVR noch hinkriegen kann, wenn man damit auch noch eine entsprechend hohe Anzahl Pixel berechnen möchte. Allerdings sind natürlich schon auch sehr starke Einschränkungen mit eingeflossen. Zum einen ist in deiner Sinus-Tab eine komplette Periode in 'nur' 256 Zeit-Punkte aufgelöst, was unter Umständen zu relativ groben Abstufungen im Plasma führen kann (gut, durch diffuses Plexi wird's dann ja verwaschen). Zum anderen kommt es bei deiner Implementation sehr schnell zu identischen Musterwiederholungen in der Animation, also wenn ich's richtig überflogen habe, spätestens alle 512 Iterationsschritte der Variable plasmacounter, was bei 30 fps ca. alle 17 Sekunden wäre. Ok, da ist noch das Farbapletten-Looping (bei dir alle 768 Schritte einmal durch), aber dabei bleibt das zugrundeliegende Muster ja gleich. Zugegebenermassen ist is das aber durchaus sinnvoll, um bei limitierter Rechenpower die Plasma-Animation etwas aufzupeppen , wurde ja früher von den DEMO-Codern (auf C64 und Amiga) auch gemacht.

Gruss
Neni

Pepe_1981 · 29. Dezember 2012

Hallo Basti,

für unsere Pingpong-Plasma-Wand hatte ich seinerzeit auch so einen Algo geschrioeben bei dem quasi *nur* die Farbpalette durchgeschoben wird. Die Sinus berechung ist ja dabei nur einmalig ganz am Anfang notwendig daher kann man sogar auf die LUTs ganz verzichten, denn einmal am Anfang kann man den µC schon rechnen lassen

Die eigentliche Animation des Plasma ist dann einfach nur _EINE ADDITION PRO PIXEL_

Ich habe es noch so gamacht das das Plasma über einer Zufallszahl von 5-20 Sekunden lang läuft und sich dann selbst neu berechnet (die Anfangsform). Und bei der Anfangsform werden auch die "Zellgröße" un x,y-Richtung neu ausgewürfelt.

Das ganze sieht in Quelltext so aus:

Code

void plasma (unsigned long duration, unsigned long frame_time)
{
  //Variables
  unsigned long end_time = millis() + (duration * 1000);
  byte pixel_size_x = random(2,7);
  byte pixel_size_y = random(2,7);

  //Pointer to frame
  static unsigned char *ptr_frame;

  //Calculate Plasma Geometry only ONCE
  for(byte y = 0; y < 16;  y++)
  {
    for(byte x = 0; x < 32; x++) 
    {
      dispmem[y*32 + x] = (byte) ((15+15*(sin(((float)x)/pixel_size_x)) + 15+15*(sin(((float)y)/pixel_size_y))) / 2);
    }
  }

  do
  {    
    ptr_frame = dispmem;



    //------ Das hier ist alles was für die Berechnung eines Frames notwendig ist :-)
    //------ Eine Addition pro Pixel
      for (byte y = 0; y < 16; y++)
      {
        for (byte x = 0; x < 32; x++)
        {
          if (*ptr_frame == 29) {*ptr_frame = 0;} else {*ptr_frame = *ptr_frame + 1;}
          ptr_frame++;
        }
      }
    //-----
    //-----


    unsigned long frame_end_time = millis() + frame_time;

    Enable_Low;

    while (frame_end_time > millis()) 
    {
      for (byte x=0; x<8; x++){refresh_leds_with_reduced_colors();}
    }

    Enable_High;

  } while (millis() <= end_time);
 
  //At the end of the plasma sequence fade all LEDs smoothly to red
  frame_time = 80;

  for (byte c=0; c < 30; c++)
  {
    ptr_frame = dispmem;

    for (byte y = 0; y < 16; y++)
    {
      for (byte x = 0; x < 32; x++)
      {
        if (*ptr_frame < 29) {*ptr_frame = *ptr_frame + 1;}
        ptr_frame++;
      }
    }

    unsigned long frame_end_time = millis() + frame_time; 
    Enable_Low;
    while (frame_end_time > millis()) 
    {
      for (byte x=0; x<8; x++){refresh_leds_with_reduced_colors();}
    }
    Enable_High;
  }

}

Alles anzeigen

#

EDIT: Hier das Video dazu:

http://www.youtube.com/watch?v…0&feature=player_embedded

Ab 2:50 sieht man das Plasma.

Beste Grüße,

Pepe

Pesi · 29. Dezember 2012

Auch interessant, wobei ich sagen muss (bitte nicht in den falschen Hals bekommen!) dass das für mich kein "richtiges" Plasma ist, weil da gehört m.M. nach schon dazu, dass sich die Form auch bewegt

Übrigens, wegen dem Schluß vom Video: Lasst Euch doch mal endorsen von Freiberger! - Ihr wärt doch echt ein gutes Aushängeschild für Basteln mit Bier!

Zitat von synvox

Zum einen ist in deiner Sinus-Tab eine komplette Periode in 'nur' 256 Zeit-Punkte aufgelöst, was unter Umständen zu relativ groben Abstufungen im Plasma führen kann

Hier könnte man mit relativ einfachen Mitteln noch die Auflösung steigern, ohne ne größere Tabelle anlegen zu müssen: Ein kompletter Sinus besteht ja aus 4 "Viertelbögen", die (punkt-)symmetrisch zueinander sind.

Es würde also reichen, in der Tabelle einen "viertelten Sinus" abzulegen, dann könnte man insg. 1024 Schritte durchgehen statt "nur" 256 - halt die Werte aus der Tabelle holen und je nach "Bereich" entsprechend umrechnen...

EDIT: musst mal gucken, ich glaub', bei mikrcontroller.net oder roboternetz gibt's da schon fertig so ne Tabelle inkl. Funktion, um aus nem übergebenen Wert 0-1023 den zugehörigen Sinus raus zu holen...

letztlich hängt's natürlich auch von der Geschwindigkeit und fps ab - hat man ne feste fps-Rate, und das Plasma wabert recht schnell, dann macht's ja sowieso "Sprünge" (die man aber bei hoher Frame-Rate nicht sieht) - aber bei nem gaaanz laaaangsaamen könnte das schon noch was bringen...

synvox · 30. Dezember 2012

Zitat von Pesi

Hier könnte man mit relativ einfachen Mitteln noch die Auflösung steigern, ohne ne größere Tabelle anlegen zu müssen: Ein kompletter Sinus besteht ja aus 4 "Viertelbögen", die (punkt-)symmetrisch zueinander sind.

Es würde also reichen, in der Tabelle einen "viertelten Sinus" abzulegen, dann könnte man insg. 1024 Schritte durchgehen statt "nur" 256 - halt die Werte aus der Tabelle holen und je nach "Bereich" entsprechend umrechnen...

Ja genau, das mache ich in meiner Umsetzung für den ARM Cortex M3 auch so. Allerdings teile ich dabei 90° (entspricht einer Viertelperiode) in 100stel-Grade auf, was dann 9000 Schritte für eine Viertelperiode (oder eben 36000 für eine volle) sind. Da ich aber für jeden Schritt in der LUT eine 32 Bit Fliesskommazahl (0 - 1) hinterlege, ergibt das trotzdem eine LUT von ca. 36 KB. Naja, wenn 512 KB Flash im µC zur Verfügung stehen, alles kein Problem .
Ich brauche natürlich diese Auflösungs- und Rechentiefe, weil bei meinem System mein SynPlasma Algo praktisch das Herzstück der Animationsgenerierung in den Modulen selbst ist und ich eben kein Pixel-Daten-Streaming von einem anderen System (PC oder was auch immer) aus mache. Da muss das natürlich für genügend weiche Animationen sorgen können, und das praktisch unabhängig von der 'Waber-Geschwindigkeit', wobei die fps-Rate aber konstant bleibt. Wenn das lokal berechnete Plasma mehr als 'nettes' Zusatzfeature eingeplant ist, wenn mal nicht der PC oder so angeschlossen wird, dann muss man natürlich einen solchen Aufwand nicht treiben.

Muss mal schauen, ob ich im WWW nen Screencapture-Video-Tool für lau finde, dann könnte ich mal ein Beispielvideo von den SynPlasma-Animationen posten, da ich ja den Algo und jede diesbezügliche Erweiterung in Processing (JAVA-Wrapper) auf dem PC entwickle und teste, bevor dann die Adaptation und Optimierung in C++ für den ARM erfolgt.

Gruss
Neni

stromflo · 30. Dezember 2012

Hallo synvox,

eventuell hilft dir da das Tool Winkweiter.

Gruß Flo

Counterfeiter · 30. Dezember 2012

Ui, hier gehts ja ab... sehr schön... so ne paar Infos zum Plasmaeffekt auf dem Forum sind ja schon ganz nützlich...

Zitat von Pepe_1981

für unsere Pingpong-Plasma-Wand hatte ich seinerzeit auch so einen Algo geschrioeben bei dem quasi *nur* die Farbpalette durchgeschoben wird. Die Sinus berechung ist ja dabei nur einmalig ganz am Anfang notwendig daher kann man sogar auf die LUTs ganz verzichten, denn einmal am Anfang kann man den µC schon rechnen lassen

Ja, dass Problem ist nur, dass die Tabelle dann im RAM liegt... ich will sie aber im Flash und bereite so was mit Excel vor...

Sieht zwar auch schick aus, aber so richtig Plasma isses wirklich nich... muss schon ein weniger wabbern, wie du es in Glediator gemacht hast...

synvox Ich bin auch noch nicht 100% zufrieden mit meinem Plasma, aber ich werde da bei Gelegenheit mal noch nen bisschen dran drehen... (größere Datentypen, mehr Berechnungen), aber für so nen kleiner 8 Bitter ist das schon gar nicht mal schlecht geworden.

Schreibe auch immer zuerst in C ein Konsolenprogramm bevor es auf den Controller geht... so bleibt der dev-Aufwand schön klein.

Wieso Cortex M3? Wenn schon ARM, dann kannst du doch gleich den M4 nehmen, der hat doch direkt ne FPU dabei... genial... Hab hier auch noch dev-Boards im Schrank liegen, fand aber das es etwas Overkill für nen einfaches Plasma ist. Aber ist halt immer die Frage nach dem Anspruch an die Größe und Optik der Matrix.
Würde mich schon mal sehr interessieren dein Desktopvideo, obwohl das sicher nicht so gut verläuft wie unter dem Plexi... aber das könnte man ja auch mit einprogrammieren (in das Desktop Programm).

Ja bei meinem Algo tut sich von der Animation nicht sooo viel (bis jetzt) aber man sieht schon das Plasma wandern. Werde nachher gleich mal nen Benchmark vom obigen Source machen und dann sehen wieviel bei 288 Pixeln noch so geht.

Der Sinus ist bei mir 180° in 256 Schritten also 0,7°... dachte das reicht vielleicht? Beschäftige mich aber auch ehrlich gesagt ca. den 3 Tag mit Plasma... Bin da noch nicht so firm drin und nehme gern Tipps an, wie man obigen source noch plasmatischer bekommt
Achso, die Tabelle mit 256 Schritten hat nen ganz einfachen Hintergrund... die 8 Bit Variablen laufen einfach über, so wie es die Gradzahlen bei 360° bzw 180° auch tun würden... Fazit ist ein sehr schnelle Berechnung (quasi, keine Zusatzberechnung)... ich hab schon nen paar Dinge bei gedacht

Finde auch das der Plasmaeffekt auch einer der besten Animationen ist. Der wirkt so beruhigend und unter verlaufenden Pixeln kann man soviel künstliche( Auflösung aus einer Matrix holen...

Grüße

Basti

P.S. Ich suche noch Infos zu einem einfachen Welleneffekt der an einem Punkt startet. Hat dazu jemand schon was gemacht oder kennt ne gute Seite?

P.S. 2: Mal nachgemessen: Obiger Source braucht auf einem 24 MHz XMega und SPI Ausgabe über DMA bei 288 Pixeln ca. 7 ms ~> 130 Hz. Bei einer 16*32 = 512 Pixel Matrix genau 12,5 ms ~> 80 Hz
Fazit, auf dem AtMega ist hier sicher die Grenze für 25 Bilder erreicht, da dieser ja kein DMA hat und die Daten mit dem Prozessor per SPI raus schieben muss. Beim XMega sind noch leichte Veränderungen zu besseren Animationen möglich.

Pesi · 30. Dezember 2012

Na, 512 Pixel mit 80 fps ist doch echt ordentlich!

ich bin mir nicht ganz sicher, meinst Du, der Compiler schnallt das, dass die Rechnung hier:

Zitat

% 256*3

am schnellsten geht, wenn man das HB nimmt (= / 256) und dann mal 3 rechnet (1 Takt mit HW-Multiplikation)...?

weil es könnte ja auch sein, dass der stur erst mal die Konstante ausrechnet, ah, ja, 256*3 = 768, und dann jedes mal ne SW-Divsion aufruft, die das durch 768 teilt, was natürlich deutlich länger dauert...

k.A., ob der so schlau ist, dass er bei bestimmten Zahlen oder eben ner Angabe wie 256*3 statt 768 zu nehmen das dann so macht, also HB nehmen und dann multiplizieren....?

ansonsten könnte man ihm das ja selbst "beibringen" mit irgendsowas wie erst >>8 und dann *3 (oder so, bin kein C-Profi).

auch k.A., ob der das zwischendurch im RAM speichert, oder alles (temp) in Registern rechnet...? - in asm würde ich das halt in nem "16-Bit-Register" zam addieren, und dann das HB mal 3 rechnen = 1 Takt...

aber auch 25 fps bei 512 Pixel auf nem normalen ATMega ist schon ordentlich, keine Frage!

Zitat von Counterfeiter

Der Sinus ist bei mir 180° in 256 Schritten also 0,7°...

Bist Du Dir sicher..? - ich bin kein Mathe-Genie, aber wenn ich mir die Zahlen so ansehe, müsste das doch der rot markierte Ausschnitt sein, also schon ne ganze 360°-Periode:

Du hast ja auch zweimal nen "Nulldurchgang" bei ca. 512... wenn sich das bei 180° wiederholen würde, müste es ja auch irgendwo springen....?

ich hab' mir übrigens mal überlegt wegen der 1/4-Tabelle, ich würde da das erste Viertel abspeichern, der Winkel (10 Bit, 0-1023) wird in nem "16-Bit-Register" (z.B. X) übergeben - dann sind die untersten 2 Bit von XH praktisch das Viertel, in dem man sich befindet, und XL die Position innerhalb des Viertels:

dann muss man nur Bits auswerten, also wenn Bit 0 von XH "0" ist, dann hole ich "Tabelle [XL]", wenn's 1 ist, dann "Tabelle [255-XL]" - ist Bit 1 von XH "0", dann anschließend 511+geholter Wert, wenn das Bit "1" ist, dann 512-geholter Wert, die Werte in der Tabelle dabei von 0-512

das sollte ja auch nicht soo lange dauern, ein paar Takte mehr für die Abfrage wie die Bits gesetzt sind, und dann noch ne Addition/Subtraktion...

P.S.: Ich muss das mal ausprobieren - könnte mir vorstellen, dass das auf dem Mega (wegen kein DMA) noch mal was bringt, wenn man jedes berechnete Byte gleich an den SPI ausgibt, statt erst alles in einen Buffer zu schreiben und dann auszugeben... aber wie gesagt, 512 Pixel bei 25 fps würden mir *dicke* reichen...

Pesi · 30. Dezember 2012

Ach, jetzt ist mir auch klar geworden (manchmal dauert's bisschen länger bei mir ;)), was Du mit

Zitat von Counterfeiter

Achso, die Tabelle mit 256 Schritten hat nen ganz einfachen Hintergrund... die 8 Bit Variablen laufen einfach über, so wie es die Gradzahlen bei 360° bzw 180° auch tun würden... Fazit ist ein sehr schnelle Berechnung (quasi, keine Zusatzberechnung)... ich hab schon nen paar Dinge bei gedacht

meinst - Du meinst diese Stellen hier:

Zitat von Counterfeiter

uint8_t temp1 = (x<<4) + plasmacounter;

Wo dann die Gradzahlen überlaufen, weil ja nur 8-Bit-Variable....?

klar, da ist's dann bei 10 Bit natürlich deutlich aufwändiger, den Überlauf festzustellen und die Gradzahl anzupassen, klar, das frisst dann noch mal ordentlich Rechenleistung...

also, auf nem 8Bitter lieber 8 Bit für die 360°, stimmt schon....

die 10 Bit in der LUT haben aber schon ihre Berechtigung, oder..? - weil Du ja praktisch erst mal "feiner abgestufte" Werte addierst, und dann "rundest" (durch das rechts shiften), also so ne bessere Auflösung bekommst, als vorher "gerundete" 8-Bit-Werte zu addieren, sehe ich das richtig...?

ich werd' das dann mal auf nem Mega in asm probieren, gleich mit Deinen Tabellen...

Counterfeiter · 30. Dezember 2012

Hallo Pesi...

*edit*
Ne stimmt, der Sinus ist 360 Grad... jetzt in dem Source... das hatte ich auch erst anders... also 1,4° pro Zelle...
Ich weiß schon was du meinst, mit bloß 90 Grad ablegen, aber was soll schon der erhöhte Rechenaufwand, im Flash ist doch meist genug Platz. An der Stelle muss man IMO nicht geizen...

Die 1024 für Sinus waren anfänglich zum spielen gedacht, also hier und da nochmal anders shiften usw. Beim aktuellen Code braucht man diese Auflösung nicht, weil ich wieder 4 rechts schiebe. Aber da auch bei 255 + 255 mit 16 Bit gerechnet werden muss, hab ich das hier nicht so eng gesehen und das so gelassen. Vielleicht shiftest du es ja nochmal anders...

Zur Zeit sieht das Plasma noch ein wenig wolkig aus, also an manchen Ecken etwas ausgefranzt. Ich denke das die Plasmazellen dort zu eng beieinander liegen oder die wenige Auflösung. Vielleicht hast du ja noch eine Idee wie man das abändert, wenn du den Source probierst.

*edit 10.000* achso, jetzt versteh ich was du meinst... Weiß nicht genau was der C Compiler in ASM daraus macht, aber % * und / haben den selben Rang...

Grüße

Basti

PS. Entschuldigt meine Verwirrung, habe heute eindeutig zu lange in mein Plasma geschaut

Pesi · 30. Dezember 2012

Zitat von Counterfeiter

Zur Zeit sieht das Plasma noch ein wenig wolkig aus, also an manchen Ecken etwas ausgefranzt. Ich denke das die Plasmazellen dort zu eng beieinander liegen oder die wenige Auflösung. Vielleicht hast du ja noch eine Idee wie man das abändert, wenn du den Source probierst.

Ja, mal sehen, Problem i.M., ich hab' gerade nur ne Matrix mit 6x5 da, k.A., ob da so ein Bereich überhaupt auftaucht...? - ich brauch' auch mal was mit 16x16 oder 32x16 für Zuhause zum Basteln...

von der Theorie her k.A. - könnte schon an der Auflösung und Bitgeschiebe liegen (der y-Wert z.B. springt ja durch das <<5 von 16 auf 32 auf 48, ... während die Schleife von 1, 2, 3... durchläuft) - aber das lässt sich ja nicht vermeiden, das legt ja die Größe der Zelle fest...

oder es ist irgendwo ne "Stufe", in der Sinus- oder Farbtabelle...

übrigens habe ich mal die Tabelle für asm "umgeschrieben", und auch gleich "richtig" anfangen lassen (klar, für's Plasma ist das wurscht, aber wenn man's mal für was anderes braucht, kann das schon verwirrend sein, dass bei Deiner Tabelle sin(0) dann nicht auf der "Nullinie" liegt, sondern der untere Scheitelpunkt ist):

Code

; ================================================================================================
; Sinus-Tabelle
; 256 Werte auf 360° (1,4° Abstufung)
; Eingabe 8 Bit (0-255), Ausgabe 10 Bit (0-1023)
; berechnet von Basti (User "Counterfeiter" bei Ledstyles.de)
; ================================================================================================


Sinus_Table_8x10:


.dw		512,	524,	537,	549,	562,	574,	586,	599
.dw		611,	623,	636,	648,	660,	672,	684,	695
.dw		707,	719,	730,	741,	752,	763,	774,	785
.dw		795,	806,	816,	826,	836,	845,	855,	864
.dw		873,	882,	890,	899,	907,	914,	922,	929
.dw		937,	943,	950,	956,	962,	968,	974,	979
.dw		984,	989,	993,	997,	1001,	1004,	1008,	1010
.dw		1013,	1015,	1017,	1019,	1020,	1022,	1022,	1023
.dw		1023,	1023,	1022,	1022,	1021,	1019,	1018,	1016
.dw		1013,	1011,	1008,	1005,	1001,	997,	993,	989
.dw		984,	979,	974,	969,	963,	957,	951,	944
.dw		937,	930,	923,	915,	908,	899,	891,	883
.dw		874,	865,	856,	846,	837,	827,	817,	807
.dw		797,	786,	775,	765,	754,	743,	731,	720
.dw		708,	697,	685,	673,	661,	649,	637,	625
.dw		613,	600,	588,	575,	563,	551,	538,	525
.dw		513,	500,	488,	475,	463,	450,	438,	426
.dw		413,	401,	389,	377,	365,	353,	341,	329
.dw		317,	306,	294,	283,	272,	261,	250,	239
.dw		229,	218,	208,	198,	188,	179,	169,	160
.dw		151,	142,	134,	125,	117,	109,	102,	94
.dw		87,	80,	74,	67,	61,	55,	50,	45
.dw		40,	35,	31,	26,	23,	19,	16,	13
.dw		10,	8,	6,	4,	3,	2,	1,	0
.dw		0,	0,	1,	1,	2,	4,	5,	7
.dw		9,	12,	15,	18,	21,	25,	29,	33
.dw		38,	43,	48,	54,	59,	65,	72,	78
.dw		85,	92,	99,	107,	115,	123,	131,	139
.dw		148,	157,	166,	175,	185,	195,	205,	215
.dw		225,	236,	246,	257,	268,	279,	290,	302
.dw		313,	325,	337,	348,	360,	372,	385,	397
.dw		409,	421,	434,	446,	459,	471,	484,	496


; ================================================================================================

Alles anzeigen

~~da ist mir aufgefallen, der Wert 0 (unterer Scheitelpunkt) kommt nur 3x vor, der Wert 1023 (oberer Scheitelpunkt) dagegen 7x - so ganz symmetrisch ist das also nicht~~

EDIT: Neue, verbesserte Tabelle eingefügt

aber k.A., was das Excel da gerechnet hat, und ob das "ausgefranste" evtl. auch daran liegen könnte....?

synvox · 31. Dezember 2012

Zitat von Counterfeiter

Wieso Cortex M3? Wenn schon ARM, dann kannst du doch gleich den M4 nehmen, der hat doch direkt ne FPU dabei... genial... Hab hier auch noch dev-Boards im Schrank liegen, fand aber das es etwas Overkill für nen einfaches Plasma ist. Aber ist halt immer die Frage nach dem Anspruch an die Größe und Optik der Matrix.

Naja, da bei mir je ein µC pro Modul zum Einsatz kommt, sind die Kosten pro Chip (und auch der Stromverbrauch pro Chip bei Vollast) schon auch ein Thema, wenn ich das Ganze mal für den Verkauf produzieren möchte. Ausserdem reicht ein Cortex M3 hier locker für eine 16 x 16 Matrix pro Modul auch bei komplexen Algorithmen, und 16 x 16 ist in meinen Augen gerade ideal für ein einzelnes Modul mit 80 x 80 mm Grösse (also 5 mm Pixelabstand). Ausserdem kenne ich den LPC1768 jetzt schon sehr gut, weiss wo die Stärken und wo die Macken sind, was man vermeiden sollte etc. Und nicht zuletzt nutze ich ein sehr gutes, einfaches Entwicklungssystem dafür (mbed), welches ich mittlerweile sehr lieb gewonnen habe .

Zitat von Pesi

weil es könnte ja auch sein, dass der stur erst mal die Konstante ausrechnet, ah, ja, 256*3 = 768, und dann jedes mal ne SW-Divsion aufruft, die das durch 768 teilt, was natürlich deutlich länger dauert...

Na ich würde ja schon hoffen, dass er zuerst die Konstante berechnet und dann eben modulo 768 und nicht zuerst modulo 256 und dann mal 3 rechnet, weil das ist keinesfalls das selbe. Im zweiten Fall würde man immer in 3er-Schritten durch den hinterlegten Farbraum scrollen, was ja Farbraumauflösung verschenkt. Allerdings mathematisch formal korrekt müsste man 256*3 in Klammern setzen, wenn man sicher sein will, dass alle Compiler das so machen ( modulo 768 ).

Es gibt bei der aktuellen Implementation einiges, was es generell zu bedenken gilt. Die Colorspace-Table ist in diesem Fall ja im Prinzip eine HSV-Farbraum-Palette mit fixem S und V (auf maximum), man kann es also als Hue-Table sehen. Dabei hat eine Hue-Table, welche RGB-Werte von 0 bis 255 beinhaltet, aber eigentlich 'nur' 765 (=3*255) Elemente (bzw. 1530=6*255, falls man nicht wie hier die auf 'konstante' Lichtemission normierte Version verwendet). Die 768 Werte werden hier dadurch 'erreicht', dass jeweils die Einzelfarben (Rot allein, Grün allein, Blau allein) doppelt in der Tabelle vertreten sind, was streng genommen eben nicht ganz korrekt ist.
Was die Auflösung betrifft, ist es eben so, dass bei einer Schrittweite von 1.4° sich im schlimmsten Fall (dort wo beim Sinus die Steigung am höchsten ist) die Werte um 0.024 ändern (Sinus von -1 bis 1), also Änderungen von 2.4 % vom Skalierwert (bei 0 bis 1023 also rund 12). Je nach Grösse der Farbtabelle, der Modulationstiefe (Sinus-Plasma-Algo-Teil auf Farbtabelle), der Zoomstufe (reziprok der Zellengrösse) und der Geschwindigkeit der Animation können da schon gut sichtbare Artefakte entstehen.

Persönlich würde ich als Ansatz für erste Korrekturen die Colorspace-Table auf 765 Elemente bringen (Doppelungen rausnehmen), dann den Sinus in der Vorberechnung der LUT so skalieren, dass sich die Werte von 0 bis 764 bewegen, also skaliert mit 382 und Offset 382. Dann würde ich das Ergebnis der vier Sinus-Additionen durch vier teilen (also >> 2) und nicht durch 16 (>> 4). Damit hat man dann auf jeden Fall die volle Modulationstiefe (kann man immer noch verringern, wenn man möchte) des Plasmas auf den zugrundeliegenden Farbraum . Dann noch plasmacounter hinzuzählen und modulo 765 ausführen.

Ich habe jetzt ein Screencapture-Proggi gefunden (http://camstudio.org/), werde also demnächst mal ein kleines Demo-Video meines SynPlasma Algos erstellen. Dank auch an stromflo für den Vorschlag, aber ich hatte das Proggi hier kurz vorher gefunden gehabt, deshalb habe ich nicht weiter ausprobiert.

Gruss
Neni

Counterfeiter · 31. Dezember 2012

Zitat von Pesi

da ist mir aufgefallen, der Wert 0 (unterer Scheitelpunkt) kommt nur 3x vor, der Wert 1023 (oberer Scheitelpunkt) dagegen 7x - so ganz symmetrisch ist das also nicht

aber k.A., was das Excel da gerechnet hat, und ob das "ausgefranste" evtl. auch daran liegen könnte....?

jetzt haste mich beim Schludern erwischt Hab mir da keine Gedanken drüber gemacht und einfach die 1024 die ja bei 10 Bit nicht sein sollten zu 1023 gemacht... wie das immer so ist, sagt man sich: Das kannste später noch ordentlich machen
Das wolkige liegt jedenfalls nicht daran, der Sinus sieht immer noch schön rund aus Hab dir die bessere Tabelle mal per PM geschickt, dann kannste ja auch die Tabelle oben anpassen.
Mein Name muss für die 30 Sekunden Excel auch nicht so gehuldigt werden
So einfach sieht das dann in Excel aus, wenn man sich daneben 0 bis 255 runterzieht: =((SIN(H8*1,405*3,14159265/180)+1)*511,5)

Zitat von synvox

Na ich würde ja schon hoffen, dass er zuerst die Konstante berechnet und dann eben modulo 768 und nicht zuerst modulo 256 und dann mal 3 rechnet, weil das ist keinesfalls das selbe. Im zweiten Fall würde man immer in 3er-Schritten durch den hinterlegten Farbraum scrollen, was ja Farbraumauflösung verschenkt. Allerdings mathematisch formal korrekt müsste man 256*3 in Klammern setzen, wenn man sicher sein will, dass alle Compiler das so machen ( modulo 768 ).

Nein, wie schon geschrieben sind %, * und / gleichrangig und es wird erst das Highbyte genommen und dann mal 3 gerechnet. Geht auch viel schneller, wird aber Farbraum verschenkt. Klar könnte man jetzt die Palette in 256 Farbkombinationen packen, aber wie gesagt, zum Probieren hab ich das alles mal so gelassen. Es gibt ja noch tausend andere Kombinationen und mal ehrlich, wer setzt sich von euch hin und arbeitet erst eine Formel sauber aus geht an den PC und es sieht sofort super aus?!

Hier z.B. mal eine Variante die sehr sehr ähnlich aussieht und Modulo mit 768 ausführt:

Code

uint16_t color = 
			(((
			+ sin_lut(temp1)
			+ sin_lut(temp2)
			+ sin_lut(temp3)
			+ sin_lut(temp4)
			+ plasmacounter << 2
			) >> 4) ) % (256*3);

Zitat von synvox

Persönlich würde ich als Ansatz für erste Korrekturen die Colorspace-Table auf 765 Elemente bringen (Doppelungen rausnehmen), dann den Sinus in der Vorberechnung der LUT so skalieren, dass sich die Werte von 0 bis 764 bewegen, also skaliert mit 382 und Offset 382. Dann würde ich das Ergebnis der vier Sinus-Additionen durch vier teilen (also >> 2) und nicht durch 16 (>> 4). Damit hat man dann auf jeden Fall die volle Modulationstiefe (kann man immer noch verringern, wenn man möchte) des Plasmas auf den zugrundeliegenden Farbraum . Dann noch plasmacounter hinzuzählen und modulo 765 ausführen.

Ja das klingt gut, hatte schon ähnliche Gedanken. Meine Idee war es noch den Farbraum größer zu skalieren (klar gibts dann dopplungen). Sagen wir auf 1024. Dann brauch ich auch nur noch zwei rechts shiften nach den 4*sinus und das Modulo vereinfacht sich wieder zu Schiebeoperationen und muss nicht mit "ungünstigen" 768 arbeiten... muss aber sicher die color Variable auf 32 Bit aufbohren, das dann wiederum Probleme mit Farbpalette verursachen könnte. (kein natürlicher Überlauf)

Ja man kann so einiges noch tun, dass vielleicht auch das schöne am Plasma... mit einer FPU wäre es doch auch irgendwie zu einfach

Grüße

Basti

P.S: HSV-Farbraum-Palette... hm... da bin ich noch etwas zu neu im "Grafikgeschäft", habe zwar schon darüber gelesen aber noch keine Gedanken weiter drüber gemacht...

Pesi · 31. Dezember 2012

Zitat von synvox

Na ich würde ja schon hoffen, dass er zuerst die Konstante berechnet und dann eben modulo 768

ach so, das % bedeutet modulo, nicht dividieren...? - wie gesagt, in C kenne ich mich nicht so gut aus....

Zitat von Counterfeiter

Mein Name muss für die 30 Sekunden Excel auch nicht so gehuldigt werden

Naja, ist ja keine Huldigung, nur ne Erwähnung - das mache ich immer so (keine fremden Federn anheften), egal wie aufwändig, die Tabelle ist von Dir, also steht das auch drin...

hab's oben mal ausgetauscht - witzig übrigens, wenn man die Tabelle ohne Tabulatoren macht, ergibt sich rein durch die unterschiedlichen Zahlenlängen schon ein sinus*ähnlicher* Verlauf der Zeilenlängen:

Pesi · 31. Dezember 2012

Bin gerade beim Programmieren (muss heute zuhause bleiben, wegen nervösem Hund :D) und da ist mir noch was eingefallen: Das durchscrollen der Farbpalette machst Du ja da in der "Formel", indem Du zur per Sinuswellen erzeugten Farbe in Zeile 22 immer noch "plasmacounter" dazu addierst, also bei jedem Durchlauf dann die nächste Farbe nimmst, richtig...?

Also das "wabern" der Form und das scrollen der Farben läuft synchron...?

da könnte man auch eine zweite Variable für das Farbscrollen benutzen, die man unabhängig von Plasma-Counter (der für die Form zuständig ist) hochzählt, und hätte so gleich ohne viel Aufwand mehr Variationsmöglichkeiten - z.B. das Plasma wabert langsam und die Farbe läuft schnell drüber, oder das Plasma wabert hektisch, ändert aber nur langsam seine Farbe, etc.

werde ich mal machen, aber ich probiere das erst mal mit 8-Bit-Tabelle und alles etwas einfacher, ist nun irgendwie nicht so sinnvoll, dass ich Deine Routine 1:1 in asm übersetze, das werde ich dann wohl die nächsten Tage endlich mal zum Anlaß nehmen, mein erstes C-Programm anzufangen (Plasma auf SEDU mit Deinem Algorithmus ;))

Counterfeiter · 1. Januar 2013

Hallo Pesi,

ich kenn da noch einen der C Programme in ASM wandeln kann und das in wenigen Sekunden. Da brauchst du dir die Arbeit nicht machen
Ich hab mal die Funktion in asm als Textdatei angehangen, vielleicht steigst du ja da durch

Ja die könnte man auch async. zählen lassen, dass geht und macht nicht viel mehr Aufwand. 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.... Ich denke, darin besteht am ehesten Optimierungsbedarf und da wäre man mit ASM nicht mal schlecht dran. In GCC gibt es leider keine 24 Bit Variable und in 8 Bit ASM schreibt man sich ja so was eh selbst.

Grüße

Basti

Plasma Effekt für LED Matrix

Teilen

Benutzer online in diesem Thema