Entwicklung eines Vorgehensmodells zur systematischen Erzeugung webbasierter 3D-Welten

Inhaltsverzeichnis

Eidesstattliche Erklärung

Danksagung

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Zusammenfassung

1. Einleitung
1.1. Motivation
1.2. Herausforderung
1.3. Ziel der Diplomarbeit
1.4. Aufbau der Diplomarbeit

2. Stand des Wissens
2.1. Definitionen
2.1.1. Augmented Reality (AR)
2.1.2. 3D-Objekt
2.1.3. 3D-Szene
2.1.4. 3D-Web und Web-3D
2.1.5. Virtuelle Welt
2.1.6. Echtzeitvisualisierung
2.1.7. Immersives Internet
2.2. Vorgehensmodelle
2.2.1. Übersicht
2.2.2. Software Engineering und Web Engineering
2.2.2.1. Geschichtliche Entwicklung und Definition
2.2.2.2. Phasen
2.2.2.3. Charakteristika von Web-Anwendungen
2.2.2.4. Die UML-Methode
2.2.2.5. Methode der agilen Softwareentwicklung
2.2.2.6. Methode der modellgetriebenen Webentwicklung (MDWE)
2.2.3. Multimedia-Produktion (MP)
2.2.3.1. Definition und Charakteristika von Multimedia
2.2.3.2. Die zusammengefassten Phasen der Multimedia-Produktion
2.2.3.3. Multimedia-Anwendungsentwicklung nach Sawhney
2.2.3.4. Workflow in der 3D-Visualisierung nach Höhl
2.3. Technik
2.3.1. Übersicht und Analyse von 3D-Plattformen
2.3.1.1. Grundlagen
2.3.1.2. Übersicht über 3D-Plattformen
2.3.1.2.1 Der Gigant: Second Life
2.3.1.2.2 Der Neuling: Twinity
2.3.1.2.3 Der Hoffnungsträger: OpenSim
2.3.1.2.4 Aus der Java-Welt: Project Wonderland
2.3.1.3. Analyse von 3D-Plattformen
2.3.1.3.1 Kriterien
2.3.1.3.1.1 Systemanforderungen
2.3.1.3.1.2 Importierfähige Grafikformate
2.3.1.3.1.3 3D-Grafikprogramme
2.3.1.3.1.4 Skriptsprachen
2.3.1.3.2 Vergleich
2.3.1.3.2.1 Systemanforderungen
2.3.1.3.2.2 3D-Grafikformate
2.3.1.3.2.3 3D-Grafikprogramme
2.3.1.3.2.4 Skriptsprachen
2.3.2. Modellierung von 3D-Welten
2.3.2.1. Inworld-Build-Tool bei Second Life
2.3.2.2. 3d Studio Max
2.3.2.3. Blender
2.3.2.4. Google SketchUp
2.3.3. Integration von 3D-Welten in existierende 3D-Plattformen
2.3.3.1. Übersicht
2.3.3.2. VRML (.wrl)
2.3.3.3. X3D (.x3d)
2.3.3.4. 3D-Studio File Format (.3ds)
2.3.3.5. Wavefront Object (.obj)
2.3.3.6. Collaborative Design Activity (Collada) (.dae)
2.3.3.7. Andere Möglichkeiten der Integration in 3D-Plattformen

3. Ausarbeitung eines Gesamtmodells für die Entwicklung virtueller 3D- Anwendungen
3.1. Anforderungen
3.2. Entwicklung des neuen Modells (3DWebVM)
3.2.1. Betrachtung und Zusammenführung der Phasen des Web Engineering und der Multimedia-Produktion
3.2.1.1. WE: Problemdefinition und MP: Vorphase
3.2.1.2. WE: Anforderungsanalyse und MP: Rohkonzept
3.2.1.3. WE: Spezifikation und MP: Rohkonzept
3.2.1.4. WE: Entwurf und Implementierung sowie MP: Preproduktion, Produktion und Postproduktion
3.2.1.5. WE: Erprobung und Auslieferung sowie MP: Distribution
3.2.1.6. Zusammenfassung aller Phasen im Phasenmodell des 3DWebVM
3.2.2. Betrachtung der konkreten WE- und MP-Modelle hinsichtlich des 3DWebVM
3.2.2.1. UML Methode
3.2.2.2. Agile Softwareentwicklung
3.2.2.3. Modellgetriebene Webentwicklung
3.2.2.4. Multimediaentwicklung nach Sawhney
3.2.2.5. 3D-Visualisierung nach Höhl
3.2.3. Abdeckung der Eigenschaften von Web-, Multimedia- und 3D-Anwendungen
3.2.4. Modellierung des 3DWebVM als Prozess
3.2.4.1. Auswahl eines Modellierungswerkzeugs und der passenden Notation
3.2.4.2. Aufteilung der Hauptprozesse in EPK-Prozesswegweiser
3.2.4.3. Eingrenzung der zu modellierenden Hauptprozesse
3.2.4.4. Anforderungsanalyse Software & Medien
3.2.4.5. FIV-Spezifikation
3.2.4.6. Entwurf
3.2.4.7. Implementierung
3.2.4.8. Preproduktion
3.2.4.9. Produktion
3.2.4.10. Postproduktion
3.2.4.11. Erprobung und Auslieferung
3.2.5. Einordnung des 3DWebVM
3.2.5.1. Ausbaustufe
3.2.5.2. Submodelle
3.2.5.3. Phasenabdeckung
3.2.5.4. Gestaltungsdomäne
3.2.5.5. Branchenspezifität
3.2.5.6. Formalisierungsart
3.2.5.7. Format
3.2.5.8. Zusammenfassung

4. Umsetzung am Beispiel des KnowCubes der HHN
4.1. Aufgabenstellung
4.2. Analyse der Anforderungen
4.2.1. Allgemein
4.2.2. Analyse anhand der formulierten Anforderungen
4.2.3. Zusammenfassung der Anforderungsanalyse
4.3. Entwurf des KnowCube
4.4. Implementierung des KnowCube
4.4.1. Programmierung der 3D-Web-Schnittstelle
4.4.1.1. Application-Server-Side
4.4.1.2. 3D-Server-Side
4.4.2. Installation und Start des 3D-Servers
4.4.3. Installation des Application-Servers
4.4.4. Installation des 3D-Clients
4.4.5. Installation von SketchUp inklusive der Plugins Ogre-Mesh-Exporter und OgreXMLConverter
4.5. Preproduktion des Prototyps
4.5.1. Modellierung des KnowCubes in SketchUp
4.5.2. Erstellen einer Testtextur in Photoshop
4.5.3. Texturierung des KnowCube in SketchUp
4.5.4. Exportieren des KnowCubes aus SketchUp im Ogre-Mesh-Format
4.5.5. Installation des Testservers und des Testclients
4.5.6. Import der KnowCube-Daten auf dem Server über den Client
4.5.7. Erstellen und Texturierung des KnowCube
4.6. Produktion
4.6.1. Modellierung des KnowCube
4.6.2. Erstellung der Texturen
4.6.3. Texturierung des KnowCubes
4.6.4. Import der Inneneinrichtung aus der Google 3D-Galerie
4.6.5. Exportieren des KnowCubes und der Einrichtung in das Ogre-Mesh-Format
4.7. Postproduktion
4.7.1. Import der 3D-Objekte auf den 3D-Server
4.7.2. Import der Texturen und Texturierung der 3D-Objekte
4.7.3. Assemblieren der 3D-Welt
4.8. Erprobung und Auslieferung
4.8.1. Validierung der Software
4.8.2. Überprüfung der Inhalte der 3D-Welt

5. Fazit
5.1. Lessons learned
5.2. Abgeleitete Erkenntnisse bezüglich des 3DWebVM
5.3. Verbesserungsvorschläge für das 3DWebVM
5.4. Ausblick

Literaturverzeichnis

Anhang

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Gartner Hype Cycle

Abbildung 2: Eigenschaften von Web-Anwendungen

Abbildung 3: Multimedia als ein Konzept, das technische und anwendungsbezogene Dimensionen integriert

Abbildung 4: Eigenschaften von multimedialen Anwendungen

Abbildung 5: Modell der multimedialen Anwendungsentwicklung nach Sawhney

Abbildung 6: Ablauf der Medienherstellung nach Sawhney

Abbildung 7: Workflow der 3D-Visualisierung nach Höhl

Abbildung 8: Software-Stack von Wonderland in der aktuellen Version 0.5

Abbildung 9: Aus der Java-basierten Anwendung heraus wird die 3D-Welt zur immersiven Kommunikation erzeugt

Abbildung 10: KnowCube mit dem Second Life-builder modelliert

Abbildung 11: KnowCube und Umgebung mit Google SketchUp nachmodelliert

Abbildung 12: Entwicklung der Phase a Aufgabendefinition

Abbildung 13: Entwicklung der Phase b Anforderungsanalyse Software & Medien

Abbildung 14: Entwicklung der Phase c FIV-Spezifikation

Abbildung 15: Entwicklung der Phasen Entwurf, Implementierung, Preproduktion, Produktion und Postproduktion

Abbildung 16: Entwicklung der Phase g Erprobung und Auslieferung

Abbildung 17: Das Phasenmodell liefert das Grundgerüst des 3DWebVM

Abbildung 18: 3DWebVM Phasenabdeckung durch die UML Methode

Abbildung 19: 3DWebVM Phasenabdeckung durch agile Methoden

Abbildung 20: 3DWebVM Phasenabdeckung durch modellgetriebene Entwicklung

Abbildung 21: 3DWebVM Phasenabdeckung durch das Modell nach Sawhney

Abbildung 22: 3DWebVM Phasenabdeckung durch das Modell nach Höhl

Abbildung 23: Erweiterung des 3DWebVM nach Höhl

Abbildung 24: Eigenschaften von 3D-Anwendungen

Abbildung 25: Prozesswegweiser des GP „Webbasierte 3D-Welten erzeugen“

Abbildung 26: EPK der Anforderungsanalyse Software & Medien

Abbildung 27: EPK der FIV-Spezifikation

Abbildung 28: EPK des Entwurfs

Abbildung 29: EPK der Implementierung

Abbildung 30: EPK der Preproduktion

Abbildung 31: EPK der Produktion

Abbildung 32: EPK der Postproduktion

Abbildung 33: EPK der Erprobung und Auslieferung

Abbildung 34: KnowCube der Hochschule Heilbronn

Abbildung 35: Die vier Seiten des KnowCube

Abbildung 36: Klassendiagramm für den Zugriff auf admin_create_user über RemoteAdmin

Abbildung 37: Komponentendiagramm zur Veranschaulichung der Serverschnittstelle

Abbildung 38: Komponente openSimConnector des Application-Servers

Abbildung 39: Klasse useRemoteAdmin in UML-Notation

Abbildung 40: Grundstruktur der Klasse useRemoteAdmin als PHP-Code

Abbildung 41: Parameter von useRemoteAdmin initialisieren

Abbildung 42: XML-Daten generieren

Abbildung 43: Verbindung zum Socket des 3D-Servers herstellen

Abbildung 44: XML-Daten senden und den Response parsen

Abbildung 45: Anwendung der Klasse useRemoteAdmin

Abbildung 46: KnowCube Grundgebilde

Abbildung 47: Testtexturen des KnowCubes

Abbildung 48: Der texturierte KnowCube-Prototyp

Abbildung 49: Der Cube ist nach dem Import nur zwei Meter hoch

Abbildung 50: Der texturierte Prototyp

Abbildung 51: Innenwände des KnowCubes

Abbildung 52: Die vier Außentexturen des KnowCubes

Abbildung 53: Der KnowCube nach der Texturierung in SketchUp

Abbildung 54: Stuhl und Beamer importiert

Abbildung 55: Fertiger KnowCube (Frontansicht)

Abbildung 56: Fertiger KnowCube (Rückseite)

Abbildung 57: Fertiger KnowCube (Eingangsbereich)

Abbildung 58: Innenraum des fertigen KnowCubes

Abbildung 59: Broadcasting: Hallo 3D-Welt!

Abbildung 60: "Hallo 3D-Welt!" wird im 3D-Client ausgegeben.

Abbildung 61: Zuweisung des Koordinatenursprungs im RexMeshTool

Abbildung 62: Avatar nimmt auf dem Stuhl Platz

Abbildung 63: Ausführliche Darstellung des 3DWebVM

Abbildung 64: Praktisch angepasstes Phasenmodell

Tabellenverzeichnis

Tabelle 1: Vergleich Betriebssysteme

Tabelle 2: Vergleich CPUs

Tabelle 3: Vergleich RAM-Größen

Tabelle 4: Vergleich Grafikanforderungen

Tabelle 5: Vergleich 3D-Grafikformate

Tabelle 6: Vergleich 3D-Grafikprogramme

Tabelle 7: Vergleich Skriptsprachen

Tabelle 8: Exportierbare Formate von 3D-Modellierungswerkzeugen

Tabelle 9: Rote Kugel in VRML

Tabelle 10: Rote Kugel in X3D

Tabelle 11: Chunk-Hierarchie

Tabelle 12: Würfel mit Materialien

Tabelle 13: Charakteristische Dimensionen der Vorgehensmodelle

Tabelle 14: Einordnung der Ausbaustufe des 3DWebVM

Tabelle 15: Einordnung der Submodelle des 3DWebVM

Tabelle 16: Einordnung der Phasenabdeckung des 3DWebVM

Tabelle 17: Einordnung der Gestaltungsdomäne des 3DWebVM

Tabelle 18: Einordnung der Branchenspezifität des 3DWebVM

Tabelle 19: Einordnung der Formalisierungsart des 3DWebVM

Tabelle 20: Einordnung des Formats des 3DWebVM

Tabelle 21: Zusammenfassung der Einordnung des 3DWebVM nach Höhn

Tabelle 22: Zusammenfassung der Anforderungen

Tabelle 23: Übersicht RemoteAdmin Commands

Zusammenfassung

