Bernd Blümel Harald Gatermann Walter Hillen Horst …hstl/Dokumente/Java-Framework-Abschluss.pdf · Ein Java-Framework auf Basis von RMI, CORBA, JNI und JDBC von Ein Gemeinschaftsprojekt

Bernd BlümelHarald GatermannWalter HillenHorst Stenzel (Hrsg.)Martin TrautweinHans-Joachim Weber

Forschungsverbund Multimediaan Fachhochschulen inNordrhein- Westfalen

Intelligente, innovative Produktentwicklungfür die industrielle Praxis

Forschungsverbund Multimediaan Fachhochschulen in Nordrhein- Westfalen

Intelligente, innovative Produktentwicklungfür die industrielle Praxis

Bernd BlümelHarald GatermannWalter HillenHorst Stenzel (Hrsg.)Martin TrautweinHans -Joachim Weber

Inhaltsverzeichnis

Horst StenzelDer Forschungsverbund Multimedia.....................................................................................4

Bernd BlümelVisualisierung von grundwasserwirtschaftlichen Planungs-daten in Internet und Intranet:Ein Java-Framework auf Basis von RMI, CORBA, JNI und JDBC............................... ......5

Harald GatermannFrom Vrml to Augmented Reality Via Panorama-Integration and Eai-Java..............................................................................................................................25

Walter HillenJava Image Viewer zur Darstellung und Verarbeitungmedizinischer Bilddaten in Rechnernetzen.........................................................................41

Martin TrautweinVR im Bauwesen.................................................................................................................52

Hans-Joachim WeberVerbundforschungsprojektMultimediale 3D-Visualisierung der Herzmuskelerregung...................................................99

Horst StenzelVerteiltes Visualisieren.......................................................................................................113

Der Forschungsverbund Multimedia

Das Thema Multimedia hat in den Fachhochschulen breiten Eingang gefunden. ImBereich von Forschung und Entwicklung steht der Anwendungsaspekt im Mittelpunkt,insbesondere die Übertragung von Anwendungen und Systemen, die in denLaboratorien entwickelt wurden, in die industrielle Praxis.Durch die Orientierung der Ausbildung an der beruflichen Praxis und die vielfältigen,dauerhaften Verbindungen zwischen Industrie und Hochschule entsteht ein Netzwerkvon fruchtbarem Austausch. Davon profitiert die Hochschule, indem sie am Bedarforientierte Themen vermittelt bekommt, und auch die Industrie, die im Gegenzug dieinnovativen, risikobehafteten Entwicklungen von hoch motivierten Mitarbeitern aus denHochschulen zu günstigen Konditionen adaptiert. Der Forschungsverbund Multimediaknüpft an diese günstigen Voraussetzungen an und setzt auf dem Gebiet der Multi-media exemplarisch Entwicklungen in Gang, die sich im Vorfeld der kommerziellenNutzung befinden, aber das gesamte technische Know-how enthalten, das für eine spä-tere, erfolgreiche Vermarktung als Produkt erforderlich ist.Im Verbund von mehreren Wissenschaftlern aus verschiedenen Fachhochschulen desLandes werden eine Reihe von Projekten durchgeführt, die aktuelle Bereiche derMultimedia- Entwicklung abdecken. Die Aufgaben behandeln den intelligenten Entwurfund die Realisierung von (prototypischen) Informationssystemen in Medizin, Umweltund Bauwesen, inklusive der multimedialen Elemente der Virtuellen Realität und derRealisierung auf verteilten Plattformen.Die Projekte im Verbund beinhalten die Entwicklung multimedialer Informationsbasenund der zugehörigen Zugriffs und Transport- werkzeuge, Anfrage- und Strukturierungs-möglichkeiten sowie am Nutzer orientierte Sichtweisen der Daten. Im Sinne einesApplication- Frameworks können diese Entwicklungen als Prototypen verschiedensterAnwendungen, z.B. im Bereich der Umwelt und Medizin, dienen. Den Projekten istweiterhin ein direkter Anwendungsbezug gemeinsam. Während der gesamten Projekt-laufzeit wird auf die Kooperation nicht nur untereinander, sondern auch mit der Industriegesetzt. Diese Veranstaltung zeigt, wie diese Entwicklungen von der Industrie aufge-nommen und in ihre Aktivitäten integriert werden.

Prof. Dr. Bernd Blümel

Visualisierung von grundwasserwirtschaftlichen Planungs-daten in Internet und Intranet:

Ein Java-Framework auf Basis von RMI, CORBA, JNI und JDBC

1

Visualisierung von grundwasserwirtschaftlichen Planungs-daten in Internet und Intranet:

Ein Java-Framework auf Basis von RMI, CORBA, JNI und JDBC

von

Ein Gemeinschaftsprojekt des

Labors für e-Business am Fachbereich Wirtschaft der FH-Bochum

und der

GKW Ingenieurgesellschaft mbH

im Rahmen

des Forschungsverbunds Multimedia der Fachhochschulen des Landes NRW

gefördert vom

Ministerium für Ministerium für Schule, Wissenschaft und Forschung des Lan-des Nordrhein-Westfalen

Prof. Dr. Bernd BlümelFH BochumLabor für e-BusinessFachbereich Wirtschaft

Tel.: 0234/32-10614email: [email protected]

Jörg GotthardtGKW Ingenieurgesellschaft mbhMarkstraße 7744803 Bochum


Carsten MetzlerDr. Materna GmbHVoßkuhle 3744141 Dortmund


Beate SchulzPixelpark AGRuhrallee 944139 Dortmund


Jan SchemmUniversität Münster

email: [email protected]

Marco ViehlDatawatch GmbHKaiser-Wilhelm-Ring 27-2950672 Köln

Tel.:0221/5694-166email: marco_viehl@wgs_d.de

Java-Framework für verteilte multimedialeInformationssysteme mit Anwendungen inwasserwirtschaftlicher Planung und Bewirt-schaftung

1

Abschlussbericht

für den Zeitraum:01.10.1998 bis 30.11.2000

für das Forschungsprojekt

"Java-Framework für verteilte multimediale Informationssysteme mit Anwendungen in wasserwirt-

schaftlicher Planung und Bewirtschaftung"

Az.: 513 - 107 025 97

im Rahmen des Forschungsverbunds “Multimedia der Fachhochschulen NRW”

vorgelegt von

Prof. Dr. Bernd Blümel, FH Bochum

Bochum, 28. November 2000

1 Problemstellung und Ziele

In dem hier beschriebenen Teilprojekt wird die Eignung der Programmiersprache Javazur Erstellung, Übertragung und Darstellung multimedialer Informationen über das In-ternet untersucht. Die darzustellenden Informationen sind Visualisierungen vonGrundwassermodellen. Das Teilprojekt wird am Labor für e-Business des Fachbe-reichs Wirtschaft der Fachhochschule Bochum in Zusammenarbeit mit der GKW Inge-nieurgesellschaft (Bochum) durchgeführt.

Die GKW Ingenieurgesellschaft mbH beschäftigt sich mit der Datenverarbeitung imUmweltschutz. Schwerpunkt bildet hier die Erzeugung von Grundwasserströmungs-und Stofftransportmodellen, mit deren Hilfe Aussagen und Prognosen bezüglich derGrundwasserquantität und -qualität einschliesslich der Interaktion mit Oberflächenge-wässern gemacht werden können. Bedeutung haben diese Modelle beispielsweise fürunterirdische Bauvorhaben (Tunnelbau, Tiefgaragen) und den Bergbau, indem dieAuswirkungen auf den Grundwasserhaushalt erkannt und durch entsprechende Maß-nahmen minimiert werden können. Wasserwerke und Wasserversorger sind ebenfallsan solchen Modellen interessiert, um bei zunehmender Grundwasserbelastung durchLandwirtschaft und Industrie Aussagen über Herkunft und Beschaffenheit des geför-derten Wassers zu erhalten. Im Rahmen von Wasserrechtsanträgen können mit Hilfevon Modellen qualifizierte Aussagen zu Einzugsgebieten, Fließzeiten und Massenbi-lanzen gemacht werden.

GKW hat zur Berechnung dieser Grundwasserströmungs- und Transportmodelle dasProgrammsystem SPRING (

S

imulation of

Pr

ocesses

in

G

roundwater) entwickelt.SPRING beruht auf der Finite-Element-Methode. Die Software erzeugt anhand diver-ser Parameter zwei- und dreidimensionale Modelle, in denen durch graphische Ele-mente (z.B. Iso-Linien, Flächenfärbung) die entsprechenden Grundwasserdaten dar-gestellt werden.

Bei der Abwicklung von größeren Projekten müssen diese Darstellungen Bearbeiternaus unterschiedlichen Fachdisziplinen, unterschiedlichen Firmen (oder Verwaltungen)mit unterschiedlichen Zielsetzungen zugänglich gemacht werden. Aufgrund deren Be-urteilungen sind oftmals neue Berechnungen oder Modelländerungen erforderlich(vgl.

Abbildung 1

), bis das endgültige Ergebnis (Umweltverträglichkeitsstudie in

Abbil-dung 1

) verabschiedet werden kann. Hierbei handelt es sich um ein Beispiel unterneh-mensübergreifender Geschäftsprozesse.

Zur Zeit. werden Ausdrucke der Ergebnisse erstellt und versendet. Diese Vorgehens-weise führt nicht nur zum Zeitverlust durch den Posttransport. Vielfach sind aufgrundder Plots neue vergrößernde Darstellungen erforderlich, die dann erst bei GKW be-rechnet und erneut versendet werden müssen.

Die Übertragung der Ergebnisse an alle beteiligten Projektpartner in der für die Pro-jektpartner geeigneten Form mit Interaktionsmöglichkeit (Vergrößerung) über das In-ternet oder ggf. über ein Intranet und damit die Optimierung dieses unternehmens-übergreifenden Geschäftsprozesses ist daher das generelle Ziel des hier dargestelltenProjektes.

Hierzu sollen sich die Projektpartner auf einer entsprechenden HTML-Seite mittelsBenutzername und Passwort (vgl.

Abbildung 2

) identifizieren und dann aus einer Aus-

wahl von Modellen eine Modellvariante selektieren. Innerhalb einer Modellvariantekönnen weitere Parameter eingegeben werden (vgl.

Abbildung 3

). Das Modell solldann auf dem Server der GKW berechnet, die Ergebnisse zum Kunden übertragenund dort im Internet-Browser dargestellt werden (vgl.

Abbildung 4

). Der Kunde soll so-dann beliebige Bereiche beliebig vergrößern und auf seinem Drucker ausgeben kön-nen (vgl. Menü „Zoom“ in

Abbildung 4

).

Die Benutzerverwaltung wird über eine Datenbank vorgenommen. Aus rechtlichenGründen muss bei manchen Projekten zudem jeglicher Zugriff protokolliert werden.Auch dies geschieht über die eingesetzte Datenbank.

In diesem Teilprojekt wird also ein multimediales Internet/Intranet-basiertes Informati-onssystem konzipiert und implementiert. Daraufhin wird seine Eignung für oben be-schriebene Aufgabenstellung analysiert und bewertet.

Abbildung 1 Schema zwischenbetrieblicher Geschäftsprozesse im Bereich Planung und Bewirtschaftung von Grundwasserleitern (DFD-Darstellung)

Abbildung 2 Anmeldemaske der Anwendung

2 Eingesetzte Technologien

2.1 Java

Durch die Nutzung der plattformunabhängigen Programmiersprache Java wird die An-wendung unabhängig von der bei den jeweiligen Projektpartnern eingesetzten Hard-und Software. Dies gilt sowohl für die Server-, als auch für die Client-Seite. Diese Rah-

Abbildung 3 Modelle, Varianten und Parameter

Abbildung 4 Beispielhafte Browserausgabe

menbedingung ist hier zwingend notwendig, da bei den an solchen Projekten beteilig-ten Partnern Hardware unterschiedlichster Art (von leistungsstarken RISC-Worksta-tion zur Berechnung der Finite Elemente Modelle bis hin zu Low-Cost-PCs) eingesetztwird.

2.2 RMI, CORBA, JDBC

Sowohl die Kommunikation zwischen Client und Server (Netzwerkschnittstelle) alsauch die Kommunikation mit der Datenbank setzt auf einer Objektschnittstelle auf. ZurZeit wird hier RMI (Remote Method Invocation) eingesetzt. RMI bietet Mechanismen,mit deren Hilfe Java-Objekte, die auf verschiedenen Rechnern lokalisiert sind, mitein-ander kommunizieren können.

Die Entwicklung einer CORBA-Schnittstelle ist in einigen Teilen realisiert.

JDBC bedeutet Java Database Connectivity und ist eine von Sun entwickelte API (Ap-plication Programming Interface), die einen standardisierten Datenbankzugriff ausJava-Anwendungen heraus ermöglicht. Diese Zugriffsmöglichkeiten sind unabhängigvon der Rechner-Plattform und vom zugrundeliegenden Datenbankmanagementsy-stem (DBMS).

2.3 JNI

Die Kommunikation zwischen der Java-Anwendung und der Anwendung SPRING er-folgt mittels JNI (Java Native Interface).

JNI stellt eine native Programmierschnittstelle in Java dar. Damit können Java-Anwen-dungen mit Programmen, die in anderen Programmiersprachen geschrieben sind (z.B.C, C++ oder Assembler), interagieren.

3 Lösungs-Konzeption

3.1 Datenstruktur und Datenübertragung

Hierbei musste die bestehende Struktur des SPRING-Programmsystems zugrundegelegt werden. SPRING besteht aus verschiedenen Modulen, die anhand vorhande-ner Daten entsprechende Berechnungen durchführen (vgl.

Abbildung 5

). Diese Datenwerden in binären Hintergrunddateien vorgehalten, ebenso wie die von den Modulenberechneten Ergebnisdaten. Das PLOGEO-Modul (vgl.

Abbildung 5

) erzeugt aus die-sen Daten eine Plotdatei im PLX-Format. PLX ist ein von GKW entwickeltes proprie-täres Vektorformat.

Das XPLT-Modul des SPRING-Systems kann Plotdateien durch das PLOGEO-Modulerzeugen lassen, die erzeugten Dateien lesen, auf Bildschirm und Plotter bzw. Druckerausgeben und in verschiedenen Dateiformaten abspeichern. Es stellt die Benutzer-schnittstelle für die Datenausgabe dar. Hier kann der Benutzer Darstellungsparameter,wie beispielsweise Farbe und Abstand von Iso-Linien wählen.

Für den Internetzugriff stellte sich die Frage, in welcher Form die Daten übertragenwerden sollen. Vier Alternativen wurden diskutiert:

1. Übertragung der vom XPLT-Modul generierten Druckdatei im TIFF-Format.

2. Übertragung der vom XPLT-Modul generierten Druckdatei im PDF-Format undDarstellung in einen entsprechenden Viewer (z.B. AcrobatReader).

3. Übertragung der vom PLOGEO-Modul generierten Plotdatei im PLX-Formatund Darstellung in einem in Java selbst programmierten Viewer (Ersatz desXPLT-Moduls durch einen Java-Viewer).

4. Import der Hintergrunddaten in eine SQL-Datenbank, Übertragung der Datenzum Client und Darstellung in einem selbst programmierten Viewer

Die erste Variante schied wegen der erheblichen Datenmenge und der fehlenden In-teraktions-Möglichkeit aus. Die Dateigröße und der Verlust des Vektorformats sprachauch gegen die zweite Alternative. Die vierte Möglichkeit hätte das PLOGEO-Modulgar nicht genutzt, was einen erheblichen Programmieraufwand bedeutet hätte. Sowurde der dritte Lösungsansatz gewählt und auch realisiert.

3.2 Anwendungsarchitektur

Da der Benutzer die Anwendung via Internet/Intranet nutzt, war eine mehrschichtigeArchitektur notwendig. Wir haben uns für eine Drei-Ebenen-Architektur entschieden.Hierbei wird die Anwendung auf drei Komponenten verteilt:

⋅

-

Bildschirmdarstellung (Client, erste Ebene):

Der Client ist nur noch für die Be-nutzerinteraktion zuständig, d.h. er nimmt die Benutzereingaben auf, leitet sie

Abbildung 5 Struktur von Spring

an die eigentliche Anwendung weiter und stellt die von der Anwendung erzeug-te Lösung auf dem Bildschirm dar.

−

Anwendungslogik (Anwendungsserver, zweite Ebene):

Die Implementierungder Anwendungslogik erfolgt hier.

−

Datenverwaltung (Datenbankserver, dritte Ebene):

Die notwendigen Daten wer-den auf einem Datenbankserver vorgehalten und bei Bedarf vom Anwendungs-server angefordert.

Auf dem Client ist keinerlei Installation notwendig (natürlich muss ein Internet-Browservorhanden sein). Der Client lädt vom WWW-Server, der zweiten Schicht, eine HTML-Seite mit integriertem Java-Applet. Das Applet nimmt mittels RMI Verbindung mit demAnwendungsserver auf, der in diesem Fall dem WWW-Server entspricht. Der Anwen-dungsserver kommuniziert zum einen mit dem SPRING-System, um eine Plotdatei er-zeugen zu lassen, und zum anderen mit dem Datenbankserver, auf dem die Benutzer-daten und Zugriffsrechte hinterlegt sind. Die Kommunikation zwischen Anwendungs-server und der SPRING-Software geschieht über JNI (Java Native Interface), die Da-tenbankinteraktion wird mit JDBC realisiert. Die Anwendungsstruktur ist in

Abbildung6

dargestellt, die Objektstruktur in

Abbildung 7

(nur die Hauptklassen sind dargestellt).

Die unterlegten Objekte in

Abbildung 7

laufen auf dem Server ab. Sie sehen, dass einC-Programm benötigt wird, um ein Unix-Shell-Script zu starten (runPlogeoImp.c in

Ab-bildung 7

). Java-Anwendungen können keine Betriebssystem-Kommandos durchfüh-ren, daher musste der Umweg über ein C-Programm genommen werden. Hier wurdeJNI eingesetzt, um die Java-Anwendung mit dem C-Programm zusammenarbeiten zulassen.

Dies ist übrigens die einzige plattformabhängige Komponente der Anwendung. Das C-Programm muss für jede Plattform neu übersetzt werden. Auf Windows-Systemenmuss darüber hinaus anstelle eines Shell-Scripts eine Windows CMD-Datei erstelltwerden. Auf eine weitere Diskussion von

Abbildung 7

wollen wir hier verzichten. Einige

Abbildung 6 Struktur der Anwendung

in

Abbildung 7

dargestellten Komponenten werden allerdings in späteren Kapiteln be-sprochen.

4 Bewertung der eingesetzten Technologien

4.1 Die Java-Grafikbibliothek

Der Funktionsumfang der in Java beinhalteten Grafikbibliothek war für unsere Zweckeausreichend. Die Grafikbibliothek ist gut dokumentiert. Der Bildschirmaufbau auf demClient ist (sobald die Datenübertragung beendet ist) ausreichend schnell. Da wir diedarzustellende Grafik in einem Vektorformat an den Browser übertragen, konnten wirdie Zoom-Funktion clientseitig implementieren (ZeichenLayerobjekt und GKWGrafik in

Abbildung 7

). Bei einem Zoom ist daher kein neuer Kontakt mit dem Server erforder-lich. Die Zoom-Funktion (sie erfordert eine Neuberechnung der Grafik auf dem Client)ist ebenfalls hinreichend schnell.

Abbildung 7 Objektstruktur der Anwendung

4.2 JDBC

Dem Prototyp wurde zunächst die Datenbank YARD-SQL zugrundegelegt. Um diePortabilität der JDBC-Schnittstelle zu testen, haben wir die Anwendung sodann aufOracle umgestellt.

Die Umstellung von der YARD-Datenbank auf Oracle erwies sich nach anfänglichenSchwierigkeiten mit dem JDBC-Treiber als recht problemlos. Die der Anwendung zu-grunde liegenden Tabellen konnten bis auf eine Änderung (der YARD-Datentyp

Timestamp

heißt in Oracle

Date

) mit dem gleichen SQL-Skript erzeugt werden wie un-ter YARD.

Die Portabilität von JDBC erwies sich hier als einwandfrei. Sämtliche Datenbanktrans-aktionen funktionierten ohne Änderung des Programmcodes auf beiden Datenbank-systemen. Selbst die unterschiedlichen Datentypen

Timestamp

und

Date

machten kei-ne Probleme. Beide wurden mit Werten des JDBC-Datentyps

java.sql.Timestamp

ge-füllt und korrekt dargestellt.

Der Quellcode wurde in der Weise geändert, dass beide JDBC-Treiber (für YARD undOracle) geladen werden. Beim Starten des Serverprozesses ist dann ein Parametererforderlich, der festlegt, welche Datenbank verwendet wird.

4.3 JNI

Die Kommunikation über JNI mit einer C-Anwendung war ebenfalls problemlos. Die C-Anwendung besteht lediglich aus einer Methode, die ein von der Java-Anwendung ge-neriertes Shell-Skript aufruft (runPlogeo und runPlogeoImp in

Abbildung 7

). Der kom-plette Aufruf wird dieser Methode als Java-String übergeben und muss dort in einenC-spezifischen String konvertiert werden. Das Shell-Skript startet mit entsprechendenParametern das PLOGEO-Modul des SPRING-Systems, welches dann die PLX-Dateierzeugt.

4.4 Einlesen der PLX-Datei und RMI

4.4.1 Struktur der PLX-Dateien und Abbildung der PLX-Dateistruktur in Objekte

Eine PLX-Datei enthält eine oder mehrere

Maps

. Eine

Map

ist eine zwei- oder dreidi-mensionale Karte, die neben einigen Kopfdaten (Kartenursprung, Maßstab) aus meh-reren

Layern

besteht. Jedes

Layer

hat einen Namen und beinhaltet verschiedene Gra-fik-Objekte. Es gibt vier Objekt-Typen: Polylinien (

Polyline

), Flächen (

Area

), Texte(

Text

) und Markierungspunkte (

Marker

). Ein Objekt enthält neben seinen Koordinaten-punkten verschiedene Attribute, wie Farbe, Strichstärke, Größe etc.. Die unterschied-lichen Objekt-Typen unterscheiden sich nicht in der Struktur und Benennung der Attri-bute, allerdings in ihrer Bedeutung. So enthält das Attribut

font

beispielsweise für denTyp

Text

den Fonttyp, für die Typen

Polyline

und

Area

die Strichstärke. Teilweise sindAttribute nicht belegt, haben also den Wert Null.

In einer PLX-Datei können damit sechs verschiedene Elemente beliebig oft vorkom-men:

