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

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

Rechnen mit KDE4 usw.

06.12.2009, 17:30
Klassische Taschenrechner

Klassische Taschenrechner

Was macht man mit einem Computer? Rechnen? Meistens eMails lesen und schreiben, im Internet surfen, Artikel, Blogeinträge, Briefe und Aufsätze verfassen, Daten einpflegen, zocken... und hin und wieder sogar Programmieren.

Aber hier soll es wirklich einmal um das Rechnen gehen, also das womit man einen Großteil der Grundschulzeit verbracht hat, und die Anwendungen, die man dazu unter Linux/KDE4 verwenden kann.

bc

Natürlich kann man den Linux-Konsolen-Rechner bc verwenden:

Er kann mit beliebiger Genauigkeit rechen, unterstützt Variablen und zeigt den Rechenverlauf an. Daher kann man ihn auch aus Shell-Scripten verwenden, was ihn ziemlich universal einsetzbar und automatisierbar macht.

[Update 2009-12-13] Zum Beispiel lässt sich so das kartesische Produkt der Zeilen zweier Dateien A und B durch-multiplizieren:

while read lA;do while read lB;do echo $lA*$lB;done <B;done <A|bc >result

ALT+F2=

Der Programmstarter kann auch Rechnen! Sobald im Einfabefenster ein = steht wird der Rest als Term interpretiert und das Ergebnis angezeigt. Das ist sehr praktisch, wenn man schnell ein paar Kosten aufaddieren will oder ähnliches. Man kann auch gut Experimentieren, da das Ergebnis schon beim Tippen angezeigt wird.

Für kompliziertere Rechnungen wird das aber schnell unübersichtlich. Außerdem hat der Rechner leider einen Rundungsfehler, statt z.B. 5,5 zeigt er öfters 5,49999 an usw.

KCalc

Der Klassische Rechner auf KDE ist KCalc:

Es hat alle Funktionen, die man von einem solchen Rechner erwarten könnte: Funktionstasten für diverse wissenschaftliche und mathematische Funktionen, Umrechnung verschiedener Zahlensysteme, und ein geordnetes Verzeichnis von Konstanten aus fast allen Wissenschaftsbereichen. Man kann natürlich auch auch einige Tasten ausblenden.

KAlgebra

Etwas erweiterte Funktionen hat KAlgebra:

Neben der bc-ähnlichen Konsole mit Vorschlägen beim Tippen, sowie einem 2D und 3D Plotter (Siehe Fun with KAlgebra), beinhaltet er außerdem eine Funktionsliste mit graphischer Vorschau.

Wolfram Alpha

Jetzt verlassen wir das KDE-Gebiet in Richtung Internet. Auf der Webseite Wolfram Alpha lassen sich nahezu alle denkbaren Berechnungen durchführen, auch Integrieren und Rechen mit exotischen Daten (Eigenschaften Chemischer Elemente, Aktienkurse, Mathematische Modelle, Wetter usw.). Zu fast jeder Berechnung gibt es einen Graphen oder eine Illustration, zum Integrieren die Rechenschritte, zu Funktionen diverse Daten und einiges mehr. Siehe die sehr lange Liste von Beispielen und meine Lifestream-Einträge zum Schlagwort Wolfram.

Nebenbei bemerkt...

Natural Display (links)

Natural Display (links)

Ich für meinen Teil rechne oft mit dem klassischen Taschenrechner, in meinem Fall der fx-85EF oder der fx-85MS, von denen ich einen fast immer griffbereit habe. Obwohl sie nicht die kompliziertesten Modelle sind haben sie neben dem grundlegenden Funktionsumfang auch noch schöne Stochastik-Funktionen und Rechnen mit Prozenten und Grad, der EF hat ein Natural Display (also „schöne“ Anzeige von Brücken, Wurzeln usw. ) und Wertetabellen.

Außerdem habe ich einen Rechenschieber, mit dem sich schnell und Stromlos zumindest die Berechnungen -, +, *, /, sin, ^2, ^3, cos, arc, tan, lg berechnen lassen.

Für Windows hier eine Empfehlung für SpeedCrunch.

Einer der besten Rechner ist sicherlich der Graphing Calculator von Pacific Tech. Er zeigt nicht nur alle Rechnungen so an, wie im Mathebuch, sondern rechnet mit Vektoren und Komplexen zahlen und plottet sogar Vierdimensionales. Gibts allerdings nur für Mac und Windows und kostet seinen Preis.

Kommentare: 1 Einträge

Magnetismus und Processing

26.05.2009, 20:02

