JAVA3D am Beispiel eines Getriebemodells
Ziele von JAVA3D
Die JAVA3D-API ist eine Erweiterung von JAVA-2 und entstand in
Zusammenarbeit von Intel, Silicon Graphics, Apple und Sun. Das Ziel
ist die 3-dimensionale Darstellung virtueller Welten, wobei
insbesondere ihr Verhalten, ihre Reaktion auf externe Stimuli
programmierbar sein soll. JAVA3D kann
überall dort eingesetzt werden, wo Zusammenhänge nur durch die
perspektivische Darstellung bedienbarer Objekte erfassbar sind.
Da als Betrachter auch WWW-Browser eingesetzt werden können, eignet
sich JAVA3D zum Aufbau von Fernkursen. Das wird insbesondere dadurch
unterstützt, dass die virtuellen Welten durch den WWW-Nutzer bedient werden
können. Bei guter Programmierung kann das Verhalten der 3D-Mechanismen
verblüffend echt dem Verhalten realer Objekte angenähert werden.
Beispiel "Getriebemodell"
|
Als Beispiel soll das Modell eines Getriebes dienen.
Die Funktionsweise ist auf einem 2D-Medium nicht zu
erklären (und wird folglich auch durch Lesen dieses
Textes und Betrachten der Bilder nicht verständlich werden).
Das Problem ist
nämlich die violett dargestellte "Kralle", welche die
Drehung des vorderen Kegelrades verhindert.
Zwar zieht das Schubkurbelgetriebe (vorn) die Kralle
nach einer reichlichen viertel Umdrehung aus dem Kegelrad
heraus, wodurch die Blockierung beseitigt wird, aber bereits
nach einer achtel Umdrehung stoßen die "Speichen" des
Kegelrades an die Stifte der "Kralle".
Dennoch bewegt sich das Getriebe, da im Hintergrund ein
sogenanntes Dreirädergetriebe arbeitet, welches
die gleichmäßige Antriebsbewegung in eine
sogenannte "Pilgerschrittbewegung" umwandelt. Diese
wiederum bewirkt, dass das Kegelrad stillsteht, solange
die "Kralle" zwischen seine "Speichen" greift.
|
 |
 |
Zunächst soll dem Benutzer die Möglichkeit gegeben
werden, sich das Modell gründlich von allen Seiten
anzusehen.
Dazu kann das Getriebe mit Hilfe der Maus in jede
beliebige Lage versetzt werden.
Die linke Maustaste
ermöglicht das Drehen um die X- und die Y-Achse.
Lässt man die linke Maustaste mitten in der
Bewegung los, so "kreiselt" das Modell infolge einer
"virtuellen Trägheit" endlos weiter. Durch geschickte
Dosierung dieses Effekts kann eine langsame Rundum-Präsentation
bewirkt werden.
Mit der mittleren Maustaste wird Zoom durchgeführt.
Die rechte Maustaste gestattet das Verschieben des Modells
an jeden beliebigen Ort.
|
Auch das Ausblenden von Getriebeteilen zum Zwecke der
besseren Erläuterung kann mit Hilfe entsprechender "Knöpfe" auf dem
Bedienfeld (unten) bewirkt werden.
Dieses Bedienfeld ist mit JAVA-Swing-Objekten (JPanel, JSlider, ...)
programmiert, denn JAVA3D ist zunächst einmal "normales" JAVA, so dass
alle bisher bekannten Eigenschaften und Methoden dieser Sprache weiter verfügbar sind. |
 |
 |
Mit Hilfe der "Zoom"-Funktionalität ist die
Detailbetrachtung möglich.
|
Wenn es vorteilhaft ist, so kann durch die "Knöpfe" auf dem
Bedienfeld eine Drahtgitterdarstellung erzeugt werden.
Neben dem JAVA3D-Applet können in gewohnter Weise
"normale" HTML-Elemente wie Texte und Bilder erscheinen.
Im Beispiel befindet sich rechts neben dem Modell ein
erklärender Text. |
 |
 |
