Diplomarbeit. Grafik-APIs zur Softwareentwicklung für die computergestützte Sehschulung. Sascha Seewald Matrikel-Nr:

Transkript

1 Diplomarbeit Grafik-APIs zur Softwareentwicklung für die computergestützte Sehschulung Sascha Seewald Matrikel-Nr: Technische Universität Dresden Fakultät Informatik Institut für Software- und Multimediatechnik Professur für Computergrafik und Visualisierung Universitätsbetreuer Informatik Universitätsbetreuer Psychologie/Augenheilkunde Verantwortlicher Hochschullehrer: Dr.-Ing. Wilfried Mascolus Dr. rer. nat. Uwe Kämpf Dr. rer. nat. Markus Wacker Eingereicht am: 14. Juli 2004

2 Selbstständigkeitserklärung Hiermit erkläre ich, Sascha Seewald, dass die vorliegende Arbeit von mir selbstständig und nur unter Verwendung der angegebenen Hilfsmittel angefertigt wurde. Dresden, den Sascha Seewald, TU Dresden 2

3 Kurzbeschreibung An der TU Dresden wird seit vielen Jahren im Rahmen eines interdisziplinären Forschungsprojekts Software für die computergestützte Sehschulung entwickelt und erprobt. Komplette Eigenentwicklungen, die sowohl den steigenden Anforderungen an die therapeutische Qualität der Programme als auch den rasanten Hardund Software Entwicklungen im 3D-Bereich Rechnung tragen, gestalten sich immer aufwendiger und kostspieliger. In dieser Diplomarbeit soll untersucht werden, inwieweit sich frei verfügbare open-source Software für diese Entwicklungen nutzen lässt. Dazu werden im ersten Teil Anforderungen an 3D-Grafik-Bibliotheken für den Einsatz in der Augentherapie zusammengetragen und Bewertungskriterien daraus abgeleitet. Anschließend werden verfügbare Frameworks recherchiert und in einem detaillierten Vergleich gegenübergestellt. Im zweiten Teil der Arbeit wird mithilfe des besten Kandidaten ein Therapieprogramm entwickelt, welches sich auf bisherige Arbeiten des Forschungsprojekts stützt: Ein Malspiel für drei- bis achtjährige Kinder, das zweidimensionales Malen auf einem virtuellen Blatt sowie das Bemalen von einfachen 3D-Objekten erlaubt. Sascha Seewald, TU Dresden 3

4 Inhalt Kurzbeschreibung Wissenschaftlicher und historischer Hintergrund Vorstellen des Forschungsprojektes Ein Softwaresystem für die Augentherapie Ein erster Client Freie Software Szenegraphen Allgemeine Struktur Arbeiten auf Szenegraphen Szenegraphen im Kontext einer Anwendung Vergleich von Freien Grafik-APIs Anforderungen Bewertungskriterien Erlernbarkeit Erweiterbarkeit/Flexibilität Zukunftssicherheit Lizensierung OpenGL-Integration Dateiformat Unterstützung Features Performance Vorauswahl der Kandidaten Liste der potentiellen Kandidaten Bestimmung der Vergleichskandidaten Vorstellung der drei Kandidaten CrystalSpace Installation Übersicht Erlernbarkeit Erweiterbarkeit Spezielle Features OGRE Installation Architektur Erlernbarkeit Erweiterbarkeit/Flexibilität Spezielle Features OpenSceneGraph Sascha Seewald, TU Dresden 4

5 Installation Übersicht Erlernbarkeit Erweiterbarkeit/Flexibilität Spezielle Features Gegenüberstellung und Bewertung Eine Beispielanwendung auf Basis von OSG Einführung Spielkonzept Visuelle und akustische Gestaltung Die Softwaretechnische Umsetzung im Detail Entwicklungsumgebung Verwendetet open-source Software Entwicklung einer Benutzeroberfläche D-Zeichenverfahren D-Zeichenverfahren Modellierung von 3D-Objekten aus Handskizzen Visusstimulation Zusammenfassung Bewertung Ausblick Abbildungen Quellenverzeichnis Anlagenverzeichnis Sascha Seewald, TU Dresden 5

6 1 Wissenschaftlicher und historischer Hintergrund 1.1 Vorstellen des Forschungsprojektes An der Technischen Universität Dresden werden seit 1995 Untersuchungen zur computergestützten Sehschulung insbesondere zur Behandlung von Amblyopie (Schwachsichtigkeit) und Strabismus (Augenfehlstellung) bei Kindern zwischen drei und acht Jahren durchgeführt. Amblyopie ist ein nicht allein genetisch begründbarer Rückgang der Sehfähigkeit, der bei Kindern entsteht, wenn ein Auge weniger genutzt wird als das andere. Eine Behandlung ist bis zum 12. Lebensjahr möglich, in sehr leichten Fällen auch noch in den Jahren danach. Die Behandlungen werden momentan mit unterschiedlichen Ansätzen durchgeführt. Üblich ist z.b. die Verdeckung des gesunden Auges mit einer Augenklappe, um das bereits geschädigte Auge stärker zu fordern. Diese Diplomarbeit widmet sich der Behandlung der Amblyopie mithilfe von Computervisualisierungen. Das Verfahren geht auf Ideen von Cambell zurück und wurde von Kämpf und Muchamedjarow weiterentwickelt [1]. Seit 1995 wurden an der damaligen Medizinischen Akademie in Zusammenarbeit mit der Fakultät Informatik der TU Dresden Computerprogramme entwickelt, die insbesondere auf oszillierenden Gittern und sinusoidalen Mustern zur Visusstimulation aufbauten. Abbildung 1-1 Beispiel für eine Visusstimualtion Durch technische Studien an verschiedenen medizinischen Einrichtungen konnte nachgewiesen werden, dass diese Programme einen guten Effekt erzielen, teilweise sogar den konventionellen Verfahren überlegen sind. Als besonderer Vorteil galt bereits damals, die Möglichkeit, die Behandlung ambulant oder in Heimtherapie durchführen zu können, da die Stimulationssoftware auf jedem handelsüblichen Standard- PC ausgeführt werden kann. Die Behandlung zuhause, in vertrauter Umgebung und mit nahezu Sascha Seewald, TU Dresden 6

7 unbegrenztem Zeitfond, kombiniert mit ambulanter Erfolgskotrolle stellt eine enorme Entlastung für Kinder, Eltern und Therapeuten dar. Ende der 90er Jahre und seit Beginn des Jahrtausends wurden die Arbeiten an diesem Heilansatz vor allem an den TUD-Fakultäten für Medizin, Psychologie und Informatik weiter verfolgt. Kritisch wurde immer wieder die Positionierung der Probanden unmittelbar vor dem Bildschirm und somit die Wirkung von Nah- und Fernvisus beurteilt. Im Jahr 2000 wurde mit Hilfe der Roland Ernst Stiftung die zweite Stufe einer bundesweit angelegten multizentrischen prospektiven Studie zur computerunterstützten Sehschulung bearbeitet, welche die von Kämpf, Muchamedjarow und Seiler erzielten Pilotergebnisse [12] an einer größeren Stichprobe (200 Probanden) wiederholen konnten. Zugleich wurden von russischen Kooperationspartnern vergleichbare Untersuchungen am Helmholtz-Institut Moskau angestellt, die an einer Stichprobe von ca. 100 Patienten die Überlegenheit der Therapie gegenüber der konventionellen Behandlung mit der Augenklappe belegen konnten [13]. Es konnte unter anderem festgestellt werden, dass insbesondere das periphere Sehen beanspruchende Bildmuster für den Heilerfolg relevant sind. Das eröffnete die Möglichkeit, die Visusstimulation in den bildlichen Hintergrund zu verlagern und im Vordergrund interessante Inhalte zu präsentieren, die die Aufmerksamkeit der Kinder während der langwierigen Therapiesitzungen binden. So entstanden zahlreiche kleine Computerspiele, die die Behandlung für die Kindern aufregender machten und Therapeuten und Eltern viel Überzeugungsarbeit ersparten. Leider ist die entwickelte Software mittlerweile hoffnungslos veraltet. Es lassen sich kaum noch Computer finden, die die überholten DOS-Programme ausführen können. An dieser Stelle setzt die vorliegende Arbeit an. Es soll eine moderne Grundlage für zukünftige Entwicklungen im Bereich der computergestützten Sehschulung geschaffen werden, die aktuelle Technologien in Hard- und Software für das Heilungsverfahren nutzbar macht. Insbesondere die Integration dreidimensionaler Grafik bietet ein hohes Maß an therapeutischem Potential beispielsweise für die Schulung des stereoskopischen Sehens. Zusätzlich wird ein neues, voll einsatzfähiges Therapieprogramm entstehen, das ebenfalls auf die bewährten Kombination von Visusstimulation und Computerspiel setzt. 1.2 Ein Softwaresystem für die Augentherapie Das in dieser Arbeit vorgestellte Programm wird Teil eines umfangreichen Softwaresystems zur Organisation und Durchführung von Augentherapeutischen Behandlungen sein, welches hier in einem groben Konzept dargestellt werden soll. Zu den wichtigsten Aufgaben dieses Systems zählen: Verwaltung von Patienten/Patientendaten inklusive Krankenakte und Therapiedokumentation flexible Organisation von Therapien (Therapieplanung, Sitzungsverwaltung, Analyse/Auswertung der bisherigen Therapieergebnisse usw.) Gestaltung und Durchführung von Sitzungen mit dem Patienten einschließlich automatischer Erfassung und Dokumentation der Sitzungsdaten. Sascha Seewald, TU Dresden 7

8 Eine zentrale Forderung, ist die Möglichkeit, Sitzungen auch ohne medizinisch ausgebildetes Personal und außerhalb einer medizinischen Einrichtung durchführen zu können. Das macht Kindern wie Eltern die Durchführung der Sitzungen angenehmer, da ihnen mehr Gestaltungsfreiraum gelassen wird und die Sitzungen in vertrauter Umgebung stattfinden können. Letztendlich werden so auch Behandlungskosten gespart. Softwareseitige Voraussetzung für diese Methode, ist ein verteiltes System, mit einem Server zur zentralen Verwaltung der Patienten- und Therapiedaten und mehrere Clients zur Organisation/Manipulation dieser Daten und Durchführung der Sitzungen. Ein mögliches Szenario könnte so aussehen: Ein neuer Patient wird durch den behandelnden Arzt dem Patientenregister hinzugefügt. Nach Untersuchung und Diagnose erstellt er einen Therapieplan für den Patienten, legt unter anderem Typ, Dauer und Parameter der durchzuführenden Sitzungen fest. Alle Daten werden zentral auf dem Server erfasst und sind von dort für alle Clients abrufbar. Die Sitzungen können nun entweder im Rahmen einer medizinischen Einrichtung erfolgen (Therapierechner) oder aber zuhause (Heimrechner) bzw. unterwegs. Dazu holt sich der Patient seinen aktuellen Therapieplan vom Server, übernimmt die vom Arzt vorgesehenen Parameter und führt die Sitzung selbständig durch. Das Client-Programm erfasst automatisch die Dauer und übermittelt, diese Daten zurück zum Server, sodass Arzt und Therapeuten den Behandlungsfortgang verfolgen und kontrollieren können. Damit können zeit- und kostenintensive Arztbesuche auf ein Minimum reduziert werden und beschränken sich auf die Bereiche, in denen die ärztliche Kompetenz tatsächlich unverzichtbar ist. Die Ergebnisse von Untersuchungen werden ebenfalls in der Patientenakte erfasst und machen so die therapeutischen Fortschritte nachvollziehbar. Server Client (Arztrechner) LAN WAN Client (Heimrechner) LAN Clients (Therapierechner) Client (Mobile) Abbildung 1-2 Client-Server-Architektur Sascha Seewald, TU Dresden 8

9 1.3 Ein erster Client Die bisherigen Bemühungen zur Umsetzungen dieses Entwurfs haben sich auf die Entwicklung des Clients konzentriert. An erster Stelle sollte ein Programm stehen, dass die Ergebnisse der medizinischpsychologischen Forschung von Kämpf u. a. aufgreift und in einem Prototyp umsetzt. Dieser Client enthält noch nicht die notwendigen Komponenten zur Sitzungsverwaltung oder -auswertung, auch die Client- Server-Kommunikationskomponente ist noch nicht integriert. In dieser reduzierten Variante eignet sich die Software jedoch schon zur einfachen Heimtherapie. Sebastian Schmeck entwickelte an der TU Dresden die AmbViz-Bibliothek zur Darstellung von sinusoidalen Mustern auf Basis von OpenGL. Ebenfalls entstand eine Komponente zur bequemen Erstellung, Konfiguration und Organisation der Muster. Er etablierte ein XML-basiertes Austauschformat. Mit Hilfe seiner Arbeit wurde es möglich, Visusstimulation in beliebige Anwendungen zu integrieren und sie für die Therapie nutzbar zu machen. Auf dieser Grundlage entstand ein erstes 3D-Computerspiel (Abbildung 1-3) für Patienten zwischen drei und sechs Jahren, das durch kindgerechte Inhalte und Gestaltung deren Aufmerksamkeit binden soll, während im Hintergrund die Visusstimulation erfolgt. Abbildung 1-3 3D-Spiel mit AmbViz-Hintergrundstimulation Zukünftig sollen weitere Spiele nach demselben Konzept entwickelt werden, um den Kindern eine größere Auswahl bieten und die Behandlung abwechslungsreicher gestalten zu können. Die Clientsoftware hält dann eine Sammlung von Spielen bereit, aus der Patienten wählen können. Gleich welches Spiel gewählt Sascha Seewald, TU Dresden 9

10 wurde, werden im Hintergrund die vom Arzt festgelegten Stimulationen gezeigt. Da die bereitgestellten Spiele als eigenständige Programme laufen, stellt der Client lediglich ein Frontend zur Verfügung, um dem Anwender die Spielauswahl zu ermöglichen und das Spiel zu starten. Die Stimulationsparameter für die Sitzung werden entweder zuvor manuell gesetzt oder aber automatisch in Form einer AmbViz- Konfigurationsdatei vom Server geladen. Beim Aufruf des Spielprogramms wird diese Datei als Kommandozeilenparameter übergeben und in der Initialisierungsphase des Spiel geladen (avloadconfiguration()). Die anschließende Darstellung der Muster (avdraw()) erfolgt entsprechend dieser Konfiguration. Dabei werden automatisch die Laufzeiten (und damit Stimulationszeiten) erfasst und von einer Statistikkomponente des Clients zur späteren Auswertung registriert. Zukünftig werden die erfassten Daten wieder zurück zum Server gesendet. Frontend Wählt Spiel aus Startet Spiel Übergibt Daten Empfängt Sitzungsdaten Sendet Statistiken Spielesammlung Kommunikation Erfasst Sitzungsdaten Statistik Benutzt AmbViz-Bibliothek Abbildung 1-4 Komponenten des Clients Sascha Seewald, TU Dresden 10