Der Begriff „3D-Web“ steht derzeit bei den Medien hoch im Kurs, denn es wird davon ausgegangen, dass als nächste technologische Revolution echte 3D-Inhalte in Browser-basierten Anwendungen zum Standard werden. Somit wird auch der Bedarf an 3D-Web-Anwendungen steigen. Wie aber lassen sich diese systematisch erzeugen? Dazu wurde bei dieser Diplomarbeit ein Vorgehensmodell entwickelt: das 3DWebVM. Es zeigt auf, wie man vorgeht, wenn eine 3D-Web-Anwendung entwickelt werden soll. Zunächst wurden dazu die klassischen Phasen des Web Engineering und der Multimedia-Produktion betrachtet und daraus ein kombiniertes Phasenmodell entwickelt. Anschließend wurden konkrete Vorgehensmodelle aus Web Engineering und Multimedia-Produktion dahingehend überprüft, inwieweit sie die Phasen des 3DWebVM abdecken und somit als Referenz in diesen Phasen eingesetzt werden können. Dabei hat sich das Vorgehensmodell „Workflow der 3D-Visualisierung“ so gut integriert, dass es in zwei Phasen der Produktion übernommen wurde. Weiter wurden die Eigenschaften einer multimedialen 3D-Web-Anwendung definiert, damit sich Projektbeteiligte ein umfassendes Bild der Möglichkeiten solch einer Anwendung machen können. Zusätzlich wurde das 3DWebVM zu Integrationszwecken in Unternehmen als Prozess modelliert. Um das bis dahin entwickelte theoretische Vorgehensmodell besser einordnen zu können, wurde es nach einem Kriterienkatalog für Vorgehensmodelle eingestuft und erwies sich als ein Referenzmodell. Anschließend wurde das 3DWebVM an einem Umsetzungsbeispiel in der Praxis getestet. Dabei wurde der KnowCube der Hochschule Heilbronn in einer 3D-Welt auf dem 3D-Server OpenSim nachmodelliert und zusätzlich an einen Application-Server zur Administration angebunden. Die dabei gewonnenen praktischen Erfahrungen wurden abschließend in das 3DWebVM eingearbeitet.

Somit liefert diese Diplomarbeit zwei Varianten eines 3DWebVM: eine theoretische und eine praktisch ergänzte Variante. Beide haben ihre Vorteile: Das theoretische Modell berücksichtigt alle Aspekte der Entwicklung und kann daher als das allgemeine Modell betrachtet werden. Das praktische Modell ist deutlich reduzierter und auf das Wesentliche fokussiert. Auch konnten dessen Arbeitspakete optimiert werden. Das Phasenmodell beider Varianten ist jedoch gleich geblieben und hat sich somit in der Grundstruktur bewährt.

1. Einleitung

1.1. Motivation

Nachdem der Hype um das Thema Web 2.0 langsam am abklingen und praktischer Alltag geworden ist, tauchen selbstverständlich neue Trends in Forschung und Wissenschaft auf und übertragen sich auch auf die Wirtschaft. Neben dem Semantic Web steht der Begriff 3D-Web derzeit bei den Medien hoch im Kurs. "Das Hinzufügen der dritten Dimension ist der nächste Umbruch im Internet"^[1], so Ansgar Schmidt von der IBM. D. h. als nächste technologische Revolution sollen echte 3D-Inhalte in Browser-basierten Anwendungen zum Standard werden. Was als Hype beginnt, endet oft in einem plötzlichen Crash, so auch geschehen bei der 3D-Welt Second Life (kurz: SL). Zunächst stürzten sich Medien und Unternehmen auf SL, etwas später kam die große Ernüchterung und viele Unternehmen sprangen ab oder verschoben ihre 3D-Web-Projekte in die Forschungsabteilung. Was ein Hype jedoch deutlich macht, ist laut Gartners allgemeiner Hypekurve^[2] ein langfristiger Trend (siehe Abbildung 1). Visionären und vielen Entscheidern ist schon lange klar: Web-3D ist weiter im Kommen und wird sich auch weiterhin konsolidieren. So hat z. B. das japanische Unternehmen 3Di ein kostenpflichtiges Paket herausgebracht, welches einen 3Di OpenSim-Server und ein Browserplugin für den Internet Explorer enthält. Man kann somit eine eigene 3D-Welt erstellen, 3D-Objekte im 3ds-Studio Max-Format importieren und diese über den Internet-Explorer im Internet betrachten.^[3] Auch das aktuelle Projekt von Google „ O3D “ geht in eine ähnliche Richtung, indem versucht wird eine Open Source-Web-API zu entwickeln, welche es ermöglicht, multimediale 3D-Applikationen in den Browser zu integrieren.^[4] Somit ist es quasi sicher, dass das 3D-Web in den nächsten Jahren die breite Masse erreichen und in verschiedenen Formen auch Einzug in den Bereich des E-Business halten wird.

Aus diesem Grund hat sich der Verfasser schon während des Studiums an der Hochschule Heilbronn sowohl mit den verschiedenen Aspekten des Internet als auch mit virtuellen 3D-Welten auseinandergesetzt. Dies geschah vertieft vor allem im Rahmen mehrerer Seminararbeiten und Projektstudien während des Hauptstudiums. Nun wird es also Zeit das dabei erworbene Wissen zusammenzutragen und dieses auf die aktuellen Fragestellungen im Bereich 3D-Web zu fokussieren und anzuwenden. Es bietet sich an, dies im Rahmen dieser Diplomarbeit zu leisten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Gartner Hype Cycle

(Quelle: (Gartner Inc., 2009), WWW)

1.2. Herausforderung

Für die Entwicklung von Produkten in den Bereichen Software, Multimedia und 3D-Games existieren viele verschiedene Vorgehensmodelle. Will man jedoch in Zukunft als Unternehmen Software entwickeln (lassen), welche alle drei Eigenschaften Web, Multimedia und 3D abdeckt, existieren hierzu keinerlei integrierte Vorgehensmodelle.

1.3. Ziel der Diplomarbeit

Diesbezüglich sollen also Vorgehensmodelle aus den Bereichen des Web Engineering, der Multimedia-Produktion und der 3D-Entwicklung analysiert und mögliche Gemeinsamkeiten und Unterschiede aufgezeigt werden. Daraus soll ein neues 3D-Web-Vorgehensmodell (kurz: 3DWebVM) entwickelt werden, welches letztendlich aufzeigt, wie man vorgeht, wenn eine 3D-Web-Anwendung entwickelt werden soll.

Es sollen auch die technologischen Aspekte betrachtet werden, um Unternehmen zu zeigen, wie sich das neue Vorgehensmodell schon heute auf einfache Weise umsetzen lässt. Zu guter Letzt soll das erarbeitete Modell an einer Beispielanwendung getestet und abschließend bewertet werden.

1.4. Aufbau der Diplomarbeit

Kapitel zwei widmet sich zunächst dem aktuellen Stand des Wissens.

Flankiert durch einleitende Definitionen werden dabei in der ersten Hälfte Vorgehensmodelle des klassischen Software Engineering, des Web Engineering und Modelle zur Erstellung multimedialer sowie Architektur-orientierter Anwendungen betrachtet. Die zweite Hälfte soll beleuchten, welche Technologien momentan für die Entwicklung der 3D-Web-Anwendungen existieren und zwar hinsichtlich dreier Kernfragen:

- Welche 3D-Plattformen sind aktuell vorhanden?
- Welche Technologien zur Modellierung von 3D-Welten existieren?
- Wie lassen sich diese 3D-Welten in die Plattformen integrieren?

Kapitel drei umfasst die eigentliche Ausarbeitung und stellt somit den neuen Ansatz dar. Dabei werden die in Kapitel zwei beschriebenen Vorgehensmodelle zu einem konsistenten Gesamtmodell für die Entwicklung von 3D-Web-Anwendungen kombiniert und liefern folglich die Antwort auf die Frage nach der Vorgehensweise bei der Entwicklung von 3D-Web-Anwendungen.

Im vierten Kapitel folgt die Überprüfung der Tauglichkeit des neuen 3D-Web-Vorgehensmodells an einem praktischen Beispiel.

Das fünfte Kapitel stellt das Fazit dar. Hier wird das aus dem Praxisbeispiel gewonnene Wissen und die Erfahrung kritisch reflektiert und ein Blick in die Zukunft gewagt.

2. Stand des Wissens

Der Stand des Wissens ist in zweierlei Hinsicht zu beleuchten: Bezüglich den Vorgehensmodellen und der Technik. In Bezug auf Vorgehensmodelle, weil betrachtet werden soll, ob bereits bestehende Vorgehensmodelle verschiedener Anwendungsbereiche für die Entwicklung des neuen Vorgehensmodells herangezogen werden können, und bezüglich technischer Aspekte, um bei der späteren Anwendung auf mögliche technologische Lösungen zurückgreifen zu können, aber auch um dem Leser aufzuzeigen wie der Status Quo der Technik im Bereich 3D-Web aussieht. Da im Laufe des Textes immer wieder Begriffe auftauchen, die nicht jedem bekannt sein dürften, folgen zu Beginn einige Definitionen.

2.1. Definitionen

2.1.1. Augmented Reality (AR)

Diese „ angereicherte Realität “ ist eine moderne Variante der Mensch-Maschine-Interaktion. Damit bezeichnet man die Echtzeit-Überlagerung menschlicher Sinneswahrnehmungen mit Computermodellen. Ein AR-System kann visuelle, akustische und haptische Informationen in Echtzeit überlagern und wiedergeben. Es stellt eine Kombination von realer und virtueller Welt dar, ist interaktiv und echtzeitfähig sowie dreidimensional. Im Gegensatz zur virtuellen Realität, die nur die Realität nachbildet, integriert und überlagert die Augmented Reality virtuelle und reale Welt.^[5]

2.1.2. 3D-Objekt

Ein 3D-Objekt stellt alle visuellen Eigenschaften eines abstrakten Objektes dar. Dazu gehören die Geometriedaten wie Punkte und Polygone sowie die Materialdaten. Materialdaten sind Bildinformationen in Form von Texturen, die wiederum eine gespeicherte Information über die Beschaffenheit sind. Texturen können z. B. rauh, glänzend, farbig oder transparent sein.^[6]

2.1.3. 3D-Szene

Eine 3D-Szene ist die Beschreibung für einen Raum, in dem sich mehrere Objekte befinden. Charakterisierend für eine 3D-Szene sind Informationen zu Positionierung, Lichtquellen, Kameraeinstellungen oder über die Beschaffenheit von 3D-Objekten.^[7]

2.1.4. 3D-Web und Web-3D

Diese Begriffe sind sehr neu und werden zurzeit heiß diskutiert. Grundsätzlich lässt sich aber sagen, dass 3D-Web 3D-Content für Webbrowser bezeichnet,^[8] wohingegen Web-3D ein Netzwerk beschreiben kann, bei dem 3D-Virtuelle-Welten über Hyperlinks miteinander verbunden sind.^[9]

2.1.5. Virtuelle Welt

Eine virtuelle Welt ist ein Teilaspekt des immersiven Internets und beschreibt grundsätzlich die Nachbildung der realen Welt durch eine computergestützte Simulation.^[10]

2.1.6. Echtzeitvisualisierung

„Echtzeitvisualisierung bedeutet, dass der Zeitpunkt der Darstellung eines 3D-Objektes mit dem Zeitpunkt einer geometrischen Veränderung (oder der Veränderung des Betrachterstandortes) zusammenfällt. […] Echtzeitsysteme erlauben dem Betrachter direkt in das Geschehen einzugreifen. Alle Objekte sind in Echtzeit vom Betrachter individuell veränderbar.“^[11]

2.1.7. Immersives Internet

ThinkBalm^[12] definiert das immersive Internet so: “a collection of emerging technologies combined with a social culture that has roots in gaming and virtual worlds.” Dabei stehen neben der traditionellen Technologie der virtuellen Welten weitere Technologien wie virtuelle Hochschulen, 3D-Intranets, immersives Lernen, sog. Serious Gaming und 3D-Businessanwendungen. Allen Technologien gemeinsam ist, dass sie den Nutzer stark fesseln. Eine Kombination der Technologien sowie eine aufstrebende Kultur mit den Wurzeln im Gaming-Bereich eröffnen neue Perspektiven bezüglich Kollaboration, Engagement und Kontext. Serious Gaming meint dabei den Einsatz klassischer Game Engines wie z. B. die Quake Engine für ernsthafte Szenarien.^[13]

2.2. Vorgehensmodelle

2.2.1. Übersicht

Laut Höhn^[14] bietet der Markt eine Vielzahl von Vorgehensmodellen, Frameworks und Methodensammlungen. Beginnt ein neues Projekt, so stellt sich daher oft die Frage, ob das eingesetzte Vorgehensmodell auch für die neuen Fragestellungen geeignet ist. Doch was ist überhaupt ein Vorgehensmodell (kurz: VM)? Zunächst einmal soll ein VM helfen eine komplexe Handlungsfolge zur Herstellung eines komplexen Gegenstandes, z. B. einer Software oder eines Systems, zu ordnen und somit den Überblick über die Abfolge zu bewahren.^[15] Der Arbeitskreis für Vorgehensmodelle der Gesellschaft für Informatik hat eine Vielzahl von VM untersucht und festgestellt, dass ein VM sechs verschiedene Dimensionen aufweist, nach denen es eingeordnet werden kann:^[16]

- Ausbaustufe
- Phasenabdeckung
- Submodelle
- Gestaltungsdomäne
- Branchenspezifität
- Formalisierung

Als nächstes stellt sich die Frage, welche VM für die Betrachtung dieser Diplomarbeit interessant sind. Der Begriff „3D-Web“ liefert dafür die besten Hinweise: Web Engineering -VM werden sicher eine Rolle spielen, genauso wie VM aus dem Bereich Multimedia, welcher durch Rich Internet Applications (kurz: RIA) immer mehr Einzug ins Web hält. 3D-Anwendungen haben erfahrungsgemäß ihren Schwerpunkt in den Bereichen Gaming und Architektur, weshalb auch hieraus VM in Frage kommen.

2.2.2. Software Engineering und Web Engineering

In diesem Kapitel wird zunächst geklärt, was Software Engineering mit Web Engineering verbindet und daraus eine Definition für beide Disziplinen getroffen.

