Interaktive Darstellung einer Explosionszeichnung

Interaktive Darstellung einer Explosionszeichnung
anhand des studentischen Forschungsprojekts SOMP
Sebastian Erler, Constanze Klaus, Robert Krahn
Technische Universität Dresden, Fakultät Informatik
Institut für Software- und Multimediatechnik, Lehrstuhl für Mediengestaltung
Zusammenfassung: In dieser Arbeit wird auf die dreidimensionale
Umsetzung einer Explosionsgrafik bezüglich eines studentischen
Forschungsprojektes eingegangen. Die Projektarbeit resultiert in einer
interaktiven Anwendung, welche dem Benutzer es ermöglicht sich
einen einfachen aber genauen Überblick über das dargestellte Objekt
zu verschaffen.
1
Motivation
Abstrakte Modelle und technische Konstrukte sind für viele Menschen schwer
erfassbar und kompliziert zu erklären. Besonders im Bereich der Forschung gibt es
Projekte, deren wissenschaftliche und theoretische Konzeptionierung ausgeprägter
ist als die visuelle Gestaltung und somit für Außenstehende meist sehr praxisfern
wirken.
Illustrationen, Skizzen, Explosionsgrafiken, technische Zeichnungen oder andere
zweidimensionale Darstellungen können das Verständnis unterstützen, sind jedoch
in ihrer Präsentationsvielfalt meist unflexibel und eingeschränkt. Beispielsweise
zeigt eine Fotografie nur eine Ansicht auf ein Objekt und für Ansichten aus anderen
Perspektiven müssen neue Aufnahmen gemacht werden.
Dreidimensionale Modelle haben dagegen den Vorteil, dass ein Objekt jederzeit aus
einem anderen Blickwinkel betrachtet werden kann. Das räumliche
Vorstellungsvermögen des Betrachters wird durch diese Art der Darstellung
unterstützt und das Verständnis des komplexen Gegenstandes erleichtert.
Virtuelle 3D Modelle können zudem durch ihre Interaktivität und Manipulierbarkeit
die Anschaulichkeit von Funktionsweisen des Objekts fördern und motivieren den
Benutzer zum Selbststudium und experimentellen Lernen.
Ziel dieser Arbeit ist es ein interaktives virtuelles 3D Modell eines technischen
Forschungsgegenstands zu realisieren, welches in seiner Darstellungsform sowohl
für Laien als auch für Sachkundige geeignet ist. Zur detaillierten Betrachtung soll es
dem Nutzer möglich sein, sich frei um das Objekt zu bewegen und gleichzeitig eine
Explosionszeichnung als Animation zu steuern
2
Einführung
Virtuelle 3D Modelle finden in vielen Bereichen Anwendung. In der Medizin gibt es
beispielsweise interaktive Modelle einzelner Organe wie dem Herz [1], die sich
interaktiv erkunden lassen. Auch Produkte wie eine Computermaus [2] können als
Echtzeitmodell von allen Seiten betrachtet werden. Der äußere Aufbau dieser
Objekte und deren Struktur werden so anschaulich und intuitiv für den Benutzer
dargestellt.
Leider bleiben die innere Struktur und die Zusammenhänge von Objektteilen dem
Betrachter verborgen. Abhängigkeiten zwischen den Baugruppen oder die
Anordnungen einzelner Elemente sind meist nicht sichtbar, da es bei den
dargestellten Objekten zu Überlappungen und Verdeckungen kommt.
Eine Verbesserung dieser 3D Modelle besteht darin, auch den inneren Aufbau dem
Benutzer zugänglich zu machen. In der 2D Grafik wird dies meist durch eine
Explosionszeichnung des Objektes realisiert (angedeutet in Abbildung 1). Diese
Grafiken sind spezielle technische Zeichnungen. Während normale technische
Zeichnungen ein Objekt meist in der Draufsicht, Vorder- und Seitenansicht
abbilden, wird das Objekt bei einer Explosionszeichnung in seine einzelnen
Bauteile zerlegt und perspektivisch dargestellt. Zusammenhänge zwischen den
Elementen und Anordnungen von Baugruppen werden dadurch visualisiert.
Die Verbindung eines virtuellen 3D Modells und einer Explosionszeichnung in eine
interaktive Anwendung erlaubt es nun dem Nutzer ein Objekt in seiner Zerlegung
von allen Seiten betrachten zu können und somit auch den Aufbau innerhalb des
Objektes zu begreifen. Eine Erweiterung dieses Ansatzes mündet in der
interaktiven Steuerung der Explosionsgrafik, sodass das Objekt in differenzierten
Zerlegungsgraden dargestellt wird.
Die Konzipierung und prototypische Umsetzung der beschriebenen Erweiterung
virtueller 3D Modelle soll Gegenstand dieser Arbeit sein und anhand eines
Forschungsprojekts realisiert werden.
3
Projektgegenstand und Kooperationspartner
An Universitäten und Hochschulen gibt es viele Projekte, bei denen die eingangs
geschilderte Problematik des Herantragen von Forschungsthemen an ein breiteres
Publikum relevant ist. Das von uns ausgewählte Forschungsprojekt soll nun im
Folgenden genauer vorgestellt werden.
3.1
Kooperationspartner STARD
Kooperationspartner dieser Arbeit ist die Studentischen Arbeitsgruppe für
Raumfahrt in Dresden (STARD) am Institut für Luft- und Raumfahrttechnik der
Technischen Universität. Eines der laufenden fakultätsübergreifenden Projekte ist
der Bau eines Miniatursatellitens, welcher in der Erdumlaufbahn Daten erheben
soll.
3.2
CubeSat-Projekt SOMP
Seit 2006 arbeitet STARD am Bau eines Satelliten, dem Student's Oxygen
Measurement Project (SOMP), welcher im Rahmen des internationalen CubeSatProjekts stattfindet.
Das CubeSat-Projekt wurde von mehreren amerikanischen Universitäten initiiert um
Hochschulen, Forschungseinrichtungen und privaten Unternehmen einen
kostengünstigen Weg für Forschungen und Projekte im Weltall zu bieten. Die
entwickelten Miniatursatelliten, wegen ihres geringen Gewichts auch Picosatelliten
genannt, müssen dabei gewisse Spezifikationen erfüllen.
Die wichtigsten Standards eines CubeSats sind seine Ausmaße von 10 x 10 x 10
cm und das Gewicht von 1 kg. Mithilfe einer speziellen Startvorrichtung können
diese Satelliten als Sekundärnutzlast bei einem Raketenstart eines größere
Satelliten mitgeführt werden.
3.3
Missionsziele
Die Daten, welche durch das SOMP erfasst werden, dienen zwei Experimenten.
Zum einen wird der atomare Sauerstoff im Orbit der Erde gemessen. Dieser ist sehr
aggressiv und greift die Schutzschicht von Satelliten und Raumstationen an. Die
Messung erfolgt durch FIPEX-Sensoren, die ebenfalls an der TU Dresden am
Institut für Luft- und Raumfahrttechnik entwickelt wurden. Zum anderen werden
Dünnschichtsolarzellen
(DSSZ)
der
Firma
SOLARION
GmbH
unter
extraterrestrischen Bedingungen getestet. Die neuartigen flexiblen Solarzellen
kamen bisher nur auf der Erde zum Einsatz und sollen nun auf
Weltraumqualifizierung geprüft werden.
3.4
Aufbau des CubeSat SOMP
In Abbildung 1 ist eine exemplarische Explosionszeichnung des CubeSats zu
sehen. Der Satellit besteht im Wesentlichen aus einer Rahmenstruktur, deren sechs
Außenwände mit Solarzellen und Antennen versehen sind. Eine der Außenwände
ist die Nutzlastseite, welche zwei FIPEX-Sensoren in einer Einheit und vier
Dünnschichtsolarzellen in zwei Modulen trägt. Im Inneren der Struktur befindet sich
eine Anordnung von Leiterplatten, welche für die Subsysteme des Satelliten
verantwortlich sind. Die Kommunikation mit dem Satelliten findet über ein digitales
Funksystem im Amateurfunkbereich statt.
Abb. 1: Aufbau des CubeSats SOMP
[Web08]
4
Entwicklungsumgebung
Zur Realisierung der prototypischen 3D Anwendung wurde neben unterstützenden
Werkzeugen hauptsächlich die 3D Entwicklungsumgebung Blender genutzt.
Blender besticht durch eine Vielzahl an Möglichkeiten und Werkzeugen zur
Erstellung von dreidimensionalen Körpern und Szenen. Außerdem bietet es dem
Entwickler die Möglichkeit eigene Materialien, komplexe Animationen und diverse
graphische Effekte direkt im Programm zu erstellen. Neben der Modellierung von
Objekten und der Entwicklung von Animationen, beinhaltet Blender eine Funktion
zur Erstellung interaktiver Anwendungen. Diese Funktion, GameEngine genannt,
ermöglicht es anschauliche aus dem Bereich der Computerspiele bekannte,
dreidimensionale Umgebungen zu erschaffen, in welchen der Nutzer mit der
Anwendung interagieren kann. Die Entwicklung im Rahmen der GameEngine
erlaubt es unter anderem komplexe logische Zusammenhänge zwischen Objekten
zu erstellen und in der Programmiersprache Python geschriebene Skripte direkt in
die interaktive Anwendung einzubinden. Zum Beispiel könnte ein Interaktion
zwischen Nutzer und Anwendung mittels der Maus basierend auf der Nutzung eines
solchen Python Skripts realisiert werden.
Während eine dreidimensionale Animation nur beim einmaligen kodieren in einen
Film intensiv die Ressourcen des Rechners nutzt und sich beim späteren Abspielen
eher anspruchslos zeigt, wirkt sich die Komplexität der in der GameEngine
entwickelten Szene direkt auf die interaktive Anwendung aus. Bei der Entwicklung
der Anwendung musste entsprechend auf ein gutes Verhältnis zwischen grafischer
Attraktivität und performanter Ausführung geachtet werden.
Zusätzliche Vorteile von Blender sind eine Vielzahl bereits bestehender – mit
Blender entwickelten – Projekte, und die Veröffentlichung der Software unter der
„GNU General Puplic License“.
5
Arbeitsschritte der Anwendungsentwicklung
Die Entwicklung der Anwendung lässt sich in folgende Teilschritte unterteilen,
welche anschließend auszugsweise näher beschrieben werden sollen:
1. Einbindung und Anpassung der bereits gegebenen Rohdaten
2. Konzeption einer Szene für die Anwendung
3. Umsetzung der dreidimensionalen Explosionsanimation
4. Entwicklung eines User-Interfaces (Steuerung, Menü, etc.)
5. Detailarbeiten und ästhetische Effekte
Ausgangsbasis für die Anwendung bildet ein CAD1-Modell des Satelliten. Wie
bereits in Kapitel 4 erwähnt, bildete die Optimierung des Detailgrades in Bezug auf
die Performance der Anwendung einen wichtigen Teilschritt. CAD-Modelle sind
allgemein sehr wirklichkeitsgetreu und eignen sich nicht ohne weiteres zur
Darstellung in einer Echtzeitanwendung. Blender bietet jedoch eine Import-Funktion
für CAD-Modelle an, wodurch ein Informationsverlust durch eventuelles
eigenständiges Modellieren verhindert wird. Somit können CAD-Modelle sehr gut
als Ausgangsobjekt genutzt werden. Grundsteinlegend für den weiteren Verlauf des
Projekts wurde das CAD-Modell nach dem Einfügen in das Projekt stark
1Computer
Aided Design
vereinfacht. Dabei wurden nicht sichtbare Details sowie unnötige geometrische
Strukturen entfernt.
Parallel zur geometrischen Vereinfachung des Satelliten-Modells und der
Entwicklung von Texturen bzw. Materialien für den Satellit, wurden erste Konzepte
der globalen Szene erarbeitet. Die genauen Inhalte und die Probleme bei der
Konstruktion der Szene werden in gesonderten Abschnitten erläutert.
Der dritte Arbeitsschritt, die Umsetzung der Explosion, erfolgte nach den Vorgaben
des Lehrstuhls für Luft- und Raumfahrttechnik. Das User-Interface und die
Interaktion wurde versucht leicht verständlich und dezent zu realisieren.
6
6.1
Aufbau und innere Struktur der Anwendung
Das User Interfaces
Es wurde versucht das User Interface übersichtlich, intuitiv und dezent zu gestalten.
Abbildung 2 zeit das Startmenü, welches den Nutzer nach der Startanimation
empfängt. Der Nutzer hat hier die Möglichkeit die eigentliche Anwendung zu
starten, sich kurze über das SOMP Projekt zu informieren oder eine Übersicht der
am Projekt beteiligten Personen anzeigen zu lassen. Des Weiteren kann das
Programm beendet werden.
Abbildung 3 zeigt alle Menüs im Hauptteil der Anwendung, welche durch Klicken
auf das jeweilige Symbol in der unteren linken Ecke des Bildschirms geöffnet und
geschlossen werden können. In der Reihenfolgen von links nach rechts sind dort
die Menüs „Options“, „Sound“, „Controls“ und „Exit“ hinterlegt. Über das
Optionsmenü können einzelne Baugruppen des Satelliten ein- und ausgeblendet
und der Grad der Explosionszeichnung geregelt werden. Neben der
Anwendungssteuerung durch die Maus sind zusätzlich alle grundlegenden
Funktionen über die Tastatur nutzbar.
Abb. 2: Startmenü
Abb. 3: Anwendungsmenü
6.2
Konzeption der Anwendung
Abb. 4: Szenenaufbau
Blender bietet die Möglichkeit Inhalte innerhalb einer Anwendung in verschiedene
Szenen zu gliedern und bei der Ausführung durch diese unterschiedlchen Szenen
zu wechseln. In der Konzeptionsphase entstand eine Aufteilung in 5 Szenen welche
in Abbildung 4 dargestellt ist. Nach Starten der Anwendung wird dem Anwender
zunächst ein Schriftzug und ein Ladebildschirm präsentiert. Dies ist die initiale
Szene, „Fade-In“. Sie dient dazu, dem Nutzer nicht sofort zu viele Eindrücke zu
vermitteln und bietet schnelles Feedback nach dem Starten ohne lange Wartezeit.
Ist der Ladevorgang abgeschlossen wird automatisch in die Szene „Startup“
übergegangen und eine kurze Animation abgespielt, die schließlich in das
Hauptmenü mündet. An dieser Stelle kommen die in Abbildung 4 gepunktet
dargestellten Szenen zum Einsatz. Diese Szenen überlagern optisch jeweils die
aktive Szene und beinhalten das User Interface. Dies hat den Vorteil, dass zu
keinem Zeitpunkt Elemente des User-Interface von anderen Objekten
durchdrungen werden können. Ausgehend vom Hauptmenü kann der Nutzer nun in
die Szene „Interactive“ wechseln. Sie stellt nicht nur die Hauptfunktion der
Anwendung bereit, sondern beinhaltet auch die wichtigsten Objekte wie den
Satelliten oder die Umgebung.
6.3
Aufbau und Entwicklung der interaktiven Szene
Die interaktive Szene stellt den Kernteil der Anwendung dar. Die Interaktion mit dem
CubeSat findet in einer Nachbildung des Welltall statt, um dem Benutzer ein
gewisses Raumgefühl zu vermitteln und gleichzeitig die Umlaufbahn des Satelliten
zu simulieren.
Die Bestandteile der Szene können in Gruppen gegliedert werden. Die erste
Gruppe von Objekten stellt die Umgebung dar. Sie beinhaltet die Erde, deren
Atmosphäre, das Weltall und ein Bild der Sonne (siehe Abbildung 5). Die
Atmosphäre ist rosa markiert und das Weltall wurde zur besseren Übersicht als
Gitter dargestellt.
Abb. 5: Bestandteile der Umgebung
Die Atmosphäre wurde abstrahiert und als Scheibe konstruiert, welche erst aus
Sicht der Kamera wirkt als würde sie die Erde komplett umschließen. Wie auch das
Bild der Sonne richten sich diese beiden Objekte während der Nutzung der
Anwendung permanent nach der Position der Kamera im Raum aus, um die
Simulation der Umgebung beständig zu halten.
Besonders viele Objekte und damit auch rechenintensive Geometrie sind in der
Gruppe des Satelliten vereinigt. Dieser besteht unter anderem aus den
Seitenwänden samt Solarzellen, den Antennen, dem Rahmen und den Platinen im
Inneren (siehe Abbildung 1). Wobei jedes dieser Elemente wiederum mehrere
Objekte enthält. So sind die FIPEX-Sensoren zur Messung des atomaren
Sauerstoffs zum Beispiel auf einer Seitenwand befestigt und bestehen selbst aus
mehreren Einzelteilen (siehe Abbildung 6).
Abb. 6: Drahtgittermodell des CubeSat
Die letzte Gruppe besteht aus Hilfsobjekten welche in der späteren Anwendung
nicht sichtbar sind. Darin sind die Kamera, Lichtquellen und sogenannte EmptyObjekte enthalten. Diese Empty-Objekte dienen lediglich der Strukturierung von
Objekten, wie im Folgenden noch dargelegt wird. Darüber hinaus können sie auch
dazu verwendet werden, Programmlogik zu tragen ohne selbst jemals in der
Anwendung sichtbar zu sein.
Abbildung 10 zeigt das Drahtgittermodell der interaktiven Szene. Das grobmaschige
äußere Modellnetz stellt die Abstraktion des Weltalls als Sternenhintergrund dar
und die Modellkugel im Innern die Erde. Weiterhin sind mehrere Objekte zu sehen,
die nur dünne Koordinatenachsen zeigen. Dies sind die angesprochenen EmptyObjekte. Das größte dieser Objekte, welches seinen Ursprung in der Mitte der Erde
hat, ist das „World-Empty“ und dient dazu die 90 minütige Rotation des Satelliten
um die Erde zu realisieren. Bei Betrachtung dieser Objekte bietet sich die
Erläuterung der Objekthierarchien an. In Blender, wie auch in anderen 3DEntwicklungsumgebungen, existiert das Konzept das „parenting“. Durch diese
Operation wird ein Objekt zum Eltern-Objekt eines anderen, im Folgenden KindObjekt genannt, erhoben. Diese Bindung hat die Orientierung des Kind-Objektes
am Koordinatenraum des Eltern-Objektes zur Folge. Der Satellit wurde auf diese
Weise am „World-Empty“ orientiert. Neben dem Satelliten besitzt das „World-
Emtpy“ zwei weitere Kinder, ebenfalls Empty-Objekte, welche zur Bewegung und
Positionierung der Kamera genutzt werden.
Dreht sich nun das „World-Empty“ um eine Achse, so tun dies auch der Satellit und
die Kamera. Wobei es durch diese Hierarchie zusätzlich möglich wird die Kamera
um den Satelliten herum zu rotieren. An dieser Stelle sei erwähnt, dass weder die
24h-Rotation der Erde um ihre eigene Achse, noch deren jährliche Rotation um die
Sonne nachgestellt wurden.
Die Abbildungen 7 bis 9 zeigen die Beziehungen der „Empty“ Objekte zu einander
am Beispiel der Rotation des „World-Empty“. Das rosa eingefärbte „World-Empty“
wird an dessen Y-Achse um die Kugel rotiert, dabei verändert sich die Position der
gekoppelten, kleineren Kind-Objekte. In Abbildung 9 ist zu erkennen, dass KindObjekte zwar ihre Position entsprechend den Eltern verändern, sich aber dennoch
frei rotieren lassen. Diese Eigenschaft wird zur freien Bewegung der Kamera um
den Satelliten genutzt.
Abb. 7: Veranschaulichung der Rotation – Schritt 1
Abb. 8: Veranschaulichung der Rotation – Schritt 2
Abb. 9: Veranschaulichung der Rotation – Schritt 3
In der Mitte von Abbildung 10 lassen sich die zwei Empty-Objekte erkennen, welche
für die Rotation der Kamera um den Satelliten verantwortlich sind. Ein Objekt
realisiert die vertikale-, das andere die horizontale Rotation der Kamera.
In Hinblick auf die Nutzerfreundlichkeit der Steuerung wurde schnell klar, dass die
Rotation der Kamera in der Vertikalen eingeschränkt werden muss. Das Ziel ist ein
eingeschränkter vertikaler Rotationsspielraum auf 180°. So kann die Kamera
maximal bis senkrecht von oben bzw. unten schauend auf den Satelliten bewegt
werden. Dadurch wird eine Überkopfstellung der Kamera und somit die Invertierung
der horizontalen Rotation um den Satelliten vermieden um dem Nutzer eine
einfachere Orientierung im Raum zu ermöglichen. Es ist dennoch möglich aus
jedem beliebigen Winkel den Satelliten zu betrachten.
Ein weiterer interessanter Aspekt der Szene bezieht sich auf den Umgang mit
Sternenhintergrund und Sonne. Der Sternenhintergrund ist in Abbildung 10 als
Gittermodel dargestellt.
Abb. 10: Drahtgittermodell der interaktiven Szene
Um möglichst wenig Geometrie somit Rechenleistung für den Hintergrund
verwenden zu müssen wurde das Weltall in eine kugelähnliche Form mit lediglich
30 Flächen abstrahiert. Auf diesen Flächen ist ein sich wiederholendes Muster von
Sternen auf schwarzem Grund aufgebracht. Die Illusion wirkt allerdings nur,
solange der Betrachter sich in der Mitte dieser Kugel befindet. Da die Kamera, wie
bereits angesprochen, um die Erde rotiert ändert sich damit auch die Position des
Betrachters in der Szene (Abbildung 10). Um die Gleichabständigkeit des
Betrachters zu den Flächen des Sternenhintergrunds zu wahren muss der
Hintergrund mit der Kamera mit bewegt werden. Würde man dies nicht tun, käme
der Betrachter bei einer bestimmten Kamerabewegung näher an den „Rand des
Universums“ und würde so die Sterne größer wahrnehmen als aus dem Zentrum in
der Szene. In Analogie zu den Eltern-Kind Beziehungen des „World-Emty“, liegt die
Lösung des Problems darin, den Sternenhintergrund durch „parenting“ an die
Kamera zu binden. Gleichzeitig musste aber dafür gesorgt werden, dass sich die
Sterne nicht mit der Kamera um die Erde drehen.
Eine weitere Abstraktion betrifft die Sonne. Die Ausführungsgeschwindigkeit einer
dreidimensionalen Szene wird wesentlich durch den Komplexitätsgrad der
enthaltenen Objekte bestimmt. Ein viel verwendeter Ansatz liegt darin, Objekte nicht
als dreidimensionales Objekt in die Szene zu integrieren. Statt dessen wird lediglich
eine Bild dieses Objektes (eine Textur) auf eine Fläche aufgetragen. Dies führt zu
wesentlich weniger geometrischen Strukturen in der laufenden Anwendung bei
akzeptabler Darstellungsqualität. War bei der Erde dieses Verfahren durch deren
Umkreisung nicht möglich, kann die Sonne jedoch abstrahiert werden. In der
Anwendung wird es nie dazu kommen, dass der Betrachter sich hinter die Sonne
bewegen kann. Gleichzeitig muss nur dafür gesorgt werden, dass diese Fläche
immer senkrecht zur Blickrichtung steht.
7
Probleme bei der Erstellung
Während des Entwicklungsprozesses traten mehrere Probleme im Bereich der
Darstellung und Konzipierung auf, die im Folgenden näher beleuchtet werden
sollen.
7.1
Realitätsnahe Darstellung der Umgebung
Das erste Problem bestand darin, dass der 10 cm große Satellit und die im
Durchmesser ca. 12.750 km große Erde im Größenverhältnis von rund 1:120
Millionen zueinander stehen und dieses in Blender aufgrund von begrenzter
Rechenleistung nicht darstellbar ist. Die Erde wurde deshalb wesentlich kleiner
gehalten, ebenso der Abstand des CubeSat zur Erde.
Dadurch entstand ein weiteres Problem. Der Skalierungseffekt für den Satelliten
hatte auch Einfluss auf die Größenwahrnehmung der Erde. Die Kamera wurde bei
einem Herauszoomen aus der Szene weiter weg von den Objekten bewegt. Durch
den verhältnismäßig kleinen Abstand von Kamera und Erde wurde das Sichtfeld auf
die Erdoberfläche größer, obwohl es sich in der Realität aufgrund der
Größenverhältnisse nicht merklich verändern würde.
Das Problem wurde durch eine Hilfskonstruktion gelöst, indem sich beim Zoomen
nunmehr nicht die Kamera bewegt, sondern der CubeSat skaliert wird. Das
Sichtfeld auf die Erde bleibt somit gleich und der Benutzer bekommt durch das
Vergrößern und Verkleinern des Satelliten den Eindruck eines Skalierungseffekt.
7.2
Vertikale Rotation der Kamera um den Satelliten
Der CubeSat soll durch den Benutzer interaktiv erforscht werden und von allen
Seiten betrachtet werden können, weshalb die Kamera frei im Raum steuerbar ist.
Bei einer vertikalen Bewegung kommt es jedoch ab einem bestimmten Punkt zu
Problemen bei der Steuerung. Sobald die Kamera über den Satelliten hinüber
schwenkt, spiegelt sich die Steuerung. Ebenfalls bei einem Schwenk unterhalb des
Satelliten. Eine Mausbewegung nach rechts führt nun nicht mehr zu einer
Kamerarotation gegen den Uhrzeigersinn, sondern mit dem Uhrzeigersinn.
Die Kamera besitzt zwei Rotationszentren an welchen jeweils x-, y-, z-Achsen
liegen, die im Mittelpunkt des Satellitenmodells zusammen führen – eines für die
horizontale Bewegung Rh und eines für die vertikale Bewegung Rv. Bei einer
horizontalen Kameraveränderung bleibt die z-Achse zh des Rotationszentrums Rh
fest. Bei einer vertikalen Veränderung bleibt die y-Achse yv von Rv fest.
Angenommen es wird eine Mausbewegung nach oben ausgeführt, so wird nur um
die Rotationsachse yv gedreht und die Achsen von Rh bleiben unverändert. Nun
wird die Bewegung der Maus beispielsweise an der Stelle gestoppt, bei der sich die
z-Achse zv um 180° gedreht hat. Die Kamera steht somit global gesehen kopfüber
und zv zeigt in die entgegengesetzte Richtung wie zh. Bewegt man nun die Maus
nach rechts, d.h es wird nur um die Rotationsachse zh gedreht und die Achsen von
Rv bleiben unverändert, wird von Rh aus betrachtet immer noch eine Rotation
gegen den Uhrzeigersinn ausgeführt. Von Rv aus gesehen wird jedoch die Kamera
mit dem Uhrzeigersinn gedreht und der Benutzer nimmt eine gespiegelte Steuerung
wahr.
Um das Problem zu lösen könnte man die Steuerung in diesen Fällen intern
invertieren, damit der Benutzer wie gewohnt die Maus bewegen kann. Wir haben
uns jedoch gegen diese Variante entschieden, da es unter Umständen zu einem
„lost in space“ Gefühl des Benutzers kommen kann und er die Orientierung in der
Ansicht verliert. Wir haben uns stattdessen für eine Einschränkung der Navigation
entschieden. Die Kamera kann nun bei einer vertikalen Bewegung nur noch
zwischen -90° und 90° rotieren, gemessen vom Ursprungszustand der Achsen, und
das Kopfstehen der Kamera wird somit verhindert.
7.3
Interaktiv wechselndes Kamerazentrum
Um die Interaktivität der Anwendung zu erhöhen, war es vorgesehn einzelne
Elemente des CubeSat selektieren und genauer betrachen zu können. Die Kamera
müsste sich dafür auf die ausgewählten Bauteile neu ausrichten und die
Rotationszentren auf den Mittelpunkt des Objekts verschoben werden. Aufgrund
unseres Systemaufbaus war uns dies nicht möglich zu realisieren. Versuche
zeigten, dass die Verschiebung des Satelliten aus dem Bildmittelpunkt zu
Objektverzerrungen und -durchdringungen führt.
8
Fazit und Ausblicke
Häufig verschlingt die Entwicklung eines Prototypen viel Zeit. Oft wird dabei viel Zeit
für bisher unbekannte Problemstellungen oder die Auseinandersetzung mit neuen
Entwicklungsprozessen verwendet. Auch im Fall dieser Projektarbeit kann man
rückblickend ähnliche Feststellungen treffen. Im Verlauf des Projekts wurden
wertvolle Erfahrungen gesammelt und wichtige Fähigkeiten erlernt. Künftige
Arbeiten im Rahmen der Blender-Umgebung könnten somit schneller und
organisierter bearbeitet werden. Der gesamte Ablauf ließe sich besser planen und
gegebenenfalls in einzelne detailliertere Phasen unterteilen. Abschließend kann
man den Verlauf des Projekts als sehr lehrreich, jedoch auch als zeitintensiv
beschreiben.
Neben vielen Detailarbeiten an Texturen und kleinen Effekten bietet der
entstandene Prototyp einige Möglichkeiten für Erweiterungen. Einerseits wäre ein
Plugin für Blender denkbar, welches es ermöglichen würde dreidimensionale
Explosionsanimationen relativ einfacher und schneller zu erzeugen. Dieses Plugin
würde die Erfahrungen des Projekts nutzen und für zukünftige, ähnlich geartete
Arbeiten zur Verfügung stellen. Blender bietet für die eigene Entwicklung und
Einbindung von Plugins bereits gute Grundlagen.
Mittels Skripten können Entwickler umfassend auf die Funktionen der
Entwicklungsumgebung zugreifen und Prozesse automatisieren und vereinfachen.
Die umfassende Dokumentation und der öffentlich zugängliche Quellcode des
Programms (Blender) wirken sich dabei unterstützend auf die Entwicklung und die
resultierenden Fähigkeiten eines Plugins aus.
Die Grundidee für ein „Explosions-Plugin“ beinhaltete folgenden Ansatz: Es könnte
dem Blender-Nutzer ermöglicht werden für einzelne Objekte Bewegungsachsen zu
definieren auf welchen sich die Objekte während einer Explosion bewegen würden.
Zusätzlich wäre es gegebenenfalls möglich zeitliche Abhängigkeiten im Verlauf
einer Explosion zu konfigurieren. Resultierend aus diesen Einstellungen wäre das
Plugin in der Lage automatisch eine Animation zu erzeugen. In wie weit komplexere
Bewegungen, zum Beispiel eine Rotation um eine Achse bei gleichzeitiger
Bewegung auf der gleichen Achse, zum Beispiel für Schrauben, möglich wären,
hätte im Verlauf der Entwicklung des Plugins untersucht werden müssen. Unter
Berücksichtigung der gesammelten Erfahrungen scheint ein solches Plugin
durchaus realisierbar zu sein.
Eine weitere Erweiterung des Projekts stellt eine Anbindung der „WiiMote“ zur
Steuerung der Kamera in der Anwendung dar. Die freie Bewegung der „WiiMote“ im
Raum würde eine intuitive Steuerung innerhalb der dreidimensionalen Szene
erlauben und es gegebenenfalls dem Benutzer erlauben sich einfacher bzw.
spielerischer mit der Anwendung auseinander zu setzen. Im Internet2 wurden
bereits auf der Steuerung mit der „WiiMote“ basierende Projekte veröffentlicht, eine
Umsetzung scheint somit durchaus möglich.
2http://www.selectparks.net/modules.php?name=News&file=article&sid=628
Literatur
[Web08]
Weber, A.: CubeSat in Dresden - Die Studenteninitiative SOMP
(Vortragsfolien), Internationale Luft- und Raumfahrtausstellung, Berlin, Mai 2008
Verzeichnis von Webadressen
[1]
Uniklinikum Saarland, 3D Modelle in der Anatomie, http://www.uniklinikumsaarland.de/med_fak/anatomie/bock/java/frameher.htm, Abruf: 01.09.2009
[2]
EDV für konstruierende Berufe, Visualisierung / Animation, http://www.choppen.de/inhalt_visualisierung_animation.htm, Abruf: 01.09.2009