X3D: Programmierung interaktiver 3D-Anwendungen für das Internet

Jörg H. Kloss

X3D

Programmierung interaktiver 3D-Anwendungen für das Internet

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Fast alle Hardware- und Softwarebezeichnungen und weitere Stichworte und sonstige Angaben, die in diesem Buch verwendet werden, sind als eingetragene Marken geschützt. Da es nicht möglich ist, in allen Fällen zeitnah zu ermitteln, ob ein Markenschutz besteht, wird das -Symbol in diesem Buch nicht verwendet.

®

Umwelthinweis: Dieses Buch wurde auf chlor- und säurefreiem PEFC-zertifiziertem Papier gedruckt. Um Rohstoffe zu sparen, haben wir auf Folienverpackung verzichtet. Alle Rechte vorbehalten. Kein Teil des Buches darf ohne Erlaubnis der Pearson Education Inc. in fotomechanischer oder elektronischer Form reproduziert oder gespeichert werden.

10 9 8 7 6 5 4 3 2 1 12 11 10

ISBN 978-3-8273-2829-8

© 2010 Addison-Wesley Verlag, ein Imprint der PEARSON EDUCATION DEUTSCHLAND GmbH, Martin-Kollar-Str. 10-12, 81829 München/Germany Alle Rechte vorbehalten Lektorat: Brigitte Bauer-Schiewek, [email protected] Korrektorat: Sandra Gottmann Fachlektorat: Arndt von Koenigsmarck Herstellung: Claudia Bäurle, [email protected] Satz: Reemers Publishing Services GmbH, Krefeld Einbandgestaltung: Marco Lindenbeck, webwo GmbH, [email protected] Druck und Verarbeitung: Kösel, Kempten (www.KoeselBuch.de) Printed in Germany

I NHALTSVERZEICHNIS Vorwort

1

Einleitung

5 Aufbau und Leseempfehlung Voraussetzungen Historie und aktuelle Version

Kapitel 1

X3D und XML

11

1.1

12 13 13 14 14 15 15 17 17 18 19 19 20 21 23 25

1.2

1.3

1.4

1.5

1.6

Kapitel 2

6 8 9

Basistechnologie XML 1.1.1 Kompatibilität und Interoperabilität 1.1.2 Metadaten Regelwerk zu X3D 1.2.1 Wohlgeformte Dokumente 1.2.2 Gültige Dokumente Die Sprache X3D und ihre DTD 1.3.1 Standarddeklaration in X3D 1.3.2 Einblick in die DTD Die Sprache X3D und ihre XSD 1.4.1 Erweiterte Standarddeklaration in X3D 1.4.2 Einblick in die XSD Debugging von X3D-Code 1.5.1 Fehlervermeidung 1.5.2 Fehlersuche durch Validierung Terminologie XML versus SDL

Der Baukasten X3D

27

2.1

28 28 30

Sprachmodule 2.1.1 Profile 2.1.2 Komponenten und Level

IV

INHALTSVERZEICHNIS

2.2

Kapitel 3

32 33 34

Architektur des Szenenaufbaus

37

3.1 3.2

38 40 41 43 45 46 47 48 49 50 52 54

3.3

3.4

Kapitel 4

2.1.3 Gesamtkonstrukt 2.1.4 Software-Unterstützung Nachschlagewerk X3D-Spezifikation

Dateikonzept und Szenengraph Spezifikation von Knoten 3.2.1 Generische Spezifikation 3.2.2 Enkodierung in XML Hello Virtual World 3.3.1 Worldbuilding im Datenbereich 3.3.2 Datei erstellen und starten Dateiformate und Enkodierungen 3.4.1 XML (.x3d) 3.4.2 ClassicVRML (.x3dv) 3.4.3 Binär (.x3db) und komprimiert (.x3db.gz) 3.4.4 Konvertierung

Objekte und Eigenschaften

57

4.1

58 58 60 61 61 62 63 63 65 67 68 70 71 73 77

4.2

4.3

Geometrische Primitive 4.1.1 Quader () 4.1.2 Kegel () 4.1.3 Zylinder () 4.1.4 Kugel () 4.1.5 Geschicktes Kombinieren Transformationen 4.2.1 Koordinatensysteme – die Welt von X3D 4.2.2 Translation 4.2.3 Rotation 4.2.4 Skalierung Oberflächeneigenschaften 4.3.1 Farbenzauber 4.3.2 Materialeigenschaften 4.3.3 Shading

INHALTSVERZEICHNIS

4.4

Kapitel 5

79 80 84

Modellierung von Objekten

87

5.1

88 90 91 93 95 98 101 101 104 107 108 114 118 126

5.2

5.3

Kapitel 6

Die Burg 4.4.1 Ausgangsszene 4.4.2 DEF und USE

V

Elementarteilchen 5.1.1 Punktwolken mit PointSet 5.1.2 Drahtgitter mit IndexedLineSet 5.1.3 Körper mit IndexedFaceSet 5.1.4 Dreieckige Polygone 5.1.5 Viereckige Polygone Zweidimensionales in 3D 5.2.1 2D-Geometrien 5.2.2 Text 3D-Generatoren 5.3.1 Extrusion 5.3.2 Höhengitter 5.3.3 NURBS 5.3.4 Die Burg: Mauern, Tor und Berge

Szenengestaltung

137

6.1

138 139 141 144 147 148 151 157 162 169 173 180 185

6.2

Beleuchtung 6.1.1 Distanzlicht 6.1.2 Punktlicht 6.1.3 Spotlicht Texturierung 6.2.1 Texturtypen 6.2.2 Texel-basiertes Mapping 6.2.3 Texture Mapping 6.2.4 Texturen positionieren, orientieren, skalieren und kacheln 6.2.5 Pixel-genaues Texturieren von Polygonen 6.2.6 Multitexturierung 6.2.7 Erstellen von Texturen 6.2.8 Die Burg: Details mit Texturen

VI

INHALTSVERZEICHNIS

6.3

6.4

Kapitel 7

191 192 199 201 201 204 210

Integration ins Web

213

7.1

215 217 219 222 222 225 231 238 239 243 245 248 252 254 258 262

7.2

7.3 7.4

7.5

Kapitel 8

Szenenumfeld 6.3.1 Hintergrundgestaltung 6.3.2 Nebel und andere Phänomene Benutzerführung und -hinweise 6.4.1 Aussichtspunkte setzen 6.4.2 Navigationseigenschaften des Avatars 6.4.3 Hintergrundinformationen

Hyperlinks mit Anchor 7.1.1 E-Mails aus der 3D-Welt 7.1.2 Voice-over-IP, Chats und Videokonferenzen Kombination von HTML und X3D 7.2.1 Wechselwirkung von X3D, HTML, XHTML und HTML5 7.2.2 Einbetten von X3D in Webpages 7.2.3 Das Frame-Konzept 7.2.4 Einbetten von X3D in Windows-Programme Verteilte Welten mit Inline Optimierung von Lauf- und Ladezeit 7.4.1 Billboards 7.4.2 Level of Detail Spracherweiterung mit Prototypen 7.5.1 Aufbau eines Prototypen 7.5.2 Einsatz von Prototypen 7.5.3 Prototypen in externen Bibliotheken

Audio und Video in 3D

265

8.1

266 267 270 273 276 277 278 281

8.2

Filmsequenzen integrieren 8.1.1 Videoformate 8.1.2 Animationsformate 8.1.3 Streaming-Formate Audiosequenzen und Toneffekte integrieren 8.2.1 Audioformate im AudioClip-Knoten 8.2.2 3D-Raumklang mit dem Sound-Knoten 8.2.3 Modellierung des akustischen Burgraums

INHALTSVERZEICHNIS

Kapitel 9

Animation und Interaktion

287

9.1

289 290 292 295 297 298 299 299 302 302 305 306 308 313 318 320 320 321 323 329 332 336 341

9.2

9.3

9.4

9.5

9.6

Kapitel 10

VII

Konzept und Elemente der Animation 9.1.1 Ereignisse, Zustände und Knotenschnittstellen 9.1.2 Keyframe-Animation, Interpolation und Taktgeber 9.1.3 Ereignissteuerung mit ROUTE Übersicht verfügbarer Interpolatoren 9.2.1 Spezialisierte lineare Interpolatoren 9.2.2 Optimierte nichtlineare Interpolatoren 9.2.3 Ereigniskaskaden, Fan-in und Fan-out Konzept und Elemente der Interaktion 9.3.1 Interaktion = Sensor + Animation 9.3.2 Ereignisvielfalt von Sensoren Übersicht verfügbarer Sensoren 9.4.1 Zeigegerät- und Bewegungssensoren 9.4.2 Umgebungssensoren 9.4.3 Head-up-Display (HUD) Objektzustände mit Behelfslogik 9.5.1 Trigger, Toggle und Filter 9.5.2 Diskrete Zustandsänderungen mit Sequenzern und Switch 9.5.3 Ein 3D-Katalogsystem Interaktives Burg-Erlebnis 9.6.1 Burgtor mit Entscheidungslogik 9.6.2 Aufzugfahrt mit Kamerabindung 9.6.3 Ego-Ausrüstung und Tastaturereignisse

Scripting und externe Programmierung

347

10.1

348 349 349 351 352 357 359 361 363

10.2

Sprachenvielfalt und Gemeinsamkeiten 10.1.1 EAI und SAI 10.1.2 Der Script-Knoten Scripting mit ECMAScript 10.2.1 Hello ECMAScript World 10.2.2 Externes und internes Scripting 10.2.3 Debugging von Skriptcode 10.2.4 Spezialfunktionen 10.2.5 Browser-Objekt mit vordefinierten Methoden

VIII

INHALTSVERZEICHNIS

10.3

10.4

10.5

10.6

Anhang A

10.2.6 Dynamischer Quellcode 10.2.7 Ein virtueller Baukasten Funktionale Skripte in der Burg-Szene 10.3.1 Unterhaltung mit Passwort und Cockpit 10.3.2 Reale Zeit auf virtueller Analoguhr Programmierung mit Java 10.4.1 Hello Java World 10.4.2 Debugging, Spezialfunktionen und die Browser-Klasse 10.4.3 Dynamische Codegenerierung Persistenz in virtuellen Welten 10.5.1 Besucherzähler mit Dateizugriff 10.5.2 Benutzerinteraktionen dauerhaft bewahren Multiuser-Welten 10.6.1 Architektur, Komponenten und Datenströme 10.6.2 Quasi-parallele Client-Server-Kommunikation 10.6.3 MU-Server-Komponenten 10.6.4 MU-Client-Komponenten 10.6.5 Setup und Bedienung des MU-Systems

367 368 374 377 385 390 392 398 401 404 405 412 420 422 427 429 435 446

Anhang

451

A.1

451 451 451 451 452 452 452 452 453 453

A.2

A.3 A.4 A.5

Stichwortverzeichnis

Auf der CD A.1.1 Tutorial-Dateien Interessante Links und Download-Adressen A.2.1 Allgemeines zu X3D A.2.2 X3D-Spezifikation A.2.3 X3D-Software A.2.4 Weitere Software-Tools Literatur Der Autor Glossar

455

VORWORT Der richtige Zeitpunkt für ein Buch zum Thema interaktiver 3D-Anwendungen ist immer auch relativ. Lange liegt der ursprüngliche Hype um Virtual Reality und Standards wie VRML Mitte der 1990er-Jahre zurück, auf den eine Zeit jenseits des Medienrummels folgte. Unbelastet von überzogenen Erwartungen hielt die interaktive 3D-Grafik seitdem auf immer leistungsfähiger werdenden Plattformen konsequent Einzug in die verschiedensten Anwendungsbereiche der Visualisierung und Simulation. Anfang des neuen Jahrtausends zog insbesondere ein einzelner richtungweisender Vertreter der wieder neu erfundenen Virtual Worlds erneut die geballte Aufmerksamkeit auf sich. Nach dem gesellschaftlichen und erstaunlich starken wirtschaftlichen Interesse folgte erneut eine Phase der tiefen Ernüchterung, die den Themenbereich in der öffentlichen Diskussion bis heute stark beeinflusst. Doch auch hier geht die Entwicklung im Hintergrund unbeirrt weiter, und die Etablierung immer neuer Virtual Worlds und Online-Games, 3D-Applikationen und -Filme sowie mobiler 3D-Schnittstellen und Augmented-Reality-Systeme weist auf eine erneute Phase der dauerhaften Konsolidierung verbunden mit dem Ausblick auf innovative Anwendungsfelder hin. Dabei wird das Rad nicht immer neu erfunden, sondern häufig auch Altbewährtes konsequent weiterentwickelt und auf immer neue Medien und Systeme kreativ und massenmarkttauglich übertragen. X3D ist ein prominenter Vertreter dieser Entwicklung, der nahezu den gesamten Bogen über die Höhen und Tiefen in der Geschichte interaktiver 3D-Umgebungen spannt. Hierbei haben der internationale ISO-Standard und seine Vorgängerversionen sowohl historische Bedeutung als Wegbereiter, einen festen Platz im

2

VORWORT

Bereich professioneller 3D-Applikationen als auch eine konsolidierende Rolle für die heute viel diskutierten Themen der Interoperabilität und Standardisierung verteilter 3D-Anwendungen im Internet und auf den daran angeschlossenen Software- und Hardware-Systemen. Das vorliegende Buch und der darin behandelte internationale 3D-Standard sind somit zugleich zeitlos als auch aktueller denn je. Als bewährte und etablierte Grundlage vieler professioneller 3D-Anwendungen spiegelt X3D die Geschichte, die Ansätze und die bisherige Entwicklung in diesem aufregenden Themenfeld wider, zeigt den State of the Art moderner 3D-Technologien auf und liefert als potenzieller Kandidat für zukünftige 3D-Anwendungsfelder schon heute fundierte Konzepte und Antworten für viele der aktuell diskutierten Problem- und Fragestellungen. Mit einem deutlichen Schwerpunkt auf den praktischen Einsatz des 3D-Standards liefert das vorliegende Buch das Wissen, die Mittel und viele Anregungen, eigene 3D-Applikationen zu entwickeln und direkte Erfahrungen mit den unterschiedlichen Aspekten der interaktiven 3D-Grafik zu sammeln. Dabei wird der Einsteiger im Bereich 3D-Grafik und/oder X3D im Rahmen eines umfangreichen Tutorials auf seinem Kenntnisstand abgeholt und bis zum fortgeschrittenen Worldbuilder entwickelt, der mit den Vorgängerversionen erfahrene VRML-Entwickler aufgrund der vielen Neuerungen von X3D auf den Geschmack gebracht sowie dem bisherigen Nutzer proprietärer 3D-Technologien die Vorteile und der in vielerlei Hinsicht profitable Umstieg zu einem offenen internationalen ISO-Standard im Kontext moderner Web-Technologien an vielen Beispielen aufgezeigt. Der vorgestellte Funktionsumfang von X3D bietet dabei für jeden Anwender etwas, sowohl dem ambitionierten 3D-Weltenbummler, dem grafikorientierten Gestalter, dem Animations- und Interaktionsdesigner als auch dem Programmierer von verteilten 3D-Applikationen. Es ist davon auszugehen, dass der Themenbereich interaktiver 3D-Anwendungen auf dem Internet noch weiter an Bedeutung gewinnen und schon bald ein fester Bestandteil der alltäglichen elektronischen Kommunikation sein wird. Welche Technologien, Anbieter oder Standards dabei letztlich beziehungsweise zu einem bestimmten Zeitpunkt das Rennen machen werden, wird die Zukunft zeigen. X3D und sein Vorgänger VRML haben bereits wichtige Fundamente geliefert und werden sicher auch künftig auf die eine oder andere Weise eine wichtige Rolle spielen. Mit diesem Buch soll dazu beigetragen werden, die Leser auf diese aufregende Zeit vorzubereiten und zu ermutigen, mit den erworbenen Kenntnissen an dieser Entwicklung teilzuhaben und diese eventuell sogar aktiv mitzugestalten. Denn der Erfolg einer neuen Technologie hängt vor allem von deren Akzeptanz sowie dem kreativen, zahlreichen und verantwortungsvollen Gebrauch und damit letztlich von uns Anwendern ab.