Map

,

Layer

,

Polyline

,

Area

,

Text

und

Marker

. Um jedes Element eindeutig zuidentifizieren, ist jeweils eine Kennung (

type

) vorangestellt. Die Zugehörigkeit von Gra-fik-Objekten zu einem

Layer

, bzw. von

Layern

zu einer

Map

ist über die Reihenfolge

der Daten geregelt: Nach den

Map

-Daten (mit der folglich jede Plotdatei beginnt) folgtdas erste

Layer

mit seinen Objekten, dann das zweite

Layer

mit seinen Objekten usw..

Serverseitig werden die Daten aus einem File-Strom gelesen und in Objekten gespei-chert, die nacher über RMI zum Client übertragen werden. Die Objekte entsprechendabei den Objekten der Karte z.B. Polylinien, Flächen (vgl

Abbildung 8). Dabei werdenbeim Einlesen viele Objekte erzeugt, die nur zwischenzeitlich gebraucht werden (vgl.Kapitel 4.4.3), aber auch viele Objekte für die Elemente der Grafik an sich. Innerhalbder Speicher-Objekte werden wiederum Objekte benötigt, um die Informationen einesElements leicht verfügbar zu machen.

Für eine durchschnittliche PLX-Datei werden dabei mehrere zehntausend Objekte dereinzelnen Objektarten erzeugt (GKWServer in Abbildung 7 erzeugt diese Objekte).

4.4.2 Problematiken der gewählten Speicher-Objekt-Struktur

Bei unserer ersten Realisierung der Speicher-Objekte wurden Maximal- und Minimal-koordinaten für Polylinien und Flächen in Hashtables abgelegt. Bei kleineren PLX-Da-teien (<= 1MB) funktionierte dies auch einwandfrei. Bei größeren Dateien erhielten wirplötzlich einen java.lang.OutOfMemoryError und zwar selbst dann, wenn noch genü-gend Speicher für Java (nachgewiesen durch Runtime.getRuntime().freeMemory())vorhanden war.

Explizites auf null setzen nicht mehr benötigter Objekte brachte eine leichte Verbesse-rung des Verhaltens. Ein expliziter Aufruf des Garbage Collectors verbesserte die Me-mory-Situation nicht mehr, er verschlechterte nur die Performance der Anwendung.

Durch die erste Zeile der Fehlermeldung "at java.util.Hashtable.keys(Hashtable.java)"hatten wir die Vermutung, dass der Speicher mit den vielen Hashtables, die mit einervoreingestellten Kapazität von 110 Einträgen beim Konstruktor Hashtable() erzeugt

Abbildung 8 Abbildung der PLX-Datei auf Objekte (Marker und Texte sind nicht dargestellt)

werden, Probleme hat. Da in den meisten Fällen pro Hashtable nur vier Werte tatsäch-lich benötigt werden, haben wir die Hashtables auf acht Werte voreingestellt. Sunempfiehlt, Hashtables doppelt so groß wie tatsächlich benötigt, zu dimensionieren.Dies führte tatsächlich dazu, dass es auf serverseitig zu keinem Fehler mehr kam. Al-lerdings ist uns nicht klar, warum es zu einem OutOfMemoryError kam, obwohl eigent-lich zu jeder Zeit genügend Hauptspeicher vorhanden war.

4.4.3 RMI

Literatur und Erfahrungsberichte zu RMI sind spärlich gesät. Das Sun RMI-Tutorial be-schreibt die Übertragung einzelner Strings über RMI. Dies entspricht in keiner Weiseder Komplexität der in unserer Anwendung zu übertragenden Objektstruktur (vgl. Ab-bildung 8). Beim Einsatz von RMI traten daher Probleme auf.

Das erste Problem betrifft die Serialisierbarkeit. Objekte oder Datentypen, die überRMI übertragen werden sollen, müssen serialisierbar sein. Primitive Datentypen undStrings sind dies. Andere Objekte müssen dazu das Interface Serializable implemen-tieren. Dazu reicht es normalerweise aus, der Deklaration der Klasse implements Se-rializable hinzuzufügen.

Das Problem tauchte dann bei den Polyline- und Area-Objekten auf. Sie enthalten un-ter anderem ein Integer-Array jeweils für die x- und y-Koordinaten der Punkte. DieseArrays sind für sich genommen serialisierbar. Da sie aber in ein weiteres Objekt “ge-packt” werden (Polyline bzw. Area), welches mit vielen weiteren Objekten gleichenTyps wiederum ein Array bildet, erkennt RMI offensichtlich nicht mehr die Serialisier-barkeit. Obwohl die Klassen Polyline und Area zusätzlich das Interface Serializable im-plementieren, funktionierte die Übertragung nicht. Erst als die Integer-Arrays mit denKoordinaten in einer eigenen Klasse, die ebenfalls serialisierbar gemacht wurde, ge-kapselt wurden, konnte RMI die Objekte übertragen.

Die in Kapitel 4.4.2 geschilderte Problematik (Hashtables) setzte sich bei der Übertra-gung über RMI fort. Bei großen Dateien führte die Übertragung der Objekte auf die Cli-ent-Seite zu einer EOFException. Wir ersetzten daraufhin die Hashtables durch einfa-che Integer-Werte, was zu einer Beseitigung des Fehlers führte. Allerdings ist der Zu-sammenhang zwischen der EOFException und den Hashtables für uns nicht erkenn-bar.

4.5 CORBA

Neben der komplexen Struktur der eingelesenen PLX-Datei werden einfache Stringsübertragen (z.B. Benutzernamen, Passworte, Modell-Metadaten). Die Übertragungdieser Daten bereitete beim Einsatz der RMI-Technologie keine Probleme.

Dieser Teil der Schnittstelle wurde bereits auf CORBA umgestellt. Die CORBA-Imple-mentierung war ungleich aufwendiger als die Implementierung in RMI. Dies war zumgroßen Teil durch scheinbare Inkompatibilitäten zwischen den eingesetzten CORBA-Systemen bedingt. Hier konnte noch keine endgültige Klärung erfolgen.

Eine Umsetzung der Übertragung der komplexen Struktur der eingelesenen PLX-Da-tei auf CORBA wurde verworfen.

5 Multimediale Projektberichte und Hilfssysteme

Ein weiteres interessantes Einsatzgebiet der hier entwickelten Technologien ergabsich im Projektverlauf. Abschluss- oder Zwischenberichte werden in Papierform an dieAuftraggeber übermittelt.

Zukünftig könnte dies auf elektronischen Medien (z.B. CD-ROM) geschehen. Die Er-gebnisdateien könnten im PLX-Format beigefügt und über das Java-Applet vermittelseines Browsers betrachtet werden. Die Auftraggeber können dann durch die einge-baute Lupen-Funktion die Visualisierung der Ergebnisse verändern. Diese Technolo-gie kann zudem für das Hilfesystem der Anwendung SPRING genutzt werden.

6 Das iterativ, inkrementelle Vorgehensmodell

Ein weiteres interessantes Ergebnis des Projekts ist, dass das iterativ, inkrementelleVorgehensmodell (vgl. Fowler 1999, Einsatz im Projekt vgl. Kapitel 11.3) für die Ent-wicklung von Software unter den erschwerten Begleitumständen einer Entwicklung imFachhochschulumfeld sehr gut geeignet ist und zu guten Ergebnissen führt.

Bedingt durch die momentane Situation auf dem EDV-Arbeitsmarkt und der intensivenNachfrage nach Java-Entwicklern standen Vollzeit-Mitarbeiter jeweils nur eine Ver-tragszeit und studentische Hilfskräfte nur bis zu Ihrem Diplom oder in einer Praktikum-sphase zur Verfügung. Die Mitarbeit an einem anspruchsvollen Java-Entwicklungspro-jekt verschaffte ihnen dann qualifizierte Arbeitsplätze in Unternehmen der Region.

Daher wechselten die Mitarbeiter im Projekt ständig. Bedingt durch das iterativ, inkre-mentelle Vorgehensmodell konnten sie aber zumindest eine Iteration vollständigdurchführen. Sie hatten dadurch einen klar abgegrenzten und überschaubaren Ar-beitsbereich, der in der jeweiligen Beschäftigungsphase erfolgreich abgeschlossenwerden konnte.

Dies legt den Schluss nahe, dass die Nutzung des iterativ, inkrementellen Vorgehens-modells Friktionen durch Mitarbeiter-Fluktuation in großen Projekten abmildern kann.

7 Performance-Analyse

Für die Performance-Untersuchungen wurde die Gesamtanwendung in 27 Teilprozes-se unterteilt. Hierdurch konnte zwischen server-, client-, netzwerk- und datenbankin-duzierten Abhängigkeiten unterschieden werden.

7.1 Nutzung eines JIT-Compilers

Vor der Übertragung des Datenstroms über das Netzwerk werden die zu übertragen-den Daten vom Serverprozess komprimiert. Hierdurch wird der Datenstrom um mehrals 50% verkleinert. Dies erkauft man sich durch zusätzlichen Rechenaufwand aufdem Server. Bei großen Karten können die Komprimierungsroutinen mehrere Minutenbenötigen. Durch die Nutzung eines JIT-Compilers kann diese Zeit um mehr als 50 %reduziert werden. Andere auf dem Server durchgeführte Prozesse, insbesondere Da-tenbankabfragen und Zugriffe auf das Dateisystem, profitieren vom JIT-Compiler nicht.

Clientseitig ergab sich gleiches Bild. Insbesondere die Dekomprimierungsroutinenund die Zeichenroutinen profitierten bei großen Dateien deutlich vom JIT-Compiler. Beikleineren Dateien wirkte der JIT-Compiler bremsend. Dies erklärt sich daurch, dass dieZeit für die Compilierung des Java-Bytecodes die Zeit, die durch die Beschleunigungsich wiederholender Abläufe gewonnen wird, überstieg.

Mit der Entwicklung effizienterer JIT-Compiler erwarten wir eine weitere Performance-Verbesserung in den angesprochenen Bereichen der Anwendung.

7.2 Datenbankabhängige Faktoren

Für ein professionelles DBMS sind die teilweise ermittelten Zugriffszeiten von 5 Se-kunden und mehr für einen Selectbefehl bei der YARD-Datenbank recht dürftig. Be-trachtet man allerdings den Anspruch an die Datenbank im Allgemeinen für diese An-wendung, sind diese Werte als noch ausreichend zu betrachten. Die Nutzung der Ora-cle-Datenbank ergab einen Geschwindigkeitszuwachs vom Faktor 5. Da dieser Wertfür eine Oracle Datenbank immer noch enttäuschend ist, lässt sich der Ursprung derschlechten Performance eher in der JDBC-Schnittstelle suchen, da große Perfor-manceunterschiede verschiedener Schnittstellen auch aus dem Bereich der ODBC-Schnittstellen bekannt sind.

Die Nutzung von Oracle ist für Unternehmen des Adressatenkreises dieser Anwen-dung aus Preisgründen nicht möglich. Wir werden die Anwendung im nächsten Jahralso auf das MySQL-DBMS umstellen, welches auf Performance optimiert ist. Darüberhinaus erwarten wir mit der Entwicklung effizienterer JDBC-Treiber weitere Perfor-mance-Verbesserungen

7.3 Internet versus Intranet

F r den sp teren praktischen Einsatz der Applikation war es interessant zu erfahren,wie sich die Applikation verh lt, wenn man den Zugang zu der zweiten und drittenSchicht der Applikation ber das Internet herstellt und dadurch ber geringere Lei-tungskapazit ten verf gt. Dabei wurden bertragungen ber ein 10 MBit/s Ethernetmit einem 56.000 Bit/s Modem-Anschluss verglichen.

Bei den Ergebnissen gab es keine großen Überraschungen. Es war zu erwarten, dassdie geringere Übertragungsrate, die beim Zugriff über das Internet zur Verfügungsteht, eine Verschlechterung der Performance bringen würde.

Bei der Betrachtung der Einzelmesswerte der Providermessungen kann man dieSchwankungen zwischen den einzelnen Messungen sehen, die grundsätzlich vom In-ternet bekannt sind.

Obwohl die reine bertragung der Layer- bzw. Map-Daten ber das Internet selber umein Vielfaches l nger dauert, als die bertragung ber ein Ethernet, dauert die Warte-zeit des Benutzers nach seiner letzten Eingabe bis zur Darstellung der Karte ber dasInternet bei mittelgro§en Dateien (ca. 1,5 MByte) insgesamt nur ca. 55 % l nger. Diesliegt daran, dass die reine bertragung der Daten nur einen Teilprozess der insgesamtdurchzuf hrenden Abl ufe darstellt. Zeitaufwendig ist insbesondere die Komprimie-rung bzw. Dekomprimierung der Daten. Mit einer weiteren Reduzierung der Bandbrei-te nimmt der Einfluss der Komprimierung ab.

Im Ethernet hingegen ist die Komprimierung der Hauptzeitfaktor. Hier würde sich einedeutliche Beschleunigung einstellen, wenn man auf die Komprimierung verzichtet. Mitdem Aufkommen der DSL-Technologien und damit ausreichend schnellen Internet-Zu-gängen werden wir durch Verzicht auf die Komprimierung eine weitere Performance-Steigerung erhalten.

8 Fazit, Relevanz und weitere Arbeiten

Seit dem Projektstart im Oktober 1998 konnten wir in relativ kurzer Zeit einen funkti-onsfähigen Prototyp zur Darstellung zweidimensionaler Karten erstellen. Dies ist diebislang weitestgehende Integration von Internet-Technologien in der Hydro-Informatik.Auch der Einsatz von Multimedia in Projektberichten wurde in dieser Form in der Hy-dro-Informatik noch nicht eingesetzt.

Die Performance der Anwendung ist ebenfalls zufriedenstellend. Die einmalige Über-tragung der Grafikdatei zum Client hängt im Wesentlichen von der Dateigröße und derKapazität der Verbindung ab. Dies ist im Intranet unproblematisch. Hier ist die Warte-zeit im Wesentlichen von der Dauer der Datenkomprimierung abhängig und kanndurch einen Verzicht auf Komprimierung wesentlich gesteigert werden.

Im Internet kommt es schon bei mittelgroßen Dateien zu Ladezeiten im Bereich vonmehreren Minuten. Vergleicht man dies allerdings mit einem Post-Transport, so ist derZeitgewinn beträchtlich. Diese Verzögerung tritt pro angeforderte Variante auch nureinmal auf, da alle Darstellungs- und Grafikänderungen auf dem Client stattfinden. Mitdem Aufkommen der DSL-Technologien ist auch hier mit einer Besserung zu rechnen.

Eine Implementierung der gesamten Netzwerkschnittstelle in CORBA wurde aufgrunddes komplexen Objektmodells verworfen.

Ein weiteres interessantes Ergebnis des Projekts ist, dass das iterativ, inkrementelleVorgehensmodell (vgl. Fowler 1999, Einsatz im Projekt vgl. Kapitel 11.3) für die Ent-wicklung von Software unter den erschwerten Begleitumständen einer Entwicklung imFachhochschulumfeld ausgezeichnet geeignet ist und zu guten Ergebnissen führt (vgl.Kapitel 6).

9 Veröffentlichungen

Ein erster Prototyp der Anwendung wurde auf der Lüdenscheider Technologiemesse(Dezember 1998) auf dem Stand der Märkischen Fachhochschule präsentiert.

Die bisherigen Ergebnisse wurden auf der Tagung “Grundwassermodelle” am TGZ derRuhr-Universität Bochum (18.11.99-19.11.99) unter dem Titel “Multimediale Darstel-lung von grundwasserwirtschaftlichen Planungsdaten in Internet und Intranet: EinJava-Framework auf Basis von RMI, CORBA, JNI und JDBC” vorgetragen und werdenin Kürze in den Proceedings zu dieser Veranstaltung erscheinen. Eine Veröffentlichungim Journal of Hydroinformatics ist in Vorbereitung.

10 Technologietransfer

Das Projekt wird in enger Zusammenarbeit mit der Firma GKW durchgeführt. Ein Pro-totyp für die Erstellung multimedialer Projektberichte (vgl. Kapitel 5) wird bereits ein-

gesetzt. Die Umsetzung des Prototyps der Gesamtanwendung in eine Anwendungwird nach Abschluss des Projekts realisiert.

Durch Veröffentlichungen und Vorträge (vgl. Kapitel 9) sowie durch Diplomarbeiten sollein Transfer auf andere Branchen erreicht werden. Die RMI betreffenden Ergebnissewurden bereits erfolgreich bei einer Diplomarbeit bei der DMT in Essen eingesetzt.

11 Projektmanagement, Arbeitsorganisation, Mitarbeiter und Verantwortlichkeiten

Leiter des Teilprojekts:Prof. Dr. Bernd BlümelLabor für e-BusinessFH Bochum, Fachbereich WirtschaftUniversitätsstraße 15044801 BochumTel.: 0234-32-10614Fax: 0234-32-14224email: [email protected]: http://www.fh-bochum.de/fb6/

11.1 Hardwareanschaffungen und Softwareinstallationen

• 2 Workstation angeschafft

• Datenbankserver in Bochum und Hagen beschafft und installiert

• Linux installiert

• YARD-SQL installiert

• Java Workshop installiert

• NetBeans installiert

• SPRING installiert

• TogetherJ installiert.

11.2 Mitarbeiter und Verantwortlichkeiten

11.3 Meilensteine / Iterative Vorgehensweise

Zeitraum Beschäftigungsart Tätigkeit

01.10.98 - 31.05.99 Studentische Hilfs-kraft

Einlesen und Übertragung der Da-ten, Datenbankinteraktion, Interakti-on mit SPRING

01.10.98 - 31.12.98 Vollzeit-Mitarbeiter Grafische Darstellung der Ergebnis-daten, Dokumentation

01.06.99 - 31.08.99 Vollzeit-Mitarbeiter Umstellung auf CORBA, Erstellung einer Anwendung zur Pflege der Datenbank, Dokumentation

01.08.99 - 08.10.99 Studentische Hilfs-kraft

Benutzerschnittstelle, Hilfesystem

22.11.99 - 31.05.00 Performance-Analysen

10.09.00 Installation des Prototyps bei der Fir-ma GKW

01.10.98 Projektbesprechung mit dem Kooperationspartner: Aufnahme AnforderungenGrobkonzeptionierung Anwendungsstruktur

02.10.98-07.10.98 Ermittlung und Strukturierung der Anforderungen, Ermittlung Prioritäten-liste, Software-Installationen

08.10.98 Projektbesprechung mit dem Kooperationspartner: Verabschiedung AnforderungenVerabschiedung PrioritätenlisteKlärung der Datenstruktur (PLX)

08.10.98-11.01.99 Analyse des Aufbaus der PlotdateiKonzeptionierung, Entwicklung und Implementierung des Objektmodells zur Aufnahme der PlotdatenKonzeptionierung, Entwicklung und Implementierung des RMI-Modells Konzeptionierung, Entwicklung und Implementierung des Grafikmoduls zur Kartendarstellung

12.01.99 Projektbesprechung mit dem Kooperationspartner:Präsentation und Verifizierung der bisherigen ErgebnisseDiskussion der Datenbankstruktur

13.01.99-07.04.99 Konzeptionierung, Modellierung und Implementierung der Datenbank-struktur (Yard)Konzeptionierung, Modellierung und Implementierung des JDBC-ZugriffsUmstellung Yard, OracleVerbesserung des Grafikmoduls

12 Integration in die Lehre

Das Projekt umfasste drei Diplomarbeiten:

Carsten Metzler: Multimediale Darstellung von grundwasserwirtschaftlichen Pla-nungsdaten in Internet und Intranet

Markus Hagebölling: Entwicklung eines Konzeptes zur Messdatenerfassung mit derSoftware DMT DACweb

Marco Viehl: Performance-Studien bei einer verteilten Internet/Intranet-Anwendung

Ergebnisse des Projekts werden in der Lehrveranstaltung (Wahlfach) “Java-Entwick-lung für Fortgeschrittene” diskutiert und eingesetzt.

13 Kooperationen im Rahmen des Verbundes

Im Rahmen des Forschungsverbunds besteht eine intensive Zusammenarbeit mit denKollegen Prof. Hillen und Prof. Stenzel insbesondere bei der Entwicklung und Analysevon Schnittstellen zwischen dem Frontend und der dahinter liegenden Datenbank.

08.04.99 Projektbesprechung mit dem Kooperationspartner:Präsentation und Verifizierung der bisherigen ErgebnisseAnalyse: Erstellung der PLX-Datei nach Benutzereingaben durch die Spring-Anwendung

09.04.99-27.04.99 Installation der SPRING-Software auf dem ServerKonzeptionierung, Entwicklung der Kommunikation mit der SPRING-Anwendung über JNI

28.04.99 Projektbesprechung mit dem Kooperationspartner:Präsentation und Verifizierung der bisherigen ErgebnisseGrundidee Viewer für elektronische Medien (vgl. Kapitel 5)

29.04.99-02.08.99 Entwicklung des Viewers für elektronische MedienBeginn der CORBA-ArbeitenEntwicklung einer Anwendung zur Pflege der Datenbank

02.08.99 Projektbesprechung mit dem Kooperationspartner: Präsentation und Verifizierung der bisherigen ErgebnisseDiskussion Benutzerinteraktion und Hilfesystem

03.08.99-11.12.99 Konzeptionierung, Modellierung und Implementierung des Benutzerin-teraktion-Systems

12.11.99 Präsentation und Diskussion der bisherigen Ergebnisse an der FH mit allen ProjektbeteiligtenEvaluierung der Vorgehensweise und ErgebnissePlanung der nächsten Teilschritte

19.11.99 Präsentation der bisherigen Ergebnisse auf der Tagung “Grundwasser-modelle”

22.11.99 -30.04.00 Performance-Studien

10.09.00 Installation des Prototyps bei GKW

14 Zusammenarbeit mit dem Data-Mining Projekt

Die Zusammenarbeit mit dem Data-Mining-Projekt ist vertieft worden (vgl. Projektbe-richt von Prof. Dr. Johannes “Neuronale Fuzzy-Logik für Data-Mining”). Die im Rah-men des in diesem Abschlussbericht beschriebenen Projekts installierte Yard-Daten-bank wird im Data-Mining-Projekt ebenfalls genutzt. In diesem Projekt wird die im Rah-men des Data-Mining-Projekts beschaffte und installierte Oracle-Datenbank mitge-nutzt.

In Hagen wurde in Zusammenarbeit mit dem Data-Mining-Projekt ein neuer Daten-bank-Server angeschafft und installiert.

Prof. Harald Gatermann