Anschließend werden die Phasen der Vorgehensmodelle kurz erläutert, was später bei der Entwicklung eines Web-3D-Modells helfen soll. Da die besonderen Anforderungen an Web Engineering aus den Charakteristiken von Web-Anwendungen abgeleitet werden,^[17] folgen anschließend die Charakteristika der Web-Anwendungen. Zum Schluß werden drei ausgewählte Vorgehensmodelle aus dem Web-Engineering vorgestellt:

- UML-basierte Methode
- Methode der agilen Websystem-Entwicklung
- Methode der modellgetriebenen Webentwicklung (kurz: MDWE)

2.2.2.1. Geschichtliche Entwicklung und Definition

Zu Beginn der kommerziellen Nutzung des Webs wurden die klassische Entwicklung von Anwendungen und die Entwicklung von Web-Anwendungen oft miteinander verglichen. Dabei wurden zum Teil große Unterschiede festgestellt, z. B. im Zeithorizont von der Initialisierung einer Softwareentwicklung bis zum ersten Einsatz der Software.^[18]

Doch E-Business-Anwendungen gewannen mit der Zeit stark an Bedeutung. Wurden sie Anfangs nur zur Präsentation des Unternehmens im Web genutzt, durchliefen sie eine Entwicklung bis hin zur Integration von operationalen Systemen und der Abwicklung von Geschäftsprozessen sowie der Integration in die bestehenden unternehmensinternen Anwendungen. Das ist der Grund dafür, warum die Realisierung von Web-Projekten in der heutigen Zeit mit den Spezifika des Software Engineering erfolgt. Auch Kappel et al.^[19] sind der Meinung, dass moderne Web-Anwendungen vollwertige, komplexe Softwaresysteme darstellen.

Wenn Web Engineering heutzutage Methoden des Software Engineering nutzt, bleibt zu klären, was Software Engineering ist. Dazu existieren verschiedene Definitionen,^[20] z. B. die des IEEE, von Barry Boehm etc. Die aktuellste Definition ist von Ian Sommerville. Er versteht unter Software Engineering folgendes: „An engineering discipline which is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use.“^[21] Versucht man alle Definitionen auf einen Nenner zu bringen, so stellt man fest, dass Software Engineering es ermöglicht komplexe Software zu entwickeln, indem passende Werkzeuge und Methoden eingesetzt werden. Es hilft somit Zeit und Geld zu sparen sowie die Qualität der Software und die Produktivität des Personals zu steigern. Diese Definition passt folglich zu Kappels Definition für Web Engineering, die besagt, dass Web Engineering die Anwendung systematischer und quantifizierbarer Ansätze ist, um Anforderungsbeschreibung, Entwurf, Implementierung, Test, Betrieb und Wartung qualitativ hochwertiger Web-Anwendungen kosteneffektiv durchführen zu können.^[22] Die Weiterentwicklung von Software Engineering zum Web Engineering sieht Gröschel^[23] durch Berücksichtigung folgender Aspekte gegeben:

- Verteiltheit: Für das Funktionieren des Gesamtsystems wird auf Funktionen und Daten zugegriffen, die über verschiedene Rechner verteilt sind, wodurch sich ein höheres Risiko einer eingeschränkten Funktionsfähigkeit ergibt.
- Performance: Durch die Verteilung des Gesamtsystems ist eine besondere Betrachtung der Performance inklusive der zugrunde liegenden Netzwerke notwendig.
- Grafikdesign: Dem grafischen Design muss eine stärkere Bedeutung zugewiesen werden, da viele Nutzer existieren, die das System nur sehr selten nutzen.
- Client-Heterogenität: Die potentielle Heterogenität der Clientsysteme (z. B. Mobilgeräte oder verschiedene Browser) muß berücksichtigt werden.

2.2.2.2. Phasen

Warum macht es Sinn einzelne Phasen des Web Engineering zu betrachten? Laut Dumke^[24] deswegen, weil es auf dem Gebiet der Vorgehensmodelle bei der Entwicklung von Websystemen so ist, dass man noch nicht von einem allseits anerkannten Standard sprechen kann. Deshalb sollte die phasenbezogene Web-Anwendungsentwicklung zunächst einmal methodenneutral betrachtet werden. Auch für Gröschel existieren für das klassische Software Engineering in Theorie und Praxis zahlreiche Vorgehensmodelle, die zum Teil auch unternehmensspezifisch angepasst werden. Den meisten der Vorgehensmodelle ist jedoch die Einteilung in verschiedene Phasen gemein. Klassisch werden die Phasen Initialisierung, Analyse, Design, Implementierung, Test und Wartung unterschieden.^[25] Daher folgt nun eine Betrachtung der Phasen des Web Engineering, wie sie Dumke^[26] und Gröschel^[27] beschreiben.

Problemdefinition

Bei der Problemdefinition geht es um die Beschreibung der Anforderungen an ein zu erstellendes Softwaresystem. Wichtig dabei ist, dass die Anforderungen überprüfbar sind. Dabei lassen sich funktionale, qualitative, system- und prozessbezogene Anforderungen unterscheiden.

Anforderungsanalyse

Weil die in der ersten Phase definierten Anforderungen meistens unvollständig sind und deshalb viele Softwareprojekte vorzeitig scheitern,^[28] müssen diese untersucht werden. Die Analyse betrifft die Eigenschaften von Anforderungen wie Eindeutigkeit, Vollständigkeit, Verifizierbarkeit, Konsistenz, Modifizierbarkeit und Handhabbarkeit. Die Anforderungsanalyse ist somit die Phase der Kontrolle von Anforderungen an ein zu entwickelndes Softwaresystem hinsichtlich Korrektheit, Vollständigkeit, Sachgerechtigkeit, Konsistenz und Machbarkeit und deren zweckmäßige Speicherung für die ständige Nutzung, Aktualisierung und Überprüfung im Verlauf der Entwicklung der Software. Die Anforderungsanalyse gestaltet sich schwierig, weil die Eigenschaften der Anforderungen sehr unterschiedlich sein können. Methoden der Anforderungsanalyse sind z. B. die fachspezifische Begriffskontrolle, die Konsistenzkontrolle, die Analogiemethode oder die Interview-Technik. Aber auch die einfache Beobachtung und das Brainstorming gehören zu diesen Methoden. Eine Priorisierung der Anforderungen bezüglich des Zeitmanagements ist sinnvoll und kann z. B. nach der Formel von Eisenhower^[29]

„Priorität = Dringlichkeit * Wichtigkeit“

durchgeführt werden. Es ist auch zu beachten, dass Anforderungen nicht nur zu Projektbeginn stehen, sondern im Sinne eines konsequenten Anforderungsmanagements den gesamten Prozess der Softwareentwicklung durchlaufen, da sie sich oft ändern und angepasst werden müssen.^[30]

Spezifikation

Die Spezifikation ist die Formulierung aller funktionalen Anforderungen in einem Modell, welches die computerbezogenen und organisatorischen Systemkomponenten beschreibt. Die Beschreibung der künftigen Funktionalität der zu entwickelnden Software stellt somit auch die spätere softwareseitige Realisierung sicher. Um ein Modell zu erstellen bedarf es einer Modellierung. Beim Web Engineering ist das die strukturelle, operationelle und informelle Umsetzung von Anforderungen in einer dem zu entwickelnden System angemessenen und für den Entwickler und Auftraggeber interpretierbaren Form, eben dem Modell. Hierzu können verschiedene Techniken der Modellierung herangezogen werden: Strukturelle Modellierungstechniken, die mit Vereinfachung, Abstraktion oder komprimierten Abbildungen arbeiten, wie z. B. das OOM mit der UML, operationelle Modellierungstechniken wie die Animation, Simulation oder das Prototyping, aber auch informelle Techniken wie Recherchen oder Interviews. Die dazugehörigen Modellarten stehen immer im Kontext ihrer Funktionalität wie z. B. das Funktionsmodell, das Datenmodell, das Zustandsmodell etc. Beispielsweise ist das am weitesten verbreitete Datenmodell das Entity Relationship Model. Bei der Spezifikation werden auch Aspekte der Komplexität berücksichtigt. Ziel ist dabei die Untersuchung der Machbarkeit und somit ihre Absicherung. Die Spezifikation wird auch dazu benötigt, um auf Grundlage des Lastenheftes ein Pflichtenheft für den Auftraggeber erstellen zu können und somit eine Verhandlungsbasis für Verträge zu schaffen.

Entwurf/ Design

In der Entwurfsphase geht es um die Umsetzung der systembezogenen, also hard - und softwarebezogenen Anforderungen. Dies sind zum einen Systemvorgaben, die sich auf die Problemstellung beziehen, zum anderen die Voraussetzungen des Systems. Das Hauptergebnis des Entwurfs ist die Architektur. Sie stellt beim Web Engineering die soft- und hardwarebezogene Struktur eines zu entwickelnden Systems dar. Dies umfasst die Komponenten der Struktur, externe Schnittstellen, sowie die Beziehungen zwischen den einzelnen Komponenten. Darstellungsarten für Architekturen sind z. B. in der UML Komponenten- oder Verteilungsdiagramme.^[31] Existieren in der Architektur kritische Elemente, so wird deren Funktionieren in einer Testimplementierung nachgewiesen, weil die Architektur schließlich darstellen soll, dass die systembezogenen Anforderungen erfüllt sind („ Proof of concept “).

Darstellungsmittel für Details der Komponenten sind z. B. Flussdiagramme, Struktogramme oder einfach ein Pseudocode.

Das Ergebnis dieser Phase ist schließlich der Systementwurf. Er beinhaltet alle problemspezifischen funktionalen Komponenten, die operationale Struktur des Systems, eine Datenkomponente die die Datenhaltung regelt, sowie die Benutzerschnittstelle. Weitere Ergebnisse des Entwurfs sind meist Testkonzepte, Dokumentationen, sowie erweiterte Konzepte bezüglich Abnahme, Einführung und Betrieb der Web-Anwendung.

Implementierung

Die Implementierung stellt die Umsetzung der Entwurfsergebnisse in ein programmiertes und auf spezieller Hardware abarbeitbares System dar. Einfach gesagt erfolgt hier die Kodierung des Entwurfes in einer konkreten Programmiersprache mit anschließendem Test. Dabei werden die Phasen Kodierung, Test, Integration und Installation durchlaufen.

Das Kodieren kann auf einfache Weise durch Editieren erfolgen. Moderne Modellierungsmethoden bieten auch die Möglichkeit den Code aus einem Modell heraus generieren zu lassen. Sie werden auch unter dem Begriff des Model Driven Engineering (kurz: MDE) oder Model Driven Software Engineering (kurz: MDSE) diskutiert^[32], womit sich auch das Kapitel 2.2.2.6 „Methode der modellgetriebenen Webentwicklung (MDWE)“ befasst. Weiter besteht die Möglichkeit, einen bereits vorhandenen Quellcode anzupassen oder ihn einfach zu übernehmen. Entscheidend dafür, welche Art der Kodierung eingesetzt wird ist das beabsichtigte Qualitätsniveau und der Testaufwand dessen die Anwendung bedarf.

Erprobung und Auslieferung

Nach der Implementierung erfolgt die Erprobung der Web-Anwendung, bei der der Nachweis der Validität erbracht wird, welcher auf Grundlage von zuvor definierten Akzeptanzkriterien fußt. Das Softwareprodukt wird dabei kontrolliert eingesetzt und es werden erste Anwendungserfahrungen gemacht. War die Erprobung erfolgreich, kann die Software ausgeliefert werden. Die Auslieferung bildet den Abschluß der Entwicklung. Es erfolgt eine Übergabe an den Auftraggeber.

2.2.2.3. Charakteristika von Web-Anwendungen

Web-Anwendungen weisen im Vergleich zu nicht Web-basierten traditionellen Anwendungen interessante Charakteristika auf. Bei den produktbezogenen Charakteristika handelt es sich um den Inhalt (Content), die Navigationsstruktur (Hypertext) sowie um die Benutzerschnittstelle (Browser). „Content is king!“, lautet die Devise bei Web-Anwendungen, wobei der Inhalt sehr unterschiedlich strukturiert ist. Auch die Qualitätsansprüche der User an den Inhalt schwanken gewaltig. Die Grundlage jeder Web-Anwendung sind Hypertext-Dokumente. Zum Hypertext-Paradigma, welche die Grundlage zur Aufbereitung von Informationen darstellt, existieren viele verschiedene Modelle, wobei das Web ein sehr einfaches Modell benutzt. Grundbestandteile solcher Modelle sind aber immer Knoten, Links und Anker. Dabei sind Knoten eindeutige identifizierbare Informationseinheiten, die über eine URL adressierbar sind. Links realisieren die Verweise zwischen den Knoten. Anker bilden Quell- und Zielbereiche von Links ab, wie z. B. ein Absatz oder ein Kapitel in einem Text. Besonderheiten der Präsentation in einem Browser beziehen sich hauptsächlich auf Aspekte der Ästhetik im Sinne eines „look and feel“, sowie der Selbsterklärbarkeit, d. h. die Web-Anwendung muss ohne eine explizite Dokumentation auskommen. Weitere Aspekte der Präsentation sind die Benutzerlogik, d. h. das Interaktionsverhalten muss einheitlich ausgelegt sein, und die Usability, die es dem User erlaubt rasch Routine bei der Bedienung aufbauen zu können.

Nutzerbezogene Charakteristika zeigen die starke Heterogenität von Web-Anwendungen auf, da sich die User durch Anzahl, Kultur und Endgeräte in Hard- und Software unterscheiden, aber auch der Ort und die Zeit der Nutzung nicht exakt vorhersehbar sind. Diese Kontextfaktoren sind schwer zu erfassen, weshalb der Einfluss auf sie nur begrenzt möglich ist.

Charakteristika bezüglich der Entwicklung von Web-Anwendungen sind gekennzeichnet durch Ressourcen wie den Mitarbeiter, die technische Infrastruktur, den Entwicklungsprozess sowie der Notwendigkeit, bereits existierende Lösungen in den Prozess einfließen zu lassen.