Durch Betätigen des Start-"Knopfes" beginnt sich das
Getriebe zu drehen. Am Schieberegler am unteren Rand kann
die Winkelgeschwindigkeit beeinflusst werden.
Auch während das Getriebe "arbeitet", kann es von allen
Seiten betrachtet werden.
Das Ein- und Ausschalten ist auch durch Anklicken des
grünen Einschalters bzw. des roten Ausschalters möglich.
Der blaue Pfeil ist eine Hyper-"Text"-Referenz.
Ein Mausklick auf den Pfeil bewirkt das Laden
von http://www.java3d.org.
|
Um dem Nutzer das perfekte Gefühl zu geben,
eine Getriebemodell "in der Hand" zu halten, kann er
eines der Räder anklicken und durch Mausbewegung ein
"virtuelles Drehmoment" erzeugen. Die Folge ist, dass sich
das Getriebe entsprechend dreht.
Insbesondere diese Möglichkeit täuscht das Vorhandensein
eines Getriebemodells ziemlich gut vor. Der Nutzer meint,
die Getriebeelemente mit seinem Zeigefinger in Bewegung zu
versetzen. Einzig das Fehlen einer Rückmeldung über den
Tastsinn stört diese Illusion.
|
 |
Das Beispiel zeigt eine JAVA3D-Anwendung zu der es eine
alternative Präsentation praktisch nicht gibt. Denn die
Funktionsweise des Getriebes ist nur dann zu verstehen, wenn
man es in Aktion sieht und dabei von allen
Seiten betrachten kann. Eine 2-dimensionale Darstellung ist deshalb
nicht möglich, weil es kein ebenes Getriebe ist.
Natürlich könnte man für ein Fernstudium Getriebemodelle bauen und an die
Fernstudenten schicken. Aber angenommen, es wären in einem
Fernkurs Mechanismentechnik etwa
50 grundlegende Getriebe vorzustellen. Dann müsste man bei
50 Studenten jedes Semester 2500 Getriebemodelle bauen und
verschicken.
Eine Darstellung in Grund-, Auf- und Seitenriss auf
einer WWW-Seite dürfte in
diesem Fall selbst mit noch so gutem Begleittext
keinerlei Wissensgewinn hervorrufen.
Einzig das Filmen eines Modells und die Codierung in
einem geeigneten Format (MPEG, AVI, ...) wäre eine denkbare
Alternative. Allerdings ist der Fernstudent in diesem Fall dem
Kameramann "ausgeliefert". Möchte der Student das Getriebe in einer
konkreten Situation unter einem bestimmten Blickwinkel
sehen, so ist das - falls eine solche Szene im Film fehlt - nicht
möglich.
Getriebe ausprobieren/Quelltext
Die bisherigen Ausführungen legen den Schluss nahe, man könne nun eine WWW-Seite
mit dem Modell laden und das Getriebe ausprobieren. Das ist im Prinzip auch
richtig! Das Problem ist: JAVA3D läuft nur unter Steuerung einer JAVA-2-Umgebung.
Die gängigen WWW-Betrachter enthalten jedoch ziemlich alte JAVA-1-Implementierungen.
Und selbst wenn sie eine JAVA-2-Umgebung hätten, so ist kaum anzunehmen, dass
diese ausgerechnet die JAVA3D-Erweiterung einschließt.
Der einzige Ausweg aus diesem Dilemma ist: Man muss auf seinem Rechner eine JAVA-2-Umgebung
mit den JAVA3D-Erweiterungen lokal installieren und den WWW-Betrachter dazu bringen, diese
JAVA-2-Maschine zum Anzeigen der JAVA-Applets zu benutzen.
Vor weiteren Ausführungen zu diesem Thema, soll jedoch eine weitere Voraussetzung
angesprochen werden, denn man benötigt unbedingt eine Hardware-3D-Beschleunigung.
Hat man diese nicht, so ist die Darstellung unerträglich langsam und liefert
ruckartige Bewegungen. Dann wäre der relativ große Aufwand der Browser-Umkonfigurierung
völlig nutzlos.
Hardware-3D-Beschleuniger
Wer eine relativ neue (> 1996) Graphikkarte besitzt, kann ziemlich sicher sein,
dass sich auf dieser ein Hardware-3D-Beschleuniger befindet. Windows-XX-Nutzer können
sich zudem relativ sicher sein, dass der Treiber diesen Hardware-3D-Beschleuniger auch
tatsächlich benutzt.
Leider haben Linux-Nutzer genau hier ein Problem. Denn der
Besitz einer Graphikkarte mit Hardware-3D-Beschleuniger garantiert noch nicht,
dass dieser auch benutzt wird. Im allgemeinen sind dafür einige Änderungen am X11-System
notwendig. Einige Linux-Distributionen bieten die automatische Installation einer
entsprechend konfigurierten X11-Umgebung an.
Zudem existiert nicht (oder nicht kostenfrei) für jede Graphikkarte ein
3D-beschleunigter Treiber. Man lasse sich auch durch das Wort "Acceleration"
in den X11-Konfigurationsfiles nicht irritieren: Hier ist im allgemeinen der
2D-Beschleuniger gemeint. Eine Aufstellung über die 3D-Unterstützung
ist unter
http://www.linux3d.org/genframe.php3?hardware zu finden.
Viele Nutzer tragen sich mit der Hoffnung, dass ein schneller Prozessor
die fehlende Hardware-3D-Beschleunigung kompensieren kann. Diese Hoffnung soll
durch die Betrachtung zweier Details zerstört werden:
 |