From Vrml to Augmented Reality Via Panorama-Integration and Eai-Java

From Vrml to Augmented RealityVia Panorama-Integration and Eai-JavaAbstract

The author shows the enhancement of abstract and �sterile� VRML-scenes by integration ofpanoramas, made from stitched photographs or special panorama cameras. The problem of havingonly one point of view in a photograph taken from a fixed point can be solved by using a defined,invisible �box� in vrml, which allows a movement of just a few meters, but also turning around andgetting a kind of Augmented Reality.

The next development of interaction not only in movement is the interactive integration of vr-objectsby using EAI-Java-Tools.

Resumo

O autor mostra o desenvolvimento de cenas-VRML abstratas e �estéreis� pela integração de panoramas,feitos através de fotografias tradicionais �coladas� ou câmeras especiais. O problema de existir apenasum ponto de vista nas fotografias tiradas de um ponto fixo pode ser resolvido usando-se uma �caixa�definida e invisível em vrml, permitindo um movimento de alguns metros, além de rotacionar e propiciaruma espécie de Realidade Aumentada.

O próximo desenvolvimento de interações, não apenas no movimento, é a integração interativa deobjetos-rv utilizando-se EAI-Java-Tools.

VRML

VRML was a fascinating invention by standardizing 3d-geometry worldwide, by enablingvirtual buildings und communities, by enabling global engineering and communication inthe field of architecture and planning.

One of the great advantages for architects is the ability of nearly every cad-program toexport 3d-constructions to vrml - by this means it is possible for architects, students,client, multi-disciplinary-workgroups on different places in the world to talk about thoseconstructions or threedimensional concepts or even works together on those projects.

Nevertheless VRML normally shows artificial, abstract and sterile pieces of architecture,far away from all those little details of the real world. Especially compared to a photographyou see the difference and the poorness of this kind of digital abstraction (figure 1).

Harald [email protected] Bochum School of Architecture,Bochum, Germany

figure 1 - Sterile virtual worlds

figure 2 - Moving Threatre

figure 3 - Stitched photographs

QTVR and other panorama-techniques

On the other hand Quicktime-VR was invented, followed by other similar techniques ofshowing 360-degree-panorama-scenes, such as IPIX, RealVR, Smoothmove etc. It seemedto be a very new kind of mirroring our real surrounding, but it was not more than asophisticated transfer of a very old idea into the world of digital media: the “movingpanorama”, which was already used in british theatres a hundred years ago! (figure 2)

One of the fascinating ideas in Quicktime-VR and similar techniques is the stitching-process, which abandons expensive equipment (figure 3). In Bochum we also started withthis kind of low-tech-panoramas, but we found out, that those panoramas are just goodenough for illustrating web-pages, but not for creating full-screen immersive impressions.So we used the most professional analog-panorama-camera, the Roundshot 220 (figure 4)and we bought one of the first digital panorama-cameras, the Pano-Cam (figure 5) Thisenables us to create a full-screen pano-photo in a few seconds (vertical capacity 5000 px)!

figure 6 - six sides form a cube

figure 5 - Pano-Cam (digital panorama)figure 4 - Roundshot (analogue panorama)

While Quicktime-VR only delivers cylindric panos, IPIX, Smoothmove and the early versionsof Real-VR also deliver spheric-views, made by using fisheye-lenses (either stitched or rotated).

The fisheye-photographed surrounding of the point, the photograph was taken, can beshown as a flat projektion (always with the ratio of 1:2, which results from the 180degrees vertical and 360 degrees horizontal). Alternately some programs (as Smoothmove)can transform and export the sorround-picture into a cube with 6 sides. (figure 6)

figure 9 - vr-scenary: alternative indoor-design for a museumfigure 8 - EAI-interactivity

figure 7 - 360-degrees background

Combining VRML and panorama-techniques

In Bochum we tried to combine both: digital panoramas (first we used panoramas, “stitched”by Quicktime VR, then we used RealVR, later labeled as Livepicture´s IVR), which iscompatible to VRML 2.0. VRML also enables creators to use a background, formed by sixsides of a cube. Normally those sides are made from colored backgrounds. When usingphotgraphes (made from a panorama-camera), those 6 sides are totally melted togetherand creating a totally realistic interactive background (figure 7).

This enabled us to realize different sceneries:

- creating a virtual building on an unbuild site, looking at the virtual building and also seeingthe naturally “textured” surrounding.

