Bernhard Häussner
Tags: Artikel mit dem Tag «Videos» durchstöbern

5gon

21.01.2011, 18:45
5gon-no1-seq01-0001-blackCrystal-w1

5gon-no1-seq01-0001-blackCrystal-w1

Im Rahmen meiner Studien zu Pentagrammen, Fünfecken, und ähnlichem sind ein paar interessante Geometrische Figruen entstanden.


Pentagramm [5gon-no3-seq01-all]

Dodecaicosahedron (seq4)
Kommentare: keine

Drehmomente und Kräfte mit Processing

20.04.2010, 14:57

Zu meinem Blogeintrag mit Stills aus den Physik-Inspirierten Processing-Sketches wollte ich noch einiges zur Methodik, Physik und Umsetzung notieren.

Achtung: Was hier steht muss nicht alles wissenschaftlich korrekt sein. Ich habe zwar bei einem Mathe-/Physiklehrer über die Grundprinzipien referiert, das schließt natürlich Mängel nicht aus. Der interessierte und/oder fachundige Leser kann ja einen Kommentar hinterlassen, falls Klärungsbedarf besteht. Mir fehlt leider die Zeit, alles nachzuprüfen.

Einführung und Methodik

Dies ist ein Antwortversuch auf die Frage, wie sich ein starrer Körper verhält, wenn auf eine Kraft - nicht am Schwerpunkt - einwirkt. Ich versuchte das Zusammenspiel aus Rotation und Translation zu beschreiben.

Im Lehrplan Physik steht ein ganzer Haufen einfachster Formeln für ein paar wenige Spezialfälle. Man lernt recht viel über Kräfte, Drehmoment, Federn, Druck, Optik, ein bisschen Wärmelehre und Energie. Dann noch ein paar Dinge mit Elektronen, die man als Grundwissen für die Kernchemie braucht. Dumm nur, dass man das alles Stückchenweise beigebracht bekommt, und vor allem ohne dabei die Rechentechniken dahinter zu beherrschen. Integrale und Vektoren lernt man erst in der Mathematik der Kollegstufe komplett. Jetzt, wo ich einigermaßen rechnen kann, habe ich aber kein Physik mehr. Trotzdem will ich noch ein bisschen aus meinen Physik-Kenntnissen schöpfen, zumal sich mit physikalisch inspirierten Berechnungen interessante Simulationen am Computer erstellen lassen.

Erstaunlich zutreffend stellt Wolf Wagner in „Uni-Angst und Uni-Bluff“ fest:

»Das Lesen und Lernen ohne eigene Fragestellung ist also nicht nur ineffektiv. Es ist auch anstrengender, weil Langeweile die Konzentration erschwert «
Wagner, Wolf:
Uni-Angst und Uni-Bluff. Wie studieren und sich nicht verlieren,
Hamburg 2002. S. 105.

Da kam mir eine Fragestellung gerade recht. Die schiefe Ebene, der Kraftstoß und einiges anderes wurde ausführlichst behandelt. Jedoch greifen alle Kräfte (engl. force) immer am Schwerpunkt an. Zwar habe ich auch mal etwas vom Drehmoment (engl. torque) gehört und sogar die Veränderung des Trägheitsmoments (engl. rotational inertia) in Kindheitsjahren auf einem Karussell zu spüren bekommen, doch eine Synthese dieser sämtlichen Bewegungsparameter fehlte immer: Was passiert, wenn eine Kraft eben nicht am Schwerpunkt angreift?

Nach ein paar Feldversuchen hat man ungefähr das Bewegungsverhalten wie im folgenen Video im Kopf. Feldversuche hieß für mich mit einem Zirkel (genauer: seiner Nadel vorne) einen Bierdeckel auf dem Tisch herum schleifen. Wegen unpräziser Motorik und störender Reibung habe ich mich aber dann auf die Computersimulation verlagert. Um die Thesen zu bestätigen müsste ich das Experiment vielleicht auf einem Air Hockey filmen. So oder so ergibt sich wohl keine genaue experimentelle Bestätigung, aufgrund der feinen Abhängigkeit von der Startparametern. Jedoch kann man versuchen den Bewegungsablauf auf Energieerhaltung zu prüfen, wo die einzelnen Formeln experimentell bestätigt werden können.


Simulation mit 1 Scheibe