VORWORT

Danksagung Die Idee zu diesem Buch geht nicht zuletzt auf das frühere Werk „VRML97 – Der neue Standard für interaktive 3D-Welten im World Wide Web“ zurück, das 1998 ebenfalls bei Addison-Wesley erschienen ist. Hierbei möchte ich meinen damaligen Co-Autoren danken und insbesondere an Bob Rockwell erinnern, der auf visionäre und inspirierende Weise schon damals vieles von dem beschrieben hatte, was heute Gegenstand aktueller Diskussionen ist. Auch dem Pearson-Verlag und insbesondere meiner Lektorin, Frau Brigitte Bauer-Schiewek, danke ich für die Weitsicht und das erneute Vertrauen, dieses Thema zu diesem Zeitpunkt angenommen und unterstützt zu haben. Ebenso bedanke ich mich für die Unterstützung und die wertvollen Hinweise meines Fachlektors, Herrn Arndt von Koenigsmarck, die mich in diesem Projekt bestärkt haben. Selbst wenn es manchmal so schien, ist die Zeit auch während des Schreibens nicht stehen geblieben, und die Welt hat sich weitergedreht. Ich möchte vor allem an meinen Opa Oskar erinnern sowie an Albert und nach nunmehr zehn Jahren auch weiterhin an Curt. Mein Dank gilt meinen Eltern und meiner Schwester für all das Gute. Ganz besonders danke ich Alexandra für all das Schöne und den uneingeschränkten Rückhalt sowie ihrer Familie für die Rücksicht auch auf der Baustelle. Ebenso danke ich Maximilan und Benedikt für den frischen Wind und allen zusammen für die viele nötig gewesene Geduld.

Jörg H. Kloss

3

EINLEITUNG Der internationale ISO-Standard X3D ist ein mächtiges Werkzeug zur Beschreibung und Gestaltung dreidimensionaler Grafikobjekte und Szenen, die mit einem X3D-Viewer betrachtet und zwischen verschiedenen 3D-Programmen und über das Internet ausgetauscht werden können. Darüber hinaus umfasst die 3D-Beschreibungssprache effektive Mechanismen zur Definition und Umsetzung aufwendiger Animationen und komplexer Interaktionen mit Ansätzen einer elementaren Zustandslogik. Aufgrund des offenen Konzepts und der Kompatibilität zu anderen Standards im World Wide Web fügen sich X3D-basierte 3D-Umgebungen nahtlos in moderne multimediale Online-Systeme ein und integrieren ihrerseits etablierte Technologien wie Audio- und Video-Streaming oder auch Voice-over-IP. Die Möglichkeit der Erweiterung durch interne Skriptsprachen sowie die Schnittstellenprogrammierung mit externen Sprachen wie Java erlaubt zudem einen nahezu unbegrenzten Ausbau der Funktionalität und die unmittelbare Kopplung mit anderen Applikationen zu komplexen 3D-Systemen. Hierzu zählen aufwendige Visualisierungen und Simulationen genauso wie Virtual Worlds und andere Multiuser-Plattformen. In diesem Buch, das in Form eines Tutorials beziehungsweise Workshops aufgebaut ist, werden Sie an diese Themen und Anwendungsbereiche herangeführt, und das dabei erworbene Wissen können Sie an vielen lauffähigen Beispielen, aber auch an einer sukzessive ausgebauten virtuellen Welt konkret in die Praxis umsetzen. Dazu werden Sie als Leser auf Ihrem individuellen Kenntnisstand abgeholt, der Einsteiger sanft in den

6

EINLEITUNG

Umgang mit einer 3D-Szenenbeschreibungssprache eingeführt und dem bereits mit anderen 3D-Sprachen oder einer früheren VRML-Version vertrauten Umsteiger die Neuigkeiten, Besonderheiten und Vorteile der mächtigen XML-Basis aufgezeigt. Der Web-Designer bekommt zahlreiche praktische Tipps zur Integration von X3D mit weit verbreiteten Applikationen und aktuellen Online-Technologien geliefert, aufwendige Animations- und Interaktionskonzepte werden demonstriert und auch fortgeschrittene Themen zum Scripting mit ECMAScript bis hin zur professionellen Programmierung persistenter virtueller Welten werden abgedeckt. Wenn Sie das Tutorial vom ersten bis zum letzten Kapitel erfolgreich durchgearbeitet haben, sind Sie in der Lage, anspruchsvolle 3D-Anwendungen auf der Basis von X3D, zusätzlichen Sprachen und Applikationen sowie anhand Ihrer eigenen kreativen Ideen selbst zu entwickeln. Auch für den Fall, dass Fragen offen geblieben sein sollten oder sich bei Ihrer künftigen Arbeit als Worldbuilder neue ergeben, werden Ihnen die angegebenen Online-Quellen zu X3D helfen, detaillierte Informationen zu allen nur denkbaren Themen nachzuschlagen. Obwohl das Tutorial sequenziell aufgebaut ist, können Sie natürlich auch direkt mit einem für Sie besonders interessanten Kapitel beginnen und dann gegebenenfalls später auf die verwiesenen Grundlagenkapitel zurückgreifen.

Aufbau und Leseempfehlung Auch wenn Sie selbst am besten wissen, was für Ihren individuellen Kenntnisstand von Interesse ist, sind einige Kapitel für bestimmte Lesergruppen besonders geeignet und zu empfehlen. So sind die beiden einführenden Kapitel „X3D und XML“ und „Der Baukasten X3D“ nicht nur für Einsteiger interessant, sondern insbesondere auch für Umsteiger zu empfehlen, die die spezifischen Vorteile der Beschreibungssprache X3D, deren XML-Basis und die gegenüber VRML97 neu eingeführte Modularstruktur kennenlernen wollen. Wer diesen eher theoretischen Teil überspringen und sofort praktisch einsteigen möchte, findet im Kapitel „Architektur des Szenenaufbaus“ die obligatorische Einsteigerdatei „HelloWorld“ in allen mit X3D möglichen Dateiformaten beziehungsweise Enkodierungen. Ab dem Kapitel „Objekte und Eigenschaften“ werden Sie in die Aspekte der 3D-Modellierung mit X3D eingeführt und beginnen damit, eine virtuelle Burgszene als zentrales X3D-Beispiel sukzessive auf- und auszubauen. Dabei lernen Einsteiger anhand des demonstrierten Funktionsumfangs von X3D auch allgemeine Grundlagen der 3D-Modellierung und Szenengestaltung kennen, und Umsteiger finden in den Kapiteln „Modellierung von Objekten“ und „Szenengestaltung“ viele neue und mächtige Grafikfunktionen, wie NURBS und Multitexturierung, mit denen der 3D-Standard ergänzt wurde. Eine Sammlung nützlicher Integrationsmöglichkeiten von X3D in Websites und Windows-Applikationen, die Kombination mit etablierten Programmen zur Internet-Kommunikation über E-Mail, VoIP oder Chat sowie der Aufbau einer Bibliothek aus selbst entwickelten Prototypen im Kapitel „Integration ins Web“

EINLEITUNG

ermöglichen dem zusehends versierten 3D-Gestalter, das erworbene Wissen noch vielfältiger und effektiver einzusetzen. Wenn Sie sich bisher ausschließlich auf die 3D-Grafik konzentriert haben, zeigt Ihnen das Kapitel „Audio und Video in 3D“ die ergänzenden und immersiven Möglichkeiten der akustischen Raummodellierung auf und demonstriert zudem, wie einfach und vielfältig sich aktuelle multimediale Technologien wie Audio- und Video-Streaming in ansprechende X3D-Umgebungen integrieren lassen. Nachdem Sie sich mit den statischen Komponenten von X3D vertraut gemacht haben, führt Sie das Kapitel „Animation und Interaktion“ in das anspruchsvolle Thema der ereignisgesteuerten Animation und sensorgetriebenen Interaktion ein, auf dessen Grundlage Sie Ihre X3D-Szenen zu dynamischen virtuellen Welten ausbauen werden. Hierbei lernt der fortgeschrittene Einsteiger nicht nur die grundlegenden Mechanismen kennen, sondern setzt bereits anspruchsvolle Konzepte wie Head-up-Displays, 3D-Katalogsysteme und Elemente von 3D-Spielen in Egoperspektive praktisch um, die auch für den erfahrenen Animations- und Interaktionsdesigner interessante Möglichkeiten aufzeigen. Insbesondere der Umsteiger findet hier neue Konzepte und Elemente zur Abbildung von Objektzuständen mit Behelfslogik und zur Auswertung von Tastaturereignissen vor, die sich in den Vorgängerversionen von X3D lediglich mit Zusatzsprachen realisieren ließen. Eine umfangreiche Erweiterung der bis dahin aufgebauten Burgszene zu einer interaktiven Erlebniswelt verdeutlicht den unterschiedlich erfahrenen Lesergruppen das enorme Potenzial des internen Leistungsumfangs von X3D. Den fortgeschrittenen Lesern, die über den Sprachumfang von X3D hinausgehen möchten, zeigt das abschließende Kapitel „Scripting und externe Programmierung“ die herausfordernde Funktionserweiterung durch Zusatzsprachen auf. Dabei wird der versierte X3D-Entwickler an die grundlegenden Mechanismen und die zentrale Schnittstelle zwischen der 3D- und einer Zusatzsprache am Beispiel der einfach zu erlernenden Skriptsprache ECMAScript herangeführt und bis zu anspruchsvollen Konzepten der dynamischen Codegenerierung, der Umsetzung spielerischer Komponenten und der Nutzung von Systemdaten geleitet. Auf dieser Grundlage wird schließlich der letzte Schritt für den angehenden X3D-Profi vollzogen und in die Kopplung der 3D-Beschreibungssprache mit der Programmiersprache Java und damit entwickelten Anwendungen eingeführt. Im direkten Vergleich zu den Skriptbeispielen werden dabei selbst für den unerfahrenen Java-Programmierer die Gemeinsamkeiten und Unterschiede zwischen den beiden Zusatzsprachen und Ansätzen nachvollziehbar, sowie das enorme Potenzial dieser Kombination aufgrund ausgewählter Beispiele zum Dateizugriff und zur Persistenz in X3D-Welten greifbar. Die Programmierung eines eigenen Multiuser-Systems mit Java und X3D bildet schließlich den krönenden Abschluss dieser umfassenden Darstellung zum ISO-Standard X3D.

7

8

EINLEITUNG

Voraussetzungen Gemäß dem Grundsatz des Tutorials – vom Einsteiger zum Fortgeschrittenen – werden keine spezifischen Vorkenntnisse von Ihnen als Leser erwartet, da Sie in das Themengebiet interaktiver 3D-Grafik im Allgemeinen und mit X3D im Besonderen grundlegend eingeführt werden. Je nach Kenntnisstand können Sie sich an den oben genannten Empfehlungen zum Erarbeiten der Tutorial-Kapitel orientieren oder im Zweifelsfall das Buch vom ersten bis zum letzten Kapitel vollständig durcharbeiten, was grundsätzlich zu empfehlen ist. Damit stellen Sie sicher, dass Sie die in späteren Kapiteln gegebenenfalls vorausgesetzten Kenntnisse zu diesem Zeitpunkt dann auch wirklich aufweisen. Ein grundsätzliches Interesse an 3D-Grafik vorausgesetzt, benötigen Sie keine mathematischen Grundlagenkenntnisse zur Computergrafik, da die zugrunde liegenden hochkomplexen Berechnungen in Echtzeit vollständig von den X3D-Viewern übernommen und von der 3D-Beschreibungssprache abstrahiert werden. Ebenso werden keine Kenntnisse im Bereich der Metasprache XML oder einer der X3D-Vorgängerversionen von VRML vorausgesetzt, da X3D in der in diesem Buch vorwiegend verwendeten XML-Enkodierung durchaus auch ohne diese Grundlagenkenntnisse leicht verständlich, erlernbar und anwendbar ist. Obwohl X3D auch ein gängiges Austausch- und Ausgabeformat von professionellen Grafik- und Animationsprogrammen ist, werden derlei Entwicklungsumgebungen für das Tutorial nicht benötigt. Im Rahmen des Tutorials macht deren Einsatz auch wenig Sinn, da es ja gerade darum geht, die 3D-Beschreibungssprache zu erlernen und direkt anzuwenden. Natürlich hilft das Tutorial auch dabei, den von Entwicklungsumgebungen automatisch generierten X3D-Code im Nachhinein besser zu verstehen, auszubessern und mit Interaktionen und Skripten zu ergänzen. Sämtliche Beispiele und 3D-Welten im Tutorial werden jedoch ausschließlich von Hand beschrieben und entwickelt. Von daher reicht für die Erstellung der Beispielszenen ein einfacher Texteditor aus, der Bestandteil eines jeden Betriebssystems ist, wie beispielsweise Notepad unter Microsoft Windows. Um die teilweise längeren Quelltexte jedoch besser überschauen zu können, ist ein Editor hilfreich, der die Syntax von X3D kennt und die strukturierten Sprachelemente optisch hervorhebt. Erlaubt dieser zudem die Prüfung auf Wohlgeformtheit und Gültigkeit einer XML-basierten X3D-Datei, kommt dieser einer integrierten Entwicklungsumgebung gleich, wie sie für Programmiersprachen üblich ist. Um die entwickelten X3D-Dateien betrachten zu können, wird ein X3D-Viewer benötigt, der die eingesetzten Sprachmodule und Komponenten unterstützt, wobei die Leistungsmerkmale zwischen den unterschiedlichen Systemen durchaus voneinander abweichen können. Zur Anzeige der im Tutorial beschriebenen Beispieldateien und zur Erstellung der abgebildeten Screenshots wurden die beiden X3D-Viewer BS Contact und Octaga Player eingesetzt, wobei viele weitere X3D-Viewer alternativ online verfügbar sind. Mit einem Editor und einem entsprechend leistungsfähigen X3D-Viewer sind Sie somit also bereits vollständig ausgerüstet, die Beispiele im Tutorial auszuführen und eigene

EINLEITUNG

