.plan
by nex on 11/11/04, 9:21 AM in meta
Nächste Schritte. Siehe auch Projekttagebuch.
Derzeit:
Siehe Wer macht was.
Anmerkungen:
Der zentrale Code, der sich um die Verarbeitungskette des Video-Streams kümmert, muss noch etwas überarbeitet werden – hier brauchen wir GUI-Hooks und demensprechend mehr Flexibilität.
Die Videovararbeitung an sich passiert in den *VideoProcessor-Klassen. Ich bin hierfür von TestVideoWriter ausgegangen, hier habe ich den Code nämlich selbst geschrieben. Main stammte ja zu 90% noch aus dem Prototypen, für den wiederum diese Klasse zu 90% aus einem Beispiel von Sun übernommen wurde – das ist daher rausgeflogen.
Update: Der Sun-Code ist raus, habe jetzt auch an der RTP-Sache mitgebastelt (das hatte ich ja nicht vor, bin aber zugegebenermaßen selbst schuld, habe ja beim VideoProcessor meine eigene Deadline nicht eingehalten ...), das funktioniert jetzt auch. Nachdem ich die letzten beiden Tage vor der Deadline an allen Ecken und Enden Kleinigkeiten erledigt habe, ist der Warden immer noch nicht sehr weit gediehen, das GUI auch nicht. Die Idee wäre jedenfalls folgende: Der Warden bekommt vom GUI oder einer XML-Konfigurationsdatei Messages, die ihm sagen, wie der Effekt aussehen soll, was als Quelle und was als ziel verwendet werden soll, etc., und instanziert demgemäß alles nötige und schickt Messages weiter (z.b. an den Effekt, Helligkeit verändern).
Ältere Einträge:
Das angegebene Datum bezieht sich auf den Zeitpunkt, zu dem ich den jeweiligen Eintrag in diesen Abschnitt verschoben (also erledigt) und evtl. mit einem 'update'-Zusatz versehen habe. (Also nicht den Zeitpunkt, zu dem ich den Eintrag ursprünglich angelegt habe.)
2005.01.05
Werde alle noch unerfüllten muss-Anforderungen auflisten und einen Zeitplan erstellen, damit uns die Planung nicht entgleist.
Update: erledigt
2005.01.04
Die Wolken sehen noch eher nach Wasserdampf als nach Rauch aus, werde unsere Literaturliste nochmals durchgehen und schauen, was sich da machen lässt. Vielleicht versuche ich es mal mit einem Partikelsystem, wir könnten das aber auch weglassen (siehe Make some noise).
Werde außerdem die JavaDoc ergänzen und anfangen, die Funktionalität mit dem GUI-Prototypen zu verknüpfen.
Update: Habe ein Partikelsystem gemacht, das passabel aussieht. Der Algorithmus dafür ist aus dem Hut gezogen, aber stark an gängige Computational-Fluid-Dynamics-Theorie angelehnt. Könnte sein, dass ich dessen Geschwindigkeit noch verbessern muss, das wird sich noch herausstellen; falls es nötig ist hab ich jedenfalls schon mehrere Ideen, wo man noch was rausholen kann.
Konnte auch AlphaOverlayEffect verbessern, dessen process-Methode läuft jetzt so schnell, dass sie praktisch gar keine Zeit mehr braucht. Der Trade-Off dieser Änderung ist, dass entweder der Rauch nur eine einzige Farbe haben kann (im Gegensatz zu z.B: einem Partikelsystem, bei dem jedes Partikel eine eigene Farbe hat), oder der Effekt eine Unmenge an RAM benötigt (derzeit ist ersteres implementiert). Nachdem aber eh noch niemand Code geschrieben hat, der Rauch malt, der an verschiedenen Stellen verschiedene Farben hat, sollte das kein Problem sein.
Das neue Alpha-Compositing kommt jetzt also ohne Java2D aus. Ich denke an dieser Stelle ist das okay, da der neue Code beduetend schneller ist und somit der Echtzeit-Anforderung entgegen kommt. Nachdem der Rauch nun wieder, wie auch ursprünglich im Prototyp, als ein einziges Array, das als Alpha-Kanal für die Rauch-Farbe dient, gerendert wird, entspricht er eher einem Graustufen-Bild als einem Bild mit Alpha-Kanal. Es stellt sich also die Frage, ob er überhaupt als ein Java2D-Image übergeben werden soll, und vor allem ob für das Compositing der einzelnen Partikel Java2D verwendet werden soll. Nachdem das erzeugte Bild nun keinen Alpha-Kanal mehr hat, sollten die Partikel-Graphiken additiv eingefügt werden. Ich habe aber im Java2D-API nichts gefunden, womit dies realisiert werden könnte. Derzeit mache ich das zu Fuß. Das nach Java2D zu übertragen, z.B. indem ich eine eigene Composite-Klasse schreibe, würde wohl nichts bringen, solange kein Native-Code dahintersteht, der das irgendwie beschleunigt (wie es beim AlphaComposite möglich ist). Mehrere hundert Partikel in ein Bild einzufügen ist aber doch sehr teuer – hier wäre noch eine bessere Idee gefragt.
Die Doku habe ich auch erweitert, siehe hier. Zum GUI bin ich noch nicht gekommen, wegen der CFD-Sache, die ich vorgezogen hatte. (Ohne eine dynamische Änderung der Partikel-Bewegungs-Vektoren sah der Effekt einfach doof aus, und verzichten können wir auf das Partikel-System auch nicht, da es von den Effekten, die wir bisher haben, der einzige ist, der ungefähr wie Rauch aussieht.)
2004.12.13
NoiseEffectSource funktioniert, werde das demnächst auf PerlinNoise erweitern und dann dafür sorgen, dass nicht für jedes Frame ein völlig neues Bild generiert wird, sondern ein zeitlicher Zusammenhang/Ablauf erkennbar ist.
Update: Das Perlin-Noise wird als drei-dimensionales 'Voxel Volume' erzeugt; die dritte Dimension wird in der Animation auf die Zeitachse abgebildet, wodurch auf dieser ein flüssiger Ablauf gegeben ist.
2004.11.11
Die Methode, die ich ursprünglich in SmokeSourceDriver verwendet habe, um einen Alpha-Kanal in ein Bild hineinzubekommen, ist anscheinend viel zu langsam, um in Echtzeit auf jedes Frame angewendet zu werden. Es ist vielleicht möglich, das mit einem simplen arracopy() zu erledigen.
Werde hierzu bei nächster Gelegenheit versuchen, die Daten des von nextFrame() zurückgegebenen Bilds mit einem BandedSampleModel zu speichern – dieses ist in diesem PDF auf Seite 24 illustriert.
Update: Hat funktioniert, das Setzen eines neuen Alpha-Kanals braucht jetz praktisch keine Laufzeit.
Viel später:
Werde den Effekt auf processTest.java vorbereiten (d.h. um einen 'deterministischen Modus' erweitern).
Für die letzte Phase habe ich dann noch kleinere, inkrementelle Verbesserungen an Doku und Code vor, sowie Testen und QA. Das setzt voraus, dass das RTP-Zeug, das XML-Zeug und der Installer von wem anderen kommen und ich nichts übersehen habe – mal sehen.
Update: Das hätte heißen müssen, dass diese anderen Sachen vollständig von wem anderen kommen. Habe da dann auf Anfrage doch mitgeholfen.
Und schließlich: Schnitterkennung. Vielleicht was mit Histogrammen?
|