Alle drei Charakteristika Produkt, User und Entwicklung sind zudem dem Charakteristikum der Evolution unterworfen, da sich Rahmenbedingungen und Anforderungen schnell ändern können, sowie ein Konkurrenzdruck besteht.^[33]

Die folgende Abbildung 2 fasst die Charakteristika von Web-Anwendungen grafisch nochmals zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Eigenschaften von Web-Anwendungen

(Quelle: Eigene Darstellung in Anlehnung an (Kappel, et al., 2004), S. 10 ff.)

2.2.2.4. Die UML-Methode

Die Unified Modeling Language bildete sich im Wesentlichen aus der in der Praxis am meisten genutzten objektorientierten Methode, der Object Modeling Technique, aus den Darstellungsmitteln für moderne Telekommunikationssysteme und aus der bewährten objektorientierten Technologie nach Booch heraus^[34]. Die Grundlage der UML-Methode sind die für die Modellierung einzusetzenden UML-Diagramme. Somit ergibt sich ein diagrammbezogener Entwicklungsverlauf in den folgenden Etappen:

1. Objektorientierte Spezifikation: Diese umfasst die Modellierung der Anwendungsstruktur des Websystems mit dem Use-Case-Diagramm sowie die Darstellung des Prozessverhaltens mit Sequenz-, Aktivitäts- oder Zustandsdiagrammen. Dabei werden auch die für die Verarbeitung notwendigen Objekte dargestellt. Wie die Objekte miteinander operieren, kann in einem Kollaborationsdiagramm dargestellt werden.

2. Objektorientiertes Design: Der Entwurf der Systemarchitektur wird zunächst anhand eines Komponentendiagrammes vorgenommen. Die zweckmäßige Zusammenfassung der Objekte erfolgt in einem Klassendiagramm auf der Grundlage der anzuwendenden Klassenbibliothek einer speziellen objektorientierten Programmiersprache. Der Entwurf der Verteilung im Web wird mit Hilfe eines Verteilungsdiagrammes dargestellt.

3. Objektorientierte Implementierung: Die eigentliche Kodierung und der Test werden hierbei auf der Grundlage des Systementwurfs und der dabei zum Teil möglichen Codegenerierung in einer Programmierumgebung vorgenommen.

Es existieren darüber hinaus auch objektorientierte Methoden mit einem stärkeren Fokus auf das Web. Zu den etabliertesten zählen neben der Web Markup Language (kurz : Web ML) die Object-Oriented Hypermedia Method (kurz: OO-H), der Object-Oriented Web Solution Approach (kurz: OOWS) und das an der Münchener Universität entwickelte UML-based Web Engineering (kurz: UWE). UWE ist davon die neueste Entwicklung und stellt einen Ansatz zur modellgetriebenen Entwicklung von Web-Anwendungen dar. Es ist eine konservative Erweiterung von UML und besteht im Kern aus einer UML-Erweiterung, die eine intuitive Notation für die Modellierung von Web-Anwendungen bereitstellt. Daraus folgt eine konsequente Aufteilung in Teilmodelle, die separate Aspekte bei der Modellierung einer Web-Anwendung darstellen: Inhalt, Navigation, Prozesse und Präsentation. UWE deckt sowohl die Analyse- als auch die Entwurfsphase ab und definiert systematische Vorgehensweisen zum Aufbau und Ableitung der einzelnen Teilmodelle. „Konservative Erweiterung der UML“ soll heißen, dass neben hinzugefügten Elementen die bestehenden Elemente der UML weiterhin mit gleichbleibender Semantik verwendet werden können.^[35]

2.2.2.5. Methode der agilen Softwareentwicklung

Laut Cockburn hat das Wort Agilität bei der Entwicklung von Systemen im Geschäftsbereich nach Goldman (1997) folgende Bedeutung: „ Agilität ist dynamisch und kontextspezifisch, bringt inhärent starken Wandel mit sich und ist wachstumsorientiert. Agilität beschreibt weder, wie die Effizienz verbessert noch Kosten gesenkt werden, geschweige denn, wie man sich abschottet, um Konkurrenzstürme zu überstehen. Agilität beschreibt den Erfolg und den Gewinn: den Erfolg bei aufkommender Konkurrenz und den Gewinn in Bezug auf Profit, Marktanteil und Kunden im Zentrum der Konkurrenzstürme, vor denen sich viele Unternehmen heute fürchten.“^[36] D. h. der Kern agiler Entwicklung ist die Verwendung von einfachen aber erfolgreichen Regeln zum Verhalten während des Projektes sowie der Gebrauch von Regeln, die den Menschen und die Kommunikation in den Mittelpunkt stellen. Wie aber sehen die Charakteristika der agilen Softwareentwicklung (kurz: ASE) im Detail aus? Zunächst einmal ist eine frühe Implementierung der Softwareanwendung beim Kunden das höchste aller Ziele der ASE. Des Weiteren sind kurze Zeitintervalle bei der Softwareerstellung wichtig. Die ASE misst ihren Arbeitsfortschritt vor allem durch den Teil der Software, der bereits anwendbar ist und somit inkrementell eine gewisse Menge der Systemanforderungen bereits realisiert. Auch sind Anforderungsänderungen bis in den späten Verlauf der Softwareentwicklung vorgesehen. Der Auftraggeber und der Entwickler arbeiten eng zusammen („face-to-face“-Kommunikation) und können bei Bedarf den Ergebnisstand täglich auswerten. Darüber hinaus besteht die Kunst der Entwicklung vor allem in der Fähigkeit, die einzelnen Systemkomponenten und deren Integration so einfach wie möglich zu halten. Was die Teamarbeit betrifft, so ist schließlich eine Reflexion in bestimmten Zeitabständen durch das Team vorgesehen. Diese soll die Effizienz steigern.^{[37] [38]} Voraussetzung für ASE sind kleine Teams sowie die Gewährleistung der direkten Kommunikation untereinander was oft durch die Arbeit in einem gemeinsamen Raum erreicht wird. Der Entwicklungsprozess beginnt bei agilen Verfahren mit der allgemeinen Problemstellung. Die weiteren Systemaspekte werden dann jedoch durch kommunikative Tätigkeiten umgesetzt. Durch die ständige Anwesenheit des Auftraggebers können weitere geänderte Anforderungen sofort besprochen und umgesetzt werden. Die Entwickler teilen sich wechselseitig die Implementierung ausgewählter Anforderungen und den jeweiligen Test, so dass ein inkrementelles Systemwachstum erreicht wird. Voraussetzung dieser dokumentenlosen Entwicklungsform ist eine hohe Qualifikation der Entwickler selbst, die ausschließlich über eine Pinnwand den Projektfortschritt anzeigen.

Der Vorteil einer agilen Entwicklung von Webanwendungen ist der hohe Nutzereinfluss noch während der Entwicklung selbst. Ein Nachteil kann sich bei der Wartung der Anwendung aufzeigen, weil die Kenntnisse über das System stark personengebunden sind.^[39]

Eine spezielle Methode der ASE ist Extreme Programming (kurz: XP). XP ist wohl das bekannteste und zugleich unkonventionellste aller agilen Verfahren. Die Grundprinzipien von XP sind klar definiert: Man arbeitet mit direktem Feedback. Die Einfachheit ist das Leitziel und die Entwicklung findet in inkrementellen Zyklen statt. Außerdem sind Änderungen immer willkommen und die Arbeit muss ein hohes Maß an Qualität aufweisen. Aus diesen Grundprinzipien leiten sich 13 Praktiken ab, die vor allem den Projektzyklus, den Entwicklungszyklus sowie weitere unterstützende Praktiken beinhalten. Heute wird XP weltweit sehr erfolgreich angewendet, wozu der hohe Detaillierungsgrad der Praktiken beigetragen hat. Diese Praktiken zu befolgen bedeutet allerdings nicht unbedingt, dass man den Entwicklungsprozess agil umsetzt. Wichtiger als die Praktiken sind die fünf Grundprinzipien von XP. Sich nach ihnen zu richten macht den Kernpunkt agiler Entwicklung aus. Die Praktiken zeigen nur einen möglichen Weg dorthin.^[40]

2.2.2.6. Methode der modellgetriebenen Webentwicklung (MDWE)

Wie in der Einführung zum Web Engineering erläutert wurde, hat die rasante Entwicklung des WWW und der dazugehörigen Technologien stattgefunden, was folglich zur Anhebung der Komplexität und Dynamik von Web-Anwendungen geführt hat. Um diesen Aspekten auch bei der Entwicklung gerecht zu werden, wurden Methoden des Software Engineering integriert und zu Web Engineering weiterentwickelt. Dies brachte den Einsatz von Modellen wie z. B. die der UML mit sich. Aus der Idee der konsequenten Verwendung von Modellen ist schließlich der Ansatz der modellgetriebenen Softwareentwicklung oder Model Driven Software Engineering (kurz: MDSE) entstanden. Der Hauptgedanke dabei ist, Modelle der Anwendung als Basis für den gesamten Entwicklungszyklus zu verwenden. Aus ihnen kann dann automatisch der Quellcode der Anwendung generiert werden. Der Vorteil: Modell und Code sind synchronisiert. Außerdem findet die Entwicklung der Software auf einer höheren Abstraktionsebene statt, was ihr schließlich die Unabhängigkeit von einer bestimmten Technologie beschert. Diese MDSE hat auch Einzug in die Domäne des Web Engineering gehalten und wird dort als Model Driven Web Engineering (kurz: MDWE) bezeichnet.^[41] Die modellgetriebene Entwicklung von Web-Anwendungen ist z. B. mit UWE möglich. Hierzu haben die Münchener Forscher Kraus et al.^[42] ein Vorgehensmodell entwickelt, welches auf eine ATL-realisierte Transformationskette aufsetzt und den kompletten Entwicklungsprozess vom Analysemodell bis hin zum generierten Quelltext möglich macht. Bei der ATL handelt es sich um die ATLAS Transformation Language, die eingesetzt wird um Modell-zu-Modell-Transformationen durchführen zu können.

2.2.3. Multimedia-Produktion (kurz: MP)

Dieses Kapitel definiert zu Beginn den Begriff Multimedia um ein gemeinsames Verständnis zu begründen, woraus sich nachfolgend die Eigenschaften für multimediale Anwendungen ableiten lassen. Auch bei den multimedialen Vorgehensmodellen sollen, wie auch beim Web Engineering, die grundlegenden Phasen der Entwicklung aufgezeigt werden, was bei der Entwicklung des neuen Modells helfen soll. Anschließend werden zwei konkrete Vorgehensmodelle vorgestellt: die Multimedia-Anwendungsentwicklung nach Sawhney sowie der Workflow in der 3D-Visualisierung nach Höhl.

2.2.3.1. Definition und Charakteristika von Multimedia

Betrachtet man den Begriff Multimedia ganz banal, so stellt man fest, dass es sich um den Einsatz einer Vielzahl einfacher Medien handeln muß. Der Begriff der Medien wird im Kontext dieser Diplomarbeit nicht weiter diskutiert. Die Definition von Krömker und Klimsa^[43] sollte hierzu ausreichen. Sie zählen zu den Medienformen Film, Fernsehen, Hörfunk, Musik, Print, Internet und die Mobilkommunikation. Was aber sind dann die besonderen Eigenschaften von Multimedia? In einfacher Form definiert der ausgewiesene Experte für Markenkommunikation Alan Ross^[44] den Begriff Multimedia als den Überbegriff für das Zusammenfließen von verschiedenen Inhaltsformen und Werken wie Text, Grafik, Audio und Video in digitaler Form in einem interaktiven Kontext. Etwas detaillierter ist die Ausführung des Medienwissenschaftlers Weidenmann^[45]. Er ist der Meinung, dass sich der Begriff Multimedia insbesondere durch digitale Inhalte auszeichnet. Außerdem spielt das Vorhandensein unterschiedlicher Interaktionsmöglichkeiten eine wichtige Rolle, z. B. eine aktive Navigation, die Manipulation von Inhalten oder die Steuerung von Wiedergabeparametern. Neben der Interaktivität existieren zwei weitere Eigenschaften, die Medien erfüllen müssen, damit man sie als multimedial bezeichnen kann: Zum einen müssen mehrere Kodierungsformen verwendet werden (Multikodalität). Texte verwenden z. B. eine symbolische Kodierungsform (verbal). Ein Bild benutzt hingegen eine abbildhafte bzw. imaginäre (realgetreu oder schematisch/ typisierend) Kodierungsform. Zum anderen müssen verschiedene Sinnesmodalitäten eingesetzt werden (Multimodalität). Darunter versteht man die angesprochenen Sinne des Menschen. Die häufigsten Sinne sind der auditive und der visuelle Sinn. Ein Text auf dem Computermonitor ist somit monokodal (verbal) und monomodal (visuell). Wird dieser jedoch durch Originalsounds (auditiv und abbildhaft/ realgetreu) untermalt, sind die Eigenschaften Multimodalität (visuell und auditiv) und Multikodalität (abbildhaft/ realgetreu und symbolisch/ verbal) erfüllt. Issing und Klimsa^[46] sehen die Thematik noch differenzierter. Für sie spielt neben dem Medienaspekt der Multimedialität durch Text, Grafik, Video und Ton und dem Integrationsaspekt durch Interaktivität, Multitasking und Parallelität auch der Anwendungsaspekt eine wichtige Rolle. Dabei werden einfach einzelne Anwendungskategorien für Multimedia-Anwendungen definiert, nämlich Datenbank-, Kommunikations-, Hypermedia- und Autorensysteme sowie Systeme der virtuellen Realität. Eine Übersicht hierzu liefert Abbildung 3. Diese erweiterte Definition von Issing und Klimsa soll bei dieser Diplomarbeit als Grundlage für weitere Betrachtungen herangezogen werden, weil auch der Anwendungsaspekt hinsichtlich Systemen der virtuellen Realität im Fokus des neuen Vorgehensmodells stehen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Multimedia als ein Konzept, das technische und anwendungsbezogene Dimensionen integriert

(Quelle: (Issing, et al., 2002) S. 6)