X3D-Szenen zu entwickeln. Hervorzuheben ist, dass die benötigten Komponenten für die nichtkommerzielle Nutzung unter Einhaltung der Nutzungsbestimmungen in der Regel kostenlos zum Download bereitstehen. Insofern können Sie sich Ihre Grundausstattung online unter folgenden Adressen mit den jeweils aktuellsten SoftwareVersionen zusammenstellen. • X3D-Edit: Entwicklungsumgebung mit Syntax-Highlighting für X3D, ClassicVRML, ECMAScript und Java. Integrierter X3D-Viewer Xj3D. Debugging von XML-Code auf Wohlgeformtheit und Gültigkeit sowie Konvertierung zwischen verschiedenen X3D-Enkodierungen und vieles mehr. Download unter (gegebenenfalls Zertifikat akzeptieren): https://savage.nps.edu/X3D-Edit/ • BS Contact: X3D-Viewer von Bitmanagement Software GmbH. Download einer Testversion unter: http://www.bitmanagement.com/ • Octaga Player: X3D-Viewer von Octaga. Download unter: http://www.octaga.com/ Nutzen Sie gegebenenfalls die angebotenen Hinweise und Dokumentationen der einzelnen Software-Produkte zu deren Verwendung, Bedienung und Installation. Wo es für die Inhalte des Tutorials sinnvoll ist, werden wir Ihnen einzelne Funktionen auch in den entsprechenden Kapiteln vorstellen und näher erläutern. Natürlich steht es Ihnen frei, auch andere Tools einzusetzen. Nutzen Sie die Freiheit eines internationalen Standards, nicht an spezifische Hersteller gebunden zu sein und die Möglichkeit der Wahl zu haben. Wenn Sie das Tutorial und die vielen Beispiele nicht bloß theoretisch durchlesen, sondern auch ausprobieren und aktiv nachvollziehen wollen, sollten Sie zumindest einen X3D-Viewer auf Ihrem Rechner installiert haben. Neben der Möglichkeit, die Beispieldateien auch direkt von dem beiliegenden Datenträger zu starten, können Sie die zumeist vollständig abgedruckten oder sukzessive erweiterten Quelltexte auch selbst in einem Editor eingeben. Hierfür können Sie auf den Texteditor Ihres Betriebssystems oder aber auf das empfehlenswerte X3D-Edit zurückgreifen. Mit dem X3D-Viewer und dem Editor Ihrer Wahl sind Sie nun also bereit für die große Entdeckungstour „X3D“.

Historie und aktuelle Version Die Beschreibungssprache X3D geht zurück auf die Virtual Reality Modelling Language (VRML), die bereits auf der ersten Konferenz des World Wide Web Consortium (W3C) im März 1994 unter Tim-Berners Lee initiiert und basierend auf der 3D-Beschreibungssprache OpenInventor des damaligen Branchenprimus Silicon Graphics Incorporated zur zweiten W3C-Konferenz im Oktober 1994 als VRML 1.0 offiziell präsentiert wurde. Mit dem Ziel, die bis dahin rein statischen Konzepte vor allem um dynamische Elemente der Animation, Interaktion und mit Skripten zu ergänzen, entwickelten die vom damaligen VRML Consortium gesteuerten Arbeitsgruppen das 3D-Format weiter. Im August 1996 präsentierten sie die neue Version VRML 2.0, die nach gerin-

9

10

EINLEITUNG

gen Überarbeitungen und einem aufwendigen Antragsverfahren Ende 1997 von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) unter dem Eintrag ISO/IEC 14772 mit der Bezeichnung VRML97 standardisiert wurde. Nach dem Platzen der Internet-Blase und dem darauf folgenden Rückzug vieler Firmen als treibende Kraft für die Weiterentwicklung des Standards wurde es vorübergehend ruhiger um das Thema virtuelle Welten im Web und somit auch um VRML97. Auch die Bemühungen, den mächtigen und dadurch recht umfangreich gewordenen Standard unter dem Arbeitstitel VRML-Lite auf wenige Kernfunktionen zu reduzieren, konnten nichts an der Tatsache ändern, dass die durchschnittliche Bandbreite und Rechnerleistung der damaligen Web-User einer angemessenen Nutzung virtueller Welten noch nicht gewachsen waren. Mit dem explosionsartigen Erfolg des Web und der ungebrochenen Leistungssteigerung heimischer Infrastruktur verbesserte sich die Basis für anspruchsvolle Online3D-Welten jedoch bis heute ungebremst und ist längst auf einem beeindruckend hohen Niveau angekommen. Nicht zuletzt aus diesem Grund erlebten gerade die so genannten Virtual Worlds vor wenigen Jahren eine beeindruckende Renaissance beziehungsweise eine bis dahin unvergleichlich starke private und kommerzielle Nutzung, die trotz nachgelassenem Medieninteresse weiterhin ungebremst voranschreitet. Um der zeitgleich aufgekommenen Informationsüberflutung im Web entgegenzuwirken, forciert das W3C seit Jahren die strukturierte Informationsaufbereitung durch den Einsatz der eXtensible Markup Language (XML). Zahlreiche themenspezifische aber auch etablierte Datenaustauschformate wurden seither in die erweiterbare Auszeichnungssprache XML übertragen, so auch VRML97. Neben der Übertragung auf XML wurde der 3D-Standard von dem zwischenzeitlich umbenannten Web3D Consortium unter dem Arbeitstitel VRML-NG (Next Generation) zudem strukturell vollständig überarbeitet und in Profile unterteilt, die einen auf unterschiedlich anspruchsvolle Anwendungen und leistungsfähige Endgeräte abgestimmten Einsatz des 3D-Formats ermöglichen. Im Dezember 2004 wurde die Beschreibungssprache eXtensible 3D (X3D) als internationaler Standard ISO/IEC 19775 anerkannt. Um immer neue modulare Funktionen der interaktiven 3D-Echtzeitgrafik erweitert, folgte im November 2005 die Version X3D V3.0, im Dezember 2006 die Version X3D V3.1 und im Juni 2008 die aktuelle Version X3D V3.2, an deren Weiterentwicklung auch weiterhin im Rahmen der Arbeitsgruppen des Web3D Consortium gearbeitet wird.

1 X3D UND XML X3D ist eine Sprache zur Beschreibung von 3D-Szenen, deren Konzept und Format in hohem Maße mit der Historie, den Anforderungen und den zukünftigen Entwicklungen des Internets verknüpft ist. Im Rahmen seiner Entstehungsgeschichte entwickelte sich der Vorläufer von X3D nahezu zeitgleich mit dem Aufkommen des World Wide Web und der Auszeichnungssprache HTML (Hypertext Markup Language), was unter anderem Einfluss auf die Gestaltung von VRML als Beschreibungssprache im Klartextformat hatte. Ebenso wie HTML im Textumfeld sollte auch die 3D-Beschreibungssprache möglichst vielen Anforderungen genügen und dabei anwendungs- und herstellerneutral bleiben. So ist es nur konsequent, dass auch VRML auf der Basis des universellen Beschreibungsformats XML zu X3D weiterentwickelt wurde, ähnlich wie HTML zu XHTML. Hieraus resultieren zusätzliche Vorteile, die die Rolle des ISO-Standards X3D als universellem 3D-Datenformat für das Internet weiter festigen.

12

Kapitel 1

XML lohnt sich.

Trotz des theoretisch anmutenden Schwerpunkts dieses Kapitels steht der praktische Nutzen für Sie als Entwickler von 3D-Umgebungen – als sogenannter Worldbuilder – im Vordergrund. Mit dem Wissen über die Aspekte und Vorteile der XML-Basis können Sie das Potenzial des ISO-Standards X3D zur Erfüllung Ihrer Anforderungen noch besser einschätzen. Ebenso werden Sie in die Lage versetzt, über das vorliegende Buch hinaus die vorhandenen und zukünftigen X3D-Ressourcen im Internet für Ihre eigenen Projekte zu nutzen, indem Sie unmittelbar auf die Sprachdefinition, neue Funktionsmodule des Web3D Consortium oder unabhängige XML-Tools zurückgreifen können. Denn eines ist schon heute klar, die Arbeiten und Themen der Working Groups im Web3D und W3C Consortium sowie die Entwicklungen des gesamten Technologiebereichs von 3D-Grafik, Internet und virtuellen Welten sind noch längst nicht abgeschlossen.

1.1

Basistechnologie XML

X3D ist eine XML-Sprache.

Beginnen wir unser X3D-Tutorium also mit dem „X“, bevor wir uns dem „3D“ zuwenden. Auch wenn Sie für Ihre Arbeit mit der Sprache eXtensible3D (kurz X3D) nicht zwangsläufig ein tiefes Verständnis von XML benötigen, sollten Sie doch mit einigen Begrifflichkeiten vertraut sein. Denn schließlich ist X3D vollständig auf der Basis von XML verfasst und somit ein sogenanntes XML-Derivat.

Elemente und Attribute

Die eXtensible Markup Language (kurz XML) ist eine erweiterbare Auszeichnungssprache zur Repräsentation hierarchisch strukturierter Daten in Textform, die zwischen Computersystemen in Netzwerken ausgetauscht werden. In ihrer Funktion als standardisierte Metasprache wird XML dazu verwendet, weitere in der Regel anwendungsspezifische Auszeichnungssprachen zu definieren, die ähnlich funktionieren wie HTML. Hierzu werden Elemente (markiert durch Tags) und Attribute mit erlaubten Wertzuweisungen definiert, deren Verwendung und inhaltliche Verschachtelung durch strukturelle Einschränkungen in Form einer separaten Grammatik festgelegt sind. Zur Formulierung der Grammatiken stehen Schemasprachen wie DTD und XML-Schema zur Verfügung. Neben der Prüfung auf Wohlgeformtheit nach dem allgemeinen XMLRegelwerk können die XML-Sprachen zusätzlich anhand ihrer Grammatiken auf ihre spezifische Gültigkeit validiert werden. Die in XML-Dokumenten enthaltenen Daten werden durch Parser ausgelesen und anwendungsspezifisch zur Weiterverarbeitung bereitgestellt.

Beispiele für andere XML-Sprachen

Seit der Veröffentlichung der ersten XML-Spezifikation (Recommendation) im Februar 1998 durch das World Wide Web Consortium (W3C) wurden zahlreiche XMLDerivate von verschiedenen Institutionen, Branchen und sonstigen Interessensgemeinschaften entwickelt und eingeführt. Prominente Beispiele für XML-Sprachen sind XHTML, WML (Wireless Markup Language), RDF (Resource Description Framework), GML (Geography Markup Language), GPX (GPS Exchange Format), SMIL (Synchronized Multimedia Integration Language), SyncML (Synchronization Markup

X3D UND XML

13

Language), KML (Keyhole Markup Language für Google Earth), SVG (Scalable Vector Graphics), Collada (Collaborative Design Activity) und neben vielen weiteren auch das vom Web3D Consortium verantwortete X3D.

1.1.1

Kompatibilität und Interoperabilität

Aufgrund ihrer gemeinsamen Basis sind XML-Sprachen in einem hohen Maße miteinander interoperabel. Dadurch stehen für die XML-Sprachen zentrale XML-Tools zur Verfügung. So lassen sich mittels XSLT-Prozessoren (Extensible Stylesheet Language Translator) Dokumente von einer XML-Sprache in eine andere XML-Sprache übersetzen und die darin enthaltenen Daten je nach Bedarf unterschiedlich verwenden oder darstellen. Ebenso sind zentrale Ansätze von XML Security auf alle Sprachen gleichermaßen anwendbar. Auch die Kombination von XML-Sprachen in gemeinsamen Dokumenten ist vorgesehen, indem mehrere Namensräume in eine XML-Datei importiert werden.

Gemeinsame Tools und kombinierte Anwendungen

Trotz ihrer inhaltlichen Unterschiede fügen sich die XML-Sprachen somit nahtlos aneinander und integrieren sich ebenso in das permanent mit neuen Diensten und Anwendungen erweiterte Internet. Die Online-Systeme, die auf ein XML-basiertes Datenaustauschformat setzen, erfüllen damit bereits ein elementares Kriterium für ihre Kompatibilität und die Interoperabilität ihrer Datenbasis. Von diesen Vorteilen profitieren auch die mit X3D entwickelten 3D-Welten und letztendlich auch Sie als Anwender dieser XML-Sprache.

Interoperable 3D-Welten

1.1.2

Metadaten

Ein weiteres wichtiges Merkmal von XML-Dateien ist, dass diese optional weiterführende Informationen über sich selbst oder die beabsichtigte Verwendung als sogenannte Metadaten enthalten können. Dabei können die Metadaten beispielsweise frei formulierte Beschreibungen zum Inhalt der Datei, zum Verfasser, prägnante Stichwörter oder aber auch konkrete Anweisungen für die Suchroboter von Suchmaschinen umfassen. In der Regel werden die Metadaten beim Abrufen des XML-Dokuments nicht angezeigt, sondern stehen lediglich im Quelltext der Datei zur optionalen Verarbeitung zur Verfügung.

Beschreiben Sie Ihre 3D-Szenen.

Entsprechend lassen sich auch X3D-Dateien mit Metainformationen versehen. Die Angabe von Metadaten erfolgt im Kopfbereich (engl. Header) einer XML-Datei, der durch den Tag gekennzeichnet ist. Die einzelnen Metadaten werden jeweils innerhalb eines Elements meta und über dessen Attribute name und content festgehalten, wie im folgenden Beispiel gezeigt. Nebenbei sei angemerkt, dass die den Attributen zugewiesenen Werte entweder in doppelten („filename“) oder einfachen (‚author‘) Anführungszeichen stehen können.

Metadaten im X3D-Header

14

Kapitel 1



Durch das Potenzial der XML-Basis erhalten Ihre X3D-Dateien damit auch Anschluss an einen weiteren, essenziellen Trend im Internet. Auf der Suche nach der Antwort auf die explodierende Datenmenge (Information Overload) im Internet setzte das W3C schon frühzeitig seine Hoffnungen und Anstrengungen auf die Entwicklung von XML. Auf der Basis des einheitlichen Datenformats sollen sämtliche Informationen im Internet eine gemeinsame Struktur erhalten, die leichter maschinell zu verarbeiten ist und zukünftig sogar semantisch analysiert werden kann. Je nach dem Erfolg der ebenfalls XML-basierten Ansätze, wie die Web Ontology Language (OWL) und das Resource Description Framework (RDF), ist X3D somit also auch bereits für die zukünftigen Anforderungen des als Semantic Web oder Web 3.0 bezeichneten Internet gerüstet. Eine gute Investition also, als Worldbuilder auf X3D zu setzen.

1.2

Regelwerk zu X3D

Grundsätzlich besteht ein XML-konformes Dokument aus Elementen, Attributen, deren Wertzuweisungen und dem Inhalt der Elemente, der aus Text oder wiederum aus untergeordneten Elementen bestehen kann. Das Regelwerk von X3D als XML-Derivat setzt sich aus den allgemeinen XML-Regeln und der spezifischen X3D-Grammatik zusammen. Die XML-Regeln gelten für alle XML-Derivate gleichermaßen, während mit der Grammatik die einzelnen Strukturelemente, deren Verschachtelungsregeln sowie die Attribute mit ihren zugelassenen Wertzuweisungen sprach- und themenspezifisch festgelegt sind.

1.2.1 Ein wohlgeformtes X3DDokument erfüllt die XML-Regeln.

Wohlgeformte Dokumente

Anhand der XML-Regeln lässt sich ein X3D-Dokument auf seine Wohlgeformtheit überprüfen. Zu den Kriterien der Wohlgeformtheit gehören unter anderen folgende Aspekte: • Am Beginn des Dokuments steht der Bezug auf die verwendete XML-Deklaration. • Das Dokument besitzt genau ein Wurzelelement, das alle anderen Elemente enthält. • Alle Elemente mit einem Inhalt besitzen ein Start- und ein End-Tag (Beispiel: Inhalt). Leere Elemente ohne einen Inhalt können auch in sich geschlossen sein und nur aus einem Empty Element-Tag bestehen (Beispiel: ). • Ein Element darf nicht mehrere Attribute mit gleichem Namen besitzen.

X3D UND XML

15