- going inside a virtual building, simulating the view to the site (when turning around, youcan have a “natural” view into the garden

We had to develop the integration of panoramas in vrml and the cad-model in vrml - a steptowards “augmented reality”. But there is one point, which restrict the movement insidea vr-model: the point of view, either in a static photograph or in a panorama-photograph,limitates the movement of the user in a vr-world. While it is possible in vr-worlds withouta photographic-background, to move around and look at the vr-scenery from differentpoints, the usage of a photographed background sets limits: it is only possible to movearound for a few meters. We defined an invisible VR-Box, which allows the movement andthe turn around to see the panorama from different sides.

Interaction inside VRML

Another field of engagement is interaction inside of VRML-sceneries - made with VRMLand EAI. We already have some prototypes of VRML-EAI and are developing the nextgeneration of navigation inside augmented reality.

We have developed an interactive toolbox, creating geometric elements directly insideof vrml-worlds.

At the moment we work on combining digital-panorama-surroundings with interactiveeai-generated virtual objects for interior design as well as for architectural planning in thecities together with “normal” people (citizens, neighbours, non-architects) - simulatingalternatives, developed by specialists like architects, town-planners etc. There is a realsucess and more confidence in the planning by this kind of vr-simulation instead of onlyworking with maquettes.

Interaction for Non-Architects

The fields of using these techniques reach from professional design to design with non-architects, with users of any kind of architectural object - e.g. a museum. We are justdesigning an exhibition in a museum, using all thoes techniques: photographing thesurrounding with Pano-Cam, converting the photo-file, combining with cad-exportedvrml and creating a new world: finding alternative Design by interactive simualtion !!

Prof. Harald GatermannDipl.-Ing. Juergen Czerner

From VRML to Augmented Reality via Panorama-Integration and EAI-Java


FH Bochum International School of Architecture Bochum Germany


FH Bochum International School ofArchitecture Bochum Germany

students from 20 countries Internationality:Interdisciplinarity: architecture,

civil engineering, photogrammetry


FH Bochum International School ofArchitecture Bochum Germany

CAAD, Visualisation, DTP, HTML, Photography,Coll. Design (V-Studio)

Teaching:

Research:Hypermedia, VRML-Tutorial,Panorama-Photography, AR, VR

2 via panorama-photography (QTVR / Real-VR)

1 from VRML . . . to AR

3 and EAI (Extern Authoring Interface for VRML)

Topics:

1 VRML . . . VRML is an international standard fordescribing 3D-geometrycreated by . . . enthusiastscreated for . . . multimediaused by . . . . . architects

1 VRML . . . VRML has many benefits:- easy to use (export from CAD-programs)- can be „tuned“ with textures and

multimedia-effects (sound, video etc.)

- can be used for VR-flights, walkthroughs,-films and any kind of kinetic effects

1 VRML . . . but VRML also has many lacks:- difficult data structure in complex worlds- structures for efficient models are different

from those exported by cad-programs

- VRML-models often look and feel sterile, cold and artificial because of their synthetic origin

2 Quicktime VR + Panorama-Photography panorama-photography again became popular in 1994, when Eric Chen developed the Quicktime-VR-technology for Apple

> Sehsucht

2 Quicktime VR + Panorama-Photography But it was not new!It was used in british theatres 100 years ago

> Demo Goebel-Panorama

2 Quicktime VR + Panorama-Photography

Quicktime VR is interactivQuicktime VR is internet-based and works online world-wide

Quicktime VR ist a closed system

And 99% of the people only know it as a web-gimmick in the size of a stamp

-

+

> Demo QTVR auf HTML-Seite

2 Panorama-Photography

Quicktime VR (and similar systems . . . )became popular because

panos could be created with low-tech-equipment


Quicktime VR (and similar systems like Smoothmove, IPIX, Livepicture etc.)can be improved by using the full screen

> Demo Copacabana, Schloß Burg

getting immersive effects (feeling like being inside a real or a virtual surrounding)


Quicktime VR (and similar systems . . . )could be improved by . . .

Using professional equipment(analog Pano-Camerasanddigital Pano-Cameras)> DLR

2 Panorama-Photography + Real-VR

A few years later Eric Chen created Real-VR, an open system, based on VRML 2.0

#VRML V2.0 utf8

Vista

{type „CYLINDER„ filename „pano.jpg"

}

#VRML V2.0 utf8

Vista

{type "SPHERE„ filename „pano.jpg"

}


By using fish-eye-lenses you get a 360 degree surrounding

> Demo Peter Murphy Powerhouse Museum


VRML 2.0 can use a cube with 6 sides as backgroundBy mapping a modified panorama

on the sides,you get a photorealistic immersive surrounding

> Demo Peter Murphy Powerhouse Museum Sydney

#VRML V2.0 utf8

Background {

frontUrl "pano1.jpg"

backUrl "pano3.jpg"

leftUrl "pano4.jpg"

rightUrl "pano2.jpg"

bottomUrl "u.jpg"

topUrl "o.jpg"

}

3 QTVR vs. VRML

VRML

QTVR . . .

-cylinder-projection

Real-VR . . . -cylinder-projection

or spheric projection

3 RealVR + VRML combining a photorealistic surroundingwith VR-Objects

> Hohensyburg

3 QTVR + VRML

or combining VR-Objects with a photorealistic surrounding

> powerhouse.wrl

3 . . . To Augmented Realityinstead of sterile CAD-/VR-Worldsa photorealistic surroundingcombined with VR-Objects

3 . . . To Augmented Reality

. . . combined with VR-Objects not only forprofessionals and experts, but also for

„real“ people

4 EAI („Extern Authoring Interface“). . . interactive influencing VRML-worlds from a menu outside the VRML-window

people can send their proposal to the professional planners

The End . . . we are not at the end of our ideas . . .

http: // www . vr-box . de

. . . maybe someone would like to accompany our way . . .

. . . we are still going forward . . .

Prof. Dr. Walter Hillen

Java Image Viewer zur Darstellung und Verarbeitungmedizinischer Bilddaten in Rechnernetzen

Java Image Viewer zur Darstellung und Verarbeitungmedizinischer Bilddaten in Rechnernetzen

W.Hillen, F.Unglauben, R.Indefrey

Medizinische InformatikFH - Aachen Abt. Jülich, Biomedizinische Technik

Email: [email protected]

Zusammenfassung. Auf der Basis der Java-Programmiertechnik wurde ein Image-Viewer entwickelt, mit dem medizinische (DICOM-)Bilddaten, Befunde und Patienten-informationen innerhalb und außerhalb des Krankenhauses dargestellt und verarbeitetwerden können. Die Java-Anwendung ermöglicht eine Informationsübertragung imIntra- und Internet, die unabhängig ist von der Hardware und vom Betriebssystem desClients. Der Funktionsumfang der auf den Client übertragenen Software zur Visualisie-rung und Verarbeitung der Bilddaten wird vom Server genau auf die jeweils ausgewähltemedizinische Anwendung abgestimmt.

Schlüsselwörter: medizinische Bildverarbeitung, verteilte Informationssysteme, Java,DICOM, PACS.

1 Einleitung

Medizinische Bildinformation wird in der klinischen Diagnostik weitgehend digitalaufgenommen und verarbeitet. Die Bilddaten von CT-, MR-, Angiographie- undnuklearmedizinischen Geräten werden hierbei in der Regel zentral verwaltet (Bild-/ Patientendatenbank) und auf speziellen Befundungskonsolen ausgewertet. DieWeiterleitung der Bilddaten und Befunde z.B. zur chirurgischen Abteilung, zu denKlinikstationen oder auch zum niedergelassenen Arzt (außerhalb des Krankenhau-ses) erfolgt allerdings oft noch in Form von Filmkopien und Textdokumenten.Die Übertragung der Bilddaten, Befunde und Patienteninformationen in digitalerForm innerhalb und außerhalb des Krankenhauses im Intra- und Internet sowiedie multimediale Darstellung und Verarbeitung der Informationen ist das generelleZiel der vorliegenden Aktivität.

2 Systemkonzept

Das Konzept des Informationssystems zur Darstellung und Verarbeitung medizi-nischer Bilddaten im Intra- und Internet ist in Abb. 1 dargestellt. Typischerweisewerden die Bilddaten der unterschiedlichen diagnostischen Systeme (CT, MRu.s.w) auf speziellen Befundungskonsolen ausgewertet und in einem zentralenBildarchiv (Picture Archiving and Communication System, PACS) gespeichert.Ebenfalls werden in speziellen Datenbanksystemen (KIS, RIS) die Patientendatenund Befundungsergebnisse verwaltet. Im dargestellten Systemkonzept verbindet

ein spezieller Web-Server das zentrale Datenarchiv der radiologischen Abteilungmit den dezentralen Arbeitsplätzen (Clients). Die Kopplung zwischen Web-Serverund Clients erfolgt über Intra- oder Internet. Die Clients können sowohl in denverschiedenen Klinikbereichen (Intranet-Kopplung) als auch in den Praxen nie-dergelassener Ärzte (Internet-Kopplung) plaziert sein. Auf dem Web-Server istein verteiltes Informationssystem installiert, das auf den Datenbestand des Zent-ralarchivs zugreift. Zu diesen Daten zählen die Patientendaten, die patientenbezo-genen Applikationen sowie die Daten , die einer einzelnen Applikation zugeordnetsind. Die applikationsbezogenen Daten bestehen im allgemeinen Fall aus denBilddaten, den Ergebnissen der Befunde (in Form von Textdokumenten und/odergrafischen Overlays) sowie spezifischen Parametern der Aufnahmesysteme undParametern zur Steuerung der Java-Anwendung auf dem Client. Dieser „Daten-satz“ einer medizinischen Applikation wird zusammen mit dem Java-Code beieiner User-Anfrage vom Web-Server auf den Client übertragen.

Abb.1: Systemkonzept eines verteilten, multimedialen Informationssystems imBereich der bildgebenden Diagnostik.

Der Systembenutzer benötigt auf dem Client (PC, Mac, Sun, ...) mit Ausnahmeeines Netz-Browsers keine spezielle Softwareinstallation. Damit entfallen sowohldie Erstinstallation der Software als auch spätere Software-Updates auf den de-zentralen Arbeitsplätzen. Die Pflege der Bild- und Patientendatenbank, die Ein-

stellung der applikationsbezogenen Parameter sowie der vollständige Sevice derSoftware erfolgen auf dem Web-Server.

Das Java-Framework garantiert eine von der Hardware und von dem Betriebs-system der Client - Rechner unabhängige Anwendung. Diese Plattformunabhän-gigkeit stellt eine der generellen Vorteile der Java-Applikation dar. Hierdurch wirdgewährleistet, dass die Vielfalt der heute eingesetzten Systeme in gleicher Weiseunterstützt wird.

3 Programm - Funktionen

Innerhalb der Java-Anwendung wählt der Benutzer die gewünschte medizinischeApplikation eines Patienten aus und aktiviert damit die Übertragung der Bilddatensowie der zugehörigen Befunde und Patienteninformationen (applikationsbezoge-ne Daten) vom Server auf den Client. Ebenfalls werden sämtliche Java-Komponenten zum Einlesen, Darstellen und Verarbeiten der Daten in Form einesJava-Applets auf den Client übertragen und zur Ausführung gebracht.

In der Anwendung werden verschiedene Methoden der Bilddarstellung und derinteraktiven Bildverarbeitung sowie Verfahren zur Visualisierung von Patientenin-formationen und Befunden bereitgestellt. Zu den bislang realisierten Möglichkei-ten der Darstellung und Verarbeitung der Bilder und Informationen gehören:

• Unterstützung medizinischer Bildformate (DICOM) mit einer Digitalisierungs-tiefe von 8-Bit bis max. 16-Bit pro Pixel.

• Darstellung von Einzelbildern und Bildgruppen (z.B. CT- / MR- Applikatio-nen) sowie spezielle Darstellung von Kardio-Bildsequenzen in Echtzeit.

• Interaktive Bildoperationen zur optimalen Wiedergabe der Bilder (z.B. Kon-trast- / Helligkeitsanpassungen, Bildfilter, Zoomfunktionen).

• Intuitiv bedienbare, auf den Anwendungsfall zugeschnittene Benutzeroberflä-che.

Alle Bildverarbeitungsschritte werden in voller Digitalisierungstiefe durchgeführt.Zur Darstellung von Bildern mit mehr als 8-Bit ist ein eigenes Color-Model entwi-ckelt worden. Das Color-Model führt eine Projektion der Daten in den 8-Bit Dar-stellungsbereich durch über eine beliebig einstellbare 16- auf 8-Bit LUT-Operation.

Die Methoden und der Funktionsumfang der zur Anwendung gebrachten Soft-ware-Module sind genau auf die jeweils ausgewählte Applikation abgestimmt. Sosind z.B. Bildverarbeitungsschritte wie Restaurationsfilter auf den einzelnen An-wendungsfall und das verwendete Aufnahmesystem optimiert. Ebenso werden imGegensatz zu einer fest installierten Software dem Benutzer nur Operationen und

Visualisierungsverfahren bereitgestellt, die für die gewählte Applikation sinnvollsind. Damit wird eine einfache, applikationsbezogene und zielgerichtete Pro-grammanwendung realisiert mit einer intuitiv bedienbaren und auf den Anwen-dungsfall zugeschnittenen Benutzeroberfläche.

Die Benutzeroberfläche des Programms wird automatisch angepaßt und optimiertin Bezug auf unterschiedliche Bildschirmauflösungen und benutzerabhängigeBrowser-Einstellungen. Ein Beispiel für die Organisation der Benutzeroberflächezeigt Abb.2. Im dargestellten Beispiel wird eine CT-Bildsequenz wiedergegeben,wobei Darstellungsart und Benutzerführung der Anwendung entsprechend ges-taltet sind. Analog zur Darstellung von Bildsequenzen bietet das Programm spe-zielle Darstellungsmoden zur Wiedergabe von Einzelbildern und Bildgruppen.

Abb. 2: Organisation der Benutzeroberfläche auf dem Client(Dargestelltes Beispiel: Visualisierung von Einzelbldern)

4 Programm - Evaluation

Die Java-Anwendung wurde in einer Laborumgebung mit den Browsern NetscapeCommunicator und MS Internet Explorer getestet und insbesondere hinsichtlichder Funktionalität und der Ausführungsgeschwindigkeit ausgewertet. Die Anwen-dung erwies sich unter beiden Browsern im Betrieb als absolut stabil. Ein beson-

derer Schwerpunkt der Evaluation lag in der Untersuchung der Ausführungszeitenbeim Einlesen komplexer Bilddaten und bei rechenintensiven Bildoperationen.Das Java-Applet benötigt zum Einlesen eines 1,9k*1,7k großen 16-Bit Bildes ca.3,7 s (Pentium-PC 700 MHz mit 100 MB/s Netzanbindung unter Win 98). EineFIR-Bildfilterung mit beliebigem 5x5 Kern benötigt bei dem gleichen Bild 3,8 s.

Die bisherigen Studien zeigen, dass unter Java ein relativ schnelles, verteiltes In-formationssystem für den Bereich der bildgebenden Diagnostik realisiert werdenkann mit vielfältigen Möglichkeiten der Bilddarstellung und der interaktiven Bild-verarbeitung, das den besonderen Vorteil der Plattformunabhänigkeit besitzt.

Dieses Projekt wurde unterstützt vom “Innovationsprogramm Forschung”des “Ministerium für Schule, Wissenschaft und Forschung” des Landes Nord-rhein Westfalen.

Study of Database Connections for a Java Medical Image Viewer

F. Unglauben, W. Hillen, M. Murdfield

Medizinische InformatikFH Aachen Abt. Jülich, Biomedizinische Technik

Ginsterweg 1, 52428 Jülich

Abstract: Different methods to connect a Java-Applet for Medical ImageVisualisation to databases are presented. Using Java Database Connectivity(JDBC) two-tier and three-tier applications have been developed. The middle-tieris built with Java-Applications and Java-Servlets connecting to the Applet usingRemote Method Invocation (RMI) and the Hypertext Transfer Protocol (HTTP).The evaluation aims at a Java based visualisation and processing of medicalimages in a distributed environment with a direct connection of the Java-Applet toexisting PACS.

Keywords : PACS, Teleradiology, Distributed Systems, DICOM, ImageInformation Systems, Java, Servlets, JDBC

1 Introduction

For archiving and retrieval of medical image data nowadays picture archivingand communication systems (PACS) are generally installed in large hospitals. Inthis environment diagnosis stations that are suitable especially for primarydiagnosis and databases that store image and diagnosis data are connectedthrough a Local Area Network (LAN). Picture creating devices as well as thePACS use the DICOM (Digital Imaging and Communications in Medicine)standard as their image format and standard interface. Viewing stations arespread all over the hospital to retrieve and view stored images . They allow aquick access to image and diagnosis data.

The Java technology allows to build viewing stations with no special softwareinstalled beside an operating system and a network browser. In this conceptJava-Applets are transferred together with image data and diagnosis informationfrom a web-server through the network to the client (viewing stations). Thenetwork browser that is installed on the client starts the Applet in its Java VirtualMachine (JVM). The connection of this client software to PACS is the target ofthe present evaluation. Possibilities to connect the clients (Java-Applets) todatabases in the PACS as well as the transfer of image data from the PACS tothe clients are presented.

2 PACS with distributed software

The basic concept of a PACS with an added web-server for distributed imagevisualisation is shown in figure 1. Medical images are transferred to the PACSwhere servers for storage and archival are connected to diagnosis stations. A

web-server is connected to the PACS. This web-server transfers Java-Appletsfor medical image visualisation together with image and diagnosis data throughIntra- or Internet to the clients that are located inside or outside the hospital. Inthe network browser that is installed on the clients the Applet is started andallows to view image and diagnosis data.A Java-Applet for viewing and processing medical images in a net browser waspresented by Hillen et al [1].

Fig. 1: Basic concept of a PACS with connected web-server for distributedmedical image visualisation on clients.

3 Connecting Java Applets to PACS

The system concept shown in figure 1 has been simulated in a laboratory set-up.An Oracle database has been structured according to the DICOM standard [3].This database keeps information about the patients’ studies and the location ofmedical images produced during these studies. As medical images can belocated on multiple storing devices the servername and path rather than theimage itself is stored in the database.

Java’s standard extension Java Database Connectivity (JDBC) has been usedto analyse different ways of applications with the general aim to realise anapplication that is written in 100% Java and therefore is completely platform-and system-independent [2].

Intranet

Internet

Web-Server

DiagnosisStorage/Archival

Medical Image Acquisition (CT, MR, DR...)

PACS

Clients(Viewing-Stations)

Realised database applications

Figure 2 shows two general concepts of the developed database applications.The upper part of figure 2 shows a two-tier application with a Java-Applet onthe client and the database installed on the web-server. Image and diagnosis dataare located on this web-server. The lower part (figure 2) shows several three-tierapplications with Java-Applets on the clients, Java Servlets or Java Applicationson the web-server (middle-tier) and the database and file system on differentservers. Each application uses a JDBC-Driver of Type IV for databaseconnection. This driver is written in 100 % Java and can be loaded from theweb-server to the Java-Applets on the client side.

Fig. 2: Basic structure/concept of a two-tier application consisting of clientsand a web-server in comparison to three-tier applications with aseparate web-server in the middle-tier.

The middle-tier is realised by using Java- Servlets and Java-Applications. JavaServlets can be started interactively from clients and run in the virtual machineof the web server whereas an application has to be started directly on the server.Network communication with the database server was realised in all cases by theOracle-JDBC-Driver. The network protocol between client (Java-Applet) andmiddle-tier (Java-Servlet/Java-Application) is used to send commands from theApplet to the Servlet and to transfer database query results and image data from

Java-Applet

Java-Servlet

JDBC-Driver

Web-Server (middle-tier)

Web-/Database-Server

Java-Servlet/Java-Application

Java-Applet

Clients

JDBC-DriverRMI

HTTP

Clients

Java-AppletJDBC-Driver

OracleDatabase

Storage-Server

File-System

Image-Data

Database-Server

OracleDatabase

Two-Tier Application

Three-Tier Applications

the Servlet to the Applet. It was varied by using Java’s Remote MethodInvocation (RMI) as well as the Hypertext Transfer Protocol (HTTP). Bothprotocols can be used in Internets because they are accepted by firewalls andproxy servers. In three-tier applications image data are transferred from anadditional storage server. Image data are transferred using I/O-Streams ondifferent protocols (RMI and HTTP). Java offers the possibility to transfer thedata-streams compressed with Lempel-Ziv-Algorithm. Furthermore in the three-tier application image data are copied to a temporary file on the web-server. Thisfile is overwritten as soon as another image is loaded and transferred to the Java-Applet using the FileInputStream.

To keep several connections simultaneously open to the database a hashtablewith connection objects has been created. This so called Connection Poolmanages and controls multiple connections to databases. Any Applet thatconnects to the middle-tier gets its own connection. This connection is checkedwhether it is free and valid.

The Java-Applet for medical image visualisation that is loaded to the clienthas interfaces to act either in a two-tier or in a three-tier environment. Theseinterfaces are each realised in one Java-class. Only this class has to be changedif the database structure changes. This facilitates the connection to any type andany structure of database in a PACS environment.

4 Results

The time it takes to open a connection and to query the database in two-tierapplications is determined by the processor power of the client. Connection andtransfer on a Pentium II 266 take less than half of the time they take on aPentium 133. Looking at three-tier models, only the performance of the web-server influences all database interactions. The client’s Applet only givescommands that are executed by the web server’s Servlet/Application. Howeverall results of database queries have to be transferred from web server to client.This transfer is dependent on the performance of both parts (client and webserver) as well as on the used network protocol. HTTP is twice as fast as RMI intransferring complex data.

Using Applets in a two-tier model means that databases as well as image datahave to be located on the web-server the Applet is loaded from. This is due toJava’s security restrictions. With a three-tier model Java-Servlets and -Applications are allowed to contact any server in an Intranet. Thereforedatabases and image data can be distributed on different machines. The transferof image data is strongly dependent on the network protocol. Again HTTP hasshown better performance. However transferring image data through an input-/output-stream leads to memory overflows with large images (>2.2 MBytes).Compressing the streams with Lempel-Ziv-Algorithm takes a lot of time andonly moves the overflow problem to another borderline (>3.5Mbytes). Copyingthe image data in a temporary file and loading this data directly to the Applet

using a FileInputStream has shown the best performance and no memoryoverflow even with large images (tested up to 12Mbytes in MS InternetExplorer).

Java-Applications have to be started on the middle-tier (web-server). Whenusing RMI the “RMIRegistry” has to be started as well. Servlets can be startedinteractively by accessing their URL. This can be done in a browser or by theJava-Applet itself. The “RMIRegistry” in this case is done in the Servlet’ssuperclass to avoid multiple inheritance as any Applet has to inherit fromHTTPServlet.

Connections can be opened at one time and kept in a hashtable. The Servletmanages the number of connections and makes sure that each connectionsremains valid. In the test environment only a small advantage in performancewas noticed.

5 Conclusions

The concept of using Java-Applets on clients offers the possibility to distributemedical images stored in a PACS through networks via a web-server as shownin [1]. One class can build the interface to databases and can be changed ifdatabases’ structure changes.

Two-tier database applications as realised in this project are only useful insmall environments. The web-server must contain the datbase as well as all theimage data as Applets are only allowed to contact the server they are loadedfrom. In real PACS environments where image and diagnosis data is distributedon several servers the use of Java Applets can only be realised by using three-tier applications with a web-server in the middle-tier. This gives the possibilityto query databases on any server and to retrieve image data from any storagedevice in the network. Java’s Remote Method Invocation (RMI) is a useful andsecure mechanism to transfer data through network but compared to HTTP it hasless performance.

Connection Pools are able to manage multiple connections to databases. Theirfunction and advantages have to be further tested in real environments.

6 References

1. Hillen W., Jansen N., Unglauben F., Indefrey R.: Multimediale Darstellung undVerarbeitung medizinischer Bilddaten in Rechnernetzen. Bildverarbeitung für die Medizin1998: 373-377. Springer-Verlag, Berlin, 1998:

2. Unglauben F.: Implementation of an Oracle database with a Java interface for medicalimage visualisation, Master Thesis, Coventry University, August 1999

3. Murdfield M.: Anlegen und Verwalten einer Oracle Datenbank für die medizinischeBilddarstellung unter Java, Diplomarbeit, FH Aachen Abt. Jülich 1999

This project was supported by the “Innovationsprogramm Forschung /Forschungsverbund: Multimedia an Fachhochschulen”of the “Ministerium fürSchule und Weiterbildung Wissenschaft und Forschung” (NRW-Germany).

Prof. Dr.- Ing. Martin Trautwein

Zusammenfassung

VR im Bauwesen

� Ausgangssituation Aus der Wahrnehmungspsychologie ist bekannt, dass der Mensch im Prinzip dreidimensional denkt.

So "sieht" ein Architekt bereits während der frühen Phasen des Entwurfsprozesses ein dreidimensionales Modell des späteren Gebäudes vor seinem geistigen Auge.

Dieses 3D-Modell muss nun in eine kommunizierbare und technisch nutzbare Form transformiert werden, was in der Regel mit Hilfe einer technischen Zeichnung geschieht.

Der Einsatz von 3D-CAD-Systemen beinhaltet hier ein erhebliches Nutzenpotential. Trotzdem ist zu beobachten, dass in vielen Architektur- und Ingenieursbüros leistungsfähige informationstechnische Werkzeuge wie 3D-CAD/CAE - Systeme bislang nur in geringem Umfang in eingesetzt werden. Mögliche Gründe hierfür sind:

• hohe Investitionen für die Schaffung einer angemessenen Hard- und Softwareumgebung

• notwendige Umstellung der bisherigen Arbeitsweise der Konstrukteure

• komplizierte 2D-Benutzungsoberflächen der 3D-CAD-Systeme

• keine durchgängige Verwendung des 3D-Modells über den gesamten Entwurfsprozess

Die Techniken der virtuellen Realität können hier zumindest teilweise Abhilfe schaffen.

� Realitätsnahe Visualisierung für Produktpräsentationen Das im Laufe des Entwurfsprozess entstehende 3D-Modell des Bauprojektes kann parallel für realitätsnahe Präsentation des Gebäudes vor dem Auftraggeber und/oder den spätere Nutzern bzw. Käufern herangezogen werden.

Insbesondere bei öffentlichen Bauvorhaben führt die anschauliche Darstellung des Projektes zu schnellerer Akzeptanz des Vorhabens bei der betroffenen Bevölkerung. Im Gegensatz zu üblichen Methoden (Holz-/Gipsmodellen oder animierten Videosequenzen) kann sich ein Betrachter frei in dem virtuellen Gebäude bewegen und die für ihn wichtigen Bereiche inspizieren.

Die Gebäudeinformationen werden so eingängig und leicht verständlich vermittelt.

� Verbesserung der Kommunikation zwischen Entwicklungsteams Auf Grund der hohen Komplexität von Bauprojekten und der Forderung nach kurzen Planungszeiten erfolgt der Entwurf parallel in verschiedenen, oft räumlich weit voneinander getrennten Planungsteams.

Die Zusammenführung der verschiedenen Entwürfe verursacht einen hohen Abstimmungsaufwand. Es besteht die Gefahr, daß Fehler zu spät erkannt werden und notwendige Änderungen im Entwurf zu spät, d.h. mit hohem zeitlichen und finanziellen Aufwand durchgeführt werden müssen.

Durch die realitätsnahe Visualisierung der Entwürfe verbunden mit der Möglichkeit der gemeinsamen Begehung durch die Architekten und Ingenieure mittels der VR - Technologie können Planungsfehler frühzeitig aufgedeckt werden. Durch Nutzung der zu Verfügung stehenden Hochleistungsnetze kann die gemeinsame Begehung auch von verschiedenen Standorten in Europa erfolgen.

Die technische Realisierung und die Ausdehnung dieser Idee auf den gesamten Lebenszyklus eines Gebäudes wird Gegenstand weiterer Untersuchungen sein.

� Projektablauf Zitat aus dem Projektantrag von 1997

� Vorbemerkung Visualisierung geplanter Situationen und Umgebungen ist seit den

Anfängen der Disziplin ein zentrales Anliegen aller Planenden und Entwerfenden im Bauwesen.

Mit dem Einsatz der Computer hat diese Visualisierung eine ganz neue Qualität erreicht, eine einmal mit Hilfe des Rechners entworfene Umgebung kann aus den unterschiedlichsten Betrachtungswinkeln dargestellt werden, ohne daß jeweils eine grafisch und handwerklich aufwendige Zeichnung erstellt werden muß. Animationen von Wegen durch Gebäude sind als Videofilm herstellbar.

� Die Absicht Da der technische Aufwand zur Realisierung der interaktiven und

immersiven Darstellung erheblich ist, planen die Antragsteller ein gemeinsames Erarbeiten der Grundlagen und Techniken der virtuellen Realität sowie der Datenkommunikation zwischen verschiedenen Standorten.

Aufbauend auf der identischen Hard- und Software sollen zunächst die Verfahren gemeinsam erprobt und zur Einsatzreife entwickelt werden. Die Antragsteller erwarten von diesem Vorgehen erhebliche Synergieeffekte. Aufbauend auf diesen Kenntnissen und in ständigem Erfahrungsaustausch soll dann in einem zweiten Schritt eine Umgebung entwickelt werden, die den Einsatz der genannten Techniken in den Fachgebieten der Antragsteller ermöglicht.

� Virtuelle Realität Eine virtuelle Welt, setzt sich aus verschiedenen Komponenten wie Geometrien, Oberflächen, Lichtquellen, Animationen und Sound zusammen.

� Geometrie Geometriemodellierung

Bei der Modellierung unterscheidet man grundsätzlich zwischen zwei verschiedenen Methoden.

Bei der 2D-Modellierung erstellt man zunächst einen zweidimensionalen Grundriss des gewünschten Objektes. Aus diesem Grundriß wird dann durch Extrusion oder Rotation ein dreidimensionales Objekt erzeugt.

Bei der3D-Modellierung wird das gewünschte Objekt aus vordefinierten Objekten - sogenannten Primitiven - zusammengesetzt oder aus diesen erzeugt.

In aller Regel wird im Bauwesen die Geometrie in CAD-Programmen erzeugt und in die Programme der VR importiert.

Viele CAD und CAAD-Programme enthalten heute Export-Module zu VR-Darstellungsprogrammen.

Häufig anzutreffen ist der Export nach VRML, bei CAAD-Programmen teilweise auch der Export nach O2C. Ein Teil der gängigen Programme des CAD im Bauwesen stellt allerdings nur eine Schnittstelle nach Visualisierungsprogrammen wie 3DStudio zur Verfügung.

� Reduktion durch Weglassen Zeichnungs- und Modellinformationen, die für den Bau eines Gebäudes wichtig sind, können für eine Visualisierung unnötig sein. Sie sollten beim Export der Geometrie weggelassen werden. Hierfür bieten sich zwei Lösungen an:

• Man kann die Layer- und Ebenentechnik der CAD-Programme nutzen und Exportfilter einbauen. (beispielsweise um Installationspläne zu eliminieren)

• Man kann Elemente, die für die Visualisierung keine Bedeutung haben, löschen

� Verringerung der Komplexität der Geometrie Die Komplexität der Geometrie - gemessen durch die Anzahl der Polygone, aus denen sich ein Element zusammensetzt - muss mit Rücksicht auf die Anforderungen einer Echtzeit - Visualisierung reduziert werden. Dies betrifft weniger Innen- und Aussenwände, deren ebene Oberflächen keinen Ansatz zur Reduktion bieten.

Reduktion ist vor allem bei Details notwendig, die aus Bauteilbibliotheken entnommen und eingesetzt werden, beispielsweise bei Tür- und Fenstergriffen.

� Reduktion durch Ersatzdarstellung Für bestimmte Bauteile wird es notwendig, Ersatzdarstellungen zu definieren und beim Export möglichst automatisch statt der konstruierten Elemente zu verwenden. Zweischaliges Mauerwerk kann so beispielsweise durch eine entsprechende Ersatzdarstellung visualisiert werden.

� Vereinfachung durch Texturen Bauteile mit komplexer Geometrie, die aus sehr vielen Polygonen zusammengesetzt werden müssten, kann man näherungsweise durch Orthophotos des Bauteils ersetzen, die als Texturen auf eine vereinfachte Ersatzdarstellung des Bauteils montiert werden.

� Licht und Oberfläche (Texturen) Licht und Oberflächenmodellierung

Eine Szene der VR wird stets durch eine oder mehrere Lichtquellen beleuchtet. Mit Blick auf die zu erreichende Framerate bei der Visualisierung wird es notwendig, die Zahl der Lichtquellen auf das Minimum zu reduzieren.

Schattenberechnung erhöht den Zeitaufwand für das Rendern eines Bildes erheblich.

Als Ausweg bietet es sich an, mit aufwendigen Renderverfahren Licht- und Schattenverläufe berechnen zu lassen. Die so erhaltenen Bilder werden dann als Texturen auf die Oberflächen gelegt.

Oberflächeneigenschaften

Den Objekten einer Szene müssen nach ihrer Modellierung geeignete Oberflächeneigenschaften, wie Farbe, Transparenz oder Glanz gegeben werden. So kann beim Betrachter ein möglichst naturgetreuer Eindruck erzeugt werden.

Texturen

Zusätzlich müssen oft auf die Objekte Texturen gelegt werden. Bei einer Textur handelt es sich um eine zweidimensionale Grafik, die in der Regel mit einem

Bildbearbeitungsprogramm erstellt wurde. Größe und Qualität der Texturen beeinflussen die Übertragungszeit über Netze und auch die Framerate bei der Visualisierung. Der notwendige Kompromiss zwischen Darstellungsqualität und Framerate wird stark durch die technische Entwicklung der Computer, vor allem der Grafikkarten beeinflusst

� Funktionalität Animation/Simulation/Interaktion

Viele der virtuellen Welten, die im Internet zu finden sind, enthalten Animationen, Objekte, die sich bewegen. Die Programmierung dieser Funktionalität wird durch Skripte möglich.

Interaktion mit einer virtuelle Welt meint, dass der Benutzer mit der Maus auf ein Objekt zeigt und durch Mausklick eine Aktion, z.B. eine Animation, auslöst.

Möchte man wirkliche Dynamik, also z.B. Animationen die sich durch bestimmte Zustände der Szene

ändern, muß man wieder auf Skripte zurückgreifen. Dies trifft auch auf Simulation zu. Man kann beispielsweise die

Flugbahn eines Balls unter Einfluß der Schwerkraft vorberechnen, die Bahn durch ein Skript errechnen

lassen.

Statische virtuelle Welten verlieren für den Betrachter schnell ihren Reiz. Deshalb wurde VRML in der Spezifikation 2.0 um animierte Objekte und Interaktion mit Objekten erweitert, um Szenen zu beleben. Auch VR-Formate wie Superscape, Realimation, World Toolkit oder SentAX unterstützen Animation und Interaktion.

Skripte

Um den Szenen ein „intelligentes“ Verhalten zu geben, werden Skripte eingesetzt. Dabei muß man zwischen proprietären und externen Skriptsprachen unterscheiden. VR-Tools unterstützten in de Regel eine

eigene (proprietären) Skriptsprache, während VRML-Tools die externe Sprachen, wie Java oder JavaScript,

unterstützen, ein solches Skript kann auch in einem anderen Tool verwendet werden kann.

Autonome Objekte

Der Ansatz sogenannter autonomer Objekte - Objekte mit einer gewissen Eigenintelligenz - soll die Interaktion so in denProduktionsprozess virtueller Welten integrieren, dass eine Programmierung nur noch für den Prototyp eines Objektes notwendig ist. Dies ist Gegenstand eines zur Zeit laufenden Forschungsvorhabens.

� Sound Der Eindruck sich in einer virtuellen Welt zu befinden wird durch räumlichen Klang verstärkt. Geräuschquellen werden je nach Entfernung zum Beobachter lauter oder leiser. Stereoklang ermöglicht es dem Betrachter die Position einer Geräuschquelle im Raum ungefähr wahrzunehmen. Im rahmen des Forschngsvorhabens spielt Sound lediglich eine untergeordnete Rolle.

� Modellieren der Umgebung � Vorhandene Bebauung

Vorhandene Bebauung in der Umgebung des zu visualisierenden Modells kann auf unterschiedliche Arten modelliert werden:

• Übernahme von Architektenentwürfen - analog

• Photogrammetrische Aufnahme der umgebenden Bebauung

• Nachkonstruktion eines Entwurfes nach Architektenplänen

� Photogrammetrische Aufnahme der umgebenden Bebauung Photogrammetrische Verfahren

Teilweise vom Boden aus, teilweise aus einem Steiger wurden Fotos der Häuserreihe in der Ölmühlenstraße aufgenommen. Aus gescannten Fotos wurden dreidimensionale Modelle der Häuser konstruiert, die dann auf dem Katasterplan platziert wurden. Die Rückseiten der Häuser und Seitenwände, die sich nicht fotografieren ließen, sind in den Modellen durch einfarbige Flächen ersetzt.

» Siehe Dokument: ..\VR-Projekte\Ölmühlenstr\Haus33.wrl

� Aufnahmen Dies soll hier am Beispiel des Hauses Ölmühlenstraße 33 gezeigt werden.

Aus den Bildern

entstand das dreidimensionale Modell.

� Ergänzung Die nicht fotografierten Seiten wurden ergänzt

und das Modell auf dem Katasterplan platziert.

� VR-Modell Es kann jetzt als 3D-Modell von allen Seiten betrachtet werden.

» Siehe Dokument: ..\VR-Projekte\Ölmühlenstr\Krankenhaus\Haus33.wrl

� Übernahme von Architektenentwürfen - analog Bei Entwürfen, deren Detaillierung für die Visualisierung nicht relevant ist, oder für die nur Skizzen vorliegen, können Ansichten gescannt und auf einen Körper mit den vorgegebenen Maßen als Textur aufgelegt werden.

» Siehe Dokument: ..\VR-Projekte\Parkhaus\parkhaus.WRL

� Nachkonstruktion eines Entwurfes nach Architektenplänen Wenn Gebäude auch von Innen zu betrachten sein sollen, stellt sich das aufwendige Nachkonstruieren eines Gebäudes in einem Modellierprogramm als einzige Möglichkeit dar. Da dies sehr

zeitaufwendig und damit teuer ist, sollte eine Nachkonstruktion nur in Ausnahmefällen erfolgen.

» Siehe Dokument: ..\VR-Projekte\ETC\ETC.WRL

� Vegetation Besonders zeitaufwendig und damit teuer in der Modellierung und rechenaufwendig beim Echtzeitrendern ist das Nachbilden von Vegetation. Folgende Verfahren versuchen das Problem zu lösen:

• Modellierung von Bäumen durch gekreuzte transparente GIF-Bilder

• Erzeugen von naturähnlichen Bäumen durch Skripte

• Modellierung von Vegetation durch Bilder mit Alpha-Kanal als Texturen

� Transparente gif's Die Bäume werden mit zwei rechtwinklig gekreuzten Rechtecken modelliert, auf denen als Texturen transparente GIF-Bilder gelegt wurden.

Im VRML-Modell sehen diese Bäume dann so aus:

� Bilder mit Alpha - Kanal Vergleichbar der Methode der transparenten GIF-Bilder wird in anderen VR-Modellierungsprogrammen mit Bildern gearbeitet, die einen Alpha-Kanal für die Transparenz enthalten. bei einem 8-bit Alpha-Kanal lassen sich weniger auffällige Übergänge in die Transparenz erstellen.

� Skripte in 3DSMAX Die Fähigkeit des Modellierungsprogrammes 3DStudio MAX Abläufe durch Skripte zu automatisieren, gibt die Möglichkeit durch frei erhältliche Skripte Vegetation zu modellieren.

Diese Vegetationsmodelle sind allerdings sehr abstrahiert und dennoch durch die Vielzahl der erzeugten Polygone zu aufwendig für ein Echtzeit-Rendering.

� Gelände

� VRML - Elevation Grid Übernahme digitaler Geländedaten

Von den Landesvermessungsämtern werden Daten zur Verfügung gestellt, welche die Geländehöhen in einem Raster mit konstanten Abständen angeben.

Die VRML97 - Spezifikation kennt einen Knoten "ElevationGrid". Dieser Knoten beschreibt eine gleichmäßiges rechtwinkliges Punkteraster mit variierender Höhe. Da die Punkte auf einem gleichmäßigen Raster liegen, muss nur der Rasterabstand angegeben werden. Zusätzlich wird nur eine Matrix der Höhen der einzelnen

Punkte benötigt. Es ist so möglich kleine und damit schnell zu visualisierende VRML Dateien zu erzeugen. Es wurde ein Programm entwickelt, das die Punktdaten aus der Landesvermessung direkt in ein ElevationGrid einliest und als VRML Datei ausgibt.

Das Programm erzeugt eine sofort zu betrachtende VRML Datei, es wird eine Kamera eingefügt, und es besteht die Möglichkeit, das ElevationGrid mit einer Textur zu überziehen. Außerdem kann ein Überhöhungsfaktor eingegeben werden, so sind die Höhenunterschiede besser zu erkennen.

» Siehe Dokument: ..\VR-Projekte\Gelände\dgm25elv.wrl

� DGM - z.B. aus MX Liegen Vermessungsdaten vor, können diese mit geeigneten Programmen in ein digitales Geländemodell übernommen werden. Die bei einer Dreiecksvermaschung erzeugten Polygone lassen sich in VR-Programme exportieren.

� 3DSVIZ - aus digitalisierten Höhenlinien Erstellung von Geländemodellen aus Höhenlinienplänen mit 3DStudio VIZ

In 3DStudio VIZ ist im Gegensatz zu 3DStudio MAX das AEC Objekt Gelände enthalten. Es generiert Objekte aus Konturliniendaten d.h. Höhenlinien. Hiermit ist es also möglich, sehr leicht aus Höhenlinienplänen - vorzugsweise im DXF Format - ein Gelände zu modellieren. Dazu erstellt 3DStudio VIZ aus den bearbeitbaren Splines eine Netzoberfläche über diesen Konturen.

Die Höhenlinien müssen nach 3DStudio VIZ importiert werden, und weil es sich dabei ja um 2D-Zeichnungsdateien handelt, muß jede Höhenlinie auf die richtige Höhe verschoben werden.

Wenn die Konturlinien für die Geländeerstellung erst einmal vorhanden sind, bietet die Funktion "Gelände" ein sehr gutes Werkzeug zur Geländemodellierung.

Der Nachteil ist, daß bei einem Export in eine VRML Welt eine sehr große Datei entsteht.

» Siehe Dokument: ..\VR-Projekte\Müller_Hense\D I P L O M - Präsentation 04.02.1999\Diplomarbeit\Geländemodell\Maxmodell.WRL

Visualisierung � Anforderungen an die Visualisierung

Um die geeignete Form der Visualisierung zu finden ist eine Betrachtung der Personengruppen erforderlich, für die die Modelle gedacht sind.

Dabei stellten sich zwei Personengruppen als maßgebend heraus:

• Planer Arbeit einzeln oder in kleinen Gruppen, hohe Affinität zur Technik, Bereitschaft zur Bedienung der Eingabegeräte

• Entscheidungsträger Gruppengröße 20 - 30 Personen, wenig technisches Verständnis, "Computerphobie"

� Personenkreis • Planer

Arbeit einzeln oder in kleinen Gruppen, hohe Affinität zur Technik, Bereitschaft zur Bedienung der Eingabegeräte

• Entscheidungsträger Gruppengröße 20 - 30 Personen, wenig technisches Verständnis, "Computerphobie"

� Technische Anforderungen Der Raumeindruck des virtuellen Modells wird als nicht verzichtbar eingeschätzt, daher soll auf jeden Fall eine Stereo-Darstellung erfolgen.

Aus den anzusprechenden Personenkreisen ergaben sich zwei Lösungsansätze zur Visualisierung. Da bei beiden Gruppen die Kooperation und Kommunikation über das Modell vorrangig ist, verzichten beide Lösungsansätze auf das Bewegungstracking.

Lösungsansatz für Planer:

Stereo-Darstellung am Monitor,

Betrachtung durch aktive Stereo-Brillen

Bewegungssteuerung mit Spacemouse

Lösungsansatz für Entscheidungsträger

Stereo - Projektion

Betrachtung durch polarisierte Brillen

Bewegungssteuerung durch Vorführer (im Dialog mit Betrachtern)

� Lösungsansatz Den beiden genannten Personengruppen muss die Visualisierung mit unterschiedlichen Techniken ermöglicht werden.

Für Planer kommt die Lösung 1 zum Einsatz:

Bei größeren Gruppen kommt eine Stereo-Projektion wie in Lösung 2 dargestellt zum Einsatz

� Lösung 1 Darstellung den Modells auf einem 21"- Monitor, Bilder für linkes und rechtes Auge zeitlich nacheinander.

Navigation mit Maus und Spacemouse

Betrachtung mit aktiver Stereobrille, die von einem Infrarotsender auf dem Monitor gesteuert wird.

� Lösung 2 Projektion der Bilder für rechtes und linkes Auge durch zwei Projektoren mit polarisiertem Licht

Betrachtung mit polarisierender Brille

Navigation mit Tastatur und Maus durch einen Bediener im Dialog mit den Betrachtern

� Hardware Die Stereo - Projektion wird von zwei EIKI-Projektoren realisiert, die mit polarisierenden Folien im Projektionsstrahl ausgestattet sind.

Wegen des hohen Absorptionsgrads der Folien muss der Raum abgedunkelt werden. Als Projektionsfläche dient eine metallisierte Leinwand.

Die Leinwand aus der Nähe:

Die Zuschauer tragen polarisierende Brillen, die ihnen auf Grund der Polarisierung die beiden Bilder für linkes und rechtes Auge aufbereiten.

� ein Rechner - zwei Grafikkarten Zum Einsatz kommt eine Grafik Workstation auf Basis Intel - Windows NT, die mit zwei Obsidian - Grafikkarten ausgestattet ist. Jede dieser Grafikkarten verfügt über zwei Voodo-2 Prozessoren.

� zwei vernetzte Rechner Zwei möglichst identisch ausgestattete Rechner auf der Basis Intel - Linux werden über TCP/IP vernetzt, die Treiber des Programmes SentAX übernehmen die Synchronisation der beiden Projektionen.

� Software-Voraussetzungen Für die Stereo-Projektion werden spezielle Treiber benötigt, die im Forschungsprojekt für das VR-Programm Realimation zur Verfügung standen.

Der Betrieb zweier vernetzter Rechner wird vom Programm SentAX unterstützt

� Weitere Visualisierungstechniken � High End

Kennzeichen der high end Visualisierungen sind:

• Lokalisieren des Standpunktes des Betrachters und seiner Blickrichtung ("tracking").

• Die virtuelle Umgebung reagiert auf die Bewegung des Betrachters.

• Interaktion mit dem VR-Modell beispielsweise über Datenhandschuh möglich.

Zum Einsatz kommen:

• Head-mounted Display (Datenhelm)

• CAVE / CUBE

• Holobench

Der Etat des Forschungsprojektes ließ den Einsatz dieser Visualisierungstechniken nicht zu. In Kooperation mit dem Heinz-Nixdorf-Institut der Universität Paderborn wurden Modelle auf die dort vorhandene Technik umgesetzt und ihre Einsatzmöglichkeiten untersucht.

� HMD Head-mounted display

Ein Helm, der - über den Kopf gestülpt - dem Benutzer die Möglichkeit gibt, sich in einem vom Computer generierten Raum zu bewegen. Die Kopfbewegungen werden analysiert und die entsprechenden

Änderungen auf zwei kleinen Monitoren, die sich in diesem Helm befinden, dargestellt.

� CAVE CAVE™ / CUBE™

begehbarer Raum (3 m Kantenlänge) mit Leinwänden als Begrenzung

über Spiegel werden diese von Projektoren angestrahlt

� Holobench Holo Bench™:

pro Wand wird ein Projektor und ein Spielgelsystem benötigt

aus Kostengründen werden nur ein paar Wände in die Projektion eingeschlossen manchmal findet die Decke oder der Fußboden als Projektionsfläche Verwendung

Auflösung: 1280 x 1024 Pixeln bei einer Frequenz von bis zu 120 Hz

Objektmanuipulation mittels Datenhandschuh. Shutterbrille für

dreidimensionalen Seheindruck notwendig

� Consumer Im Bereich Computerspiele sind eine Reihe von Neuheiten auf dem Markt, die dreidimensionalen Bildeindruck bei Computerspielen vermitteln.

Shutterbrille für 3D-Spiele u.ä.

Betrachtung von VRML-Dateien mit Hilfe des Blaxxun Plugins möglich

senkrecht aufeinander stehende Projektionsflächen

Projektionsfläche ca. 1800 x 1000 mm

Auflösung von 1280 x 1024 Pixeln

Objekte scheinen über dem Tisch zu schweben

Manipulation durch Datenhandschuh

Shutterbrillen oder Polarisationsbrillen für stereoskopische Sicht

� VR in der Verkehrsplanung Haltestellen der Stadtbahn Bielefeld

� Hst Bielefeld Hauptbahnhof Untersuchung zu einer neuen Wegweisung in der unterirdischen Haltestelle Hauptbahnhof

» Siehe Dokument: ..\VR-Projekte\Hauptbahnhof\newStadtbahnBI.WRL

� Hst Bielefeld Ölmühlenstraße Planung einer Haltestelle mit Hochbahnsteigen in beengten räumlichen Verhältnissen (Stadtwerke Bielefeld)

Realisierte Projekte

» Siehe Dokument: ..\VR-Projekte\HaltestelleOelmuehlenstr\OelmühlenstrWRL\Oelmuehlenstr.wrl

� VR in Denkmalpflege und Museumsarbeit Klosteranlage Marsberg - Bredelar

Freilichtmuseum Detmold

• Haus Moven

• Vinsebecker Kötterhaus

� Haus Moven Aufgaben:

• Rekonstruktion und Strukturanalyse des Hauses Moven im Freilichtmuseum Detmold

• Visualisierung der Umbauschritte

• Präsentation auf CD

» Siehe Dokument: ..\VR-Projekte\Ackroyd\Html\Index.html

� Vinsebecker Kötterhaus Rekonstruktion des "Vinsebecker Kötterhaus" im Freilichtmuseum Detmold in verschiedenen Zeitschnitten

» Siehe Dokument: ..\VR-Projekte\Gärtner\Diplom\html\Bauzustände.htm

� Kloster Bredelar Visualisierung des heutigen Zustandes der Klosteranlage Marsberg - Bredelar

(Verein für Ortsgeschichte Bredelar)

» Siehe Dokument: ..\VR-Projekte\KlosterBredelar\wrlWelt\Kloster.WRL

� VR für die Akquisition Neues Bahnhofsviertel Bielefeld (Cinemax, Parkhaus, Spassbad)

Höcker Zelte und Hallen

� neues Bahnhofsviertel Visualisierung des "Neuen Bahnhofsviertel" in Bielefeld zur Akquisition von Investoren (Fa. Goldbeck Bau)

» Siehe Dokument: ..\VR-Projekte\Müller_Hense\D I P L O M - Präsentation 04.02.1999\Diplomarbeit\modell.wrl

� Höcker Zelte Visualisierung des Auf- und Abbaus von Zelten der Firma Höcker für deren Internetauftritt

» Siehe Dokument: ..\VR-Projekte\Stücken\hoecker.de\index.html

� VR für die städtebauliche Beurteilung • Rosental in Detmold

• Willy - Brandt - Platz Bielefeld (Bahnhofsvorplatz)

• Haltestelle Universität der Stadtbahn Bielefeld

� Universität Bielefeld Fußgänger - Verbindung von der Haltestelle der Stadtbahn zum Hauptgebäude der Universität (Stadtwerke Bielefeld)

• Erster Entwurf

• Endgültiger Entwurf

� erster Entwurf

» Siehe Dokument: ..\VR-Projekte\Kreische\haltestelle.WRL

� endgültiger Entwurf

» Siehe Dokument: ..\VR-Projekte\HaltestelleUniBielefeld\wrlWelt\HaltestelleUni.WRL

� Bahnhofsvorplatz Bielefeld Willy - Brandt - Platz in Bielefeld (Bahnhofsvorplatz)

Untersuchung unterschiedlicher Verkehrsführung von Fußgängerströmen und unterschiedlicher Orientierungssysteme (Stadt Bielefeld)

» Siehe Dokument: ..\VR-Projekte\Friedrich\Bilder für Welt\Bahnhof.WRL

� Rosental Detmold Neue zentrale Bushaltestelle im Rosental Detmold (Ingenieurbüro Schröter und Ristein)

Alternativlösungen

• mit Membrandächern

• mit konventionellen Dächern

� Glasdächer

» Siehe Dokument: ..\VR-Projekte\HaltestelleRosental\wrlWelt\Rosental.WRL

� Membrane

» Siehe Dokument: ..\VR-Projekte\HaltestelleRosental\wrlWelt\MembranRosentalBlaugrau.WRL

� Neubau Familienfürsorge Einbindung des Neubaues der Familienfürsorge in das Stadtbild zwischen Schloss und Theater

» Siehe Dokument: ..\VR-Projekte\HaltestelleRosental\wrlWelt\Rosental II.WRL

Prof. Dr. Hans- Joachim Weber

VerbundforschungsprojektMultimediale 3D-Visualisierung der Herzmuskelerregung

VerbundforschungsprojektMultimediale 3D-Visualisierung der Herzmuskelerregung

EinleitungZur Initiierung und Koordinierung der Pumpbewegung besitzt das Herz ein Reizbildungs- undReizleitungssystem. Von einem übergeordneten Erregungszentrum aus, dem Sinusknoten,verläuft die Erregung physiologischerweise frei über die Vorhofmuskulatur. Vom AV-Knotenan erfolgt die Weiterleitung über ein verzweigtes System von Reizleitungsbahnen bis hin zuden Herzmuskelzellen der Ventrikel [Abb.1]. Das Gewebe dieser Bahnen ist makroskopischund mikroskopisch nur schwer von dem des Herzmuskels zu unterscheiden.Als Hilfsmittel zur Darstellung dieser dreidimensionalen Strukturen stehen in Forschung undLehre meist nur zweidimensionale Abbildungen oder Kunststoffmodelle zur Verfügung.

Die komplexen räumlichen Zusammenhänge der Herzanatomie und des Reizleitungssystems,die zeit- und ortsabhängigen dynamischen Abläufe des elektrischen Reizes und die dadurcherzeugte Kontraktion des Muskelgewebes sind aber durch zweidimensionale Darstellungennur schwierig zu erfassen und auch durch den geübten Betrachter oft kaum dreidimensionalvorstellbar. Noch diffiziler wird das Verständnis bei der Verbindung von medizintechnischenGeräten und vernetzten biologischen Regelmechanismen, wie z.B. der Wirkung einesHerzschrittmachers auf die Erregung des Herzens.Reale dreidimensionale anatomische Modelle ermöglichen zwar gute Einblicke in dieAnatomie, sind aber einigen Beschränkungen unterworfen. So lassen sie sich nicht

Abb.1: Längsschnitt des Herzens mit Erregungsbildungs- und Erregungsleitungssystem (grün) [1]

Linker Tawara-Schenkel

Rechter Tawara-Schenkel

Purkinje-Fasern

Ventrikelmuskulatur

HIS-Bündel

AV-Knoten

Sinusknoten

Vorhofmuskulatur

zerstörungsfrei für die Betrachtung beliebiger Schnittebenen öffnen. Beschriftungen könnenaufgrund des Platzmangels nur mittels Nummern erfolgen, deren Bedeutungen in Listennachgeschlagen werden müssen. Außerdem können anatomische Modelle meist nie sodetailgetreu gearbeitet werden, wie es die Natur vorgibt.Die Nutzung menschlicher Herzen läge daher auf der Hand, ist aber aufgrund desOrganmangels nur wenigen Experten vorbehalten. Neben der eben beschriebenen Schnitt–und Beschriftungsproblematik besteht bei natürlichen Herzen aber zusätzlich dieSchwierigkeit der Differenzierung zwischen Muskelgewebe und Erregungsleitungsbahnen.Daher sind natürliche Herzen, bezogen auf die Zusammenhänge von Anatomie undElektrophysiologie, nur bedingt für das Selbststudium geeignet.Virtuelle dreidimensionale Modelle hingegen unterliegen solchen Beschränkungen nicht,sie lassen sich zerstörungsfrei drehen, wenden, schneiden und beschriften. FarblicheKennzeichnungen können zur Hervorhebung und Differenzierung bestimmter Strukturenherangezogen werden. Zusammen mit Bildern, Zeichnungen und Texten können drei-dimensionale virtuelle Modelle eine Multimediale Lernumgebung ergeben und soHilfestellung bei der 3D-Visualisierung leisten.

Ziel des ProjektsIm vorliegenden Projekt sollen die Möglichkeiten der Informationstechnologie genutztwerden, um eine verständliche Darstellung des Reizleitungssystems Medizinern,Medizintechnikern und Entwicklern in der medizintechnischen Industrie zur Verfügung zustellen, für deren tägliche Arbeit die genaue dreidimensionale Kenntnis desReizleitungssystems unabdingbar ist.Zur Bild- und Informationserfassung sollen verschiedene Eingabemedien eingesetzt werden.Neben der analogen und digitalen Bilderfassung von spezifischen anatomischen undphysiologischen Sachverhalten und deren didaktischen Aufarbeitung sollen zurWissensvermittlung insbesondere virtuelle statische und dynamische 3D-Modelle sowieAnimationen entwickelt werden.Diese Visualisierungsmodule sollen in eine multimediale interaktive Lernumgebungeingebunden werden, mit der geeignete Präsentationsmöglichkeiten realisierbar sind.

Material und Methoden

Viewpoint-ModellDie Erstellung eines virtuellen Modells des Reizleitungssystems ist eine der Hauptaufgabendieses Projekts. Als Ausgangsbasis wurde ein Oberflächenmodell des Herzens von der FirmaViewpoint gewählt. Dieses aus 68.000 Polygonen bestehende Gittermodell beschreibt allegrößeren anatomischen Strukturen an der Außenseite und in den Hohlräumen des Herzens.Diese äußeren und inneren Oberflächen können mit Texturen (Oberflächenstrukuren)überzogen werden. So entsteht der Eindruck eines komplett modellierten Herzens, solangeman sich virtuell innerhalb der Hohlräume oder gänzlich außerhalb des Herzen befindet.Zwischen diesen Oberflächen ist das Herz hohl und substanzlos.

SoftimageBearbeitet wurde das Viewpoint-Modell mit der Software Softimage auf mehrerenWorkstations von Silicon Graphics (SGI) unter dem Betriebssystem IRIX. Diese Rechnerhaben speziell für grafische Anwendungen konzipierte Prozessoren und Systemkomponenten.Softimage ist eine Software, mit der Oberflächenmodelle aus Polygonen erstellt und animiertwerden können.

Softimage erlaubt es, Kamerafahrten zu simulieren, Lichtquellen einzustellen und Objekte zubewegen. Texturen definieren das Aussehen einer Oberfläche. Muster, Farben, Schatten undReflektion bestimmen dabei den Eindruck beim Betrachter.

ObjekterstellungGittermodelle, die durch Punkte und deren Verbindungslinien definiert werden, bilden dasGerüst der einzelnen Objekte, über die Texturen (Oberflächenstrukturen) gespannt werden.Um Objekte zu erstellen, werden geometrische Grundformen wie Quader, Kegel und Kugelnaneinandergefügt, gedehnt, gestaucht, extrudiert, gespiegelt und gedreht.

AnimationZur Animation eines Modells werden für jedes Bild im Prinzip die Position derGitternetzknoten und der Lichtquellen, die Reflektion der Textur und der Blickwinkel derKamera eingestellt. Softimage ist dabei in der Lage, die einzelnen Positionen der Kameraanhand einer vorgegebenen Kurve zu berechnen. Dafür muß der Weg um ein Objekt unddessen Anfangs- und Endpunkt festgelegt werden. Zusätzliche Angaben, wie die Größe derWinkelschritte, aus denen die Betrachtung erfolgen soll, oder die Geschwindigkeit derKamerafahrt bestimmen die Dynamik der Bewegung. Die Berechnung der Einzelbilder, dassogenannte Rendern, übernimmt die Software dann in langwierigen Rechenoperationen.

PortierungFür die Portierung der Filme auf andere Plattformen wurde das Apple Quicktime Formatbevorzugt. Hierbei spielt die Wahl des richtigen Kompressionsalgorithmus, des sogenanntenCodecs, eine bedeutende Rolle. Die Kompression mit dem JPEG-Algorithmus (höchsteKompressionsrate) lieferte die besten Ergebnisse unter Windows und MacOS in einemheterogenen Netzwerk unter Windows NT (Server).

Abb. 2: Screenshot aus Softimage. Drahtgitterdarstellung des Herzens: Vorhöfe weiß, Ventrikelaußenseite grün,Ventrikelinnenseite grau, Reizleitungssystem violett;

VideofilmeMikroskopische Aufnahmen von isolierten Herzzellen wurden mit einem inversen Mikroskop(Zeiss Axiovert 135) und einer digitalen Video-Kamera (Sony 3 CCD Color Video Camera)vorgenommen. Die Aufzeichnung erfolgte mit einem digitalen Videorecorder.

Videoaufnahmen von der makroskopischen Anatomie, wie Kamerafahrten am plastiniertenmenschlichen Herzen und am künstlichen Herzmodell, wurden mit einer 3 CCD Kamera(Sony DCR-VX1000E) durchgeführt. Ebenso erfolgten die Aufzeichnungen vonanatomischen Demonstrationen an menschlichen Herzen und vom schlagenden Herzen beiRöntgendurchleuchtung.Die Videobearbeitung erfolgte mit der Videoschnittsoftware iMovie auf Apple Macintosh mitanschließender Konvertierung in das Quicktime-Movie-Format.

Printvorlagen und FotosAbbildungen, Dias und Fotos wurden mit einem Flachbettscanner (Agfa ARCUS II) undeinem Diascanner (Nikon LS1000) digitalisiert und mit Photoshop bearbeitet.

Interaktive PräsentationDie Multimediale Aufbereitung der unterschiedlichen digitalen Inhalte erfolgte mit Hilfe derProgramme Macromedia Flash und Macromedia Director. Diese umfangreichen Authoring-Pakete sind insbesondere dafür geeignet, interaktive webfähige Präsentationen zu erstellen.Flash verwendet vektorbasierte Informationen für die Darstellung von Grafiken undAnimationen. Durch die Vektorisierung der Graphiken werden die Flashfilme sehr klein undsind plattform- und auflösungsunabhängig darstellbar. Intuitiv lassen sichBenutzeroberflächen erzeugen, durch Action-Scripts entstehen animierte interaktiveAnwendungen.Mit Flash wurden die Navigation und die interaktive Beschriftung der Abbildungen sowie dieanimierte Darstellung der Aktionspotentiale realisiert. Flash kann auch Filme und Sounds ausDirector aufrufen.In Director lassen sich Videos, Bilder und Sounds verschiedenster Formate steuern. DieSynchronisation vom animierten schlagenden Herzmodell mit Aufnahmen von natürlichenHerztönen sind ein Beispiel für die Arbeit in Director.

3D DisplayDer 18"-TFT-Monitor ELSA ECOMO 4D bietet eine völlig neuartige und faszinierendedreidimensionale Darstellung direkt auf dem Bildschirm. Die innovative Technik ermöglichtdie permanente Darstellung unterschiedlicher Bilder für das rechte und linke Auge.Wie beim natürlichen Sehen (linkes und rechtes Auge) wird das darzustellende Objekt auszwei gering differierenden Blickwinkeln betrachtet.Der ECOMO 4D erzeugt vertikale, spaltenförmige Teilbilder. Dabei können die Spalten mitgerader Nummer für das Halbbild des linken Auges und die Spalten mit ungerader Nummerfür das Halbbild des rechten Auges gleichzeitig erzeugt werden. Durch eine Prismenmaske,die dem LCD-Display vorgelagert ist, werden die Lichtstrahlen der spaltenförmigen Bilderauf das jeweils richtige Auge gelenkt. Bei der anschließenden Bildfusion im Gehirn entstehtgleichzeitig der Tiefeneindruck.Ein intelligentes Eyetracking-System synchronisiert dabei kontinuierlich das Prisma mit derAugenposition des Betrachters und ermöglicht damit eine ergonomische, realistischeDarstellung von 3D-Anwendungen, die das Standard-D4D-Format unterstützen.

Abb. 3: Eingabegeräte für die Bild- und Informationserfassung. Datenverarbeitung in einemheterogenen Netzwerk unter Windows NT. Redundante Speicherung auf verschiedenen Medien.Analoge und digitale Bildausgabe über unterschiedliche Printmedien, Präsentation stechniken und imInternet

ErgebnisseModellierung in SoftimageIm Einzelnen wurden folgende Schritte im 3D Modell der Firma Viewpoint durchgeführt:• Verbesserungen an bestehenden

anatomische Innenstrukturen:z.B.a) Papillarsehnenfäden der