11 1.4 Freie Software Im Rahmen der vorliegenden Arbeit kommen ausschließlich Freie Software-Produkte zum Einsatz. Dieses Kapitel soll einen kurzen Überblick zum Begriff Freie Software und deren Entstehungsgeschichte geben. Software wird als Frei bezeichnet, wenn ihre Lizenz jedem Nutzer mindestens folgende Freiheiten garantiert: 1. Die Freiheit, die Software zu jedem beliebigen Zweck zu nutzen. D.h. die Beschränkungen auf bzw. der Ausschluss von bestimmten Anwendungsfeldern (Forschung und Bildung, Militär, Wirtschaft, Politik, Medizin), zeitliche oder jede anderen Einschränkung der Nutzung machen die Software unfrei. 2. Die Freiheit, zu verstehen, wie die Software funktioniert und sie an seine eigenen Bedürfnisse anzupassen. Der freie Zugang zum Quellkode ist Voraussetzung dafür. Software, die diesen Zugang durch spezielle Lizenzen, Non-Disclosure-Agreements (NDA) oder das Zurückhalten der üblicherweise bevorzugten Bearbeitungsform verhindert, beschränkt oder erschwert ist unfrei. 3. Die Freiheit, ohne Einschränkungen Kopien zu erstellen und weiterzugeben. Wenn die Software jemanden, der sie benötigt aus einem beliebigen Grund vorenthalten wird, ist sie unfrei. Die Weitergabe darf wahlweise gegen ein Entgelt erfolgen, um für den Aufwand der Erstellung und Verbreitung zu entschädigen. 4. Die Freiheit, die Software zu verbessern und die Verbesserungen an jeden Weiterzugeben. Ziel dieser Bestimmungen ist es unter anderem, die Unabhängigkeit des Nutzers vom Urheber der Software zu garantieren. Im traditionellen Urheberrecht bestimmt der Urheber allein, über die Verwendung, Bearbeitung und Weiterentwicklung eines Softwareproduktes (Copyright). Je nach Lizenzmodell werden ausgewählten Nutzern (z.b. einer Firma, einer Privatperson) unter bestimmten Bedingungen (Lizenzkosten, NDA), bestimmte Rechte (Nutzung, Verbreitung, Integration in eigene Software) eingeräumt. Üblicherweise bleibt der Nutzer dabei vom Urheber abhängig. Sei es durch Lizenzkosten, zeitlich beschränkte Lizenzen oder die Verpflichtung, notwendige Anpassungen/Verbesserungen allein durch den Urheber durchführen zu lassen. Insbesondere die Weiterentwicklung der Software wird erschwert, weil nach dem Copyright der ursprüngliche Autor der Software mindestens Mitspracherecht darüber erhält, wie die weiterentwickelte Software - an deren Erstellung er ja nicht mehr direkt beteiligt war - genutzt, vertrieben oder bearbeitet werden darf. Copyleft ist der Versuch diese Praxis umzukehren (daher das Antonym zu Copyright), und überträgt auch Softwareanwendern alle Freiheiten, die der Urheber hatte. Erst dieses Konzept und seine vertragliche Festschreibung in einer Lizenz machen Freie Software langfristig lebensfähig. Denn wird ein Programm, das unter eine Freie Software Lizenz gestellt wurde, angepasst oder weiterentwickelt, wird das Endprodukt wieder frei sein. Sascha Seewald, TU Dresden 11

12 Die Ideen zu Freier Software sind hauptsächlich auf Richard Stallman zurückzuführen, der 1984 das GNU- Projekt [40] ins Leben rief, mit dem Ziel ein komplettes Betriebssystem auf Basis von Freier Software zu entwickeln. Dazu wurde mit der General Public License (GPL) der rechtliche Rahmen geschaffen, der die oben genannten Freiheiten allen Anwendern vertraglich garantiert gründete Stallman die Free Software Foundation [39], eine gemeinnützige Organisation zur Förderung von Freier Software insbesondere des GNU-Projekts. Nach und nach konnten sich immer mehr Entwickler weltweit für Stallmans Idee begeistern und begannen unter der GPL zu entwickeln. Bis heute sind über 3000 Freie Softwareprojekte bei der FSF registriert und es kommen täglich neue hinzu. Das wohl bekannteste Projekt ist das Linux-Betriebssystem, das 1990 von dem finnischen Studenten Linus Towalds begonnen wurde und sich seit dem zum Standard-Kernel des GNU-Systems entwickelt hat. 1.5 Szenegraphen Bei der Beschreibung virtueller Welten wird ab einem bestimmten Komplexitätsgrad eine ordnende Struktur zur Organisation der Objekte dieser Welt unentbehrlich. Szenegraphen stellen einen Ansatz für diese Aufgabe dar, der einfach und doch sehr mächtig ist. Was Szenegraphen genau sind und wie man sie in der Computergrafik eingesetzt werden, soll dieses Kapitel einführend erklären Allgemeine Struktur Ein Scenegraph ist eine hierarchische Struktur zur Organisation von Objekten in 3D-Welten. Ihm liegt in der Regel ein gerichteter azyklischer Graph (DAG) zugrunde, mit den klassischen Elementen: Knoten, Knoten-Verbindungen und Knoten-Komponenten, also den Knoten zugeordnete Daten. Ein solcher Baum besteht mindestens aus einem Wurzel-Knoten an der Spitze und ggf. mehreren untergeordneten Kind-Knoten, die selbst wiederum Kinder haben können. Fahrrad Rahmen Vorderrad Hinterrad Rahmen-Mesh Rad-Mesh Abbildung 1-5 Ein einfacher Szenegraph In einem Szenegraphen repräsentieren die Knoten grafische Objekte wie z.b. Lichtquellen oder Geometrie (Polygone, Splines usw.). Sie werden mithilfe des Graphen organisiert und positioniert. Sascha Seewald, TU Dresden 12

13 Die Verbindungen von Mutter- zu Kind-Knoten können verschiedene Bedeutungen haben, üblich ist die Vererbung von Transformationen nach unten hin, sodass sich Änderungen an der Lage eines Objektes zugleich auf all seine untergeordneten Objekte auswirken. Die Abbildung 1-5 zeigt einen einfachen Graphen zur Beschreibung eines Fahrrades. Die Wurzel des Baumes stellt ein Gruppen-Knoten, dem drei weitere Knoten untergeordnet sind. Eine Verschiebung des Fahrrad-Knotens würde auch dessen untergeordnete Kind-Knoten verschieben. Jeder dieser drei Knoten verweist auf Geometriedaten (Mesh), die zu seiner Darstellung benötigt werden. Unter der Annahme, dass Vorder- und Hinterrad die gleiche Geometrie zugrunde liegt, können beide auf dasselbe Komponentenobjekt zurückgreifen, auch wenn die Positionen von Vorder- und Hinterrad verschieden sind. Das ist ressourcenschonend und letztendlich auch performanter, denn Rad-Meshes müssen nur einmal im Speicher vorgehalten werden. Jeder Graph kann Teil eines anderen Graphen werden, und so zu beliebig komplexen Strukturen kombiniert werden. Hier ein Beispiel für einen beleuchteten Fahrradständer mit vier Fahrrädern. Szene Lichtquelle Fahrradständer Fahrrad Fahrrad Fahrrad Fahrrad Rahmen Vorderrad Hinterrad Rahmen Vorderrad Hinterrad Rahmen Vorderrad Hinterrad Rahmen Vorderrad Hinterrad Rahmen-Mesh Rahmen-Mesh Rahmen-Mesh Rahmen-Mesh Rad-Mesh Rad-Mesh Rad-Mesh Rad-Mesh Abbildung 1-6 Graph eines Fahrradständers Die Lichtquelle, bewirkt die Beleuchtung des gesamten untergeordneten Graphen, wirkt also als ein Manipulator auf den Subgraphen. Materialknoten wirken ähnlich. Sie kapseln Informationen zur Beschreibung von Oberflächen und vererben ein spezielles Aussehen auf alle ihre untergeordneten Knoten. Sascha Seewald, TU Dresden 13

14 Es ist eine Vielzahl an Knoten mit jeweils eigener Semantik bzw. spezifischem Effekt auf Sub- und/oder Nachbar-Graphen denkbar. Jede Szenegraph-Implementation stellt hier eigene mehr oder weniger fachspezifische Knoten in einer Sammlung - dem NodeKit - bereit Arbeiten auf Szenegraphen Allgemeine Grundlage für das Arbeiten auf Graphen, bildet deren Traversierung, d.h. das Durchlaufen aller Knoten eines Graphen in einer bestimmten Reihenfolge. Im Falle eines Szene-DAGs sind breadth-firsttraversal und depth-first-traversal die bedeutensten Traversierungsarten. Während der Traversierung des Baumes können Operationen auf den durchlaufenen Knoten ausgeführt werden. Die Kombination aus einem Traversierungsverfahren und einer pro Knoten ausgeführten Operation lässt sich zu einer semantischen Einheit - zum Besucher (Visitor) zusammenfassen. Der Besucher wird von der Wurzel ausgehend abwärts durch den gesamten Baum gereicht und führt auf jedem Knoten seine spezifische Aktion aus. Das Visitor-Konzept erlaubt letztendlich die Trennung der Funktionalität von der strukturellen Organisation der Daten, und ermöglicht es, allein durch die Entwicklung neuer Besucher die Operationsvielfalt des Graphen zu erweitern. 1 Szene 11 2 Lichtquelle 10 3 Fahrradständer 9 4 Fahrrad 8 Rahmen Vorderrad Hinterrad Rahmen-Mesh Rad-Mesh Abbildung 1-7 Traversierung eines Graphen Auch die klassischen Problemstellungen der Computergrafik (Rendering, Frustrum-Culling, Animation, Collision-Detection, Picking usw.) lassen sich in Szenegraphen mit speziellen Besuchern lösen. Ein Cull-Visitor beispielsweise, traversiert alle Knoten, prüft jeweils deren Sichtbarkeit, indem das Knoten- BoundingVolume gegen das dem Visitor mitgegebene Frustrum getestet wird und speichert alle sichtbaren Sascha Seewald, TU Dresden 14

15 Objekte für das spätere Rendering. In einer strengen BoundingVolume-Hierarchie, wo also das Volumen eines jeden Knoten die seiner untergeordneten Knoten einschließt, kann die Traversierung für einen ganzen Zweig abgebrochen werden, wenn sein Volumen als nicht sichtbar erkannt wurde. Denn dann werden alle untergeordneten Objekte auch nicht sichtbar sein Szenegraphen im Kontext einer Anwendung Ein Szenegraph stellt im Kontext einer 3D-Anwendung zusammen mit einer 3D-Engine ein eigenes Subsystem dar. Es setzt auf die verfügbaren Low-Level-3D-APIs auf und abstrahiert sie weiter. Der Szenegraph kann die ihm zugrunde liegenden APIs vollständig wegkapseln oder der Anwendung weiterhin direkten Zugriff darauf gewähren. Anwendung Window-System 3D-Engine/ Szene-Graph Sound-System I/O-System Grafik-API (OpenGL, D3D) Audio-API (OSS, DS3D) I/O-API (DI) Grafik-Hardware Audio-Hardware I/O-Hardware Abbildung 1-8 Der Szenegraph im Kontext einer Anwendung Obwohl Szenegraphen, soweit sie hier vorgestellt wurden, zur Beschreibung und Darstellung von visuellen Szenen dienen, erlauben ihr allgemeines Konzept und ihre hohe Flexibilität auch die Integration nichtvisueller Aspekte. So lassen sich beispielsweise Geräuschquellen zur akustischen Gestaltung der virtuellen Welt in einen Szenegraph einhängen. Oder es werden spezielle Physik-Knoten integriert, die Objekten physikalische Eigenschaften wie Masse, Drehmoment und Bruchfestigkeit verleihen und damit die Möglichkeit zur physikalisch korrekten Interaktion schaffen. Selbst Programmlogik lässt sich in Szenegraphen integrieren und variieren, indem zum Beispiel mehrere Verhaltensoptionen in verschiedenen Zweigen kodiert werden und nur der Zweig mit dem gewünschten Verhalten aktiviert wird. Diese Beispiele sollen zeigen, dass die Einsatzmöglichkeiten von Szenegraphen über die visuelle Darstellung hinausgehen - dass sie vielmehr eine flexible Beschreibung aller Aspekte einer virtuellen Welt sein können. Sascha Seewald, TU Dresden 15

16 2 Vergleich von Freien Grafik-APIs Es gibt eine nahezu unüberschaubare Menge an Freier Software zur Erzeugung und Darstellung von 2Dund 3D-Echtzeitgrafik. Kaum ein Anwendungsgebiet, für das nicht eine entsprechende Visualisierungssoftware entwickelt wurde - von der virtuellen Begehung von Architekturentwürfen bis zur Visualisierung des Entstehungsprozess von Zyklonen. So vielfältig wie die Aufgabenstellungen sind, so unterschiedlich sind die gefundenen Lösungen. Die Projekte unterscheiden sich zum Teil gravierend in Ausrichtung, Leistungsumfang, Performance, Entwicklungsmethodik usw. Um in dieser Vielzahl an Projekten, jenes bestimmen zu können, dass in seinem Leistungsumfang und Parametern den Anforderungen der Augentherapie am besten genügt, bedarf es einer geeigneten Evaluierungsmethodik einer Grundlage für die Beurteilung und den Vergleich der verfügbaren Produkte. Dazu ist es zuerst einmal notwendig die allgemeinen und speziellen Anforderungen an ein Grafik-API für den Einsatz in der Augentherapie zusammengetragen. Daraus können anschließend die quantitativen und qualitativen Kriterien abgeleitet werden, nach denen sich die Kandidaten beurteilen lassen müssen. Vornehmliches Ziel dieses Kapitels soll es sein, eine Freies 3D-API zu empfehlen, mit dem sich zukünftige Softwareentwicklungen im Rahmen des Forschungsprojekts durchführen lassen. Das Vergleichsverfahren als solches untergliedert sich in die folgenden Arbeitsschritte: 1. Zusammenstellen einer Anforderungsliste 2. Ableiten der Bewertungskriterien aus diesen Anforderungen 3. Zusammentragen von potentiellen Kandidaten und Vorauswahl dreier zur genaueren Untersuchung 4. Detaillierte Vorstellung der drei Kandidaten 5. Abschließende Gegenüberstellung und Auswahl eines Besten 2.1 Anforderungen Bei der Aufstellung einer Liste von Anforderungen an das zu verwendende API können zwei große Gruppen unterschieden werden. Zum ersten Anforderungen, die sich aus der Anwendung des Programms ergeben - also aus der Analyse der Zielstellungen, Zielgruppen, Zielplattformen, Budgets usw. Daraus lassen sich folgende Anforderungen ableiten: Unterstützung der Windows-Plattform Interaktive Frameraten auf aktueller Low-End-Grafik-Hardware (GeForce2-Klasse) Unterstützung von Stereo-Rendering und Stereo-Hardware oder zumindest die Möglichkeit zur Integration derselben (zur Förderung des stereoskopischen Sehens) Sascha Seewald, TU Dresden 16

17 Keine Nutzung proprietärer Software, um technische und wirtschaftliche Abhängigkeiten von Dritten zu vermeiden Stattdessen: Nutzung von open-source Software Zum zweiten ergeben sich Anforderungen aus der Programmentwicklung. Diese umfasst sowohl die softwaretechnische Seite als auch die inhaltliche/gestalterische Entwicklung. Hier lässt sich folgendes nennen: Leichte Erlernbarkeit des Frameworks Erweiterbarkeit des Frameworks Zukunftssicherheit des Frameworks umfassende Dokumentation mit API-Referenz, Programm-Beispielen, Tutorials, Foren oder Mailinglisten und kommentierter, verständlicher Quellkode C++ Interface Lizensierung des Frameworks unter LGPL oder freierer Lizenz OpenGL-Unterstützng im Framework (zur Anbindung der AmbViz-Bibliothek) Unterstützung üblicher Dateiformate für Grafiken, Sounds, 3D-Modelle usw. Gute Unterstützung aktueller Grafikhardware 2.2 Bewertungskriterien Für die gegebenen Anforderungen sollen im Folgenden Kriterien abgeleitet werden, die als Bewertungsgrundlage bei der Auswahl eines geeigneten Softwarepaketes dienen. Es wird jeweils dargelegt, wie überprüft werden kann, ob und in welchem Maße ein Framework einer bestimmten Anforderung genügt Erlernbarkeit Ein leicht erlernbares Framework muss sich dem Entwickler weitestgehend intuitiv erschließen und einfach zu verwenden sein. Es sollte dem Anwender keine unnötigen Hürden stellen und ihm fehlerträchtige Aufgaben weitestgehend abnehmen. Es sollte lazy learning ermöglichen ( Lerne nur das, was du brauchst und erst dann, wenn du es brauchst! ) und so den individuellen Lernniveaus seiner Anwender gerecht werden. Da jeder Programmierer ganz unterschiedliche Voraussetzungen mitbringt, auf ganz unterschiedlich ausgeprägtes Vorwissen und Erfahrungen zurückgreifen kann, aber auch eine ganz individuelle Lernmethodik für sich entwickelt hat, ist es notwendig, ein quantitativ und qualitativ weites Spektrum an Lernunterstützung anzubieten. Sascha Seewald, TU Dresden 17