Weitere Informationen zu XML-Regeln

Eine Übersicht und weitere Hintergründe zu den XML-Regeln finden Sie im Allgemeinen auf den Seiten des W3C unter www.w3.org oder im Speziellen in der W3C Recommendation unter http://www.w3.org/TR/2000/REC-xml-20001006. Zur Verdeutlichung zeigt das folgende Beispiel ein wohlgeformtes XML-Dokument einer fiktiven XML-Sprache aus der Automobilbranche, das die oben genannten XMLRegeln erfüllt: Benziner Umweltfreundlich

Eine inhaltliche Beschränkung in der Verwendung der Elemente, der Zuteilung von Inhalten oder in der Häufigkeit des Vorkommens von untergeordneten Elementen ist durch die XML-Regeln jedoch nicht gegeben. So können dem Auto aus dem obigen Beispiel mehrere Motoren oder beliebige Emissionswerte zugeordnet werden, was in der Realität nur wenig Sinn macht. Entsprechend ist das obige Beispieldokument lediglich wohlgeformt, aber nicht gültig.

1.2.2

Gültige Dokumente

Seine Gültigkeit erhält ein XML-Dokument erst dadurch, dass es wohlgeformt ist und zusätzlich auf eine Grammatik verweist, deren Regeln es erfüllt. Die in der Grammatik definierten Regeln sind üblicherweise auf ein spezifisches Fachgebiet oder einen Anwendungsbereich bezogen und spiegeln vor allem dessen inhaltliche Strukturen und Anforderungen wider. Basierend auf einem generischen Regelwerk können XMLDokumente so zusätzlich auf themenspezifische Kriterien und deren Erfüllung mit einem validierenden Parser geprüft werden.

1.3

Ein gültiges X3D-Dokument erfüllt zusätzlich die Regeln seiner Grammatik.

Die Sprache X3D und ihre DTD

Eine gängige Schemasprache zur Beschreibung der themenspezifischen Regeln ist die Document Type Definition (Abk. DTD). In einer eigenen Syntax wird mit der DTD die Grammatik in Form von erlaubten Elementen, Attributen und Verschachtelungsmöglichkeiten festgelegt. Obwohl die Dokumenttyp-Deklaration in der Regel über den Verweis auf eine externe DTD erfolgt, ist alternativ auch eine Definition der DTDRegeln innerhalb des XML-Dokuments möglich. Das folgende Beispiel zeigt eine gültige und vollständige XML-Datei und greift zur Verdeutlichung erneut auf den Kontext der oben genannten Automobilbranche zurück.

Ein Klassiker der Schemasprachen: die DTD

16

Kapitel 1

]> Benziner Umweltfreundlich

Auf die obligatorische XML-Deklaration in der Kopfzeile der XML-Datei folgt im obigen Beispiel die Dokumenttyp-Deklaration in Form von dateiintern definierten DTDRegeln. Die Definition des Dokumenttyps auto umfasst das gleichnamige Wurzelelement auto, dem zwei weitere Elemente motor und emission hierarchisch untergeordnet sind und die jeweils nur einmal innerhalb von auto verwendet werden dürfen. In dem darauffolgenden Datenbereich werden innerhalb des Start- und End-Tags des Wurzelelements auto die beiden untergeordneten Elemente motor und emission regelkonform genau einmal verwendet, und ihnen wird jeweils ein beliebiger Text zugewiesen. Die einschränkenden Regeln zur einmaligen Verwendung der Eigenschaften „Motor“ und „Emission“ pro Auto werden dadurch den spezifischen Anforderungen der Automobilbranche gerecht. Exkurs

Eine XML-Datei besteht grundsätzlich aus drei aufeinanderfolgenden Abschnitten: 1. XML-Deklaration: Obligatorische Kopfzeile mit Bezug auf die verwendete XML-Version in spitzen Klammern mit flankierenden Fragezeichen (). Optional zwei weitere Attribute: verwendete Zeichenkodierung (Beispiel: encoding="UTF-8" für internationale Kodierung auf Basis der ISO/IEC-10646-Norm mit mindestens 8 Bit Zeichenbreite) und Ja-/NeinAttribut, ob die zugehörige DTD intern oder extern deklariert ist (Beispiel: standalone="yes"). 2. Dokumenttyp-Deklaration: Zweite Zeile mit Bezug auf die verwendete DTD innerhalb von . Bei interner DTD folgt Name des Dokumenttyps, der mit dem Wurzelelement identisch sein muss, mit anschließender Definition der DTD in eckigen Klammern (Beispiel siehe DTD „auto“). Bei externer DTD folgen Name und Referenz auf den expliziten Speicherort (SYSTEM) oder kombiniert auf den impliziten (PUBLIC) öffentlichen Bezeichner (Beispiel: ).

3. Datenbereich: Hier werden – regelkonform – die eigentlichen Daten festgelegt, Elemente ausgewählt und kombiniert sowie Attributen Werte zugewiesen. In diesem Bereich findet Ihre eigentliche Arbeit als Worldbuilder mit X3D statt.

X3D UND XML

17

Auch wenn das Automobil-Beispiel nur ansatzweise und auf sehr einfache Weise die Wirkungsweise und Beziehung zwischen XML-Dokumenten und ihrer Grammatik darstellt, spiegelt es den elementaren Mechanismus wider, der auch der XML-Sprache X3D und ihrer ungleich komplexeren Grammatik zugrunde liegt. Die Übertragung der umfassenden X3D-Spezifikation in das Regelwerk einer XML-Definition ist schon alleine aufgrund der Komplexität eine Meisterleistung des Web3D Consortium, die gar nicht hoch genug bewertet werden kann.

1.3.1

Standarddeklaration in X3D

Da Sie als Worldbuilder in der Regel ausschließlich im Datenbereich einer X3D-Datei tätig sein werden, wird sich Ihr Umgang mit der XML- und der Dokumenttyp-Deklaration in der Praxis voraussichtlich auf das Copy and Paste der Standarddeklarationen beschränken. Der Deklarationsteil einer üblichen X3D-Datei schaut dabei in der Regel folgendermaßen aus:

Eine Standarddeklaration für Ihre X3D-Dateien



Wie zu erwarten war, wird die umfangreiche DTD für den Dokumenttyp X3D außerhalb der X3D-Datei definiert. Die Referenz auf die DTD erfolgt implizit (PUBLIC) über den öffentlichen Bezeichner „ISO//Web3D//DTD X3D 3.0//EN“. Dieser Bezeichner (Public Identifier) besteht aus drei Teilen: den Angaben zur veröffentlichenden Institution (ISO//Web3D), dem Namen und der Version der DTD (DTD X3D 3.0) sowie der Sprache der verwendeten Elemente und Attribute (EN), jeweils getrennt durch einen DoppelSlash (//). Für den Fall, dass die Zuordnung über den Bezeichner einmal nicht funktionieren sollte, wird alternativ auf den konkreten Speicherort des DTD-Dokuments x3d-3.0.dtd über dessen URL (Uniform Resource Locator) verwiesen. Adressen der X3D-DTD

Eine Übersicht zu den aktuell verfügbaren DTD für X3D finden Sie auf den Seiten des Web3D Consortium unter http://www.web3d.org/x3d/specifications. Über den Pfad http://www.web3d.org/specifications/x3d-3.2.dtd greifen Sie direkt auf die jeweilige Referenz-DTD zu, in diesem Fall auf die X3D-DTD Version 3.2.

1.3.2

Einblick in die DTD

Bei Interesse können Sie einfach mal einen Blick in die DTD für X3D werfen. Die gängigen Web-Browser (Mozilla Firefox, Microsoft Internet Explorer etc.) zeigen die DTD-Dateien im Klartext an. Auch wenn wir die DTD-Syntax in diesem Kapitel nur gestreift haben, werden Sie sich selbst in der komplexen X3D-DTD grob orientieren können. Suchen Sie beispielsweise einmal nach der Definition des X3D-Elements

Ein Blick in die X3D-DTD

18

Kapitel 1

„Box“ (ein grafischer Quader). Ohne an dieser Stelle auf die Details eingehen zu wollen, können Sie im folgenden Auszug aus der X3D-DTD erkennen, dass das Element Box über die zwei Attribute size und solid verfügt, denen jeweils ein bestimmter Datentyp und Default-Wert zugeordnet ist.

Sollten Sie also beim Worldbuilding einmal dieses Buch nicht zur Hand haben und nicht mehr wissen, welche Attribute und Defaultwerte ein bestimmtes Element hat, können Sie alternativ auch direkt in der X3D-DTD nachschauen.

1.4

Die Sprache X3D und ihre XSD

Modern und mächtiger: die XSD

Neben der X3D-DTD wurde die X3D-Grammatik auch in der Schemasprache XMLSchema als sogenannte XML-Schema-Definition (Abk. XSD) definiert. XSD ist moderner als die DTD und bietet gegenüber dieser eine Reihe von Vorteilen und zusätzliche Funktionalitäten. Zum Zeitpunkt als die Schemasprache DTD gemeinsam mit XML standardisiert wurde, lag der Fokus von XML vor allem auf der Repräsentation und Verarbeitung von Textinformationen. Die Funktion als Datenaustauschformat stand noch deutlich im Hintergrund, und die Werte von Attributen wurden pauschal als einfache Textstrings (PCDATA) behandelt. Von daher ist es in der DTD beispielsweise nicht möglich, zwischen Texten und Zahlen zu unterscheiden und somit die Verwendung von Datentypen einzuschränken beziehungsweise auf Korrektheit zu prüfen.

Vorteile der XSD gegenüber der DTD

Eine XSD ist selbst in XML verfasst, eine zusätzliche Syntax für die Grammatik wie bei der DTD wird also nicht mehr benötigt. Hierdurch lassen sich auch XML-Tools auf ein XSD-Dokument anwenden, um beispielsweise dessen Wohlgeformtheit zu prüfen. Außerdem ermöglicht die Flexibilität von XML die Beschreibung ungleich komplexerer inhaltlicher Zusammenhänge, als dies mit der formalen Syntax von DTD möglich ist. Einer der wichtigsten Vorteile von XSD ist jedoch, dass zwischen Zahlen, Datumsangaben, Texten oder sonstigen Datentypen unterschieden werden kann, dadurch genauere Vorgaben und Einschränkungen definierbar sind und sich weitergehende Prüfungskriterien für die Gültigkeit eines XML-Dokuments ergeben.

Namensräume

Neu ist auch das Konzept der Namensräume (engl. Namespaces), durch das innerhalb eines Dokuments mehrere XML-Sprachen verwendet werden können, selbst wenn diese Elemente mit gleichem Namen enthalten. Hierzu werden die Elementnamen durch ein Präfix mit Doppelpunkt eindeutig zugeordnet und an den Namensraum einer bestimmten XML-Sprache gebunden (ähnlich den Vorwahlen bei Telefonnummern).

X3D UND XML

1.4.1

19

Erweiterte Standarddeklaration in X3D

Um die Vorteile von XSD zu nutzen, wurden die Regeln von X3D zusätzlich als XMLSchema beschrieben. X3D-Dateien können damit optional gegen eine der beiden oder auch gegen beide Grammatiken auf Gültigkeit geprüft werden. Für die Angabe beider Grammatiken im Deklarationsbereich einer X3D-Datei spricht, dass noch nicht alle Parser die neuere XSD unterstützen und somit immer auch auf die etablierte DTD zurückgreifen können. Die Referenz auf die XSD erfolgt im Wertebereich des Wurzelelements, im Falle einer X3D-Datei also innerhalb des obligatorischen Start-Tags X3D. Das X3D-Tag folgt dabei unmittelbar auf die XML-Deklaration beziehungsweise auf die optionale Dokumenttyp-Deklaration. Das folgende Beispiel ergänzt den oben genannten Deklarationsteil einer typischen X3D-Datei um die Referenz auf die immer extern definierte X3D-XSD.

Die erweiterte Standarddeklaration für Ihre X3DDateien



Auf den Namen des Start-Tags X3D folgt das Attribut version, in dem die Versionsnummer der tatsächlich referenzierten XSD-Datei angegeben werden muss. In der zweiten Zeile wird dem Parser über die Zuweisung eines Namespace (xmlns) mitgeteilt, dass für dieses XML-Dokument eine XSD mit dem angegebenen URI (Uniform Resource Identifier) existiert. Der konkrete Speicherort dieser XSD wird schließlich in der dritten Zeile über das Attribut xsd:noNamespaceSchemaLocation angegeben. Adressen der X3D-XSD

Eine Übersicht zu den aktuell verfügbaren XSD für X3D finden Sie auf den Seiten des Web3D Consortium unter http://www.web3d.org/x3d/specifications. Über den Pfad http://www.web3d.org/specifications/x3d-3.2.xsd greifen Sie direkt auf die jeweilige Referenz-XSD zu, in diesem Fall auf die X3D-XSD Version 3.2.

1.4.2

Einblick in die XSD

Der Vollständigkeit halber wollen wir auch einen Blick in die XSD für X3D werfen. Auch diese lässt sich wie jede andere XML-Datei mit den gängigen Web-Browsern betrachten. Die Definition des X3D-Elements „Box“ fällt hier etwas umfangreicher aus, aber die Definition der beiden Attribute size und solid ist ebenfalls gut zu erkennen.

Ein Blick in die X3D-XSD

20

Kapitel 1

… …

Sämtlichen Elementen ist hier zusätzlich explizit das Präfix für den Standardnamensraum einer XSD beziehungsweise eines XML-Schemas (xs:) vorangestellt. Ansonsten handelt es sich um gewöhnlichen XML-Code, wie Sie ihn bereits aus dem obigen Automobil-Beispiel kennen. Sie haben sich damit eine weitere Quelle zum Nachschlagen der X3D-Elemente und ihrer Attribute erschlossen, falls Ihnen dieses Buch beim Worldbuilding einmal nicht vorliegen sollte.

1.5

Debugging von X3D-Code

Fehleranalyse im Quelltext

Neben den vielen oben genannten Vorteilen soll ein weiterer praktischer Mehrwert für Ihre tägliche Arbeit als Worldbuilder mit X3D hervorgehoben werden, der ebenfalls auf der XML-Basis beruht. Da Ihre X3D-Dateien auf Wohlgeformtheit und Gültigkeit geprüft werden können, steht Ihnen damit auch eine mächtige Methodik zur Suche, Diagnose und Behebung von Fehlern im Quelltext zur Verfügung, ähnlich dem Debugging (Fehleranalyse) bei der Programmierung.

Kleine Fehler mit großer Wirkung

Dies ist umso wichtiger, als dass viele der verfügbaren X3D-Viewer die unerfreuliche Eigenschaft besitzen, vor allem bei syntaktischen Fehlern im Quelltext statt inkorrekter oder unvollständiger 3D-Szenen lediglich ein leeres 3D-Anzeigefenster anzuzeigen. Ein Hinweis auf die Fehlerursache durch Sichtkontrolle wird damit unmöglich. Und ein solches Fehlerverhalten tritt oftmals dann schon auf, wenn beispielsweise lediglich ein End-Tag vergessen oder falsch geschrieben wurde oder aber nur eine einzige schließende spitze Klammer an irgendeiner Stelle fehlt. Der Blick in den Quellcode ist dann in der Regel die einzige Möglichkeit, nach dem Fehler zu suchen und diesen zu beheben. Eine Möglichkeit, die dank des für Menschen lesbaren Klartextformats der X3D-Beschreibungssprache besteht. Fehler im X3D-Quelltext können bei allen Methoden des Worldbuildings auftreten: wenn Sie Ihre 3D-Szene in einem 3D-Grafikprogramm erstellen und im X3D-Daten-

