Die folgenden Definitionen sind nur Ideen, ob und wie sie Realisiert werden steht noch nicht fest. Auf dieser Seite ist alles sehr abstrakt gehalten um vieles mit wenig Text erklären zu können, eine genaure Beschreibung mit Beispielen und schon jetzt realisierten Umsetzungen steht in folgenden Kapiteln. Bei der Programmierung des Programms wird auch nicht versucht alles so umzusetzen wie definiert, sondern es wird zuerst eine grobe Struktur erstellt die an das Ziel so gut wie möglich angepasst wird. Ich kann nicht versprechen, dass alles was hier steht auch verständlich ist, deshalb bitte ich bei Unklarheiten oder Verbesserungen diese ins Board zu posten oder eine E-Mail schreiben, ich werde versuchen die Projektbeschreibung zu verbessern.

Die Möglichkeiten von Animatronik sollen denen eines normalen Vektorprogramms entsprechen; die Grundfunktionen zum Bearbeiten von Vektoren werden vollständig vorhanden sein. Es ist auch eine Unterstützung für Rastergrafiken vorgesehen, wobei diese sich auf das Verändern der Ausmaßen und Rasterfilter beschränkt, eine Pixelbearbeitung ist vorerst nicht vorgesehen, aber dafür gibt es genug Alternativen, wie Gimp oder Paint Shop. Die Idee mit Anime & Manga Grafiken ist nur ein Aufsatz für das Programm, ein Modul, welches zwar sehr stark von den Fähigkeiten des Systems gebrauch macht, aber nicht zum Grundsystem gehört. Damit will ich versuchen mehrere Ziele zu erreichen, falls das eine misslingt, wird vielleicht ein anderes gelingen.

Das Programm wird vollständig in Java geschrieben. Die Entscheidung für Java fiel wegen Java2D, Java Media Frameworks und Swing, außerdem ist Java leichter zu Programmieren als andere, vergleichbare Sprachen. An dieser Stelle sollte natürlich nicht unerwähnt bleiben das Java in der Performance im Verglich zu anderen Sprachen hinterherhinkt, aber ab einen 1 GHz Prozessor, 256 MB RAM und JDK 1.3 spielt das jedoch keine große Rolle mehr, weil der Benutzer dann zu langsam wird. Solche Rechner sind heutzutage keine Besonderheit mehr und da sich das Projekt erst am Anfang befindet, kann man ruhig in die Zukunft programmieren. Außerdem werden im Programm verschiedene Möglichkeiten angewandt um die Performance zu steigern.

Als nächstes sollte die Prioritätsliste von Eigenschaften erwähnt werden, nach welchen das Programm entwickelt wird:

- Stabilität
- Benutzerfreundlichkeit
- Erweiterbarkeit
- Flexibilität
- Performance
- Portierbarkeit

- Stabilität
ein gutes Programm, ist ein stabiles Programm. Es ist aber auch eine der am schwierigsten zu programmierende Eigenschaft. Aus diesem Grund sollen die einzelnen Module zuerst gut ausgetestet werden, bevor sie zum Einsatz kommen.

- Benutzerfreundlichkeit
ein gutes Programm zeichnet sich dadurch aus das viele Menschen damit arbeiten, deshalb muss Animatronik eine gute und flexible Benutzerschnittstelle vorweisen. Die Benutzeroberfläche wird nach dem Prinzip "der Benutzer kann, muss aber nicht" entwickelt. Das bedeutet, dass alle Einstellungen so gut wie möglich voreingestellt werden und der Benutzer bekommt am Anfang eine leere Oberfläche mit wenig Funktionen zu Gesicht und während der Einarbeitung wird der Anwender langsam die anderen Funktionen Stuck für Stück erlernen. Der Benutzer sollte erst dann eine Funktion sehen wenn er weiß was sie leistet und diese verwenden möchte.

- Erweiterbarkeit
ein solches Programm alleine zu schreiben ist ein Ding der Unmöglichkeit. Aus diesen Grund sollte Animatronik sehr gut und einfach Erweiterbar sein, von einem einfachen Filter bis zur kompletter Programmumstrukturierung. Da ich aus Erfahrung weis, dass die Kommunikation zwischen Programmierern nicht immer ohne weiteres klappt, setze ich vor allem auf fest definierte Schnittstellen, über welche Erweiterungen mit dem Programm verknüpft werden können. Jeder sollte seine Erweiterungen mit wenig Aufwand in das Programm selber installieren können, ohne das eine Rucksprache nötig sein sollte.

- Flexibilität
damit die obengenanten Punkte überhaut möglich sind muss das Programm sehr Flexibel sein. Vor allem geht es um kleinere unabhängige Module. Kleinere Module sind einfacher zu schreiben, zu Testen und bei Bedarf kann man ein Modul durch ein gleichwertiges ersetzen. Aus diesem Grund ist das Programm zu 80% ein API und zu 20% ein fester Kern der auf diesem API aufbaut. Erweiterungen bauen auch auf diesem API auf und integrieren sich in den Kern.