18 Dazu zählen die Dokumentation des APIs, Tutorials, Beispielprogramme, aber auch Foren und Mailinglisten, um mit Entwicklern und Anwendern in Kontakt zu kommen. Dem Quellkode fällt in diesem Zusammenhang eine besondere Rolle zu. Use the source, Luke! ein Wortspiel mit dem Ausspruch Use the force, Luke! von Obi-Wan Kinobi in Star Wars stellt das Leitmotto für eine Lern- und Entwicklungsmethode, die so nur mit Freier Software und offenen Quellen funktionieren kann. Anstatt bei einem unerklärlichen Fehler während der Entwicklung wieder und wieder (veraltete?) Dokumentationen zu wälzen oder ungeduldig auf Antworten des Supportteams warten zu müssen, kann und soll der Sourcecode als unverfälschte, immer aktuelle Antwortquelle studiert werden. Das fördert das Verständnis für die Vorgänge im Inneren des Frameworks und verbessert obendrein dessen Qualität, weil etwaige Programmierfehler nicht lange unentdeckt bleiben. Wichtigste Voraussetzung für den Erfolg der Methode ist die Lesbarkeit des Kodes. Das heißt: ausführliche Kommentare, aussagekräftige Bezeichner, übersichtlicher und logischer Quellenaufbau. Ebenfalls unersetzlich für das Verständnis des Frameworks sind Designdokumente, die fundamentale Konzepte und Entwurfsentscheidungen erklären. Wenn die API-Dokumentation die Frage beantwortet, was möglich ist und der Quellkode aufzeigt, wie dies umgesetzt wurde, dann ist es Aufgabe der Designdokumente zu erläutern, warum es genau so und nicht anders getan wurde. Die Erlernbarkeit eines Frameworks zu beurteilen, heißt letztendlich die Beantwortung dieser drei Fragen zu beurteilen. Um die Beurteilung auch praktisch untermauern zu können, sollen jeweils zwei kleine Testprogramme entwickelt werden, die die erlangten theoretischen Erkenntnisse im praktischen Umgang mit dem Framework überprüfen. In dem ersten Test (LoadModelTest) wird ein 3D-Modell geladen und dargestellt. Mit Maus oder Keyboard ist es möglich, das Objekt von allen Seiten zu betrachten. Im zweiten Test (CustomMeshTest) soll ein Polygonobjekt aus gegebenen Dreiecken zusammengesetzt und dargestellt werden. Damit soll zum einen gezeigt werden, wie eine Applikation generell innerhalb des Frameworks aussieht und funktioniert. Zum zweiten werden Hilfen, APIs, Tutorials usw., die ja für so eine Erstentwicklung definitiv benötigt werden, auf ihre Qualität hin untersucht. Letztlich lassen sich nur auf diese Weise fundierte Aussagen zu Intuitivität, Komplexität, Anforderungen eben zur Erlernbarkeit eines Frameworks treffen Erweiterbarkeit/Flexibilität Die Erweiterbarkeit des Frameworks ist Vorraussetzung für Eigenentwicklungen, bei der die gegebene Funktionalität nicht ausreicht. Hier spielen Fragen der Objektorientierung und des Designs eine gewichtige Rolle. Es ist jedoch schwer, dieses Kriterium objektiv zu beurteilen, weil Erweiterbarkeit bei den heutigen Entwicklungsstandards in der Regel weniger eine Frage der Möglichkeit als des Aufwands ist. Letztendlich ist es auch eine Frage des individuellen softwaretechnischen Geschmacks inwieweit ein Framework die Balance zwischen ausbaufähigem Grundgerüst und Goldenem Käfig findet. Bei der Bewertung sollen folgende Fragen als ein Leitfaden dienen. Sascha Seewald, TU Dresden 18

19 Ist das Framework modular aufgebaut? (Komponenten, Module, Plugins, Layering )? Erlaubt das Framework den Entwurf und die Integration eigener Klassen? Wenn ja, mit welchem Aufwand? Erlaubt das Framework die Spezialisierung bestehender Klassen (Strategie, Dekorierer, Stellvertreter)? Wenn ja, mit welchem Aufwand? Erlaubt das Framework den Zugriff auf zugrunde liegende 3D-Hardware über die entsprechenden Low-Level-APIs (OpenGL, D3D)? Wird generisch programmiert (templates, policy based design)? Wird sich an übliche Entwicklungsstandards und -praktiken gehalten, was die Zusammenarbeit mit externer Software erleichtert? Inwieweit deuten bisherige Entwicklungen mit dem Framework auf eine hohe Flexibilität und Erweiterbarkeit hin? Zukunftssicherheit Garantien für die Zukunftssicherheit von Softwareprojekten gibt es nicht. Doch man kann Indizien benennen, die auf eine hohe Lebenserwartung hindeuten, einige Voraussetzungen dafür aufführen und sie überprüfen. Bei der Bewertung dieses Kriteriums sollen folgenden Fragen beantwortet werden: Ist das Projekt noch in aktiver Entwicklung? Existieren eine Roadmap oder andere prospektive Planungen? Verfügt das Projekt über eine große heterogene Entwicklergemeinde? Wird das Projekt häufig eingesetzt und somit Bedarf für den weiteren Fortbestand geschaffen? Freie Software scheint in der Frage der Zukunftssicherheit der proprietären Software einen Schritt voraus zu sein. So kann sie zwar den Tod von Softwareprojekten nicht verhindern, erleichtert ihren abhängigen Projekten jedoch den Umgang mit den Konsequenzen. Durch die Bereitstellung des Quellkodes unter einer open-source Lizenz sind Entwickler weiterhin in der Lage, die veraltete Software selbst zu warten und ihre davon abhängigen Eigenentwicklungen auf ein alternatives Produkt umzustellen. Und nicht selten ergeben sich aus solchen Situationen neue Entwicklungslinien für alte open-source Projekte Lizensierung Bei der Auswahl eines Grafik-Frameworks ist dessen zugehörige Lizenz ein sehr wichtiges Kriterium. Die Lizenz einer Bibliothek kann tief greifende wirtschaftliche, technische und strategische Konsequenzen für das gesamte Entwicklungsprojekt haben. Die Entscheidung für eine GPL-lizensierte Bibliothek hat zum Beispiel zur Folge, dass das Host-Projekt ebenfalls unter die GPL gestellt werden muss, was unter anderem ganz andere Finanzierungskonzepte verlangte. Sascha Seewald, TU Dresden 19

20 Für das hier zu entwickelnde Projekt kommen nur Freie Software Lizenzen in Frage, die jede Art von Nutzung uneingeschränkt zulassen (nicht-kommerzielle wie auch kommerzielle) und nicht mit der Auflage verbunden sind, Modifikationen oder abgeleitetet Entwicklungen wieder unter eine open-source Lizenz zu stellen. Konkret heißt das LGPL oder freiere Lizenzen wie BSDL oder die zlib-lizenz OpenGL-Integration Dieses Kriterium soll sicherstellen, dass sich bisherige OpenGL-basierte Entwicklungen im Rahmen des Forschungsprojekts weiterhin verwenden lassen. Dazu ist zu klären, ob innerhalb des Frameworks problemlos OpenGL-Kode ausgeführt werden kann. Um diese Möglichkeit zu überprüfen, wird ein kleines Testprogramm geschrieben, dass versucht den Teapot aus dem OpenGL Utility Toolkit (GLUT) darzustellen, wobei GLUT-intern ausschließlich OpenGL-Funktionalitäten zum Einsatz kommem (u.a. Displaylisten, Elevators) Dateiformat Unterstützung Eine möglichst große Vielfalt an unterstützten Dateiformaten für Grafiken, 3D-Daten und Sounds ist wünschenswert, da sie die Schnittstelle zu den Content-Entwicklern bilden. Ein proprietäres Austauschformat beschränkt die Auswahl der Content-Entwicklungswerkzeuge auf diejenigen Programme, die das Format direkt unterstützen oder für die ein Exporter vorliegt. Ziel ist jedoch, der inhaltlichen Gestaltung nicht von vornherein Zwänge aufzuerlegen, und einen möglichst freien und praktikablen Umgang mit Mediadaten zu gewährleisten. Für die Bewertung wird die Unterstützung der gebräuchlichsten Formate herangezogen: Bild-Formate: JPG, PNG, BMP, DDS, TIFF, TGA, GIF 3D-Formate: VRML, 3DS, OBJ, X Audio-Formate: WAV, MP3, OGG, MID Features In diese Kategorie soll der Funktionsumfang der Bibliotheken verglichen werden. Dabei steht zum einen die Unterstützung aktueller hardwarenaher Features wie Anti-Aliasing, Vertex- und Fragment-Shader, VertexBufferObjects oder RenderToTexture zur Disposition. Zum zweiten spezielle Komponenten und Techniken, die den Funktionsumfang der Engine über die grafische Darstellung hinaus vergrößern, ihre Einsatzmöglichkeiten erweitern oder die Entwicklung einfach nur effizienter gestalten. Hierunter zählten zum Beispiel eine 3D-Sound-Anbindung, ein PartikelSystem, LOD-Techniken, CharakterAnimation, Physical Simulation, aber auch Unterstützung für MultiThreading, ein virtuelles Dateisystem oder Referenzzählung für Objekte. Sascha Seewald, TU Dresden 20

21 Obwohl die meisten der genannten Features bei der Programmentwicklung im Rahmen dieser Arbeit gar nicht benötigt werden, sollen sie hier der Vollständigkeit wegen aufgeführt werden. Schließlich könnten zukünftige Entwicklungen sehr wohl von diesen Fähigkeiten gebrauch machen Performance Die Performance einer 3D-Engine korrekt zu beurteilen, ist eine komplexe und umfangreiche Aufgabe. Verschiedene Engines in diesem Punkt zu vergleichen, gestaltet sich noch viel schwieriger, gerade dann, wenn sie sich im Leistungsumfang stark unterscheiden. So muss sich bei der Gegenüberstellung auf Anforderungen beschränkt werden, denen alle Kontrahenten einigermaßen gerecht werden können, um nicht von vornherein einen Kandidaten zu benachteiligen. Und selbst wenn hier ein kleinster gemeinsamer Nenner gefunden wurde, gilt es immer noch, Szenarien zu entwickeln, die tatsächlich die Leistung der Engine testen und nicht die der Grafikkarte. So macht es z.b. wenig Sinn die Framerate beim Rendern eines Meshs mit Dreiecken und 500 Zeilen FragmentProgramm als Performance-Kriterium für die Grafik-Software zu werten. Denn 99% Prozent der benötigten Zeit wird dabei von der GPU verbraucht die Engine wartet nur auf die Ergebnisse. Um nun wenigstens einen groben Eindruck von der Performance der Bibliotheken zu erhalten, sollen im Rahmen dieser Arbeit zwei kleine Stress-Tests durchgeführt werden, die die Fähigkeiten der Engine im Umgang mit einer großen Anzahl von Objekten prüfen sollen. Dazu werden zwei Szenen entworfen, die in jedem Framework implementiert und unter gleichen Bedingungen gerendert werden. Die dabei gemessenen niedrigsten, höchsten und durchschnittlichen Frameraten dienen als Vergleichswert für die Performance der Bibliothek. Die erste Szene besteht aus 4096 kleinen Objekten, die in einem kubischen Feld equidistant angeordnet sind. Die Objekte enthalten die Mesh-Geometry aus den CustomMesh-Beispielen mit einem Standard- Material. Es wird bewusst ein sehr einfaches Mesh gewählt, um nicht die Grafikhardware zum Nadelöhr bei den Tests werden zu lassen. Um zusätzlich Bandbreite zu sparen, können alle jeweils verfügbaren Techniken zur Beschleunigung des Rendervorgangs zum Einsatz kommen (shared geometry, VertexBufferObjects, DisplayLists usw.) Die virtuelle Camera wird nicht ganz mittig im Feld positioniert und rotiert mit konstanter Geschwindigkeit um eine diagonale Achse. Eine Punktlichtquelle beleuchtet die Szene. Der zweite Test hat im Wesentlichen den gleichen Aufbau wie der erste, allerdings mit einem feinen Unterschied: die Mesh-Objekte sind diesmal hierarchisch in einem Octree organisiert. Das Testfeld wurde rekursiv in 4 Hierarchieebenen unterteilt, was sich positiv auf die Geschwindigkeit der Sichtbarkeitsbestimmung (culling) auswirken sollte. Sascha Seewald, TU Dresden 21