X3D UND XML

21

format exportieren, wenn Sie diese in einem grafischen Autorensystem per Drag and Drop aus X3D-Elementen zusammenklicken, in einem Texteditor einzelne Funktionen beispielsweise zur Animation oder Interaktion nachträglich ergänzen oder aber Ihre virtuelle Welt komplett von Hand in einem Texteditor erstellen. Nicht selten kommt es vor, dass der X3D-Quellcode dann mehrere Hundert Zeilen umfasst und die Fehlersuche darin ohne Hilfsmittel zu einer reinen Sisyphosarbeit ausartet: einen potenziellen Fehler im Quelltext korrigieren, Datei speichern, im Viewer starten, bei weiterhin leerem Fenster wieder zurück zum Quelltext, die Korrektur wieder rückgängig machen, den nächsten potenziellen Fehler suchen und so weiter.

1.5.1

Fehlervermeidung

Am besten ist es natürlich, Fehler im Quelltext von vornherein in der Erstellungsphase zu vermeiden. Was sich anhört wie eine Binsenweisheit, ist ein durchaus gängiges Ziel von sogenannten Integrierten Entwicklungsumgebungen (Integrated Development Environment, IDE), wie sie bei der Programmentwicklung mit entsprechenden Programmiersprachen üblich sind. Auch für die Arbeit mit der Beschreibungssprache X3D ist eine IDE hilfreich, wann immer Sie den Quelltext einer X3D-Datei im Klartext editieren.

Eine IDE kann helfen

Auch das Java-basierte und damit weitestgehend plattformunabhängige Autorenwerkzeug X3D-Edit entspricht einer IDE und umfasst unter anderem einen Editor mit vielen hilfreichen Funktionen, die die Bearbeitung des X3D-Quelltexts erleichtern. Bereits beim Anlegen einer neuen X3D-Datei (Menü: File  New X3D  New X3D scene) schlägt der Editor automatisch das Grundgerüst für ein gültiges X3D-Dokument mit allen notwendigen Deklarationen und einer ganzen Reihe von optionalen Anmerkungsfeldern (Meta-Elementen) vor, wie in Abbildung 1.1 dargestellt.

Arbeiten im Quelltext mit X3D-Edit

ABBILDUNG 1.1 Vorgeschlagenes X3DDateigerüst im IDE-Editor von X3D-Edit

22

Kapitel 1

Syntax Highlighting

Durch die Verwendung verschiedener Schriftfarben (Syntax Highlighting) im Editor von X3D-Edit wird die syntaktische Funktion der einzelnen Textpassagen hervorgehoben, die Zusammengehörigkeit optisch kenntlich gemacht und damit die Übersichtlichkeit des gesamten Quelltexts insgesamt verbessert. So werden XML-Schlüsselbegriffe (Beispiel: ?xml, !DOCTYPE X3D PUBLIC etc.) der XML- und DokumenttypDeklaration dunkelblau (und zusätzlich im Fettdruck), Elementnamen inklusive öffnender und schließender spitzer Klammer hellblau, Attributnamen grün, Attributwerte schwarz und Kommentare hellgrau dargestellt. Sollten Sie also beispielsweise einmal vergessen, einen Kommentar ordnungsgemäß mit --> zu beenden, wird der gesamte nachfolgende Text in Hellgrau erscheinen, was Sie sehr schnell auf den Fehler aufmerksam machen wird. Auch ungültige Notationen, wie Schreibfehler bei Elementnamen, werden Ihnen unmittelbar beim Eintippen auffallen, wenn eine andere als die erwartete Farbe erscheint.

Kontextsensitive Auswahl von Attributen

Daneben leistet Ihnen X3D-Edit aktive Hilfestellung beim Tippen des Quelltexts, indem es Ihnen während der Eingabe der Elementeigenschaften die an der aktuellen Stelle möglichen und syntaktisch korrekten Attribute in einer Auswahlliste vorschlägt (siehe Abbildung 1.2). Das ausgewählte Attribut wird dann vollständig in den Quelltext übernommen, und Sie müssen nur noch den gewünschten Attributwert zwischen den hochgestellten – einfachen oder doppelten – Anführungszeichen eingeben.

ABBILDUNG 1.2 Kontextsensitive Vorschläge für die Auswahl korrekter Attribute in X3D-Elementen

Auch die Verschachtelung vieler verschiedener Elemente über mehrere Hierarchiestufen hinweg kann einen Quelltext schnell unübersichtlich erscheinen lassen. Deshalb ist es grundsätzlich wichtig, dass Sie als Worldbuilder für Ordnung in Ihrem Quelltext

X3D UND XML

23

sorgen, indem Sie die Hierarchiestufen durch Einrückungen (mittels Leerzeichen) optisch erkennbar machen. Zur Orientierung markiert X3D-Edit zusätzlich das passende (öffnende oder schließende) Gegenstück zu dem XML-Tag, den Sie gerade im Editor angeklickt haben (siehe auch das Element Transform in Abbildung 1.2), mit gelber Farbe. So lassen sich schnell vergessene End-Tags oder falsche Verschachtelungen beim Editieren aufspüren.

1.5.2

Fehlersuche durch Validierung

Sind die Eingaben oder Änderungen im Quelltext abgeschlossen oder hatten Sie zuvor ein leeres 3D-Fenster im X3D-Viewer angezeigt bekommen, sollten Sie sich eine der Kerneigenschaften von X3D als XML-Sprache zunutze machen: die Prüfung Ihrer X3D-Datei auf Wohlgeformtheit und Gültigkeit. Wenn beide Prüfungen mit Erfolg abgeschlossen sind, haben Sie eine gute Chance, dass Ihre Datei im X3D-Viewer auch zu einer grafischen Darstellung führt (ob diese dann Ihren Vorstellungen entspricht, ist eine andere Frage, der wir uns erst später in diesem Buch widmen werden). Der im Autorenwerkzeug X3D-Edit integrierte Parser wertet die im Editor angezeigte Datei entsprechend aus. Hierbei wird sowohl die Einhaltung der allgemeinen XML-Regeln geprüft als auch gegen die referenzierten X3D-Grammatiken DTD und XSD validiert.

Ist die Datei wohlgeformt und gültig?

Die Prüfung auf Wohlgeformtheit kann über das Menü (X3D  Quality Assurance  Check XML), den in der Toolbar verfügbaren Schalter mit dem Tooltipp „Check XML“ oder alternativ per Tastaturkürzel (Alt) (F9) ausgelöst werden (siehe Abbildung 1.3). ABBILDUNG 1.3 Prüfung auf Wohlgeformtheit einer X3DDatei mit X3D-Edit

24

Kapitel 1

Die Abbildung 1.3 zeigt das Ergebnis einer Prüfung auf Wohlgeformtheit mit negativem Ergebnis. In der X3D-Datei wurde im End-Tag der Buchstabe „m“ vergessen (Zeile rot markiert), sodass dem Start-Tag das passende Gegenstück fehlt. Im Fensterbereich unterhalb des Editors mit der Bezeichnung „Output – XML check“ wird die Fehlerursache entsprechend beschrieben und auf die fehlerhafte Zeile im Quelltext verwiesen. Es ist nun ein Leichtes für Sie als Worldbuilder, das Problem durch Ergänzung des fehlenden Buchstabens zu beheben. Die Validierung gegen die X3D-Grammatiken kann ebenfalls über das Menü (X3D  Quality Assurance  Validate XML), den in der Toolbar verfügbaren Schalter mit dem Tooltipp „Validate XML“ oder alternativ per Tastaturkürzel (Alt) (Umschalt) (F9) ausgelöst werden (siehe Abbildung 1.4). ABBILDUNG 1.4 Validierung der Gültigkeit einer X3D-Datei in X3D-Edit

Auch im Quelltext der X3D-Datei in Abbildung 1.4 hat sich ein Fehler eingeschlichen. Die Wertzuweisung für das Attribut diffuseColor im Element Material ist falsch, da der korrekte Datentyp drei statt der angegebenen zwei Zahlenwerte umfassen muss (korrektes Beispiel: ‚1 0 0‘). Während die Prüfung auf Wohlgeformtheit diesen Fehler noch durchgehen lässt (die XML-Regeln sind erfüllt), hat die Validierung gegen die X3D-XSD den falschen Datentyp erkannt. Die Fehlerursache wird auch hier im unteren Fensterbereich „Output – XML check“ beschrieben und die fehlerhafte Zeile im Quelltext rot markiert. Die Korrektur des Fehlers sollte für Sie als Worldbuilder nun auch kein Problem mehr darstellen.

X3D UND XML

25

Abschließend noch zwei weitere Tipps zur Fehlersuche. In X3D-Edit können Sie sich auch eine Zeilennummerierung über das Menü „View – Show Line Numbers“ anzeigen lassen. Diese hilft Ihnen, bei längeren Quelltexten die mit einer Zeilenangabe versehenen Fehlermeldungen schneller im Quelltext zuzuordnen. Auch X3D-Viewer zeigen in der Regel die Nummer der fehlerhaften Codezeile(n) an, wenn das Laden einer X3D-Datei scheitert. Für die Anzeige der Fehler stellen viele X3D-Viewer eine sogenannte Console zur Verfügung, die Sie beispielsweise im X3D-Viewer BS Contact unter dem Menüpunkt „View – Console“ aufrufen können. Beim Auftreten des Fehlers aus Abbildung 1.3 zeigt die Console des X3D-Viewers nach einem gescheiterten Ladeversuch der Datei Demo.x3d die Fehlermeldung aus Abbildung 1.5 an. ABBILDUNG 1.5 Fehlermeldung in der Console des X3D-Viewers beim Fehler aus Abbildung 1.3

Mit dem erworbenen Wissen über XML als Basis für X3D haben Sie eine wichtige Grundlage geschaffen, die Syntax von X3D besser zu verstehen und mit dieser im Rahmen Ihrer Arbeit als Worldbuilder umzugehen. Sie kennen nun bereits die Standarddeklarationen einer X3D-Datei und sind in der Lage, direkt in die X3D-Grammatiken zu schauen und Details zu einzelnen X3D-Elementen und ihren Attributen nachzuschlagen. Mit dem Wissen über Wohlgeformtheit und Gültigkeit erfüllen Sie die Voraussetzung, fehlerfreie X3D-Dateien zu erstellen. Und sollten später doch einmal Probleme bei der Anzeige Ihrer X3D-Dateien auftreten, kennen Sie die Tools und Methoden, etwaige Fehler im Quelltext aufzuspüren und zu beheben. Eine ideale Ausgangsposition, die 3D-Beschreibungssprache X3D und ihre beeindruckende Funktionsvielfalt in den folgenden Kapiteln kennenzulernen.

1.6

Terminologie XML versus SDL

Zum Abschluss dieses Grundlagen-Kapitels zur XML-Basis ist es an der Zeit, im X3DTutorium den Schritt vom „X“ zum „3D“ zu vollziehen. Während wir X3D bislang aus dem Blickwinkel einer XML-Sprache betrachtet und ausschließlich die entsprechende XML-Terminologie verwendet haben, werden wir bei der weiteren Erarbeitung der funktionalen Leistungsmerkmale der 3D-Beschreibungssprache fortan die fachspezifische Nomenklatur von X3D verwenden. Dieses Vorgehen deckt sich mit dem

26

Kapitel 1

allgemeinen Sprachgebrauch sowohl in der X3D-Entwicklergemeinde als auch im allgemeinen Kontext der 3D-Branche. Aus Sicht der X3D-Spezifikation ist das XMLFormat (lediglich) eine – von mehreren möglichen – Enkodierungen des spezifizierten Leistungsumfangs und der funktionalen Struktur des ISO-Standards X3D. Im Kern ist und bleibt X3D konzeptionell eine Sprache zur Beschreibung von 3D-Szenen wie auch schon der Vorgänger VRML97. Als sogenannte Szenenbeschreibungssprache (Scene Description Language, SDL) verfügt X3D über eine eigene Nomenklatur, deren Unterschied für unser Verständnis an dieser Stelle lediglich in einer abweichenden Bezeichnung für die bisher gebrauchten XML-Begriffe gemäß Tabelle 1.1 besteht. TABELLE 1.1 Unterschiede in der Terminologie von XML und X3D

XML

X3D (SDL)

Element

Knoten

Attribut

Feld

Um etwaige Verwirrungen zu vermeiden, merken Sie sich einfach die folgende Faustregel. Wenn wir fortan die Begriffe „Knoten“ und „Felder“ verwenden, sprechen wir über die Einheiten und Eigenschaften der Szenenbeschreibungssprache X3D, von „Elementen“ und „Attributen“ werden wir nur noch reden, wenn wir XML-spezifische Aspekte betonen wollen. In den folgenden Kapiteln werden Sie mehr über den generischen Leistungsumfang der X3D-Spezifikation sowie über die konkreten Enkodierungen des Standards und deren Gebrauch erfahren.

2 DER BAUKASTEN X3D Die Beschreibungssprache X3D stellt ein umfangreiches Arsenal an Funktionen rund um das Themengebiet 3D-Grafik, Animation, Interaktion und virtuelle Welten auf dem Web bereit. Im Laufe der Entwicklungsgeschichte wurden die Leistungsmerkmale des ISO-Standards von den elementaren Eigenschaften zur Modellierung statischer 3D-Szenen auf dynamische und interaktive Konzepte sowie immer anspruchsvollere Darstellungstechniken für virtuelle Welten ausgedehnt. Heute umfasst X3D zusätzlich zahlreiche Erweiterungen für spezielle 3D-Anwendungsbereiche (CAD, GIS, MPEG-4 etc.) und wird damit neben der Grundfunktion als Beschreibungssprache in hohem Maße auch der Rolle als standardisiertes Datenformat zum Austausch zwischen den zusehends vernetzten fachspezifischen Applikationen gerecht. Der Baukasten für Ihre Arbeit als Worldbuilder ist also reichlich gefüllt. Umso wichtiger, dass Sie einen strukturierten Überblick über die verfügbaren Bausteine erhalten und sich diesen auch zukünftig bewahren. Denn gutes Worldbuilding umfasst auch die angemessene Auswahl und die passende Kombination der geeigneten Funktionen, die X3D für Ihre Projekte, Ihren individuellen Anwendungsfokus und die von Ihnen anvisierte Zielgruppe bereithält. Das Wissen über die Strukturierung der X3D-Spezifikation werden Sie aber auch aus technischer Sicht für die korrekte Deklaration Ihrer X3DDateien benötigen. Und da die Zeit nicht stillsteht und die 3D-Grafik immer mehr Anwendungsbereiche erobert, werden sich auch zukünftig immer wieder neue Funktionen in den

28

Kapitel 2

systematisch geordneten Sprachumfang von X3D eingliedern, entwickelt und betreut von den Working Groups im Web3D Consortium.

2.1

Sprachmodule