- Performance
Performance ist für ein grafisches Programm zwar ein wichtiger Punkt, aber zu Zeit ist es eher eine Frage der Hardware. Natürlich gilt es die Performance des Programms zu steigern, aber in erster Linie geht es darum ein Programm fertig zu stellen, damit man überhaupt was zu steigern hat. Aus diesem Grund wird Animatronik wohl in Sachen Performance hinter den anderen Programme vorerst zurückbleiben (eine gute Ausrede um die Langsamkeit von Java zu verschleiern :) ).

- Portierbarkeit
Portierbarkeit war eigentlich kein besonderer Grund, da ich glaube, dass das Programm zu 90% auf Windows eingesetzt wird und Java 1.3 lauft zu Zeit nur auf 3 Plattformen, wobei nur in der Windows Version die Performance von Java2D akzeptabel ist. Bei der kreativen Implementierung von SUNs SDK 1.3 bezweifle ich außerdem das meine bisherige Implementierung überhaupt zu IBMs SDK kompatibel sein wird. Trotz allem, ein portierbares Programm ist immer wichtig, weil manche groben Fehler vermieden werden, wenn man auf einer abstrakten Ebene arbeitet. Ein Applet wird das Programm aber nie werden.

Das gesamte Programm ist Objektorientiert und Modularisiert, während der Entwicklung und während der Anwendung.

In Java erhalten die Objekte (Java Klassen) auch ihre Form wenn sie kompiliert wurden und diese Fähigkeit wird ausgenutzt um Erweiterbarkeit und Flexibilität zu erreichen. Das Programm wird in kleine Module (ein Modul kann aus mehreren Klassen bestehen) aufgeteilt, die miteinander über vordefinierte Schnittstellen kommunizieren, aber ansonsten sich nicht kennen und auch fehlen dürfen. Es gibt einen Kern, über den die gesamte Verwaltung und Zusammenarbeit der Module abläuft, wo sich einzelne Module anmelden können und abfragen können welche Module installiert sind. Einzelne Module können dynamisch währen der Laufzeit geladen und entladen werden; jedes Modul kann selbst die Verantwortung für seine Funktionalität (Speicherverwaltung, Serialisierung) übernehmen und könnte damit zu 99% Prozent vom Hauptsystem unabhängig arbeiten, wobei aber schon viele Modulrumpfe existieren, die Verwaltungsfunktionalität übernehmen. Einem Zusatzmodul steht auch frei nativen Code zu benutzen, Portierbarkeit spielt keine wichtige Rolle.

Während der Anwendung/Benutzung existieren auch nur Objekte welche in einem Baum verankert sind. Jedes Objekt besitzt Eigenschaften die gelesen/gesetzt werden können über ein allgemeines Interface, so das eine genaue Kenntnis des Objektes nicht erforderlich ist. Ein Objekt kann auch ein Knoten sein und beliebig viele Knoten- oder Blattobjekte aufnehmen. Jedes Objekt hat einen Namen und kann über einen Pfad gefunden werden.
Der Grund für die Baumstruktur ist: Vereinfachung. Will man z.B. an die Konfiguration des Programm ran kommen, dann weiß man, dass das Hauptfenster unter "root.cfg.gui.mainFrame" zu finden ist, die IO Modulliste liegt unter "root.cfg.io". Wenn jetzt eine neues IO Modul in das System installiert wird, dann kommt es als Unterobjekt in "root.cfg.io" und kann so von anderen Programmteilen sofort genutzt werden. Aber nicht nur die Konfiguration ist in der Baumstruktur angeordnet sondern auch die grafischen Objekte sind auch Objekte die alle unter "root.document" zusammengefasst werden. Natürlich ist auch eine Durchsuchung des Baum möglich, wenn man den genauen Pfad nicht kennt oder dieser sich ständig ändert. Mehr dazu steht im Kapitel 3: Systemarchitektur.

Die allgemeiner Definition von nichtlinearer Animation bedeutet soviel wie, dass zwischen zwei Schlüsselpunkten einer Animation die Interpolation nicht linear berechnet wird, sondern nach Formeln, Kurven oder anderen nichtlinearen Verfahren. Natürlich gilt das auch für die Animationen in Animatronik, aber die Möglichkeiten des Programms bieten mehr. In Animatronik bekommt jedes Objekt einen eigenen Zeitraum in welchen es animiert wird und die verschiedenen Zeiträume werden dann zum einen neuen Zeitraum zusammengefasst (Rekursivität), wobei ein Objekt mit Zeitraum beliebig oft kopiert oder verlinkt werden kann. Als Beispiel kann man hier ein Auto nennen. Die Räder eines Automobils haben in einer Animation nur 4 Schlüsselpunkte, das Auto hat aber 100 Schlüsselpunkte. In der fertigen Animation wird das Auto 100 Punkte durchlaufen, die Räder aber nur 4 Punkte und zwar 25 Mal. Die Objekte können mit ihren Zeiträumen abgespeichert werden und stehen so für andere Animationen, schon animiert, zu Verfügung.