Segelklappen b) Verschieben des Ostiums des

Koronarsinus• Neumodellierung des

Moderatorbandes• Modellierung des Sinusknotens• Modellierung des AV-Knotens

und Darstellung der Transisto-rischen Zellen

• Modellierung des His-Bündels• Modellierung des Rechten und

Linken Tawara-Schenkels• Einfügen des modellierten

Erregungsbildungs- und Erregungs-leitungssystems in das 3D-Herz-modell

• Anpassen des eingefügten Erre-gungsbildungs- und Erregungs-leitungssystems an die innereOberflächenstruktur des 3D-Herzmodells

• Einfügen der Purkinje-Fasern• Neumodellierung des membranösen

Septums mit Durchtritt des His-Bündels• Detaildarstellung des Koch- dreiecks• Darstellung verschiedener´ Schnittebenen• Erstellung von Fenster-

ansichten• Definieren von Beleuchtung

und Materialeigenschaften

Abb. 5: Längsschnitt des Herzens mit Erregungsleitungssystem

Abb.4: Screenshot des animierten isolierten Reizleitungssystems.Ansicht von vorn rechts oben lateral. Links: Sinusknoten, der durchdie Perspektive größer erscheint. Mitte: AV-Knoten mittransistorischen Zellen (grau), daran anschließend das His-Bündel.Rechts: Aufspaltung in den vorderen und hinteren Faszikel des linkenTawara-Schenkels mit Aufzweigungen bis zu den Purkinje-Fasern;dazwischenliegend der rechte Tawaraschenkel mit reduzierterDarstellung der Aufzweigungen und der Purkinje-Fasern.