1. Das Bild links zeigt eines der Zahnräder des Getriebemodells.
Bei oberflächlicher Betrachtung ist das Rad einfach grau. Untersucht man
aber die Zahnflanken etwas genauer, so stellt sich heraus, dass diese Farben
von fast Schwarz bis fast Weiß annehmen. Mehr noch: Die Radnabe zeigt einen
kontinuierlichen Farbübergang von Schwarz nach Weiß. Das bedeutet, dass der
Prozessor die Farbe eines jeden Pixels einzeln ausrechnen muss, denn wenn
er einfach einen "Eimer Farbe" über den Rädern "ausschüttet", so sieht es wie
rechts gezeigt aus. Die Konturen der Körper sind nicht erkennbar.
Nun hat aber der Prozessor für die Berechnung nur eine 25stel Sekunde
Zeit. Und die Berechnung ist relativ aufwendig. Als Argumente gehen
der Winkel der Flächennormalen am betrachteten Punkt zur Kamera und der Winkel
der Flächennormalen am betrachteten Punkt zu jeder Lichtquelle ein.
|
|
| 2. Selbst wenn die CPU irgendwann die Beleuchtung berechnet hat, so muss
sie noch die eigentliche Projektion durchführen. Ein nicht zu unterschätzendes
Problem ist dabei die Beseitigung verdeckter Polygonteile, weil dies potentiell
dazu führt, dass jeder Punkt eines jeden Polygons mit jedem Punkt aller anderen
Polygone verglichen werden muss. Aber selbst wenn das in angemessener Zeit
ausgeführt werden kann, so ist die Situation so, wie nebenstehend abgebildet.
Das Modell befindet sich als 3D-Vektorgraphik irgendwo im Haupspeicher.
Auch die Projektion wird durch die CPU als Pixelgraphik irgendwo im Hauptspeicher erzeugt.
Die Pixelgraphik muss aber noch zur Graphikkarte transportiert werden.
Da die Pixelgraphik je nach Bildgröße beträchtliche Ausmaße annehmen kann,
ist die Zeit für den Transport nicht vernachlässigbar. |
 |