Man überlegt sich schnell, dass die Kraft wohl in eine Translations-Komponente und eine Rotations-Komponente zerlegt werden muss. Die Translationskomponente deutet vom Schwerpunkt weg (Der Physiker nennt das: Die Wirkungslinie verläuft durch den Schwerpunkt) und die Rotationskomponente verläuft senkrecht dazu. Mit der Translationskomponente kann man dann (hoffentlich) wie gewohnt weiter rechen. Also die Kraft wirkt auf die Masse und bewirkt eine Beschleunigung (engl. acceleration), die die Geschwindigkeit (engl. velocity) verändert, und diese wiederum die Position.

Bei dieser Prozedur muss man stets integrieren. Weil das nicht ganz einfach ist (und mit dem Computer nicht mit einfachsten Mitteln lösbar) bedient man sich der „Eulermethode“. Den Begriff habe ich so im Englischen gefunden - bei uns: „Methode der kleinen Schritte“. Pro „Frame“ addiert man die Beschleunigung auf die Geschwindigkeit, und diese wieder auf die Position, die Faktor Zeit wir im einfachsten Fall in Frames gemessen und fällt als 1 Frame weg. Dabei muss man sich um wenig rechnerisches kümmern, und wenn man die Schrittchen sehr klein macht (ich habe eine Euler-Auflösung eingebaut, die ich anpassen kann, um genauer oder schneller zu rechnen) extrapoliert sich das System irgendwann mit zufriedenstellender Genauigkeit.

Für die Drehung muss man die Restkraft einberechnen. Da funktionieren die altbekannten Formeln zum Drehmoment. Jedoch fehlte mir zunächst das Rotationsäquivalent zu Masse. Interessanterweise hängt dieses nicht nur von der Masse, sondern auch von der Entfernung zum Dreh-/Schwerpunkt ab. Grob gesagt: Doppelt so weit entfernte Masse macht viermal so viel Ärger (also ein n²-Gesetz, ähnlich dem vom Strahlenschutz bekannten Abstandsquadratgesetz nur nicht reziprok). Die Berechnung läuft also auf das Integrieren eines Parabel-Rotationskörpers (um die y-Achse) hinaus.

Jetzt wird zum ersten Mal einbezogen, wie der Körper eigentlich aussieht, also wie die Masse um den Schwerpunkt und die Drehachse verteilt ist. Da die Prozedur zur Übersicht zweidimensional bleiben soll und wegen der Berechnung des Trägheitsmoments wählt man eine Scheibe mit konstanter Dichte, also gleich verteilter Masse. Dann überlegt man sich das Trägheitsmoment:

Kleine Formelsammlung

Trägeheitsmoment J der Masse m mit Abstand zur Drehachse r einer Scheibe mit Volumen V, konstanter Dichte ρ, Radius r', Höhe h und Grundfläche A.

Trägeheitsmoment J der Masse m mit Abstand zur Drehachse r einer Scheibe mit Volumen V, konstanter Dichte ρ, Radius r', Höhe h und Grundfläche A.

Auf Wikipedia bin ich auf diese Vereinfachung aufmerksam geworden:

Mit diesem Trägheitsmoment kann man jetzt endlich rechnen. Wie die Natur so will, bzw. die Mathematik vereinfacht, verhalten sich Rotation und Translation analog:

Analogie von Rotation und Translation: <br/>Beschleunigung a ~ Winkelbeschleunigung α<br/>Geschwindigkeit v ~ Winkelgeschwindigkeit ω<br/>Position x ~ Ausrichtung φ<br/>Kraft F ~ Drehmoment M<br/>Masse m ~ Trägheitsmoment J

Analogie von Rotation und Translation:
Beschleunigung a ~ Winkelbeschleunigung α
Geschwindigkeit v ~ Winkelgeschwindigkeit ω
Position x ~ Ausrichtung φ
Kraft F ~ Drehmoment M
Masse m ~ Trägheitsmoment J

Weil konstante Kräfte eher unspektakulär sind und sich vor allem die betroffenen starren Körper unendlich weit bewegen, halten wir sie mit einer Feder im Rahmen.

Hookesches Gesetz mit Federhärte d und Auslenkung Δl

Hookesches Gesetz mit Federhärte d und Auslenkung Δl

Videos

Diese ganzen hübschen Formeln füttert man der JVM und bastelt mit Processing.org noch eine schöne graphische Darstellung.


Viele Scheiben, jeweils nur 3 Punkte markiert

