request_url_withoutHTTP=,canonical_url_withHTTP=,canonical_url_withoutHTTP=,request_url_withoutHTTP_realspaces=. Processing (Seite 1 von 3) « Tags « Blog « Bernhard Häussner
Bernhard Häussner
Tags: Artikel mit dem Tag «Processing» durchstöbern

100. Blogeintrag

26.02.2011, 15:12

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.

Kommentare: keine

Pentagramme, 5-Ecke, √5 und Φ

21.01.2011, 18:44

In letzter Zeit habe ich mich mit den Winkeln und Strecken-Verhältnissen in Fünfecken und Pentagrammen beschäftigt, und bin dabei auf allerlei Vielfache der Wurzel 5 und der Goldenen Zahl Φ gestoßen. Dem zweidimensionalen Pentagramm, wie auch dem Dodekaeder, und in gewisser Weise auch dem Ikosaeder liegt das Fünfeck als Baustein zugrunde.

Pentagramm und Fünfeck

Die Winkel im Pentagramm sind fast alle 36°, oder Vielfache, wie 18°, 72°, 108°, 144°. Die Längenverhältnisse sind schon interessanter: Beim Fünfeck stehen Diagonale (in der Skizze blau) und Seitenlänge (magenta) im Verhältnis des Goldenen Scnittes, genauso im Pentagramm der große (hellblau, [AS]) und der kleine (hellmagenta, [SS'']) Abschnitt (gleichzeitig Seite des kleinen Fünfecks) der Seite. Dadurch, dass das Pentagramm aus den Diagonalen des Fünfecks gebildet wird, kann man von der Seitenlänge des kleinen Fünfecks auf die des Großen schließen:

[AD] = d(S,S'') + 2*Φ*d(S,S'')
[AD] = Φ*[AB]
1/Φ  = Φ - 1

[AB] = [ d(S,S'') + 2*Φ*d(S,S'') ]/Φ = ( 1/Φ + 2 )*d(S,S'') 
     = (Φ + 1)*d(S,S'')

Interessant für meine Zwecke war dies, um die Polarkoordinaten aller Punkte herauszubekommen. Dabei dient M als Ursprung, und wenn die drei Punkte A, M' und S bestimmt wurden, lassen sich die übrigen Punkte durch Rotation finden. Durch Rotation (und Spiegelung) der beiden in Cyan markierten Strecken lässt sich das gesamte Pentagramm bilden. Das habe ich bei meinen Konstruktionen verwendet. Der Azimut φ ist bei allen 3 Punkten trivial. Allein der Radius r bedarf einiger Überlegung.

Zum Glück hilft Wikipedia hier mit 2 recht praktischen Formeln für In- und Umkreisradius, sodass man sich einiges Gerechne mit Dreiecks-Ähnlichkeiten, Pythagoras etc. sparen kann:

r_i = a/10 * √(50+10√5)
r_u = a/10 * √(25+10√5)

Da r(M') der Inkreisradius des kleinen Fünfecks ist, r(S) der Umkreisradius des kleinen Fünfecks und r(A) der des großen ist, kann man die Entfernungen zunächst leicht als Vielfache der Kantenlänge des kleinen Fünfecks (d(S,S'') hier a) schreiben:

r(M') = a/10 * √(25+10√5)
r(S)  = a/10 * √(50+10√5)
r(A)) = (Φ+1) * a/10 * √(50+10√5)

Die Länge a wird nicht benötigt, und ich habe r(M') auf 1 festgelegt. Dann löst man auf:

r(M') = 1
a     = 10 / √(25+10√5)
r(S)  = √(50+10√5) / √(25+10√5)
      = -1 + √5
r(A)) = (Φ+1) * √(50+10√5) / √(25+10√5)
      =  1 + √5
      =  3.2360679774997896964091736687312762354406183596115257...

Hier ergeben sich überraschend sehr einfache Zahlenverhältnisse. Zumal da ich nicht wirklich sehe, wie man die Wurzeln so fein auflösen kann, aber der Computer schafft es irgendwie.

Dodekaeder und Ikosaeder

Offensichtlich kann man ein Dodekaeder aus 12 regulären Fünfecken bauen. Doch auch die Kanten des Ikosaeders bestehen aus den selben (also gleich ausgerichteten) 12 Fünfecken. Dies wird in der Videoanimation klar:


Dodecaicosahedron (seq3)

Übrigens sieht man in der Animation für 1 Frame einen Ikosidodekaeder, der ebenfalls gebaut werden könnte.

Einige der Diagonalen und Kanten der Fünfecke kann man zu 3 („goldenen“) Rechtecken zusammenfügen, an deren Ecken alle Kanten zusammenlaufen. Diesen Sachverhalt kann man nutzen, um das Ikosaeder zu zeichnen, wie hier im Video beschrieben:


Ikosaeder zeichnen in 3 Schritten

Oder man scheidet die 3 Rechtecke aus Papier oder Pappe und „vernäht“ sie dann mit den übrigen Kanten. Dann entsteht eine Figur, wie oben im Foto. Dabei bin ich mir noch nicht sicher, ob es eigentlich trivial ist, die Kanten so mit einem durchgehenden Faden zu nähen, ohne dass man keine Kante doppelt, eine Ecke dreimal beschickt und dann wieder dort heraus kommt, wo man angefangen hat. Eine Art dreidimensionales Nikolaushaus. Ich habe es auf Anhieb geschafft, aber instinktiv ein bisschen Taktik verwendet und stets etwas voraugedacht... (Das ist sicher interessant zu modellieren, wenn man mal Zeit hat)

Update 2016-04-10

Inzwischen habe ich einen Brute-Force-Algorithmus entwickelt, der das „Vernähen“ lösen kann, jedoch ist dies natürlich wenig zufriedenstellend. Zusätzlich habe ich eine Processing-Sketch gebastelt, die solche Nähwege darsetellen kann. Aber ich sehe es noch immer als offenes Problem, das ordentlich modelliert zu bekommen.

Kommentare: keine

Howto: Processing.org API lernen

15.05.2010, 23:44
Mein erster Processing-Screenshot

Mein erster Processing-Screenshot

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.

Kommentare: 1 Einträge

Physik-Inspirierte Processing-Sketches

20.04.2010, 15:03

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

$ braindump -R -d 7 λι4σα
$ braindump -R -d 7 λι4σα

Zwei eher vermischte Werke.

Kommentare: 1 Einträge

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
[ Seite 1 2 3 ] Nächste Seite »
 
Χρόνογραφ
© 2008-2017 by Bernhard Häussner - Impressum - Login
Kurz-Link zur Homepage: http://1.co.de/