Wenn man ein bisschen interessantere Partikel-Effekte haben will, als konstante Geschwindigkeit oder Beschleunigung, so wie Selbstorganisation, dann kann man ziemlich gut die Prinzipien von Feldern, wie Magnetismus (so heißt das irgendwie bei Processing, läuft aber auf Elektrostatik hinaus) oder Gravitation benutzen. Hier mal ein Video von meinen Magnetismus-Partikeln:


504 Magnetische Partikel. Die großen Gelben habe ich für das Video „manuell“ bewegt.

Die großen gelben Partikel haben eine recht große positive Ladung und auch eine große Masse, sodass sie sich nicht so schnell abstoßen. Die kleinen Partikel haben eine kleine Masse und kleinere negative Ladung, sodass sie schön in der Gegend herum fliegen und sich nicht so stark abstoßen.

Bei Magnetismus und Gravitation sieht die Grundgleichung so aus:

E = Q * ( D / |D|^3 )

Mit Ladung des anderen Partikels Q und Differenz der Ortsvektoren D. Hat man mehrere Partnerpartikel, addiert man diesen Feldvektor E von jedem Einzelpartikel und teilt dann durch die Anzahl. Bei der Gravitation wäre Q die Masse, es beschriebt also so etwas wie den Partikelspezifischen Wirkungsgrad.

Dann berechnet man die Coulomb-Kraft, die dieses Feld auf den Partikel auswirkt mit:

F = ε * q * E

Wobei q die Ladung des Partikels ist und ε eine Konstante, die bewirkt, dass die Feldkraft in ordentlicher Proportion ist mit anderen Kräften, die auf den Partikel wirken. Denn jetzt benötigt man noch ein paar mehr Felder oder Kräfte, damit die Partikel nicht unendlich weit abgestoßen werden bzw. aufeinander prallen. Da würde sich die Gravitation als Ergänzung zum Magnetismus eignen oder eine sog. „Pauli-Kraft“ (12er Teil vom Lennard-Jones-(12,6)-Potential), die statt dem ^3 ein ^12 hat. Das ^12 bewirkt eine große Erhöhung der Kraft, wenn die Partikel sich näher kommen, sind sie jedoch weiter entfernt, wirkt die Kraft kaum noch. Für die Pauli-Kraft musste ich ε recht hoch wählen, damit sie in Konkurrenz mit dem Magnetismus treten kann. Für Flüssigkeiten wäre statt einem weiteren Feld aber z.B. auch eine Konstante Beschleunigung nach unten in Kombination mit einem Eimer o.ä. möglich.

a = ΣF / m

Hat man alle Felder berechnet, addiert man die Kräfte, und dividiert die Kraft durch die Masse, damit hat man die Beschleunigung. Die Beschleunigung addiert man zur Geschwindigkeit und die Geschwindigkeit multipliziert man mit einer Reibungszahl und dann addiert man sie zum Ort. (Euler-Verfahren/Methode der kleinen Schritte) Damit hat man eine halbwegs brauchbares Partikelsystem.

Kleine Ergänzungen könnten noch sein ein Timer, sodass die fps keine Einwirkung auf die Geschwindigkeit haben, erfahrungsgemäß bleiben sie aber mehr oder weniger konstant. Was extrem zur Geschwindigkeit beiträgt ist das Verwerfen von kleinen Feldkräften. Man kann mit Ladung, Masse und Entfernung schon grob bestimmen, ob sich die Partikel überhaupt groß beeinflussen werden und sich dann die Berechnung der genauen Feldkraft sparen, was schon sehr viel Geschwindigkeit einspart. Hier z.B. mal ein Screenshot aus meinem für Echtzeit optimiertem Algorithmus, wo nur die auch wirklich berechneten Beeinflussungen zwischen den kleinen Partikeln als rote Linien eingezeichnet sind:

In diesem high-fps-Modus habe ich auch das Text-Rendering deaktiviert, da das doch alles deutlich verlangsamt hat. Nötig wäre auch eine bessere Methode also das simple Geschwindigkeit addieren. Ich habe gelesen man kann Integrieren. Oder man addiert einfach nur z.B. ein viertel der Geschwindigkeit und berechnet alles viermal pro gerendertem Frame, was eigentlich ganz gut funktioniert, aber eben nicht immer, es fliegen doch hin und wieder Teilchen in den Äther. Ein Geschwindigkeitslimit wäre vielleicht auch hilfreich.

Was auch noch interessant werden könnte, das ganze mit verschiedenen Ladungsarten? Das Prinzip lässt sich auf jeden Fall erweitern. Schließlich gibt es ein Wikibook über Teilchenphysik aus dem man sich einiges an Inspiration holen kann, oder man experimentiert, so wie ich bei der 3D-Tagcloud mit Processing. Hat man das ganze Buch implementiert und den Algorithmus 100% perfektioniert, ist man wohl bei so etwas wie der „Weltformel“, was definitiv interessant wäre.