Die physikalische Grundlage ist nicht mehr ganz so leicht zu erkennen:


Simulation mit einigen Scheiben

Mit etwas Spiel lassen sich die wildesten Sachen treiben:


Chaos theory experiment "Disk"

Natürlich waren neben den Formeln noch weitere Überlegungen möglich:

Möglich sind einige verschiedene Repräsentationen der Position, an der die Kräfte an den Scheiben angreifen. Einerseits die Position relativ zu Position und Drehung der Scheibe. Diese wird von den Federn gespeichert, damit sich ihr Angriffspunkt auf der Scheibe nicht verschiebt. [/p]

Diesen dreh-relativen Ortsvektor lassen die Federn jedoch von der Scheibe umrechnen in eine absolute Position, mit der sie dann den Abstand von ihrer eigenen, festen und absoluten Position berechnen können. Die Entfernung wird für die Berechnung des Kraftbetrags benötigt, der Positionsunterschied für die Richtung der Kraft.

Wenn die errechnete Kraft dann auf die Scheibe angewendet wird, wird diese jedoch wieder mit einer relativen Positionierung arbeiten. Da jedoch eine Drehung aller Kräfte einen Umweg bedeuten würde, bleibt die relative Position diesmal umgedreht.

Da von Vektoren lediglich der Betrag berechnet wird, muss man auch herausfinden, in welche Richtung der Kraftvektor für den Drehmoment zeigt, da sich hierdurch das Vorzeichen ändert. Dazu rotiert man den Positionsvektor um 90°. Wenn alle beide Koordinatenvorzeichen von diesem rotierten Vektor und dem Kraftvektor gleich sind, sind die Vektoren gleichgerichtet. Danach kann man das Vorzeichen für den Drehmoment wählen. Dann müssen die Drehmonte nur noch aufaddiert werden und mit dem Trägheitsmoment zur Winkelgeschwindigkeit und damit zur Drehung verrechnet werden.

Eigentlich ist das gesamte Verfahren eher unkompliziert, da es jedoch kein Schulstoff ist, und auch sonst kaum Dokumentiert, hat es doch einige Knobelarbeit gekostet, die richtigen Einfälle und Formeln zu kombinieren.

Erläuterungen zur Umsetzung

Interessant ist vielleicht noch die Java-Architektur dahinter. Die Scheiben implementieren ein Interface Pullable. Die Federn bekommen eine Scheibe zugewiesen (die ziehbar ist), könnten theoretisch aber auch alles andere ziehen, da alle Berechnungen, die von der Scheibe abhängen dort Eingekapselt sind und von der Feder nur die im Interface festgelegten allgemeinen Funktionen verwendet werden.

Auch die Marker, verantwortlich für das Ziehen der Linien, bekommen ein ziehbares Obejekt zugewiesen. Denn sie verwenden das selbe Interface wie die Federn um ihre Absolutposition zu berechnen von einem auf der Scheibe fixierten Punkt aus. Zusätzlich zur Scheibe bekommen sie ein Objekt delegiert, das das Interface Coorddrawer implementiert, also Koordinaten zeichnen kann.

Ich habe zwei verschiedene Coorddrawer implementiert. Im letzten Video verwende ich zwei primitivere Marker. Der rote zeichnet nur jeweils einen Punkt, der blaue merkt sich die letzte gezeichnete Koordinate und zieht dann eine Linie von ihr.

Der Koordinatenzeichner des anderen künstlerischen Videos wird nicht nur mit einer Farbe vorkonfiguriert, sondern merkt sich auch einen „Rattenschwanz“ von 2000 Koordinaten, sodass er nach dem Löschen der Zeichenfläche wieder eine lange Linie nachzeichnen kann.

Was ich auf physikalischer Seite natürlich ganz außen vor gehalten habe sind Impuls und Reibung, jedoch lässt sich das wohl auch noch leicht kombinieren.

In einem gesonderten Blogeintrag gibt es noch ein paar Stills aus den Physik-Inspirierten Processing-Sketches.

Kommentare: 6 Einträge

Selbstorganisierendes 3D-Clustering

28.05.2009, 19:33

Und wieder einmal ein bisschen mit Processing herum gespielt: Da meine 3D-Tagcloud ja noch recht wechselhafte Ergebnisse geliefert hat, habe ich nun die Erkenntnisse aus der Magnetismus-Implementierung in Processing verwendet, um die Blogposts noch besser anzuordnen. Sie ziehen sich zusammen, wenn sie ähnliche Themen behandeln, was wiederum anhand der gemeinsamen Tags festgemacht wird. Video:


Selbstorganisierender 3D-Cluster aus Blogposts basierend auf gemeinsamen Tags

Zunächst habe ich den Code aus den beiden erwähnten alten Sketches zusammen kopiert. Leider musste noch einiges geändert werden: Die Tags führen nicht länger ein Eigenleben, sondern dienen nur als Berechnungsgrundlage für die gegenseitige Anziehung der Blogeinträge. Zwar läd die Routine wieder die selbe .csv-Datei, doch diesmal legt sie nur einen Array von Blogeinträgen an, die jeweils eine Liste ihrer Tags speichern.

Daraufhin folgt eine kleine Erweiterung meiner „Magnetismus“-Partikel. die Anziehung wird nicht mehr durch eine Ladung bestimmt, sondern durch die Anzahl der gemeinsamen Tags. Sollte diese Anzahl 0 sein, erfahren die Blogeinträge eine kleine Abstoßung. Sollte die Anzahl 1 sein, ist die „Ladung“ 1, sollte sie 5 sein, ist die Ladung 5100, also vergleichsweise groß. Das sorgt dafür, dass sich die Partikel gerne „durchkämpfen“. Dann haben die Partikel an sich immer die Ladung 1, weil es ja eine symmetriche Bindung ist. Es gibt wieder eine „Pauli-Kraft“, sodass die Partikel nicht wie ein Zelt zusammenfallen. Damit sie sich aber nicht unendlich abstoßen, habe ich auch noch eine weitere Kraft zum Zentrum hin hinzugefügt, die sich kontrollieren lässt, sodass manchmal die Blogeinträge etwas lockerer auseinander fallen und sich aber auch in der Mitte zu einem Ball zusammenfinden. Sehr eindrucksvoll finde ich wie bestimmte Themenkomplexe bei geringer „Zentripetalkraft“ in Kristall-artigen Strukturen zusammen bleiben.

Beim Rendering habe ich wieder ein bisschen neuen Code ausprobiert. Die Linien repräsentieren nun die Stärke der gegenseitigen Anziehung (nicht wie vorher die Entfernung) und die Partikel haben einen DOF-Effekt bekommen: Eine Textur, die sich je nach Entfernung zur Kamera verändert, zu einer weich gezeichneten Version der Textur.

Kommentare: keine

3D-Tagcloud mit Processing

25.05.2009, 18:55

Ich habe ja schon etwas mathematisches und recht interaktives mit Processing gemacht. Jetzt wollte ich noch eine kleine Daten-Visualisierung basteln. Da ich wenig Lust habe tagelang irgendwelche tweets zu analysieren und ich mich nicht in die Musik-Librarys von Processing einarbeiten wollte, habe ich meine Blogeinträge und die dazugehörigen Tags als Datenset hergenommen, was auch noch eine recht überschaubare Datenmenge ist, und sie in einer Art 3D-Netz angeordnet. Video:


Zunächst einmal habe ich die Daten als .csv aus der Datenbank exportiert. Dieses Dateiformat ist zum Glück einfach mit Processing einzulesen. Daraus habe ich ein paar Objekte erstellt. Hier war ich mir ein bisschen unsicher, wie das zu realisieren sei. Im Endeffekt habe ich 3 Arrays von Objekten, einer enthält alle Tags, einer alle Blogeinträge und ein dritter alle Verbindungen. Zusätzlich bekommen alle Tags noch eine ArrayList mit ihren zugeordneten Blogeinträgen, um das aktivieren (röten) einfacher zu machen.

Dann haben die 3 Objekte (Eintrag, Tag, Verbindung) erstmal jeweils eine rendering-Methode bekommen. Die Einträge und Tags zeigen einfach ihr Label an, und beginnen auf einer Ebene mit (mehr oder weniger) zufälliger Position. die Verbindungen, die jeweils einen Pointer auf einen Eintrag und einen Tag speichern, rendern sich als Linie zwischen den Positionen der beiden. Zusätzlich habe ich noch eine Szene implementiert, die von der aktuellen Framezahl die Kameraposition und das aktivierte Tag bestimmt.

