100. Blogeintrag

Das ist nun also der 100. Blogeintrag, und er enthält eine kleine Chronik.

Die Graphik hier ist übrigens ein Screenshot aus einer Processing-Sketch, wo ich mit ein bisschen Java-Code eine Timeline zusammengestrickt habe, die die chronologische Verteilung der Blogeinträge zeigt und die Verlinkung mit den häufigsten Tags. Man sieht eindeutig, wann ich in Bremerhaven bzw. Wilhelmshaven war.

Angefangen hat das Blog als kleines Experiment. Ich hatte schon länger vor meine diversen Seiten in einer großen, irgendwie dynamischen, Seite unterzubringen und zu dokumentieren. Tatsächlich hatte ich wohl schon die ein oder andere Blog-ähnliche Seite gebastelt, mal um Smarty zu testen, mal um AJAX zu testen, außerdem hatte ich natürlich eine Menge Design-Entwürfe. Irgendwann musste ich all dies unter einen Hut bringen, und da ich meine Festplatte formatiert hatte, konnte ich bei 0 anfangen.

Der neue Plan war: Meine Seitenstrukturen mit XML-Dateien basteln, und außerdem objektorientiertes PHP schreiben.

Beide technischen Experimente sind inzwischen etwas veraltet. Meine PHP-Klassen von damals entsprechen heute nicht mehr meinen Ansprüchen, außerdem gibt es ja inzwischen Namespaces. Und das mit dem XML hat sich als problematisch herausgestellt, da bei jedem Seitenaufruf eine Menge XML-Dateien verarbeitet werden müssen. Zum Glück ist die Server-Hardware leistungsstark und die Besucherzahlen sind nicht zu hoch.

Andere technische Errungenschaften waren: Eine eigene Markup-Sprache, „progressive enhancement“ mit jQuery und PHP-Klassen-Autoloading.

Der erste Blogeintrag Hello World! wurde am 15.10.2008 geschrieben. Damals gab es allerdings noch kein CMS, das bedeutet des Eintrag wurde direkt in die Datenbank geschrieben. Online ging die Seite dann gut zwei Monate später, am 19. Dezember 2008. Das schließe ich jetzt einfach mal aus den ersten Log-Einträgen:

84.56.72.255 - - [19/Dec/2008:14:18:14 +0100] "GET / HTTP/1.1" 200 566 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
[...]
92.75.61.95 - - [19/Dec/2008:19:31:46 +0100] "GET /index.php HTTP/1.1" 200 3001 "http://78.47.239.227/blogentry.php?link=28_Pretty_Good_Privacy_%28PGP%29" "Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.0.3) Gecko/2008092700 SUSE/3.0.3-4.4 Firefox/3.0.3" 

Ich stelle gerade erstaunt fest, dass die Links von damals, noch mit IP-Adresse und ohne die „schönen“ URLs, noch immer wie gewünscht weitergeleitet werden.

Auch an der live-Seite wurden immer weitere Verbesserungen vorgenommen, wie „schöne“ URLs mit htaccess, Kurz-URLs, erklärte Abkürzungen, und viele jQuery-Spielereien. Meine Aufzeichnungen über diese Seite finden sich allesamt unter dem Tag Projekt: Mein Blog.

Howto: Processing.org API lernen

Ich habe am 20. Mai 2009, etwa vor einem Jahr, meine ersten paar Processing-Versuche gemacht, und die Sachen aus dem ersten Blogeintrag zum Thema sind in mehreren Stunden am 21. entstanden. Vieles andere, das ich bisher mit Processing gemacht habe, ist dann in den Tagen darauf entstanden, ich konnte wirklich schnell interessante Dinge machen.

Davids Kommentar hat mich dazu veranlasst, ein bisschen zu überlegen, wie ich Processing.org eigentlich gelernt habe. Aus meiner Antwort habe ich jetzt einen Blogeintrag gemacht, der darstellt, wie ich mich an Processing herangetastet habe und auch anderen helfen soll, den Einstieg in die Processing-API zu erleichtern. Vielleicht lassen sich die Grundlegenden Schritte sogar zum Erlernen einer jeden Programmiersprache benützen.