Kommentare: keine

Wellen mit PHP rendern

30.04.2009, 19:52

Da ich heute mal wieder etwas Zeit zum Programmieren hatte (bzw. zum was-ich-will-Programmieren) habe ich unseren aktuellen Physik-Stoff visualisiert und zwar mit PHP und GD.

Ich habe ja schon vorher ein wenig mit SVG herumexperimentiert. Das war allerdings alles etwas krum und schief und ganz ohne Mathematik per Hand zusammengebastelt:


interference

Jetzt musste natürlich ein Algorithmus her. Eigentlich sind es nur 2 Klassen, die festlegen, wie eine Welle aussieht und was passiert, wenn sie von einem Zentrum ausgeht. Und zwar werden zyklische Wellenfronten von verschiedenen Zentren aus übereinandergelegt. Schwer zu erklären, einfacher im PHP-Code zu sehen:

class Wave {
  function __construct($length,$amplitude) {
    $this->length=$length;
    $this->amplitude=$amplitude;
  }
  function getPhaseAtLength($s) {
    $phase=($s%$this->length)/$this->length;
    $phaseWithDelta=fmod($phase+(isset($this->phase)?$this->phase:0)+1,2)-1;
    return $phaseWithDelta;
  }
  function getAmplitudeAtLength($s) { //sinuswelle
    $A=sin(deg2rad($this->getPhaseAtLength($s)*360))*$this->amplitude;
    return $A;
  }
  function setPhase($phase) {
    $this->phase=$phase;
    return $this;
  }
}

class Wavecenter {
  function __construct(Wave $wave,Point $center) {
    $this->wave=$wave;
    $this->center=$center;
  }
  function getAmplitudeAtPoint(Point $point) {
    $distance=$this->center->getDistance($point);
    $amp=$this->wave->getAmplitudeAtLength($distance);
    return $amp;
  }
}

Und mit ein bisschen anderem Code, der das ganze Visualisiert, entsteht dann sowas, wie die roten Wellen oben.

Das erste ist natürlich keine Sinuswelle: Am Anfang hat meine Point::getDistance() nicht funktioniert (^ statt pow()), so dass diese seltsame Figur entstanden ist. Interessant ist, dass man bereits zwei überlagerte Wellen sieht (daher die Symmetrie), diese jedoch seltsam deformiert sind.

Da ich gerade noch eine Phasenverschiebung dazu gezimmert habe, kann ich die Wellen auch noch animieren, also nicht nur in der Position des Mittelpunkts, sondern sie auch wandern lassen. Das sieht dann so aus:

Als kleinen Nachtrag noch ein paar Überlagerung einer Welle und anderen mit kleinerer Wellenlänge, wobei die Wellenlängen in (anfangs) kleinen ganzzahligen Verhältnissen stehen. Daher kann man sie auch recht leicht in der Musik finden. Die oberste Reihe wäre demnach das Schallbild, wenn man 1, 2, und 3 mal den selben Ton spielt, nur eben in der anderen Oktave. Das hört man normalerweise recht einfach, aber beim Sehen ist es etwas anders:

Jetzt wäre es natürlich irgendwie cool, auch einzelne Wellen irgendwie umher wandern zu lassen, um Doppler-Effekt und Reflexion etc. zu zeigen, aber da wären etwas kompliziertere Models nötig.

Nachtrag 26. Mai 2009: OpenGL

Da ich vor kurzem begonnen habe mit Processing Grafiken zu basteln, habe ich Processing auch gleich mal für das Wellen-Darstellen benutzt. Und das funktioniert sehr gut: Processing bietet die Grundlagen, sodass man leicht eine Welle, die von einem Zentrum ausgeht rendern kann. Das macht man dann z.B. mit 10 Frames, immer mit leichter Phasenverschiebung. Das könnte man dann einfach animieren. Wesentlich ansehnlicher ist es aber, wenn man die gerenderte Welle als animierte Textur in eine OpenGL-Szene mit additiver Überblendung einsetzt. Dann entstehen nämlich die oben gezeigten Bilder in realtime. Abgesehen vom anfänglichen Rendern und dem Laden in den Graphikspeicher der 10 2000x2000 Pixel Texturen. Screenshot:

Vor allem wenn man mehr Wellenzentren man hat, übernimmt OpenGL viele Berechnungen, weshalb man die Wellenzentren ohne Wartezeiten einfach mit der Maus verschieben kann.

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