22 2.3 Vorauswahl der Kandidaten Nachdem die Kriterien für einen fundierten Vergleich von Grafik-APIs aufgeführt worden sind, sollen in diesem Kapitel Freie 3D-Bibliotheken recherchiert und auf ihre potentielle Eignung hin untersucht werden Liste der potentiellen Kandidaten Die Recherche der Kandidaten wurde ausschließlich im Internet durchgeführt. Als besonders fruchtbar erwiesen sich hierbei die Webseiten und Es ist praktisch keine gedruckte Literatur verfügbar, die eine Übersicht zum Angebot an Freien Grafik-APIs bietet. Das liegt wahrscheinlich auch daran, dass nur ein schnelles Medium wie das Internet mit der Entwicklungsgeschwindigkeit dieser Produkte schritt halten kann. Es folgt eine Auflistung der recherchierten Grafik-APIs in alphabetischer Reihenfolge: Blender ( Coin3d ( Crystal Space ( OGRE ( OpenSceneGraph ( OpenSG ( plib ( TheNebulaDevice ( Visualisation Toolkit ( X-Engine ( Bestimmung der Vergleichskandidaten Es folgt eine kurze Vorstellung der Kandidaten. Diese erhebt keinen Anspruch auf Vollständigkeit sondern soll vielmehr einen ersten Eindruck wiedergeben, der sich bei der Recherche im Netz ergab. Dazu wurden von jedem API der aktuelle Stand des Quellcodes, der Dokumentation und aller notwendigen Entwicklungswerkzeuge herangezogen und getestet. Weiterhin wurden Webseiten, Foren und Newsgroups gesichtet. Die oben genannten Kriterien zur Erlernbarkeit, Zukunftssicherheit, Linzensierung und OpenGL-Integration wurden grob überprüft und beurteilt. Projekte, die hierzu keine ausreichenden Informationen bereitstellten, Sascha Seewald, TU Dresden 22

23 sich nicht übersetzen ließen oder einfach nur den Eindruck erweckten, ungeeignet für das Anwendungsgebiet zu sein, wurden disqualifiziert. Blender ist weit mehr als ein 3D-API. Es ist eine komplette Grafik-Entwicklungsumgebung. Eine Sammlung von Programmen, Werkzeugen und Komponenten für alle Aufgabestellungen und Entwicklungsstadien im Bereich Computergrafik. Modelling, Animation, Gamecreation, Realtime- Rendering, Raytracing/Radiosity, WebRendering und vieles mehr zählen zu den Stärken der Blender-Suite. Leider sind nicht alle Teile des Projekts open-source, was Eigenentwicklungen erschwert. Der Einstieg in das Framework erweist sich wegen seines Umfangs ohnehin als sehr schwierig. Die CVS-Distribution enthält im Moment mehr als 4000 Quellkodedateien. Der Schwerpunkt des Projekts liegt offensichtlich jedoch eher auf einer high-level Anwendungsentwicklung. Beispielkode oder Coding-Tutorials ließen sich nicht finden. Allerdings wird auf der Website auf Handbücher und weiterführende Literatur verwiesen. Coin3D ist eine high-level Visualisierungsbibliothek auf Basis von OpenGL und voll kompatible zu SGIs OpenInventor v2.1. Der Funktionsumfang wurde um zusätzliche Komponenten wie GUI- Anbindung zu Win32 und Qt erweitert. Bei der Dokumentation wird gern auf OpenInventor-Literatur verwiesen. Das Lizenzmodell ist die GPL. CrystalSpace, eigentlich ein Game-Developement-Kit, präsentiert das API sich beim ersten Lesen der Featurelist als umfangreiches Visualisierungsframework mit zahlreichen Beispielprogrammen und guter teils mehrsprachiger Dokumentation. Die Engine erfreut sich bei der open-source- Community großer Beliebtheit, wofür die zahlreichen Entwicklungs-Projekte und regen Diskussionen in den Foren sprechen. Obwohl die Ausrichtung auf die Spielentwicklung nicht zu verkennen ist, loht sich wahrscheinlich ein näherer Blick auf das Framework. OGRE (Objekt-Oriented Graphics Rendering Engine) ist ein high-level Visualisierungsframework auf Basis von OpenGL oder Direct3D. Es verfügt über ein ausgefeiltes Design und kann mit bemerkenswertem Funktionsumfang aufwarten. Der sehr gute Entwickler-Support auf der Website und die interessanten Features qualifizieren ORGE für genauere Untersuchungen. OpenSceneGraph ist ein Grafik-Toolkit auf Basis von OpenGL. Der zentrale Kern der Bibliothek ist ein Szenegraph, in den Darstellungs-Objekte und GL-States in Form von Knoten eingehängt werden können. Herausragend sind das Angebot an fast 60 einfachen und anspruchsvollen Beispielprogrammen und die ausführliche Dokumentation des API. Um OSG scheint sich eine große Fangemeinde gefunden zu haben, welche zahlreiche ergänzende Projekte zu OSG hervorgebracht hat, die sich nahtlos in das Framework einfügen. Auf jeden Fall einen intensivieren Blick wert. OpenSG ist der OpenSceneGraph-Bibliothek sehr ähnlich. Das vom BMBF geförderte Projekt setzt ebenfalls auf einen Szenegraphen über OpenGL auf. Die Ausrichtung der entwickelten Komponenten ist jedoch deutlich wissenschaftlicher bzw. technischer. Leider ist die Dokumentation noch sehr lückenhaft, obwohl fast 20 ausreichend dokumentierte Beispielprogramme zur Verfügung Sascha Seewald, TU Dresden 23

24 gestellt werden. Was beim ersten Überfliegen von OpenSG-Code sofort unangenehm auffiel, war die Notwendigkeit jede Änderung an einem OpenSG-Objekt in einen begineditcp( )/endeditcp( )-Block zu fassen, was die Multithreading-Fähigkeit des Codes sicherstellen soll. Hierbei stellt sich die Frage, ob die Vorzüge dieses ungewöhnlichen Designs die Umständlichkeit bei der Implementation rechtfertigen, zumal andere Bibliotheken elegantere Lösungen für dieses Problem gefunden zu haben scheinen. plib ist eigentlich ein Verbund von interoperierenden Bibliotheken. Es ist das einzige Projekt dieser Liste, das nicht in c++ geschrieben ist, sondern vielmehr in ANSI-C. Obwohl das noch keine Schlüsse auf die Qualität der Software zulässt, sollen hier doch nur objekt-orientierte Lösungen untersucht werden. TheNebulaDevice ist eine open-source-gameengine entwickelt von der RadonLabs GmbH - einer Berliner Spielschmiede - und der open-source-community. Das Design der Engine ist sehr modular und gut erweiterbar innerhalb eines strengen Frameworks. Die Code-Dokumentation der Module ist ausreichend, doch es fehlen Beispiele für den Einstieg und weiterführender Support wie Foren oder Mailinglisten. Der OpenGL-Support ist erst in der Entwicklung. VTK (The Visualization Toolkit) ist ein professionelles Framework für Image-Prozessing, Volumerendering und andere Aufgabenstellungen im wissenschaftlichen Bereich. Obwohl die Dokumentation gut ist und zahlreiche Beispiele vorhanden sind, decken sich Funktionsumfang und Ausrichtung der Bibliothek allgemein nicht mit denen des zu entwickelnden Projekts. Die X-Engine ist eine kleine aber moderne Bibliothek im Entstehungsprozess. Sie ist 3D-APIunabhängig und hat sich auf die Integration der neuesten Hardwareentwicklungen spezialisiert. Leider ist die Dokumentation noch unausgereift. Umfangreiche Design-Dokumente geben zwar Aufschluss über die zugrunde liegende Architektur, ersetzen jedoch keine Tutorials. Beispielprogramme sind vorhanden, jedoch schlecht kommentiert. Die Abbildung 2-1 fasst nochmals die APIs und ihre vorläufige Bewertung in einer Übersicht zusammen. Die markierten Kandidaten schnitten bei dieser Vorauswahl am besten ab und werden in den folgenden Kapiteln detailliert vorgestellt und verglichen. Sascha Seewald, TU Dresden 24

25 API Lizenz Support/Dokumentation/ Tutorials/Foren/Mailinglisten Beispielkode Aktive Entwicklung OpenGL- Anbindung möglich Blender Non- OS/GPL/BL - - ja? Coin3D GPL - - ja ja CrystalSpace LGPL + + ja? OGRE LGPL ++ + ja? OpenSceneGraph OSGPL (LGPL) ja ja OpenSG LGPL - + ja ja plib LGPL + o nein? TheNebulaDevice Tcl/Tk o - ja? VTK wie zlib o + ja? X-Engine zlib/libpng - o ja? Abbildung 2-1 Zusammenfassung der Vorauswahl 2.4 Vorstellung der drei Kandidaten CrystalSpace Installation Grundlage der durchgeführten Untersuchungen bildet die aktuelle Release-Version 0.98r001 aus dem CVS. Die Installation und Kompilierung des umfangreichen SDK gestalten sich problemlos, dafür sorgen unter anderem die mitgelieferten Projektfiles für VC6 und VC7 und die sehr gute Dokumentation des Installationsprozesses. Engine und Beispielprogramme lassen sich übersetzen, sofern alle notwendigen Bibliotheken verfügbar sind. Zur Ausführung der Demoanwendungen aus der IDE heraus muss ein Datenpaket installiert werden und die entsprechenden Ausführungspfade gesetzt werden, da sonst die zahlreichen Module und Plugins der Engine nicht gefunden werden. Negativ fiel auf, dass nicht alle Headerfiles der Bibliothek in einem separaten CS-spezifischen Include- Verzeichnis gehalten werden. Damit kann es zu ungewollten Interferenzen mit gleichnamigen Headern anderer Projekte kommen (z.b. platform.h). Dieser Umstand wird zusätzlich verschärft da CrystalSpace keinen eigenen Namensraum für seine Bezeichner nutzt, was schnell zu gefährlichen Überlagerungen im globalen Namensraum führen kann. Sascha Seewald, TU Dresden 25

26 Übersicht CrystalSpace ist ein komplett modularisiertes Softwaresystem. Mehr als Zeilen Kode verteilen sich auf einige wenige Kernkomponenten und zahlreiche Module, in Form von Plugins. Die Abbildung 2-2 zeigt die wichtigsten Systemteile auf. Abbildung 2-2 CrystalSpace Architektur Erlernbarkeit CrystalSpace hält einige umfangreiche Dokumente bereit, die dem Anwender den Einstieg in das System erleichtern sollen. Ein sehr ausführliches Manual führt in die Distribution ein, erklärt alle notwendigen Schritte bei der Installation und stellt die einzelnen Systemteile detailliert vor. Drei kleine Tutorials und eine HOWTO-Sektion mit wichtigen Hintergrundinformationen runden dieses umfangreiche Handbuch ab. Weiterhin wurden zahlreiche Tutorials von der Community eingebracht, die auf der Website verlinkt sind. Besonders hervorzuheben ist dabei Maze Game Tutorial, in dem schrittweise ein voll funktionsfähiges Spiel mit CrystalSpace entwickelt wird. Die API-Referenz wurde mit doxygen erstellt und ist stellenweise leider sehr einzeilig. Sascha Seewald, TU Dresden 26

27 CrystalSpace pflegt eine stark frequentierte Mailingliste mit über 700 registrierten Anwendern. Ein Wiki- Board stellt zusätzlichen Informationen, Tutorials, Links und eine kleine, gut organisierte FAQ-Sammlung bereit. So gut die aufgeführten Dokumente sind, so notwendig sind sie auch, wenn man ernsthaft mit CrystalSpace arbeiten möchte. Denn die Bibliothek ist selbst für erfahrene 3D-Entwickler höchst eigenwillig was Strukturen, Konzepte und Bezeichner anbelangt. So wird beispielsweise um ein Objekt, welches nur Dreiecks-Geometrie speichern soll (gemeinhin: Mesh) ein komplizierter Apparat aus imeshobject, csmeshobject, csmeshfactory, imeshobjectfactory, imeshwrapper und imeshfactorywrapper gesponnen, wobei keines dieser Objekte wirklich das ist, was der Name vermuten lässt. Eigene Geometrie muss an einer Instanz von igeneralfactorystate definiert werden, woraus sich schließlich Objekte vom Typ igeneralmeshstate generieren lassen das gewünschte Mesh. Der folgende Kode zeigt einen Ausschnitt aus dem CustomMesh-Beispiel: // Mesh-Fabrik erzeugen csref<imeshfactorywrapper> factory = engine->createmeshfactory("crystalspace.mesh.object.genmesh", "myfactory"); // spezielle Schnittstelle anfordern csref<igeneralfactorystate> factorty_state = SCF_QUERY_INTERFACE(factory->GetMeshObjectFactory(), igeneralfactorystate ); // Verticen setzen factory_state->setvertexcount(vertex_count); for ( int i = 0; i<vertex_count; i++ ) factory_state->getvertices()[i].set(...); // Dreiecke setzen factory_state->settrianglecount(triangle_count); for ( int t = 0; t<triangle_count; t++ ) factory_state->gettriangles()[t].set(...); // Normalen berechen factory_state->calculatenormals(); // in der Fabrik eine Instanz des Prototypen erzeugen lassen csref<imeshwrapper> mesh = engine->createmeshwrapper(factory, "mycube"); // spezielle Schnittstelle anfordern... csref<igeneralmeshstate> mesh_state = SCF_QUERY_INTERFACE( mesh->getmeshobject(), igeneralmeshstate); //... und ein Material setzen mesh_state->setmaterialwrapper(mymaterial); Sascha Seewald, TU Dresden 27

28 Das CrystalSpace-Framework enthält zahlreiche Stolperfallen, die Anfängern die Entwicklung unnötig schwer machen. Beispielsweise muss einem Mesh unbedingt ein Material zugewiesen werden, ansonsten kommt es beim Rendern zu einer Zugriffsverletzung. Mesh-Objekte ohne Material müssen mittels eines leeren Materials nachgebildet werden. Im folgenden Kodebeispiel darf keinesfalls die letzte Zeile vergessen werden, oder die durchgeführten Änderungen an der Position eines Objekts bleiben unberücksichtigt. Hier hätte man sich einen für den Anwender transparenten Update-Mechanismus gewünscht // Zugriff auf das Transformations-Objekt des Mesh erlagen imovable* movable = mesh->getmovable(); // dieses einem Sektor hinzufügen (CrystalSpace ist eine Portal-Engine!) movable->setsector(room); // die gewünschte Position setzen movable->setposition( csvector3(1,2,3) ); // und diesen Aufruf nicht vergessen!!! movable->updatemove(); Bezeichner sind teilweise unglücklich gewählt: ein Sprite ist nicht wie üblich ein kleines 2D-Bitmap sondern ein spezielles 3D-Mesh. Ein Model ist kein 3D-Modell sondern eine komplette Szene mit Lichtquellen und Cameras. Weiterhin orientiert sich CrystalSpace funktional noch immer sehr stark an dem Einsatzgebiet für das es ursprünglich entwickelt wurde: das Portal-Rendering. Ohne das Verständnis für diese spezielle Form des Renderings erschließt sich die Bibliothek dem Neuling nicht. Zusammenfassend muss man leider sagen, dass CrystalSpace hauptsächlich durch seine unintuitiven Konzepte und Bezeichner und trotz der guten Unterstützung mit Lehrmaterialien nur schwer zu erlernen ist Erweiterbarkeit CrystalSpace verwendet einige interessante Mechanismen, um Flexibilität und Erweiterbarkeit sicherzustellen. Zuerst fällt dabei das komplexe Plugin-System auf. CrystalSpace-Plugins machen ihre Funktionalität dem System bekannt, indem sie ihre bereitgestellten Objekte bei einer zentralen Registratur (ObjectRegistry) anmelden. Eine spezielle Technik (Shared Class Facility) erlaubt es, später bei dieser Registratur Objekte anzufordern, die eine bestimmte Schnittstelle zur Verfügung stellen können (ähnlich wie bei COM). // abstrakte Schnittstelle zu einem Renderer irenderer* renderer = 0; // Anfordern eines konkreten Objekts mit irenderer-schnittstelle // bei der Objekt-Registratur renderer = CS_QUERY_REGISTRY(obj_reg, irenderer); Sascha Seewald, TU Dresden 28

29 Ist kein solches Objekt registriert worden, liefert die Anfrage 0 zurück, anderenfalls ein passendes Objekt. Dieser Mechanismus macht CrystalSpace sehr flexibel bei der Einbindung neuer Komponenten mit dem zusätzlichen Vorteil, dass bestehender Client-Kode dazu nicht angepasst werden muss. Das Schnittstellen-Prinzip wurde auch konsequent auf die Objektebene übertragen, wo Klassen immer aus einer öffentlichen, rein abstrakten Schnittstelle (Prefix i ) und privaten, variablen Implementationen (Prefix cs ) bestehen (ähnlich den Java Interface). Bei der Einführung eines eigenen Typs wird einfach von einer oder mehreren Schnittstellen geerbt und die geforderte Funktionalität implementiert. Helfer-Macros (wie SCF_IMPLEMENT_IBASE) nehmen dem Entwickler einige Arbeit ab. Trotzdem wirkt CrystalSpace im Detail etwas steif und unhandlich. Es besitzt keinen Scenegraph oder etwas Ähnliches. Viele starre Schnittstellen betonieren das System ein und machen es schwer erweiterbar. Man merkt, dass das Projekt schon 1997 begonnen wurde, in Zeiten als noch fast ausschließlich in Software gerendert wurde und 3D-Hardware erst im Aufkommen war. Obwohl die Engine damals ohne Frage auf dem neusten Stand der Technik war, ist es ihr offensichtlich schwer gefallen, mit den rasanten Entwicklungen in den Bereichen Computergraphik und Softwaretechnik schritt zu halten. Trotz dessen hat die Engine eine große Fangemeinde. Es wurden unzählige Spiele für die verschiedensten Plattformen auf ihrer Basis entwickelt. Ebenso wie Editoren, Converter, Importer/Exporter, Sprachanbindungen usw. In dieser Beziehung hat sich die lange Lebenszeit des Projekts ausgezahlt Spezielle Features Portal-Engine Plattformunabhängiges virtuelles Dateisystem (VFS) mit transparentem Zugriff auf zip-dateien Script-Anbindung für Python, Perl und Java Script Statische und dynamische Schatten 3D-Audio, Physik und Animationen OGRE Installation OGRE wird - wie alle Projekte in diesem Vergleich - von SourceForge [35] gehostet und erleichtert so den zentralen Zugriff auf Quellen, Binaries und Daten. Dank der mitgelieferten VisualStudio-Projektfiles erweist sich der Buildvorgang als unkompliziert. Die Beispiele lassen sich übersetzen, führten jedoch teilweise zu Abstürzen. Als hinderlich bei der Entwicklung einer eigenständigen Anwendung mit OGRE erwies sich die Organisation der Module, Header und Binaries. Obwohl OGRE als Framework konzipiert ist, folgt es nicht der üblichen Struktur einer Bibliothek mit jeweils einem zentralen Ordner für Header, Libs und Binaries. Vielmehr liegen diese Dateien auf mehreren Modulen in verschiedenen Verzeichnissen verteilt, was zu verzweigten Datei- und Verzeichnis-Abhängigkeiten beim Erstellen und Ausführen führt. Weiterhin können Sascha Seewald, TU Dresden 29

30 die Kompilate der verschiedenen Buildkonfigurationen (Debug & Release) nicht dem Namen nach unterschieden werden. Um diese Probleme zu umgehen, empfehlen die Entwickler, eigene Applikationen innerhalb des OGRE Beispielprojektpfades zu entwickeln. Hier erleichtern relative Pfade zu Headern und Binaries die Konfiguration der Buildumgebung. Ein sehr gutes Einsteiger-Tutorial führt schrittweise durch die notwendigen Konfigurationen. Der größte Nachteil dieser Lösung ist die ungewollte Vermischung des eigenen Projektkodes mit dem des Frameworks. Die im Rahmen dieser Arbeit entwickelten Beispielprogramme, sind getrennt von OGRE in separaten Verzeichnissen organisiert Architektur Die im Folgenden vorgestellten Klassen bilden die Kernkomponenten der OGRE-Engine. Ein Root-Objekt stellt den zentralen Einstiegspunkt zur ORGE-Engine dar. Es wird als Singleton von der Anwendung gehalten und ermöglicht den Zugriff auf alle wichtigen Systemkomponenten wie RenderSystem, SceneManager, ResourceManager usw. Alle Phasen des Renderings können hierüber manipuliert und bequem gesteuert werden. Beispielsweise wird mit der Methode showconfigdialog() ein Dialog aufgerufen, über den die wichtigsten Darstellungsparameter wie das zu verwendende 3D-API, Auflösung und Farbtiefe bequem eingestellt werden können. Die Ergebnisse werden automatisch an den ORGE-Kern weitergeleitet und umgesetzt. Insgesamt bildet das Root-Objekt eine Fassade zu den komplexeren Subsystemen der Engine. Ein RenderSystem nimmt Zeichenanfragen entgegen und setzt diese auf das jeweilige 3D-API um. OGRE hält im Moment drei dieser Systeme zur Auswahl: GLRenderSystem, D3DRenderSystem und D3D9RenderSystem. Komponenten, die auf RenderSystem-Funktionalität zugreifen, tun dies selbstverständlich über eine abstrakte Schnittstelle (RenderSystem), die die konkrete Implementation wegkapselt. Obwohl diese Komponente in OGRE eine zentrale Rolle spielt, hat der Nutzer relativ wenig direkten Kontakt damit. Das liegt vor allem daran, dass durch die Engine zahlreiche Objekte angeboten werden, die bereits ihren Zeichenmechanismus implementiert haben der Anwender kann diese einfach benutzen, ohne sich noch um die Details des Rendering kümmern zu müssen. Die Aufgabe der SceneManager liegt in der Verwaltung von Objekten der virtuellen Welt. Sie enthalten in der Regel einen SceneGraph, der für die Art der Szene zugeschnitten ist. Beispielsweise bietet OGRE einen BSPSceneManager an, der auf die Darstellung von Indoor-Welten zugeschnitten ist, die optimalerweise mittels BSP und PVS organisiert sind. SceneManager übernehmen wichtige Aufgaben beim Prerendering, insbesondere das Culling und die Vorsortierung der Objekte. Sie erstellen eine Renderqueue und senden diese zur Darstellung an das aktuelle RenderSystem. OGRE hat eine eigene Ressourcenverwaltung für Daten jeglicher Art (Texturen, Geometrie, Materialen, Shader usw.). Die jeweils zuständigen ResourceManager bieten einheitliche Schnittstellen zur Organisation von Ressourcen. Ressourcen werden bei Bedarf automatisch geladen bzw. entladen und können über eindeutige String-Handles identifiziert werden. Sascha Seewald, TU Dresden 30

31 Erlernbarkeit ORGE macht Anfängern den Einstieg in die Engine sehr leicht. Auf der Website (bzw. der Distribution beiliegend) findet sich eine Readme-Seite, die den interessierten Leser in das Projekt einführt, die verschiedenen Lern- und Hilfesysteme vorstellt und Hinweise zu den ersten Schritten mit OGRE gibt. Ein Manual, stellt die wichtigsten Systemteile vor und kann erste konzeptionelle Fragen klären. Die Qualität der API-Referenz (Doxygen) ist sehr gut. Der Quellkode ist fast akribisch strukturiert und ausführlich kommentiert. OGRE hat zur Unterscheidung interner und öffentlicher Funktionalität eine eigene Nomenklatur eingeführt: Bezeichner mit vorangestelltem Unterstrich sind mehr oder weniger für den OGRE-internen Gebrauch gedacht, und sollten nur mit Vorsicht benutzt werden. Meistens liegen bei Methoden dieser Art kontextspezifische Abhängigkeiten vor, die durch den Aufrufenden korrekt behandelt werden müssen. Die Auffälligkeit im Namen, weist den Programmierer gezielt auf diese Problematik hin und versucht so, Programmierfallen zu reduzieren. Unbeantwortet gebliebene Fragen können schließlich in einem der moderierten Foren gestellt werden. Der Lead-Programmer Steve Streeting beantwortet den Großteil der Fragen selbst. OGRE bietet eine Reihe von Tutorials an, um den Nutzer bei der Entwicklung seiner ersten Anwendung zu unterstützen. Installation der Engine, Konfiguration der Entwicklungsumgebung, Setup der Projektfiles und der erste RenderLoop werden Schritt für Schritt erklärt. Die wichtigsten Features der Engine werden in 24 Demoprogrammen anschaulich vorgestellt Erweiterbarkeit/Flexibilität OGRE s Software-Design ist durchdacht und auf das Einsatzgebiet zugeschnitten. Es stellt ein gutes Grundgerüst für eigene (Rapid-)Entwicklungen dar. Die Engine ist auf wenige mächtige Subsysteme verteilt und macht regen Gebrauch von OO-Spezifika wie Abstraktion, Kapselung und Polymorphie. Ein integriertes Plugin-System erlaubt Funktionserweiterungen ohne Neukompilierung. Eingeführte Konzepte werden konsequent umgesetzt ( alle Daten sind Ressourcen - zu jeder Ressource gehört ein zuständiger Manager ). Die Spezialisierung bestehender Klassen kann nur durch Ableitung erfolgen. Obwohl OGRE prinzipiell OpenGL unterstützt, gibt es keine saubere Möglichkeit eigenen OpenGL-Kode auszuführen. Dem Design folgend soll und darf der Anwender nur Plattform- und API-unabhängigen Kode schreiben. OGRE arbeitet mit der STL zusammen, nutzt allerdings eine eigene String-Implementation (Ogre::String), die jedoch zu std::string kompatibel ist. Auf der Website werden momentan 25 Projekte benannt, die OGRE zum Rendering einsetzen. Inhaltlich sind alle Projekte im Spiel-Sektor angesiedelt. An der TU Delft (NL) dürfen Studenten in ComputerGrafik- Kursen sogar mit OGRE ihre ersten 3D-Spiele entwickeln. Trotz allem muss festgestellt werden, dass OGRE s gute Erweiterbarkeit nur innerhalb eines strengen Rahmens gewährt wird. Die Engine lässt sich sehr gut nach unten hin spezialisieren, aber nur schwer nach links und rechts erweitern. Beispielsweise würde die Unterstützung von Stereo- oder Panorama-Rendering wahrscheinlich tief schürfende Eingriffe in Sascha Seewald, TU Dresden 31

32 SceneManager oder RenderSystem erfordern, mit Konsequenzen für das gesamte System. Hier wäre ein sauberes Layering zur Trennung von Szene, Rendersystem und Darstellungsweise wünschenswert. Zwischen den Komponenten existiert eine starke Verflechtung - sie tendieren zu monolithischen Schwergewichten mit all-in-one-funktionalität, bieten aber dafür den Vorteil der leichten Bedienbarkeit. Leider bringt der integrierte Szenegraph dem Anwender nur schwachen Nutzen. Seine Funktionalität beschränkt sich auf die Vorwärtsvererbung der Transformation und die Gruppierung von Objekten in speziellen Hierachien wie Octrees oder BSPs. Obwohl die OGRE-Entwickler den multi-purpose Charakter der Engine hervorheben, ist die Ausrichtung auf 3D-Spieleanwendungen nicht zu übersehen. Mit alleinigem Blick auf dieses Anwendungsgebiet, eignet sich OGRE sehr gut für Entwicklungen, bei denen man schnell und unkompliziert zu hochwertigen Ergebnissen kommen möchte Spezielle Features OGRE kann mit einer großen Menge an Features aufwarten, die hier auszugsweise aufgeführt werden sollen: Support für Cg oder HLSL-Shader (Ogre::GpuProgramm) ParticleSystem mit zahlreichen Emittern und Affektoren (Ogre::ParticleSystem, Ogre::ParticleEmitter, Ogre::ParticelAffector) ShadowSystem mit Unterstützung für verschiedene Render-Techniken (Stencil, Texture), an Objekten und Lichtquellen individuell einstellbar (Ogre::SceneManager) Scriptbare Materialien, Partikel, Overlays usw. Skeletal Animation (Ogre::Skeleton) Ein Einheitliches Animationssystem (Ogre:Controller) OpenSceneGraph Installation Die Installation von OSG erweist sich als unproblematisch. Quellkode, Binaries und Testdaten der Releases liegen in getrennten Paketen vor. Der aktuelle Stand des Quellkodes wird in einem nightly tarball oder direkt via CVS angeboten. Zur Compilierung werden OpenThreads [34] und OpenProducer [33] benötigt. Zahlreiche Plugins setzen auf weiteren Bibliotheken auf, die jedoch nicht zwingend erforderlich für den OSG-Kern sind. In einem VC6- Workspace sind alle notwendigen Einstellungen für den Erstellungsprozess zusammengefasst. Die Integration in VS.NET 2003 funktioniert reibungslos. Alle Beispielprogramme werden fehlerfrei übersetzt und funktionieren mit den bereitgestellten Daten einwandfrei. Sascha Seewald, TU Dresden 32

33 Übersicht OSG s Architektur orientiert sich stark an den großen kommerziellen Visualisierungspaketen wie IRIS Performer und Inventor. Den Kern des Systems bildet ein multifunktionaler SceneGraph auf Basis von OpenGL. Ein NodeKit stellt klassische OpenGL-unabhängige SceneGraph-Knoten zur Verfügung. Ein osg::geode- Knoten z.b. speichert Darstellungsobjekte, ein osg::transform-knoten transformiert den untergeordneten Subgraph, ein osg::lightsource-knoten beleuchtet die Szene usw. Die zugehörigen Knoten-Komponenten reflektieren dann jeweils spezifische OpenGL-Funktionalität. So ist ein osg::geode-knoten eigentlich ein Container für osg::drawables, eine Gruppe von Komponenten, die OpenGL Zeichen-Operationen abbilden (gldrawarrays() osg::geomerty, gldrawpixels() osg::drawpixels, gluquadric osg::shapedrawable). OSG steht durch die Knoten-Komponenten in direkter Beziehung mit OpenGL. Noch deutlicher wird dies bei der Manipulation der GL-States (z.b. glcolor(), glfog(), glviewport()). OSG s StateKit führt für jede Variable der GL-StateMachine eine eigene Klasse ein (osg::stateattribute), die die State-spezifischen Daten speichert (z.b. die Koordinaten eines Rechtecks bei osg::viewport) und sich in der Regel auch bequemer bedienen lässt als die adäquaten Funktionen in OpenGL. Jeder Knoten besitzt einen Container (osg::stateset), der solche State-Objekte aufnimmt und vor dem Renderprozess anwendet. Um die Darstellungsparameter für ein Geometrie-Objekt zu ändern, müssen die gewünschten Änderungen in dem zugehörigen StateSet durchgeführt werden. Der folgende Kode veranschaulicht, wie ein Mesh mit einem bestimmten Material versehen wird. // erzeuge einen Knoten mit Meshdaten osg::geode* mesh = createsomemesh(); // hole das zugehörige StateSet (wird bei Bedarf erst erzeugt) osg::stateset* stateset = mesh->getorcreatestateset(); // erzeuge und konfiguriere ein Material osg::material* material = new osg::material(); material->setdiffuse( FRONT_AND_BACK, osg::vec4(1,0,0,1) ); // speichere das Material im StateSet des Meshs stateset->setattribute( material ); osg::stateattributes werden standardmäßig auf hierarchisch untergeordnete Knoten vererbt. Dieses Verhalten ist jedoch konfigurierbar. Ein ausgeklügelter Mechanismus verknüpft die StateSets verschiedener Knoten entlang des Baumes nach benutzerdefinierten Regeln. So lässt sich beispielsweise der Drahtgitter- Rendermodus für die gesamte Szene erzwingen, wenn auf den Wurzel-Knoten des Szenegraphen folgender Kode angewendet wird: // StateSet des Wurzelknotens holen osg::stateset* stateset = root->getorcreatestateset(); Sascha Seewald, TU Dresden 33

34 // PolygonMode StateAttribute Objekt erzeugen (kapselt glpolygonmode()) osg::polygonmode* pm = new osg::polygonmode; // Modus setzen (wireframe) pm->setmode( FRONT_AND_BACK, LINE ); // Attribut speichern und das Überladen aller untergeordneten States // dieses Typs erzwingen stateset->setattributeandmode( pm, OVERRIDE ); Die StateAttribute in StateSets untergeordneter Objekte werden wegen des gesetzten OVERRIDE-Flags überschrieben. In dem Beispiel würden also alle PolygonMode-StateAttribute im Subgraph ignoriert und daher die gesamte Szene im Drahtgittermodus dargestellt werden. Der OSG RenderProzess gliedert sich in die drei Phasen: Update Cull Draw, die pro Frame mindestens einmal durchlaufen werden. Jede Phase dient der Durchführung einer einzigen, klar abgegrenzten Aufgabe und wird jeweils mithilfe eines speziellen Visitors umgesetzt. In der Update-Phase wird der Graph auf den neusten Stand gebracht. Hier werden animierte Objekte aktualisiert und benutzerdefinierte Manipulationen am Graph durchgeführt. Dieser Update-Schritt findet in der Regel einmal pro Frame statt. Die Cull-Phase dient der Sichtbarkeitsbestimmung und Vorbereitung des eigentlichen Zeichenvorgangs. Sie ist spezifisch für eine gewählte Sicht und kann pro Frame auch mehrfach durchlaufen werden (z.b. für dynamisches Reflection-Mapping, wo pro Frame bis zu sechs Sichten gerendert werden). Ein Cull-Visitor durchläuft den Baum und stellt den besuchten Knoten Informationen über den aktuellen Renderkontext zur Verfügung. LOD-Knoten können so z.b. nach ihrem Abstand zum Betrachter oder nach ihrer Pixel-Größe auf dem Bildschirm fragen und entsprechende Detailstufen auswählen. Gleichzeitig prüft der Visitor die Sichtbarkeit aller Knoten (BoundingSphere-Hierarchie) und hängt alle sichtbaren Objekte in eine Render- Warteschlage ein. In der Draw-Phase wird diese Queue nach bestimmten Kriterien sortiert und schließlich durch OpenGL gezeichnet. Geschickte gewählte Sortierkriterien können die Performance des Renderings ungemein erhöhen. Beim State-Sorting z.b. werden die grafischen Objekte entsprechend ihrer Darstellungsparameter geordnet, um die zeitaufwendigen Änderung von States und der zugehörigen Daten - wie Texturen - zu reduzieren. In verdeckungsreichen Szenen kann die Tiefensortierung der Objekte von vorne nach hinten zu erheblich geringerem Overdraw führen. OpenSceneGraph erlaubt über Callbacks die freie Gestaltung dieses Sortiervorgangs. Cull und Draw greifen per Definition nur lesend auf den SceneGraph zu in der Update-Phase darf auch geschrieben werden. Das erlaubt es, viele Cull- und Draw-Stufen zu parallelisieren und auf verschiedene Threads zu verteilen. So wird es auch möglich, gleichzeitig mehrere Ansichten ein und desselben Graphen zu rendern, sogar auf einem verteilten System mit mehreren Grafikkarten oder RenderClients. Sascha Seewald, TU Dresden 34

35 Erlernbarkeit OpenSceneGraph-Programmierung zu erlernen, fällt nicht schwer, wenn bereits OpenGL-Grundkenntnisse vorhanden sind. Obwohl man bei der Arbeit mit OSG niemals einen OpenGL-Bezeichner benutzen muss, ist es von Vorteil, die fundamentalen Konzepte dieser mächtigen Grafik-Bibliothek zu kennen und zu verstehen. Diesbezüglich fehlendes Vorwissen würde den Einsteig in OSG ungemein erschweren, zumal sämtliche angebotenen Lehrmaterialien darauf voraussetzend Bezug nehmen. Die teilweise etwas veraltete Website bietet gute Informationen für den Einstieg. Motivation, PowerPoint- Präsentationen mit konzeptionelle Grundlagen, Artikel mit Hintergrundinformationen, Installationshinweise, Links zu Referenzdaten und eine FAQ helfen, sich ein erstes Bild zu machen. Fast 60 sehr gut kommentierte Beispielprogramme führen den Neuling in OSG s umfangreiches Objektsystem ein und zeigen Tricks und Techniken auf, mit denen man am meisten von dem Framework profitieren kann (Callbacks, AttributeFunctors, Primitive-Iterator ). Zusätzlich dazu hat die Community dem Projekt zahlreiche Tutorials in unterschiedlichsten Schwierigkeitsgraden beigesteuert. Leider ist die API-Referenz stellenweise etwas schwach dokumentiert. Eine Mailinglist mit über 900 registrierten Entwicklern bietet Hilfe bei Fragen die sich aus Dokumentation und Beispielkode heraus nicht beantworten lassen Erweiterbarkeit/Flexibilität OpenSceneGraph bietet seinen Anwendern in jeder Beziehung ein hohes Maß an Flexibilität. Zum einen garantiert das SceneGraph-Konzept allein schon gute Erweiterbarkeit. Der Szenegraph kann ohne weiteres durch neue funktionelle Knoten ergänzt werden. Neue Visitor können spezifische Anfragen auf dem Graph ausführen (osg::pickvisitor), ohne dass dessen Elemente je darauf vorbereitet werden mussten. Zum zweiten sind OSG s Komponenten sehr feingliedrig, was einerseits durch die relativ hohe Anzahl von Klassen die Komplexität erhöht, andererseits jedoch viel leichter zu warten und zu erweitern ist als schwergewichtige, stark gekoppelte Klassenhierarchien. So ist es vollkommen unkompliziert, Neuerungen der OpenGL in OSG einzuarbeiten. Beispielsweise wurde bei der Integration von Shadern nur ein einziges neues StateAttribute eingeführt - osg::vertexprogramm, welches nun wie üblich in einem StateSet eingesetzt werden kann. Die langen Entwicklungszeiten für systemweite Änderungen und Anpassungen der Clientsoftware, wie sie bei anderen APIs in solchen Situationen häufig notwendig werden, entfallen. Im Bezug auf die Erweiterbarkeit fällt OSG s Callback-Mechanismus besonders positiv auf. An Knoten und deren Komponenten lassen sich Callback-Funktionen für die verschiedenen Render-Stages registrieren, die während der Ausführung der entsprechenden Phase zurückgerufen werden und dem Anwender die Kontrolle über den weiteren Verlauf geben. Bei osg::drawables lässt sich beispielsweise ein DrawCallback anmelden. In der Draw-Phase wird anstelle der Drawable-Standard-Implementation der zugewiesene DrawCallback aufgerufen. Hier kann der Anwender beliebigen OpenGL-Kode ausführen und bei Bedarf sogar die originale Zeichenfunktion aufrufen (Decorator-Pattern). // DrawCallback-Definition struct MyDrawCallback: public osg::drawable::drawcallback { Sascha Seewald, TU Dresden 35

36 // eigene draw Methode virtual void drawimplementation(osg::state& s,const osg::drawable* d) const { // pre-rendering Kode glpushattrib(gl_lighting); gldisable(gl_lighting); // bei Bedarf originale Zeichenfunktion aufrufen d->drawimplementation(s); } } // post-rendering Kode glpopattrib(); // Registrierung des eigenen DrawCallbacks an einem osg::drawable some_drawable->setdrawcallback( new MyDrawCallback ); Das Callback-Konzept erlaubt es, Objekte ohne Vererbung zu spezialisieren und ihr Verhalten sogar zur Laufzeit zu variieren. Dadurch, dass ein bestimmter Aspekt (hier das Rendern) in einem einzelnen Objekt konzentriert vorliegt, lässt sich die entwickelte Funktionalität leichter an anderer Stelle wieder verwenden. OpenSceneGraph wurde auf zahlreiche Plattformen portiert (IRIX, Linux, Windows, MacOS, Solaris, HP-UX und sogar Playstation2) läuft auf low-end Computern ohne 3D-Beschleuniger wie auch in high-end Render- Netzwerken mit zahllosen Clients. Es unterstützt von Haus aus Stereo-Rendering für Rot-Grün-Brillen oder vollwertige VR-Helme. Die Ausgabe kann auf einem einfachen Monitor oder einem aus 20 Displays bestehen 3D-Screen erfolgen. Dieses Potential mag die Mehrzahl der Anwendungen gar nicht ausschöpfen können, doch zeigt es, wie vielseitig und anpassungsfähig OSG ist. Dies spiegelt sich auch in dem breiten Spektrum an OSG-basierten Projekten wieder. Hier kann dieses professionelle Framework vor allem bei VirtualReality-Anwendungen oder im Bereich Massive-Data-Visualisation seine Stärken ausspielen. Selbstverständlich wird OSG auch erfolgreich für die Spielentwicklung eingesetzt - z.b. in Diosoft s Shooter Frontier [41] Spezielle Features MultiThreading-Support Stereo/MultiView-Rendering-Support 3D-Sound, Physical Simulation, ParticleSystem, Character Animation Massive-Terrain-Visualization Paged-LOD Auto-Impostors (on-the-fly creation, on-demand-update) Anbindung an zahlreiche ToolKits (GLUT, Qt, MFC, SDL, Win32) Sascha Seewald, TU Dresden 36

37 2.5 Gegenüberstellung und Bewertung Es folgt eine Gegenüberstellung der drei Kandidaten mit abschließender Bewertung. Die angegebenen Frameraten wurden unter Windows XP, auf einem Intel P4 2400HT mit GF4600 ermittelt. CrystalSpace OGRE OpenSceneGraph Version 0.98 r001 (cvs) (cvs) (cvs) Unterstützte Plattformen Win32, Linux, MacOS Win32, Linux, MacOS IRIX, Linux, Win32, FreeBSD, MacOS, Solaris, HP-UX, PS2 Unterstützte 3D-API OpenGL, DirectDraw OpenGL, D3D OpenGL Lizenz LGPL LGPL OSGPL (LGPL) Unterstützte Bild-Formate gif, tga, png, bmp, jpg, png, jpg, tga, bmp, dds rgb, gif, jpg, png, tiff, pic, bmp, dds, tga, qt Unterstützte 3D-Formate proprietär, 3ds, mdl, md2, ase, obj, pov proprietär proprietär, 3ds, obj, lwo, x, vrml, pfb, iv, md2, flt 3D-Exporter für Maya, Milkshape, 3DS 3DSMax, Maya, Blender, Milkshape 3DSMax Tutorials Beispielprogramme Registrierte User Mailinglisten/Foren Shader VP, FS, Cg VP, FP, Cg, HLSL VP, FP, Cg, GLslang OpenGL Integration - - X Stereo Rendering - - X Multi Threading - - X 3D-Audio X - X Physical Simulation X - X Character Animation X X X GUI X X - Network Support X - - ArrayTest fps (min / avr / max) 44 / 115 / / 223 / / 251 / 351 TreeTest fps (min / avr / max) 35 / 150 / / 232 / / 261 / 434 Abbildung 2-3 Gegenüberstellung der Kandidaten Sascha Seewald, TU Dresden 37

38 CrystalSpace OGRE OpenSceneGraph Erlernbarkeit (+) Flexibilität Funktionsumfang Performance Abbildung 2-4 Bewertung der Kandidaten Wie die Übersicht zeigt, spielt CrystalSpace in der Gegenüberstellung eine eher untergeordnete Rolle, gleichwohl es mit einem sehr großen Funktionsumfang aufwarten kann. Die Eigenheiten dieser stark spezialisierten Engine machen sie unflexibel und schwer erlernbar. OGRE besticht durch intuitive Bedienbarkeit und ermöglicht einen schnellen Einstieg in das System. Performance und Funktionsumfang sind gut, wenn auch streng auf die 3D-Spielentwicklung ausgerichtet. Insgesamt liefert jedoch OpenSceneGraph das überzeugendste Ergebnis des Vergleichs. Es bietet dank umfangreicher Beispiele und Tutorials hervorragende Einstiegsmöglichkeiten, sofern ein grundlegendes Verständnis für die OpenGL vorhanden ist. Das Framework ist sauber, effizient, intuitiv und hinterlässt schlichtweg einen professionellen Eindruck. Der Funktionsumfang ist sehr gut und nicht auf ein bestimmtes Einsatzgebiet zugeschnitten. OSG bringt von allen drei Kandidaten die besten Voraussetzungen für zukünftige Entwicklungen (auch außerhalb des Spielesektors) mit. Die Entscheidung zugunsten von OpenSceneGraph ist nicht zuletzt durch die gesammelten Praxiserfahrungen geprägt worden. Bei der Entwicklung der zwölf Testprogramme bekam man sehr schnell einen Eindruck davon, wie gut oder schlecht die verwendete Software ist. Gerade die vergleichende Umsetzung derselben Aufgabenstellung in drei verschiedenen Frameworks, deckt deren jeweilige Stärken und Schwächen schonungslos auf. Erst in der Gegenüberstellung der verschiedenen Lösungsansätze zeigen sich Ausdruckskraft und Eleganz der OpenSceneGraph-Bibliothek, die in der Form in keiner Statistik den gebührenden Niederschlag finden können. OSG schafft es, die Mächtigkeit der OpenGL handhabbar zu machen und darauf aufzubauen, ohne sie dabei im Namen der Benutzerfreundlichkeit einzuschränken oder zu verstecken. Mit einer soliden konzeptionellen, softwaretechnischen und algorithmischen Basis braucht OSG den Vergleich mit seinen ausgewachsenen Vorbildern Performer und Inventor nicht zu scheuen. Es ist gerade die Vielseitigkeit, die man sonst nur von großen und teuren Visualisierungs-Paketen kennt, die diese Freie Software zur ersten Wahl für professionelle Grafik-Entwicklung in jedem Anwendungsgebiet macht. Eben auch in der Augentherapie. Sascha Seewald, TU Dresden 38

39 3 Eine Beispielanwendung auf Basis von OSG Im zweiten Teil dieser Arbeit soll eine konkrete Anwendung entwickelt werden, die die Ergebnisse des Vergleichs aufgreift und davon gebraucht macht. Zum einen wird damit ein umfassendes Referenzprojekt geschaffen, das die Einbindung von OSG in einem realen Applikationskontext zeigt und an dem sich zukünftige Entwicklungen orientieren können. Die zahlreichen OSG-Demoprogramme sind auf technischer Ebene sehr lehrreich, behandeln jedoch immer nur einen einzelnen Aspekt und erreichen niemals die Komplexität einer echten Anwendung. Die Ausführungen dieses Kapitels zur Entwicklung eines Computerspiels werden sich daher auf die Integration des OSG- Frameworks konzentrieren. Zum zweiten soll eine voll einsatzfähige Applikation mit therapeutischem Charakter entstehen, die also für das Forschungsprojekt praktischen Nutzen hat und letztendlich den Patienten zugute kommt. Dabei setzt auch diese Anwendung auf die bewährte Kombination von Visusstimulation und Aufmerksamkeitsbindung durch spielerische Inhalte. 3.1 Einführung Spielkonzept Die Idee zum Spiel ist einer bei Kindern sehr beliebten und pädagogisch wertvollen Beschäftigung entlehnt: dem freien Malen. Auf weißem Papier wird mit Buntstiften oder Wasserfarbe, Kohle- oder Fettstiften der Fantasie freien Lauf gelassen. Kinder sind auf diese Weise in der Lage sich stundenlang selbst zu beschäftigen und entwickeln nebenbei ihre kreativen und sensor-motorischen Fähigkeiten. Dieses Potential soll in einem Malspiel mit der therapeutischen Wirkung der Visusstimulation verknüpft werden. Konzeptionell orientiert sich das Spiel am wirklichen Malen mit Wasserfarben auf Papier: der Arbeitsplatz des Kindes enthält eine Zeichenfläche (das Blatt Papier), einige wenige Zeichenwerkzeuge mit unterschiedlichen Strichformen (die Pinsel) und eine Farbpalette zur Auswahl der Zeichenfarbe (der Malkasten). Außerdem wird ein Stempelwerkzeug angeboten, mit dem kleine Bildchen und Symbole aufgetragen werden können. Weiterhin wird das Malen auf 3D-Objekten angeboten. Diese lassen sich frei rotieren, füllen und in unterschiedlichen Pinselstärken bemalen (Abbildung 3-1). Ein spezielles Zeichenwerkzeug ermöglicht sogar die Konstruktion von 3D-Objekten aus einer skizzierten Silhouette. Das Kind malt nur den Umriss einer Schnecke und erhält interaktiv eine echte 3D-Schnecke zum drehen und bemalen. Dabei fließen in den Modellierungsprozess grundlegende Prinzipien der menschlichen Bild-Interpretation ein. So führt eine schmale Silhouette zu einem schlanken Körper und eine große Wölbung zu einem dicken Klumpen. Die erzeugten Objekte sind radial-symmetrisch und wirken sehr organisch das Verfahren eignet sich besonders für rundliche und schlauchförmige Formen. Die Steuerung Sascha Seewald, TU Dresden 39

40 der Zeichenwerkzeuge erfolgt ausschließlich mit der Maus oder einem Stift auf einem Grafiktablett. Sowohl das Auswählen der Farben und Werkzeuge, als auch das Zeichnen bzw. Stempeln erfolgt einfach per Mausklick. Abbildung 3-1 Eine im Spiel bemalte 3D-Ente mit Visusstimulation im Hintergrund Visuelle und akustische Gestaltung Ausgangspunkt für Überlegungen zur Gestaltung der Programmoberfläche sollte natürlich die Zielgruppe also Kinder im Alter von drei bis acht Jahren sein. Intuitive, kindgerechte Bedienelemente stellen eine notwendige Voraussetzung für Akzeptanz und Spielspass bei den Kindern dar. Ebenso kann eine spielerisch-akustische Untermalung der Programmoberfläche den Unterhaltungswert steigern. Um hier möglichst großen Gestaltungsfreiraum zu lassen, sind Layout und Erscheinungsbild der Bedienelemente austauschbar gehalten, sodass auch nach Abschluss der softwaretechnischen Entwicklungsphase Änderungen daran vorgenommen werden können. Psychologen, Therapeuten und Multimediadesigner können und sollen so ihr Wissen und ihre Erfahrungen ohne Programmierkenntnisse in das Spiel einfließen lassen. Bei aller Freiheit in der Gestaltung gilt es jedoch immer darauf zu achten, die stimulierenden Muster im Hintergrund nicht durch allzu große Bedienelemente zu verdecken oder anderweitig wirkungslos zu machen. Überhaupt besteht die Gefahr, dass die Kinder die Stimulation einfach übermalen und so den therapeutischen Erfolg verringern könnten. Um dem aus dem Wege zu gehen, sollte die Oberfläche möglichst wenig opaque Flächen enthalten und vielmehr die Muster durch transparente Elemente und Sascha Seewald, TU Dresden 40

41 Zeichenflächen hindurch scheinen lassen. Inwieweit verdeckende bzw. halbdurchlässige Oberflächenelemente die therapeutische Wirkung beeinflussen ist bis zum jetzigen Zeitpunkt noch nicht untersucht worden. Hier sind noch detaillierte Studien notwendig. 3.2 Die Softwaretechnische Umsetzung im Detail Entwicklungsumgebung Als Programmiersprache wird c++ gewählt. Zum einen, weil der Grossteil der Freien Software für diese Anwendung c bzw. c++ Interfaces bereitstellt, ebenso wie die AmbViz-Bibliothek von Sebastian Schmeck. Zum anderen weil für eine Echtzeitanwendung hohe Ausführungsgeschwindigkeit unerlässlich ist. Und obwohl sich in dieser Hinsicht in den letzten Jahren viel getan hat, ist c++-code im Allgemeinen noch immer performanter als sein entsprechendes Gegenstück in Java. Nicht zuletzt soll sich mit c++ die Möglichkeit erhalten werden, spezielle 3D-Hardware zur Darstellung oder Nutzerinteraktion systemnah anzusprechen. Die Entwicklung findet unter Windows XP statt. Als Compiler kommt der aktuelle optimierende c++ Compiler von Microsoft zu Einsatz (vc7.1). Dieser wurde überraschend im März 2004 mit dem Microsoft Visual C++ Toolkit 2003 kostenlos zur freien Verfügung gestellt [28]. Seine Stärken liegen in der Codeoptimierung und der hervorragenden Unterstützung des c++ Standards. Die automatische Quellkode-Dokumentation erfolgt mithilfe des freien Software-Projektes Doxygen [29] Verwendetet open-source Software Ein wesentliches Ziel für die Entwicklung des Programms ist die bestmögliche Einbindung von Freier Software. Nach dem Motto Integrieren statt implementieren soll bei der Bearbeitung der gegebenen Problemstellungen weitestgehend auf offene und bewährte Lösungen der open-source community zurückgegriffen werden. In der Regel bedeutet das, open-source Bibliotheken einzubinden. Die Auswahl einer solchen Bibliothek zur grafischen Darstellung wurde bereits untersucht. Es kommt OpenSceneGraph zum Einsatz. Für den Audioteil soll die plattformunabhängige open-source high-level 3D-Sound-Bibliothek OpenAL [16] zum Einsatz kommen. Sie setzt auf die jeweiligen Audioschnittstellen des Betriebssystems auf (DirectSound3D unter Windows, OSS oder ALSA unter Linux) und zeichnet sich durch ein schlichtes, intuitives Interface und hohen Abstraktionsgrad aus. Für die saubere c++-anbindung der OpenAL sorgt die ebenfalls freie Bibliothek OpenAL++ [30]. Diese bringt gleich Funktionalität zum Streamen von ogg-files mit und nutzt dafür die vorbis.lib [31] und ogg.lib [32]. Weiterhin wird vielfach von der Boost Collection [20] Gebraucht gemacht. Eine umfangreiche Sammlung von kleinen Template-basierten c++-bibliotheken, zur Ergänzung der STL. Von besonderem Interesse sind hier die SmartPointer-, FileSystem- und Thread-Library. Sascha Seewald, TU Dresden 41

42 Zur Tesselierung von 2D-Polgonen und zum Filtern von 3D-Meshes wird auf die hochwertigen geometrischen Algorithmen des bereits vorgestellten Visualisation Toolkit (VTK) zurückgegriffen Entwicklung einer Benutzeroberfläche Für die Gestaltung der Benutzeroberfläche des Spiels wird eine Gruppe von einfachen GUI-Elementen (Widgets) benötigt. Wegen der speziellen Anforderungen an das Aussehen der Widgets, sollte es möglich sein, deren Form und Gestaltung selbst festlegen zu können oder zumindest einen eigenen Skin zu entwerfen. Selbstverständlich muss die Darstellung auf OpenGL-Basis erfolgen, da die Elemente direkt in die Zeichenfläche integriert werden, womit Toolkits wie MFC oder Qt gleich ausscheiden. Eine schnelle Recherche der verfügbaren freien GL-Toolkits ergab leider, dass keiner der Kandidaten die freie Gestaltung der Widgets erlaubt. Zu nennen sind hier vor allem GLGooey [37] und der GLOW Toolkit [38]. Folglich muss eine Eigenentwicklung diese Lücke schließen, was den positiven Effekt hat, dass die Oberfläche genau auf die Anforderungen der Anwendung zugeschnitten werden kann. Grundlage aller Widgets ist ein rechteckiger Eingabebereich auf dem Bildschirm (InputArea). Dieser empfängt Mouse und Keyboard-Ereignisse und bietet Methoden an, um darauf zu reagieren. Ein Widget ist solch ein InputArea-Objekt jedoch erweitert um die Fähigkeit zur Darstellung. Im Gegensatz zu einer InputArea kann man ein Widget also auch sehen. Das Aussehen oder auch Visual eines Widgets wird durch einen eigenen OSG-Graphen festgelegt, der wie jeder Scenegraph beliebig geartet und somit beliebig komplex sein. Ob das Widget durch ein schlichtes Icon oder einen rotierenden 3D-Körper repräsentiert wird, bleibt offen und obliegt der Kreativität des Gestalters. Zur Darstellung der gesamten Benutzeroberfläche werden alle Graphen der enthaltenen Widget eingesammelt und zu einem großen GUI-Graphen zusammengefügt (Abbildung 3-2). Dieser kann dann wie üblich durch OSG gerendert werden. Desktop Panel B B Abbildung 3-2 Eine schematische Benutzeroberfläche und ihr entsprechender aus allen Widget-Graphen zusammengesetzter OSG-Scenegraph Von dem allgemeinen Widget können nun spezielle abgeleitet werden, die ein konkretes Verhalten implementieren. Ein Button z.b. modelliert einen Schalter, den man durch Klicken mit der Maus aktivieren und deaktivieren kann. Der zugehörige Header sieht in etwa folgendermaßen aus: Sascha Seewald, TU Dresden 42

43 class Button: public Widget { public: /// actions bool bool void activate(); deactivate(); toggle(); /// queries bool active() const { return _active; }; bool inactive() const { return!_active; }; /// events virtual void onactivate() {}; virtual void ondeactivate() {}; virtual void ontoggle() {}; /// Button-spezifische Ereignisbehandlung virtual void onmouseclick() { // die von Widget geerbte onmouseclick-methode aufrufen... Widget::onMouseClick(); }; //... und den Button umschalten toggle(); protected: /// Methode zum Anfordern des Button-Visual - ein OSG-Scenegraph, /// der das Aussehen des Buttons festlegt. /// Die notwendige Synchronisation übernimmt der Button selbst. virtual osg::node* getorcreatevisual(); /// radio group virtual RadioGroup* getradiogroup() const; virtual void setradiogroup( RadioGroup* rg ); /// active flag bool _active; }; Eine RadioGroup fasst eine Gruppe von Schaltern zusammen, in der immer genau ein Schalter aktiviert ist und alle anderen deaktiviert sind. Ein Beispiel dafür ist die Werkzeugleiste im Spiel: der Anwender darf aus einer Palette von Werkzeugen wählen, es darf jedoch immer nur eines aktiviert sein. Eine RadioGroup stellt sicher, dass vor der Aktivierung eines neuen Buttons, alle anderen Buttons der RadioGroup deaktiviert werden. Eine weitere Spezialisierung ist das Group-Widget, mit dem sich mehrere GUI-Elemente gruppieren lassen. Das ermöglicht die Organisation der Widgets in Hierarchien (DAG), wie sie für komplexe graphische Benutzerflächen unerlässlich sind. Alle Ereignisse, die ein Group-Widget von Maus oder Keyboard empfängt, werden an die untergeordneten Widgets durchgereicht, diese reichen sie wiederum an die ihnen Sascha Seewald, TU Dresden 43

44 untergeordneten Elemente durch usw. Die gesamte Oberfläche des Spiels ist in einer Gruppe zusammengefasst dem Desktop (siehe Abbildung 3-2Abbildung 3-2). Abschließend soll noch das Panel vorgestellt werden, mit dem sich beliebige 3D-Szenen in einem rechteckigen Bereich auf dem Bildschirm anzeigen lassen. Die Modell-Vorschau in der unteren linken Ecke im Spiel ist ein solches Panel. Das Vorschau-Modell wurde aus einer Datei gelesen und in einem OSG- Graph abgelegt. Um es in einem Panel anzuzeigen, wird nur der Wurzelknoten des Modell-Graphen an das Panel übergeben und dieses sorgt automatisch für das korrekte Rendering. GUI-Framework InputArea Widget Button Group Panel ColorPot Desktop Canvas Anwendungsschicht Abbildung 3-3 Hierarchie der GUI-Komponenten Die Stärken dieses GUI-Entwurfs liegen in seiner Schlichtheit und Flexibilität. Die gebotene Funktionalität ist genau auf das Spiel zugeschnitten, kann jedoch jederzeit ohne viel Aufwand erweitert werden. Die Integration weiterer Widgets wie Lists, Bars, Slider oder Ähnliches sollte kein Problem darstellen. Da das Aussehen der Widgets durch beliebige OSG-Graphen festgelegt wird, bleibt auch in dieser Hinsicht genug Freiraum für zukünftige Anpassungen D-Zeichenverfahren Dieses Kapitel soll Auskunft darüber geben, wie die 2D-Zeichenfunktionalität - also das Malen auf dem virtuellen Papier des Spiels - implementiert wurde. Zuerst sollte gesagt werden, dass das Bild, in das gemalt wird, als OpenGL-Texturobjekt vorgehalten wird und sämtliche Zeichenoperationen der Werkzeuge (Stift, Pinsel, Stempel) mithilfe der OpenGL durchgeführt werden. So wird ein Maximum an Performance erzielt, da für die Manipulation des Bildes 3D-Hardware zum Einsatz kommt und es zu keinem Zeitpunkt notwendig wird, umfangreiche Daten zwischen CPU und GPU (bzw. RAM und Video-RAM) zu transferieren. Sascha Seewald, TU Dresden 44

45 Bei der Anwendung der Malwerkzeuge werden prinzipiell folgenden Schritte durchgeführt: 1. Die Bild-Textur wird in ihrer vollen Auflösung in ein Rechteck auf dem Bildschirm gezeichnet. Sie dient als Hintergrund für die nachfolgenden Zeichenoperationen. 2. Das Malwerkzeugs wird in genanntem Rechteck angewendet. Dabei werden in der Regel Teile des ursprünglichen Bildes übermalt. 3. Das manipulierte Bild wird vom Bildschirm zurück in die Bild-Textur zurück lesen. Dieser Vorgang findet für den Anwender nicht sichtbar im Backbuffer der Grafikkarte statt. Das oben beschriebene Zeichnen auf den Bildschirm ist in Wirklichkeit nur ein Zeichnen in den Bildschirmspeicher. Die Bild-Manipulation geschieht in einem extra Render-Pass vor der eigentlichen Darstellung der Spieloberfläche. OpenSceneGraph hält für diese Aufgabe eine fertige Komponente bereit die osgutil::rendertotexturestage. Als RenderStage bezeichnet OSG einen Render-Pass mit allen benötigten Daten: die zu zeichnende Szene in Form eines Scenegraphs, ein Viewport-Rechteck usw. Die spezielle osgutil::rendertotexturestage zeichnet den übergebenen Graphen nach dem oben beschriebenen Verfahren in eine Textur. Stempelwerkzeug osg::geode Quad-Geometrie Stempelbild-Textur Abbildung 3-4 Graph des Stempelwerkzeugs Die Zeichenoperationen der Werkzeuge werden jeweils durch einen individuellen OSG-Szenegraph beschrieben. Zum Beispiel der Graph des Stempelwerkzeugs (Abbildung 3-4) besteht schlicht aus einem quadratischen Polygon mit einer Textur, die das Stempelbild enthält. Beim Stempeln wird dieses texturierte Polygon flach in das Bild gezeichnet es entsteht ein Stempelabdruck. Natürlich sind auch kompliziertere Werkzeuge denkbar (es ließe sich beispielsweise mit vollwertigen 3D-Objekten stempeln) sie müssen nur in einem OSG-Scenegraph beschreibbar sein. Sascha Seewald, TU Dresden 45

46 Damit die Zeichenoperationen an der Stelle im Bild stattfinden, auf die der Anwender gerade mit seinem Mauscursor zeigt, wird der Werkzeuggraph unter einen speziellen Transformationsknoten gehangen. Dieser hat Informationen über die aktuelle Mausposition und verschiebt das Werkzeug entsprechend in der Bildebene. Schließlich sorgt ein übergeordneter osg::switch-knoten dafür, dass nur dann gezeichnet wird, wenn der Nutzer bei gewähltem Malwerkzeug die linke Maustaste gedrückt hält. Ist das nicht der Fall, werden alle Subgraphen des Knoten deaktiviert also auch nicht mehr traversiert und folglich nicht mehr gezeichnet. osg::switch aktiviert den Subgraph nur bei gedrückter Maustaste osg::transform verschiebt den Subgraph entsprechend der Maus- Cursor-Position Maus Events Werkzeuggraph Abbildung 3-5 Vollständiger RenderToTexture-Graph Um den entstandenen Graphen (Abbildung 3-5), wie gewünscht, in die Bild-Textur rendern zu lassen, wird eine entsprechende osgutil::rendertotexturestage angelegt und mit dem Graphen und der Bild-Textur konfiguriert. OSG arbeitet dann in der Draw-Phase alle registrierten RenderStages in spezifizierter Reihenfolge ab. Die vorgestellte Lösung schafft es, das gesamte Malverfahren in einem OSG-Szenegraph zu beschreiben. Bis auf die Generierung des Graphen, war quasi kein spezieller Kode notwendig, um die gewünschte Funktionalität mit OpenSceneGraph umzusetzen. Durch geschicktes Zusammenstecken von OSG- Standard-Komponenten entsteht im Ergebnis ein hochautomatisierter, effizienter und jederzeit erweiterbarer 2D-Zeichen-Algorithmus. Sascha Seewald, TU Dresden 46

47 D-Zeichenverfahren In diesem Kapitel werden einige Vorüberlegungen zur Implementation des Malens auf 3D-Modellen erläutert, die während der Entwurfsphase des Spiels angestellt worden sind. Um ein Mesh-Objekt mit Farbe zu versehen, kommen in der Echtzeit-Grafik üblicherweise zwei Verfahren in Frage: VertexColoring und Texturing. 1. Beim VertexColoring wird jedem Vertex ein zusätzliches Attribut für dessen Farbe mitgegeben. Beim Füllen der Polygone werden die Farben der Verticen linear über die Fläche interpoliert, sodass ein Farbverlauf von einem Eckpunkt zu anderen entsteht. Diese Farbe dient dann als Grundlage für folgende Beleuchtungsberechnungen oder Ähnliches. 2. Beim Texturing werden die Farbinformationen eines Polygons aus einem beliebigen Bild der Textur gewonnen. Dazu erhält jeder Vertex Texturkoordinaten, die auf eine Stelle in der Textur verweisen. Die Texturkoordinaten werden ebenfalls linear über die Fläche interpoliert. Pro Pixel wird dann die Farbe in der Textur an der interpolierten Stelle ausgelesen und weiterverarbeitet. Ein Polygon-Objekt zu Bemalen bedeutet ganz abstrakt, die Farbinformationen des Mesh zu verändern, unabhängig davon, in welcher Form sie vorliegen. Im Falle von VertexColoring bedeutet das, die Farbeinträge der Verticen zu ändern; beim Texturing den Inhalt des Texturbildes. Beim Malen auf freibeweglichen 3D-Objekten, erweist sich erstgenanntes Verfahren als das unkompliziertere, da die aufwendige Rückprojektion vom Bild-, über den Objekt- in den Textur-Raum und das anschließende Zeichnen in die Textur entfällt. Stattdessen bedarf es nur der Selektion der gewünschten Verticen und der Veränderung ihrer Farbwerte. Dieses als VertexPainting bekannte Verfahren ist weit verbreitet, in der Spielindustrie sehr beliebt und wird von jedem guten 3D-Modelling-Programm unterstützt. Das Verfahren soll auch in dieser Anwendung zum Einsatz kommen. Die oben genannte Selektion der Verticen soll mithilfe eines Auswahlbereichs um den Mauscursor im Bild- Raum erfolgen. Die Farbe aller Verticen innerhalb des Bereichs soll verändert werden. Ein selektierbarer Vertex muss bei genauer Betrachtung also folgende zwei Bedingungen erfüllen: A. Seine Bildraum-Projektion muss innerhalb des Fensters (Viewport) und innerhalb des Auswahlbereichs um den Cursor liegen. B. Der Vertex darf aus der momentanen Sicht durch nichts verdeckt werden. D.h. weder Vorder- noch Rückseiten desselben oder anderer Objekte dürfen zwischen Vertex und virtueller Kamera liegen. Beim VertexPainting, würden also alle Verticen der Szene durchlaufen, auf oben genannte Kriterien hin untersucht und bei Erfüllung der beiden Bedingungen entsprechend der Werkzeugfarbe eingefärbt. Für die Überprüfung der zwei Kriterien bieten sich jeweils verschiedene Testverfahren mit ihren entsprechenden Vor- und Nachteilen an. Es folgt eine kurze Übersicht. Zu Kriterium A bieten sich folgende zwei Lösungen an: Sascha Seewald, TU Dresden 47

48 A1 2D-Projektion und 2D-Inside-Test Projektion aller Verticen (z.b. mit gluproject()) und damit Bestimmung ihrer Bildraum- Koordinaten Anschließender 2D-Test, ob der Vertex innerhalb des Viewports und innerhalb des Selektionsbereiches liegt Vorteil: unkompliziert da die notwendige Funktionalität bereits durch die GLU-Bibliothek bereitgestellt wird A2 3D-Beam-Test Bestimmung eines 3D-Volumenkörpers durch Extrusion des Umrisspolygons des Selektionsbereichs entsprechend der Projektionsmatrix 3D-Test, ob Verticen innerhalb dieses Volumens liegen Vorteil: ermöglicht vielfältige Culling-Optimierungen bei der Vertexauswahl (vgl. Frustum-Culling) Nachteil: sehr rechenintensiv und CPU-lastig Die Verdeckungsproblematik (Kriterium B) lässt sich mit folgenden Methoden untersuchen: B1 Analyse des ZBuffers Zeichnen der 3D-Szene in den Z-Buffer (mit Rückseiten) Pro Vertex: Projektion in den Bildraum (wie bei A1), Zurücklesen der Tiefeninformation aus dem ZBuffer an der projizierten Stelle und Vergleich mit rechnerisch bestimmter Tiefe des Vertex Sind die beiden Werte gleich, wurde der Punkt nicht übermalt und ist daher auch nicht verdeckt Vorteil: unkompliziert Nachteil: Zurücklesen des Z-Buffers ist in der Regel sehr langsam, Zwei-Pass-Verfahren, ungenau B2 OcclusionQuery Zeichnen der 3D-Szene in den Z-Buffer (mit Rückseiten) Pro Vertex: Initialisierung eines OcclusionQuery, Zeichnen des Vertex als Punkt, Abfrage des Query Wurde kein Pixel gezeichnet, ist der projizierte Vertex entweder verdeckt oder außerhalb des Viewports Durch Verwendung des Stencil-Buffers ließe sich gleichzeitig überprüfen, ob der projizierte Punkt innerhalb des Selektionsbereichs liegt, womit ein separater A-Test überflüssig würde Vorteil: läuft komplett in Hardware, ausbaufähig zu einer All-In-One-Lösung Nachteil: OcclusionQuery wird nicht überall unterstützt, wahrscheinlich langsam wegen des begin/end/get-overheads, ggf. Zwei-Pass-Verfahren, ungenau Sascha Seewald, TU Dresden 48

49 B3 Ray-Casting Aussenden eines Strahls von der virtuellen Kamera aus zu jedem Vertex und Test auf Schnitte mit Szenengeometrie Liefert der Test keine Kontakte mit anderer Geometrie, ist der Vertex nicht verdeckt Vorteil: numerische (und damit genauere) Beantwortung der Frage nach verdeckten Verticen, benötigt keinen Rendervorgang Nachteil: CPU-lastig Die beiden vorgestellten grafischen Lösungsverfahren zur Bestimmung der Verdeckung (B1 und B2) haben einen inhärenten Nachteil, der vielleicht in Kauf zu nehmen ist, hier jedoch nicht unerwähnt bleiben soll. Bei der Bestimmung der Sichtbarkeit eines Vertex, wird auf das entsprechende Fragment im Depth-Buffer zurückgegriffen und mit der tatsächlichen Tiefe des Vertex verglichen. Dieser Ansatz funktioniert solange, wie auf ein Depth-Buffer-Fragment auch nur genau ein Vertex fällt. Für den Fall, dass sich mehrere Verticen ein Depth-Fragment teilen, würde dieses üblicherweise den Depth-Wert des am wenigsten entfernten Vertex annehmen, was jedoch alle anderen Verticen dieses Fragments fälschlicherweise verdeckt erscheinen ließe. Der Nachteil gegenüber den numerischen Verfahren besteht also in der Ungenauigkeit der Ergebnisse, die durch die Rasterung des Depth-Buffers bedingt ist. Je geringer die Render-Auflösung ist und je dichter die Verticen liegen, umso wahrscheinlicher treffen deren Projektionen auf ein und dieselbe Pixelposition und können so die Verdeckungsanalyse verfälschen. Da numerische Verfahren rein geometriebasiert arbeiten und somit ohne Rasterung auskommen, tritt dieser Fehler nicht auf. Um das beschriebene Problem zu vermeiden oder zumindest dessen Häufigkeit zu reduzieren, sollte der Tiefenvergleich mit einer gewissen Toleranz durchgeführt werden. Die größeren Probleme liegen jedoch eher im Bereich der Performance, ganz gleich welche Verfahren nun zum Einsatz kommen. Es sollte geprüft werden, inwieweit der Einsatz von Caching-Verfahren eine Verbesserung in diesem Bereich bringt. Zum Beispiel ändern sich Bildraumkoordinaten und Sichtbarkeit der Verticen nur dann, wenn das Modell durch den Anwender bewegt bzw. gedreht wurde. Den überwiegenden Teil der Zeit bleibt die Lage der Verticen im Bild jedoch gleich. Es wäre also sinnvoll, die für eine Selektion genötigten Daten pro Vertex zwischen zu speichern und nur aufzufrischen, wenn der Anwender eine Änderung an der Transformation des Modells vorgenommen hat. Da eine Festlegung auf ein bestimmtes Verfahren zum jetzigen Zeitpunkt nicht möglich scheint, müssen spätere Tests mit verschiedenen Implementationen zeigen, welches Verfahren die beste Balance zwischen Geschwindigkeit, Genauigkeit und Kompatibilität gewährleistet. Als Referenz soll zuerst die nahe liegende Kombination A1-B1 umgesetzt werden. Sascha Seewald, TU Dresden 49

50 3.2.6 Modellierung von 3D-Objekten aus Handskizzen Das im Spiel integrierte Modellierungswerkzeug basiert auf einer Arbeit von Takeo Igarashi aus dem Jahr 1999 [42]. Darin wird ein System zur Stift-basierten Modellierung von einfachen 3D-Objekten vorgestellt, dass dem Anwender keinerlei Vorkenntnisse über Meshes, Polygonen und Verticen abverlangt. Es eignet sich somit hervorragend für kleine Kinder. Diese zeichnen mit einem Stift oder der Maus den Umriss eines Objekts und ein Konstruktionsverfahren generiert daraus ein polygonales Oberflächenmodell. Dieses Verfahren soll nun im Detail vorgestellt werden. Den Ausgangspunkt des Modellierungsprozesses bildet die aus der Handskizze des Kindes abgeleitete schnittfreie Silhouette. Diese wird geschlossen, diskretisiert und von redundanten Punkten bereinigt. Alle benachbarten Verticen des Polygonzugs halten einen bestimmten Mindestabstand zueinander, was die Qualität des späteren Modells insgesamt verbessert. Abbildung 3-6 Ergebnis der Delaunay-Triangulation Mittels constrained delaunay triangulation wird die Silhouette in der Ebene tesseliert. Dabei werden alle Verticen des Silhouettenpolygons zu Dreieckseckpunkten und alle Liniensegmente zu Dreieckskanten. Die entstehende Menge von Dreiecken lässt sich anhand der jeweiligen Nachbarschaftsbeziehung in drei relevante Gruppen teilen (Abbildung 3-6): Terminal Triangles (rot) haben genau ein angrenzendes Nachbardreieck und somit zwei Aussenkanten (exterior edges). Sleeve Triangles (blau) grenzen an genau zwei benachbarte Dreiecke mit denen sie jeweils eine Innenkante (interior edge) teilen. Junction Triangles (grün) sind an allen Seiten mit anderen Dreiecken verbunden, haben also keine exterior edge, jedoch drei interior edges. Sascha Seewald, TU Dresden 50

51 Zunächst werden alle Terminal-Dreiecke des Mesh beseitigt, indem ihre nähere Umgebung neu vermascht wird: Abbildung 3-7 Beseitigung der Terminal-Dreiecke Ein Terminal-Dreieck T hat zwei Außen- und eine Innenkante. Über dem Dreieck wird ein Halbkreis errichtet, bei dem die Innenkante des Dreiecks dessen Durchmesser bildet (Abbildung 3-7a). Liegt ein Eckpunkt von T auf oder innerhalb des Halbkreises, wird die innere Kante verworfen und T mit dem anliegenden Dreieck zu einem 4-Eck verschmolzen. Das entstandene 4-Eck hat selbst wiederum genau eine innere Kante nämlich die von dem neuen Dreieck eingebrachte. Es wird ein Halbkreis über dieser neuen Innenkante errichtet (Abbildung 3-7b), wieder getestet, ob einer der Punkte innerhalb des Halbkreises liegt und gegebenenfalls dieses 4-Eck mit dem benachbarten Dreieck vereint. So wird die Region um das Terminal-Dreieck schrittweise vergrößert, bis alle Punkte der Region außerhalb des Halbkreises liegen (Abbildung 3-7c). Dann erfolgt die fächerförmige Triangulation des entstandenen n-ecks um den Schwerepunkt der aktuellen Innenkante (Abbildung 3-7d). Abbildung 3-8 Sonderfall Junction-Triangle Die sukzessive Erweiterung der Region endet auch, wenn das angrenzende Dreieck ein Junction-Triangle ist (Abbildung 3-8a). In diesem Fall, erfolgt ebenfalls die fächerförmige Triangulation der Region, jedoch um den Schwerepunkt des angrenzenden Junction-Triangle (Abbildung 3-8b). Sascha Seewald, TU Dresden 51

52 Abbildung 3-9 Unterteilung der Sleeve-Triangles Nachdem alle Terminal-Dreiecke beseitigt sind, werden die übrigen Dreiecke unterteilt. Sleeve-Dreiecke werden entlang der Geraden durch die Schwerepunkte ihrer beiden Innenkanten zerschnitten (Abbildung 3-9) und Junction-Dreiecke per midpoint subdivision zerlegt. Das entstandene, immer noch flache Mesh ist nun für die 3D-Extrusion vorbereitet. Abbildung 3-10 Extrusion durch Verschiebung der inneren Punkte Es enthält neben den ursprünglichen Verticen nun auch neue Punkte (Abbildung 3-10a), die innerhalb der Silhouette liegen und nicht Teil einer Aussenkante sind (interior points). Diese Punkte werden senkrecht nach oben verschoben, wobei die Höhe proportional mit der durchschnittlichen Größe der umgebenden Dreiecke zunimmt (Abbildung 3-10b). Das hat den Effekt, dass Punkte, die sehr weit im Inneren des Mesh liegen, stark verschoben werden; Punkte, die eher am Rand liegen, weniger stark. Das Objekt wird also zum Rand hin leicht abgerundet (Abbildung 3-10c). Anschließend werden die entstandenen Schrägen einzeln rekursiv unterteilt, mit dem Ziel dem Mesh eine rundliche Gestalt zu geben. Abbildung 3-11 Ausformung durch rekursive Unterteilung Sascha Seewald, TU Dresden 52

53 Die Subdivision erfolgt jedoch nicht einfach flach in der Dreiecksebene, sondern versucht vielmehr durch vertikale Verschiebung der Verticen, das Dreieck sphärisch auszuformen. Dazu wird die Höhe der neuen Verticen, so angepasst, dass sie sich einem angelegten virtuellen Viertelkreisbogen annähern (Abbildung 3-11d). Die Abbildung 3-12 zeigt diese Verschiebung nochmals in der Seitenansicht. Abbildung 3-12 Sphärische Ausformung durch vertikale Verschiebung der Verticen In einem vorletzten Schritt wird die entstandene Objekthälfte gespiegelt und zu einem geschlossen Volumen verbunden. Um nun noch die Qualität des Ergebnisses zu erhöhen und etwaige Spitzen, Bruchkanten oder Verwerfungen zu reduzieren, wird das Modell schließlich mit einem relaxierenden Mesh-Smoothing- Algorithmus (laplacian smoothing) bearbeitet. Damit ist die Generierung des Volumens abgeschlossen Visusstimulation Die Konfiguration und Darstellung der Visusstimulation erfolgt mithilfe der von Sebastian Schmeck entwickelten AmbViz-Bibliothek. Da das Rendering der Muster auf OpenGL-Basis erfolgt, muss sichergestellt werden, dass es nicht zu Interferenzen mit der ebenfalls OpenGL-basierten OSG-Bibliothek kommt. Die AmbViz-Bibliothek erwartet zum Zeichnen einen vorbereiteten und voll konfigurierten OpenGL- Renderkontext. Daraus folgt, dass Zeichenaufrufe an die Bibliothek im Rahmen der OSG-Drawstage stattfinden müssen, da nur zu diesem Zeitpunkt durch OSG ein GL-Kontext garantiert wird. Es wird sichergestellt, dass etwaige Änderungen an der GL-Statemachine durch die Bibliothek wieder zurückgenommen werden. Der folgende Kode zeigt, wie die AmbViz-Anbindung in OSG umgesetzt wurde. Ein eigens entwickelter DrawCallback initialisiert die Bibliothek bei Bedarf, führt die notwendigen Render- Vorbereitungen durch und löst schließlich den AmbViz-Zeichenvorgang aus. Dieser DrawCallback lässt sich bei jedem osg::drawable anhängen und so an beliebiger Stelle und beliebig oft im Scenegraph positionieren. Die geometrische Basis der Muster ist eine Menge von Polygonen, die flach in einer Ebene angeordnet sind. Prinzipiell kann diese Ebene wie alle OpenGL-Primitive frei transformiert werden, sodass es sogar möglich wäre, um die Muster herumzugehen und sie dreidimensional zu betrachten. Sascha Seewald, TU Dresden 53