Ganz anders verhält es sich, wenn Hardware-3D-Beschleunigung eingesetzt wird.
In diesem Fall wird die 3D-Vektorgraphik in einer Initialisierungsphase
direkt auf der Graphikkarte plaziert. Aus diesem Grunde haben
heute gebräuchliche Graphikkarten RAM-Größen von 32 MB und mehr.
 |
Die CPU verwaltet für jedes 3D-Modell eine Art "Deskriptor" (eine ganze Zahl).
Mit Hilfe dieses Deskriptors kann die CPU die Graphikkarte anweisen, das
betreffende Modell zu projizieren. Damit sich die virtuelle Welt bewegt, werden
vor der Projektion entsprechende Projektionsmatrizen auf der Graphikkarte
plaziert.
Die Graphikkarte übernimmt neben der Projektion die Beseitigung der
verdeckten Polygonteile, die Lichtberechnung und ähnliches mehr.
Dadurch wird einerseits die CPU aus dem gesamten 3D-Darstellungsprozess
herausgenommen und andererseits der Verkehr auf dem Bus auf nahezu Null reduziert.
Es liegt auf der Hand, dass dieses Verfahren auch durch eine noch
so schnelle CPU nicht kompensierbar ist. Bei Verwendung einer 800MHz-CPU
und einer Graphikkarte ELSA Gladiac GTS 2 ergibt sich ein Leistungsverhältnis
von 1:20.
|
Installation von JAVA3D
Wer die Hardware-3D-Beschleunigung realisiert hat, kann die Installation der
Java-2-Umgebung mit der Java-3D-Erweiterung beginnen. Man benötigt das
Java Software Development Kit, welches es für die Betriebssysteme:
JAVA3D erhält man für:
Achtung! Windows-95/98/ME/XP-Nutzer sollten die Direct3D-Variante
der OpenGL-Variante vorziehen, da unter diesen Betriebssystemen nur
diese Direct3D-Variante den 3D-Hardware-Beschleuniger richtig ausnutzt.
Die "Installation" besteht im Entpacken der Archive. Im Verzeichnis demo/java3d befinden sich
einige Beispielprogramme, die man zunächst testen sollte.
Übersetzen und Ausführen
Der Quelltext des Getriebemodells ist im Archiv j3dgetriebe.tgz. Im File LIESMICH.TXT
befinden sich noch einige Installationstipps und Informationen zur Benutzung des Programms. Die Übersetzung erfolgt durch das Kommando:
javac Getriebe.java
Das Programm kann sowohl als Applikation:
java Getriebe
als auch als Applet gestartet werden:
appletviewer Getriebe.html
Starten im WWW-Betrachter
Wie bereits erwähnt, muss man zunächst seinen WWW-Betrachter so umkonfigurieren, dass er die
lokale Java-Installation zum Anzeigen der Applets benutzt. Am einfachsten haben es die Linux-Nutzer, falls
sie KDE >= 2.0.x und Konqueror >= 1.9.8 benutzen. Dann genügt es, im Konqueror:
Einstellungen --> Einrichten -->Browser -->Java/JavaScript
auszuwählen, dort:
- Java global zu aktivieren;
- benutzerdefiniertes Java verwenden einzustellen
und
- als Pfad den Pfad zum lokal installierten Java einzustellen.
Danach lädt man einfach: Getriebe.html
Nutzer anderer Browser müssen ein Plugin installieren, welches die Benutzung der
lokalen Java-2-Maschine ermöglicht und laden dann Getriebe_plugin.html. Das Installieren des Plugins ist relativ mühevoll
und auch dem Autor noch nie auf die von den Plugin-Autoren beschriebene Weise
gelungen. Ein Tipp: Erstaunlicherweise hilft es beim Netscape, diesen noch einmal
komplett aus der Originaldistribution zu installieren (???):
Informationen über die Plugins sind unter.
http://www.javasoft.com/products/java-media/3D/java3dfaq-1.3.html#intro
zu finden.
Arbeitsweise
Aufbau von JAVA3D-Programmen
Die nebenstehende Abbildung zeigt den Aufbau eines einfachen JAVA3D-Programms.
Ein Text soll gedreht werden.
JAVA3D-Programme basieren auf einem Modellgraphen. Dieser Modellgraph
ist ein Baum (wenn man nur die dicken Pfeile verfolgt).
Jedes JAVA3D-Programm erzeugt zunächst ein
virtuelles Universum. Dieses besitzt ein rechts orientiertes 3-dimensionales
kartesisches Koordinatensystem. In diesem System ist eine Locale
definiert, zu welcher alle Koordinaten im Baum relativ sind.
Der Grund für dieses transformierte System liegt in der
Ausdehnung des virtuellen Universums. Es ist so groß wie unser
Universum (20 Mrd. Lichtjahre = 189 200 000 000 000 000 000 000 000 m).
Die Plejaden (offener Sternhaufen im Sternbild Taurus) sind
130 pc = 4 009 200 000 000 000 000 m entfernt.
|
 |