Aus allen zuvor betrachteten Definitionen für Multimedia lassen sich die Charakteristika für multimediale Anwendungen (kurz: MA) ableiten. Die nachfolgende Abbildung 4 fasst diese grafisch zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Eigenschaften von multimedialen Anwendungen

(Quelle: Eigene Darstellung)

2.2.3.2. Die zusammengefassten Phasen der Multimedia-Produktion

Im Bereich der Medien- und Multimedia-Produktion gibt es eine große Anzahl bekannter Vorgehensmodelle. Klassische Betrachtungsweisen wie z. B. die von (Krömker, et al., 2005) betrachten die wissenschaftlichen Disziplinen und Modelle, die der Medienproduktion zugrunde liegen und versuchen auf diese Weise das heterogene Feld der Medienproduktion zu beleuchten. Dies geschieht auch durch Aufteilung nach Branchen weil diese historisch gesehen mit den technischen Bedingungen entstanden sind. Andere Betrachtungsweisen haben wiederum das Medienmanagement im Fokus und bringen dieses mit betriebswirtschaftlichen Aspekten in Verbindung, so bei (Gläser, 2008) der die Methodik, das Umfeld und die Unternehmensführung und Steuerung von Medienunternehmungen thematisiert. Wieder andere gehen von der technischen Seite heran und zeigen auf, wie neue Technologien multimediale Anwendungen und die zugrunde liegenden Geschäftsmodelle und Geschäftsprozesse beeinflussen, so bei (Herzog, 2009). Leider fehlt allen genannten Betrachtungsweisen eine eindeutige Positionierung der multimedialen Thematik, was dem Umstand geschuldet ist, dass Multimedia technologisch gesehen sehr große Entwicklungssprünge in relativ kurzer Zeit gemacht hat und deshalb nur in der Anfangszeit der Multimedia-Anwendungsentwicklung allgemeine multimediale Prozesse veranschaulicht wurden. Diese haben aber trotzdem auch heute noch ihre Gültigkeit. Sie werden aktuell eben differenzierter und branchenfokussierter betrachtet.^[47] Trotz allem sprechen die genannten Betrachtungsweisen grundsätzlich von denselben Phasen des Entwicklungsprozesses, welche auch Srinivasan^[48] allgemein beschrieben hat. Nach seiner Beschreibung und in Kombination mit den vorgestellten Betrachtungsweisen folgt nun die Beschreibung der Phasen zur Produktion von Multimediasystemen:

1. Die Vorphase: An dieser Stelle findet das Briefing statt. Hier erhalten Agenturen Informationen zu den erforderlichen Sachverhalten um einen Auftrag durchführen zu können. Die Aufgabenstellung wird definiert sowie Ziele und Marktgegebenheiten erläutert. Wichtig ist dabei, dass das Briefing nicht schon die konkrete Lösung der Aufgabe vorwegnimmt, sondern einen gewissen Spielraum zur Ausgestaltung, ähnlich einem Lastenheft, lässt.

2. Das Rohkonzept: Es besteht aus mehreren Etappen wie Festlegung der Inhalte, Bestimmung der Visualisierungsformen, Definieren der Programmierungs- bzw. Implementationsdetails, Konzipieren der technischen Storyline, Koordination der benötigten Ressourcen, Beachtung der Copyrightrechte und schließlich das sogenannte Sign-Off, bei dem eine Art Abschlussdokumentation erfolgt.

3. Die Preproduktion: Hier erfolgt die Recherche, Planung und Erzeugung der benötigten Inhalte durch Managementsysteme. Dabei wird ein Interface festgelegt, ein Konzept der Interaktivität entwickelt, das Storyboard definiert und ein Prototyp implementiert, den man hinsichtlich der Marktanforderung nach und nach verfeinert.

4. Die Produktion: An dieser Stelle werden die Inhalte weiter angepasst. Es erfolgt die tatsächliche Erzeugung der Grafiken, der Stilbilder, der Musik, der Audio-Files, der Animationen und der Video-Files sowie die Auswahl und ggf. die Durchführung der erforderlichen Konvertierungen. Bei Filmen z. B. erfolgen Dreharbeiten, bei Musik die tatsächliche Aufnahme der Instrumentalisierung, für das Internet erfolgt eine Erstellung der Anwendung aus dem Storyboard heraus.

5. Die Postproduktion: Hier wird der erstellte multimediale Inhalt nochmals verfeinert, nachbearbeitet und getestet. Dabei dient die Assamblage als Test bzw. Debugging der finalen Zusammenstellung, das Mastering als Archivierung der entsprechenden Konfigurationen sowie die Replikation als abschließende System- oder Komponentenüberprüfung.

6. Die Distribution: Dabei wird der erstellte Inhalt den Zielgruppen zur Verfügung gestellt. Formen der Distribution bei multimedialen Anwendungen können eine digitale Bereitstellung, die tatsächliche Ausstrahlung, ein Vertriebssystem oder ein Providersystem sein.

2.2.3.3. Multimedia-Anwendungsentwicklung nach Sawhney

Bei diesem Modell handelt es sich um eine Kombination aus klassischem Software Engineering erweitert um Aspekte für die Entwicklung von Multimedia-Systemen. Für die Entwicklung des neuen Vorgehensmodells ist das Modell nach Sawhney gut geeignet, da es sich in Richtung hypermediale Software-Systeme orientiert. Ein Nachteil ist jedoch, dass der hohe Grad der Interaktivität von diesem Vorgehensmodell nicht berücksichtigt wird.^[49] Es stehen die Gestaltungsaspekte des zu entwickelnden Multimedia-Systems und nicht die zu implementierenden Funktionalitäten im Vordergrund. Wie Abbildung 5 zeigt, ist dieses Modell stark prozessorientiert und dabei angelehnt an klassische Modelle des SE wie das Wasserfallmodell.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Modell der multimedialen Anwendungsentwicklung nach Sawhney

(Quelle: (Scherp, 2001), S. 25)

Die Entwicklung des Multimedia-Systems geschieht parallel zum SE-Prozess und wird Top-Down durchgeführt, das heißt es werden Entscheidungen auf höherer Ebene getroffen und dann schrittweise verfeinert (siehe Abbildung 6). Nach der Analysephase vollzieht sich die Entwicklung des Multimedia-Systems bis zum Beginn der Programmrealisation in einem evolutionären Prozess. Kostenbedingt sind nach der Fertigstellung und Validierung des Drehbuchs oder Storyboards keine Phasenwiederholungen möglich. Daher findet im Vorgehensmodell ab der Programmrealisation und Medienproduktion eine strenge Phaseneinhaltung statt. Die Medienherstellung beginnt bereits in der Analysephase mit der Medienanalyse, wird in der Konzeptphase mit der Grob- und Feinplanung des Inhalts fortgesetzt und endet in der Medienproduktionsphase mit der Herstellung und Nachbearbeitung der Medien.^[50]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Ablauf der Medienherstellung nach Sawhney

(Quelle: (Scherp, 2001), S. 25)

2.2.3.4. Workflow in der 3D-Visualisierung nach Höhl

Wolfgang Höhl^[51] befasst sich vorrangig mit der 3D-Visualisierung im Bereich der Architektur und des Gaming. Der nachfolgend beschriebene Workflow zur 3D-Visualisierung bezieht sich auf architektonische Visualisierungsformen. 3D-Modelle haben dabei zwei wesentliche Anwendungsbereiche: zum einen als 3D-Visualisierung, die als Schaubild in die Entwurfspläne integriert wird, zum anderen als Präsentationsmodell im Modellbau. Wie entsteht aber 3D-Visualisierung und in welche Präsentationstechniken können sie eingebunden werden? Üblicherweise werden in der Architektur fünf Präsentationstechniken verwendet: 3D-Modelle, Printmedien, Filme, DVD und Webdesign. Abbildung 7 zeigt den üblichen Workflow in der Entwurfs- und Genehmigungsplanung. Dabei erweitert Höhl die Präsentationstechniken um zwei neue interaktive Darstellungsformen: Game Design und Augmented Reality. Jede der dargestellten Präsentationstechniken hat ein konkretes Endprodukt. Der Erstellungsprozess kann in acht Arbeitsschritte bzw. Arbeitsphasen gegliedert werden:

- Installieren und Kompilieren der Programme
- Desktop Publishing (Bildbearbeitung und Texturen erstellen)
- 3D-Modelling (3D-Modelle erstellen)
- Texturing (Oberflächengestaltung und Texturierung)
- Lightning (Beleuchtung, Lichter und Kameras setzen)
- Animation (Bewegungsabläufe definieren)
- Rendering (Renderverfahren auswählen und einstellen)
- Compositing ( Layout, Level Design, Mischen, Schnitt und Mastering)

Jedes Endprodukt hat ein spezielles Dateiformat. Abhängig davon werden in jeder Phase des Arbeitsprozesses unterschiedliche andere Dateiformate zum Datenaustausch benötigt. Diese Dateiformate werden in der Abbildung 7 in den Spalten „Input/Output“ dargestellt. Sinnvolle Schnittstellen gibt es immer nach den einzelnen Arbeitsphasen, d. h. man kann z. B. entweder in einem Programm modellieren, texturieren, animieren und rendern oder man modelliert in einem Tool und wechselt zum texturieren usw. in ein anderes Tool.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Workflow der 3D-Visualisierung nach Höhl

(Quelle: (Höhl, 2009), S. 33)

2.3. Technik

2.3.1. Übersicht und Analyse von 3D-Plattformen

2.3.1.1. Grundlagen

Es gibt leider keine eindeutige Definition einer 3D-Welt oder einer 3D-Plattform. Ein Blick in die Geschichte zeigt jedoch, dass die Anfänge solcher Plattformen die sogenannten Massively Multiplayer Online Role-Playing Games (kurz: MMORPG) waren. Ihre drei Hauptmerkmale waren damals eine 3D-Grafik, eine persistente Welt zu der die Spieler immer Zugang hatten sowie die Interaktion zwischen den einzelnen Spielern mit einem Spielziel.^[52] Das Prinzip hat sich bis heute nicht sehr verändert. Nach Auffassung von Meinke^[53] sind die vier grundlegenden technischen Komponenten eines MMORPG Server-Core, Library, Objekte und Client. Diese Diplomarbeit definiert daher für sich den Begriff der 3D-Plattform als die Infrastruktur einer modernen Form des MMORPG basierend auf den oben aufgeführten vier Komponenten. Wichtig ist auch zu erwähnen, dass moderne 3D-Plattformen wie Second Life oder dessen Open Source Variante OpenSim kein Spielziel aufweisen.

2.3.1.2. Übersicht über 3D-Plattformen

Nachfolgend sollen verschiedene 3D-Plattformen vorgestellt werden. Aus dem proprietären Bereich werden zwei Plattformen skizziert: Die größte ist Second Life und die neueste heisst Twinity. Aus dem Open Source Bereich werden der Server OpenSimulator und die Sun Plattform Project Wonderland vorgestellt.

2.3.1.2.1 Der Gigant: Second Life

Laut eigenen Angaben ist Second Life (kurz: SL) eine virtuelle Welt und somit eine dauerhaft bestehende 3D-Umgebung, die vollständig von ihren Bewohnern erschaffen und weiterentwickelt wird. In dieser riesigen Onlinewelt kann der Benutzer praktisch alles kreieren oder auch selbst werden, was sein Vorstellungsvermögen zulässt. SL beinhaltet integrierte Tools um Inhalte erstellen zu können. Somit sind der Kreativität der Benutzer keine Grenzen gesetzt. Die Objekte lassen sich in SL in Echtzeit und in Zusammenarbeit mit anderen erstellen. Der digitale Stellvertreter, genannt "Avatar", lässt sich individuell einstellen und macht es somit möglich seine Persönlichkeit auf unterschiedlichste Weise auszudrücken. Die realitätsnahe Simulation der Umgebungsphysik in SL wird auf einem Backbone aus Hunderten miteinander verbundenen Computern ausgeführt und wächst mit seiner Bevölkerung mit. Der Benutzer kann 3D-Inhalte entwerfen und verkaufen, Land erwerben und bebauen, virtuelles Geld verdienen, welches sich auch in reales Geld umtauschen lässt.^[54] SL ging im Sommer 2003 online und hat bis heute etwa 10 Millionen kostenlose Accounts und rund 100.000 aktive Teilnehmer akquiriert, die an einer Art virtuellem Wirtschaftsleben partizipieren. SL ist die bekannteste und beliebteste virtuelle 3D-Plattform. Umsatz generiert SL über die Vermietung von virtuellem Land und den Premium Accounts. Diese sind notwendig um in SL Land kaufen und bebauen zu können. Der Account kostet ca. fünf Euro monatlich. Im Sommer 2008 hat es Linden Research Inc. in Kooperation mit IBM zum ersten Mal geschafft einen Avatar von Second Life in eine andere virtuelle Welt zu teleportieren. Dabei wurde der Avatar auf einen OpenSim Server teleportiert.^[55] Das dabei verfolgte Ziel ist klar: Plattform-Wechsel mit ein und demselben Avatar! Dies ist im Moment die Vision auf die unter dem Schlagwort Web-3D hingearbeitet wird. Die Zukunft sieht also so aus, dass ein Benutzer nur noch einmalig einen Avatar erstellt und mit diesem dann in allen existierenden virtuellen Welten auftreten kann. Ein weiteres Feature von SL ist das virtual conferencing, von dem immer mehr Organisationen Gebrauch machen. Beispielsweise veranstaltete IBMs Academy of Technology im Herbst 2008 eine Virtual World Conference und anschließend eine Jahresversammlung. Beide fanden in einer sicheren SL-Umgebung statt. IBM schätzt, dass der ROI für diese Konferenz bei rund 320.000 US$ lag und die Jahresversammlung für nur ein Fünftel der in der realen Welt anfallenden Kosten ausgeführt wurde. Somit ist klar dass die IBM diese Möglichkeit auch weiterhin nutzen wird.^[56]

2.3.1.2.2 Der Neuling: Twinity