Schritt 1: Basiswissen, Konzepte verstehen

Zunächst habe ich im „offiziellen“ Lernbereich das „Getting Started“ durchgemacht. Danach kann man noch die Tutorials zu Color usw. kurz überfliegen, Trigonometrie und Vektoren kann man sich wohl fast sparen, dabei es kommt auch stark darauf an, wie sehr man mit diesen mathematischen Grundlagen von Anderem vertraut ist.

Ich weiß nicht, ob es gut ist, Processing als aller erste Programmiersprache zu lernen. Sicherlich motivierend ist, dass die ersten Programme ansehnlichere Dinge Produzieren, als ein „Hello World“ oder ein abstraktes Fantasie-Auto, das angeblich beschleunigen und bremsen kann. Hier empfiehlt es sich dann vielleicht doch ein ausführliches Buch zu kaufen.

Es ist sicher hilfreich, wenn man schon ein bisschen in Java oder ähnliches (PHP, JS...) reingeschnuppert hat, dann kennt man die Kontrollstrukturen (Wenndann, Schleifen usw.) grob; Man muss dann beachten, dass Processing vieles vereinfacht. Zu dem Thema findet man unter "Control" in der API-Doc manches. Man kann natürlich auch herumprobieren...

Schritt 2: Herumprobieren, Wissen vertiefen, Orientieren, Inspiration

Mit dem Basiswissen habe ich dann ein paar rudimentäre Spielereien gemacht.

Wenn man dann etwas in den grundlegenden Konzepten drinnen ist (z.B. was macht draw() usw.), sind die mitgelieferten Beispiele wirklich sehr praktisch, da lernt man die Möglichkeiten sehr gut kennen und das Wissen wird vertieft. Außerdem klären sich einige übliche Einstiegsfragen ala „Wie macht man eigentlich ...?“. Bei interessanterem sollte man durchaus den Code genau lesen und verstehen. Ich habe dann immer schon die Beispiele leicht modifiziert, um zu sehen, ob auch alles so funktioniert, wie ich denke.

Ausgehend von den Beispiel-Sketches kann man dann die ersten eigenen Ideen verwirklichen. Außerdem sammelt sich langsam ein gewisser Code-Fundus an von Standard-Funktionen, die man immer wieder verwenden kann.

Schirtt 3: API nach Bedarf genauer studieren, Googeln

Im Folgenden schaut man wenn nötig immer in der API-Doc nach den Funktionen, die man benutzt. Praktischerweise heißen sie eigentlich immer so, dass man sie auch findet. Irgendwann kann man sich die Funktionsnamen und Parameter entweder merken, bzw. aus alten Sketches kopieren.

Wenn man nicht weiter kommt, hilft Google weiter, vor allem in Verbindung mit site:http://processing.org. Ausweichend kann man manchmal auch auch Java-Implementierungen zurückgreifen, zum Beispiel für Datenstrukturen mit Sortieren usw. oder für String-Operationen und was es eben nicht direkt in Processing gibt.

Schritt 4: Anderer Leute Code lesen

Wer immer noch wissbegierig ist, sollte durchaus über die Beispiele hinaus Code lesen. Oftmals ist der Quelltext von Processing-Applets, die man im Internet findet, verfügbar.

Ein für viele Arten von Animationen essentielles Tutorial ist das zu Partikelsystemen, wleches auch gleich noch ein paar OOP-Basics aufzeigt. Ich habe den Code dort zwar nie verwendet, weil ich meine Partikelklassen schon zusammen hatte, bevor ich das gefunden habe, aber so oder ähnlich implementiert man das eben.

Auch für einige Effekte sorgt additives überblenden mit OpenGL. Das ermöglicht das einfache Verwenden von Texturen und sorgt für eine interessante Optik.

... und dann heißt es wohl noch Üben. Ich hoffe also, dass diese kleine Liste jemanden weiter hilft.

Physik-Inspirierte Processing-Sketches

Die interessantesten Momente aus dem in Drehmomente und Kräfte mit Processing beschriebenen Prozess finden sich hier.