Rechter Tawara-Schenkel mit reduzierter Verzweigung dargestellt

Sinusknoten

AV-Knoten

TransistorischeZellen

Linker Tawaraschenkelhinterer Faszikel

Rechter Tawaraschenkel

Linker Tawaraschenkelvorderer Faszikel

Moderatorband

Animation des Modells in SoftimageDas verbesserte und ergänzte Viewpoint Modell wurde im nächsten Schritt animiert. ZurDarstellung spezifischer Strukturen und Lerninhalte wurden Animationen in verschiedenenPerspektiven erstellt:• 360° Drehung um die Längsachse des geschlossenen Herzen• 360° Drehung mit teilweise eröffneten Kammern und Blick auf das Reizleitungssystem• 360° Drehung des isolierten Reizleitungssystems• Drehung um das Koch-Dreieck• Fahrt durch das Herz, dem natürlichen Blutstrom folgend• Pumpbewegung des Herzen• Farbliche Darstellung des Erregungsverlaufs über das geschlossene statische Herzmodell• Farbliche Darstellung des Erregungsverlaufs über das geschlossene Herzmodell mit

Pumpbewegung• Vertikalschnitt des virtuellen Herzmodells mit farblicher Darstellung des Erregungs-

verlaufs von der Innen- zur Außenseite der Ventrikelmuskulatur sowie der Erregungs-rückbildung

Multimediale AufbereitungIn der interaktiven Präsentation werden dem Benutzer die erstellten Bilder, Filme undAnimationen leicht Verständlich dargeboten. In einer didaktisch sinnvollen Reihenfolgewerden die Anatomie, Physiologie und Elektrophysiologie des Herzen, insbesondere desReizleitungs- und Reizbildungssystems, dargestellt. Dabei können durch Querverweise(Hyperlinks) und eine einfache Navigation Gedankensprünge des Lernenden nachvollzogenund der Wunsch nach Zusatzinformation angeregt und befriedigt werden.Die unterschiedliche Visualisierung bestimmter Sachverhalte mittels Modell, Foto undAnimation bzw. Film erleichtert das Verständnis der räumlichen Zusammenhänge.

Abb. 6b: Detaildarstellung des AV-Knotens mittransistorischen Zellen und anschließendem His-Bündel, das in das Septum membranosum eintritt.Rechts: Trikuspidalklappe.

Abb. 6a: Eröffnung des rechten Vorhofes mit Blick aufden AV-Knoten, das Koch-Dreieck, die Tricuspidalklappeund das Foramen ovale.

Todaro-Sehne

Foramen ovale

Ostium sinuscoronarii

Trikus-pidal-klappe

MembranösesSeptum

His-Bündel

AV-Knoten

Transis-torische

Zellen

Abb. 7: Herzlängsschnitt mit interaktiven Schaltflächen, die mit erläuterndenTexten hinterlegt sind.Hier sind gleichzeitig mehrere der einzeln aufrufbaren Textinformationen dargestellt.

Abb. 8: Plastiniertes menschliches Herz mit Markierung des AV-Knotens (rotes Fähnchen) undHervorhebung des Membranösen Septums durch Hinterleuchtung.

AV-Knoten

MembranösesSeptum

Seite 9 von 13

An plastinierten menschlichen Herzen werden spezifische anatomische Strukturen in ihrerunverfälschten Gestalt, in natürlicher Position und ihrer Beziehung zu wichtigen Nachbar-strukturen durch Detailaufnahmen mit gezielter Beleuchtung dargestellt, wie z.B. dieHervorhebung des membranösen Septums durch Hinterleuchtung (Abb.8).

Eine Beschränkung auf die plastische, kontrastreiche Darstellung der interessierendenEinzelstruktur wird auch durch Modellierung des Erregungsleitungssystems mit Knetmassein einem eigens erstellten Glasherzen und in Plastik-Herzmodellen erzielt. Die Bilddokumentedienen als weitereVisualisierungsmodule.

Die komplexen physiologischen Abhängigkeiten von Herzerregung und Muskelkontraktionwerden z.B. durch mikroskopische Videoaufnahmen auf das zelluläre Niveau reduziert.Isolierte Herzmuskelzellen in Kultur zeigen, daß sie sich autonom kontrahieren können.Durch elektrische Stimulation ist eine frequenzabhängige, sychrone rhythmische Kontraktioninduzierbar. Hierdurch wird die Notwendigkeit eines frequenzbestimmendenErregungsbildungs- und Erregungsleitungssystems für die zeitlich konsekutive Erregung derVorhof- und Kammermuskulatur begreiflich, eine unabdingbare Voraussetzung für diegerichtete Pumpfunktion des Herzens.

Die elektrophysiologischen Vorgänge in den einzelnen Abschnitten des Erregungsleitungs-systems und der Herzmuskulatur werden anhand der charakteristischen, zeitlich versetztenAktionspotentiale dargestellt (Abb.9, rechts).Hierbei zeigt die spezifische Einfärbung der charakteristischen Aktionpotentiale gleichzeitigdie Lokalisation und räumliche Ausdehnung der Erregung im Herzen an (Abb.9, links).Die Animation macht den zeitlichen Ablauf und die Abfolge dieser Aktionspotentiale undihre Bedeutung für das Zustandekommen des Oberflächen-EKGs deutlich (Abb.9, rechtsunten).

Abb. 9: Links: Farbliche Differenzierung der Orte des Erregungsverlaufes. Reduzierte Darstellung des rechtenTawaraschenkels. Rechts: Zeitlich versetzte, nacheinander ablaufende Aktionspotentiale. Farbliche Kodierungder zugehörigen Bereiche im Herzen. Blau: Sinusknoten; grün: Vorhof; gelb: AV-Knoten; orange: His-Bündel;rot: Tawaraschenkel; violett: Purkinje-Fasern; grau: Kammermyokard

AusgabemedienDie Darstellung dreidimensionaler Modelle mittels zweidimensionaler Ausgabemedien(Abb.9) reduziert die Aussagefähigkeit aufgrund der mangelnden räumlichen Tiefeentscheidend.Verbesserungen der räumlichen Vorstellungskraft kommen bei der zweidimensionalenBildausgabe über Monitore bereits durch geeignete Beleuchtung mit Reflexionen undSchattenwurf zustande und können so auch über Printer ausgegeben werden.Weitere Verbesserungen des räumlichen Eindruckes werden durch zusätzliche Drehung derModelle erreicht. Dabei handelt es sich in dem vorgestellten Projekt um selbstständigablaufende Animationen wie auch um interaktive Animationen, die in bestimmten Phasen undWinkelschritten der Drehung zum besseren Studium gestoppt werden können.Einen unvergleichlichen dreidimensionalen Eindruck erlangt der Betrachter aber erst durchPräsentation der speziell aufbereiteten Filme von dreidimensionalen Modellen auf einem 3D-Monitor. Die mit Softimage entwickelten 3D-Modelle, die Ansichten aus bis zu 720Winkelschritten enthalten, werden hierfür so berechnet, daß für das linke und rechte Auge aufdem Ecomo-4D-Bildschirm gleichzeitig zwei Bilder mit einem Betrachtungsabstand von 5Winkelgraden dargestellt werden. Bei einem vorgegebenen Abstand des Betrachters von 60bis 80 cm in Mittelposition vor dem Monitor scheinen die plastischen Modelle dann vor derBildschirmebene zu stehen. Horizontale Kopfbewegungen werden durch ein intelligentesEye-Tracking (Erfassung der Pupillenposition) und Nachführen des Prismenrastersausgeglichen, während vertikale Kopfbewegungen für den 3D-Eindruck nicht von Bedeutungsind.

Diskussion

Zum besseren Verständnis der komplexen dreidimensionalen anatomischen Strukturen ammenschlichen Herzen und der von ihnen abhängenden elektrophysiologischen Vorgängewurden unterschiedliche Visualisierungsmodule entwickelt und in eine multimedialeUmgebung eingebunden.

Als Basisprogramm für die 3D-Visualisierung diente ein Polygonmodell der Fa. Viewpointmit 68.000 Polygonen, das die wichtigsten äußeren und inneren anatomischen Strukturenbeinhaltet. Da die zu entwickelnden Visualisierungsmodule die anatomischen undphysiologischen Zusammenhänge bei der Herzerregung und der Muskelkontraktion möglichstexakt wiedergeben sollen, war zunächst die Korrektur mancher anatomischer Strukturen imViewpoint-Modell notwendig. Andere Strukturen mußten sogar völlig neu implementiertwerden, um eine solide Ausgangsbasis für unterschiedliche spätere Anwendungen zu haben.

Das Modelling wurde mit Softimage durchgeführt, ein mächtiges Programmpaket, das eineintensive, langfristige Einarbeitung notwendig machte und nur durch kontinuierlichekonsequente Anwendung für den Benutzer einsetzbar bleibt. Mit Softimage gelang es, alleAnforderungen an Modelling und Animation in dem dreidimensionalen Polygonmodell desHerzens zu realisieren.

Die statischen Modelle des Herzens und die Herzschnitte des beschriebenen Entwicklungs-projektes sind ausgezeichnet durch anatomische Exaktkeit, detailierte Darstellung und durchfarbliche Kennzeichnung zusammenhängender Strukturen. Die Oberflächen erscheinenaufgrund der hohen Polygonanzahl sehr gleichmäßig und glatt. Farbwahl, Oberflächentexturund geeignete Beleuchtung bewirken einen guten plastischen Eindruck. Durch Schwenkenund Drehen wird der dreidimensionale Eindruck noch entscheidend verbessert.

Das Erregungsbildungs- und Erregungsleitungssystem, Hauptgegenstand des Forschungs-projektes, wird durch seine gelbe Färbung kontrastreich hervorgehoben und ist daher ausunterschiedlichen Betrachtungsperspektiven stets gut in Hinblick auf seine Ausdehnung undBeziehung zu Nachbarstrukturen erkennbar. Selbst bei transparenter Darstellung des Herzensist das Erregungsleitungssystem durch überlagerte Strukturen hindurch gut abgrenzbar undbis in die feinsten Verzweigungen nachzuverfolgen.Das Erregungsleitungssystem mit seinen Hauptstrukturen wurde zunächst frei modelliert unddann in das virtuelle 3D-Herzmodell implementiert und den anatomischen Strukturenangepaßt. Der exakte oberberflächenparallele Verlauf der Purkinje-Fasern zurunregelmäßigen Innenseite der Ventrikelmuskulatur konnte dadurch erreicht werden, daß dieaufwendige Modellierung der Purkinje-Fasern direkt im Herzmodell erfolgte.

In Nachbarschaft zum AV-Knoten ist mit dem Modelling des Koch-Dreiecks eine weiterebedeutende Struktur für die elektrophysiologischen Abläufe im Herzen implementiert. ImBereich des Koch-Dreiecks können pathologische Veränderungen auftreten, die zu schwerenHerzrhythmusstörungen führen. Die exakte Darstellung ist daher für das Verständnis beiMedizinern von großer Bedeutung, die hier z.B. Elektroablationen durchführen. Inbesonderefür Ingenieure ist detaillierte dreidimensionale Visualisierung wichtig, die für diesenEinsatzbereich Hochfrequenzgeräte, Defibrillatoren, Schrittmacher und entwickeln.

Das mit großer Sorgfalt implementiert His-Bündel sowie das membranöse Septum sindweitere wichtige anatomische Strukturen. Einerseits dienen sie dem Verständnis derAbleitung des His-Bündel-EKG, andererseits können sie dem Herzchirurgen verdeutlichen,wie das His-Bündels aufgrund seiner Nähe bei Herzklappenoperationen in Mitleidenschaftgezogen werden kann. Detailaufnahmen des virtuellen Herzmodells und Nahaufnahmen desplastinierten menschlichen Herzens mit Spezialeffekten werden zur didaktischenUnterstützung eingebaut.

Virtuelle Herzschnitten ermöglichen dem Anwender Ansichten des Erregungsleitungs-systems aus unterschiedlichen, optimierten Blickrichtungen, zum Teil mit gezoomtenDetailansichten. Virtuelle Herzschnitte waren in dem Viewpoint-Herzmodell nicht problemlosherstellbar, daes sich hierbei um ein Oberflächenmodell und kein Volumenmodell handelt.Bei virtuellen Herzschnitten kam es daher zur Öffnung von Falschräumen zwischen denOberflächen, z.B. der Außen- und Innenseite einer Herzkammerwandung, was die aufwendigeErgänzung neuer Ebenen zum Verschluß notwendig machte.

Die Interaktivität ist durch sensitive Schaltflächen verwirklicht, die mit erläuternden Textenhinterlegt sind und auf Wunsch nacheinander angeklickt werden können, so daß es nicht zueiner Textüberfüllung und damit zur Störung der Visualisierung kommt. ZusätzlicheInformationen stehen dem Programmanwender über Querverweise zur Verfügung.

Zusätzliches aufgearbeitetes Bildmaterial, das analog und digital über verschiedeneEingabemedien gewonnen wurde, wird zur didaktischen Unterstützung des gleichen Themasgezielt eingebaut. Neben der Modellierung des Koch-Dreiecks finden sich so z.B. Filme überanatomische Demonstrationen am menschlichen Herzen, oder Einzelbilder und Filme vomplastinierten menschlichen Herzen mit spezieller Beleuchtung.

Animationen des 3D-Herzmodells sind besonders geeignet, um die räumliche Ausdehnungvon anatomischen Strukturen oder physiologischen Abläufen zu visualisieren. Inselbstablaufenden oder interaktiven Animationen wird dem Betrachter am drehenden

Herzmodell der Blick aus allen Richtungen ermöglicht. Modellierte Fenster im Herzmuskelgestatten von außen einen ausgezeichneten Einblick auf die inneren Strukturen. Besondershervorgehoben erscheint dabei das Erregungsleitungssystem, das durch seine intensiveGelbfärbung sehr gut in seinem Verlauf bis zu den feinsten Purkinjefasern hin verfolgtwerden und bei transparenter Darstellung des Herzens sogar durch überlagerte Strukturenhindurch gesehen werden kann. Manche Animationen können in verschiedenen Positionen derDrehung zum besseren Studium gestoppt werden.

Die interaktive Animation der Elektrophysiologischen Abläufe bei der Herzerregung istgekennzeichnet durch Farbkodierung der Erregungsorte im Herzen. Die gleicheFarbkodierung wird didaktisch geschickt für die dynamisch ablaufenden, zeitlich versetztenAktionspotentiale verwendet. An einer typischen EKG-Kurve zeigt die Farbkodierungweiterhin, wie die einzelnen Aktionspotentiale am Zustandekommen des Oberflächen-EKGsbeteiligt sind. Dieses elektrophysiologische Basiswissen wird dann übertragen auf dieVisualisierung der Erregungsverlaufes an der Oberfläche eines statischen Herzmodells, aufein längsgeschnittenes und schließlich auf ein schlagendes, geschlossenes Herzmodell mitHerztönen.

Meist stehen für die Darstellung dreidimensionale Computermodelle nur zweidimensionalenMedien zur Verfügung. Deshalb wurde beim vorliegenden 3D-Herzmodell der gute räumlicheEindruck in erster Linie durch geschickte Beleuchtung und zusätzliche Drehung verwirklicht.Der beste dreidimensionale Eindruck wurde jedoch auf einem speziellen 3D-Bildschirm(Ecomo 4D) mit spezifisch aufbereiteten Filmen erzielt, auch ohne die unergonomischenShutter-Brillen oder Rot-Grün-Brillen anderer Verfahren. Leider ist der räumliche Eindruckauf einem 3D-Bildschirm im vollem Umfang aber nur von einem entsprechend positioniertenBetrachter zu erfassen. Bei Betrachtung durch mehrere Personen kann es aufgrund ihrerKörperbewegung zu Störungen der Eye-tracking-Funktion kommen, was ruckartigeBildstörungen bei der Modell-Rotation zur Folge hat. Die Eye-Tracking-Funktion muß dannabgeschaltet werden. Dieses beeindruckende Ausgabemedium, das sich derzeit vor derMarkteinführung befindet, ist leider noch verhältnismäßig kostspielig. Andere 3D-Präsentationstechniken für einen größeren Zuschauerkreis mußten in diesem Projekt wegender noch vielfach höheren Kosten, wegen des hohen technischen Aufwandes und des großenPlatzbedarfs ausscheiden.

Die Ergebnisse im Forschungsprojekt Multimediale 3D-Visualisierung der Herzmuskel-erregung können eine wichtige Ausgangsbasis für das Verständnis von Erkrankungen, wiez.B. Herzinfarkt und Herzrhythmusstörungen, und deren Auswirkung auf die Erregungs-leitung und das EKG sein. Sie können ebenso zur Verdeutlichung der Wirkung vonMedikamenten, wie z.B. Antiarrhythmika, herangezogen werden. Die anatomische undphysiologische Exaktheit der Visualisierungsmodule ist auch von zentraler Bedeutungfür das Verständnis der Wechselwirkung zwischen medizintechnischen Geräten undvernetzten biologischen Regelmechanismen. Gegenstand weiterführenden Projekten solldaher die Anwendung und Arbeitsweise medizintechnischer Geräte am Herzen sein, wie z.B.der Wirkung eines Schrittmachers auf die Herzmuskelerregung.

Literaturverzeichnis

Anderson, R.H., Becker, A.E.:Anatomie des Herzens. Stuttgart, Georg Thieme 1982

Anderson, R.H., Siew, Y.H., Becker, A.E., Lang, M.:Living Anatomy: The CARTO and NOGA Systems in the Clinical Arena.Waterloo, Biosense Europe

Publikationen von Becker (Zeitschriften-Artikel)

Eberl, M., Jacobsen, J.:Macromedia Director 7 Insider. München, Markt und Technik Verlag 2000

Kasumoto, F.M.:Cardiovascular Pathophysiology. Madison, Fence Creek Publishing 1999

Netter, F.H.:Farbatlanten der Medizin. Band 1: Herz. Stuttgart, Georg Thieme 1990

Flyer vom Forschungszentrum Jülich: Autostereoskopisches Display

Tawara, S.:Das Reizleitungssystem des Säugetierherzens. Jena, Fischer 1906

Wolter. S.:Flash 5. Bonn, Gallileo Press 2000

Projektverantwortlicher:

Prof. Dr. rer.nat. Hans-Joachim WeberFachhochschule Aachen, Abt. JülichBiomedizinische TechnikLabor für KardiotechnikGinsterweg 152428 Jülich

Das Projekt wurde unterstützt vom Ministerium für Schule, Weiterbildung, Wissenschaft undForschung des Landes Nordrhein-Westfalen.

Alle Warenzeichen, Marken- und Produktnamen sind das Eigentum ihrer jeweiligen Inhaber.

Prof. Dr. Horst Stenzel

Verteiltes Visualisieren

Abschlussbericht – Oktober 2000

Forschungsverbund „Multimedia“ der Fachhochschulen desLandes Nordrhein-Westfalen