Eine rein zufällige Anordnung ist allerdings nicht wirklich zufriedenstellend. Deshalb beginnen nun die Tags als nächstes sich dem Schwerpunkt ihrer zugehörigen Blogeinträge zu nähern und die Blögeinträge nähern sich dem Schwerpunkt ihrer Tags. Aus Spaß habe ich das einmal laufen lassen, natürlich kollidiert das ganze recht zielstrebig. Als zweiter Bewegungsparameter kommt hinzu, dass, wenn ein gewisser Mindestabstand unterschritten wird, sich die Blogeinträge und Tabs auch gegenseitig abstoßen. Hier musste ich die Parameter recht fein abstimmen.

Damit nicht der Expansionscharakter die Überhand bekommt (wie bei unserem Universum?), habe ich auch noch eine Arena eingeführt: Wenn die Schriftposition aus einem Zylinder in der Mitte des Bildschirms heraus wandert, greift ein „Sheepdog“, der das Bewegungsverhalten überschreibt und die Tags bzw. Einträge zurück zum Mittelpunkt zieht, bis sie wieder im Rahmen sind. Da die Blogeinträge sowieso etwas unter Druck stehen, sorgt das dafür, dass alles schön zentriert bleibt und ein bisschen in ein Raster gepresst wird.

Je nach Anfangsposition funktioniert der Algorithmus mal besser und mal schlechter, vielleicht müsste ich noch etwas an den Parametern schrauben. Es ist auch schwer zu sagen, was gut und schlecht ist, aber hin und wieder gehen Tag-Eintrag-Verbindungen über den halben Zylinder („mangelnder Ellbogen-Einsatz“?) und bei manchen Durchläufen werden z.B. einige einfache Verbindungen recht schön kurz.

Das ganze lief mit dem P3D-Renderer eigentlich ganz ordentlich, doch dank diesem Tutorial zu Additive Blending mit OpenGL wird jetzt auch mit dem OpenGL-Renderer der Text ohne die weißen Flächen in den Buchstaben gerendert. Ich musste nur alles auf schwarz umstellen, was allerdings auch nicht schlecht aussieht. Jetzt läuft die Animation mit Kantenglättung (smooht() und P3D läuft bei mir sehr sehr langsam) weich wie Butter. Und so sieht alles in schwarz aus:

Mit einer netten Textur und frei drehbar im neuen Style:

Irgendwie interessiert mich als nächstes „Magnetismus“. Man liest recht viel darüber, mal sehen was genau man sich darunter vorzustellen hat.

Kommentare: keine

Processing: 3D-Koch-Kurve mit Sierpinski-Dreieck

23.05.2009, 17:34

Nachdem ich mich jetzt mal an Processing heran gewagt habe, habe ich auch gleich mal einen fraktalen Körper basteln müssen. Es handelt sich um eine Art dreidimensionale Koch-Schneeflocke.

Die Koch-Schneeflocke an sich ist eigentlich recht simpel, habe ich schon in Logo und PHP implementiert. Es wird eine Linie jeweils durch eine Linie mit einem Dreieck darin ersetzt. Auf den Raum übertragen heißt das dann eine Dreieckfläche bekommt einen Tetraeder eingesetzt. Dies wird dann mit den Flächen des Tetraeders rekursiv wiederholt, sodass dann ungefähr so etwas entsteht:

Es entsteht eigentlich eine etwas andere Form, die allerdings nicht sehr interessant anzusehen ist, nämlich ein Tetraeder, der in viele kleine Tetraeder zerlegt ist. Damit der strenge Tetraeder etwas aufgelockert wird, habe ich die neuen Tetraeder immer um 70% skaliert. Es sind also keine Tetraeder mehr, sondern, je tiefer die Rekursion geht, immer schiefere Pyramiden.

Außerdem habe ich nicht mit nur einem Dreieck begonnen, sondern mit einem Tetraeder, sodass ein Körper ensteht, ähnlich wie wenn man in 2D mit dem Dreieck beginnt. Bei 6 Rekursionsschritten ergeben sich dann 66*4 = 186 624 Dreiecke. Die werden dann von Processing z.B. mit 7%iger Transparenz gerendert, damit es etwas schöner aussieht und so kann dann dieses Video entstehen:


Interessant ist eigentlich auch, dass der Rest, der vom ursprünglichen Dreieck bleibt, wenn man die ganzen Tetraeder heraus nimmt, genau dem Sierpinski-Dreieck entspricht. So sieht der Code aus:

fraqTriang trs[]=new fraqTriang[4];

void setup(){
  size(640, 480, P3D);
  noStroke();
  fill(150,150,150,20);
  int bigrad=200;
  int req=6;
  
  PVector A=new PVector(-bigrad,0,0);
  PVector B=new PVector(bigrad/2,0,-173.21);
  PVector C=new PVector(bigrad/2,0,173.21);
  PVector D=new PVector(0,-bigrad*(sqrt(6)/3),0);
  
  trs[0]=new fraqTriang(A,B,C,req);
  trs[1]=new fraqTriang(A,D,B,req);
  trs[2]=new fraqTriang(A,C,D,req);
  trs[3]=new fraqTriang(B,D,C,req);
}


void draw(){
  background(255);
  lights();
  
  float winkel=(mouseX/float(width))*TWO_PI;
  float xpos=cos(winkel);
  float ypos=sin(winkel);
  float radius=300.000;
  camera(xpos*radius, mouseY, ypos*radius, // eyeX, eyeY, eyeZ
         0.0, -50.0, 0.0, // centerX, centerY, centerZ
         0.0, -1.0, 0.0); // upX, upY, upZ
      
  for (int i=0;i<trs.length;i++) {
    trs[i].display();
  }
  //saveFrame("frames/koch3d-####.png"); //uncomment to record
}

class fraqTriang{
  PVector PointA;
  PVector PointB;
  PVector PointC;
  fraqTriang recTris[]=new fraqTriang[6];
  int rec;
  float scaling;
  
  fraqTriang(PVector A,PVector B,PVector C, int recursion){
    scaling=0.7;
    PointA=A;
    PointB=B;
    PointC=C;
    rec=recursion;
    applyRecursion ();
  }
    
  void applyRecursion () {
    if (rec!=0) {
      PVector PointAB2=PVector.add(PointA,PointB);
      PointAB2.div(2);
      PVector PointAC2=PVector.add(PointA,PointC);
      PointAC2.div(2);
      PVector PointBC2=PVector.add(PointB,PointC);
      PointBC2.div(2);
      
      PVector PointZ=PVector.add(PointA,PointB);
      PointZ.add(PointC);
      PointZ.div(3);
      PVector PointAB=PVector.sub(PointA,PointB);
      PVector PointAC=PVector.sub(PointA,PointC);
      PVector PointH=PointAB.cross(PointAC);
      PointH.normalize();
      PVector PointAAB2=PVector.sub(PointA,PointAB2);
      float a=PointAAB2.mag();
      float pheight=a*(sqrt(6)/3)*scaling;
      PointH.mult(-pheight);
      PVector PointZH=PVector.add(PointZ,PointH);
      
      recTris[0]=new fraqTriang(PointA,PointAB2,PointAC2,rec-1);
      recTris[1]=new fraqTriang(PointB,PointBC2,PointAB2,rec-1);
      recTris[2]=new fraqTriang(PointC,PointAC2,PointBC2,rec-1);
      
      recTris[3]=new fraqTriang(PointZH,PointAC2,PointAB2,rec-1);
      recTris[4]=new fraqTriang(PointZH,PointAB2,PointBC2,rec-1);
      recTris[5]=new fraqTriang(PointZH,PointBC2,PointAC2,rec-1);
    }
  }  
  
  void display () {
    if (rec==0) {
      beginShape();
      vertex(PointA.x, PointA.y ,PointA.z);
      vertex(PointB.x, PointB.y ,PointB.z);
      vertex(PointC.x, PointC.y ,PointC.z);
      endShape(CLOSE);
    } else {
      for (int i=0; i<recTris.length;i++) {
        recTris[i].display();
      }
    }
  }
  
}

Man sieht dem Code an, wie schnell man mit Processing Graphiken erstellen kann, ohne sich mit komplizierteren APIs herumzuschlagen. Durch die vielen Beispiele, die Processing beiliegen und die übersichtliche API-Dokumentation kann man innerhalb von kurzer Zeit schon recht hübsche Ergebnisse erzielen. Viel Synatax muss man auch nicht lernen, da die Processing-Synatx mehr oder weniger der von Java entspricht.

Kommentare: keine
[ Seite 1 2 3 ] Nächste Seite »
 
Χρόνογραφ
© 2008-2014 by Bernhard Häussner - Impressum - Login
Kurz-Link zur Homepage: http://1.co.de/