Selbst definiert sich Twinity als „[…] eine 3D-Onlinewelt, die eng mit der Realität verknüpft ist.“^[57] Betreiber der Plattform ist das Unternehmen Metaversum aus Berlin. Twinity ist der Neuling auf dem proprietären 3D-Plattform-Markt und existiert erst seit September 2008. Die Besonderheit an Twinity ist, dass es sich so nah wie möglich an der Realität orientiert. So werden auch nur real existierende Mega-Cities aufgebaut, wie z.B. Berlin, Singapur oder London. Die Avatare haben, bis auf die Möglichkeit sich zu teleportieren, dieselben Eigenschaften der Menschen aus der realen Welt: Sie können nicht fliegen und das Aussehen ist auf ein menschliches Aussehen beschränkt. Derzeit befindet sich Twinity in der Beta-Phase und hat von sich aus die Teilnehmer begrenzt. Ziel ist ein kontinuierliches Wachstum mit einer parallel laufenden und stetigen Weiterentwicklung der Plattform. Die Plattform wird schrittweise für den Markt geöffnet. Die virtuelle Stadt Berlin ist bereits für Benutzer zugänglich, an der Entwicklung von London und Singapur wird derzeit gearbeitet. In Twinity besteht die Möglichkeit Geschäftsräume zu mieten und dort die eigenen Waren zu verkaufen. Eigene Gebäude dürfen nicht erstellt werden um das Stadtbild zu wahren. Mittlerweile ist es aber möglich in Twinity Objekte im 3D-Format Collada zu importieren. Benutzer können sich in Twinity ein Zuhause kaufen, dieses mit verschiedenen Möbeln und Gegenständen einrichten und außerdem über Voice- und Text Chat mit anderen Benutzern kommunizieren. Momentan ist der Account noch kostenlos. Es bleibt abzuwarten, ob sich das ändert. Wahrscheinlich wird nach Abschluss der Beta-Phase ein Premium-Zugang zur 3D-Plattform kostenpflichtig werden.

2.3.1.2.3 Der Hoffnungsträger: OpenSim

Das OpenSim-Projekt entstand 2007 und wurde von Darren Guard initiiert. Ziel war es eine virtuelle 3D-Umgebung zu schaffen, die für unterschiedliche Anwendungsbereiche nutzbar ist.^[58] Guard erkannte nämlich das Problem, dass viele Versuche virtuelle Welten zu entwickeln hauptsächlich daran scheiterten, dass man gleichzeitig Server und Client entwickeln musste. Sein Glück war, dass im Januar 2007 der Second Life-Client Second Life-Viewer als Open Source veröffentlicht wurde und somit die damit verbundene Programmbibliothek libSecondlife in einer stabilen Version vorlag. So wurde die Idee zu OpenSim geboren. Ursprüngliches Ziel war es ein Konzept für einen Server zu entwickeln, auf den man sich mit einem Second Life-Viewer verbinden konnte und der die grundsätzlichen Funktionen dieses einen Clients unterstützen sollte. Mittlerweile hat sich das Ziel jedoch ausgeweitet: Man versucht nun einen Standard für Plattformen virtueller Welten im Allgemeinen zu entwickeln, der von jeder Anwendung eingebunden werden kann und somit eine größere Interoperabilität ermöglicht. So lassen sich unbegrenzt 3D-Welten erstellen, Avatare erschaffen, Landschaften formen und Skripte, Texturen, Sounds und Animationen hochladen und gestalten. Zur internen Kommunikation lässt sich ein klassischer Chat einsetzen. Man kann sich weiter mit anderen OpenSim-Servern verbinden um gemeinsam eine umfangreiche virtuelle 3D-Landschaft zu generieren. OpenSim ist somit nach Expertenmeinung die grundlegende technologische Basis für die Entwicklung eines erweiterten, zukünftigen 3D-Internet. Es ermöglicht den Betrieb und die Nutzung einer eigenen, kostenlosen 3D-Echtzeit-Simulation auf dem eigenen PC mit der zusätzlichen Option diesen entweder alleine im Standalone-Modus zu betreiben oder ihn an andere OpenSims anzuschließen. Der Anschluss kann entweder im HyperGrid-Modus oder im klassischen Grid-Modus erfolgen. Eine unabhängige Welt im Standalone-Modus ist z B. für Unternehmen interessant, die die neuen Möglichkeiten virtueller Welten für sich nutzbar machen möchten, dies aber vor dem Hintergrund der Datensicherheit bisher gescheut haben.

Man kann bei OpenSim anderen Nutzern Zugang zu einem Sim gewähren. Sie können sich dann in GridMode mit ihrem Avatar beliebig von Sim zu Sim bewegen oder teleportieren. Mit Sicherheit ist es ein sehr großer Vorteil von OpenSim, dass es auf der Technologie von Second Life basiert. Somit lassen sich z. B. einzelne Objekte zwischen OpenSim und Second Life durch Export-Import-Funktionen austauschen. Als Client kann zum einen der Second Life-Viewer verwendet werden, zum anderen existiert mittlerweile etwa ein Dutzend Open Source-verfügbarer OpenSim-Clients. Die bekanntesten davon sind aktuell der Hippo-Viewer und der realXtend-Viewer. OpenSimulator ist in C# programmiert und befindet sich noch in der Alpha-Phase in der aktuellen Version 0.65. Es wird täglich von einer sehr fleißigen Gemeinde weiterentwickelt, siehe z. B. (opensim, 2009). Die Architektur von OpenSim ist bewusst am Linden Lab Network ausgerichtet. Deshalb gibt es fünf Services welche jeder Region, die mit dem Viewer kommunizieren will, zur Verfügung gestellt werden. Diese fünf Services sind: User, Grid, Asset, Inventory und Messaging. Deshalb heisst die OpenSim-Architektur offiziell UGAIM -Architektur.

Eine detaillierte Betrachtung verdient an dieser Stelle noch der HyperGrid-Modus. Dieser Modus ist eine Erweiterung, die es erlaubt, den eigenen OpenSim mit anderen OpenSims bei nahtlosem Datentransfer über das Internet zu verbinden. Er kann sowohl im Standalone-Modus als auch im Grid-Modus verwendet werden. Somit fördert dieser Modus eine effektive Vernetzung virtueller Welten. Die Grundidee des HyperGrid besteht darin, dass der Administrator einer OpenSim-Region oder eines OpenSim-Grids Hyperlinks auf seine Landkarten setzen kann, die auf hypergride Regionen anderer Betreiber verweisen. Sobald diese Hyperlinks bestehen, können Benutzer auf die neuen Regionen auf genau die gleiche Art einwirken wie auf die eigene Region bzw. den eigenen Grid. Um genau zu sein, können Benutzer sich in die neue Region teleportieren lassen. Sobald die Benutzer die Region hinter dem Hyperlink erreicht haben, interagieren sie automatisch mit der neuen Welt ohne sich darin neu einloggen zu müssen und haben darüber hinaus immer noch Zugriff auf das gesamte eigene Inventar.^[59]

Viele Unternehmen haben sich mittlerweile der OpenSim-Thematik angenommen und entwickeln unterschiedliche Features und Dienste. Das im Zusammenhang mit der Fragestellung der Diplomarbeit interessanteste Projekt stellt dabei realXtend dar.

Es stellt eine Open Source-Plattform für die Entwicklung von eigenen 3D-Welten mit OpenSimulator als Basis zur Verfügung. RealXtend stellt dabei den realXtend-Viewer und den realXtend-Server zur Verfügung. Der Server setzt auf OpenSim als Basistechnologie auf, hat aber den Vorteil, dass er schon eine gut ausgestattete 3D-Welt installiert hat, die man nach seinen Ansprüchen modifizieren kann. Darüber hinaus werden mit der Installation eine umfangreiche Datenbank an 3D-Objekten mitgeliefert um sofort mit dem Umbau der virtuellen Welt beginnen zu können. Weitere Features sind Weiterentwicklungen in verschiedenen Bereichen. RealXtend unterstützt z. B. den Import des Ogre-Formats, ein Avatar-Generator ermöglicht den Import und die Modifikation der Avatare uvm. Das Ziel dieser Plattform ist die Entwicklung standardisierter, webbasierter virtueller 3D-Welten zu beschleunigen. Dies wird erreicht indem die beste Technologie für jedermann kostenlos verfügbar gemacht wird. Denn nach Auffassung der Betreiber liegt der wahre Wert miteinander verbundener 3D-Welten in deren Anwendungen und nicht in der Plattformtechnologie selbst.^[60]

2.3.1.2.4 Aus der Java-Welt: Project Wonderland

Das Java-basierte Toolkit „Project Wonderland“ oder „ Wonderland “ ist Open Source. Im Jahre 2007 zu reinen Demonstrationszwecken entwickelt, liegt es aktuell in der Version 0.5 vor. Wonderland ist für die Erstellung von kooperationsorientierten virtuellen 3D-Welten entwickelt worden. Innerhalb dieser 3D-Welten können Benutzer mit hoher immersiver Klangwiedergabequalität kommunizieren, Desktop-Anwendungen und Dokumente live miteinander teilen und echte Geschäftstransaktionen abwickeln. Wonderland ist außerdem erweiterbar. Entwickler können neue Funktionalitäten hinzufügen um sowohl komplett neue Welten als auch neue Features in vorhandenen Welten zu kreieren.^[61] Mit Wonderland soll eine Umgebung bereitgestellt werden, die in Sachen Sicherheit, Skalierbarkeit, Zuverlässigkeit und Funktionalität alles abdeckt. Unternehmen können Wonderland für den Aufbau einer virtuellen Präsenz nutzen um mit Kunden, Partnern und Mitarbeitern besser kommunizieren zu können. User sollen darüber hinaus in der Lage sein ihre tägliche Arbeit in virtuellen Welten erledigen zu können. Sie sollen auch in der Lage sein Teile der virtuellen Welt selbst zusammen zu fügen um somit ihre eigenen Arbeitsgewohnheiten und Bedürfnisse abzubilden. Mögliche Kollaborations-Szenarien sind z. B. Audio-orientierte-Kommunikationsformen, Live-Desktop-Anwendungen aller Art und kollaborative Kreationen mit grafischem und prozeduralem Inhalt. Ein wichtiges Ziel der Entwickler von Wonderland ist die strikte Erweiterbarkeit der Umgebung. Auch neue Verhaltensweisen von Avataren oder anderen Objekten der virtuellen Welt sind bei Wonderland durch initiative Entwicklungen realisierbar. Langfristiges Ziel ist die Unterstützung einer Entwicklung der Dinge in der virtuellen Welt selbst. Trotzdem wurde darauf geachtet, dass Objekte und andere Daten in Wonderland importiert werden können: Sowohl Open Source als auch proprietäre Modeling- und Animations-Formate werden unterstützt.^[62] Der Client hat einen browsertypischen Aufbau. Der Server ist ein Set unabhängiger Anwendungen und arbeitet Web-basiert. Abbildung 8 zeigt den Software-Stack in der aktuellen Version. Wie dabei ersichtlich wird, managed der Web-Server Services die sich aus internen und externen Prozessen zusammensetzen. Es können aber auch externe Services z. B. zur Identifizierung implementiert werden. Die Hauptfeatures sind derzeit das Application Sharing, bei dem X11- und Java-Anwendungen bei einer Zusammenarbeit von den Teilnehmern gemeinsam genutzt werden können, das Immersive Audio, welches viele verschiedene Audio-Features wie Mixen, Recorden, das Virtuelle Mikrofon etc. bereitstellt und die Telephone Integration, die es Avataren ermöglicht sich über ihre Telefone zu verbinden. Vor allem das Application Sharing ist ein großes Plus für Wonderland. Hat man nämlich bereits Java-basierte Anwendungen in Gebrauch, kann mit geringem Aufwand aus dieser Anwendung heraus dynamisch eine 3D-Welt generiert werden,^[63] zu sehen auch in Abbildung 9. Das Game Graphics System von Wonderland setzt auf der 3D-Gameengine J-Monkey auf, ebenfalls eine reine Java-basierte Entwicklung. Das Avatar-System beinhaltet vorgefertigte 3D-Körper, eine Skinning-Funktion zur Anpassung der Texturen sowie Animationen und Posen die zur Belebung der Körper eingesetzt werden können. Was das Inventar von Wonderland angeht, so existieren hierzu, wie oben bereits erwähnt, schon einige Features. Z. B. lassen sich bereits 3D-Modelle im Collada-Format .dae und im Google SketchUp-Format .skp importieren. Auch werden alle gängigen Tools wie Photoshop, GIMP, Google SketchUp, Maya und sogar Blender unterstützt und können somit kreativ genutzt und in den Erstellungsprozess integriert werden. Der Content kann aber auch dynamisch aus einer integrierten Palette eingefügt werden, wie z. B. der Firefox Browser oder das Mikrofon. Fast zum Standard einer 3D-Welt gehören schon die klassischen In-world tools, mit denen sich Objekte bewegen, modifizieren aber auch skalieren lassen. In der Entwicklung befinden sich derzeit noch ein modulares System um eigenentwickelte Extensions in Form von Artwork, Code, Skripten, etc. auch proprietär bereitstellen zu können, das sog. Embedded Swing zur in-world-Application-Entwicklung sowie ein Web-basiertes Managementsystem für den Server. Mit diesem erweiterten Funktionsumfang kann aber nach Aussage von Sun erst Mitte des Jahres 2010 gerechnet werden.^[64]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Software-Stack von Wonderland in der aktuellen Version 0.5

(Quelle: (Sun Microsystems Inc., 2009), WWW)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Aus der Java-basierten Anwendung heraus wird die 3D-Welt zur immersiven Kommunikation erzeugt

(Quelle: (Nourie, 2008), WWW)

2.3.1.3. Analyse von 3D-Plattformen

Die Analyse der Plattformen soll dem Leser einen tieferen Einblick in ihre Leistungsfähigkeit und die Anforderungen an selbige verschaffen. Hierzu wurden Kriterien eruiert, die die Plattformen auf einer technischen Ebene miteinander vergleichbar und somit bewertbar machen. Die Analyse wird durch eine Gegenüberstellung in einem Kriterienraster umgesetzt. Zunächst werden die Kriterien kurz beschrieben und anschließend an den vier 3D-Plattformen Second Life, Twinity, Open Simulator und Project Wonderland über ein Raster abgebildet.