Und diese zwei Pendants habe ich mir als Hintergrundbilder (engl. Wallpaper) eingerichtet:

Updates 2010-04-20

Zwei eher vermischte Werke.

Drehmomente und Kräfte mit Processing

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:

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.

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

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:

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.

Videos

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

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

Mit etwas Spiel lassen sich die wildesten Sachen treiben:

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.

Processing und Blender

Processing ist gut geeignet um Daten und Berechnungen zu visualisieren, Blender übernimmt dafür mehr Material- und Rendering-Aufgaben. Dennoch gibt es Bereiche, in denen sich die Verwendungszwecke überschneiden, zum Beispiel die hier gezeigten Formen.

Das Bild oben ist eine runde zweifache Spirale - Auf der innersten Ebene jeweils zwei gestreckte und zu Spiralen verdrehte Kreise und Quadrate, deren Dehnprodukt sich dann spiralförmig schraubend um einen Kreis windet. Zwar kann Blender auch mit Python gescriptet werden, das habe ich mir aber bisher noch nicht angeschaut, weshalb alles eher in „Handarbeit“ entstanden ist. Die Farben habe ich nachträglich noch ein bisschen mit GIMP verändert. Das ist ein Rendering in Original-Farben und mit einer etwas angehobenen Ebene:

Wenn sich diese Doppelspiralkreise dann wiederum um einen Kreis legen, entsteht das:

Mit Processing geht dieses verdoppeln und drehen alles viel Einfacher. Hier mal ein Bild aus einem nicht wirklich fertigem Projekt:

Es ist ein Versuch eine Art Haarbüschel nach gewissen Expansionsregeln zu erstellen. Die „Haare“ können in der Sketch interaktiv nach oben und unten gebogen werden, was ein recht lustiges Bild ergibt. Vielleicht hier nochmal ein Bild mit besserem Überblick und anderer rendering-Methode:

Ich habe mich auch schon in Processing etwas mit Spiralen auseinandergesetzt, ist aber leider nicht in 3D, aber dank farblicher Überarbeitung doch noch recht interessant geworden:

Die Bildungsvorschrift ist übrigens eine Linie von einem Punkt aus im rechten Winkel zum Ursprung bis zu einem bestimmten Winkel und das sehr oft wiederholt. Der Sourcecode beschränkt sich auf wenige Zeilen:

// Initialisieren
size (1800,1100);
smooth();
background(255);
// Setzt den Ursprung des Koordinatensystems auf die Mitte
translate(width/2,height/2);

// 20 Spiralen
for (int k=0; k<20; k++) {
  // Weiterdrehung pro Spiralsegment
  float rotateStep=PI/11.465;
  // Anzahl der Spiralsegmente
  int rotateAnz=200;
  // Startposition
  float len=k; // wird ei jeder Spirale leicht vaiiert
  // Startposition 2
  float prelen=cos(rotateStep)*len;
  
  // Die Spiralensegmente erstellen
  for (int i=0; i<rotateAnz; i++) {
    // für jedes Segment ein Stück weiter drehen
    rotate(rotateStep);
    // Entfernung des Endes des letzten Segments zum Ursrung
    // Verwendet als Entfernung des Anfangs des aktuellen Segments zum U.
    len=prelen/cos(rotateStep);
    // eine Linie vom Ursprung zum Anfang des Segments
    stroke(0,40);
    line(0,0,len,0);
    /* Damit das letzte, nicht abgeschlossene Segment 
     * nicht so hässlich aus der Spirale hängt */
    if (i!=rotateAnz-1) { 
      // Eine Linie vom Anfang zum Ende des Segments
      // Das wird die Spirale
      stroke(0,200);
      line(len,0,len,len*tan(rotateStep));
    }
    prelen=len;
  }
}

Mit den Kommentaren ist es doch ganz ordentlich länger geworden. Vom rechten Winkel sind übrigens nurnoch die Trigonometrischen Funktionen cos und tan übrig: Die Strecke Ursprung-Segmentbeginn ist die Hypotenuse des Segments und wird die (zu unserem Schritt-Rotationswinkel) Ankathede des nächsten.