Ohne eine gute Sortierung wird ein Baukasten schnell unübersichtlich. Um dem entgegenzuwirken, wurde der gesamte Sprachumfang im Rahmen der Standardisierung von X3D systematisch in überschaubare und thematisch zusammengehörige Module unterteilt. Aus den Erfahrungen mit dem weniger gut strukturierten X3D-Vorgänger VRML97 hatten die Working Groups zudem die Erkenntnis gewonnen, dass nicht alle Elemente einer so mächtigen Beschreibungssprache für jede Art von Anwendung benötigt werden und das Alles-oder-Nichts-Prinzip den Erfolg und die Verbreitung eines 3D-Standards erschweren kann. Auch wenn sich die infrastrukturellen Voraussetzungen für den massenhaften Einsatz aufwendiger 3D-Systeme durch immer leistungsfähigere und gleichzeitig preiswertere Computer, Grafikkarten und InternetBreitbandanbindungen erheblich verbessert haben, wird auch in der näheren Zukunft ein maßvoller Umgang mit den Ressourcen wichtig bleiben. Vorteile der Modularisierung

Die modulare Unterteilung bietet viele praktische Vorteile für den Umgang mit der mächtigen 3D-Beschreibungssprache. Für Sie als Worldbuilder bieten die thematischen Entsprechungen der Module eine gute Orientierung bei der Auswahl der benötigten Funktionen aus der Fülle der verfügbaren Leistungsmerkmale. Im Rahmen der Weiterentwicklung der X3D-Spezifikation durch das Web3D Consortium lassen sich zudem neue Leistungsmerkmale innerhalb bestehender oder aber als zusätzliche Module ergänzen, ohne dass dafür jedes Mal die gesamte Spezifikation mit einer neuen Versionsnummer verabschiedet oder gar dem ISO-Standardisierungsprozess zugeführt werden muss. Durch die Option zur selektiven Implementierung einzelner Module werden zudem die Software-Hersteller in die Lage versetzt, ihre X3D-Applikationen anwendungsoptimiert, kompakter und folglich ökonomischer zu produzieren, ohne dabei auf die Konformität zum ISO-Standard und die Kompatibilität zu gleichartigen Anwendungen verzichten zu müssen. Von einem großen Angebot an verfügbarer X3DSoftware profitieren schließlich auch die X3D-User, also das Publikum Ihrer 3D-Welten, und letztendlich der gesamte Technologiebereich.

2.1.1 1. Ebene: Profile

Profile

Bei den Modulen werden Profile, Komponenten und Level unterschieden. Auf der ersten beziehungsweise höchsten Gliederungsebene wird der gesamte X3D-Sprachumfang in sogenannte Profile (engl. Profile) eingeteilt, die für einen bestimmten Funktionsumfang stehen und in deren Rahmen die Kompatibilität und Interoperabilität zwischen X3D-Anwendungen bereits grob festgelegt sind. Hierarchisch angeordnet, umfasst das jeweils höher gestellte Profil den Leistungsumfang aller untergeordneten

DER BAUKASTEN X3D

29

Profile und erfordert damit auch den größeren Aufwand in der Implementierung. In Abbildung 2.1 ist die hierarchische Einbettung der fünf Basisprofile von X3D grafisch dargestellt.

Full Immersive

ABBILDUNG 2.1 Die fünf Basisprofile von X3D

üüüüü Interchange Core

Das innerste Profil in Abbildung 2.1 mit der Bezeichnung Core bildet den Kern und damit den kleinsten gemeinsamen Nenner aller X3D-Implementierungen. Es stellt lediglich elementare Grundfunktionen bereit, wie beispielsweise den ROUTE-Mechanismus oder die Angaben für Metadaten, aber noch keinerlei grafische Funktionen. Ein X3D-Viewer, der lediglich das Core-Profil implementiert hätte, wäre zwar sehr kompakt, könnte jedoch auch nur die Metadaten einer X3D-Datei verarbeiten und würde von daher kaum die Bezeichnung „Viewer“ verdienen.

Das zentrale Profil Core

Unmittelbar aufbauend auf dem Core folgt das Basisprofil Interchange, das alle wesentlichen Funktionen und Komponenten zur Gestaltung und für den Austausch geometrischer 3D-Modelle inklusive Materialien, Texturen, Beleuchtung und Animation umfasst. Das Profil Interactive ergänzt Interchange um Elemente der Interaktion, wie beispielsweise Sensoren. Im Profil Immersive ist der gesamte Leistungsumfang von VRML97 inklusive Audio, Umgebungseffekten und Scripting enthalten, ergänzt um neue Komponenten wie 2D-Geometrien und weitere Event-Mechanismen. Das Profil Full entspricht der maximalen Implementierung von X3D und umfasst damit auch die fortgeschrittenen Bereiche wie beispielsweise NURBS (Non-Uniform Rational B-Spline) zur ultrarealistischen Freiformmodellierung, H-Anim (Humanoid Animation) zur Gestaltung natürlicher Bewegungsabläufe von Avataren oder GeoSpatial zur Umsetzung realer Geodaten in 3D-Terrains.

Die Basisprofile Interchange, Interactive, Immersive und Full

Neben den Basisprofilen umfasst der X3D-Standard derzeit noch zwei zusätzliche Spezialprofile. Das Profil CADInterchange zielt dabei vor allem auf die Rolle als Datenaustauschformat für CAD-Applikationen (Computer Aided Design) ab und integriert die in diesem Kontext benötigten X3D-Komponenten in Anlehnung an das Basisprofil Interchange. Das Profil MPEG-4Interactive umfasst dagegen nahezu alle Komponenten des Basis-Profils Interactive und dient damit vor allem als Grundlage für die Implementierung der 3D- und Interaktionskonzepte des Multimediastandards MPEG-4

Die Spezialprofile MPEG-4 Interactive und CADInterchange

30

Kapitel 2

nach ISO/IEC 14496. Auch wenn der AV-Standard MPEG-4 allgemein eher für seine Audio- und Videokompression bekannt ist, umfasst dieser in seiner objektbasierten Auslegung auch Konzepte für die Interaktion mit den kombinierten 2D- und 3D-Komponenten eines binären Mediastreams. Das binäre MPEG-4-Szenenbeschreibungsformat BIFS (Binary Format for Scenes) beziehungsweise dessen XML-Entsprechung XMT-A (Extensible MPEG-4 Textual Format) integrieren dabei Komponenten von VRML97 beziehungsweise X3D in den MPEG-4-Szenengraphen. Das X3D-Profil MPEG-4Interactive fasst die dafür benötigten Komponenten entsprechend zusammen. Profilangabe in der X3D-Datei

Die Information darüber, welches Profil eine X3D-Applikation implementiert haben muss, um eine X3D-Datei angemessen darstellen zu können, trägt die Datei in sich selbst. Innerhalb des Start-Tags des Wurzelelements X3D wird über das Attribut profile das erforderliche Profil explizit angegeben (Beispiel profile=“Immersive“). Der bereits im Kapitel zu den XML-Grundlagen vorgestellte Deklarationsbereich einer X3D-Datei wird also entsprechend erweitert, wie das folgende Beispiel zeigt.

Für die Entwicklung einer exakt auf die Bedürfnisse und Ressourcen einer Applikation abgestimmten X3D-Szene kann die Auswahl eines bestimmten Profils jedoch zu grob sein. Hierfür werden dann weitere Details in der Auswahl einzelner Funktionsbereiche benötigt.

2.1.2 2. Ebene: Komponenten

Komponenten und Level

Die Vielfalt der einzelnen Funktionsbereiche des X3D-Sprachumfangs wird in Form von sogenannten Komponenten (engl. Component) abgebildet, die die Module der zweiten Gliederungsebene bilden. Jedes Profil setzt sich entsprechend aus einer bestimmten Menge von Komponenten zusammen, wobei jedes hierarchisch höher angeordnete Profil alle Komponenten des untergeordneten Profils mit einschließt. Die Komponenten umfassen die einzelnen Knoten eines bestimmten funktionalen Themenbereichs von X3D, wie beispielsweise die Basisgeometrien Quader, Kegel, Zylinder und Kugel als Bestandteile der Komponente „Geometry3D“. Um das Korsett der Profile ein wenig aufzulockern und den Einsatz der Komponenten flexibler zu gestalten, ohne dabei die modulare Struktur und die darauf basierende Interoperabilität zwischen den X3D-Anwendungen aufzugeben, lassen sich einzelne Komponenten bei Bedarf auch außerhalb ihres Profils verwenden. Dies macht dann Sinn, wenn beispielsweise für ein X3D-basiertes Geoinformationssystem (GIS) lediglich die spezielle Funktionalität der Komponente „Geospatial“ aus dem Full-Profil

DER BAUKASTEN X3D

31

benötigt wird, ansonsten aber die Komponenten des Profils Interchange ausreichen. Damit das GIS nun nicht alle der zahlreichen und aufwendigen Komponenten des Full-Profils implementieren muss, lässt sich in der GIS-kompatiblen X3D-Datei zusätzlich zum Interchange-Profil die einzelne Komponente Geospatial deklarieren. In manchen Fällen sind selbst die einzelnen Knoten in den Komponenten so aufwendig zu implementieren, dass es Sinn macht, auch die Komponenten weiter zu unterteilen. Als Module der dritten Gliederungsebene werden dann innerhalb der Komponenten sogenannte Ebenen (engl. Level) unterschieden, die hierarchisch die einzelnen Knoten zusammenfassen. Eine Ebene lässt sich dann zusätzlich zu einer Komponente angeben, wenn nicht die gesamte Komponente mit allen Knoten, sondern lediglich die Knoten einer bestimmten Ebene dieser Komponente implementiert sein müssen. So kann eine X3D-Datei beispielsweise nur die vier Basisgeometrien Quader, Kegel, Zylinder und Kugel (Level 1) der Komponente Geometry3D benötigen, auf deren weitaus komplexeren Geometrieknoten IndexedFaceSet (Level 2), ElevationGrid (Level 3) und Extrusion (Level 4) aber verzichten (siehe auch Tabelle 2.2).

3. Ebene: Level

Die Angabe einer oder mehrerer Komponenten und Level ist optional. Im Bedarfsfall werden diese am Anfang einer X3D-Datei im Quelltext aufgeführt, unmittelbar folgend auf die Deklarationen und das Start-Tag X3D. Im Header-Bereich der Datei, zwischen dem Start- und End-Tag , können über das Element component und das Attribut name die Komponente sowie über das Attribut level der Level explizit angegeben werden. Der folgende Auszug aus dem Quelltext einer X3D-Datei zeigt exemplarisch den vollständigen Deklarationsteil zusammen mit den Angaben zu den verschiedenen Komponenten und ihrem Level.

Angabe von Komponenten und Knoten im Header der X3D-Datei



Da im Profil Interchange die Komponente Geospatial überhaupt nicht, die Komponente Geometry3D nur bis Level 2 und die Komponente Lighting nur bis Level 1 enthalten ist, wird im oben gezeigten Beispielcode explizit auf die jeweils zu ergänzenden Komponenten beziehungsweise Level verwiesen.

Kapitel 2

32

2.1.3

Gesamtkonstrukt

Bei der Vielzahl an Profilen, Komponenten, Level und deren Kombinationsmöglichkeiten ist es für Sie als Worldbuilder wichtig, die Übersicht zu behalten. Natürlich können Sie bei Ihrer Arbeit auch großzügig mit den Ressourcen umgehen und immer ein Profil wählen, das Ihre Anforderungen sicher abdeckt. Eventuell können Sie dann ja auch im Nachhinein noch eine Optimierung vornehmen, indem Sie in der Deklaration Ihrer fertigen X3D-Datei die überflüssigen Komponenten oder Level identifizieren und optimieren. Maßvoll modellieren

Alle Module auf einen Blick

TABELLE 2.1 Gesamtübersicht Profile, Komponenten und Level in X3D Version 3.2

Dies ist vor allem dann von Bedeutung, wenn Sie mit Ihrer 3D-Szene auf bestimmte Anwendungssysteme mit einer eingeschränkten Leistungsfähigkeit abzielen und trotzdem zufriedenstellende Darstellungsergebnisse sicherstellen wollen. Grundsätzlich gilt insbesondere für das Internet die Faustregel, je weniger Ressourcen eine 3D-Welt benötigt, umso größer wird auch ihre Verbreitung über die verschiedensten Plattformen sein. Natürlich ist dabei immer auch auf die Balance zwischen Einfachheit und Attraktivität einer virtuellen Welt zu achten. Um Ihnen den Überblick und die Auswahl Ihrer Bausteine zu erleichtern, stellt Tabelle 2.1 für jedes der Basis-profile die jeweils enthaltenen Komponenten und deren Level dar. Insgesamt hat sich die Anzahl der verfügbaren Komponenten seit der Standardisierung von X3D gemäß Spezifikation Version 3.0 von 24 über Version 3.1 mit 28 auf die Version 3.2 mit 34 verschiedenen Komponenten kontinuierlich gesteigert. In Tabelle 2.1 zeigt das Vorhandensein einer Zahl in der Spalte des betroffenen Profils an, dass die Komponente in der entsprechenden Zeile in diesem Profil enthalten ist. Der Wert der Zahl entspricht dabei dem Level der Komponente, die dieses Profil umfasst. Der Vollständigkeit halber sind auch die beiden Spezialprofile MPEG-4Interactive und CADInterchange aufgeführt. Interchange

Interactive

Immersive

Full

MPEG-4

CAD

Profil 1 1 1 1 3 1 2

Profil 1 1 2 2 3 1 3

Profil 1

2 2 2 1

Profil 2 2 3 3 5 4 4 2 1 1 3 3 5 1

Profil 1 1 2 2 1 1 2

1 2 2

Profil 2 1 3 2 3 2 4 1 1 1 2 3 2 1

Komponente Core Time Networking Grouping Rendering Shape Geometry3D Geometry2D Text Sound Lighting Texturing Interpolation Pointing device sensor

2 1 2 1

1 1 4 2

1 2

DER BAUKASTEN X3D

Interchange

Interactive

Immersive

Full

MPEG-4

CAD

TABELLE 2.1

Profil

Profil

Profil

Profil

Profil

Profil

1

2

2

1 1 1

2 2 2

3 3 4 2 1

1 1 1

Gesamtübersicht Profile, Komponenten und Level in X3D Version 3.2

2

Komponente Key device sensor Environmental sensor Navigation Environmental effects Geospatial Humanoid animation Non-uniform Rational B-Spline (NURBS) Distributed interactive simulation (DIS) Scripting Event utilities Programmable shaders CAD geometry Texturing3D Cube map environmental texturing Layering component Layout component Rigid body physics component Picking sensor component Followers component Particle systems component

33

1 1

4 2

1

1 1

1 1 1 2 2

1 2

3 1 2 2 3 1 3

Sämtliche der in diesem Buch vorgestellten X3D-Funktionen lassen sich Tabelle 2.1 zuordnen. Sie können also während des Worldbuildings jederzeit hier nachsehen, welche Module für Ihre 3D-Szenen nötig beziehungsweise welche Kombinationen möglich sind.

2.1.4

Software-Unterstützung

Auch die schönsten 3D-Modelle mit den aufwendigsten Funktionen haben nur einen bescheidenen Nutzen, wenn die zur Ansicht verwendete Software die entsprechenden X3D-Module nicht unterstützt und folglich nicht darstellen kann. Dies gilt ebenso für alle nicht grafischen Funktionen, die mit dem X3D-Standard beschrieben werden können (Sound, Scripting, Networking etc.). Aus diesem Grund sollten Sie durchaus eine möglichst genaue Vorstellung von der Leistungsfähigkeit der Systeme und Applikationen haben, auf denen Ihre X3D-Dateien später verwendet werden sollen. Dies ist natürlich leichter gesagt als getan, insbesondere wenn Ihre 3D-Welten einem möglichst breiten Publikum auf dem Internet zugänglich gemacht werden sollen.