Die Projekte in diesem Forschungsverbund wurden mit Mitteln des Ministeriums für Schule, Wis-senschaft und Forschung des Landes Nordrhein-Westfalen gefördert.

Verbundprojekt: Java-Framework für verteilte multimedialeAnwendungssystemeZielsetzung des Projekts ist die Realisierung verteilter multimedialer Informationssysteme mit Hilfeder für multimediale Anwendungen besonders geeigneten Objekt-orientierten ProgrammierspracheJava – mit dem Ziel der Erstellung eines allgemein verwendbaren, Plattform-unabhängigen Frame-works.

Teilprojekt: Verteiltes Rendern und Visualisieren mit CORBAund Java – Anwendung für statische (energiegerechtes Bauen)und zeitabhängige Medien (Video-Service)Prof. Dr. Horst Stenzel,Prof. Dr. Erich Ehses,Dipl.-Inf. Wolfgang Moser,Stud.Inf. Dirk Bangel, ITA

Fachbereich Informatik, Fachhochschule Köln

Zielsetzung des Teilprojekts ist die Herstellung eines Frameworks mittels CORBA und Java zurRealisierung verteilter Anwendungen, speziell zur verteilten Implementierung von Visualisierungs-werkzeugen.

Das Teilprojekt wurde außerdem aus dem Forschungsetat der Fachhochschule Köln unterstützt

Verteilte Informationssysteme für multimediale Anwendungen

Multimediale Systeme sind ein geradezu typischer Anwendungsbereich für Informationssysteme,die über mehrere Rechner-Plattformen verteilt sind. Zum Beispiel nutzt der WWW-Browser die Fä-higkeiten des Benutzerrechners zur Darstellung der Seiten in angemessener Zeit, aber die Informa-tionen werden regelmäßig über das Netz von entfernten Rechnern geholt. Der aktuelle Trend beiAnwendungen mit Nutzern, die über ein Intranet oder auch weltweit verstreut sind, ist, die Daten-haltung an einigen wenigen Stellen im Netz zu zentralisieren, genauso wie andere, kritische oderbesonders aufwendige Ressourcen. Zentralisierung hat erheblich geringeren Aufwand zur Folge wasHerstellung der Integrität, Wartung und Aktualisierung betrifft. Auf der anderen Seite ermöglichtund verlangt die globale Vernetzung verteilte Mehrbenutzer-Szenarien, bei denen die Rechner-Ressourcen und die zur Visualisierung und Interaktion erforderlichen Kapazitäten so nahe wiemöglich an den Anwender gebracht werden müssen, weil die dafür erforderlichen Bandbreiten heut-zutage noch nicht ökonomisch über Netze bezogen werden können. In diesem Spannungsfeld ist fürjede Anwendung ein Kompromiß zwischen Geschwindigkeitsanforderungen auf der einen und Inte-gritäts- und Aufwandsüberlegungen sowie Implementierungsaufwand, auf der anderen Seite erfor-derlich. Hier soll das in diesem Projekt entwickelte Framework eine Unterstützung liefern, indem

H.Stenzel e.a. – Abschlußbericht Java-Framework – Verteiltes Rendern und Visualisieren

dem Systemdesigner und -implementierer fertige Bausteine für die Verteilung multimedialer An-wendungen in transparenter Form an die Hand gegeben werden. Der Architekt einer Anwendunggliedert sein System nach logischen, funktionalen Gesichtspunkten, wobei er sich an der Strukturdes Frameworks orientiert. Teile, die ihn nicht interessieren, kann er ohne Performance-Verlustignorieren, und spezifische Funktionalität kann er innerhalb des Frameworks durch Vererbung undErweiterung einbauen.

Frameworks

Ein Framework deckt typischerweise einen spezifischen Software-Anwendungsbereich ab. EinFramework ist mehr als eine in einer Bibliothek zusammengefaßte Klassenhierarchie, sondern esbeinhaltet als ein generalisierter Anwendungsprototyp sowohl die Datenstrukturen als auch die dy-namischen Aspekte – Schnittstellen zu Benutzern und anderen Applikationen und Ausführungslogik– ab. Erfolgreiche Frameworks wachsen und entwickeln sich über einen längeren Zeitraum und ge-hen auseinander hervor. Mit anderen Worten ist ein Framework eine wiederverwendbare Anwen-dung, die zwar vollständig im Hinblick auf die erforderliche Funktionalität für ein spezielles An-wendungsfeld ist, aber nicht vollständig ausformuliert ist im Hinblick auf eine spezielle Anwendungin diesem Feld [Fayad 2000]. Aus Objekt-orientierten Frameworks können durch Vererbung, Wie-derverwendung und Spezialisierung viele weitere Anwendungen abgeleitet werden. In der Welt derzunehmend komplexer werdenden Softwaresysteme – Menge der Daten, Anzahl der Verfahren,Dienste und Datenformate, Größe der Netze und Zahl der Benutzer wachsen beständig – ist dies ei-ne der wenigen erfolgversprechenden und zukunftsweisenden Technologien. Beispiele für erfolgrei-che Frameworks findet man durchaus auch im Bereich der public domain Software.

Dieses Projekt stellt sich als ein Framework zur Integration von Middleware (s.u.) dar. Andere Fra-meworks zielen auf die Infrastruktur von Systemen, z.B. Kommunikation, Benutzer-Schnittstellen,oder auf gesamte Unternehmensbereiche, wie Produktion, Finanzwirtschaft, o.a.

Frameworks und Klassenbibliotheken ergänzen einander. Umfangreiche Frameworks werden unterZuhilfenahme von Objekt-orientierten Prinzipien gestaltet. Das beinhaltet die Benutzung von Klas-senhierarchien. Aber Frameworks gehen darüber hinaus, als sie typischerweise eine vollständigeApplikation umfassen, in der an verschiedenen vordefinierten Stellen die für die jeweilige spezifi-sche Anwendung erforderlichen Erweiterungen und Spezialisierungen vorgenommen werden. Wäh-rend Klassenbibliotheken typischerweise Objekte bereit stellen, die instanziiert werden und derenMethoden aufgerufen werden, wird in Frameworks die Kontrolle umgekehrt, der Benutzercode wirdim Rahmen des prototyischen Ablaufs aktiviert (Hollywood-Prinzip, “don’t call us, we call you”).

Java

„Java macht frei“ – kompatible Java-Implementierungen sind für praktisch alle DV-Umgebungenerhältlich, so daß Anwendungen ohne Neukompilierung auf jedem Clienten-System lauffähig sind.Standardisierte Schnittstellen für die Rechner-Kommunikation im Netz, die Benutzungsoberflächenund Datenbanken gestatten leichte Integration in komplexe Umgebungen. Darüber hinaus ist es mitJava möglich, verteilte Systeme ohne eine Installation auf Seite des Clientensystems zu schaffen –mit der Ausnahme des Java-Basis-Systems, das z.B. in vielen WWW-Browsern schon integriert istund von Sicherheits-relavanten Informationen können alle Komponenten der Anwendung währenddes Betriebs vom Server bezogen werden. Dies verursacht einen gewissen Kommunikationsauf-wand bei jeder Benutzung des Systems, der aber durch geschickte Implementierung vertretbar ge-ring gehalten werden kann. Andererseits ist Aufwand zur Installation und Aktualisierung solcherSysteme aber praktisch gleich Null. Dieser Vorzug macht Java zur bevorzugten Programmier- undInstallationsumgebung von verteilten Anwendungen im Internet.


JMF

Das in diesem Projekt entwickelte Framework baut für die Behandlung spezielle Medientypen aufeinem anderen auf, dem Java Media Framework (JMF) [JMF 1999] Alle geläufigen Audio- und Vi-deomedientypen werden durch ein API unterstützt, das Funktionen für das Betrachten, Konvertie-ren, Manipulieren und Speichern von Mediendaten bietet. Gegenüber den APIs für Medienströme(streaming media) wie QuickTime oder Real, die für den Anwendungsprogrammier wie eine blackbox funktionieren, sind hier alle Methoden im Quelltext offengelegt und können im Sinne eineswhite box-Frameworks an die Anwendungsspezifischen Bedürfnisse angepaßt werden.

CORBA & MSS

CORBA ist ein offener Industrie-Standard, der inzwischen von einigen Produkten unterstützt wirdund der Eingang in zahlreiche Applikationen gefunden hat [CORBA 1998]. Die Erweiterungen vonCORBA, die im Visibroker 4.0 realisiert wurden, haben diesem Projekt sehr genützt. CORBA isteine Sammlung von Werkzeugen, Schnittstellen-Definitionen und Programmen für die Anwen-dungsentwicklung, die als typische middleware zwischen Betriebssystemfunktionen und Anwen-dungs-spezifischen Routinen auf einem relativ hohen Niveau vielfach benötigte Dienste anbietet. Essteht hierin z.B. in direkter Konkurrenz zu COM/DCOM der Firma Microsoft.

Es besteht und bestand dringender Bedarf, verteilte Datenhaltung, Ergebnisermittlung und Visuali-sierung für eine Vielzahl von Projekten zu realisieren. Das in diesem Verbundprojekt intendierteFramework bietet ideale Voraussetzungen für solche Realisierungen.CORBA bietet die Möglichkeit, die Vermittlungs- und Transportdienste Plattform- und Hersteller-unabhängig zu realisieren.Die ISO-Norm PREMO [PREMO 1998] greift ein Defizit von CORBA für die Anwendung fürverteilte Multimedia-Systeme auf. CORBA ist von Hause nicht geeignet für den Transport großerDatenbestände, da jede Transaktion als eine Einheit abgewickelt wird. Der Transfer von Daten un-abhängig von Objektinstanzen und deren Aktivierung in entfernten Rechnern wird deshalb oft au-ßerhalb der CORBA-Mechanismen realisiert. CORBA wird benutzt, um Dienste auszuwählen, zulokalisieren und zu aktivieren, während der eigentliche Datentransport z.B. mit Hilfe von sharedmemory oder sockets abgewickelt wird.Dieses Projekt erweitert die CORBA-Funktionen um die Möglichkeit, Daten in Form von Strömenzu übertragen. Dabei wird der Strom wie ein Datenkanal als Objekt definiert und jeweils ein Emp-fänger- und ein Sender-Objekt miteinander verknüpft. Der eigentliche Datentransport erfolgt nachder Verknüpfung durch push- oder pull-Aufrufe in Sender bzw. Empfänger. Die Transportkontrolleist von da an transparent für die anwendenden Routinen. Diese Funktionalität entspricht dem IMA-Entwurf MSS (Multimedia System Services [IMA 1998]), der leider nie verabschiedet wurde, ob-wohl auf Seiten der Softwareentwickler nach wie vor großer Bedarf dafür besteht.

Ziel der ISO-Norm PREMO ist die Bereitstellung Hersteller-unabhängiger Frameworks für verteilteMultimedia-Anwendungen. In diesem Projekt werden große Teile von PREMO auf der Basis vonCORBA in Java umgesetzt. Durch die Verwendung von CORBA und Java ist die Forderung nachPlattform-Unabhängigkeit definitionsgemäß gewährleistet. Die Verwendung von Java bindet aufGrund der Programmiersprachenunabhängigen, in IDL formulierten Schnittstellen nicht an eineUmgebung oder Sprache; insbesondere die Interoperabilität mit C++ ist im Rahmen dieses Projektserprobt worden.

Anwendungen des Frameworks

Ein erstes Anwendungsziel bestand in der Verteilung einer ursprünglich nicht verteilten Anwendungzur Planung energiegerechter Bauwerke. Datenbanken für Produktdaten und Verordnungen, Be-


rechnungen für physikalisch exakte Beleuchtungssimulation und qualitativ hochwertige Ausgabekönnen mit Hilfe des Frameworks transparent für den Anwender auf verschiedene Rechner verteiltwerden. Dieses Vorhaben ist mit dem Namen RadianceWrapper realisiert worden und stellt die Ba-sis für den folgenden Anwendungsbereich dar.Als zweites Anwendungsgebiet ist die Verteilung von Audio- und Video-Daten im Netz ausgewähltworden. Während Video-Daten an praktisch jeder Stelle im Netz betrachtet oder abgespeichert wer-den können sollen, sind die Quellen für diese Informationen (live oder Speicher-Server) und dieProzessoren für die Verarbeitung auf wenige spezialisierte Knoten beschränkt. Ein Benutzer einessolchen verteilten Audio- und Video-Service soll auf diese Ressourcen in transparenter Weise, ohneKenntnis der Netztopologie und der Internet-Adressen zugreifen können, indem er die ihn interes-sierenden Informationen anhand ihres Inhalts auswählt. Komplexere Anwendungsszenarien mitmehreren synchronisierten Quellen, Verarbeitungsschritten und Senken sind von vorn herein mit inBetracht zu ziehen, wie sie sich zum Beispiel aus Videokonferenz-Anwendungen oder verteiltenLehrveranstaltungen ergeben. Daraus resultieren einige Anforderungen an die einzusetzende Soft-ware, zumal nach Möglichkeit auf vorhandene Elemente zurückgegriffen werden sollte, um denAufwand für Reralisierung, Weiterentwicklung und Pflege so gering wie möglich zu halten.

Anforderungen an Middleware und Framework

Im folgenden sind die Anforderungen an die zu verwendenden Softwarekomponenten zusammenge-faßt:

Factory

Factory Factory

SceneCreatorUnit

CanvelerUnitRenderUnit

ImageViewerUnit

JVM 2 JVM 3

JVM1

Radiance Wrapper

startet/kontrolliert

überträgt


Rechner1

Überträgt Szene Erzeugt Bild


erzeugt erzeugt

erzeugt erzeugt

Bildbetrachter

start

start

start

rad

ra_gif,rad_jpg,....

Abbildung 1: RadianceWrapper - Kontroll- und Datenfluß


- Realisierung der Clientsoftware in Java, um von möglichst vielen Anwenderplattformen ohnezusätzlichen Implementierungsaufwand genutzt werden zu können. Mit der Aufnahme vonCORBA in den Netscape-Browser ist der Kommunikationsaufwand deutlich reduziert und dieGeschwindigkeit gesteigert worden.

- Informationsserver und Vermittlungsknoten sollen aus Performance-Gründen in der jeweils op-timalen Hard- und Software realisiert werden können (C++, Multiprozessor-Architekturen, pro-prietäre, hochperformante Produkte wie Datenbanken).

- Die Middleware ermöglicht einen transparenten Informationsaustausch über Programmierspra-chen-, Architektur- und Betriebssystemgrenzen in lokalen Netzen und im weltweiten Internethinweg.

- Eine Authentifizierung der Clienten durch die Server ist möglich. Jeder Client kann nur die ihmzugedachten Informationen vom Server erhalten.

- Erweiterungen der Fähigkeiten des Servers sind möglich, ohne daß die Client-spezifische Soft-ware angepaßt werden muß.

- Die Lokalisierung der Server erfolgt unabhängig von der Kenntnis konkreter IP-Adressen oderURLs dynamisch aufgrund des Server-Angebots relativ zum jeweiligen Client

Diese Anforderungen sind durch die gewählte Kombination CORBA, Java und JMF und den daraufaufbauenden eigenen Arbeiten, die sich an der ISO-Norm PREMO orientieren, erfüllt.

Die PREMO-Prototyp-Implementierung des CWI [Duke 1999] basiert auf Java RMI. Damit ist daswichtige Ziel der Programmiersprachen-Unabhängigkeit nicht gewährleistet. Darüber hinaus erfor-derten einige fehlende Eigenschaften des Object Life Cycle Managements umfangreiche Eigenar-beiten. In einer Vorstudie SoRCmark [Ritter 1999] wurden die Performace-Eigenschaften von RMIund CORBA systematisch verglichen, um den durch CORBA verursachten Overhead qualitativ undquantitativ greifbar zu machen, insbesondere im Hinblick auf die Übertragung großer Datenmengen,für die traditionellerweise „Socket-Tunnel” verwendet werden. Die Messungen lieferten keine über-raschenden Ergebnisse, und erfreulicherweise auch keine schockierend negativen Resultate. DerOverhead, der durch die plattformneutrale Darstellung der Datentypen zu erwarten ist, wächst imwesentlichen linear, die Verlangsamung der Übertragung bleibt im Rahmen. Es ist zu hoffen, daßzukünftige CORBA-Versionen über die von RPC-Systemen ererbten sturen Konvertierungen hinauseine flexible, optimierte Konvertierung bei der Übertragung zwischen zwei definierten Partnernunterstützen werden.

RadianceWrapper

Als ein erstes Framework wurde RadianceWrapper für einen verteilten photorealistischen Beleuch-tungssimulator implementiert. RadianceWrapper benutzt die RMI-Mechanismen des PREMO-Prototyps der CWI, der die Kommunikation von Java Clients und –Servern gestattet.Radiance [Radiance 1999] ist ein weithin akzeptiertes Produkt zur physikalisch weitgehend exaktenBerechnung von Beleuchtungsverhältnissen in dreidimensionalen Szenen. Zum Zeitpunkt der Studieexistierte Radiance nur als C-Code für Unix-Betriebssysteme, während die Clients in der Regel ver-schiedene Arten von MS-Windows benutzen. Zur Erzielung der Kompatibilität mit den Java-RMI-Transportmechanismen des PREMO-Servers wurde der Radiance-Code in ein Java-Objekt verpackt,ebenso die Konverter, die die errechneten Bilder in das für den Benutzer erforderliche Format wan-deln. Radiance und Filter liegen aus Performancegründen nicht in Java vor. Es ist durchaus denkbar,


aber hier nicht realisiert, zur Beschleunigung das Rendering auf mehrere Server zu verteilen. DieVerteilung wird für den Clienten transparent vorgenommen, das Radiance-Objekt lokalisiert seiner-seits die verfügbaren verteilten Renderer-Objekte und faßt deren Ergebnisse zusammen.Die Aktivierung des Rendering durch den Client erfordert die Lokalisation einer Instanz desRadiance-Objekts. Die Darstellungsparameter und die Szenenbeschreibung werden als Methodenpa-rameter an das Radiance-Objekt übertragen.SceneCreator und ImageViewer sind PREMO-Objekte, die im Clienten existieren. Die Daten flie-ßen von der SceneCreatorUnit zur RenderUnit, das Roh-Bild wird zur ConverterUnit übertragen,das endgültige Bild wird der ImageViewerUnit geschickt, die es auf dem Bildschirm sichtbar machtoder anderweitig ausgibt. Alle Units können sich auf verschiedenen entfernten Rechnern befinden,insbesondere für die Rechen- und Speicher-aufwendigen RenderUnit und ConverterUnit ist dies na-heliegend.

Factories

Im Gegensatz zu klassischen verteilten Anwendungen, bei denen die entfernten Ressourcen über IP-Adressen oder URLs angesprochen werden müssen, die feste Adresse im Internet bezeichnen, bietenCORBA und PREMO die Möglichkeit, Objekte anhand von gewünschten und erforderlichen Eigen-schaften zu beschreiben, durch Factory Finder zu lokalisieren und mit Hilfe von Factories referen-zierbare Instanzen und die erforderlichen Referenzen zu erzeugen. Dem Client kann so jede Kennt-nis von der IP-Lokalisierung seiner Server fehlen. Dies erzeugt eine sehr große zusätzliche Flexibi-lität bei der dynamischen Konfigurierbarkeit von verteilten Systemen, deren Potential heutzutagebei weitem noch nicht ausgeschöpft ist.

Streaming

Der Datentransport in verteilten OO-Systemen erfolgt über die Signatur der Objekt-Methoden beideren Aufruf – entsprechend der Parameterliste eines Funktionsaufrufs werden Eingabe- und Aus-gabeparameter übertragen. Das bedeutet für verteilte Systeme, daß die Parameter von einem System

Abbildung 2: Framework-Szenario Video-Streaming

ConnectByDeviceproviding content informations

getAllDevicesretrieving device

informations startinitiate streaming

pushSynchronizedWithOutKeystreaming video data

Devicepublisher

Contentprovider

Viewer

leer


zum anderen kopiert werden können. Für diesen Vorgang kann soviel Zeit benötigt werden, daß derGewinn durch die Verteilung der Aufgaben auf den dafür jeweils optimalen Rechnerknoten leichtverloren geht. Mit dem Konzept des Streaming vermeidet man diesen Nachteil, indem das Empän-ger-Objekt schon anfangen kann zu arbeiten, während die Übertragung der Eingabe noch nicht ab-geschlossen ist – ein Konzept, das beim Betrachten von Bildern und insbesondere bei der Präsenta-tion von Audio- und Video-Dateien über das Internet weite Verbreitung gefunden hat.CORBA- und RMI-Objekte blockieren typischerweise, wenn sie eine Methode eines anderen Objektaufrufen, bis die Ergebnisse vollständig vorliegen. Dies ist insbesondere dann sinnvoll, wenn Ga-rantien über die Ausführung der Methode verlangt werden.Wenn Ströme von Daten bewegt werden müssen, liegt es nahe, diese Daten in handliche Pakete zuzerlegen, die dann als Parameter von send- bzw. receive-Methoden versendet werden. Der Empfän-ger stellt daraus wieder die für die Verarbeitung erforderliche Struktur her. Dies ist aus verschiede-nen Gründen nicht sinnvoll: Jeder Methodenaufruf ist mit zusätzlichem Overhead versehen. DieSoRCmark-Studie zeigte die Steigerung der Effizienz der Datenübertragung mit der Zunahme derGröße der Objekte. Das Deassemblieren und Assemblieren der Daten zu bzw. von Paketen ist eineAktivität, die in der Anwendung nichts zu suchen hat.

CTL

PREMO definiert virtual connections für die Übertragung von Daten in Strömen, die die Rolle vonKanälen haben. Diese Funktionalität wurde in diesem Projekt im sogenannten CORBA TransportLayer (CTL) zusammen mit anderen, in PREMO Part 3 definierten Funktionen erfolgreich imple-mentiert:- Objekt-Lokalisierung- Puffer-Strategien- Synchroner und asynchroner Datentransport- Ereignisbehandlung- Ausnahmebehandlung

Zentral für die neu zu implementierenden Funktionen ist der Transportdienst für die Datenströme.Die Aufgaben, die in diesem Zusammenhang bestehen, werden aufgeteilt einerseits auf die Vertei-lung der Angebote durch Server und die Vermittlung zwischen Anforderungen durch Clienten durchsogenannte device publisher und andererseits auf die generalisierten datenverarbeitenden Objekte,devices genannt, die in drei verschiedenen Variationen auftreten: Es gibt device-Objekte für dasAnbieten, Verarbeiten und Verknüpfen und Empfangen von Informationen.