Hier ein Beispiel für eine Animation. Es gibt zwei Objekte die im einen Zeitraum 0-t eine Animation bilden und ein neues Objekt a1 erschaffen.

Das Objekt a1 wird benutzt um eine weitere Animation/Objekt b1 im Zeitraum 0-2t zu erstellen. a2, a3 sind keine Kopien sondern nur Verweise auf die Animation a1, die Geometrie ist also nur in a1 vorhanden. Eine Animation/Objekt kann mit Parametern versehen werden, welche das Aussehen verändern können (rote/grüne, gelbe/blau Farbe).

Die einzelnen Objekte/Verweise können beliebig angeordnet werde, in beliebiger Anzahl. Hier ein Beispiel wo a3 vor a2 steht:

Natürlich können die einzelnen Objekte/Verweise auch parallel angeordnet werden. (Im diesem Beispiel wird im Endergebnis nur die Animation a3 sichtbar sein, weil sie a2 überlagern wird):

Will man a2 und a3 ändern, muss man lediglich a1 ändern und dann werden alle von a1 abhängigen Animationen automatisch verändert (stellt Euch mal vor, es gäbe nicht nur a2, a3 sondern auch a4...a1000)

Mehr dazu steht im Kapitel 8: Animation.

Eine Animation in 2D in der ein Objekt von links nach recht läuft ist einfach zu bewerkstelligen. Eine Animation wo es sich um die eigene Achse dreht ist schwieriger. Natürlich kann man mit Morphing und Interpolation viel erreichen, aber das Ergebnis wird nicht immer zufrieden stellen, aus diesem Grund kommt die Objektersetzung zum Einsatz. Bei der Objektersetzung werden für ein Objekt so viele Ansichten wie benötig per Hand angefertigt. Jetzt besteht nur die Aufgabe die Objekte auch anzuordnen. Genau hier kommt das Objektnetz ins Spiel:

Es wurden 8 Objekte: k1o1, k1o2, k1o3, k1o4, k2o1, k2o2, k2o3, k2o4 erstellt. Diese werden nun den Knoten k1 und k2 entsprechend untergeordnet. Die Konten k1, k2 repräsentieren einen von 4 untergeordneten Objekten. Das bedeutet, das wenn k1 auf denn Bildschirm (Konten s) gezeichnet wird, kann nur ein Objekt aus k1o1, k1o2, k1o3, k1o4 gezeichnet werden, das gleiche gilt für k2. Die Abhängigkeit d1, d2, d3, d4 der Objekte stellt die Bedingung da, dass wenn Objekt k1o1 von dem Knoten k1 gezeichnet wird, dann kann nur Objekt k2o1 von den Konten k2 gezeichnet werden und entsprechend die anderen Abhängigkeiten. Das Resultat wurde folgendermaßen aussehen:

Das Objektnetz kann auch von den Objekten unabhängig sein, also kann man zuerst das Netz erstellt und erst danach es mit Objekten belegen oder in einem existierenden Netz die Objekte austauschen.

Wenn wir schon bei Objektnetzen angelangt sind, dann können wir das ruhig auch etwas erweitern. Wenn man einen menschlichen Charakter animieren will, dann wird man irgend wann es leid sein jedes mal die Gliedmassen von Hand zu bewegen, damit die Figur einigermaßen menschlich wirkt.
In einem 2D Run & Jump, Arcade oder 3D Action Spiel steuert man den Charakter mit ein paar Tasten, wobei je nach Kombination der Charakter lauft, springt, klettert oder vollführt sonstige Animationen. Der Grund dafür ist, dass die Animationsvorgänge schon festgelegt und bestimmten Tasten zugeordnet sind. Das gleiche Verfahren wird auch in Animatronik angewandt, mit dem Unterschied das hier beliebig viele Animationsvorgänge definiert werden können und das ganze wird nicht mit der Tastatur gesteuert, sondern mit einem Script. Das Steuerscript beschreib auch nicht jeden Vorgang in Detail genau, sondern beschreibt die gesamte Szene abstrakt und überlässt es dem Programm die richtigen, natürlich vordefinierten, Animationsbewegungen zu finden. Ein Beispiel:

  <script name="Beispiel Script">
    <scene name="scene 1" location="Wald">
      <dialog>
       <charakter name="ch1">Text von Charakter 1</charakter>
       <charakter name="ch2">Text von Charakter 2</charakter>
      </dialog>
    </scene>
  </script>

