2.3. Software für X3D – Bildschirme
Werbung
Fach: Systemprogrammierung Name: Stefan Kraus Matr.Nr.: XXXXXX E-Mail: [email protected] Thema: Entwicklung von zwei Echtzeit - Animationen unter OpenGL und DirectX™ für X3D - Systeme Inhaltsverzeichnis WICHTIGER HINWEIS ........................................................................................................ 2 1. Einleitung .............................................................................................................................. 3 1.1.Voraussetzungen .................................................................................................................. 4 1.1.1. Hardware Voraussetzungen .............................................................................................. 4 1.1.2. Software Voraussetzungen ............................................................................................... 4 2. X3D – Bildschirme ............................................................................................................... 5 2.1. Grundlegendes ..................................................................................................................... 5 2.1.1. Was sind X3D - Bildschirme? .......................................................................................... 6 2.1.2. Was sind deren Anwendungsgebiete? .............................................................................. 9 2.2. Die Tiefen der X3D – Technologie ................................................................................... 10 2.2.1. Aufbau und Funktionsweise ........................................................................................... 10 2.2.2. Die Entstehung von räumlicher Tiefe ............................................................................ 12 2.3. Software für X3D – Bildschirme ...................................................................................... 12 2.3.1. X3D – Tools ................................................................................................................... 13 2.3.2. X3D – Media Player ....................................................................................................... 16 2.3.3. X3D - 3D Studio Plugin ................................................................................................. 17 2.3.4. X3D – OpenGL Enhancer .............................................................................................. 18 2.3.5. More3D DirectX™ Stereo Driver .................................................................................. 19 2.4. Die Programmierung ......................................................................................................... 21 2.4.1. Was ist zu berücksichtigen ............................................................................................. 21 2.4.2. Eine Frage der Performance ........................................................................................... 22 3. DirectX™ - Demo ............................................................................................................... 23 3.1. Einleitung .......................................................................................................................... 23 3.1.1. Was wurde gemacht? ..................................................................................................... 23 3.1.2. Was war geplant? ........................................................................................................... 23 3.1.3. Szenen-Überblick ........................................................................................................... 24 3.1.4. Verwendete Werkzeuge ................................................................................................. 25 3.2. Die ViperEngine ................................................................................................................ 28 3.2.1. Eine knappe Einführung ................................................................................................. 29 3.3. Aufbau der DirectX™ - Demo .......................................................................................... 30 3.3.1. Das Klassendiagramm .................................................................................................... 30 3.3.2. Das Zusammenspiel ....................................................................................................... 31 3.4. Problemstellungen ............................................................................................................ 32 3.4.1. Synchronisation .............................................................................................................. 32 4.0 OpenGL – Demo ............................................................................................................... 34 4.1. Einleitung .......................................................................................................................... 34 4.1.1. Was wurde gemacht? ..................................................................................................... 34 4.1.2. Was war geplant? ........................................................................................................... 34 4.1.3. Szenen-Überblick ........................................................................................................... 35 4.1.4. Verwendete Werkzeuge ................................................................................................. 35 4.3. Aufbau OpenGL - Demo ................................................................................................... 36 4.3.1. Funktionsübersicht ......................................................................................................... 36 4.3.2. Das Zusammenspiel ....................................................................................................... 37 5. Aufwand .............................................................................................................................. 38 6. Fazit ..................................................................................................................................... 39 7. Quellen................................................................................................................................. 40 Seite: 141 WICHTIGER HINWEIS Das Projekt wurde entgegen der Vereinbarungen bearbeitet! Mein Team-Kollege, mit dem ich das Projekt machen sollte, hatte während der gesamten Zeit nichts (!!!) zur Realisierung beigetragen, mich jedoch stets im Glauben gelassen, dass diverse Arbeiten bereits fertig wären, er aber diese noch weiter ausbauen würde. Recherche und Einarbeitung in die X3D-Systeme erfolgte nur durch mich (Stefan Kraus), das gleiche gilt auch für die Entwicklung der beiden Echtzeit-Animationen. Der von uns abgegebene ProjektAntrag weicht daher von der tatsächlich getätigten Arbeit ab. Ein Client und Server wurden nicht programmiert, da diese in den Aufgabenbereich meines Team-Kollegen fielen. Ich habe mir sehr viel mühe gegeben, dennoch soweit wie möglich alle geforderten Teile des Projektes ordentlich zu erfüllen. Ich habe nicht nur meinen Teil komplett erfüllt, sondern zusätzlich noch Teile meines Team-Kollegen! Über dieses Problem hatte ich ja bereits mit Herrn Heinzel gesprochen und er hatte sich die einzelnen Teile bereits auf dem Projektantrag notiert (es sind jedoch weitere dazugekommen!). Ebenfalls hatte ich die Erlaubnis die, für die Dokumentation, maximal erlaubte Seitenzeil zu überschreiten. Jedoch hatten Herr Heinzel und ich uns nicht darüber geeinigt wie diese Zahl auszusehen hat. Ich hoffe im Rahmen geblieben zu sein, und bitte um Verständnis, da zum einen das Thema sehr komplex war und zum anderen, da ich doppelte Arbeit leisten musste! Weiterhin möchte ich darauf hinweisen, dass mein Teamkollege bis heute kein Wort über den Ausstieg verloren hat. Seine letzten Worte waren: „Du schaffst das schon, Stefan“. Er hatte mir zugesichert, dass er mir die fehlenden OpenGL-Scenen bis zum Abgabetermin zukommen lassen würde. Ebenso wollte er sich in die X3D-System einarbeiten um bei deren Dokumentation ebenfalls mitwirken zu können. Soweit ist es aber nicht gekommen. Ich habe bis zum 30.12.2004 auf Resultate gewartet, leider vergeblich. Die OpenGL Demo entstand unter extremen Zeitdruck, was dazu geführt hat, dass diese Qualitativ gesehen, Dimensionen hinter der DirectX-Demo liegt. Auf Musik musste ich sogar ganz und gar verzichten, da eine Synchronisation innerhalb weniger Tage nicht machbar war, zumal das Programmieren der einzelnen Szenen, dank Teamkollege, noch nicht einmal stattgefunden hatte. Ich hoffe, dass dieser Umstand bei der Benotung berücksichtigt wird. 1. Einleitung Die X3D-Systeme von Opticality sind für Multimediale Anwendungen der Durchbruch in die dritte Dimension. Es ist nun auch für den End-Benutzer zum ersten male möglich Filme, Computerspiele und alle anderen Formen der Multimedialen Unterhaltung in 3D zu genießen. Das 2D Bild des Monitors wird nun vollständig 3D. Filme erhalten eine bisher noch nicht gekannte Faszination, nämlich die der dritten Dimension. Objekte, Figuren, alles hat eine nie dagewesene Tiefe, die scheinbar zum greifen nah ist. Computerspiele werden uns noch mehr in ihren Bann ziehen, uns noch realer und noch fantastischer erscheinen. Die X3D-Systeme läuten eine neue Ära des Multimedialen Zeitalters ein und öffnen somit neue Möglichkeiten der Multimedialen Unterhaltung. Wir werden uns in den folgenden Kapiteln diese Bildschirme genauer unter die Lupe nehmen. Wir werden erfahren, wie sie funktionieren, wofür man sie alles einsetzen kann, und wie man sogar eigene 3D-Anwendungen für sie entwickeln kann. Die Vielfalt ist recht groß und bei weitem noch nicht vollkommen ausgeschöpft. Wir werden auch erfahren, welchen Problemen diese neue Technologie gegenübersteht und was uns in Zukunft noch alles erwarten wird. Ich für meinen Teil bin jedenfalls sehr gespannt und aufgeregt. Begleiten Sie mich in eine Welt, die noch nie ein Mensch zuvor gesehen hat. Eine Welt die Ihren Atem zum stocken bringen wird. Eine Welt in der Phantasie und Realität verschmelzen werden. Willkommen in der dritten Dimension „Faszinierend“ Spok, Star Trek TOS 1.1. Voraussetzungen Um überhaupt in den Genuss dieser neuen Technik kommen zu können muss man bestimmte Voraussetzungen sowohl auf der Hardware- als auch auf der Software-Basis erfüllen. 1.1.1. Hardware Voraussetzungen Es gelten folgende Voraussetzungen: CPU Grafikkarte Arbeitsspeicher Zusätzliche Hardware Intel Pentium4 CPU mit 2.0GHz oder mehr (bzw. Gleichwertige AMD CPU) 3D-Grafikkarte mit min. 64 MB VRAM und voller DirectX™ 9.0 Unterstützung. Anschluss analog oder digital (ATI 9700 oder höher bzw. GeForce Ti4800 oder höher, optimal 128 MB VRAM) Min. 512 MB RAM (optimal 1024 MB RAM) X3D – Bildschirm Die oben aufgelisteten Werte sind sogar die Mindestvoraussetzungen um überhaupt einen ordentlichen optischen Fluss zu erhalten. Wieso das so ist, klären wir in einem späteren Kapitel. Jedoch sollte man sich vorab stets im Hinterkopf halten, dass es sich hierbei um 3DGrafiken handelt, was zur Folge hat dass die Grafikkarte die am meisten beanspruchte Komponente ist. Grundsätzlich gilt: Je besser die Grafikkarte, desto flüssiger jede Art von 3D-Anwendung (vorausgesetzt die Anwendung nutzt die Grafikkarte). 1.1.2. Software Voraussetzungen Es gelten folgende Voraussetzungen: Betriebssystem Zusätzliche Software Microsoft(R) Windows(TM) XP Home Microsoft(R) Windows(TM) XP Professional Microsoft(R) Windows(TM) 2000 X3D-Software/Treiber (abhängig von Funktionalität) DirectX™ 9.0c und OpenGL Derzeit werden nur die Betriebssysteme Windows 2000 und XP unterstützt. Für UnixSysteme gibt es zurzeit keinerlei Unterstützung (ist jedoch bereits in Planung). Welche X3D-Software/Treiber man installieren muss hängt ganz von der Funktionalität ab. Für Filme gibt es den X3D Multimedia Player, der für dass Abspielen von 3D-Filmen verantwortlich ist. Für Spiele bzw. Anwendungen die auf OpenGL bzw. DirectX™ basieren benötigt man je nach Wahl den OpenGL Enhancer bzw. den More3D-Treiber. 2. X3D – Bildschirme Die X3D-Bildschirme sind der Kern des ganzen. Ohne sie hätten wir nichts von all der schönen 3D Grafik. In diesem Kapitel werden wir folgendes behandeln: Was sind X3D-Bildschirme? Was sind deren Anwendungsgebiete? Aufbau und Funktionsweise Benötigte und vorhandene Software Programmierung 2.1. Grundlegendes Als erstes widmen wir uns der Frage was das denn überhaupt für Bildschirme sind und wofür man diese einsetzen kann. Anschließend werden wir deren Aufbau in groben Zügen kennen lernen und erfahren, wie ein realistisch wirkendes, dreidimensionales Bild in ihnen entsteht. Danach lernen wir einige Software-Pakete kennen, die unverzichtbar bei der Anwendung von X3D-Bildschirmen sind. Als letztes in diesem Kapitel erfahren wir einige wichtige Grundlegende Dinge in Sachen Programmierung, auf die man achten sollte, wenn man 3DAnwendungen für diese Art von Systemen entwickelt. „ES KÖNNTE EINE ART BIOLOGISCHE LEBENSFORM SEIN“ Dr. Beverly Crusher, Star Trek TNG 2.1.1. Was sind X3D - Bildschirme? Kurz und knapp: 3D ohne Brille 3D für Mehrere gleichzeitig 3D von verschiedenen Standpunkten aus Die X3D-Bildschirme unterscheiden sich von den herkömmlichen Bildschirmen, wie wir sie kennen. Diese sind nämlich in der Lage, Bilder dreidimensional darzustellen. Die Bildqualität ist dabei unabhängig vom Betrachtungsstandpunkt. Die 3D – Bildschirme sind in verschiedenen Ausführungen erhältlich. Die nachfolgende Tabelle gibt eine Übersicht über die derzeit vorhandenen Bildschirme: X3D-17“ Display AD Auflösung: 1280 x 1024 Eff. Displaygröße (mm): 338,0 x 270,0 Diagonale (mm): 17" (432,0) Gewicht: 10,0 kg Äußere Abmaße 378,0 x 374,0 x 195,6 [B/H/T] (mm): Eingang: analog (VGA) 15 pin D-Sub cable oder DVI Stromversorgung: 100-240 V, 50/60 Hz X3D-19“ Display AD Auflösung: 1280 x 1024 Eff. Displaygröße (mm): 376,3 x 301,1 Diagonale: 19" Gewicht: 10,0 kg Äußere Abmaße 442,0 x 474,0 x 180,0 [B/H/T] (mm): Eingang: analog (VGA) 15 pin D-Sub cable oder DVI Netzeingang: 100-240 VAC, 50-60 Hz X3D-20“ Display AD Auflösung: 1600 x 1200 Eff. Displaygröße 408,0 x 306,0 (mm): Diagonale (mm): 20" Gewicht: 12,0 kg Äußere Abmaße 483,0 x 502,0 x 210,0 [B/H/T] (mm): Eingang: analog (VGA) 15 pin D-Sub cable oder DVI Stromversorgung: 100-240 V, 50/60 Hz X3D-40“ Display AD Auflösung: 1280 x 768 Eff. Displaygröße 871,7 x 523,0 (mm): Diagonale (mm): 40" Gewicht: 41,0 kg Äußere Abmaße 949,0 x 605,0 x 141,0 [B/H/T] (mm): Eingang: analog (VGA) und digital(DVI) Stromversorgung: 100-240 V, 50/60 Hz X3D-50“ Display AD Auflösung: 1280 x 768 Eff. Displaygröße 1098,2 x 620,5 (mm): Diagonale (mm): 50" Gewicht: 48,0 kg Äußere Abmaße 1218,0 x 714,0 x 110,0 [B/H/T] (mm): Eingang: analog (VGA) und digital(DVI) Stromversorgung: 100-240 V, 50/60 Hz 2.1.2. Was sind deren Anwendungsgebiete? Die Anwendungsmöglichkeiten der X3D-Bildschirme sind sehr vielfältig und die hiermit möglichen dreidimensionalen Darstellungen faszinierend und effektvoll. Neben Werbewirtschaft, Wissenschaft, Technik, Medizin ist diese Technologie vor allem für die Unterhaltungsindustrie besonders interessant. Hierzu zählen unter anderem Computerspiele und das tägliche Fernsehen. Angestrebt, durch diese Technologie, ist die Einführung des 3D-Fernsehen. Hier einige Beispiele für Anwendungsgebiete: Werbewirtschaft Wissenschaft und Technik Medizin neue Möglichkeit der werbewirksamen Präsentation, z. B. Point of Sale, Point of Information, Messeauftritt, Präsentationen, Schaufenster, virtuelle Verkaufsportale, Wegweiser Steigerung der Aufmerksamkeit bei den Kunden Nutzung als Gemeinschaftsportale verbessertes product placement unterhaltsame und informative Verkürzung von Wartezeiten eingehende Analyse von Konstruktionen, Entwicklungen und Entwürfen in jeder Phase frühzeitige Analyse und Prüfung von Planungsalternativen, technischer Maße und die Integration in bestehende Baugruppen mögliche Kostenoptimierung durch Verringerung nachträglicher Planungskorrekturen, nicht mehr unbedingt notwendige Herstellung eines Prototypen, effektivere Entwicklungszeiten anschauliche Präsentation für Entscheider und Kunden, welche nicht über das technische Know-How und die Vorstellungskraft verfügen Realisierbarkeit von Kundenwünschen darstellbar verbesserte Diagnostik Steigerung der Ausbildungsqualität und der Nachhaltigkeit von Wissen Kostenoptimierung 2.2. Die Tiefen der X3D – Technologie Nun wird es langsam an der Zeit etwas tiefer in diese neue Technologie einzutauchen. Uns reicht es nicht (mir jedenfalls nicht) nur zu wissen wozu diese Bildschirme gut sind und wofür man sie alles einsetzen kann. Ein Blick hinter die Kulissen wird uns mehr Aufschluss darüber geben wie sie funktionieren und wie sie aufgebaut sind. 2.2.1. Aufbau und Funktionsweise Die X3D-Bildschirme basieren auf den uns bisher bekannten Flach-Bildschirmen (TFT-LCD, Plasma), welche um einen speziellen optischen Filter erweitert worden sind. Diesen Filter nennt man Wellenlängenselektives Filterarray! Dieser Filter gibt die Lichtausbreitungsrichtungen der einzelnen Subpixel des Bildschirmes vor und befindet sich in einer fest vorgegebenen Entfernung zum Front-Panel des Bildschirmes (Bild 2 Illustriert den Aufbau). Bild 2 Einfach gesagt bewirkt der Filter, dass einzelne Farbwerte der Pixel in verschiedenen Winkeln in den Raum abgestrahlt werden. Abhängig vom Betrachtungswinkel lässt der Filter darunter liegende Pixel durch oder blockiert diese vollständig. Dadurch sieht der Betrachter immer eine Kombination aus mehreren unterschiedlichen Ansichten, wovon einige das dominierende Bild darstellen. Den Rest erledigt das menschliche Gehirn, welches die dominierenden Bilder herausfiltert und aus diesen die Ungleichheiten ermittelt. Sowohl der Betrachtungswinkel als auch der Abstand zum Bildschirm spielen eine entscheidende Rolle in Bezug auf das resultierende Erscheinungsbild und auf die Räumliche Wahrnehmung dieses Bildes. Anhand der nachfolgenden Skizze wollen wir dies näher untersuchen (Bild 3). Bild 3 Im obigen Bild (Bild 3) können wir sehen, aus welchen Entfernungen und Betrachtungswinkeln unser Gehirn ein ordentliches Bild erkennen kann. Befindet sich der Betrachtende vom Bildschirm weit entfernt, nimmt er zwei benachbarte Bilder wahr, nämlich Bild 6 und 7. Je näher er dem Bildschirm rückt, desto mehr Bilder kann er erkennen (Bilder zwischen 2 und 4, 4 und 7 etc.). Befindet sich ein Beobachter genau zwischen den kräftig hervorgehobenen Linien (rote Augen zeigen diese besondere Position) nimmt er ein unreines Bild wahr. Diese Bereiche, in denen ein unreines Bild entsteht, nennt man transitional area (Übergangszone). Man kann es selbst an einem ganz einfachen Experiment beobachten. Man ermittelt eine Position an der man das Bild gut erkennen kann. Nun schwenkt man ganz langsam den Kopf horizontal nach links oder nach rechts. Irgendwann stellt man fest, dass das Bild unreiner wird und nicht mehr richtig als ein 3D Bild zu erkennen ist. Geht man von diesem Punkt aus dann weiter in die eingeschlagene Richtung, kommt man wieder an einen Punkt, an dem das Bild wieder klar zu erkennen ist. Dies ist leider einer eines der Nachteile mit denen diese X3D-Systeme zu kämpfen haben. Eine Lösung für dieses Problem könnte z.B. sein, eine Kamera am Bildschirm anzubringen, welche die Kopfbewegungen mitverfolgt und dementsprechend den Filter anpasst. Technisch sicherlich möglich, aber was passiert bei mehreren Betrachtern? Die Lösung kann also nicht in der Hardware liegen, sondern in der Software. D.h. dass die Anwendungen, welche dieses 3D-Feature nutzen entsprechend optimiert sein müssen um ein akzeptables Ergebnis liefern zu können. 2.2.2. Die Entstehung von räumlicher Tiefe Wie zuvor ausführlich besprochen, enthalten die Bilder mehrere perspektivische Ansichten (insgesamt acht), die jeweils aus leicht versetzten Kamerapositionen aufgenommen wurden. Diese Bildanteile werden nun ebenso versetzt in den Raum abgestrahlt. Der Betrachter hat zwei Augen, die einen Abstand von 6,5 cm voneinander haben. Somit empfängt er jeweils zwei dieser acht Bilder und sieht somit räumlich. 2.3. Software für X3D – Bildschirme Im Besitz eines solchen Bildschirmes zu sein ist sicherlich eine wunderbare Sache, solange man auch die notwendige Software dafür besitzt. Vom letzteren gibt es mittlerweile doch recht viele und um hier die Übersicht behalten zu können werden wir uns nun kurz die bisher verfügbaren Software-Produkte etwas genauer anschauen. Derzeit verfügbar sind folgende Software-Produkte: X3D – Tools X3D – Media Player X3D – 3D Studio Max Plugin X3D – OpenGL Enhancer More3D DirectX™ Stereo Driver 2.3.1. X3D – Tools Die X3D-Tools sind eine Sammlung grundlegender Programme, mit denen 3DBilder und auch Videos zusammengestellt werden können. Dieser Player erlaubt das Abspielen von X3D-Spezifischen Videos und Standbildern. Die 3D Studio MAX-Plugins ergänzen das 3D-Studio um Renderingfunktionalität für X3D-Bilder. Die erforderlichen acht Teilbilder werden dabei im Hintergrund automatisch berechnet und gerastert. Es ist möglich, Einzelbilder sowie Bildsequenzen zu berechnen. Die Szenen müssen dafür nicht geändert werden. Bei diesem Produkt handelt es sich um eine Erweiterung des OpenGL-Treibers. Dieser sorgt dafür, das OpenGL Anwendungen dreidimensional auf den X3D – Bildschirmen dargestellt werden. Dieser Treiber beeinflusst 3D-Spiele und Anwendungen automatisch dahingehend, dass diese ohne Modifikation X3Dkompatible Bilder berechnen. Die Benutzung erfolgt analog zu Treibern für Shutterbrillen wie z.B. die ELSA Revelator. Die X3D-Tools sind sozusagen die Basis für alle anderen X3D-Software Produkte. Zu den X3D-Tools gehören folgende Programme: X3D Quick Start X3D Display Manager X3D License Manager X3D Image Wizard X3D zWraper X3D Kamerad Wir wollen uns nun diese einzelnen Programme etwas genauer anschauen um zu erfahren wozu diese überhaupt dienen. X3D Quick Start Der X3D Quick Start ist nach der Installation der X3D-Tools in der Task-Leiste zu finden. Mit diesem Programm kann man alle anderen X3D-Tools Programme starten. Es ist also sozusagen nur eine schnelle Starthilfe für andere Programme. X3D Display Manager Der X3D Display Manager ist für das Selektieren eines angeschlossenen X3D – Bildschirmes zuständig. Ebenso lassen sich über dieses Programm diverse Einstellungsmöglichkeiten auf Knopfdruck erledigen. X3D License Manager Der X3D License Manager ist für das Verwalten der Lizenzen von zusätzlichen X3D Programmen zuständig. Die meisten dieser Programme sind im Lieferumfang eines X3D – Bildschirmes nicht mit dabei und sind mit zusätzlichen Kosten verbunden. X3D Image Wizard Der X3D Image Wizard erstellt X3D Bilder aus mehreren Betrachtungswinkeln bzw. extrahiert einzelne Bilder aus bestimmten Betrachtungswinkeln. X3D zWarper Mit dem X3D zWarper kann man aus 2D-Bildern, welche eine Tiefen-Information besitzen, X3D-Bilder erzeugen. Es dient also zur Erstellung von 3D Bildern aus den äquivalenten 2D Bildern. Die Tiefeninformationen werden hierbei in einer Grau-Scala abgelegt (Bild 4), welche jedem Pixel des 2D-Bildes eine Tiefe zuweist. Das 2D-Bild wird über eine TiefenMap so abgeändert, dass daraus ein 3D-Relief entsteht. Anhand dieses 3D-Reliefes generiert der zWarper die benötigten Ansichts-Perspektiven welche für die Erstellung des 3D-Bildes verwendet werden. Dieser Vorgang wird von X3D als „z-Warping“ bezeichnet. Bild 4 Alles was man im Prinzip dann nur noch machen muss ist den zWarper zu starten, die beiden Bild-Quellen anzugeben und diverse Einstellungen (Bildgröße, Format etc.) zu tätigen. Den Rest übernimmt der zWarper. X3D Kamerad Dieses kleine Programm ist, wie der zWarper auch, für die Erstellung von X3D-Bildern zu verwenden. Der Unterschied zwischen den beiden Programmen ist jedoch der, dass man hier die verschiedenen Ansichten selber liefern muss. Selber liefern? Äh ... klingt ja recht komplex! Ist aber in Wirklichkeit recht simpel. Möchte man z.B. von einem Fernseher ein 3D-Bild erzeugen, muss man nichts anderes machen, als mit einer Digi-Cam mehrere Bilder aus verschiedenen Perspektiven aufzunehmen. Das dabei natürlich Schwankungen in den Aufnahmen entstehen können ist selbstverständlich. Und genau für diese Schwankungen ist das Programm Kamerad zuständig. Es korrigiert weitestgehend diese Unreinheiten und erstellt am Ende ein 3D-Bild. 2.3.2. X3D – Media Player Den X3D – Mediaplayer gibt es in zwei unterschiedlichen Versionen: X3D Media Player Standard Version X3D Media Player Professional Version Die X3D Media Player Standard Version ist für das Abspielen von X3D-Spezifischen Videos zuständig und erlaubt ebenso das Betrachten von X3D-Standbildern (im X3Dmv und X3Dim Format). Die X3D Media Player Professional Version im Vergleich zur Standard Version zusätzlich die Möglichkeit eigene Komprimierte Video-Sequenzen zu erstellen. Ebenso erlaubt dieser Player das Abspielen von MPEG2, AVI und WMV. Mit beiden Versionen können playlists erstellt werden. In der Professional Version ist zudem noch ein X3D Media Player ActiveX Control im Lieferumfang inbegriffen, wodurch man diesen Media Player in eigene Programme, welche z.B. mit Delphi oder Visual Basic erstellt wurden, einbinden kann. Folgende Formate werden unterstützt: Standard Version 3D-Formate 2D-Formate Professional Version 3D-Formate Komprimiertes X3Dmv Video Format Komprimiertes X3Dim / Img4D Standbild Format Unkomprimiertes AVI Format Videos in AVI, MPEG1/2 und WMV Format Bilder in JPG, BMP, PNG, TGA und TIF Format Videos in AVI, MPEG1/2 und WMV 2.3.3. X3D - 3D Studio Plugin Dieses Plugin ist wirklich überaus mächtig und relativ simpel einzusetzen. Die Installation erfolgt durch das Ausführen des entsprechenden Setup-Programms, abhängig von der verwendeten 3D Studio Max Version. Unterstützt werden 3D Studio Max 4, 5 und 6. Nach der Installation muss man dann nur noch das Plugin frei schalten. Dies erfolgt über den weiter oben besprochenen License Manager. Nach erfolgreicher Installation und Plugin Freischaltung kann man dann auch schon loslegen. Einfach 3D Studio Max starten und das Plugin steht schon zur Verfügung. Das wohl schönste an der ganzen Sache ist, dass meine seine bisherigen Szenen bzw. Projekte nicht abändern muss um diese in 3D bewundern zu können. Das einzige was zu tun ist, sind einige Einstellungen im Plugin vorzunehmen, damit das Rendern auch in 3D geschieht. Achtung: Bei der Installation ist folgendes zu beachten. An der Stelle in der Installation, bei dem man den Zielordner eingeben kann, muss man den 3Dstudio Max Ordner auswählen. Also den Ordner, in welchem man seine 3D Studio Max Version installiert hat. Ansonsten wird das Plugin nicht geladen. In diesem Fall muss man es zuerst deinstallieren und anschließend neu installieren. 2.3.4. X3D – OpenGL Enhancer Der X3D OpenGL Enhancer ist eine Erweiterung der standardisierten OpenGL-Schnittstelle, die es ermöglicht, die Bilderzeugung auf der Grafikkarte entsprechend der X3D-Technologie zu steuern. Bei dieser Erweiterung handelt es sich um eine einfache DLL, nämlich die OpenGL32.DLL. Diese schaltet sich zwischen die Anwendung und dem eigentlichen OpenGL Treiber. Während die 3D-Anwendung wie gewohnt auf einem 2D-Bildschirm bedient wird, erzeugt die Grafikkarte automatisch auf einem zusätzlichen X3D-Display eine echte 3D-Darstellung der Szene, die tatsächlich im Raum steht. Die 3D-Anwendung muss lediglich den OpenGL-Standard unterstützen, eine weitere Anpassung der Software ist nicht mehr nötig. Wichtig ist, dass sich diese DLL in dem Verzeichnis befindet, in der sich auch die entsprechende Anwendungsdatei befindet (also die ausführbare EXE – Datei). Da der eigentliche OpenGL Treiber den gleichen Namen trägt wie der OpenGL Enhancer sollte man diese unter keinen Umständen verwechseln. Ohne den OpenGL Treiber funktioniert auch der OpenGL Enhancer nicht, was soviel heißt dass man keine Grafikausgaben erhält. Der linke Bildschirm zeigt die gewohnte Darstellung der 3D-Anwendung an. Alle Menüs, Texte, Bedienelemente etc. sind vollständig verfügbar. Das zusätzliche X3D-Display auf der rechten Seite stellt die 3D-Szene parallel in echter Tiefe dar. Die Objekte scheinen im Raum zu schweben. 2.3.5. More3D DirectX™ Stereo Driver Der More3D DirectX™ Stereo Driver ist eine universelle Software, die im Hintergrund einer 3D-Grafikanwendung mitläuft und alle deren Grafikausgaben in echtes, räumliches 3D-Stereo für unterschiedliche Ausgabegeräte konvertiert (in diesem Fall für X3D – Bildschirme). Dieser Treiber wurde nicht von X3D entwickelt sonder, wie der Name bereits verrät, von More3D (www.more3d.de). Dabei handelt es sich um einen, wie bereit oben erwähnt, universellen Treiber. D.h. dass jede Art von 3D Technik unterstützt wird. Die Ausgabe erfolgt stets dreidimensional, unabhängig von der verwendeten Hardware für Anzeige. X3D arbeitet jedoch mittlerweile recht eng mit More3D zusammen. Unterstützt werden 3D Anwendungen basierend auf DirectX™ und OpenGL, wobei es beim letzteren Einschränkungen gibt (nur Quad Buffered Applikationen kontrolliertes Stereo). More3D legt den Schwerpunkt auf DirectX™. Gründe hierfür sind folgende: DirectX bietet eine offene Plattform! Der Grafik-Standard Microsoft® DirectX™ unterstützt die komplexen Funktionen der neuesten Grafik-Hardware. Im Vergleich zu den meisten auf OpenGL basierenden Anwendungen, wirken die Anwendungen, die die neueste DirectX Version benutzen, fotorealistischer and grafisch aufwendiger als jemals zuvor. Mehr und bessere 3D-Anwendungen Hunderte von Anwendungen verwenden DirectX™ als Standard. Sie können sofort ohne jegliche Modifikation benutzt werden. Individuelle Ideen können mit Hilfe einer der 3DAntrieben, basierend auf dem hoch professionellen Direct3D™, implementiert werden oder wir können für Ihren außergewöhnlich starken 3D-Motor eine Lösung erstellen. Die nachfolgende Tabelle gibt eine komplette Übersicht über den More3D Stereo Treiber: Features Betriebssysteme 3D - Standards Ausgabemedien Echtzeit-Konvertierung von Direct3D-Anwendungen Arbeit unbemerkt im Hintergrund Zahlreiche Einstellmöglichkeiten Controlpanel innerhalb der Applikation Räumliche 3D-Screenshots auf Tastendruck Qualität vs. Geschwindigkeit einstellbar Geeignet für verschiedene 3DAusgabemedien Microsoft(R) Windows(TM) XP Home Microsoft(R) Windows(TM) XP Professional Microsoft(R) Windows(TM) 2000 Direct3D, im Fenster und Vollbildmodi 4D-Vision Displays X 3D-Displays i-Art 3D-Aufsätze Achtung: Der More3D Treiber läuft momentan nur in Kombination mit nVidia GeForceGrafikkarten. ATI-Grafikkarten werden zurzeit nicht unterstützt. Empfohlen wird mindestens eine GeForce 4200Ti mit 128 MB VRAM. Die Anwendung ist relativ einfach. Zuerst installiert man den More3D Treiber und startet danach den Computer neu (man sollte vorher allerdings den neuesten Grafikkarten-Treiber installieren). Nach dem Neustart wird automatisch schon der More3D Treiber geladen und ausgeführt. Ein Symbol in der Task-Leiste gibt Zugriff auf die Einstellungsmöglichkeiten. Ist dieses Symbol grau hinterlegt ist der Treiber inaktiv. Dies kann durch zuvor manuelles Abschalten der Fall sein, oder aber es gab einen Fehler bei der Treiber-Initialisierung. Wenn jedoch das Symbol in Farbe hinterlegt ist, war die Treiber-Initialisierung erfolgreich und es können diverse Einstellungen vorgenommen werden. Die wichtigste dieser Einstellungen ist die Auswahl des richtigen X3D-Bildschirmes. Ist nun auch dies erledigt steht einem nichts mehr im Wege. Einfach die entsprechende 3D-Anwendung starten und auf dem X3DBildschirm genießen. 2.4. Die Programmierung Bei der Entwicklung von 3D-Anwendungen für X3D Systeme gibt es einige Besonderheiten auf die man unbedingt achten sollte. Zwar liefert X3D ein SDK (Software Development Kit) auf Wunsch mit, jedoch liegt es nicht in unserem Interesse dieses SDK zu behandeln oder gar zu nutzen. Für uns ist wichtig und entscheidend zu wissen, was man bei der 3D ProgrammEntwicklung unter OpenGL bzw. DirectX™ beachten muss damit am Ende ein akzeptables Ergebnis herauskommt, ohne dabei das X3D-SDK verwenden zu müssen. Schließlich sind aktuelle Computerspiele auf X3D-Systemen bereits lauffähig, ohne dass diese nachträglich angepasst werden mussten. 2.4.1. Was ist zu berücksichtigen Die wohl Beste Nachricht bezüglich dieses Themas ist, dass es Programmiertechnisch nichts, aber auch wirklich gar nichts zu berücksichtigen gibt. Keine kryptischen Zusatzfunktionen oder andere lästige Programmierprobleme mit denen wir zu kämpfen hätten. D.h. man entwickelt seine 3D-Anwendung wie gehabt und bestaunt am Ende das Ergebnis auf den X3D-Bildschirmen, ganz ohne Zusatzaufwand. Jedoch gibt es einige Punkte, auf die man Rücksicht nehmen sollte, damit am Ende die dreidimensionale Darstellung besser zur Geltung kommt. Zum einen wäre da die Szenen-Gestaltung. Hier sollte man darauf achten, Bezugspunkte zu haben. Ein Objekt erscheint noch realer und dreidimensionaler wenn man z.B. einen Bezugspunkt in Form eines Hintergrundes oder eines anderen Objektes hat, welches sich in einer gewissen Distanz zu anderen Objekten befindet. Dadurch erhält man einen wesentlich besseren Tiefeneindruck. Ein anderer Aspekt ist die Geschwindigkeit mit der man Objekte bzw. Kameras bewegt. Diese sollte nicht zu schnell von statten gehen, eher langsam und geschmeidiger. Bei zu schnellen Bewegungen erkennt unser Gehirn die Illusion als nicht ganz real an, und der so gewünschte 3D-Effekt bleibt teilweise bzw. ganz aus. 2.4.2. Eine Frage der Performance Das wohl größte Manko bei der Programmierung ist die Performance, auf die man stets Rücksicht nehmen muss. Man kann nicht einfach seine 3D-Anwendung mit tausenden von Effekten und sonstigen Feinheiten voll packen und dann erwarten dass die 3D-Umrechnung genauso flüssig von statten geht wie ohne diese 3D-Umrechnung. Wenn man bedenkt, dass für jeden einzelnen Frame acht Kamera-Perspektiven berechnet werden müssen, kann man sicht leicht vorstellen dass bei komplexen Szenen, die obendrein ja noch in Echtzeit berechnet werden, die Performance extrem stark abfällt. Z.B. läuft die DirectX™-Demo, die wir im nächsten Kapitel besprechen werden, ohne die Nutzung von More3D (was ja wie bereits besprochen dafür benötigt wird) auf einem 1,6 Centrino mit einer ATI 9700 / 128 MB VRAM Grafikkarte mit im Durchschnitt knapp über 200 FPS (Frames Per Second). Schaltet man More3D hinzu, sinkt diese auf knapp über 24 FPS. Dieser Wert reicht zwar gerade noch für eine flüssige Animationswirkung, bedenkt man jedoch, dass es sich hierbei nur um eine 3DDemo handelt, also kein Computerspiel bei dem zusätzlich Berechnungen für Kollision, Künstliche Intelligenz, Physik etc. hinzukommen, ist dieser Wert äußerst ernüchternd. OpenGL stellt übrigens auch keine Ausnahme dar, d.h. das eben erörterte Problem gilt auch im Falle von OpenGL. Ich selbst habe ein Computerspiel getestet (den Namen darf ich leider nicht verraten) um mir ein Bild von dieser Problem-Situation zu machen. Tatsächlich war es so, wie ich es erwartet hatte. Das Spiel zuckte und ruckelte munter vor sich hin wodurch der Spielgenuss natürlich total flachfiel. Dieses wohl recht bedeutende Problem führt zu einer weiteren Überlegung, nämlich zu der Entscheidung über die richtige Wahl der Programmiersprache. Die DirectX™-Demo wurde in C++ entwickelt. Hätte ich die gleiche Demo unter Java und mit Hilfe von Java3D entwickelt (welche Leistungsmäßig DirectX™ weit unterlegen ist) wäre der Animationsablauf die reinste Katastrophe. Die Firma More3D jedenfalls scheint den Schwerpunkt auf C/C++ zu legen, da ja, wie bereits besprochen, DirectX der Favorit für das Unternehmen ist. Andere Sprachen kämen für DirectX™ natürlich auch in Frage, jedoch ist es eine Tatsache, dass DirectX am besten mit C++ harmoniert (dies beweisen unzählbare Tests und Benchmarks). Achten Sie also bei der Entwicklung stets auf die Performance und optimieren Sie wo Sie nur können. Wenn möglich versuchen Sie bei dem einen oder anderen Effekt zu tricksen; es muss nur so aussehen als ob! Vermeiden Sie Überfrachtung in Form von zu vielen detaillierten Modellen. Der Endnutzer bekommt grafisch vielleicht nicht das Beste aber er bekommt es in echter 3D. Das alleine reicht für ein Stundenlanges Staunen. Es ist eine komplett neue Technik, die bei weitem noch nicht ausgereift ist. Es ist nur eine Frage der Zeit bis auch echte 3D absolut flüssig laufen wird. Wenn es aber soweit ist, werden wir alle bald über die heutige Anzeigetechnik lachen. 3. DirectX™ - Demo 3.1. Einleitung In diesem Kapitel werden wir die DirectX™-Demo, welche zu Testzwecken für X3DBildschirme entwickelt wurde, besprechen. Wir werden klären, was gemacht wurde, was beabsichtig war und welche Werkzeuge eingesetzt wurden. Anschließend widmen wir uns dem Klassendiagramm und schauen uns das Zusammenspiel zwischen den einzelnen Elementen an, sowie den Aufbau der in der Demo verwendeten Szenen. Da diese Demo mit Hilfe einer 3D-Engine mit Namen ViperEngine entwickelt wurde, werden wir auch diese kurz und knapp vorstellen. Als letztes werden wir dann noch grundlegende Probleme bei der Echtzeitanimations-Entwicklung anschauen. 3.1.1. Was wurde gemacht? Es wurde eine 3D Echtzeit-Animation in C++ mit einer 3D-Engine entwickelt, welche auf DirectX™ 9.0c basiert. Die Echtzeit-Animation läuft, wie der Name schon sagt, in Echtzeit ab. Grafiken, Positionen, Eingabemöglichkeiten, Musik und Physik werden während der Laufzeit berechnet. Die Animation besteht aus insgesamt sechs unterschiedlichen Szenen, mit jeweils sechs unterschiedlichen Effekten und Höhepunkten. Die Musik läuft synchron zur Animation im Hintergrund ab und wurde hinsichtlich des Musikablaufs, auf diese abgestimmt. 3.1.2. Was war geplant? Geplant waren ursprünglich nur fünf Szenen in die Demo aufzunehmen. Da aber die gewählte Musik eine relativ lange Laufzeit hat, wurde zusätzlich eine weitere Szene eingefügt um einfach mehr Abwechslung bieten zu können. Der gesamte Ablauf, also der Aufbau und die Gestaltung der Szenen stand vor der Entwicklung bereits fest, wurde aber währenddessen verfeinert und teilweise auch abgeändert. Die Wahl der Musik musste bereits im Vorfeld feststehen, da sich die gesamte Animation danach richtet. Es wurde bewusst ein Titel der Kategorie GOA (Mischung aus Techno und Trance) gewählt, um die Technische Seite der Animation in den Vordergrund zu stellen und um einfach dass Ganze ‚fetziger’ wirken zu lassen. „Nutzt du diese Maschine auch aus?“ Dade, Hackers 3.1.3. Szenen-Überblick Die Gesamte Demo wird in Echtzeit gesteuert, wobei diese wiederum von der Musik in Abhängigkeit gebracht wird. D.h. die Musik liefert mit der aktuellen Spur-Position auch die aktuelle Zeit. Dadurch ist es möglich, während der Entwicklungsphase Sprünge an bestimmte Stellen innerhalb der Animation vorzunehmen, was die Entwicklung wesentlich vereinfacht. Ebenso ist es dadurch möglich, bestimmte Effekte innerhalb der Animation, mit der Musik zu synchronisieren. Die Szenen sind vollkommen unabhängig voneinander aufgebaut. D.h. dass man die Szenen jederzeit auch in einer anderen Reihenfolge abspielen lassen kann. Zu beachten wäre dann allerdings die Laufzeit jeder einzelnen Szene, welche ja dann evtl. neu eingestellt werden muss. Diese ist nämlich abhängig von der Musik. D.h. ein Wechsel von einer Szene zur anderen findet nach jedem Beat-Wechsel bzw. Rhythmus-Wechsel statt. Es folgt nun ein grober Überblick jeder einzelnen Szene: Szene 1 Szene 2 Szene 3 Szene 4 Szene 5 Szene 6 Hier wird ein kleiner Rundflug durch unser Sonnensystem präsentiert. Jeder einzelne Planet samt zugehöriger Umlaufbahn wird dargestellt. Es wurde der Übersicht halber auf korrekte Größen und Distanzen verzichtet. Diese Szene zeigt vier verschiedenfarbige rotierende Würfel innerhalb eines anderen Würfels. Die einzelnen Würfel werfen auf die Wand des umgebenden Würfels jeweils ein Spot-Licht in der entsprechenden Würfel-Farbe. Interessant ist die Farbmischung, wenn zwei Spot-Lichter übereinander liegen. In dieser Szene sieht man einen Goldenen Stern, der die Umgebung (eine Berglandschaft) spiegelt. Dieser wiederum fliegt über eine Wireframe-Landschaft. Der 3D-Effekt kommt hier besonders gut zur Geltung. Bei dieser Szene kommt etwas Physik ins Spiel. Mehrere Kugeln werden von einem Gravitationspunkt angezogen und Fliehkräfte sorgen für den nötigen Schub. Wird eine Kugel zu stark beschleunigt, so dass sie ihren ‚Orbit’ verlässt, prallt sie an einem Umgebenden Würfel (dargestellt als ein Schachbrett) ab. Die Weißen Felder dieses Schachbretts sind dabei durchsichtig, und man erkennt erneut die Umgebende Berglandschaft. Die vorletzte Szene simuliert ein Schwarzes Loch im Miniformat, welches sich mitten in der Berglandschaft befindet. Dieses saugt mehrere Kugeln in sich hinein. Interessant ist die Verzerrung die sehr raffiniert simuliert wird. Die letzte Szene ist der Abspann. Es wird eine animierte Magnum dargestellt, die dreidimensionale Texte raus schießt, und anschließend einen aus Cowboy-Filmen bekannten ‚Draw’ ausführt. Selbstverständlich muss auch mal nachgeladen werden, ebenfalls animiert. Nach dem Ende der Demo folgt noch ein abschließendes Bild, mit diversen Grüssen an Bekannte und Freunde. Anschließend beendet sich die Demo von selbst. Die Gesamtlaufzeit der Demo beträgt 7,5 Minuten. Da der Ablauf in Echtzeit stattfindet, macht es keinen Unterschied ob man einen langsameren PC benutzt oder einen schnelleren. Die Dauer bleibt stets fest, nämlich 7,5 Minuten. 3.1.4. Verwendete Werkzeuge Für die Entwicklung dieser Demo wurde Microsofts(R) Visual Studio .NET eingesetzt, welches ausschließlich zur Programmierung verwendet wurde. Benötigt wurde zudem noch das DirectX™-SDK, welches sich ebenfalls auf der CD-ROM befindet. Für die Kompilierung innerhalb dieser IDE müssen folgende Vorarbeiten getroffen werden: Als allererstes müssen Sie dass auf der CD-ROM befindliche DirectX-SDK installieren. Danach kopieren Sie das Verzeichnis /Workspace von der CD-ROM, mit samt seinen Unterverzeichnissen, auf die Festplatte und starten die Datei WorkSpace.sln welche sich im Verzeichnis /Workspace befindet (Visual Studio .NET muß installiert sein). Anschließend öffnen Sie den Options-Dialog unter dem Menüpunkt TOOLS > OPTIONS. Wählen Sie hier anschließend PROJECTS > VC++ DIRECTORIES aus. Das nachfolgende Bild veranschaulicht das Ganze etwas genauer. Geben Sie nun das benötigte Include-Verzeichnis des DirectX™-SDKs an, sowie das IncludeVerzeichnis der ViperEngine und die der Demo Digillusion. Ebenso unter Include Files geben Sie zusätzlich noch das rc-Verzeichnis der ViperEngine an. Diese Verzeichnisse befinden sich innerhalb des /Workspace Verzeichnisses (z.B. das Include-Verzeichnis der ViperEngine befindet sich in /Workspace/ViperEngine). Das IncludeVerzeichnis ihres DirectX™-SDK befindet sich innerhalb des Verzeichnisses, welches Sie bei der Installation angegeben haben. Als nächstes müssen Sie noch die jeweiligen Bibliotheken-Verzeichnisse angeben. Dies geschieht über die Auswahl Library Files des gleichen Fensters (siehe Bild). Hier müssen Sie das Lib-Verzeichnis Ihres DirectX™-SDKs angeben und zusätzlich noch dass der ViperEngine. Bestätigen Sie anschließend mit OK. Als nächstes müssen Sie dem Linker die zu bindenden Bibliotheken mitgeben. Dies geschieht unter den jeweiligen Projekt-Einstellungen. Öffnen Sie also zuerst die Projekt-Einstellungen für das ViperEngine-Projekt. Wählen Sie dann CONFIGURATIONS PROPERTIES > LINKER > INPUT aus. Im Feld Additional Dependencies tragen Sie folgendes ein: odbc32.lib odbccp32.lib d3d9.lib dxerr9.lib d3dx9.lib dinput8.lib dxguid.lib dsound.lib winmm.lib strmiids.lib (siehe Bild). Öffnen Sie nun die Projekt-Einstellungen für das Digillusion-Projekt und tragen Sie dort unter Additional Dependencies folgendes ein: odbc32.lib odbccp32.lib WinMM.lib ViperEngine.lib d3d9.lib d3dx9.lib. Setzen Sie nun das Digillusion-Projekt als das aktive Projekt und drücken Sie die F5-Taste. Falls es bei der Kompilierung zu Fehlermeldungen kommen sollte gehen Sie bitte die einzelnen Schritte noch mal durch und überprüfen Sie diese auf Richtigkeit. 3.2. Die ViperEngine Wir wollen nun kurz einen Blick auf die 3D-Engine werfen, mit der diese Echtzeit-Animation entwickelt wurde. Die Engine wurde von Stefan Kraus in C++ entwickelt und basiert vollständig auf DirectX™ 9.0. Die Gesamtentwicklungszeit dieser Engine betrug ca. 2 Jahre, kurz nachdem DirectX™ 9.0 erschienen ist. Die Engine ist ein Open-Source Projekt. Den Quellcode kann man bei Stefan Kraus beantragen ([email protected]). 3.2.1. Eine knappe Einführung Die Engine verfügt über folgende Fähigkeiten: Abspielen und Manipulation von Sound-Dateien (MP3 Format) Unterstützung von Keyboard und Maus Eingaben 2D/3D Grafikausgaben Physik-Engine Kollisionserkennung Abspielen von Animationen, erstellt in 3D Studio Max Texturverwaltung (Kubische Texturen, Volumen Texturen etc.), Multi-Texturing, Bump-Maping Pfad-Animationen (Direkt/Kurven) Atmosphärische Effekte (Spiegelung, Nebel, Licht, Umgebung etc.) Kompletter Enumerationsdialog mit Auswahl und Einstellmöglichkeiten (z.B. Auflösung, Multisampling, Hardware-Rendering, Software-Rendering, Schatten etc.) Rendern in mehrere Viewports und mit Rand (Kino etc.) Manipulation von Modellen 2D/3D-Textausgaben Laden von X-Files samt Animation und zugehöriger Texturen Laden von .dm Dateien (eigenes Format, exportiert durch ein Script in 3D Studio Max) Da sich die Engine immer noch in der Entwicklung befindet, kommen in bestimmten Zeitabständen ständig neue Features hinzu. Die Engine wird mit der entsprechenden 3D-Anwendung als DLL-Datei mitgeliefert. Ohne diese Datei lässt sich die Anwendung nicht ausführen. D.h. dass die Gesamte Funktionalität der Engine sich in einer Dynamischen Bibliothek befindet, die erst zur Laufzeit gebunden wird. 3.3. Aufbau der DirectX™ - Demo 3.3.1. Das Klassendiagramm Das folgende Klassendiagramm gibt einen Aufschluss über die Zusammenhänge der für die Demo verwendeten Klassen. Nur die wichtigsten Member und Methoden werden aufgelistet. Die kompletten Klassen-Beschreibungen finden Sie in den entsprechenden Header-Dateien. Digillusion (Main) DEMO SCENE01 Member: - status Methoden: - Init(); - Render(); - Exit(); Member: - ViperD3D - ViperTexture Manager - ViperErrorHa ndling - ViperSound - ViperDInput - ViperDAudio - Time - quit SCENE02 Member: - status Methoden: - Init(); - Render(); - Exit(); Methoden: - Load(); - Run(); - Unload(); SCENE03 SCENE04 SCENE05 SCENE06 Member: - status Member: - status Member: - status Member: - status Methoden: - Init(); - Render(); - Exit(); Methoden: - Init(); - Render(); - Exit(); Methoden: - Init(); - Render(); - Exit(); Methoden: - Init(); - Render(); - Exit(); 3.3.2. Das Zusammenspiel Das Zusammenspiel des Hauptprogrammes mit den Klassen bzw. die Klassen untereinander ist relativ simpel und einfach gestrickt. Das Hauptprogramm (Digillusion) erstellt zuerst ein Fenster, welches mittels der 3D-Engine geschieht. Anschließend erstellt es eine Instanz der Klasse DEMO, wobei es das Handle und die Instanz des zuvor erstellen Fensters übergibt. War dies ebenfalls erfolgreich wird die Methode DEMO::Load() aufgerufen. Diese Methode macht nun folgendes: Instanzen von ViperD3D, ViperTexturManager, ViperErrorHandling, ViperDAudio, ViperSound, ViperDInput, ViperMesh etc. erstellen Alle Modelle laden Alle Texturen laden Musik laden Tastatur initialisieren Alle Szenen Vor-Initialisieren Nachdem all das reibungslos von statten gelaufen ist, wird im Hauptprogramm die Methode DEMO::Run() aufgerufen. Diese Methode beinhaltet eine Schleife, die bei jedem Durchgang, die entsprechende SCENE01...06::Render() Methode aufruft. Dieser Aufruf hängt vom Status der jeweiligen Szene ab. Beim Start der Demo ist der Status von SCENE01 auf STATUS_PLAY gesetzt und der Status aller anderen Szenen auf STATUS_STOP. Dadurch wird also zuerst SCENE01 abgespielt. Ist die Abspielzeit von SCENE01 abgelaufen, setzt sie ihren eigenen Status auf STATUS_FINISH. Dadurch weiß DEMO dass SCENE01 beendet wurde, und setzt somit den Status der nachfolgenden Szene (SCENE02) auf STATUS_PLAY wobei es natürlich zuvor die SCENE01::Exit() Methode aufruft. Innerhalb dieser Schleife wird auch die aktuelle Position der Musik abgerufen welcher intern als float-Wert gehandhabt wird. Dieser float-Wert stellt die Zeit dar, welche jeder SCENE01...06::Render() Methode übergeben werden muss. Weiterhin wird innerhalb dieser Schleife auch die Tastatur-Eingabe überprüft. Wird während der Laufzeit die ESC-Taste gedrückt, wird die interne Variable QUIT auf TRUE gesetzt, was zum Abbruch der Schleife und somit zum Beenden der Demo führt. Mit F10 kann man übrigens während des Ablaufs der Demo, Screenshots schießen! Viel mehr gibt es hinsichtlich des Zusammenspiels nicht zu sagen. Wie ich bereits schon erwähnt habe sind die Zusammenhänge relativ einfach. Natürlich besitzen die einzelnen Szenen noch weitere Methoden, die sind jedoch selbsterklärend und Informationen dazu können aus dem Quellcode entnommen werden. 3.4. Problemstellungen Ich kann ruhigen Gewissens sagen, dass es keine ernstzunehmenden Probleme während der Entwicklung dieser Echtzeit-Animation gab. Es gab hin und wieder ein paar Stolperfallen, die jedoch recht schnell und zügig überwunden werden konnten. Dennoch möchte ich auf eine wesentliche Problemstellung in der Echtzeit-Animations-Programmierung eingehen. Da sich diese ebenfalls auf andere Bereiche übertragen lässt, finde ich es sinnvoll diese hier kurz zu erläutern und Lösungsvorschläge bzw. Ratschläge zu geben. (Das gleiche gilt übrigens auch für die OpenGL Demo!) 3.4.1. Synchronisation Die Synchronisation ist wohl der Kernpunkt bei der Entwicklung einer Echtzeit-Animation, welche in Kombination mit einem Musikstück abläuft und auch danach ausgerichtet werden muss bzw. soll. Aber bereits auch ohne Musik kann es zu Problemen kommen. Hierzu ein Beispiel: Haben Sie schon einmal ein sehr altes Spiel gespielt, vielleicht eines, das noch aus der „Steinzeit“ der Computer stammt? Falls ja, dann haben Sie bestimmt gemerkt, dass viele dieser Spiele heute unglaublich schnell ablaufen und man zum Einsatz von so genannten Blocker-Programmen, die den Prozessor verlangsamen, gezwungen wird. Ich möchte einmal das Beispiel Wing Commander ansprechen. In diesem Spiel schlüpft der Spieler in die Rolle eines Weltraum-Fliegers, der für das Überleben der Menschlichen Spezies gegen Außerirdische Invasoren, den Kilrathi, kämpft. Startet man dieses Spiel auf einem heutigen Rechner, kommt man leider kaum zum Spielen, weil es innerhalb von einem Bruchteil einer Sekunde schon wieder zu Ende ist und man abgeschossen wurde. Doch warum ist das so? Die damaligen Programmierer hatten wohl die Entwicklung der Prozessorgeschwindigkeit reichlich unterschätzt und haben auch keine Rücksicht auf die Zeit genommen. Sie haben also einfach vorausgesetzt, dass alle möglichen Computer für verschiedene Aktionen gleich lange brauchen würden. Dem ist aber nicht so, denn ein Intel Pentium 4 mit 1,4 GHz ist nun mal schneller als ein Intel Pentium 3 mit 600 MHz. D.h. dass der P4 in der gleichen Zeit viel mehr Anweisungen verarbeiten kann als sein Vorgänger, der P3. Das würde bedeuten, dass bei einem Netzwerkspiel, welches zwei Spieler gegeneinander spielen, wobei einer der Spieler einen P4 und der andere einen P3 hat, der P4 Spieler schneller schießen, schneller laufen und überhaupt alles schneller erledigen könnte als sein Gegner. Nicht besonders fair oder? Das Problem hier ist, wie zuvor kurz erwähnt: die Zeit, welche vergessen wurde. Die Lösung liegt darin, die Differenz zweier Zeitpunkte, nämlich zum einen am Anfang jeder Spiele-Schleife und zum anderen am Ende jeder Spiele-Schleife, zu bilden und in Sekunden umzurechnen. Diese Differenz muss dann nur noch mit jeder Aktion multipliziert werden und schon läuft auf beiden Maschinen das Spiel synchron. Hier ein kleines Code-Beispiel, wie so etwas aussehen könnte: time1 = (float) timeGetTime(); While(!done) { time += ((float) timeGetTime() – time) / 1000.0f; //Eingaben abfrage //Sonstige Berechnungen durchführen //Rendern Render(time); } Render(float time) { ball_position.x += ball_geschwindigkeit * time; } Der Ball, aus dem obigen Beispiel, würde auf jedem PC gleich schnell ‚rollen’, Gott-ZEITDank! Der Kern liegt also in der Zeit. Und genau dass gleiche Prinzip muss auch bei der Entwicklung von Echtzeit-Animationen angewendet werden, damit ein konstanter Animations-Fluss, unabhängig von Prozessorgeschwindigkeit, entsteht. Im Falle einer Echtzeit-Animation, welche in Abhängigkeit von einem Musikstück steht, wird die Zeit nicht berechnet sondern direkt aus der aktuellen Position innerhalb des Musikstückes ermittelt bzw. ausgelesen. Gibt es dann z.B. Sprünge in der Musik, aufgrund unvorhergesehener Prozessorbelastungen, entstehen auch synchrone Sprünge innerhalb der Animation, was dazu führt, dass sowohl Animation als auch die zugehörige Musik Synchron zueinander ablaufen! 4.0 OpenGL – Demo 4.1. Einleitung In diesem Kapitel werden wir die OpenGL-Demo, welche ebenfalls zu Testzwecken für X3D-Bildschirme entwickelt wurde, besprechen. Wir werden klären, was gemacht wurde, was beabsichtig war und welche Werkzeuge eingesetzt wurden. Anschließend widmen wir uns der Funktionsübersicht zu und schauen uns das Zusammenspiel zwischen den einzelnen Funktionen an, sowie den Aufbau der in der Demo verwendeten Szenen. 4.1.1. Was wurde gemacht? Es wurde eine 3D Echtzeit-Animation in der Programmiersprache C entwickelt, welche auf OpenGL basiert. Die Echtzeit-Animation läuft, wie der Name schon sagt, in Echtzeit ab. Grafiken, Positionen und Eingabemöglichkeiten werden während der Laufzeit berechnet. Die Animation besteht aus insgesamt drei unterschiedlichen Szenen. Im Gegensatz zur DirectX™-Demo läuft diese Demo nicht selbstständig ab, d.h. dass man zwischen den Szenen manuell wechseln muss (Tasten: F1 bis F3). 4.1.2. Was war geplant? Geplant waren ursprünglich fünf Szenen in die Demo aufzunehmen, zusammen mit einem passenden Musikstück. Die Gründe warum das nicht so geklappt hat wie geplant wurden bereits am Anfang dieser Dokumentation (unter WICHTIGER HINWEIS) erläutert. Auch bei dieser Demo stand der gesamte Ablauf bereits vor der Entwicklung fest, wurde aber währenddessen verfeinert und teilweise auch abgeändert. 4.1.3. Szenen-Überblick Im Gegensatz zur DirectX™-Demo läuft diese hier nicht selbstständig ab. D.h. dass der Betrachter die Szenen-Wechsel manuell durchführen muss. Dies geschieht über die Funktionstasten (F1 bis F3 für Szene 1 bis Szene 3). Leider ist aus der Demo nicht das geworden, was ich mir vorgestellt hatte. Ich hatte geplant eine Demo ganz im Stil der bereits besprochenen DirectX™-Demo zu programmieren. Der Grund warum dieses Vorhaben nicht umgesetzt werden konnte, habe ich ja bereits auf der ersten Seite dieser Dokumentation erläutert. Auch hier sind die Szenen vollkommen unabhängig voneinander aufgebaut. D.h. dass man die Szenen jederzeit auch in einer anderen Reihenfolge abspielen lassen kann. Es folgt nun ein grober Überblick jeder einzelnen Szene: Szene 1 Szene 2 Szene 3 In dieser Szene wird ein texturierter, rotierender Würfel dargestellt. Diese Szene zeigt eine im Wind wehende USA-Flagge. Der Wind wird geschickt simuliert, d.h. es finden keine tatsächlichen physikalischen Berechnungen statt. In dieser Szene werden mehrere, stufenförmig angeordnete, texturierte Würfel angezeigt. Diese Würfel rotieren ebenfalls, wodurch sich, nach einer gewissen Zeit, die Stufe von selbst aufbaut. 4.1.4. Verwendete Werkzeuge Für die Entwicklung dieser Demo wurde ebenfalls Microsofts(R) Visual Studio .NET eingesetzt. Benötigt werden außerdem noch zusätzlich die OpenGL-Bibliotheken, zusammen mit allen zugehörigen Header-Dateien. Das Einbinden der Bibliotheken und Header-Dateien erfolgt analog in der gleichen Art und Weise, wie es bereits für das DirectX-Demo Projekt beschrieben wurde. Deshalb möchte ich die einzelnen Schritte hier nicht noch mal erläutern. Bitte haben Sie dafür Verständnis. Die Projekt-Dateien finden Sie auf der beiliegenden CD-ROM im Ordner /OglAndX3D. Sie brauchen nur das OglAndX3D-Verzeichnis komplett auf die Festplatte zu kopieren und anschließend nur noch die Datei OglAndX3D.sln auszuführen. 4.3. Aufbau OpenGL - Demo 4.3.1. Funktionsübersicht Auch hier möchte ich nur die wichtigsten Funktionen kurz vorstellen, da eine komplette Funktionsbeschreibung bereits im Quellcode vorhanden ist. Das Zusammenspiel klären wir anschließend im nächsten Absatz. Die wohl wichtigste aller Funktionen ist die WinMain() - Funktion. Diese ist unser Haupteinstiegspunkt in das Programm. Hier werden alle notwendigen Initialisierungen durchgeführt, sowie die Animation gestartet als auch komplett kontrolliert. Hier werden auch alle Eingaben abgefangen und bearbeitet. Es gibt je eine Initialisierungsfunktion für jede Szene. In jeder einzelnen werden SzenenSpezifische Einstellungen vorgenommen. In diesen werden allerdings keinerlei Texturdaten geladen. Das Laden aller Texturen findet in der LoadTextures() – Funktion statt. Diese wird noch vor den einzelnen Initialisierungs–Funktionen aufgerufen. Das Rendern der einzelnen Szenen wird über die Funktionen DrawScene01(), DrawScene02() und DrawScene03() erledigt. 4.3.2. Das Zusammenspiel Das Hauptprogramm (OglAndX3D) erstellt zuerst ein Fenster. Anschließend werden alle Texturen geladen und alle Szenen initialisiert. Nachdem alles reibungslos von statten ging, wird die Demo – Schleife betreten. Diese wird so lange ausgeführt, bis der Benutzer die ESCTASTE drückt, wodurch die Demo komplett beendet wird. Hier eine grobe Übersicht über den Programmablauf (vereinfacht dargestellt): WinMain() { // OpenGL – Fenster erstellen CreateGLWindow(); // Alle Texturen laden LoadTextures(); // Alle Szenen initialisieren InitScene01(); InitScene02(); InitScene03(); // Die Lebenswichtige Schleife While(!done) { // Tastatur – Eingaben verarbeiten // Aktuelle Szene zeichnen – abhängig von Auswahl DrawScene01() ... DrawScene03(); } // Ende der Animation KillGLWindow(); } Innerhalb der Schleife werden Tastatur-Eingaben geprüft, und je nach aktueller Szenen-Wahl die entsprechende Szene gerendert. Es werden hierbei keinerlei Status-Informationen der einzelnen Szenen benötigt, da der selbst Benutzer entscheidet, welche Szene gerade abgespielt werden soll. 5. Aufwand Die folgenden Tabellen zeigen eine Übersicht über Aufwand in Bezug auf die einzelnen Projekt-Teile: Grundlagen Vertiefung Einarbeitung in die X3D-Systeme 8 Stunden 15 Stunden Entwicklung der DirectX™-Demo 6 Stunden Planung: Szenen-Aufbau 8 Stunden Planung: Ablauf 3 Stunden Planung: Logik 2 Stunden Modell-Entwicklung 15 Stunden Textur-Erstellung (Suche und Generierung) 98 Stunden Programmierung 12 Stunden Validierung Entwicklung der OpenGL-Demo 2 Stunden Planung: Szenen-Aufbau 1 Stunde Planung: Ablauf 2 Stunden Planung: Logik 8 Stunden Modell-Entwicklung 4 Stunden Textur-Erstellung (Suche und Generierung) 13 Stunden Programmierung 3 Stunden Validierung Gesamtaufwand 200 Stunden 6. Fazit Bisher gab es kein einziges Projekt an dem ich mehr Spaß und Interesse hatte wie bei diesem hier. Die Faszination dieser X3D-Systeme treibt mich sogar soweit, dass ich mir in naher Zukunft selbst einen solchen X3D-Bildschirm zulegen werde. Die Einarbeitung in die X3D-Systeme war sehr Zeitaufwendig aber auch äußerst Interessant. Ich hätte auch gerne noch weitaus mehr zu diesem Thema geschrieben, musste jedoch aufpassen, die maximal geforderte Anzahl an Seiten nicht zu überstrapazieren. Die Entwicklung der einzelnen Echtzeit-Animationen hat mir auch sehr viel Spaß gemacht, zumal ich selbst meine Freizeit mit der Programmierung von 3D-Anwendungen verbringe (Stichwort: ViperEngine). Leider muss ich zugeben, dass ich bei der OpenGL-Demo nicht den gewünschten Spaßfaktor erfahren durfte, da diese unter extremen Zeitdruck entstanden war und darüber hinaus nicht dass wurde, was ich mir gewünscht hatte. Ich selbst bin überzeugt davon, dass sich die X3D-Systeme in naher Zukunft durchsetzen werden. 3D-Fernsehen ist die Zukunft in Sachen Multimediale Unterhaltung. Wie lange das jedoch auf sich warten lassen wird steht im Moment noch in den Sternen. Den ersten größeren Einsatz dürften wir jedoch in der Spiele-Branche erwarten, und das nicht allzu ferner Zeit. 7. Quellen X3D-Informationen http://www.x3dworld.de http://www.opticalitycorporation.com/ http://www.more3d.com Schriftliches Zusatzmaterial in Englisch von Herrn Prof. Heinzel Texturen und Grafiken Planeten-Texturen: http://www.softwareburner.de/sonnensystem.htm Texturen für die Pistole in Scene06: http://www.circlesoft.org/pages.php?pg=home Andere Texturen: Teils selbst erstellt unter MS Paint Aus eigener Sammlung, welche aus downloads von diversen Internetseiten stattfand (legal und frei erhältlich). Die zu den einzelnen Texturen zugehörigen Internetseiten sind mir im einzelnen leider nicht mehr bekannt, da dies schon vor Jahren stattfand. Modelle Pistole: http://www.circlesoft.org/pages.php?pg=home Andere Modelle: Erstellt in Maya (sehr simple Objekte, ohne Modellierungsaufwand, da diese unter Maya z.T. schon als Template vorhanden sind). Exportiert in X-File durch frei verfügbares Plugin, welches im DirectX-SDK inbegriffen ist. Texturierung erfolgt innerhalb des Programmcodes! Musik Protoculture – More Directions Erhältlich unter www.scene.org. Steht aber mittlerweile nicht mehr auf dem Server zum download bereit! Zusätzlich verwendete Literatur (Buch/Internet): Bücher: 3D Spieleprogrammieung mit DirectX™ 9.0 OpenGL Bible Tricks of the 3D Game-Programming Gurus Windows Programmierung 3D-Grafik Internet: http://nehe.gamedev.net http://freespace.virgin.net/hugo.elias http://www.gamedev.net http://www.drunkenhyena.com http://www.codesampler.com/dx9src.htm http://www.cpp-home.com/index/tiki-view_blog.php?blogId=1