Wollte man ein Wasserstoffatom im Sternbild der Plejaden modellieren, so
wäre der Kern 130 pc entfernt. Das Elektron umkreist diesen
in einem Abstand von 0.5 Å (= 0, 000 000 000 050 m).
Somit wäre der Abstand des Elektrons vom Koordinatenursprung
4 009 200 000 000 000 000 m + 0, 000 000 000 050 m.
entfernt. Diese Addition kann man sich mit gewöhnlicher Double-Arithmetik "sparen", denn
als Ergebnis würde einfach 4 009 200 000 000 000 000
präsentiert. Im Sternhaufen der Plejaden fielen also Kern und Hülle
zusammen.
Um solche Modellierungen dennoch zu ermöglichen, werden sogenannte
Highresolution-Koordinaten verwendet:
Es handelt sich dabei um ein 8-elementiges Integer-Feld, mit einem
"gedachten" Komma nach dem 4. Element. Um nun die Verwendung
solcher umständlicher Zahlen auf ein Minimum zu begrenzen, wird
eine Locale mit Hilfe solcher Highresolution-Koordinaten plaziert und
nachfolgend mit double-Werten relativ zur Position der
Localen gearbeitet.
Die BranchGroups sind separat übersetzbare Teile des Modells. Das darf nicht
mit der JAVA-Programmübersetzung verwechselt werden! Hier ist mit
"übersetzen" etwas anderes gemeint. Wie bereits
ausgeführt wurde, werden am Anfang die Modelle zur Graphikkarte
transportiert. Dazu baut man den Modellgraphen bis zur BranchGroup auf
und ruft dann dessen compile()-Methode. Erst danach kann
die BranchGroup tatsächlich verwendet werden. Sie ist nach der
Übersetzung nicht mehr veränderbar. Das hätte natürlich zur Folge, dass
das Modell unbeweglich bleibt. Aus diesem Grunde, muss man vor der
Übersetzung bestimmen, was am Modell danach noch verändert werden darf.
Natürlich könnte man einfach alles erlauben. Das ist aber
nicht zu empfehlen, da Informationen über konstante Eigenschaften
bei der Übersetzung in höhere Effektivität umgemünzt werden.
Die TransformGruppen trennen solche Teile des Modells voneinander, die
in sich starr sind, also ihre relative Lage zueinander nicht
verändern. Die TransformGruppen selbst sind Träger einer Transformationsmatrix,
welche die Lage der TransformGruppe im Raum bestimmt.
Treten auf dem Weg von der Wurzel bis zu einem Knoten mehrere
TransformGruppen auf, so summieren (eigentlich multiplizieren) sich
ihre Wirkungen. Auf diese Weise kann zum Beispiel die komplizierte
Bewegung eine Rades an einem Auto als Überlagerung einer Translation
mit einer Rotation beschrieben werden.
Die Behavior-Knoten bestimmen das Verhalten des Modells. Sie
wirken auf die Knoten ein, ändern ihre Eigenschaften und können
so zum Beispiel eine Rotation hervorrufen.
Mit der ViewPlattform beginnt der "subjektive" Teil des Modells.
Sie bestimmt den Ort der Kamera. Ihre Position kann vom Behavior-Knoten
durch Ändern der Eigenschaften der TransformGruppe verändert werden.
Auf diese Weise kann sich der Nutzer im virtuellen Universum bewegen.
Dabei bestimmt die View die Kameraeigenschaften (Öffnungswinkel, ...).
Das 3DCanvas ist quasi der "Film", auf den das Gesehene projiziert wird.
Es handelt sich dabei um eine Subklasse des bekannten AWT-Canvas.
Somit ist der Anknüpfungspunkt zum "normalen" JAVA erreicht: Das
3DCanvas wird "ganz normal" auf der Appletoberfläche plaziert und
zeigt das Geschehen im virtuellen Universuim an.
Wie erzeugt man die Modelle?
Man könnte annehmen, dass bestimmte Grundobjekte (Kugel, Quader, Zylinder, ...)
als Körper bereits fertig vorliegen. Dem ist aber nicht so! JAVA3D kennt
überhaupt keine Körper. Zwar gibt es einige vordefinierte Modelle
in den JAVA3D-Utilities. JAVA3D selbst kennt aber als "kompliziertestes" Objekt das ebene Polygon, welches
durch seine Eckpunkte (Ortsvektoren) beschrieben werden muss. Will man Rundungen
modellieren, so muss man zudem noch die Flächennormalen an den Eckpunkten
vorgeben. Das wirft die Frage auf, wie man komplexe Objekte gestalten kann.
Im vorliegenden Getriebe-Programm wurden alle Modelle mit Hilfe mathematischer
Funktionen gebildet. In Zahnrad.java ist zu sehen, wie das Zahnrad
aus rund 5*Zähnezahl Polygonen zusammengesetzt wird.
Für viele Fälle wäre es jedoch besser, man könnte die Modelle interaktiv erzeugen. In diesem
Zusammenhang ist ein Projekt interessant, welches das Importieren sogenannter X3D-Files in JAVA3D-Programme
ermöglichen soll (http://hypermultimedia.com/Xj3D).
Der X3D-Standard gestattet das Beschreiben virtueller Welten mit
XML-Mitteln. Man kann annehmen, dass es bald auf diesem Gebiet viele Anwendungen
einschließlich Modellierer geben wird.
Wie beschreibt man das Verhalten der virtuellen Welt?
Bisher wurde an keiner Stelle behauptet, dass es sehr einfach ist,
JAVA3D-Welten zu programmieren. In der Tat ist das Finden der
Verhaltensbeschreibung relativ kompliziert. Für bestimmte Standardverhaltensweisen
(Mausnavigation, Rotation, Verschiebung, ...) gibt es vorgefertigte Behavior-Klassen.
Für alle anderen Verhaltensweisen, die sich nicht in solche einfachen Schemata
pressen lassen, müssen eigene Behavior-Klassen ersonnen werden.
JAVA3D ermöglicht über weite Strecken eine eher sachbezogene, wenig mathematische
Herangehensweise. Das Verhalten des vorliegenden Getriebemodells ist jedoch
keinem bekannten Standard auch nur ähnlich. In Elemente.java ist zu
sehen, wie die Bewegungskurven der einzelnen Getriebeelemente mit Hilfe
von Gleichungen bis 5. Grades errechnet werden. Die Gleichungen selbst
sind Lösungen eines nichtlinearen Gleichungssystems für das
4-Elemente-Koppelgetriebe. Zum Finden der Lösung wurde das
Formelmanipulationsprogramm MAPLE benutzt. Außerdem hat der
Autor mehrfach den Rat des Dipl.-Math. Ralph Sontag eingeholt, dem
an dieser Stelle herzlich gedankt sein soll.