2.3.1.3.1 Kriterien

Zunächst wird auf die Systemanforderungen der Plattformen eingegangen. Für die Erstellung von 3D-Welten und den darin befindlichen Objekten ist es wichtig, dass Schnittstellen zu 3D-Grafikprogrammen existieren. Deshalb werden nach den Systemanforderungen die 3D-Grafikformate und 3D-Grafikprogramme betrachtet, die mit den 3D-Plattformen kompatibel sind. Als letztes Kriterium für den Vergleich der 3D-Plattformen sollen die möglichen Scripting Languages herangezogen werden, da diese für Entwickler oft entscheidend sind.

2.3.1.3.1.1 Systemanforderungen

Damit die erzeugten 3D-Welten und Objekte überhaupt auf den Rechnern der Endbenutzer aufgerufen werden können, müssen deren Rechner die Systemanforderungen erfüllen. Dabei gilt: Je höher die Qualität der Anwendung, desto höher sind die Systemanforderungen. Dies kann sich in verschiedenen Kriterien wiederspiegeln die nachfolgend beschrieben werden.

Betriebssystem

Das Betriebssystem als zentrales Steuerelement eines Rechners sorgt für den Ablauf von Anwendungsprogrammen, verwaltet den Hauptspeicher und regelt die Ein- und Ausgabe von Daten. Für den Vergleich wurden nur die gängigsten Betriebssysteme herausgesucht: Windows XP und Vista, Mac OSX sowie Linux und Solaris. Tabelle 1 zeigt die Ergebnisse.

CPU/ Prozessor

Der Hauptprozessor ist die zentrale Verarbeitungseinheit eines Rechners und führt sämtliche Rechen- und Ladevorgänge während des Betriebs aus. Je besser der Prozessor, desto mehr Rechenvorgänge können in kürzerer Zeit ablaufen. Auch bei den Prozessoren zeichnet sich ab, dass die Plattformen vor allem für die weiter verbreiteten Prozessoren von Intel ausgelegt sind. Die im Vergleich aufgeführten Prozessoren sind folgende: Intel Core 2 Duo, Intel Core 2 Quad, Athlon 800 und Athlon XP 2 (siehe Tabelle 2).

RAM/ Arbeitsspeicher

Die verschiedenen Plattformen setzen eine Mindestgröße des Arbeitsspeichers voraus. Es gilt, dass ein kleinerer Arbeitsspeicher als angegeben einen optimalen Ablauf des Programms verhindert. Um eine moderne 3D-Plattform am Laufen halten zu können, sollte ein Arbeitsspeicher in der Größenordnung von einem Gigabyte vorhanden sein, wie aus Tabelle 3 ersichtlich wird.

Grafikanforderungen

Die Grafikkarte spielt eine elementare Rolle, wenn es darum geht, 3D-Szenen in einer ansprechenden Qualität abzuspielen. Hier ist die Echtzeitvisualisierung der 3D-Welt wichtig. Dafür besitzen Grafikkarten einen eigenen Grafikprozessor und einen Grafikspeicher. Je besser eine Grafikkarte ausgestattet ist, desto besser können Abläufe und Details sichtbar gemacht werden. Die im Vergleich aufgeführten Grafikkarten-Serien reichen für Anwender, die sich 3D-Objekte ansehen möchten bzw. die virtuelle 3D-Welten besuchen. Folgende Grafikkarten werden verglichen: Von ATI-Radeon die Serien 8000, 9000 und X, sowie von Nvidea GeForce die Serien 7, 8 und 9. Auch hier gilt, dass diese Empfehlungen der 3D-Plattformen lediglich Mindestanforderungen sind. Sollten qualitativ bessere Grafikkarten eingesetzt werden, hat dies auf den Ablauf der Programme keinen Einfluss. Tabelle 4 liefert die Übersicht und Ergebnisse.

2.3.1.3.1.2 Importierfähige Grafikformate

Die meisten 3D-Objekte werden nicht direkt in der virtuellen Welt erstellt, sondern mit Hilfe externer Grafikprogramme. Die 3D-Plattformen bieten verschiedene Schnittstellen um diese Objekte zu importieren. Für diesen Import müssen die Objekte bestimmte Grafikformate haben. Im Folgenden werden einige 3D-Grafikformate aufgelistet und beschrieben. Dies sind vor allem 3dm, 3ds, ase, dae, fbx, obj, rwx, wrl, x3d und skp. Eine nähere Beschreibung einiger dieser Formate erfolgt im Kapitel „Integration von 3D-Welten in existierende 3D-Plattformen“. Die Erkenntnisse zu Grafikformaten sind in Tabelle 5 dargestellt.

2.3.1.3.1.3 3D-Grafikprogramme

Dateien, welche die zuvor beschriebenen Grafikformate haben, können mit verschiedenen Grafikprogrammen erstellt werden. Auf dem Markt existiert eine unglaubliche Fülle dieser Grafikprogramme, sowohl im proprietären als auch im Open Source-Bereich. Die wichtigsten nachfolgend aufgezählten sollen zur Analyse herangezogen werden: Blender, Wings 3D, SketchUp, Art of Illusion, 3dsMAX, Lightwave, Maya und Softimage XSI. Die wichtigsten dieser Grafikprogramme werden im Kapitel „Modellierung von 3D-Welten“ näher erläutert. Die Ergebnisse des Vergleichs der 3D-Grafikprogramme liefert Tabelle 6.

2.3.1.3.1.4 Skriptsprachen

Die verschiedenen Plattformen sind alle in verschiedenen Skriptsprachen geschrieben. Mit ihnen werden die Rahmenbedingungen für den Ablauf dieser Welten gelegt. Es besteht teilweise die Möglichkeit, verschiedene Programmiersprachen zu verwenden. Im Folgenden werden die einzelnen Programmiersprachen genannt, die für den Vergleich (siehe Tabelle 7) betrachtet wurden: C#, Java, JScript.NET, Linden Scripting Language (kurz: LSL), Open Simulator Scripting Language (kurz: OSSL), Python, Visual Basic.NET und Yield Prolog.

2.3.1.3.2 Vergleich

2.3.1.3.2.1 Systemanforderungen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vergleich Betriebssysteme

(Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Vergleich CPUs

(Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Vergleich RAM-Größen

(Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Vergleich Grafikanforderungen

2.3.1.3.2.2 3D-Grafikformate

(Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Vergleich 3D-Grafikformate

(Quelle: Eigene Darstellung)

2.3.1.3.2.3 3D-Grafikprogramme

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Vergleich 3D-Grafikprogramme

(Quelle: Eigene Darstellung)

2.3.1.3.2.4 Skriptsprachen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Vergleich Skriptsprachen

(Quelle: Eigene Darstellung)

2.3.2. Modellierung von 3D-Welten

Dieses Kapitel soll eine Übersicht darüber verschaffen, welche Möglichkeiten existieren um für 3D-Welten Objekte erstellen zu können, d. h. welche Technologien dazu vorliegen. Grundsätzlich kann man dabei zwei Vorgehensmöglichkeiten unterscheiden. Zum einen existieren oft Client-integrierte Werkzeuge mit denen in der bestehenden Welt selbst Objekte erschaffen und bearbeitet werden können. Ein Beispiel dafür ist das Inworld-Build-Tool des SL-Viewers. Zum anderen existiert eine Unmenge an externen Werkzeugen zur Generierung von 3D-Objekten. Für die Diplomarbeit interessant sind vor allem Tools, die die Kreation digitaler Inhalte und die Generierung von 3D-Web-Content unterstützen. Hierzu wurden ein paar aus dem zuvor durchgeführten Vergleich ausgesucht. Diese werden im Folgenden näher beschrieben: Der Allrounder mit dem größten Marktanteil 3dsMAX, das ebenfalls mächtige Open Source-Tool Blender sowie das neueste 3D-Creation-Tool aus der Google-Schmiede SketchUp. Vor- und Nachteile beider Toolvarianten liegen auf der Hand. Inworld-Tools haben nur den grundlegenden Funktionsumfang zur Verfügung, bleiben dafür frei von Schnittstellen-Problematiken. Externe Tools wiederum haben genau diese Schnittstellen zu meistern und bieten dafür einen sehr umfangreichen Funktionsumfang der in der 3D-Welt nicht realisierbar ist. Diese Tools sollen in den nachfolgenden Kapiteln näher betrachtet werden.

Tabelle 8 liefert zusätzlich eine Übersicht der exportierbaren Formate der 3D-Modellierungswerkzeuge.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Exportierbare Formate von 3D-Modellierungswerkzeugen

(Quelle: Eigene Darstellung)

2.3.2.1. Inworld-Build-Tool bei Second Life

Wie bei den Tools 3d Studio Max oder Blender weiter unten näher beschrieben, gehören zu den Grundfunktionalitäten von 3D-Modellierungswerkzeugen Modellieren, Shading, Lichtdesign, Rendering, Animation und das Skripting. Welche dieser Funktionen ein einfaches Inworld-Build-Tool (kurz: IBT) leisten kann, soll hier beleuchtet werden. Es sei vorweg gesagt, dass ein IBT von der Tiefe nicht an ein Max oder Blender reicht und dass Client-integrierte Tools vorrangig zur Kommunikation und Inventarisierung eingesetzt werden. Gleichzeitig stellen sie jedoch soviel Funktionalität bereit, um schnell kreativ werden zu können. Zur Modellierung steht dem IBT von SL eine Datenbank aus primitiven Objekten, sog. Prims zur Verfügung. Diese können nach Erstellung durch Positionierung, Drehung und Dehnung manipuliert und mit anderen Objekten zusammengeführt werden. Auch das Land selbst, auf dem gebaut wird, lässt sich bearbeiten, indem man es einebnet, anhebt, absenkt, glättet, usw. Erstellte Objekte können auch mit Texturen belegt werden. Auch hier kann man entweder auf eine SL-Datenbank an Mustern zurückgreifen oder aber eigene Bilder hochladen und auf den Objekten positionieren. Hingegen lässt sich in Sachen Lichtdesign keine umfangreiche Funktion finden. Alleine einzelnen Objekten kann eine farbliche Beleuchtung zugewiesen werden. Auch Rendering existiert zwar, aber nur in Form eines „Foto“-Buttons, der Screenshots schießt, die dann im png-Format gespeichert werden können. Animation und Skripting sind im IBT von SL eng miteinander verbunden, denn mit der Linden Scripting Language lassen sich Animationen für den Avatar oder andere Objekte schreiben. Abbildung 10 zeigt den KnowCube der Hochschule Heilbronn. Dieser wurde mit dem SL-IBT vom Diplomanden zu Veranschaulichung auf einem OpenSim-Server modelliert und zeigt, dass nicht unbedingt hochkomplexe 3D-Werkzeuge zur Erstellung von 3D-Objekten notwendig sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: KnowCube mit dem Second Life-builder modelliert

(Quelle: Eigener Screenshot)

2.3.2.2. 3d Studio Max

3d Studio Max, von eingefleischten Fans einfach Max genannt, ist eine kommerzielle Software zur Erstellung von 3D-Objekten und Animationen. Es wird von Autodesk bereits seit 14 Jahren entwickelt und läuft ausschließlich auf dem Betriebssystem Windows. Der Funktionsumfang der Software ist über die Jahre gewachsen, wurde mit Extensions überhäuft und ist mittlerweile so unglaublich mächtig, dass es mit Sicherheit keinen Experten gibt, der sich mit allen Funktionen gleich gut auskennt. Um alle Funktionen in Max zu verstehen, braucht man fundiertes Wissen aus dem 3D-Bereich sowie jahrelange Erfahrung in der Anwendung. Max ist das umfangreichste 3D-Grafik- und Animationsprogramm, das am 3D-Markt im Bereich der digitalen Contenterstellung existiert. Durch die vielen Möglichkeiten in den einzelnen Teilbereichen der Software wie Modellierung, Materialisierung, Texturierung und Animation existieren in der freien Wirtschaft Experten, die sich in 3ds Max nur auf einen Bereich spezialisieren. Die wichtigste Funktion bei Max ist die Modellierung. Hierunter wird die einfache Erstellung und Bearbeitung von 3D-Objekten verstanden. Max verfügt über eine riesige Bibliothek von vorgefertigten 3D-Objekten. Weiter existiert eine Menge von Shading-Funktionen, die zur Bearbeitung von Oberflächen, Materialien und Texturen eingesetzt werden. Auch Lichteinstellungen spielen in der 3D-Welt eine große Rolle, denn sie lassen Szenen realitätsnah erscheinen. Max bietet dazu zehn verschiedene Typen an Lichtquellen. Eine weitere Hauptfunktion von Max ist das Rendern, d. h. aus den 3D-Daten wird eine 2D-Ansicht generiert. Max kann natürlich auch Animationen erstellen. Diese Funktion wird vor allem im Gaming-Bereich sehr geschätzt und angewandt. Zu guter Letzt sei noch auf das Scripting verwiesen, denn die Software verfügt über eine eigene Scripting-Language genannt „MAXScript“. Interessant ist auch die Betrachtung der Objekterzeugung. Bei der Modellierung beginnt man meistens mit dem Grundgerüst des zu erstellenden Objektes. Über die 3D-Objektbibliothek kann ein Prim gewählt werden und dient als Ausgangsbasis zur Modellierung. Max stellt das Objekt innerhalb der Szene CAD-klassisch in vier verschiedenen Perspektiven dar: in jeder der drei Achsen x, y und z sowie als 3D-Perspektive mit Fluchtpunkten und im Horizont. Dabei enthält die rudimentäre Arbeitsfläche noch keine Einstellungen bezüglich Licht oder Kameraperspektive. Hat das Objekt seine Form erhalten, erfolgt das Shading bei dem der Designer die Oberflächentextur bearbeitet und eventuell noch die Einstellungen der Lichtquellen, die der Szene noch mehr Raumgefühl und Authentizität verleihen. Wird nun eine Vorschau oder der Export in ein Bildformat gewünscht, erfolgt dies anhand des Renderings. Dies sind nur die grundlegenden Möglichkeiten und erfahren bei Max die größte Nutzung. Dank der Animationsfunktion ist natürlich auch die Herstellung Interaktiver Medien in Max ein großes Anwendungsfeld. Interessant bei Max sind auch die exportierbaren Formate. Hier lässt sich konstatieren, dass die Software so ziemlich alle Formate unterstützt, was auch auf die Machtstellung am Markt zurückzuführen ist. Folgende Formate lassen sich exportieren und sind für die Betrachtungsweise der Diplomarbeit von Relevanz: 3D-Studio (3ds), Collada (dae), Wavefront Object (obj), VRML97 (wrl) sowie Autodesk FBX (fbx).^[90]

2.3.2.3. Blender

Blender wurde 1998 veröffentlicht. Es hat stürmische Zeiten erlebt, weil die Gründer im Zuge des Dot-Com-Blase 2000/ 2001 bankrott gingen. Blender bot auch für gewerbliche Nutzer eine kostenlose Vollversion zur Erstellung und Bearbeitung von digitalen 3D-Objekten an und fand so schnell großen Zulauf. Dank einer Spendenaktion konnte der Quellcode der Software von einem der Gründer zurückgekauft und unter der General Public License der Öffentlichkeit zur Verfügung gestellt werden. Die dabei gegründete Blender Foundation sowie eine große Community haben zum Erhalt und zur Weiterentwicklung von Blender einen großen Beitrag geleistet. Blender wird heute in den Bereichen 3D-Modellierung, Web-Design und auch im Game-Design verstärkt eingesetzt. Zu den Funktionalitäten gehört bei Blender genau wie bei Max das Modellieren, Shading, Lichtdesign, Rendering, Animation und das Skripting.^[91] Besonders erwähnenswert ist die integrierte Gaming-Engine, mit der sich z. B. Walk-throughs durch erstellte 3D-Welten auf Knopfdruck generieren lassen.^[92] Skripting ist in Blender mit C, C++ und Python möglich. Was den Export angeht, so unterstützt Blender aus heutiger Sicht alle wichtigen Formate wie 3D-Studio (3ds), Collada (dae), Wavefront Object (obj), VRML97 und VRML 1.0 (wrl), Autodesk FBX (fbx) und zusätzlich auch Extensible 3D (x3d). Für viele Formate, die Blender nicht standardmäßig bereitstellt, existieren Skripte in der Community.

2.3.2.4. Google SketchUp

Eine Sonderstellung auf dem 3D-Modellierungs-Markt hat Google SketchUp. Es wird seit 1999 vom Unternehmen SketchUp, die mittlerweile von Google aufgekauft wurden, entwickelt.^[93] Das Besondere daran: Die Software erzeugt mit Hilfe klassischer 2D-Zeichenwerkzeuge 3D-Modelle. Designer finden einen klassischen Workflow auf dem Weg zu digitalen Konstruktionsplänen in drei Dimensionen. Google SketchUp holt klassische Zeichenwerkzeuge in eine Arbeitsumgebung, die man aus 3D-Modelling-Tools kennt. So fertigt man Strichzeichnungen an, deren Einzelteile sich drehen, verschieben und skalieren lassen, nur eben auf drei statt nur auf zwei Achsen. Die so entstehenden Formen füllt SketchUp automatisch und erzeugt nach und nach komplette 3D-Gebilde. Über zahlreiche Menüs modifiziert man Schatten, Farben, Texturen, usw. Zudem lassen sich die einzelnen Linien der gezeichneten Gittermodelle jederzeit manipulieren. So bleibt die Spontaneität der Arbeit wie bei Illustrationsanwendungen erhalten, ohne dass erst eine hochkomplexe Arbeitsumgebung wie die eines typischen 3D-Modelling-Tools erlernt werden muss.^[94] SketchUp ist Freeware und exportiert nur die Formate SKP als Eigenformat und KMZ für Google Earth. Die kostenpflichtige Variante SketchUp Pro exportiert zusätzlich die Formate DWG , DXF , 3DS , OBJ , XSI , VRML und FXB sowie die Videoformate QuickTime und AVI. Darüber hinaus lassen sich Modelle in beliebiger Auflösung drucken und exportieren (BPM, TIFF, PNG, JPG und PDF).^[95] Letztendlich bleibt zu sagen, dass Google SketchUp ein gelungener Versuch ist, zwei Welten zusammenzubringen. Der Mix aus typischen 2D-Zeichenwerkzeugen für 3D-Modelle funktioniert einwandfrei. Abbildung 11 zeigt den KnowCube der Hochschule Heilbronn mit seiner Umgebung in SketchUp modelliert. Durch die dem Diplomanden vertrauten Handgriffe aus Adobe Illustrator konnte diese Szene in nur wenigen Stunden modelliert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: KnowCube und Umgebung mit Google SketchUp nachmodelliert

(Quelle: Eigenproduktion)

2.3.3. Integration von 3D-Welten in existierende 3D-Plattformen

2.3.3.1. Übersicht

In diesem Abschnitt geht es um 3D-Grafikformate, die zur Integration von 3D-Welten in 3D-Plattformen geeignet sind, d. h. in die Plattformen über Schnittstellen importiert werden können. Grundsätzlich lassen sich Grafikformate in drei verschiedene Bereiche gliedern:^[96] Formate, die für das Computer Assisted Design eingesetzt werden (kurz: CAD-Formate), Formate die zur Erzeugung von digitalen Inhalten eingesetzt werden (DCC-Formate) und Web-3D-Content - Formate. Der Schwerpunkt unserer Betrachtungen liegt auf Multimedia und Web-3D, weshalb nachfolgend nur DCC und Web-3D-Formate betrachtet werden. Im Bereich DCC scheint das mächtigste Format das 3D-Studio File Format (.3ds) zu sein, das momentan am häufigsten eingesetzte das Wavefront Object (.obj) und das aktuellste das Collada -Format (.dae). Als Web-3D-spezifische Formate existieren das Wrl -Format der Virtual Reality Modeling Language (kurz: VRML) sowie das x3d -Format, welches jedoch auf Basis von VRML in eine XML-konforme Spezifikation vom Web-3D-Konsortium transferiert wurde^[97]. Wie bereits beschrieben werden die meisten 3D-Objekte nicht direkt in der virtuellen Welt erstellt, sondern mit Hilfe externer 3D-Grafikprogramme. Die Webplattformen bieten verschiedene Schnittstellen um diese Objekte zu importieren. Für diesen Import müssen die Objekte bestimmte Grafikformate aufweisen. Es gibt aber auch noch andere, rudimentäre Möglichkeiten Daten auf 3D-Plattformen einzubinden. Diese werden am Ende des Kapitels kurz erläutert.

[...]

^[1] (Schmidt, 2007), WWW

^[2] Vgl. (Gartner Inc., 2009), WWW

^[3] Vgl. (3Di Inc., 2009), WWW

^[4] Vgl. (Google Inc., 2009), WWW

^[5] Vgl. (Höhl, 2009), S. 10

^[6] Vgl. (Rusdorf, 2008), WWW, S. 2

^[7] Vgl. (Rusdorf, 2008), WWW, S. 3

^[8] Vgl. (Khronos, 2009), WWW

^[9] Vgl. (Pirkola, et al., 2009), WWW

^[10] Vgl. (Höhl, 2009), S. 10

^[11] (Höhl, 2009), S. 8

^[12] (ThinkBalm, 2008), WWW

^[13] Vgl. (Höhl, 2009), S. 9

^[14] Vgl. (Höhn, 2007), S. 3 f.

^[15] (Ebenda), S. 3

^[16] (Ebenda), S. 7

^[17] Vgl. (Kappel, et al., 2004), S. 1

^[18] Vgl. (Gröschel, 2004), S. 55

^[19] Vgl. (Kappel, et al., 2004), S. 1

^[20] Vgl. (Agarwal, et al., 2007), S. 6 f.

^[21] (Sommerville, et al., 2001), S. 4

^[22] Vgl. (Kappel, et al., 2004), S. 2 ff.

^[23] Vgl. (Gröschel, 2004), S. 38 ff.

^[24] Vgl. (Dumke, et al., 2006), S. 323

^[25] Vgl. (Gröschel, 2004), S. 55

^[26] Vgl. (Dumke, et al., 2006), S. 5 f.

^[27] Vgl. (Gröschel, 2007), WWW

^[28] Vgl. (The Standish Group, 2009), WWW

^[29] Vgl. (inside-online.de, 2009), WWW

^[30] Vgl. (Anforderungen dürfen nicht nur am Projektbeginn stehen, 2006)

^[31] Vgl. (Jeckle, et al., 2004), S. 139 ff.

^[32] Vgl. (Ablonskis, 2007), S. 6 f.

^[33] Vgl. (Kappel, et al., 2004), S. 10 ff.

^[34] Vgl. (Dumke, et al., 2006), S. 337 ff.

^[35] Vgl. (Kroiß, 2008), S. 21 f.

^[36] Vgl. (Cockburn, 2003), S. 13

^[37] Vgl. (Fowler, et al., 2001), WWW

^[38] Vgl. (Waters, 2007), WWW

^[39] Vgl. (Dumke, et al., 2006), S. 343

^[40] Vgl. (Benninger, 2003), WWW

^[41] Vgl. (Kroiß, 2008) S. 9

^[42] Vgl. (Kraus, et al., 2007), WWW

^[43] Vgl. (Krömker, et al., 2005), S. 6 ff.

^[44] Vgl. (Ross, 2009), WWW

^[45] Vgl. (Weidenmann, 2001), S. 415-466

^[46] Vgl. (Issing, et al., 2002), S. 5 f.

^[47] Vgl. (Krömker, et al., 2005), S. 20.

^[48] (Srinivasan, et al., 2001), S. 77 ff.

^[49] Vgl. (Sawhney, 1995), S. 24 ff.

^[50] Vgl. (Sawhney, 1995), S. 24

^[51] Vgl. (Höhl, 2009), S. 32 f.

^[52] (Lober, 2007), S. 7

^[53] (Meinke, 2006), WWW

^[54] Vgl. (Linden Research Inc., 2009), WWW

^[55] Vgl. (Klaß, 2008), WWW

^[56] Vgl. (Second Life Grid, 2009), WWW

^[57] (Metaversum GmbH, 2009), WWW

^[58] Vgl, (Strunck, 2009), WWW

^[59] Vgl. (Opensimulator.org, 2009), WWW

^[60] Vgl. (realXtend, 2009), WWW

^[61] Vgl. (java.net, 2009), WWW

^[62] Vgl. (java.net, 2009), WWW

^[63] Vgl. (Nourie, 2008), WWW

^[64] Vgl. (Sun Microsystems Inc., 2009), WWW

^[65] Vgl. (Linden Research Inc., 2009), WWW

^[66] Vgl. (Metaversum GmbH, 2009), WWW

^[67] Vgl. (java.net, 2009), WWW

^[68] Vgl. (java.net, 2009), WWW

^[69] Vgl. (Linden Research Inc., 2009), WWW

^[70] Vgl. (Metaversum GmbH, 2009), WWW

^[71] Vgl. (Strunck, 2009), WWW

^[72] Vgl. (java.net, 2009), WWW

^[73] Vgl. (Linden Research Inc., 2009), WWW

^[74] Vgl. (Metaversum GmbH, 2009), WWW

^[75] Vgl. (Strunck, 2009), WWW

^[76] Vgl. (java.net, 2009), WWW

^[77] Vgl. (Linden Research Inc., 2009), WWW

^[78] Vgl. (Metaversum GmbH, 2009), WWW

^[79] Vgl. (Strunck, 2009), WWW

^[80] Vgl. (java.net, 2009), WWW

^[81] Vgl. (Radeon3D.org, 2009), WWW

^[82] Vgl. (wikipedia.org, 2009), WWW

^[83] Vgl. (Linden Research Inc., 2009), WWW

^[84] Twinity hat im April 2009 eine Schnittstelle zum Import von Collada-formatierten Objekten implementiert und seinen Entwicklern und Content-Partnern zur Verfügung gestellt. Weitere Formate sind in der Entwicklung, allerdings ist noch nicht bekannt um welche es sich dabei handelt. Es wird aber wohl je nach Marktsituation auf .skp, .x3d oder .3ds hinauslaufen.

^[85] Die Entwicklungen der Schnittstellen zu den Formaten Collada (.dae) und .x3d wurden im Verlaufe des Google Summer of Code 2008 begonnen. Derzeit ist leider noch nicht ersichtlich, wann die Schnittstellen dazu veröffentlicht werden. Siehe dazu (Frisby, 2008), WWW

^[86] Wonderland unterstützt die Formate .x3d und .skp direkt. Siehe dazu (java.net, 2009).

^[87] Vgl. (Linden Research Inc., 2009), WWW

^[88] Art of Illusion unterstützt VRML und X3D: siehe dazu (Scheurich, 2001), WWW

^[89] Bei Project Wonderland kann man grundsätzlich in Java programmieren. Es lassen sich aber so ziemlich alle Scripting-languages einbinden. Grund dafür ist der Java Specification Request 223 (JSR 223). Die Spezifikation beschreibt Mechanismen, die es in Skriptsprachen entwickelten Programmen ermöglichen auf Informationen der Java-Plattform zuzugreifen. Diese Skript-Programme können somit in serverseitige Java-Anwendungen integriert werden. Informationen zum aktuellen Stand des JSR 223 siehe unter (Java Community Process, 2006). Eine Beispielanwendung kann unter (Tremblett, 2009) eingesehen werden.

^[90] Vgl. (Saint-Moulin, 2007), WWW

^[91] Vgl. (Wartmann, 2007), S. 11 ff.

^[92] Vorgehensweise zum Erstellen von 3D-Walk-Throughs nachzulesen bei (Höhl, 2009)

^[93] Vgl. (Winfuture.de, 2007), WWW

^[94] Vgl. (Bechberger, 2006), WWW

^[95] Vgl. (Google SketchUp, 2009), WWW

^[96] Vgl. (Blender.org, 2009), WWW

^[97] Vgl. (Web 3D Consortium, 2009), WWW