Dieses Script beschreibt eine Szene wo sich zwei Charaktere vor einen Waldhintergrund unterhalten. Wie jetzt die Charakter sprechen (Mundbewegung) und welche Gesten sie dabei machen sollte das Programm selber "entscheiden", falls genug Vorlagen existieren (es geht jetzt nicht um künstliche Intelligens sondern um vorprogrammierter Auswahl, Objektnetz). Falls den Animator die Entscheidung des Programms nicht passt, sollte er jeder Zeit die Möglichkeit haben in die Szene per Hand einzugreifen und alles korrigieren. Die Entscheidungen die das Programm trifft müssen nicht unbedingt eindeutig sein, das heißt das Programm kann das Steuerscript auf mehrere Weise interpretieren und darstellen, der Benutzter geht nacheinander alle durch und wählt die aus die ihm gefällt, auf diese Weise bleibt ihn aber die Positionierung von einzelnen Objekten erspart.
Die Haupteigenschaft des Steuerskriptes ist, das es keine Befehle definiert. Dafür bietet es die Möglichkeit selber Befehle zu definieren wie: script, scene, dialog, charakter. Danach hat man genau so viele Befehle wie man braucht und alle tragen die Name die man selber dafür festlegt. Die einzige Vorbedingung ist, dass das Script sich an die Regeln von XML halten muss.

Objektbibliotheken sind Sammlungen von Objekten, Farbpaletten, Texturen, Animationspfaden, Objektnetzen, Sounds und Java Klassen. Eine Bibliothek dient dem Zweck Objekte die thematisch zusammengehören auch zusammenzufassen. Daraus können dann die Objekte vollständig oder teilweise geladen werden um sie im aktuellem Projekt zu verwenden. Die Bibliotheken sind normale Zip-Dateien mit einer oder mehreren Inhaltsdateien, aber ansonsten kann dort alles mögliche untergebracht werden. Mehr dazu steht im Kapiteln 3: Systemarchitektur und 4: IO.

Hier gilt die gleiche Regel wie in der Animation: kleine Objekte die in einem eigenen Zeitraum existieren. Aus kleineren Musikstücken werden immer größere zusammen gesetzt, die wiederum selber Musikstücke sind und auch mit anderen kombiniert werden können (Rekursivität). Die einzelnen Stücke können mit Parameter versehen werden um z.B.: die Lautstärke zu verändern. Damit man genügend Material für die Zusammensetzung hat, will ich einen Import für Creative Labs Soundfonts 2.0 einbauen. Da bis heute kein Java API existiert welches die Soundfonts laden und bearbeiten kann, werde ich wohl selber ein API schreiben. Wer mir dabei helfen will dieses API zu entwickeln, sollte sich bitte melden. Mehr dazu steht im Kapitel 9: Sound.

Bei all den schönen Definitionen brauch Animatronik auch eine schöne Anwendungsoberfläche. Die GUI ist das, womit ich mich bis jetzt am meisten beschäftigt habe und es ist schon was brauchbares rausgekommen. Mehr dazu steht im Kapitel 5: Benutzerschnittstelle.

Wenn schon ein Programm machen, dann von Anfang bis zum Ende richtig. Wem wird es nutzen wenn der Quelltext auf die Seite gesetzt wird und daneben steht "es funktioniert"? Aus Erfahrung weiß ich, dass Java nicht einfach zu installieren ist, besonders da ich auch noch an die 10 Zusatz APIs benutze, die man normalerweise alle einzeln runterladen muss. In diesem Fall traue ich auch einen erfahrenen Java Programmierer es nicht zu, alles so einzurichten wie es sein soll. Zum Gluck ist das auch nicht nötig, denn die JRE ist so ausgelegt das man sie einem Programm beilegen kann und der Anwender wird das nicht merken. Die stabile Windows Version wird in einem Installationsprogramm ausgeliefert, welches auch die angepasste JRE enthalten wird mit allen benötigten APIs. Da noch Wrapper, für den Start des Programms, beigelegt werden (EXE-Dateien die java.exe aufrufen), sollte ein normaler Anwender im besten Fall gar nicht merken, dass das Programm auf Java läuft (natürlich sollte er auch einen 1 GHz Rechner besitzen, damit er es wirklich nicht merkt).
Für andere Systeme wird das Programm in einem Zip-Archiv ausgeliefert, ohne die JRE, dafür 100% Java. Die Zusatz APIs, oder besser gesagt die JAR-Dateien, werden in einem zweiten Zip geliefert. Einem Linux oder Unix Anwender traue ich zu das JRE oder SDK selber zu installieren, die Zusatz APIs in lib/ext zu setzen und die Pfade in den Batch-Dateien anzupassen.