interface Devicepublisher : ERIP { oneway void hello (in RIP call); oneway void bye (in RIP call); string ConnectByRouter (in string IOR); oneway void DisconnectByRouter (in string IOR); string ConnectByDevice (in string IOR,in Devices information); oneway void DisconnectByDevice (in string key); boolean areYouAlive (); string getRealIOR (); DeviceAnswers getAllDevices ();

};

Abbildung 3 IDL-Definition des CTL-device publisher-Objekts


CTL device publisherDie Intention bei der Schaffung von device publishern ist, die Verbreitung der Information überMultimediadienste und Inhalte in neutraler Form zu ermöglichen. Die device publisher arbeiten wieein Netzwerk von Maklern, die nur die Kenntnis über Objekte untereinander vermitteln. Sie bedie-nen sich dabei eines spanning tree-Algorithmus, wie er von Netzwerk-Routern her bekannt ist. Eindevice registriert seine Dienste bei einem beliebigen device pulisher, der seinerseits automatisch fürdie Verbreitung der Information sorgt, und ein Nutzer fragt bei einem beliebigen device publishernach bestimmten Diensten oder Inhalten, die der publisher im Netz lokalisiert.Durch die Nutzung von CORBA für die Referenzierung von Objekten ist eine weltweite Eindeutig-keit der Benennung ermöglicht, und die Forderungen nach Unabhängigkeit sind erfüllt.

CTL deviceEin device ist ein generalisiertes Objekt, in das bzw aus dem MM-Ströme hinein oder heraus tretenkönnen. Es kann beliebig viele einzelne Dienste anbieten, wobei jeder Dienst seinerseits wahlweiseaus einem Eingabestrom und einem Ausgabestrom besteht. So sind die devices die Prototypen für:- Objekte, die Inhalt oder Dienste anbieten z.B. Quellen für Video und/oder Audio, Kameras,

Speicher, synthetische Bild- oder Tonquellen wie Renderer,- Objekte, die Ströme weiterverarbeiten, z.B. einen Strom auf mehrere aufteilen, zwei Ströme

synchronisiert kombinieren, Filtern, Komprimieren, sowie- Objekte, die Dienste nutzen im Sinne von Informationssenken, z.B. Viewer, Browser oder Ar-

chivierung und Speicherung

Abbildung 4 IDL-Definition des CTL-device-Objekts

interface DeviceDefine:ServiceBuild,Device {

string buildServiceUnsychron (in commands comman,in string sessionkey);string buildServiceSychron (in commands comman,in string sessionkey);oneway void start (in string sessionkey);boolean isStarted (in string sessionkey);oneway void stop (in string sessionkey);boolean isStoped (in string sessionkey);oneway void destroy (in string sessionkey);oneway void error (in string what,in string sessionkey);oneway void timeout (in string what,in string sessionkey);Devices getInformation ();boolean areYouAlive ();boolean pullSynchronizedWithOutKey (in string backToIOR,in string sessionkey);oneway void pullUnSynchronizedWithOutKey (in string backToIOR,in string sessionkey);boolean pullSynchronizedWithKey (in string backToIOR,in string sessionkey,in string

key);oneway void pullUnSynchronizedWithKey (in string backToIOR, in string sessionkey, in string

key);boolean pushSynchronizedWithOutKey (in byteArray data,in string sessionkey);oneway void pushUnSynchronizedWithOutKey (in byteArray data,in string sessionkey);boolean pushSynchronizedWithKey (in byteArray data,in string sessionkey,in string key);oneway void pushUnSynchronizedWithKey (in byteArray data,in string sessionkey, in string key);

};


SynchronisationCTL devices können zu beliebigen komplexen Netzwerken miteinander verknüpft werden. DasFramework zeigt die Anwendung eines noch recht übersichtlichen Netzwerkes mit zwei Kamerasund zwei Präsentations-Anwendungen., die die Informationen beider Kameras gleichzeitig darstel-len, im Sinne einer einfachen Video-Konferenz-Anwendung. Da die Informationen aus den beidenQuellen unterschiedlich lange im Netz unterwegs sein können, bis sie zum Empfänger gelangen,bieten sich zwei Möglichkeiten der Behandlung der Zeitunterschiede an:- Die Informationen werden unmittelbar dargestellt, so daß unter Umständen gleichzeitige Vor-

gänge asynchron sichtbar werden. Dies ist nur in recht beschränktem Maße tolerierbar.- Die Informationsströme werden miteinander abgeglichen und synchronisiert. Dazu ist eine ver-

läßliche zentrale Zeitgabe erforderlich, sowie ein Mechanismus, der einen Strom gegebenenfallsverzögert, wenn Informationen aus einem anderen Strom nicht rechtzeitig eintreffen. Diese Syn-chronisierung kann an einer zentralen Stelle im Netz oder bei jedem Empfänger geschehen. Bei-de Möglichkeiten werden durch den event-Mechanismus von PREMO unterstützt.

CTL PufferstrategienAktuelle Streaming-Protokolle verwenden Mechanismen zum Ausgleichen der schwankendenÜbertragungsraten in belasteten Netzen. Im Rahmen dieses Projekts ist mit verschiedenen solchenStrategien experimentiert worden, ohne daß eine Empfehlung für eine optimale Strategie abgegebenwerden kann. Insbesondere lag es nahe, das durch die Versendung der Ströme mittels CORBA auf-tretende Verwaltungsoverhead an die verfügbare Bandbreite anzupassen. Der hierfür erforderlichezusätzliche Aufwand hat aber den Nutzen zunichte gemacht.Der Versuch, die Übertragung durch den potentiell schnelleren oneway-Aufruf zu beschleunigen,schlug fehl, weil der verwendete Inprise Visibroker Version 4 damit keine konsistenten Ergebnisseliefert.

Abbildung 5: Framework-Szenario Verteiltes Lernen


Schlußbemerkung

Zusammenfassend ist festzustellen, daß die Konzepte, wie sie in PREMO definiert wurden, sinnvollund nützlich sind bei der Implementierung spezieller verteilter Multimedia-Systeme, auch beimVorliegen der Notwendigkeit des Transports großer Datenmengen oder -Ströme. Die Nachhaltigkeitdes erstellten Frameworks ist durch die Verwendung allgemein zugänglicher, von großen Organisa-tionen gepflegten Komponenten (CORBA, Java, JMF) gewährleistet. Das Framework geht in sei-nem Nutzen über die verwendeten Komponenten hinaus, da es die insbesondere für Streaming-Anwendungen erforderlichen Funktionen des device publishing, der beliebigen Verknüpfungen derObjekte zu verarbeitenden Netzwerken und der Synchronisation der Komponenten beinhaltet.

Referenzen

[PREMO 1998] ISO/IEC 14478-1, -2, -3, Information Technology – Computer Graphics and ImageProcessing – Presentation Environments for Multimedia Objects (PREMO), Part 1: Funda-mentals, Part 2: Foundation Component, Part 3 Multimedia System Services. InternationalOrganization for Standardization, 1998

[Fayad 2000] Mohamed E. Fayad, Introduction to the Computing Surveys’ Electronic Symposiumon Object-Oriented Application Frameworks, ACM Computing Surveys, Vol. 32, No 1,2000

[Duke 1999] David J. Duke, Ivan Herman, M. Scott Marshall, PREMO: A Framework for Multi-media Middleware, Springer, Berlin 1999

[CORBA 1998] Object Management Group, siehe http://www.omg.org[IMA 1998] Interactive Multimedia Association, siehe http://www.ima.org[JMF 1999] Java Media Framework, siehe http://www.java.sun.com[Radiance 1999] siehe http://floyd.lbl.gov/radiance/refer/ray.html[Ritter 1999] Eduard Ritter, Jörg Merlau, Design und Prototyp-Implementierung eines verteilten

Multimedia-Systems auf Basis von ISO/IEC 14478 PREMO, Diplomarbeit, Gummersbach1999

Prof. Dr. Horst Stenzel

Vortragsfolien

Verbundforschungsprojekt Java-Framework

für verteilte multimediale Informationssysteme mit Anwendungen

Forschungspartner

❚ Anwendungsbereich Wasserwirtschaftliche Planung und Bewirtschaftung:Prof. Dr. B. Blümel, Prof. Dr. H. Johannes, Märkische FH Iserlohn, FB Techn. Betriebswirtschaft

❚ Anwendungsbereich Medizinische Diagnostik:Prof. Dr. W. Hillen, FH Aachen, FB Physikalische/Biomedizinische Technik

❚ Anwendungsbereich Videoservice:Prof. Dr. E. Ehses, Prof. Dr. H. Stenzel, FH Köln, FB Informatik

Verteilte MM-Anwendung: Videoservice

Kooperationspartner

❚ Verdi Information Consult GmbH

Siegburger Str. 3553757 Sankt Augustin

Förderung

❚ Ministerium für Schule, Wissenschaft und Forschung NRW❚ Fachhochschule Köln

Meilensteine

SoRCmark Frühjahr 1999

Radiance WrapperEnde 1999

CTLSeptember 2000

Premo Part 2 & 32. Quartal 2001

(geplant)

Visualisierung vonWissens- und DatenräumenSommer 1997

Verteiltes OO-Infosystem Herbst 1998

SoRCmark

❚ SoRCmark, Projektarbeit Merlau, RitterPerformance Sockets, RMI, CORBA

Abbildung A2.4 : 3. Messung der Byte-Übertragung mit Sockets, RMI und CORBA.

0

500

1000

1500

2000

2500

0 500000 1000000 1500000 2000000

Bytes

Zeit/

ms

3. Sockets (byte)

3. RMI (byte)

3. CORBA (byte)

Polynomisch (3. RMI(byte))Polynomisch (3.CORBA (byte))Polynomisch (3.Sockets (byte))

Abbildung A2.6 : 3. Messung der Float-Übertragung mit RMI und CORBA.

0

500

1000

1500

2000

2500

3000

3500

0 500000 1000000 1500000 2000000

Bytes

Zeit/

ms

3. RMI (float)3. CORBA (float)Polynomisch (3. CORBA (float))Polynomisch (3. RMI (float))

Radiance Wrapper

❚ Studie Ritter, Merlau:❙ Einsetzbarkeitsstudie:

❘ ISO-Norm „PREMO“ im praktischen Einsatz als Framework für verteilte Multimediasysteme

❙ Ausgangspunkt: Designstudie des CWI Amsterdam❙ Test und Weiterentwicklung des RMI-basierten Frameworks

❚ Erstellung einer PREMO-basierten Beispielanwendung❙ Radiance Wrapper:

❘ Fernsteuerung eines Service für photorealistisches Rendern

❚ ISO/IEC 14478 (PREMO):Programming Environment for Multimedia Objects

Das Radiance-Modell

Factory

Factory Factory

SceneCreatorUnit

CanvelerUnitRenderUnit

ImageViewerUnit

JVM 2 JVM 3

JVM1

Radiance Wrapper


überträgt


Rechner1

Überträgt Szene Erzeugt Bild


erzeugt erzeugt

erzeugt erzeugt

Bildbetrachter

start

start

startrad

ra_gif,rad_jpg,....

Zeitabhängige Medien

❚ Video und Audiostreaming:❙ Zielsetzung:

❘ Weltweites Auffinden aller medienanbietenden Devices❘ Unabhängigkeit von IP-Adressen oder URLs❘ Per CORBA standardisierte Zugriffsweise

❚ Plattform- und Herstellerneutral❚ Hochsprachenunabhängige Schnittstellen❚ 100%-ige Datenkonsistenz❚ Ablösung von Socketverbindungen❚ Viewer in Java in jeden Browser integrierbar

❙ Frameworks:❙ Datenvisualisierung: Sun Java Media Framework❙ Datentransport und Objektverknüpfung: CORBA Transport Layer

Corba Transport Layer (CTL)

Studie:

Eignung von CORBA für die ISO-Norm „PREMO“ in Bezug auf:

❙ Event handling❙ Exception handling❙ Object locating❙ Pufferstrategien❙ Zeitindepenzen bei zeitkritischer Datenübertragung,

synchron und asynchron

Java Media Framework (JMF)

❚ API für das Zusammenführen von Audio, Video und anderen zeitbasierten Medien.

❚ Für Java-Anwendungen und Applets.

❚ Derzeitige Version: 2.1

❚ Beteiligte Firmen, u.a. : Entera, Apple, Sun, Silicon Graphics, Intel, IBM

❚ Eine breite und vielschichtige Wissensbasis.

❚ Maximum an Leistung und Performance.

❚ Unterstützung: Alle geläufigen Audio- und Videomedientypen.

CTL: Grundlegendes Konzept

Aufteilung der Transportfunktionen:

❚ Verteilung und Vermittlung: Device publisherZuständig für die Verbreitung der Informationen über

Devices

❚ Datensenken und -quellen: DevicesZuständig für:

❙ Anbieten von Diensten und Content❙ Weiterverarbeiten von Content❙ Nutzung von Diensten

❚ Einfaches Verbreiten von Multimediadiensten und -content❙ Devices bieten Publishern Dienste an. ❙ Publisher verständigen sich untereinander über die angebotenen Dienste.

❚ CORBA-bedingte Objekteigenschaften: ❙ Weltweites Lokalisieren von Publisherobjekten❙ Jederzeit 100%-ige Daten- und Informationskonsistenz❙ Unabhängigkeit

CTL Device publisher

IDL Definition

interface Devicepublisher : ERIP {oneway void hello (in RIP call);oneway void bye (in RIP call);string ConnectByRouter (in string IOR); oneway void DisconnectByRouter (in string IOR);string ConnectByDevice (in string IOR,in Devices information);oneway void DisconnectByDevice (in string key);boolean areYouAlive ();string getRealIOR ();DeviceAnswers getAllDevices ();

};

CTL Device publisher

CTL Devices

Ein Device bietet beliebig viele Dienste anJeder Dienst besteht wahlweise aus:

❙ Eingabedatentyp❙ Ausgabedatentyp

Aufgaben:

❙ Video-/Audioquellen ❙ Video-/Audiopräsentation❙ Verarbeitung z.B. Komprimierung, Rendering❙ Speicherung

CTL DevicesIDL Definitioninterface DeviceDefine:ServiceBuild,Device

{string buildServiceUnsychron (in commands comman,in string sessionkey); string buildServiceSychron (in commands comman,in string sessionkey); oneway void start (in string sessionkey);boolean isStarted (in string sessionkey);oneway void stop (in string sessionkey);boolean isStoped (in string sessionkey);oneway void destroy (in string sessionkey); oneway void error (in string what,in string sessionkey);oneway void timeout (in string what,in string sessionkey);Devices getInformation ();boolean areYouAlive ();boolean pullSynchronizedWithOutKey (in string backToIOR,in string sessionkey);oneway void pullUnSynchronizedWithOutKey (in string backToIOR,in string sessionkey);boolean pullSynchronizedWithKey (in string backToIOR,in string sessionkey,in string key);oneway void pullUnSynchronizedWithKey (in string backToIOR, in string sessionkey, in string key);boolean pushSynchronizedWithOutKey (in byteArray data,in string sessionkey);oneway void pushUnSynchronizedWithOutKey (in byteArray data,in string sessionkey);boolean pushSynchronizedWithKey (in byteArray data,in string sessionkey,in string key);oneway void pushUnSynchronizedWithKey (in byteArray data,in string sessionkey, in string key);

};

CTL Testszenario

Ein videostreamanbietendes Device (MPEG-2) publiziert an ein darstellendes Device.

Prinzipiell:

Anbieter und Darsteller sind in beliebiger Anzahl möglich und kombinierbar.

Contentprovider

Devicepublisher

Contentconsumer„ServiceBuilder“

CTL Testszenario

ConnectByDeviceproviding content informations

getAllDevicesretrieving device

informations startinitiate streaming

pushSynchronizedWithOutKeystreaming video data

Ablauf

Devicepublisher

Contentprovider

Viewer

CTL Testszenario

leer

Multipoint-VideokonferenzTelelearning-Szenario

Devicepublisher

Devicepublisher

exchanging deviceinformations

exchanging deviceinformations

Contentprovider

Contentprovider

Contentprovider

Viewer Viewer

Devicepublisher

Viewer

Viewer

Viewer

Viewer

ModerierteArbeitsgruppe

VorlesungHörsaal

Externe Zuschauer

CTL: ErgebnissePufferstrategie:

Zwei exemplarische Verläufe der Pufferauslastung während einer Stunde (hoher Pufferfüllstand ist erstrebenswert)

Übertragung ohne besonderes Puffermanagementbezüglich der Speicherung und interner Organisation; kontinuierliches push von Paketen konstanter Größe

Übertragung mit Puffermanagement:Anpassung der Paketgröße zur Optimierung des Overheads in Abhängigkeit vom Füllstand des Empfängerpuffers; kontinuierliches push durch den Sender

CTL: Ergebnisse

Inprive Visibroker:❚ Grunsätzlich gute Performance❚ Gute Integration in Java-Entwicklungsumgebung❚ Schwierigkeiten wegen der teilweise unglücklichen CORBA-Umsetzung (bis zur Version 4)

(COS naming)❚ Keine 100%-ige Datenkonsistenz des eigentlich deutlich schnelleren Oneway-Aufrufes

(mit Version 4)

Fazit:In der Summe der Erfahrungen steht einer CORBA-basierten PREMO-Umsetzung nichts entgegen.

Alle Vorteile von CORBA, Java & JMF stehen im Framework für verteilte multimediale Anwendungen zur Verfügung.

Perspektive

PRogramming Environment for Multimedia Objects

Motivation

CORBA

Weitere Existenz undPflege

PlattformunabhängigkeitProgrammiersprachenunabhängigkeit

Vielzahl von Diensten

Hohe SicherheitVereinheitlichterAufbau

Globale Entwicklung

Middleware für Multimedia-Frameworks

PREMO-Implementation mit CORBA

❚ Tauglichkeit❙ Objektmodell

❙ Objektlebenszyklus

❙ Kopieren von Objekten

❙ Kontinuierliche Datenströme (Onewayaufrufe außer acht gelassen)

PRESSETEXT

ABSCHLUSSVERANSTALTUNGFORSCHUNGSVERBUND MULTIMEDIA ANNRW-FACHHOCHSCHULEN

Prof. Dr. Stenzel, FH Köln, Herr Schröer,MSWF, Prof. Dr. Schneeberger, ProrektorFH Bochum, Dr. Köster, MSWF

Große Resonanz beim interessierten Fachpublikum fanddie Abschlusspräsentation des ForschungsverbundesMultimedia an Fachhochschulen in Nordrhein-Westfalenam 30.11.00 an der FH Bochum.

Im Verbund von Wissenschaftlern aus fünf verschiede-nen Fachhochschulen des Landes wurden seit 1997 eineReihe von Projekten durchgeführt, die aktuelle Bereicheindustrierelevanter Multimedia-Entwicklung abdecken.Die Aufgaben behandelten den intelligenten Entwurf unddie Realisierung von (prototypischen) Informationssyste-men in Medizin, Umwelt und Bauwesen, inklusive dermultimedialen Elemente der Virtuellen Realität und derBearbeitung von Bilddaten auf verteilten Plattformen.

Auf dieser Abschlußveranstaltung wurden die erarbeite-ten Projekte vorgestellt.

Der Sprecher des Forschungsverbundes, Prof. Dr. HorstStenzel, FH Köln und der Prorektor der FH Bochum, Prof.Dr. Frank Schneeberger begrüßten insbesondere Dr.Köster aus dem Ministerium für Schule, Wissenschaftund Forschung des Landes Nordrhein-Westfalen, der dieerfolgreich abgeschlossenen Projekte würdigte, die alle-samt wichtige Anstöße gaben im Hinblick auf Multimedia-Einsatz in der heimischen Industrie, aber auch der Qua-lifikation der beteiligten Studierenden und Diplomandendienten und den Hochschulen wichtige Impulse gab. Dr.Köster nutzte die Gelegenheit, die neue Campus-Source-Initiative des Ministeriums zu erläutern, die vor allemneue Schwerpunkte in der multimedia-gestützten Lehrean den Hochschulen geben soll.Der Sprecher des Forschungsverbundes, Prof. Dr. Stenzel,zeigte die Synergie-Effekte, die sich sowohl in der Zu-sammenarbeit der verschiedenen Fachdisziplinen derbeteiligten Hochschulen wie auch den einbezogenenIndustriebetrieben ergab.

Der Senatssitzungsraum verwandelte sich in ein Kongreß-Center:Vorträge wurden ergänzt durch die praktische Vorführung an PC-Arbeits-plätzen. Sogar ein Web-Server wurde installiert, um das Prinzip verteilterDaten und den Online-Zugriff darauf zu demonstrieren.

Auskünfte:

FH Bochum KIT 0234-32-10702www.fh-bochum.de/kitForschungsverbund Multimedia Prof. Dr. StenzelDer Forschungsverbund im WWW:http://www.gm.fh-koeln.de/Projekte/VerbundFPArbeitskreis Multimedia der Fachhochschulen in NRWhttp://www.gm.fh-koeln.de/MM-AK-FH-NW

Besonderer Blickfang unter den messeartig präsentiertenExponaten war sicherlich das plastifizierte Herz, eineigens angefertigtes Herzmodell und ein neuartiger 3D-TFT-Bildschirm zur Simulation des Herzinneren. WeitereThemen: Java-gestützte Bilddatenbanken, die niederge-lassenen Ärzten ebenso wie Medizinern im Krankenhauseinen Online-Zugriff auf Röntgenbilder erlauben, virtuel-le Fahrten in einem Modell der Bielefelder Straßenbahnoder die weltweit erste digitale Panoramakamera, diezum Abschluß der Veranstaltung noch für ein Gruppen-foto "zweckentfremdet" wurde.

Prof. Dr. Weber (oben), Prof. Dr. Blümel (links) präsentierten ihre Multime-dia-Projekte. Herr Schröer (oben rechts) aus dem MSWF läßt sich dieinnovativen Ansätze und das Industrieinteresse erläutern

Ein Kunstherz auf dem neuartigen Stereomonitor: Visualisierungshilfe fürangehende Mediziner und Medizintechniker

Aspekte der Visualisierung und interaktiven Begehung simulierter Städte-baulicher Situationen zeigen Prof. Gatermann (links) und Prof. Dr. Trautwein(daneben).

Documents

Bernd Blümel Harald Gatermann Walter Hillen Horst …hstl/Dokumente/Java-Framework-Abschluss.pdf · Ein Java-Framework auf Basis von RMI, CORBA, JNI und JDBC von Ein Gemeinschaftsprojekt