Unterschiedliche Leistungsfähigkeit von X3D-Viewern

34

Kapitel 2

Alleine die vielen verfügbaren X3D-Viewer weisen ein recht heterogenes Leistungsspektrum bezüglich ihres Supports der verschiedenen X3D-Module auf. Dies ist jedoch nicht immer auf einen Mangel an Leistungsfähigkeit oder ein unausgereiftes Entwicklungsstadium des Viewers zurückzuführen, sondern oftmals auch das durchaus beabsichtigte Resultat einer anwendungsoptimierten Ausrichtung durch den Hersteller. Support-Tabellen im Web3D-Wiki

Damit Sie als Worldbuilder nicht einzeln die Leistungsmerkmale der verschiedenen X3D-Viewer auf den Herstellerseiten durchsuchen und abgleichen müssen, wurde vom Web3D Consortium eine Initiative angestoßen, den Support der X3D-Module für die gängigen Viewer zentral zusammenzustellen und aktuell zu halten. Viele der teilnehmenden Hersteller sind Mitglieder im Web3D Consortium und haben sich entsprechend zur Auskunft verpflichtet. Ein „yes“ in der Player-Support-Tabelle bedeutet, dass der entsprechende X3D-Viewer alle Knoten auf jedem Level der betreffenden Komponente unterstützt. Leider findet sich vereinzelt auch ein unspezifisches „partial“, an anderer Stelle dagegen jedoch auch die konkrete Angabe des implementierten Level. Eine ähnliche Aufstellung steht auch für X3D-Autorensysteme und Konvertierungstools bereit. Support-Tabellen für X3D-Viewer, Autorensysteme und Konvertierungstools

Eine Übersicht zum Support der X3D-Module durch die gängigen Viewer, Autorensysteme und Konvertierungstools finden Sie als Link unter www.web3d.org/x3d/ wiki. Testen, testen und testen

Als Worldbuilder werden Sie dennoch nicht umhinkommen, den konkreten Support für Ihre 3D-Szenen auf einem oder am besten mehreren X3D-Viewern zu testen. Vereinzelt weichen die Implementierungen und Toleranzen der verschiedenen Viewer voneinander ab, sodass eine 3D-Szene bei dem einen Hersteller korrekt, bei dem nächsten aber fehlerhaft dargestellt wird. Es gehört zur guten Praxis eines Worldbuilders, spätestens vor der Veröffentlichung einer 3D-Welt im Internet diese ausgiebig und auf verschiedenen Plattformen zu testen. Auch wir werden in unserem Tutorial beizeiten auf verschiedene X3D-Viewer zurückgreifen, falls einzelne Leistungsmerkmale nur von bestimmten Viewern korrekt unterstützt werden. Sie werden dies daran erkennen, dass die Screenshots im Buch dann einen anderen X3D-Viewer zeigen.

2.2 Das Herzstück des ISO-Standards

Nachschlagewerk X3D-Spezifikation

Die X3D-Spezifikation bildet das Herzstück des ISO-Standards X3D. In den Dokumenten der Spezifikation sind neben dem generellen Konzept, der Nomenklatur und weiteren fundamentalen Informationen auch sämtliche Profile, Komponenten, Level sowie die einzelnen Knoten, ihre Felder und möglichen Werte beschrieben. Sie umfasst damit das gesamte Regelwerk von X3D und bietet somit die beste Alternative zum

DER BAUKASTEN X3D

35

Nachschlagen bei Fragen zur Syntax von X3D, neben den bereits besprochenen formalen Grammatiken der DTD und XSD – und natürlich diesem Buch. Ebenso wie die X3D-Grammatiken wird auch die X3D-Spezifikation vom Web3D Consortium gepflegt, verwaltet und zentral bereitgestellt. Das Web3D Consortium koordiniert die Working Groups, die an der (Weiter-)Entwicklung der einzelnen Komponenten arbeiten, und führt die Entwürfe zu den Standards, Novellierungen und Anlagen den sukzessiven Stufen der Standardisierung bis hin zur ISO-Zertifizierung zu. Die Dokumente werden in ihren unterschiedlichen Standardisierungsstadien auf den Seiten des Web3D Consortium veröffentlicht. Adresse der X3D-Spezifikationen

Eine Übersicht zu den aktuell verfügbaren Standards, Erweiterungen und Entwürfen finden Sie auf den Seiten des Web 3D Consortium unter www.web3d.org/x3d/ specifications im Bereich der „X3D International Standards“. Neben der dort mittlerweile im Archiv unter „Previous Versions of Standards“ ruhenden initialen X3D-Spezifikation ISO/IEC 19775:2004 findet sich die jeweils aktuellste Version unter „X3D International Standards“. Zum Zeitpunkt der Entstehung dieses Buches ist der aktuellste Stand bezüglich der Architektur und sämtlicher Module in der X3D-Spezifikation ISO/IEC 19775-1:2008 festgehalten. Ein Akronym gemäß den ISOKonventionen gibt Auskunft darüber, in welchem Stadium sich die Standardisierung befindet. So steht beispielsweise „FDIS“ für Final Draft International Standard, das heißt, für das betroffene Dokument steht die Entscheidung durch das ISO-Komitee über die Akzeptanz oder aber eine erneute Revision des finalen Entwurfs unmittelbar bevor, ein „IS“ ist dagegen bereits als offizieller ISO/IEC-Standard verabschiedet.

Die aktuellste Version

In der Spezifikation können Sie als Worldbuilder auch nachschauen, welche Knoten auf welchem Level einer Komponente definiert sind. Diese Information benötigen Sie, wenn Sie im Header-Bereich der X3D-Datei den notwendigen Level exakt angeben wollen. Die zusätzliche Integration dieser Information in Tabelle 2.1 hätte deren Ausmaße allerdings gesprengt. Aus diesem Grund zeigt Tabelle 2.2 in Anlehnung an die X3D-Spezifikation ISO/IEC 19775-1:2008 exemplarisch und vereinfacht die spezifizierten Knoten aller vier Levels der Komponente Geometry3D.

Level und ihre Knoten

Level

1

2 3 4

Knoten Box Cone Cylinder Sphere all Level 1 geometry nodes IndexedFaceSet all Level 2 geometry nodes ElevationGrid all Level 3 geometry nodes Extrusion

TABELLE 2.2 Die vier Ebenen der X3DKomponente Geometry3D

36

Kapitel 2

Daneben finden Sie viele weitere interessante und detaillierte Informationen in den Spezifikationsdokumenten, die Ihre Arbeit erleichtern und in einigen Fällen die Trialand-Error-Phasen während des Worldbuildings erheblich verkürzen können. Über die verlinkte Struktur der Online-Spezifikation können Sie schnell von den Profilen über die Komponenten und Level direkt auf die Beschreibungen der einzelnen Knoten zugreifen und haben so online jederzeit und allerorts ein mächtiges Nachschlagewerk zur Verfügung. Im nächsten Kapitel werden wir nochmals tiefer in die X3D-Spezifikation eintauchen, wenn wir uns die konkrete Spezifikation einzelner Knoten und ihrer Verknüpfungen ansehen.

3 ARCHITEKTUR DES SZENENAUFBAUS Selbst das beste Schauspiel überzeugt nur wenig ohne eine stimmungsvolle Kulisse, ansprechende Kostüme und eine gut inszenierte Story. Ein wenig gewagt zwar, macht dieser Vergleich doch deutlich, welch hohen Stellenwert die grundlegende Modellierung und Gestaltung einer 3D-Szene bei aller Euphorie für die bunten virtuellen Welten oder die fortgeschrittenen Leistungsmerkmale von X3D einnimmt. Ohne ansprechend modellierte Objekte, ein stimmungsvolles Szenendesign und eine zielgerichtete Fokussierung bleibt jede noch so aufwendige Interaktion und Animation in X3D konturlos und damit ohne nennenswerte Aussage. Als Worldbuilder sind Sie Regisseur, Bühnenbildner, Kostümausstatter, Beleuchter, Orchester und Buchhalter in einem. Sie modellieren die Szene, gestalten Objekte, erzeugen Dramaturgie durch Licht und Töne, bestimmen das Zusammenspiel der Akteure und sind dabei beständig auf die Performance des Ganzen bedacht. Denn Ihre Vorstellung findet nicht im Theater vor Ort statt, sie spielt weltweit, auf vielen Bühnen, vor vielen verschiedenen Besuchern unter immer neuen Bedingungen. Die Anforderungen an einen Worldbuilder erscheinen hoch, sofern sie ernst genommen werden. Ignoriert man diese, erliegen entsprechende 3D-Welten sicherlich bald einem ähnlichen Schicksal wie viele andere Online-Angebote, die einen immergleichen einstelligen Besucherzahlenstand verzeichnen. Betrachten Sie die von X3D angebotenen und im Laufe des Tutorials vorgestellten Möglichkeiten deshalb als einen Werkzeugkasten, der Ihnen hilft, Ihre Ideen und Vorstellungen

38

Kapitel 3

auf eine innovative, kreative und multidimensionale Weise anderen Menschen mitzuteilen. Zahlreiche Beispielprogramme verdeutlichen in übersichtlicher Form die Implementierung der X3D-Konzepte und liefern dabei Anregungen zu deren Einsatz. Machen Sie sich mit diesen mächtigen Tools vertraut, um sie gezielt bei Ihrer Arbeit einsetzen zu können. Noch ein Wort an diejenigen unter Ihnen, die bereits Erfahrungen mit einem der Vorgänger von X3D gesammelt haben. Nahezu alle Leistungsmerkmale des direkten Vorgängers VRML97 wurden im Rahmen des Immersive-Profils in X3D übernommen, erscheinen durch die Übersetzung in XML jedoch in einer völlig neuen Notationsform. Hinzu kommt eine Vielzahl neuer Knoten und Funktionen, die im Rahmen der zahlreichen Komponenten im Full-Profil ergänzt wurden und auch zukünftig weiter ausgebaut werden. Ein kleiner Trost für die Nostalgiker unter Ihnen: Die Notation im alten Spaghetti-Code von VRML97 müssen Sie nicht zwangsläufig aufgeben, und auch Ihre alten Modelle können Sie leicht wieder verwenden. Wie das geht, erfahren Sie in unserem Überblick über die möglichen Dateiformate von X3D. Nach den beiden vorangegangenen Grundlagen-Kapiteln wollen wir in diesem Kapitel endlich auch in die erste 3D-Welt unseres Tutorials eintauchen. Erfahren Sie, welche Konzepte dem X3D-Sprachgebrauch zugrunde liegen und wie Sie mithilfe weniger elementarer Bausteine eine einfache 3D-Szene zusammensetzen. Das grundlegende Verständnis für den Dateiaufbau und die Konzeption der einzelnen Bestandteile einer 3D-Szene ermöglicht Ihnen später den sicheren und schnellen Umgang mit den vielen und facettenreichen Elementen des Worldbuildings mit X3D.

3.1

Dateikonzept und Szenengraph

X3D ist (auch) eine Szenenbeschreibungssprache

X3D gehört zu den sogenannten Szenenbeschreibungssprachen (engl. Scene Description Language, SDL). Damit entspricht sie einem bewährten Strukturierungsansatz, der auch anderen 3D-Formaten zugrunde liegt (OpenInventor, Java3D etc.). Typischerweise greift eine SDL auch auf Ansätze der objektorientierten Modellierung zurück, um die Konstellationen und Abhängigkeiten von geometrischen Objekten und deren Eigenschaften in einer Szene zu beschreiben. Die Handhabung solcher Beschreibungssprachen erfordert vom Benutzer keinerlei Kenntnisse in entsprechend ausgelegten Programmiersprachen, sondern vereinfacht mit teilweise entlehnten Begriffen lediglich den Umgang mit den Objekten und damit den Überblick über die in der 3D-Grafik bisweilen recht komplex ausfallenden Szenen.

Ein Szenengraph und ein Wurzelknoten pro X3D-Datei

Eine X3D-Szene besteht somit aus einer geordneten Liste von Objekten, die als Knoten (engl. Nodes) bezeichnet werden. Die Struktur einer X3D-Datei ergibt sich grundsätzlich aus der Zusammenstellung von Knoten aus folgenden Kategorien: Gruppenknoten (engl. Grouping Nodes) und Kindknoten (engl. Children Nodes). Wie der Name bereits andeutet, fassen Gruppenknoten andere Knoten zusammen, wobei letztere wiederum aus beiden Kategorien stammen können. Ausgehend von einem zentralen Gruppen-

ARCHITEKTUR DES SZENENAUFBAUS

39

knoten – dem sogenannten Wurzelknoten – entsteht durch die Kombination dieser Knoten in einer X3D-Datei eine hierarchische Baumstruktur, die als sogenannter Szenengraph (engl. Scene Graph) bezeichnet wird (siehe Abbildung 3.1). Eine X3D-Datei enthält somit genau einen Szenengraph. ABBILDUNG 3.1 Szenengraph

Gruppenknoten

Gruppenknoten

Gruppenknoten

Felder

Felder

Felder

Hierarchische Objektstruktur im Szenengraph von X3DDokumenten

Kindknoten

Kindknoten

Kindknoten

Gruppenknoten

Kindknoten

Felder

Felder

Felder

Felder

Felder

Objektknoten

Objektknoten

Objektknoten

Objektknoten

Kindknoten

Objektknoten

Felder

Felder

Felder

Felder

Felder

Felder

Objektknoten

Objektknoten

Felder

Felder

Neben den Gruppen- und Kindknoten kann eine weitere Kategorie unterschieden werden, die wir als Objektknoten bezeichnen wollen. Die Objektknoten können keine weiteren Knoten enthalten und tragen von daher auch nicht zur Strukturierung des Szenengraphen bei. Ihre Aufgabe besteht vor allem darin, die in der gerenderten 3D-Szene sichtbaren Objekte und Geometrien im Szenengraph zu repräsentieren. Das Zusammenspiel der unterschiedlichen Knoten gestaltet sich folgendermaßen. Ausgehend vom Wurzelknoten bilden die unmittelbar folgenden Gruppenknoten die höchste Hierarchiestufe im Szenengraphen. Alle anderen Knoten ordnen sich diesen als Kindknoten unter, bilden eventuell weitere Hierarchiestufen über nachfolgende Gruppenknoten aus und münden schließlich auf ihrer jeweils untersten hierarchischen Ebene in spezifischen Objektknoten, die ausschließlich in diesem Kontext vorkommen können. Aus dieser Strukturierung resultieren Abhängigkeiten zwischen den Knoten einer hierarchischen Verknüpfung. Eine Veränderung in einem Gruppenknoten pflanzt sich somit über die Kindknoten bis zu den jeweiligen Objektknoten fort.

Zusammenspiel von Gruppen-, Kind- und Objektknoten

Als Beispiel für dieses Vererbungsprinzip wäre die Verschiebung eines Objekts im Raum mittels der sogenannten Transformationshierarchie (engl. Transformation Hierarchy) zu nennen: Ein Objekt (Kindknoten) mit der Form einer Kugel (Objektknoten) wird in seiner Position (Gruppenknoten) verändert. Auf diesen grundlegenden Mechanismus werden Sie als Worldbuilder permanent zurückgreifen, wenn Sie den geometrischen Objekten in Ihrer 3D-Welt eine initiale Position zuweisen oder diese später dynamisch per Animation oder Interaktion verändern und den Szenengraph entsprechend manipulieren wollen.

Vererbung von Eigenschaften

40

Kapitel 3

Knoten verbinden

Die konkrete Verknüpfung der einzelnen Konten im Quelltext einer X3D-Datei gestaltet sich je nach Notationsform unterschiedlich, wie wir in den folgenden Abschnitten dieses Kapitels sehen werden. Das Grundprinzip ist jedoch immer gleich. Ein Gruppenknoten kann über einen oder mehrere Kindknoten verfügen, während ein Kindknoten bezüglich eines bestimmten Merkmals genau einen spezifischen Objektknoten umfasst. Bezogen auf das obige Beispiel bedeutet dies, dass der Gruppenknoten Transform über die Funktion translation sich selbst, seinen Kindknoten Shape und den darunter angeordneten Objektknoten Sphere im dreidimensionalen Raum positioniert. Mit diesem Beispiel haben wir uns bereits so weit in die Syntax von X3D vorgewagt, dass wir es zusätzlich anhand der konkreten Spezifikationen der angesprochenen Knoten verdeutlichen können. Danach ist es nur noch ein kleiner Schritt, die Knoten in einer Datei zu einer zusammenhängenden 3D-Szene zu kombinieren.

3.2 Verschiedene Notationsformen

Spezifikation von Knoten

Bei der Beschreibung der Spezifikation von Knoten ist es angebracht, zwischen verschiedenen Darstellungsformen zu unterscheiden und sich die Unterschiede bewusst zu machen. Die abstrakte Beschreibung der funktionalen X3D-Architektur, deren Basiskomponenten und Knoten erfolgt im Rahmen der als internationaler Standard (ISO-Akronym „IS“) verabschiedeten X3D-Spezifikation ISO/IEC 19775. Zusätzlich zu der hierin enthaltenen abstrakten Knotenspezifikation wird deren konkrete Notation als sogenannte Enkodierung (engl. Encoding) im Rahmen des X3D-Standards festgehalten. Der unter ISO/IEC 19776-1 veröffentlichte internationale Standard beschreibt entsprechend die Enkodierung der X3D-Spezifikation in der Syntax von XML. Adressen der X3D-Spezifikationen

Die Spezifikationen zu X3D und deren Anhänge finden Sie auf den Seiten des Web3D Consortium unter www.web3d.org/x3d/specifications. Im dortigen Abschnitt „X3D International Standards“ finden Sie unter „ISO/IEC 19775: X3D architecture and base components“ den Link zur generischen X3D-Spezifikation. Unter „ISO/IEC 19776-1: XML encoding“ finden Sie den Link zur aktuellen XMLEnkodierung. Die folgenden Abschnitte stellen die oben bereits angesprochenen Beispielknoten in den jeweiligen Notationsformen gegenüber und verdeutlichen so deren Gemeinsamkeiten und Unterschiede. Je nach der von Ihnen bevorzugten Notationsform können Sie später dann jederzeit in den entsprechenden Spezifikationsdokumenten nachschlagen, falls Sie einmal Details zu einzelnen Knoten benötigen, die über die Beschreibungen in diesem Buch hinausgehen.

ARCHITEKTUR DES SZENENAUFBAUS

3.2.1

41

Generische Spezifikation

Die generische Spezifikation eines Knotens gemäß der X3D-Spezifikation ISO/IEC 19775 wird die ‚alten Hasen’ unter Ihnen noch sehr stark an die Notation in den früheren VRML-Spezifikationen erinnern. Auch die Einsteiger unter Ihnen werden später erkennen, wie ähnlich die generische Spezifikation der in ClassicVRML verwendeten Syntax ist. Die folgende Aufstellung zeigt die Spezifikation des Gruppenknotens Transform und entspricht dabei exakt der Darstellung im originalen Spezifikationsdokument. Die Spezifikation eines jeden Knotens beginnt immer mit dessen Namen und – durch einen Doppelpunkt getrennt – der Angabe des entsprechenden abstrakten Knotentyps, von dem der konkrete Knoten abgeleitet ist. Im Falle des Gruppenknotens Transform ist dies der abstrakte Knotentyp X3DGroupingNode. Transform : X3DGroupingNode { MFNode [in] addChildren MFNode [in] removeChildren SFVec3f [in,out] center MFNode [in,out] children SFNode [in,out] metadata SFRotation [in,out] rotation SFVec3f [in,out] scale SFRotation [in,out] scaleOrientation SFVec3f [in,out] translation SFVec3f [] bboxCenter SFVec3f [] bboxSize }

0 0 0 [] NULL 0 0 1 0 1 1 1 0 0 1 0 0 0 0 0 0 0 -1 -1 -1

Abstrakte Knotentypen

[X3DChildNode] [X3DChildNode] (-∞,∞) [X3DChildNode] [X3DMetadataObject] [-1,1] or (-∞,∞) (-∞, ∞) [-1,1] or (-∞,∞) (-∞,∞) (-∞,∞) [0,∞) or −1 −1 −1

Entsprechend stellt sich die Spezifikation des Kindknotens Shape dar, der dem Knotentyp X3DShapeNode entspricht. Shape : X3DShapeNode { SFNode [in,out] SFNode [in,out] SFNode [in,out] SFVec3f [] SFVec3f [] }

appearance geometry metadata bboxCenter bboxSize

NULL NULL NULL 0 0 0 -1 -1 -1

[X3DAppearanceNode] [X3DGeometryNode] [X3DMetadataObject] (-∞,∞) [0,∞) or −1 −1 −1

Und um die Knoten aus dem oben genannten Beispiel zu vervollständigen, sei auch noch die Spezifikation des Objektknotens Sphere vom Knotentyp X3DGeometryNode aufgeführt. Sphere : X3DGeometryNode { SFNode [in,out] metadata SFFloat [] radius SFBool [] solid }

NULL 1 TRUE

[X3DMetadataObject] (0,∞)

Der Wirkungsbereich eines spezifizierten Knotens wird durch die geschweiften Klammern begrenzt („{}“). Zwischen der öffnenden und der schließenden Klammer wer-

Felder definieren die Eigenschaften eines Knotens

42

Kapitel 3

den die einzelnen Eigenschaften eines Knotens als sogenannte Felder (engl. Field) festgelegt. Die Definition eines Knotenfelds vollzieht sich in fünf Schritten, die in den oben dargestellten Listings durch entsprechende Einrückungen auch optisch zu erkennen sind. 1. Feldtyp (Beispiel MFNode): Legt den Datentyp des Wertes fest, der in diesem Feld gespeichert werden kann. Ist nur ein Wert des zugelassenen Typs erlaubt, wird dem Feldtyp das Akronym „SF“ (Single Field) vorangestellt (Beispiel SFNode), bei mehr als einem erlaubten Wert dagegen das Akronym „MF“ (Multiple Field). X3D unterscheidet 21 Feldtypen in jeweils SF und MF, die in der Spezifikation ISO/IEC 19775 unter „Field type reference“ mit ihren maximalen Wertebereichen und Standardwerten aufgelistet sind. 2. Zugriffstyp (Beispiel [out]): Gibt an, ob das jeweilige Feld zur Laufzeit – also während der Ausführung der X3D-Datei – Mitteilungen erhalten und der im Feld gespeicherte Wert verändert werden kann ([in]), das Feld selbst Mitteilungen versenden darf ([out]), beides erlaubt ist ([in,out]) oder keines von beidem ([]). Der Zugriffstyp (engl. Access Type) ist entscheidend für die Manipulation der Knoteneigenschaften zur Laufzeit, die vor allem bei der Animation und Interaktion in dynamischen 3D-Szenen zum Tragen kommt. 3. Feldbezeichner (Beispiel translation): Der eigentliche Name des Knotenfelds, unter dem dieses angesprochen werden kann. 4. Standardwert (Beispiel 0 0 0): Der Wert, der dem Knotenfeld konform zu seinem Feldtyp per Definition zugewiesen ist (engl. Default Value). Der Standardwert lässt sich überschreiben, indem dem Feld ein Ersatzwert vom gleichen Feldtyp zugewiesen wird. 5. Wertebereich (Beispiel [-1,1]): Gibt in Abhängigkeit vom Feldtyp an, in welchem Bereich ein zugewiesener Wert liegen darf. Numerische Wertebereiche werden mittels mathematischer Notationen angegeben, X3D-Objekte dagegen durch die Angabe des zulässigen abstrakten Knotentyps. Abgeleitete Knotentypen

Bezogen auf unser obiges Beispiel lässt sich die hierarchische Verknüpfung der drei Knoten Transform, Shape und Sphere anhand ihrer Spezifikation nun einfach erklären. Über das Feld children kann dem Transform-Knoten ein oder mehrere (MFNode) Kindknoten vom abstrakten Knotentyp X3DChildNode zugewiesen werden. Da es sich bei dem Knotentyp X3DShapeNode um eine abgeleitete Klasse vom Typ X3DChildNode handelt, ist die Zuweisung des Kindknotens Shape damit zulässig. Über das Feld geometry kann der Kindknoten Shape auf einen (SFNode) Objektknoten vom Knotentyp X3DGeometryNode verweisen. Der Objektknoten Sphere entspricht diesem Knotentyp und ordnet sich entsprechend unterhalb ein. Der Vollständigkeit halber sei hier noch die Spezifikation des abstrakten Knotentyps X3DShapeNode inklusive dessen Ableitung vom Knotentyp X3DChildNode abgedruckt, wie sie im Standard ISO/IEC 19775 unter der Shape-Komponente zu finden ist.

ARCHITEKTUR DES SZENENAUFBAUS

X3DShapeNode : X3DChildNode, X3DBoundedObject { SFNode [in,out] appearance NULL SFNode [in,out] geometry NULL SFNode [in,out] metadata NULL SFVec3f [] bboxCenter 0 0 0 SFVec3f [] bboxSize -1 -1 -1 }

[X3DAppearanceNode] [X3DGeometryNode] [X3DMetadataObject] (-∞,∞) [0,∞) or −1 −1 −1

Für die Umsetzung der Knoten in konkrete Anweisungen innerhalb einer X3D-Datei müssen Sie zum Glück nur einen Teil der spezifizierten Informationen eingeben. Weder der Feldtyp, der Zugriffstyp noch der Wertebereich erscheinen im Quelltext, und auch der Standardwert muss nicht angegeben werden, sondern lediglich die abweichende und damit überschreibende Wertzuweisung. Generell werden auch nur diejenigen Felder im X3D-Quelltext aufgeführt, denen ein alternativer Wert zugewiesen wird, ansonsten gelten automatisch die Standardwerte. Entsprechend einfach gestaltet sich auch die Spezifizierung in der XML-Enkodierung.

3.2.2

Enkodierung in XML

Sämtliche Knoten der X3D-Spezifikation sind für ihre praktische Anwendung in die XML-Syntax übertragen worden, deren Funktionsweise, Bestandteile und viele Vorteile Sie im Kapitel zu den XML-Grundlagen bereits kennengelernt haben. Die Enkodierung der X3D-Spezifikation in XML bildet einen Teil der Spezifikationsdokumente des ISO-Standards X3D. Wie oben bereits erwähnt, beschreibt der Spezifikationsteil „ISO/IEC 19776-1: XML encoding“ die XML-Enkodierung und umfasst dabei auch die Enkodierung aller X3D-Knoten in XML. Die Regeln zur Verwendung der Knoten sind dagegen vor allem in den bereits besprochenen XML-Grammatiken festgehalten. Wie für alle anderen Knoten auch, gibt es für die drei oben genannten Beispielknoten Transform, Shape und Sphere eine Entsprechung in XML. Die folgende Aufstellung zeigt die Enkodierung des Transform-Knotens in der XML-Syntax.

ID IDREF SFVec3f [initializeOnly] SFVec3f [initializeOnly] SFVec3f [inputOutput] SFRotation [inputOutput] SFVec3f [inputOutput] SFRotation [inputOutput] SFVec3f [inputOutput] NMTOKEN

Die Übertragung ist leicht nachvollziehbar. Der Knoten Transform ist als gleichnamiges XML-Element definiert. Als Attribute des Transform-Elements sind die einzelnen

43

44

Kapitel 3

Knotenfelder beziehungsweise deren Feldbezeichner aufgeführt. Die Standardwerte sind als Wertzuweisungen den jeweiligen Attributen zugeordnet. Darauf folgt die Angabe des Feldtyps und schließlich des Zugriffstyps. In der XML-Syntax wird der Zugriffstyp jedoch durch die abweichenden Bezeichnungen [inputOnly] (statt [in]), [outputOnly] (statt [out]), [inputOutput] (statt [in,out]) und [initializeOnly] (statt []) bestimmt. Hierarchische Verknüpfung durch Verschachtelung der Tags

Der Wirkungsbereich des Transform-Elements ist – wie bei den XML-Sprachen üblich – durch das entsprechende Start- und End-Tag begrenzt. Für den Inhalt der umschließenden Transform-Tags ist der als Kommentar realisierte Platzhalter ChildContentModel eingefügt. Das ChildContentModel ist in der Spezifikation zur XML-Enkodierung als das Pendant zu dem korrespondierenden abstrakten Knotentyp X3DChildNode definiert. Die hierarchische Unterordnung weiterer Kindknoten erfolgt hier also XMLkonform durch die Einbettung beziehungsweise Verschachtelung weiterer, über das Content Model spezifizierter Elemente. Das Knotenfeld children aus der X3D-Spezifikation wird entsprechend durch das spezielle Attribut containerField mit der Namenszuweisung „children“ (NMTOKEN) ersetzt, das die Beziehung der untergeordneten Elemente zu ihrem Elternknoten Transform repräsentiert. Um die hierarchische Verknüpfung der drei Beispielknoten auch in der XML-Syntax von X3D zu demonstrieren, zeigt die folgende XML-Enkodierung den vollständig definierten Kindknoten Shape mit dem eingebetteten Verweis auf das zum abstrakten Knotentyp X3DShapeNode korrespondierende XML-Pendant ShapeChildContentModel. Zur Erklärung sei hier nur kurz angemerkt, dass die beiden Attribute DEF und USE die Vergabe (ID) und den Verweis (IDREF) auf einen beliebigen Referenznamen erlauben.

Abschließend ist der Objektknoten Sphere in der XML-Enkodierung aufgeführt, als einer der gemäß dem ShapeChildContentModel möglichen untergeordneten Objektknoten des Kindknotens Shape.

ID IDREF SFFloat NMTOKEN

[initializeOnly]

Grafisch stellt sich die Beziehung zwischen den genannten Beispielknoten Transform, Shape und Sphere in der Form eines Szenengraphs wie in Abbildung 3.2 dar.

ARCHITEKTUR DES SZENENAUFBAUS

Transform children

45

ABBILDUNG 3.2 Einfacher Szenengraph der X3D-Datei “Hello.x3d”

Shape geometry

Sphere radius

Auf der Grundlage des Szenengraphen aus Abbildung 3.2 und der Spezifikation der drei Beispielknoten in der XML-Syntax ist es nun wirklich nur noch ein kleiner Schritt, die entsprechende X3D-Datei zu entwickeln und Ihre erste 3D-Welt zu starten.

3.3

Hello Virtual World

Nachdem sämtliche Knoten des oben ausgiebig behandelten Beispiels in ihrer vollständigen Spezifikation und Enkodierung behandelt und einer hierarchischen Struktur zugeordnet wurden, lassen sich diese Angaben sehr einfach in eine konkrete X3DDatei umsetzen. Der Quellcode in Listing 3.1 entspricht exakt dem zuvor erarbeiteten Szenengraph aus Abbildung 3.2.

Die erste X3D-Datei